讓 Claude Code 和 Codex 互相 Review：有效，但不是雙重保證
本篇是「Codex 和 Claude Code 雙修」系列的第 6 / 7 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
同時使用 Claude Code 和 Codex，最實用的分工之一是：一個負責實作，另一個只看最後的 diff。
這個方法確實常能多抓一層問題，但原因不是「兩個 AI 投票就會變真理」。它只是把 author 與 reviewer 的上下文分開，強迫第二個工具重新建立假設。兩邊仍可能一起漏掉同一個需求，也可能對錯誤答案同樣有信心。
所以交叉 review 的定位應該是額外訊號，不是測試、靜態分析或人工 review 的替代品。
這是「Codex 和 Claude Code 雙修」系列第 6 篇，也是收尾。上一篇是兩邊共用 MCP 的設定與權限邊界。
先把 author 和 reviewer 的責任切開
一個可用的流程至少有四個角色責任：
| 階段 | 責任 |
|---|---|
| Author | 理解需求、修改程式、跑最相關的測試 |
| Automated checks | 型別、lint、測試、build、security scanner |
| Reviewer | 只根據需求、diff 與 repo 規則找具體缺陷 |
| Human owner | 判斷 findings、處理取捨、決定是否合併 |
如果沒有測試結果和需求，reviewer 只能猜「看起來像不像 bug」。如果沒有 human owner，兩個 agent 可能在風格偏好上來回改，最後 diff 變大，品質卻沒有提高。
Review 前先準備一份 contract
不要只丟一句「幫我 review」。至少提供：
- 這次變更要解決什麼；
- 哪些檔案或行為不在範圍內；
- repo 的
AGENTS.md／CLAUDE.md； - 已跑過哪些檢查、結果如何；
- reviewer 可以讀什麼、能不能執行指令；
- finding 要用什麼格式回報。
我常用這個 prompt 骨架：
Review the current uncommitted changes against the stated requirement and
repository instructions.
Prioritize correctness, regressions, security, data loss, and missing tests.
Do not report style preferences unless they cause a concrete defect.
For each finding, return:
- severity
- file and line
- evidence or failure scenario
- the smallest reasonable fix
If you find no actionable defect, say so explicitly and list remaining
verification gaps.「remaining verification gaps」很重要。沒有 finding 不等於已證明正確，reviewer 應該說明它沒辦法驗證什麼。
工作流 A：Claude Code 寫，Codex 審
如果 Claude Code 已完成修改，可以直接使用 Codex 的 review 入口：
codex review --uncommitted "Focus on correctness, regressions, and missing tests."codex review 也能針對 base branch 或特定 commit。實際參數以 codex review --help 和 Codex developer commands為準。
若你希望在程序層明確限制為唯讀，可以改用：
codex exec \
-s read-only \
-a never \
"Review the current uncommitted diff. Report actionable findings only."這個組合表示不等待互動批准，而且沙箱只允許讀取。它仍可能因測試需要寫 cache 或暫存檔而無法執行完整 test suite，所以 author 應先提供測試結果；reviewer 再指出缺少的驗證，不要為了跑測試臨時擴權。
工作流 B：Codex 寫，Claude Code 審
反過來可以讓 Claude Code 在 plan mode 中檢查 diff：
claude -p \
--permission-mode plan \
"Review the current uncommitted diff. Report actionable findings only."Plan mode 適合唯讀探索，但它是 Claude Code 的 permission mode，不應被描述成一個與 Codex read-only 完全相同的 OS 沙箱。若 repo 風險較高，還要搭配 Claude Code sandbox、allow/deny rules，或直接放進隔離容器。
Claude Code 的模式與規則會隨 client 更新，執行前可查 permission modes。
第一輪只收 findings，不要立刻自動修
Reviewer 回報後，先把每一項分成：
- 接受：有可重現情境或明確違反需求；
- 需要驗證：看似合理，但證據不足；
- 拒絕：誤讀需求、忽略 repo 限制或只是風格偏好。
再由 author 處理被接受的 finding，補測試並重新執行 checks。Reviewer 不應直接拿到寫入權限，否則 author／reviewer 的邊界又混在一起。
第二輪只檢查：
- 原 finding 是否真的修好；
- 修正是否帶來新 regression；
- 新增測試是否能在舊實作上失敗、在新實作上通過。
通常兩輪已足夠。若兩個 agent 對同一點反覆爭論，就交給 human owner，不要讓它們無限互審。
Plan review 比 code review 更便宜
交叉 review 不一定要等程式寫完。高風險變更在動手前，可以先讓另一個工具檢查計畫：
- migration 是否可回滾；
- API 相容性是否被忽略；
- 權限與資料邊界是否清楚；
- 驗收測試是否真的對應需求；
- 是否有更小的修改路徑。
計畫階段發現問題，通常比完成大型 diff 後重做便宜。這時 reviewer 應檢查假設和風險，不要搶著重寫整份 plan。
自動化可以做，但要有停止條件
這套流程可以包成 Skill 或 CI job，例如：
1. Verify the working tree scope.
2. Run deterministic checks.
3. Ask the second agent for findings in a fixed schema.
4. Fail only on findings that meet the agreed severity policy.
5. Save the raw review output as an artifact.
6. Stop after one review pass and request human triage.不要讓 CI 自動接受 reviewer 的所有修正，也不要在 Stop hook 裡無限啟動另一個 agent。至少要有：
- 最大輪數；
- timeout；
- 成本上限；
- 允許讀取的檔案範圍；
- 固定輸出 schema；
- 人工升級條件。
對高風險專案，還要保存 prompt、CLI 版本、git SHA 和測試結果，否則同一個 finding 之後很難重現。
哪些 finding 最值得交給第二個工具
我會優先要求 reviewer 檢查可被證明的問題：
- null、邊界值與錯誤處理；
- stale state、race condition、transaction 邊界；
- 權限繞過、secret 洩漏、輸入驗證；
- schema 或 API 相容性；
- 漏掉的測試與失敗路徑；
- diff 是否超出需求範圍。
至於命名偏好、抽象層次和「我會用另一種寫法」，除非會造成維護或正確性問題，否則不該阻擋交付。
雙修的最後一張決策表
| 任務 | 建議做法 |
|---|---|
| 小改動、有完整測試 | 一個 agent 實作，跑 checks；視風險決定是否需要第二 reviewer |
| 跨模組或高風險變更 | 先做 plan review，再實作、跑 checks、交叉 review |
| 牽涉 production 或資料 | 使用隔離環境、最小 credentials、人工批准；AI review 只當輔助 |
| 純風格重構 | 先用 formatter／lint；不要為了得到兩票而開兩個 agent |
| Reviewer 意見衝突 | 回到需求、測試與可重現證據，由 human owner 決定 |
整個系列最後想留下的不是「Claude Code 加 Codex 一定比較強」，而是一套清楚的分工方式：共用 repo 規則與流程，分開管理 runtime 權限，再讓第二個工具在需要時提供不同觀察角度。
工具會改版，模型會換名字，但這些邊界不太會過期。
