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 已經掌握目前實作上下文。

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 的任務繼續」可靠得多。

如果你正在用 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"

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

1

git diff > handoff-login-validation.diff

不要在工作區很亂時接力。至少先分清哪些是使用者原有改動、Claude Code 改動、Codex 改動，以及哪些檔案不能被下一個 Agent 覆蓋。

用 Hooks 固定交接動作

如果你經常做接力，可以把「結束前輸出交接包」寫成 Claude Code hook 或專案規則。

對接力來說，最實用的不是自動替你切工具，而是提醒或生成必要狀態。

1
2
3
4
5

如果本輪有檔案改動，請輸出：
- 已改檔案；
- 已執行驗證；
- 未完成事項；
- 建議交接給 Codex 的下一步。

Codex 側也可以把接力流程寫成 skill。可以參考 Codex Skills 怎麼寫自己的工作流，把「只讀審查」「交接包解析」「長任務恢復」拆成固定步驟。

本地、IDE、雲端怎麼分工

不要把所有事情都塞在同一個視窗。

兩者配合時，重點不是誰替代誰，而是讓上下文和責任邊界更清楚。

一個完整接力示例

假設任務是：重構使用者匯入流程，並補測試。

第 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 或自動化。

接力檢查清單

如果這張表填不出來，就先不要接力。

參考資料

• 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 同時開工，變成可控的工程流程。