一个模型再强，也只是一个工种。
真正的提效，是把对的模型放在对的环节，让它们各干各的擅长事。
最近一段时间，我逐渐把日常开发从「单点 AI」切换成了一条小型流水线：
- Claude Opus 4.7：负责沟通确认、需求拆解、顶层设计
- Codex：负责按设计写代码，把活干出来
- Claude Code：负责跑代码、验收、查漏补缺、做最后的优化
跑了一阵之后，效率比之前用任何单一工具都要稳，体验也更接近「带团队」而不是「催一个工人」。这篇博文把这套思路和心得整理出来。
为什么不是「一个模型干所有事」
最朴素的想法是：用一个最聪明的模型把所有事都搞掉，省事。
但实际跑下来你会发现几个问题：
| 阶段 | 用顶级模型 | 用编码专精模型 |
|---|---|---|
| 沟通确认需求 | ✅ 思考深、能反问 | ❌ 容易直接动手 |
| 顶层设计 | ✅ 全局视角强 | ⚠️ 偏实现细节 |
| 写大量样板代码 | ⚠️ 贵且未必更快 | ✅ 又快又准 |
| 跑测试、做修复 | ✅ 推理强、能闭环 | ⚠️ 容易卡在表层错误 |
| 重构与优化 | ✅ 看得见全局 | ⚠️ 容易局部最优 |
结论很简单：
「思考」用 Opus，「执行」用 Codex，「闭环」用 Claude Code。
把三者拼起来，每一段都用它最擅长的方式，整条链路才会顺。
整体工作流
我现在的标准流程是这样的：
用户需求
│
▼
┌────────────────────────┐
│ ① Claude Opus 4.7 │ 沟通 / 反问 / 顶层设计
│ - 澄清需求 │ 产出：Spec + 架构方案
│ - 拆任务 │
│ - 写 Spec │
└────────┬───────────────┘
│ Spec / 设计文档
▼
┌────────────────────────┐
│ ② Codex │ 代码执行
│ - 按 Spec 写实现 │ 产出：可运行的代码
│ - 覆盖基础测试 │
│ - 提交 PR / Patch │
└────────┬───────────────┘
│ 代码 / PR
▼
┌────────────────────────┐
│ ③ Claude Code │ 验收 + 优化
│ - 跑测试 / 修 bug │ 产出：可上线的版本
│ - 重构 / 性能优化 │
│ - 文档收口 │
└────────────────────────┘
三段之间，交付物是文本（Spec、Diff、Review），所以每一步都可以被人类回顾、修改和打回重做。这是这套流程最关键的一点。
① Claude Opus 4.7：先把事情想清楚
Opus 这一段我不会让它写代码，它的任务是「不让我直接写代码」。
它该做的事
- 反问澄清：把模糊的需求逼问到可以落地为止
- 拆任务：把一个目标拆成几个可独立验收的子任务
- 顶层设计：定模块边界、数据结构、关键接口
- 写 Spec：用一份能直接交给 Codex 的文档收口
我常用的开场 Prompt 模板
我要做 XXX，背景是 YYY，目前已有 ZZZ。
请先不要写代码。
1. 列出你目前还不确定 / 需要我确认的问题，至少 5 条
2. 在我回答后，给我一份顶层设计：
- 模块划分与职责
- 关键数据结构 / 接口
- 主要风险点与取舍
3. 最终把这些整理成一份 Spec，结构清晰，
可以直接交给另一个 AI 按它来写代码
真实的好处
- 少写错 比 多写快 更重要。Opus 反问一轮，能在 5 分钟内挡掉 1 小时的瞎写
- 强迫自己想清楚边界：很多需求在被反问的过程中，自己就修正了一遍
- 得到一份可复用的 Spec：哪怕之后换个执行模型，Spec 也还在
心得：这一步不是为了让 AI 做更多事，是为了让你不犯方向性错误。
② Codex：让它专心干活
到了 Codex 这一步，事情应该已经很明确了。
我喂给它的，通常包括：
- 上一步的 Spec / 顶层设计文档
- 项目结构 + 关键代码（用来给它「下游约束」）
- 一句明确的产出要求，例如：
按上面的 Spec 实现模块 A 和模块 B。
- 不要改 Spec 之外的文件
- 实现完后给我一份变更清单
- 给关键函数补上最小可行的单元测试
为什么用 Codex 来做这一段
- 快：基础代码、CRUD、样板、单测这种东西，它是真的快
- 听话：在有 Spec 的前提下，它不太会「自由发挥」
- 便宜：编码这种「重复劳动」用编码专精模型更划算
几个踩过的坑
- 不要在没有 Spec 的情况下直接让它干：容易越写越偏
- 一次别让它改太多模块：每次盯一个边界，review 更清晰
- 测试要它一起写：基础测试不补，下一步 Claude Code 会非常痛苦
③ Claude Code：闭环 + 把代码「磨亮」
Codex 写完之后，事情还没结束。
代码能跑 ≠ 代码可上线。这一步交给 Claude Code，因为它擅长：
- 真实地跑命令、看结果：测试、lint、type check、构建
- 基于真实报错做修复：不是猜，是真的看 traceback
- 从全局视角做优化：命名、抽象、错误处理、边界条件
- 顺手写一点文档：README、注释、变更说明
我交接给 Claude Code 的方式
Codex 已经按 Spec 实现了 A 和 B 模块，PR / Patch 见上。
请你：
1. 把项目跑起来，确认基础链路 OK
2. 跑全部测试，修掉失败的用例
3. 检查实现是否真的对齐 Spec，列出偏差
4. 在不扩大改动范围的前提下，对：
- 命名 / 抽象
- 异常处理
- 边界条件
做必要的优化
5. 最后给我一份「这次变更做了什么 / 还有什么没做」
它的几个高价值动作
| 动作 | 价值 |
|---|---|
| 真的跑测试 | 把「看起来对」变成「真的对」 |
| 对照 Spec 找偏差 | 防止 Codex 偷工减料 |
| 小步优化而非重写 | 不破坏 Codex 的实现，只把粗糙处磨平 |
| 输出变更说明 | 下次你回顾时不用从 0 看代码 |
心得：Claude Code 不是「再写一遍」，而是「把已经写好的版本送上线」。
一个真实的小例子
举一个最近的小活：给一个 Python 脚本加「热榜筛选 + 分类输出 + Markdown 报告」三个能力。
第一步：Opus 沟通
我只说了一句：
想给现在的 GitHub 热榜脚本加个「按主题筛选 + 自动分类 + 出一份 Markdown 报告」的能力。
Opus 回了我 6 个问题，包括：
- 主题筛选是关键词匹配，还是用模型分类？
- 分类粒度多细？是否要用户可配置？
- Markdown 报告是按天聚合，还是每次运行覆盖？
- 是否需要历史归档？
- 失败时如何降级？
- 与现有自动化 workflow 的接口怎么对齐？
我答完之后，它输出了一份 Spec：模块怎么分、配置怎么设计、关键函数签名、风险点列表、最小可行验收标准。
第二步：Codex 执行
我把 Spec 丢给 Codex，限定它只能改 scripts/ 下的几个文件，并补上单测。
它在不到一轮交互里给了我：
- 一份按 Spec 拆好的实现
- 一份配置模板
- 三个最小单测
第三步：Claude Code 收尾
Claude Code 这一步做了：
- 真实跑了脚本，发现「分类为空时报告会崩」
- 修了边界条件
- 把一个臃肿的函数拆成两个，命名也顺了一下
- 给配置加了 schema 校验
- 在 README 补了一段使用说明
- 输出一份变更清单给我审
整体下来，我自己写代码的时间是 0，但每一步的关键决策我都参与了。
关于「让谁补充」这件事
这套流程里，我自己其实有第四个角色：编辑 / 决策者。
每一段交付物（Spec、代码、Review），我都会快速过一遍，主要看三件事：
- 方向有没有跑偏（这是 Opus 阶段最该被人盯的）
- 实现有没有偷工（这是 Codex 阶段最容易出问题）
- 闭环有没有真的闭上（这是 Claude Code 阶段的底线）
如果某一步出了问题，我不会让它「再来一次」，而是回到最早能修的那一步。比如：
- 代码写歪了，但 Spec 是清楚的 → 改 Codex 那一步
- 代码写歪了，回头看 Spec 本身就含糊 → 退回 Opus 重新设计
- 代码没问题，但跑起来不对 → 让 Claude Code 排查环境/集成
越早出错越便宜，越晚出错越贵。 三段式流水线最大的好处就是让你能定位到最早的出错点。
我踩过 / 想提醒的几个坑
不要让 Opus 直接写代码
它能写，但代价很高，而且会让你失去「Spec 这一份资产」。把它当架构师用。不要让 Codex 自己决定要不要写测试
要在指令里明确写出来。基础单测的有无，直接决定第三步的成本。不要让 Claude Code 重写
它一旦开始「全局重构」，往往会破坏前两步的设计意图。要明确告诉它：最小改动，对齐 Spec。三段之间用「文档化交付物」对接
Spec 是文本、代码是 Diff、Review 是清单。不要让中间状态只活在某个聊天窗口里，全部沉淀到仓库里。保留人类的最后一次按键
合并、上线、对外发布这种动作，永远留给自己。AI 跑得越自动，人类越要管住「最后一脚」。
总结
一句话版本：
Opus 想清楚 → Codex 写出来 → Claude Code 送上线，中间用 Spec 和 Diff 串起来。
更长一点的版本：
- 把「沟通确认 + 顶层设计」这种需要全局视角的事，留给 Opus 4.7
- 把「按计划执行 + 写基础代码 + 补基本测试」这种重复劳动，交给 Codex
- 把「真实跑起来 + 修 bug + 小步优化 + 收口文档」这种闭环动作，交给 Claude Code
- 自己只做三件事：定方向、看交付、按下回车
这套流程不是为了把人从开发里赶出去，而是为了让你每次出手都打在最有价值的那一拍上。