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

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

## 先说结论

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

- 让一个模型负责生成候选方案；
- 让另一个模型负责冷启动审查；
- 对复杂任务并行产出两份方案，再由人做取舍；
- 把 UI/体验类任务和排错/推理类任务拆给不同模型。

这篇指南基于 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 从“单模型执行”改成“双模型流水线”

最低可行架构如下：

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

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

- 生成者：负责推进、产出代码或方案。
- 审查者：负责质疑、找漏洞、指出隐含假设。
- 人类：负责取舍、合并判断和最终上线责任。

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

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

优先交给 Claude Code 的任务：

- landing page 初稿；
- dashboard 或管理后台页面；
- 表单、卡片、状态页、错误页；
- 需要排版、层级、交互文案的前端组件；
- 需要把“粗糙功能”改得更像产品的任务。

示例提示词：

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

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

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

验收标准：

```bash
npm run lint
npm run test
npm run build
```

预期输出：

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

失败处理：

- 如果引入新依赖：回退，要求不新增依赖重做。
- 如果业务逻辑被重写：只保留样式和结构改动。
- 如果 build 失败：先让同一个模型修复语法，再交给另一个模型审查。

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

优先交给 Codex 的任务：

- 测试失败定位；
- 难复现 bug 的最小复现；
- 大 diff 的逻辑审查；
- 数据处理、边界条件、异常路径；
- “为什么这个实现偶尔失败”的根因分析。

示例提示词：

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

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

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

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

配套命令：

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

预期输出：

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

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

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

失败处理：

- 如果审查意见太泛：要求它引用具体文件、函数、行号或 diff 片段。
- 如果提出大范围重构：要求改成“最小修复方案”。
- 如果只说优点不说问题：重新指定“你是反方审查者”。

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

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

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

步骤：

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

示例输入：

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

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

验收标准：

- 是否满足“不引入新依赖”；
- 是否能回滚；
- 是否有状态机；
- 是否有失败重试或失败可见性；
- 是否能用测试验证。

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

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

步骤：

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

审查提示词：

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

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

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

只输出问题，不要夸奖。
```

配套输入：

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

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

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

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

建议分配：

- Claude Code：页面结构、交互状态、视觉层级、组件拆分；
- Codex：接口边界、错误处理、测试失败、状态一致性；
- 人类：产品目标、上线判断、权限边界。

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

Claude Code 提示词：

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

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

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

Codex 审查提示词：

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

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

验收标准：

```bash
npm run test
npm run lint
npm run build
```

预期结果：

- 页面能展示四类状态；
- 未知状态不会导致页面崩溃；
- 高风险 SQL 明显可见；
- mock 数据和未来接口结构保持一致。

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

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

### 低风险

可以让模型直接改：

- 文档；
- 单元测试补充；
- UI 样式微调；
- 本地脚手架代码。

### 中风险

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

- 业务逻辑；
- API 参数；
- 错误处理；
- 权限判断；
- 数据转换。

### 高风险

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

- 数据库迁移；
- 生产配置；
- CI/CD；
- 权限系统；
- 付费 API；
- 删除、覆盖、批量修改数据的脚本。

高风险任务推荐提示词：

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

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

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

### 生成者提示词

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

任务：{具体任务}

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

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

### 审查者提示词

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

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

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

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

### 人类仲裁清单

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

## 七、常见坑

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

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

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

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

### 坑 3：审查提示太温和

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

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

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

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

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

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

## 八、一周内的落地路线

### 第 1 天：建立规则

- 约定哪个模型负责生成，哪个模型负责审查；
- 约定允许修改的目录；
- 约定高风险任务只读审查。

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

推荐任务：

- 修一个小 UI；
- 补一个测试；
- 重写一段文档；
- 给一个函数加边界条件。

记录三件事：

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

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

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

### 第 6–7 天：沉淀模板

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

## 最终建议

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

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

## 来源与边界

- 来源文章：XDA Developers，《I use Claude Code and Codex together, and the combination does something neither can do alone》
- 原文 URL：https://www.xda-developers.com/use-claude-code-and-codex-together-combination-does-something-neither-can-do-alone/
- 本文基于原文摘要提炼，并加入了工程落地模板、提示词、验证命令和风险分层。
- 原文是个人经验分享，不是量化 benchmark；本文中的流程建议应先在低风险任务中试用，再逐步扩大。