Claude Code × Codex 双模型协作实战指南

> 适合分享给：已经在用 AI coding 工具、但还停留在“哪个模型更强”比较阶段的工程师、技术负责人和个人开发者。

先说结论

不要把 Claude Code 和 Codex 只当成竞争关系。更有价值的做法是：

这篇指南基于 XDA 文章《I use Claude Code and Codex together, and the combination does something neither can do alone》的观点整理，并补充了可落地的工程使用方法。

原文提供的核心启发

原文作者的经验可以压缩成三句话：

1. Claude Code 和 Codex 背后是不同模型家族，对“好代码”的直觉不同。 2. Claude Code 更适合 UI、设计、视觉层级和需要审美判断的任务；Codex 更适合耐心排查、理解问题、拆解复杂故障。 3. 让模型审查自己的代码不可靠；把一个模型的 diff 交给另一个模型审查，更容易发现盲点。

原文也明确有局限：这是个人经验，不是大规模基准测试。因此下面的工作流不是“绝对规则”，而是一套低风险、可验证的实践模板。

一、把 AI coding 从“单模型执行”改成“双模型流水线”

最低可行架构如下：

需求/问题
  ↓
模型 A：生成方案或代码
  ↓
本地测试 / 静态检查
  ↓
模型 B：冷启动审查 diff、边界条件、安全问题
  ↓
人类决策：采纳 / 回退 / 二次修改
  ↓
最终验证：测试、lint、运行结果、人工抽查

关键点不是“多叫一个模型”，而是让两个模型承担不同角色：

二、推荐分工：谁更适合做什么

1. Claude Code：适合视觉、结构和产品体验

优先交给 Claude Code 的任务：

示例提示词：

你负责前端 UI 改造。请只修改 src/components/TaskBoard.vue。

目标：
- 保留现有业务逻辑；
- 优化布局、间距、状态层级和空状态文案；
- 移动端不要横向溢出；
- 不新增依赖。

完成后请说明：
1. 改了哪些视觉层级；
2. 哪些业务逻辑没有动；
3. 我应该运行哪些命令验证。

验收标准：

npm run lint
npm run test
npm run build

预期输出：

- 页面布局更清晰；
- 空状态、错误状态、加载状态都有明确提示；
- 业务函数和 API 调用没有被重写；
- build 成功。

失败处理：

三、Codex：适合排错、复杂逻辑和耐心审查

优先交给 Codex 的任务：

示例提示词：

你是审查者，不要直接重写实现。请阅读当前 diff，并从以下角度找问题：

1. 是否有边界条件遗漏；
2. 是否引入并发、事务、缓存或状态一致性问题；
3. 是否有安全风险或敏感信息泄露；
4. 是否有测试没有覆盖的路径；
5. 是否有更小改动就能解决问题。

输出格式：
- Blocking：必须修的问题；
- Important：建议修的问题；
- Nice to have：可选优化；
- 验证命令。

不要修改文件，只输出审查意见。

配套命令：

git diff --stat
git diff -- src tests
pytest -q
ruff check .

预期输出：

Blocking:
- 某个错误路径没有回滚；
- 某个输入为空时会抛异常。

Important:
- 缺少回归测试；
- 日志里可能泄露请求参数。

验证命令:
- pytest tests/test_xxx.py -q
- ruff check .

失败处理：

四、三种最实用的双模型工作流

工作流 1：同题并行，择优合并

适用场景：架构设计、复杂重构、方案选择。

步骤：

1. 把同一个问题分别交给 Claude Code 和 Codex。 2. 要求两边都输出方案、风险和验证方式。 3. 人类比较：哪一边改动更小、风险更低、验证更清楚。 4. 只选择一个主方案执行，不要机械合并两份代码。

示例输入：

我们需要把用户导入任务从同步接口改为异步任务。
约束：
- 不引入新消息队列；
- 先用数据库任务表；
- 保留现有 API 返回格式；
- 必须可回滚。

请给出最小可行设计、涉及文件、迁移风险、测试计划。

验收标准：

工作流 2：一个写，一个审

适用场景：日常功能开发、bug fix、大 diff 合并前。

步骤：

1. 让模型 A 完成实现。 2. 运行测试和 lint。 3. 把 diff、测试输出和需求交给模型 B。 4. 只采纳 Blocking 和 Important 问题。 5. 修复后再次运行测试。

审查提示词：

下面是一个待合并 diff。请假设它可能有问题。

背景：
- 需求：修复用户导入时重复提交导致的状态错乱；
- 约束：不要改数据库事务边界；
- 当前测试：pytest 已通过。

请审查：
1. 是否真的解决重复提交；
2. 是否有竞态条件；
3. 是否改变了事务语义；
4. 是否缺少回归测试；
5. 是否有更小修复。

只输出问题，不要夸奖。

配套输入：

git diff -- src tests > /tmp/review.diff
pytest -q | tee /tmp/test.log

把 /tmp/review.diff 和 /tmp/test.log 一起交给审查模型。

工作流 3：前端交给 Claude，故障交给 Codex

适用场景：全栈小项目、内部工具、管理后台。

建议分配：

示例项目：做一个“SQL 审查任务看板”。

Claude Code 提示词：

请实现一个任务看板页面，展示 SQL 审查任务的状态。

输入数据结构：
{
  "id": "task-001",
  "file": "20260519_add_index.sql",
  "status": "reviewing",
  "risk": "high",
  "updated_at": "2026-05-19 17:00:00"
}

要求：
- 四列：待审查、审查中、已通过、已拒绝；
- 高风险任务要有明显但不刺眼的视觉提示；
- 空列要有空状态；
- 不调用真实 API，先用 mock 数据。

Codex 审查提示词：

请审查这个任务看板实现。

重点：
- 状态枚举是否完整；
- 高风险标记是否可能误导用户；
- 空数据、未知状态、时间为空时是否可用；
- mock 数据是否和未来 API 结构兼容；
- 是否缺少组件测试。

验收标准：

npm run test
npm run lint
npm run build

预期结果：

五、安全边界：不要一上来就全自动

双模型协作并不等于让两个 agent 自动互相改代码直到“看起来通过”。建议按风险分层：

低风险

可以让模型直接改：

中风险

允许模型改，但必须人工审查：

高风险

先只读审查，不允许直接执行：

高风险任务推荐提示词：

你只能做只读审查，不允许修改文件。

请输出：
1. 当前方案的风险点；
2. 需要人工确认的问题；
3. 最小安全试运行方案；
4. 回滚方案；
5. 必须通过的验证命令。

六、一个可直接复用的双模型协作模板

生成者提示词

你是实现者。请在最小范围内完成任务。

任务：{具体任务}

边界：
- 只修改：{允许修改的路径}
- 不允许：{禁止事项}
- 不新增依赖；
- 不改公共接口，除非明确说明。

完成后输出：
1. 修改文件列表；
2. 关键实现说明；
3. 风险点；
4. 验证命令；
5. 如果无法完成，说明阻塞原因。

审查者提示词

你是独立审查者。不要默认实现是对的。

请基于需求、diff 和测试输出审查：
- 是否满足需求；
- 是否有边界条件遗漏；
- 是否有安全或数据风险；
- 是否有不必要的大改；
- 是否缺少测试；
- 是否有更小、更安全的实现。

输出格式：
- Blocking：必须修；
- Important：建议修；
- Nice to have：可选；
- 验证建议。

不要输出泛泛建议，必须指向具体文件、函数、行为或测试。

人类仲裁清单

[ ] 需求是否真的完成？
[ ] 修改范围是否足够小？
[ ] 是否有测试覆盖核心路径？
[ ] 是否有失败/回滚方案？
[ ] 审查模型指出的问题是否已处理或明确拒绝？
[ ] 本地验证命令是否通过？
[ ] 是否涉及生产数据、权限、密钥或外部副作用？

七、常见坑

坑 1：两个模型都动手改，最后没人知道谁改了什么

建议：一次只让一个模型写代码，另一个只审查。需要并行方案时，也先让它们输出设计，不要同时改同一份代码。

坑 2：把两个模型的建议全部合并

建议：不要机械合并。优先选择改动更小、验证更清楚、回滚更简单的方案。

坑 3：审查提示太温和

如果你只说“帮我看看有没有问题”，模型容易输出礼貌型总结。要明确说：

你是反方审查者。只找问题，不要夸奖。

坑 4：没有把测试输出交给审查模型

只给 diff 不够。测试失败、lint 报错、运行日志会显著提高审查质量。

坑 5：把高风险操作交给 agent 自动执行

数据库、生产配置、部署、权限、账单相关任务必须先只读审查，再人工确认。

八、一周内的落地路线

第 1 天：建立规则

第 2–3 天：选择一个低风险任务试跑

推荐任务：

记录三件事：

任务：
生成模型：
审查模型：
审查发现的问题：
最终采纳的问题：
验证命令：
结论：值得继续 / 暂停 / 调整提示词

第 4–5 天：引入中风险任务

选择一个真实 bug fix 或小功能，但不要涉及数据库迁移和生产配置。

第 6–7 天：沉淀模板

把有效提示词、验证命令、常见问题整理成团队模板。不要急着自动化；先让流程稳定。

最终建议

双模型协作的目标不是“让 AI 更像一个自动程序员”，而是把 AI coding 拆成更接近真实工程团队的流程：有人写，有人审，有人仲裁，有测试兜底。

Claude Code 和 Codex 的组合价值，正在于它们不是同一种“程序员”。差异本身就是生产力，但前提是你把差异放进正确的流程里。

来源与边界