把 Claude Code 跟 Codex CLI 並用三個禮拜當生產線跑：spec 在 Claude Code 這邊抓著，程式全部派給 Codex CLI 寫。
聽起來很乾淨，實際做下去縫隙到處都是。
第一個禮拜會以為是手生，第二個禮拜就會發現同一種坑反覆撞。Anthropic 的官方文件講 Claude Code，OpenAI 的官方文件講 Codex CLI，各自都很完整。兩個放在一起怎麼跑這件事，住在使用者的 terminal 紀錄裡，沒人寫過。
下面整理累積的筆記，把最關鍵的六件事說清楚。已經在用 Claude Code 開分身、想把 Codex CLI 加進來當執行手的人，可以省下一兩個下午。文章不放具體指令（兩家工具的指令參數會隨版本變動），只講概念。要照做的時候，配當下版本的官方文件對齊細節最穩。
為什麼這個分工值得做
先講結論：讓 Claude Code 當指揮、Codex CLI 當執行手，是兩個工具最舒服的用法。
Claude Code 的強項在規劃、審查、把住 spec 不偏掉、決定什麼叫「做完了」。它的反應風格適合這層工作，加上能開分身去看別的東西，很適合當決策層。
Codex CLI 的強項在執行：寫程式、refactor、長時間連續編輯、跑測試。它的沙盒設計也讓人能放心讓它自己跑。
把兩者疊起來：Claude Code 在上面拿著 spec，把工作切成一片一片派給 Codex CLI。Codex 寫完 → Claude 開分身做 cross-family review → 通過再 merge。這個迴路比讓任一工具自己包辦穩很多。
下面六件事，是這三週裡學最久的。
一、「自動模式」不等於「完全不問」
第一次叫 Codex 自動跑一個無人值守的任務，跑回來常常會看到完全沒動。
進 log 才看到，它停在「要修這個檔，要不要批准？」的詢問畫面那裡，沒人按，卡了二十分鐘。
很多自動化工具都有類似的設計：所謂的「自動模式」其實是「需要時還是會問你」，遇到敏感操作（修改檔案、寫入特定路徑）會跳出詢問。真正的無人值守要再加一層『不要問、直接做』的設定。
安全邊界靠沙盒守，不要靠詢問擋。詢問擋一卡就整個 session 卡住、半個下午沒動，比較不划算。
二、沙盒預設沒有網路
第二個坑：寫一份指令叫 Codex 去裝一個新套件，跑半天告訴你裝不起來。
真正的原因跟套件管理器無關，Codex 沙盒預設網路是關的。
理由很單純，安全。但日常開發很多任務都需要網路：裝套件、git push、打第三方 API。要開網要顯式打開，不是 default 給你用。
關沙盒整個跑（讓它擁有完整系統權限）也能繞過去，但那等於把護欄拔了。穩定的習慣是每個任務開頭先想一秒「這個任務要不要連網」，要連就開該開的旗標、不要就保留 default。多一秒思考比拔護欄安全得多。
三、判斷成功要看多個訊號，不是 stdout 最後一行
看 Codex 跑完只看 stdout 最後一行：「OK looks good」就 merge，吃過幾次悶虧之後，會學到要看多個訊號交叉。
至少包括：
- 退出代碼是 0（程式正常結束）
- 執行紀錄裡有「整輪完成」事件（不是中途斷掉）
- 預期該寫出去的檔案真的落地在磁碟上
任何一個沒到，都不算成功。Stdout 最後一行可能在輸出中間就被緩衝切掉了，看起來像「結束時的訊息」其實只是「最後一段被擠出來的字」。
具體要怎麼接這些訊號，每家工具的旗標都不一樣，照當下版本的官方文件查。重點在概念：訊號要交叉、不能單看一條。
四、單次任務有時間上限，超過就死掉
這條學最痛。
派一個大重構給 Codex，指令寫得很細，預估它要跑四十分鐘。回來 session 死了，log 寫著「壓縮任務超時」。
當對話累積到接近上限，Codex 會自動觸發內部壓縮機制：把已經處理過的部分壓成摘要，騰出空間給新的回合。問題是壓縮本身會吃時間，一旦超時、整個 session 就死了。連 resume 都救不回。下次接回來，會拿到一個卡死的 session。
可靠的鐵律：單次任務不要拖太久。實測 25 分鐘以內是甜蜜點，更長就拆段。每段跑完寫一份小總結（「做了 X、剩下 Y、下一步從 Z 開始」），下一段用這份總結當開頭、開新 session 接續，死掉的那個直接放掉。
切段的副作用是好的：每段時間短，token 消耗也比較好估、出錯也好定位。
五、Code review 一定要交給另一家
讓 Codex 寫完 code、再讓 Codex 自己審，會抓到一些東西，但漏掉的也多。
寫程式的模型跟審程式的模型同源，思考底子一模一樣，它對自己剛寫過的東西容忍度比審別人高很多。看起來在 review，實際上在橡皮圖章。
這就是為什麼這套架構長成「Claude Code 在上、Codex 在下」：Codex 寫完之後，diff 不交給 Codex 自己審，交給 Claude 開的分身 審。不同的模型家族、不同的錯誤模式、不同的盲點。Cross-family review 抓到的東西比 self-review 多得多。
穩定流程是：Codex 寫完 → Claude Code 拉出 diff → 開 Claude 分身 review → 有問題回 Codex 修、沒問題 merge。這層額外的 review 經常能抓到肉眼掃過去看不出來的 silent bug。
六、三個並行是甜蜜點，第四個會撞牆
最後一條跟付費方案的額度有關。
Codex 的付費方案有一個滾動式的額度視窗（rolling credit window），每段時間給你一定的計算量。並行跑多個 worktree（每個 worktree 開一個獨立的 Codex session），額度消耗是疊加的。
跑四個並行，理論上應該很快，實際上跑到一半額度撞牆，所有 session 同時降速、最後一個直接被擋下來。
三個是甜蜜點。三個並行在付費方案下大致能撐 30-50 分鐘的衝刺，再多就要等額度補回來。派任務之前先問自己：「這個任務真的需要四條並行嗎？」多半答案是不需要，三條 + 一條依序排隊就夠用。
把這套整理成自己的 playbook
這六件事整理進了一份自用的筆記庫：把每個踩過的坑寫成一條「什麼時候會遇到、為什麼會發生、概念上怎麼繞過去」，再配幾份模板（任務派發格式、跨家審查流程、長任務切段紀錄等）讓自己未來不必每次重新想。
兩種方式可以用它：
- 照抄概念：找一個正在卡的問題，跳到對應段落，照著做。
- 照抄結構：把整份筆記庫當成 starter kit，clone 一份放進自己的工作目錄，依自己的工具版本微調。
之後也會把這份內容陸續整理成更系統的指南，跟同樣在做兩家工具並用的人一起累積踩坑經驗。
結語
Anthropic 跟 OpenAI 不會幫使用者寫「兩家工具一起用」的教學，這層永遠是使用者自己摸出來的。摸出來的東西可以分享，不用每個人各自摔一次。
延伸閱讀
小企鵝的經驗
主力工作流是 Claude Code（在上）+ Codex CLI（在下）+ 開 Claude 分身做 cross-family review。實戰下來最有感的兩條：第一是 Codex 沙盒網路 default 是關的，每次想派需要連網的任務都要記得開；第二是長任務真的會被內部壓縮機制超時殺掉，乖乖切段反而是最快的路。OpenClaw 上的多 agent 架構就是依這條分工跑的。
常見問題
Q: Claude Code 跟 Codex CLI 為什麼要一起用？挑一個就好嗎？
可以挑一個，但分工的甜蜜點明顯。Claude Code 擅長規劃、審查、把需求 spec 抓在手上；Codex CLI 擅長寫程式、refactor、長時間連續編輯。一個在上層做決策、一個在下層執行，比讓一個工具同時做兩件事順很多。
Q: Codex 跑長任務真的會死掉嗎？
會。當對話累積太長，Codex 會自動觸發內部壓縮機制把舊內容收斂；這個壓縮本身會吃時間，一旦超時整個 session 會死，連 resume 都救不回。實務上單次任務切在 25 分鐘以內最穩。
Q: 為什麼還要再讓另一個 AI 審 code？
讓 Codex 自己審自己寫的 code，盲點會被它的 priors 蓋過去；換另一家模型（例如 Claude）來審，不同的訓練底子會抓到不同的問題，這層 cross-family review 抓到的 silent bug 比 self-review 多得多。
整理：Penna｜小企鵝 Penchan