番外 (三)：跨模型协同工作流—— Claude 生成，Codex 校验

自写自审容易带着相同盲区，难以自查。本文介绍双模型接力工作流：包含四种桥接方案、双终端四步法，同时说明该模式的适用边界，讲清什么时候没必要这么折腾。

Claude Code
返回文章列表

先想一个熟悉的场景：你让 Claude 写完一个功能，再让它自己审一遍。它会认真检查，然后告诉你“没问题”。你信了，代码合进去，三天后线上炸了。

问题不在它不认真，在于写代码和审代码的是同一个脑子。它当时没考虑到的边界，审的时候大概率还是考虑不到。人也是这样：自己写的方案自己读三遍，错别字都看不见。

跨模型工作流解决的就是这件事：让一个模型写，另一个模型审。它的价值不在模型更强，而在多一双没参与写作的眼睛。

三种桥接方式，从轻到重

把另一个模型接进 Claude Code，业界有三条路，素材仓库把它们归为 Plugin、MCP、Router：

方式 怎么接 代表项目 代价
Plugin 另一个模型的 CLI 以斜杠命令的形式跑在 Claude Code 里 openai/codex-plugin-cc（提供 /codex:review、/codex:adversarial-review 这类命令） 最轻，装个插件就能用；但只在被调用时干活
MCP 把另一个模型包装成一个 MCP 工具，Claude 需要时调用 BeehiveInnovations/pal-mcp-server（原名 zen-mcp-server，支持五十多个模型） 中等，要配 MCP 服务；调用方式更像工具
Router 直接换掉 Claude Code 的 API 端点，请求转发给别的供应商 musistudio/claude-code-router、router-for-me/CLIProxyAPI 最重，也最需要小心——它改的是 Claude Code 的“大脑”本身

前两种是“加一个工具”，第三种是“换一个大脑”。Router 方案能力最强（可以按任务切换模型），但它把请求交给了第三方中转，牵涉账号授权和计费归属——用之前先按番外《Claude 封号自救指南》里那组四问核对一遍：程序有没有被改、谁完成登录、凭据存在哪、费用记在谁账上。

下面重点讲第二种里最朴素、也最不依赖工具的一种：两个终端，各跑各的。

双终端四步法

素材仓库记录了一套已经跑通的手工流程：终端 1 开 Claude Code，终端 2 开 Codex CLI，四个步骤轮流接力，中间只靠一份计划文件交接。

双终端接力：一份计划，两个模型 1 · Plan（Claude Code） 2 · QA 审查（Codex） 3 · Implement（Claude Code） 4 · Verify（Codex） plan mode 问清需求，产出分阶段计划 对照代码库找漏洞，只加 Phase 2.5 按阶段推进，每个测试门都过才继续 对照计划验收，不通过就退回 plans/{feature-name}.md 两个模型唯一的交接物 审查者只加不改：第二份意见不该把原计划推倒重来

四步分别是：

  1. Plan（Claude Code，plan mode）：让 Claude 进入计划模式，用提问的方式把需求问清楚，产出一份分阶段的计划，每个阶段带测试门。落盘为 plans/{feature-name}.md。
  2. QA 审查（Codex）：Codex 读这份计划和实际代码库，找计划与代码对不上的地方，把新阶段插进去（比如“Phase 2.5”），每条以 Codex Finding 开头。只加不改——它不允许重写你原来的阶段。
  3. Implement（Claude Code）：新开一个 Claude Code 会话，按阶段逐个实现，每过一个测试门才进下一阶段。
  4. Verify（Codex）：新开一个 Codex 会话，对照计划验收实现，不通过就退回第 3 步。

这套流程能跑起来，靠的是三条纪律：

纪律一：计划文件是唯一交接物。 两个模型不共享对话、不共享上下文，唯一的共识就是那份 plans/{feature-name}.md。计划写得含糊，审查就会变成两个模型各说各话。所以第 1 步的产出质量，直接决定后面三步有没有意义。

纪律二：审查者只加不改。 这是整套流程最聪明的设计。如果允许 Codex 重写计划，它会按自己的思路把 Claude 的方案推倒重来，两个模型开始打架，你夹在中间当裁判。只允许“插入新阶段、标注依据”，既保住了原计划的结构，又让审查意见变成可执行的增量。

纪律三：每个阶段都有测试门。 阶段之间不是“写完就过”，而是“测试通过才过”。这条把“实现得对不对”从主观判断变成了可验证的事实——也是第 4 步验收时唯一可靠的依据。

给 Codex 的审查提示词，可以直接抄这个结构：

读 plans/checkout.md 和实际代码库，找出计划与代码不符的地方。
只新增阶段（Phase 2.5、2.6……），不要改写已有阶段。
每条新增阶段以 "Codex Finding:" 开头，写清楚依据的文件和行号。
不要修改任何代码，只改计划文件。

最后一句“不要修改任何代码”值得单独说：审查阶段一旦让模型动手，它就会开始“顺手修一下”。审查者一动手就成了第二个作者，第二意见也就不存在了。

什么时候值得，什么时候不值得

跨模型不是免费的。两个模型要两份上下文、两份订阅（或两份 API 账单），交接还要人来搬运。所以它适合的任务有明确特征：

值得：改核心链路、动钱、动权限、大重构——这类改动一旦漏掉边界，代价远高于交接成本；或者你已经把同一段代码让 Claude 审过两轮，心里还是不踏实。

不值得：改文案、加日志、写测试这类低风险小改动；以及需求本身还没想清楚的时候——两个模型会给你两份互相矛盾的计划，除了更乱没有别的效果。

一个常被忽略的判据：如果你自己看不出第二份意见对不对，跨模型也帮不了你。它的价值是补充你没想到的角度，不是替你做决定。

值不值，看改动有多疼

跨模型工作流的本质，是把“自我审查”换成“外部审查”——和代码评审、结对编程是同一个道理，只是审查者换成了另一个模型。

交接有成本，但和“上线三天后才发现炸了”相比，这点成本通常不值一提。

本文是《从 Vibe Coding 到 Agentic Engineering》系列的番外。正篇十二篇已收官，从第 1 篇《认知开篇》读起，或直达第 12 篇《收官：官方团队 83 条技巧精编》。