如果你现在还在“一个模型干到底”，大概率会遇到三个问题：要么贵、要么慢、要么返工多。

更实用的做法是：把 Claude Code 和 Codex 当成两个不同岗位来配合——一个偏长链路规划和重构，一个偏快速代码落地和批量执行。

结论先给：怎么分工最划算

我在真实开发里用下来，最稳的分工是：

  • Claude Code：做需求拆解、架构方案、风险检查、关键重构
  • Codex：做脚手架、批量修改、测试补全、文档同步

一句话：“Claude 管方向，Codex 管产量。”

对比维度：成本、速度、质量怎么量化

别靠体感，最少用这 4 个指标：

  • 成本：每个任务的 token 或调用成本
  • 速度：从创建任务到可合并（MR/PR Ready）的总时长
  • 质量：一次通过率、回滚率、review 修改量
  • 稳定性：上下文变长后，输出一致性

你可以在每个任务结束时记一条日志：

echo "$(date +%F_%T),task=api-refactor,model=codex,cost=0.42,time_min=26,review_round=2" >> .ai-benchmark.csv

可直接抄的协作流程（本地仓库）

1) 先让 Claude Code 定“任务边界”

给 Claude Code 的 prompt 模板：

你是 Tech Lead。
目标：把 UserService 的鉴权逻辑从 controller 下沉到 middleware。
请输出：
1) 变更清单（按文件）
2) 风险点
3) 验收标准
4) 回滚方案

产物要求：

  • 文件级变更清单（避免大而空）
  • 明确“不做什么”（防范围膨胀）
  • 验收标准可自动化（test/lint/build）

2) 再让 Codex 做“批量落地”

Codex 执行模板：

按以下清单改代码，不要改未列出的文件。
完成后必须：
- 运行测试
- 输出变更摘要
- 标注高风险 diff

这一步最容易提速，尤其是：

  • 机械性 rename
  • 跨文件接口对齐
  • 单测补齐
  • README/注释同步

3) 回到 Claude Code 做“质量闸门”

让 Claude Code 专门做 3 件事：

  • 检查设计一致性（有没有偷偷歪楼）
  • 检查边界场景（空值、并发、重试、超时）
  • 给出 reviewer 视角的“高风险点”

实战里最值钱的 5 条规则

  1. 每个模型只负责一种角色，别混用。
  2. 一轮最多 1 个子目标，否则上下文污染很快。
  3. 所有 AI 结果必须可回放（prompt + diff + 测试结果）。
  4. 不通过测试就不进入下一轮。
  5. 出现两次返工就换模型角色，不要硬扛。

常见翻车点与排查

问题 1：速度快了，但回滚变多

原因通常是 Codex 改得太散、跨越边界。

处理：

  • 加“白名单文件”限制
  • 每次只允许一个主题改动
  • 强制输出 git diff --stat
git diff --stat
git diff --name-only

问题 2：Claude 给的方案好，但落地慢

原因通常是方案粒度太大。

处理：

  • 让 Claude 先给“最小可合并版本（MMP）”
  • 把任务切成 30-60 分钟可完成的块

问题 3：两个模型结论互相冲突

处理优先级：

  • 以测试与监控数据为准
  • 以系统约束（SLA、兼容性）为准
  • 以最小风险变更为准

一套轻量自动化（可选）

# 1) 记录任务开始
TASK_ID="auth-mw-$(date +%s)"
echo "$TASK_ID,start,$(date +%s)" >> .ai-run.log

# 2) 执行测试（示例）
npm test

# 3) 记录结束
echo "$TASK_ID,end,$(date +%s)" >> .ai-run.log

再配一个简单脚本统计平均耗时和返工率，就能知道你的协作策略到底有没有省钱。

什么时候不该用双模型

  • 项目极小（1-2 个文件改动）
  • 时限极短（10 分钟内必须出结果）
  • 团队没有 review 习惯（会放大风险）

这时候单模型直推更快，流程成本更低。

总结

多模型协作不是“更高级”，而是把不同模型放在最擅长的位置。

如果你现在的痛点是“改得快但不稳”，先让 Claude 做边界和验收，再让 Codex 批量执行；如果痛点是“方案好但速度慢”，就把任务切小并让 Codex 吃掉机械工作。

先跑 2 周、记录 20 个任务，再决定你的最终配比。别靠感觉，靠数据。