Codex 和 Claude Code 任务接力教程：从实现、审查到长任务恢复

Codex 和 Claude Code 任务接力，最容易做错的地方，是把它理解成“两个 AI 一起写代码”。真正稳定的做法恰好相反：同一阶段只让一个工具负责写，另一个工具负责审查、复盘、补上下文或接下一段。

如果让 Claude Code 和 Codex 同时改同一批文件，短期看起来很快，后面很容易出现冲突：谁改了什么说不清，测试失败不知道是谁引入，两个 Agent 还可能互相覆盖对方的设计。任务接力的目标不是并发写代码，而是把一个复杂任务拆成阶段，让每个工具在更合适的位置发挥作用。

快速结论

建议先用这套分工：

核心规则只有三条：

1. 同一时间只允许一个 Agent 写代码。
2. 每次接力前都生成“交接包”。
3. 接手方先复盘，不要立刻改文件。

什么时候需要任务接力

不是每个任务都要两个工具一起参与。下面几类场景更适合接力：

• Claude Code 已经完成实现，需要 Codex 做独立审查；
• Codex 做了方案或审查，需要 Claude Code 按 findings 修复；
• 长任务跑到一半中断，需要另一个 Agent 根据 checkpoint 接上；
• 本地环境和云端环境分工，例如本地复现问题，云端跑长时间探索；
• 一个工具更熟悉当前会话，另一个工具更适合做 PR 前审查；
• 你想避免单个 Agent 自说自话，需要第二视角挑战设计。

如果只是改一行配置、修一个拼写、补一个小测试，就没有必要接力。接力本身也有成本：你需要写清楚状态、边界和下一步。

不要让两个 Agent 同时写同一批文件

这是最重要的安全规则。

不推荐：

1
2

Claude Code 继续实现登录重构。
Codex 同时帮我优化同一批登录文件。

推荐：

1
2
3

Claude Code 负责实现登录重构。完成后停下，输出交接包。
Codex 只读审查这次 diff，不修改文件。
Claude Code 根据 Codex findings 修复。

这样责任边界更清楚。出了问题，你能知道是哪一阶段引入的。

交接包应该包含什么

每次从 Claude Code 交给 Codex，或者从 Codex 交给 Claude Code，都应该有一个短交接包。

模板如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

## Agent Handoff

### 原始目标
-

### 当前阶段
- 计划 / 实现 / 测试 / 审查 / 修复 / 发布前检查

### 已完成
-

### 未完成
-

### 已改文件
-

### 已运行验证
-

### 当前风险
-

### 不要重复执行
-

### 下一步建议
-

交接包不是写给人看的漂亮总结，而是给下一个 Agent 恢复现场用的。它必须包含文件、验证和边界。

这部分可以和上一篇 AI Agent 长任务中断后怎么恢复 搭配使用。任务接力本质上就是一种主动恢复。

Claude Code 到 Codex：实现后独立审查

这是最常见、也最稳的接力方式。

流程：

1. Claude Code 完成功能实现。
2. Claude Code 运行最小相关测试。
3. Claude Code 输出交接包。
4. Codex 读取 diff，做只读审查。
5. Claude Code 根据 findings 修复。
6. Codex 复审。

给 Claude Code 的提示词：

1
2
3

请完成这个功能，但完成后不要提交。
结束前输出交接包，包含已改文件、已运行测试、未完成事项和当前风险。
不要让另一个 Agent 接手前继续扩大范围。

给 Codex 的提示词：

1
2
3

请只读审查当前未提交改动，不要修改文件。
重点找 bug、回归风险、安全问题、边界条件和缺失测试。
请按严重程度列出 findings，并引用具体文件位置。

Codex CLI 官方文档里也把 review 作为独立能力：可以审查未提交改动、某个 commit 或相对 base branch 的 diff，并输出优先级化 findings。这个阶段最好保持只读。

Codex 到 Claude Code：审查后修复

Codex 输出 findings 后，不要直接让 Codex 自己修。更稳的是交给 Claude Code 按 findings 小步处理，尤其当 Claude Code 已经掌握了当前实现上下文。

给 Claude Code 的提示词：

1
2
3
4
5
6
7

下面是 Codex review findings。请逐条处理。

约束：
1. 只修复 findings 指向的问题；
2. 不做额外重构；
3. 每修复一类问题后运行最小相关测试；
4. 修复完成后输出“已处理 / 未处理 / 需要人工判断”的列表。

这样可以避免“审查意见一来，Agent 顺手把整个模块重写了”。

Codex 到 Claude Code：方案接力

有些时候，Codex 更适合先做代码库梳理、方案拆解或风险评估，然后把实现交给 Claude Code。

适合场景：

• 代码库不熟，需要先读架构；
• 改动范围大，需要拆 milestone；
• 你想让 Codex 先做计划，不动文件；
• Claude Code 更适合在当前 IDE/终端里执行具体修改。

给 Codex 的提示词：

1
2
3
4
5
6
7
8

请只做计划，不修改文件。
阅读相关代码后输出：
1. 目标理解；
2. 影响范围；
3. 建议修改文件；
4. 分阶段实现计划；
5. 每阶段验证方式；
6. 风险和回滚策略。

然后把结果交给 Claude Code：

1
2
3

请按这份计划只执行第 1 阶段。
不要提前做第 2 阶段。
完成后运行计划中对应的验证，并输出交接包。

接力时，越要防止“一口气做完”。一次只交接一个阶段。

Claude Code 到 Codex：长任务转移

如果 Claude Code 会话里已经积累了大量上下文，但任务变长、需要更独立的审查或需要转到 Codex 继续，可以做一次手动转移。

手动转移的关键不是复制全部聊天记录，而是提炼状态。

给 Claude Code：

1
2
3
4
5
6

请把当前任务整理成可交给 Codex 的交接包。
要求：
1. 不超过 800 字；
2. 包含目标、已完成、未完成、已改文件、验证结果、风险；
3. 列出 Codex 接手后第一步应该做什么；
4. 标出不要重复执行的命令。

然后给 Codex：

1
2
3

下面是 Claude Code 交接包。请先复盘，不要修改文件。
先检查当前 git 状态和 diff，确认交接包是否和工作区一致。
然后只执行“第一步应该做什么”。

这种方式比直接说“接着 Claude Code 的任务继续”可靠得多。

如果你正在用 OpenAI 的 codex-plugin-cc 这类桥接工具，也可以参考站内文章 codex-plugin-cc：把 Codex 接进 Claude Code 工作流。但即使没有插件，手动交接包也足够支撑大多数任务。

使用 resume 时要注意什么

Codex CLI 有 codex resume，用于回到保存过的会话。Claude Code 也有 --resume、--continue 或会话内恢复入口。官方文档里都把 resume 放在“恢复已有会话”的语境下。

但 resume 不是万能保险。恢复前仍然建议问三件事：

1. 这个会话是不是当前仓库的？
2. 工作区状态和会话记忆是否一致？
3. 上次中断时是否已经执行过有副作用命令？

恢复后的第一条提示词可以写：

1
2
3

我们正在恢复一个旧会话。先不要改文件。
请检查当前工作区状态，并对比你记得的任务状态。
如果二者不一致，以当前工作区为准，先输出恢复摘要。

这样可以避免旧会话把过时计划套到新文件状态上。

用 Git 做接力边界

Git 是最好的交接线。

推荐做法：

1
2
3

git status --short
git diff --stat
git diff

如果一个阶段已经完成，可以考虑做一个小 commit：

1
2

git add <files>
git commit -m "feat: implement login validation"

然后让另一个 Agent 审查这个 commit 或相对 base branch 的 diff。

如果不想提交，也可以保存 patch：

1

git diff > handoff-login-validation.diff

不要在工作区很乱时接力。至少先分清：

• 哪些改动是用户原有的；
• 哪些改动是 Claude Code 做的；
• 哪些改动是 Codex 做的；
• 哪些文件不能被下一个 Agent 覆盖。

用 Hooks 固定交接动作

如果你经常做接力，可以把“结束前输出交接包”写成 Claude Code hook 或项目规则。

Claude Code 官方 hooks 文档说明，hooks 可以在生命周期特定节点自动运行命令，用于格式化、通知、验证和规则执行。对接力来说，最实用的不是自动替你切工具，而是提醒或生成必要状态。

例如在任务结束前提示：

1
2
3
4
5

如果本轮有文件改动，请输出：
- 已改文件；
- 已运行验证；
- 未完成事项；
- 建议交接给 Codex 的下一步。

Codex 侧也可以把接力流程写成 skill。可以参考 Codex Skills 怎么写自己的工作流，把“只读审查”“交接包解析”“长任务恢复”拆成固定步骤。

本地、IDE、云端怎么分工

Codex 和 Claude Code 都有不同使用入口。不要把所有事情都塞在同一个窗口。

一个实用分工是：

OpenAI 文档里也把 Codex IDE、CLI、cloud 分成不同工作流：IDE 适合围绕当前打开文件快速迭代，CLI 适合终端工作流和 review，cloud 适合把更长任务委托出去后回来审查结果。

Claude Code 则更适合在一个连续会话里读文件、改文件、跑命令、结合 hooks 和 MCP 推进本地任务。两者配合时，重点不是谁替代谁，而是让上下文和责任边界更清楚。

一个完整接力示例

假设任务是：重构用户导入流程，并补测试。

第 1 步：Claude Code 做实现

1
2
3

请重构用户导入流程，只处理 CSV 解析和字段校验。
不要改 UI，不要改数据库 schema。
完成后运行相关单测，并输出交接包。

第 2 步：Codex 做只读审查

1
2
3
4
5
6

请审查当前未提交改动，不要修改文件。
重点看：
1. CSV 边界条件；
2. 错误处理；
3. 类型和空值；
4. 测试是否覆盖失败路径。

第 3 步：Claude Code 修复 findings

1
2
3

请只修复 Codex findings 中的 P1/P2 问题。
不要做额外重构。
每个问题修复后运行对应测试。

第 4 步：Codex 复审

1
2

请复审当前 diff，确认上次 findings 是否已解决。
如果没有新的高置信问题，请明确说明剩余风险。

第 5 步：人工决定提交

AI 可以辅助，但最终是否提交、合并、发布，还是人来决定。

常见错误

两个 Agent 互相改对方的代码

这是最常见的混乱来源。接力时要有单写者原则：一个写，一个审。

交接包太长

交接包不是聊天记录。它应该短、结构化、可执行。太长反而会让接手方忽略重点。

没有验证信息

只说“功能完成了”不够。要写清楚跑了什么测试、哪些没跑、失败在哪里。

让审查 Agent 顺手修复

审查和修复最好分开。审查阶段保持只读，修复阶段再由实现方处理。

忽略上下文过期

resume 旧会话时，旧上下文可能和当前工作区不一致。恢复后先对齐状态。

把接力当作全自动流水线

第一版不要追求完全自动。先把交接包、只读审查、按 findings 修复这三步跑稳，再考虑 hooks、skills 或自动化。

接力检查清单

每次从一个 Agent 交给另一个 Agent 前，过一遍：

如果这张表填不出来，就先不要接力。

参考资料

• OpenAI Developers：Codex CLI features：https://developers.openai.com/codex/cli/features
• OpenAI Developers：Codex workflows：https://developers.openai.com/codex/workflows
• OpenAI Developers：Codex IDE extension features：https://developers.openai.com/codex/ide/features
• Anthropic Docs：Claude Code common workflows：https://docs.anthropic.com/en/docs/claude-code/common-workflows
• Anthropic Docs：Claude Code hooks guide：https://docs.anthropic.com/en/docs/claude-code/hooks-guide

总结

Codex 和 Claude Code 任务接力的关键，不是让两个 Agent 同时干活，而是让它们分阶段协作。

Claude Code 可以负责实现、修复和本地连续推进；Codex 可以负责独立审查、方案复盘、PR 前检查和长任务接续。每次交接都用结构化交接包，把目标、已改文件、验证结果、风险和下一步写清楚。再用 Git、resume、review、hooks、skills 和 checkpoint 做边界。

把“一个写、一个审、交接前先复盘”这三件事固定下来，任务接力就会从混乱的双 AI 同时开工，变成一个可控的工程流程。