让强模型做“总工”，让高性价比模型写代码：一个可验收、可返修的跨模型开发工作流
本文以“在Codex中使用主模型（gpt-6 Astra）负责方案、调度和验收，deepseek-harness中执行模型（deepseek v4.1 flash）负责编码”为例，介绍一种可落地的跨模型开发方式。重点不是比较模型排名，而是把不同模型放在更适合它们的位置，并用工程流程约束交付质量。
一、为什么需要跨模型开发
使用 AI 编程时，我们常常默认“一项任务只能选一个模型”：要么全程使用能力强但价格较高的模型，要么为了节约成本，全程使用更便宜的模型。
其实还有第三种选择：按职责分配模型，而不是按任务绑定模型。
例如：
- 让更擅长推理、架构和审查的模型担任 Planner、Reviewer 和 Tester；
- 让成本更低、编码能力足够的模型担任 Coder；
- 由外层工作流保存需求基线、传递上下文、检查代码差异，并在失败时组织返修。
这有点像软件团队中的“技术负责人 + 开发工程师”：负责人不必亲手写完每一行代码，但要定义目标、约束实现、审查结果，并对最终交付负责。
这里的“强”和“弱”是相对于具体任务而言的。一个模型可能更擅长全局推理，另一个模型可能在局部代码生成上速度更快、成本更低。跨模型工作流的核心不是贴标签，而是做能力路由。
二、为什么模型之间可以协作
1. 模型、Agent 和工具是三层不同的东西
大语言模型本身只接收上下文并生成输出。真正完成“读取仓库、修改文件、运行测试”的，是模型外部的 Agent Runtime 或 CLI 工具。
因此，两个模型不需要在模型内部直接通信。只要外层编排器能够：
- 调用另一个模型对应的 CLI 或 API；
- 把任务说明通过标准输入或接口发送给它；
- 让两个 Agent 访问同一个工作区；
- 收集执行模型的结构化结果；
- 再由主模型读取真实代码差异并验收；
就可以形成跨模型协作。
它的结构可以概括为：
用户需求
│
▼
主模型 Agent
方案 / 调度 / 审查 / 测试 / 最终验收
│
│ 自包含交接包
▼
执行模型 Agent（通过 CLI 或 API 调用）
读取仓库 / 编写代码 / 运行约定检查
│
│ 文件变更 + 结构化报告
▼
共享工作区（事实源）
│
└──────────────► 主模型重新读取 diff 并独立验收
所以，“跨模型”并不是什么神秘的模型互联协议，本质上是三个普通机制的组合：
- 进程间通信：通过 stdin、stdout、JSONL 或 API 传递任务和结果；
- 共享状态：代码仓库、文件差异和测试结果构成共同事实；
- 流程编排：Skill 或工作流定义角色、阶段、验收和返修规则。
2. 共享仓库是事实源，提示词不是
执行模型会返回一份“我修改了什么、测试是否通过”的报告，但这只能作为线索，不能直接作为验收结论。
真正可信的事实应来自：
- 当前工作区中实际存在的文件；
git diff展示的累计变更；- 静态检查、单元测试或构建命令的真实输出；
- 对每条验收标准的逐项核对。
这条原则非常重要：模型的自述不是证据，工作区和验证结果才是证据。
3. 会话 ID 让返修保留上下文
如果执行端支持可续接会话，首次调用后可以保存其 sessionId。验收失败时，主模型把缺陷单发送回同一个会话，执行模型便能保留之前的实现上下文。
这样做有两个好处：
- 不必在每次返修时重新解释整个代码库和实现过程；
- 执行模型知道哪些部分已经完成，只处理验收失败项，减少“重写一遍”造成的回归。
但会话记忆只能提高效率，不能代替交接信息。每份返修单仍应包含证据、位置、预期行为和复验方式。
三、角色应该怎样划分
一套稳定的跨模型流程，首先要避免角色漂移。
主模型：总工与验收者
主模型负责：
- 理解真实目标，区分“用户想达到什么”与“用户建议怎么做”；
- 探索代码和约束，制定可执行方案；
- 定义 IN Scope、OUT of Scope、风险和权限边界；
- 把方案转换成执行模型能独立完成的交接包；
- 检查实际 diff，而不是照单全收执行模型的报告；
- 运行约定的验证，逐条核对验收标准；
- 验收失败时生成精确的返修单；
- 对最终结果给出 PASS、PASS_WITH_MANUAL、FAIL 或 BLOCKED。
执行模型：专注编码
执行模型负责：
- 阅读任务指定的项目规则和目标代码；
- 按已确认方案实现，不重新改变技术路线；
- 编写必要且有价值的测试；
- 运行交接包允许的局部验证；
- 报告文件变更、验收标准映射、验证结果和阻塞项。
执行模型不负责：
- 代替用户重新确认需求；
- 擅自扩大范围或重做方案；
- 自己宣布最终验收通过；
- 提交、推送或执行危险的版本控制操作；
- 在缺少权限或关键事实时自行猜测。
用户：控制关键决策
常规流程只需要在方案完成后设置一次人工确认点。之后，执行、验收和有限次数的返修可以自动推进。
只有以下情况需要再次交给用户决策：
- 需求或技术路线发生明显变化；
- 涉及危险操作或新的外部权限；
- 执行模型被环境或事实阻塞；
- 达到返修上限仍未通过。
这样既保留了人的控制权，也避免每个小步骤都等待确认。
四、一个完整的跨模型状态机
用户需求
→ 主模型制定方案
→ 用户确认方案
→ 执行模型首次实现
→ 主模型独立验收
├─ PASS → 完成
├─ PASS_WITH_MANUAL → 完成，列出人工验证项
├─ BLOCKED → 报告阻塞
└─ FAIL → 同一执行会话返修
→ 主模型重新验收全部累计 diff
→ 最多返修 3 轮
→ 仍失败则由用户选择：再试一次 / 主模型接手 / 终止
如果用户在实现过程中主动改变了目标，则进入“需求变更实施”，而不是记为一次返修：
旧需求基线
+ 用户新增、删除或修改预期
→ 更新完整需求基线与验收标准
→ 执行模型增量实现
→ 按新基线验收全部累计 diff
这个区分看似细小，实际非常关键：
- 需求变更是评价标准变了，不代表执行模型之前做错了；
- 实现缺陷是在评价标准不变的情况下，代码没有满足要求。
将两者混在一起，会让返修数据失真，也容易诱导执行模型错误地回滚本来正确的实现。
五、质量闭环的关键设计
1. 先建立可验收的需求基线
方案不能只写“增加某功能”，至少应包含：
- 可观察的目标；
- 范围内和范围外内容；
- 假设条件；
- 文件或代码定位方式；
- 每项实现任务的完成条件；
- 自动验证、手动验证和明确不执行的验证；
- 使用 Given / When / Then 表达的验收标准。
例如：
Given 用户提交了无效输入
When 页面调用保存操作
Then 不发起网络请求，并展示明确的输入错误状态
只有先定义“怎样算完成”，后续审查才不会退化成主观评价。
2. 交接包必须自包含
不要假设执行模型能看到主模型与用户的聊天记录。首次交接包应一次性包含：
# Coding Handoff
## 角色与边界
你是本任务的 Coder，不是 Planner、Reviewer 或最终验收者。
按已确认方案实现，不改变技术路线，不提交代码，不修改范围外文件。
## 项目入口
- 工作目录
- 必读规则
- 与本任务相关的 Skill 或说明
## 原始目标
只保留与实现有关的事实。
## 已确认方案
- IN Scope
- OUT of Scope
- 假设与风险
## 实现任务
- 文件定位
- 行为要求
- 完成条件
- 依赖与禁止项
## 验证契约与验收标准
- 自动验证
- 手动验证
- 不执行项
- Given / When / Then AC
## 最终报告格式
- 状态
- 文件变更
- 任务与 AC 的实现映射
- 实际运行的验证
- 偏差或阻塞
“自包含”不是把整个聊天记录塞进去，而是只提供完成任务所需的事实。这样既节省上下文，也能避免未确认草案、无关讨论和敏感信息进入下游模型。
3. 验收必须独立取证
主模型每轮验收都应重新执行以下动作：
- 查看工作区状态、文件列表、diff 统计和格式错误；
- 阅读每个改动文件的相关完整上下文；
- 检查是否存在未接线代码、临时调试物、生成物或意外删除；
- 从需求轴逐条核对验收标准；
- 从工程轴核对架构、并发、生命周期、安全、兼容性和可维护性；
- 运行验证契约中的静态检查和目标测试；
- 给每条验收标准标记“通过、失败、待手动验证”。
尤其要重新检查全部累计 diff，不能只看最近一轮补丁。返修可能修好一个问题，同时破坏之前已经通过的行为。
4. 返修单要像高质量 Bug 单
“这里不太对，请优化”几乎一定会带来低质量返修。一个可执行的返修项至少包含：
### [严重级别] 问题标题
- 证据：测试输出、复现结果或代码事实
- 位置：文件与当前行号
- 违反：哪条 AC、方案任务或工程规则
- 预期：可观察的正确行为
- 修复边界：允许改什么、禁止改什么
- 复验：主模型将怎样确认问题已解决
返修时只处理失败项，不重做已通过部分，不借机扩大范围。完成后，主模型再次独立取证，而不是接受执行模型的“已修复”声明。
5. 必须设置返修上限
自动返修如果没有上限，很容易进入循环：修复 A、破坏 B，再修复 B、又破坏 A。
比较实用的做法是默认最多三轮。超过上限后，把最后一份完整验收报告交给用户，由用户选择：
- 带额外指导再尝试一次；
- 授权主模型接手剩余失败项；
- 保留当前改动并终止。
上限不是为了放弃，而是防止系统在质量没有收敛时继续消耗预算并提供兜底。
六、跨模型工作流有哪些收益
1. 把高质量推理用在杠杆最高的位置
方案、边界、测试设计和代码审查会影响整个任务，属于高杠杆环节。让能力更强的模型负责这些工作，可以较早发现方向性错误。
编码通常占用最多 token，且任务已经被拆成明确清单后，对全局推理的要求会降低。此时交给成本更低但编码能力足够的模型，往往更划算。
2. 降低总成本，而不是单纯追求最低单价
总成本可以粗略表示为：
总成本 = 方案成本 + 实现成本 + 验收成本 + 返修成本
跨模型策略节省的是占比通常较高的“实现成本”。但只有在方案足够明确、验收能够拦截问题、返修次数受控时，节省才成立。
如果交接含糊，低价模型反复返工，最终总成本反而可能更高。因此应关注通过验收的单位成本，而不是单次调用价格。
3. 降低“自己证明自己正确”的偏差
同一个 Agent 一边写代码，一边评价自己的实现，容易沿用相同假设，漏掉同一类错误。由另一个模型基于实际 diff 和测试证据进行审查，可以增加认知多样性。
这并不保证一定发现所有问题，但通常比“实现模型自报成功即结束”更可靠。
4. 上下文更聚焦
主模型持有完整需求、架构约束和验收标准；执行模型只接收与编码有关的自包含交接包。角色分离可以减少无关上下文，降低模型被长聊天中的旧方案或噪声干扰的概率。
5. 更容易审计和复盘
结构化交接包、验收报告和返修单天然形成了一条决策链：
需求 → 方案 → 实现任务 → 文件变更 → 验证证据 → 返修记录 → 最终结论
当任务失败时，可以判断问题来自需求不清、方案错误、实现偏差、测试不足，还是环境阻塞，而不是只留下“AI 写坏了”这一模糊结论。
6. 降低对单一供应商或单一模型的绑定
只要交接协议稳定，执行端可以从本地 CLI 换成远程 API，也可以替换为另一家模型。主模型同样可以替换。真正需要保持稳定的是：
- 角色契约；
- 输入输出协议；
- 共享事实源；
- 验收和权限边界。
模型因此变成可替换的执行部件，而不是工作流本身。
七、如何通过 DSH 落地
假设 DSH 提供 headless 模式、JSONL 输出和可续接会话，外层 Agent 可以通过标准输入安全地发送交接包：
dsh --profile headless --json -
首次调用后，从结构化事件中保存 sessionId。需要返修时复用会话：
dsh --profile headless --json --session-id <sessionId> -
实现时应注意：
- 通过 stdin 发送完整交接包，不把用户文本拼进 shell 命令；
- 只解析约定的结构化事件，不把终端回显当作模型结果；
- 进程仍在运行时继续等待同一个进程，不重复启动第二个执行 Agent；
- CLI 非零退出、缺少最终事件或报告
BLOCKED时，先判断是否为可恢复的调用问题； - 不向下游传递 token、私钥、凭据或无关聊天内容；
- 执行模型不得获得比外层 Agent 更多的系统权限。
下面是一份经过泛化的 Skill 骨架：
---
name: cross-model-dev-workflow
description: 主模型负责方案、调度和验收，通过 headless 执行器把编码与返修交给另一个模型。
---
# 角色契约
- 主模型：Planner、Orchestrator、Reviewer、Tester、最终验收者。
- 执行模型：唯一 Coder；未经授权不改变方案、不提交代码、不扩大范围。
- 执行模型的自述不是验收证据，主模型必须检查实际 diff 和验证输出。
# Phase 1：方案
1. 提取目标、范围、假设、风险和权限边界。
2. 建立实现任务清单、验证契约和 Given/When/Then AC。
3. 等待用户确认方案。
# Phase 2：实现
1. 检查工作区与分支，确保能区分已有改动和本任务改动。
2. 生成自包含交接包。
3. 调用 headless 执行器，保存 sessionId。
# Phase 3：独立验收
1. 检查全部累计 diff 和未跟踪文件。
2. 分别执行需求轴、工程轴审查。
3. 运行验证契约，逐条判定 AC。
4. 输出 PASS、PASS_WITH_MANUAL、FAIL 或 BLOCKED。
# Phase 4：返修
1. 把带证据、位置、预期和复验方法的失败项发回同一 session。
2. 执行模型只修失败项。
3. 主模型重新审查全部累计 diff。
4. 默认最多三轮，超过上限交给用户决策。
# Phase 5：完成
- 汇总文件变更、AC 结果、验证证据、未执行项和人工验证项。
这份骨架公开的是通用机制，应根据自己的项目情况编写适合自己的skill。
八、安全与工程边界
跨模型意味着多了一个执行入口，因此必须明确最小权限原则：
- 调用前检查工作区，存在无法归属的改动时先停止，避免覆盖用户工作；
- 不允许执行模型自行 commit、push、强制回滚或清理文件；
- 数据库迁移、生产配置、密钥、发布流程等危险操作必须单独确认；
- 交接包不携带敏感凭据；
- 把用户输入作为数据通过 stdin 或 API 传递，避免 shell 插值和命令注入；
- 限制允许执行的测试和构建范围，防止无意触发耗时或有副作用的任务；
- 所有范围外改动都应被解释，否则验收失败。
另外，主模型和执行模型都可能犯错。跨模型工作流提升的是可控性和发现问题的概率，不是数学意义上的正确性证明。高风险代码仍应配合人工审查、隔离环境、自动化测试和发布保护。
九、常见失败方式
失败一：只把一句需求转发给执行模型
结果往往是执行模型重新做方案，技术路线漂移，主模型也无法基于统一标准验收。
改进： 先建立已确认的需求基线，再发送自包含交接包。
失败二：执行模型说“测试通过”就直接结束
报告可能遗漏失败命令、未跟踪文件或范围外改动。
改进： 主模型独立读取 diff，亲自运行约定验证。
失败三：每轮返修都开启新会话
新会话缺少实现背景，容易重写已通过代码，引入新的回归。
改进： 优先复用 session，并在返修单中写清修复边界。
失败四：把需求变化算成编码失败
这会制造错误的质量指标，也会让执行模型尝试“修复”原本符合旧需求的代码。
改进： 分开记录需求变更轮次和验收返修轮次。
失败五：主模型为了省事直接兜底编码
这会破坏角色边界，使成本统计和质量归因都失去意义。
改进： 在返修上限前坚持由执行模型修复；达到上限后，再由用户明确决定是否让主模型接手。
失败六：把所有工作都交给低价模型
这不是跨模型协作，只是模型替换。缺少高质量的方案与独立验收时，返工可能吞掉全部成本优势。
改进： 把更强的推理能力投入需求澄清、架构决策、测试设计和最终审查。
十、什么时候不适合使用
跨模型工作流不是所有任务的最优解。以下情况可能直接使用单模型更高效：
- 一行即可完成、风险极低的机械修改；
- 交接和验收成本明显高于编码成本；
- 任务需要持续的全局架构推理，几乎无法拆成清晰执行项；
- 两个执行环境不能访问同一份代码或可靠交换补丁；
- 下游模型无法满足数据合规、隐私或授权要求；
- 没有任何可验证的验收标准，也无法进行人工检查。
选择跨模型的前提不是“能调用两个模型”，而是任务可以被明确交接、独立取证和有限返修。
十一、建议的落地顺序
第一次实践时，不必立即构建复杂平台，可以从以下最小闭环开始：
- 选一个范围清晰、已有测试的小功能；
- 固定主模型和执行模型的角色；
- 编写一份自包含交接模板；
- 要求执行模型输出结构化报告；
- 由主模型独立检查 diff 和运行目标测试；
- 用同一会话完成一次证据化返修；
- 记录 token、耗时、一次通过率和返修次数；
- 与单模型完成同类任务的数据比较，再决定是否扩大使用。
值得跟踪的指标包括：
- 首次验收通过率；
- 平均返修轮数；
- 通过验收的总 token 或总费用；
- 范围外改动数量；
- 人工介入次数；
- 验收后仍发现的缺陷数量。
这些指标比单纯比较模型单价更能说明工作流是否真正有效。
结语
跨模型开发的价值，不在于“让一个模型指挥另一个模型”这个形式，而在于把 AI 编程从一次性生成，变成一个有角色、有证据、有边界、有返修上限的工程过程。
最值得保留的原则只有几条：
- 按职责选择模型，把昂贵推理用在高杠杆环节；
- 用自包含交接包传递已确认事实，不依赖隐式聊天记忆；
- 把共享工作区和测试输出作为事实源；
- 让验收者独立取证，不接受实现者自证；
- 用精确缺陷单在同一会话返修，并设置停止条件；
- 把权限、安全和人工决策点写进工作流，而不是留给模型临场判断。
当这些约束成立时，更强的模型不必承担所有编码 token，更便宜的模型也不必独自承担架构和质量责任。模型之间的能力差异，反而可以被组织成一个兼顾质量、成本与可控性的协作系统。
