【2026 最新】Opus Codex 接力怎麼做？規劃、Worktree 執行與成本驗收教學

你已經訂閱 Claude 和 Codex：想讓 Opus 5.5 想清楚需求，再交給 Codex 寫程式。問題是，兩個 Agent 只要對「完成」的理解差一點，省下的思考時間就會變成重做與驗收成本。這篇 Opus Codex 接力 教學，帶你用一張任務卡、一份交接檔和同題對照，判斷接力到底值不值得。

本文寫給第一次把兩個程式 Agent 放進同一流程的讀者。你不需要會設計多 Agent 系統；只要能開終端機、找到專案測試指令，就能跟著做。文中的登入修復是示範任務，不是 AlphaLab 對兩個產品的效能測試。

先說結論：接力要交的是「可驗收的工作」，不是一段漂亮的計畫

Opus Codex 接力＝同一張任務卡＋可落地的交接檔＋隔離的執行環境＋共同驗收。把它想成設計師交施工圖給工班：圖紙要有尺寸、不能碰的承重牆、完成後怎麼量；「請做得更好」算不上圖紙。

• 規劃端：Opus 5.5 釐清需求、找風險、定義成功證據。
• 執行端：Codex 在自己的工作目錄讀取交接檔、修改程式、跑測試。
• 驗收端：人看 diff、測試結果與實際操作，再決定是否合併。

這是你設計的工作流程：把計畫貼到另一邊，是傳遞文字與專案狀態；兩邊的使用量仍須依各自登入方式與方案查看。

什麼時候值得做 Opus Codex 接力？

先看任務有沒有「規劃錯一步，後面要大改」的特性。跨多個檔案的登入流程、需要處理資料遷移的功能、規格模糊的重構，都適合先把邊界寫清楚。改一行文案、修一個確定的拼字錯誤，交接本身可能比工作更費時；直接交給一個 Agent 即可。

如果你想先理解兩個工具各自如何工作，可讀 Claude Code vs Codex。本文關心的是同一題怎麼分工、怎麼看證據，而非宣稱哪一個模型一定比較強。

動手前，先分清兩套用量帳本

截至 2026 年 9 月，Anthropic 的 Pro／Max 說明指出：以 Claude 訂閱登入的互動式 Claude Code，與 Claude 對話共用方案用量；若環境設定了 ANTHROPIC_API_KEY，Claude Code 可能改走 API 金鑰計費。開始前在 Claude Code 輸入 /status 與 /usage，核對模型、登入身分和剩餘用量。若想只規劃，官方文件提供 claude --model claude-opus-5-5 --permission-mode plan；Plan mode 會先提出方案，等你核准才進入編輯。模型選擇與Plan mode 操作可逐項核對。

Codex 端也要看登入方式。OpenAI 官方認證文件區分以 ChatGPT 登入的訂閱存取，與以 API 金鑰登入的按用量存取；Codex 用量說明建議在使用儀表板查看帳號容量，CLI 工作中可用 /status 查看。本文不把訂閱額度換算成固定 API 美元成本：模型、任務長度、工具呼叫與方案都會改變消耗。

實務上，先把「Claude 訂閱使用量」「Codex 訂閱使用量」「API 額外支出」分成三欄記錄。若某次任務走 API 金鑰，就只在相應帳本記實際帳單，不拿訂閱剩餘額度估價。想降低 Claude 長任務的無效消耗，可接著看 Claude 怎麼省 Token。

五個零件，把規劃變成 Codex 能執行的交接

① 任務卡：「要修哪個可觀察的問題？」

先用人類語言寫目標、範圍、不能碰的區域、成功條件。示範：登入後偶爾跳回登入頁；目標是已登入使用者刷新頁面後仍進入原目標頁。範圍只含驗證狀態與跳轉邏輯；不得改會員資料表或部署設定。驗收包含一個回歸測試與一次人工重現。這張卡要同時餵給規劃端與對照組，否則比較的是不同題目。

② 規劃：「先找可推翻自己方案的證據」

在專案裡啟動 Opus Plan mode，貼上任務卡，要求它先讀既有測試與相關檔案，再輸出：疑似根因、可能反例、要改的檔案、測試指令、停止條件，以及仍未知的事。你可以貼這句：「只規劃，不修改檔案。每個改動都對應一個驗收條件；標出需要我決定的產品行為。」Plan mode 是閱讀和提出方案的工作階段；交接前仍由你審查，將核准的內容存成 handoff.md。

③ 交接檔：「把假設、禁止事項和證據寫在紙上」

handoff.md 最少包含六格：目標、已確認事實與檔案路徑、待驗證假設、允許變更範圍、測試與人工驗收、停止並回報條件。事實要能指向檔案或測試；猜測要明寫「待驗證」。例如「重新整理後回到登入頁」是觀察；「一定是 cookie 過期」只是待查假設。

把交接檔當成給另一位工程師的工單，別把整段對話塞進去。長對話裡常混著已被推翻的想法；一份短而可核對的交接，讓 Codex 知道哪些結論可以用，哪些還要查。

④ 工作目錄：「讓修改有自己的桌面」

在乾淨的 Git 專案主目錄，可用 git worktree add -b experiment/opus-codex ../opus-codex-run HEAD 建立另一個工作目錄；進入該目錄後放入交接檔，再啟動 Codex。Git 官方文件說明 Worktree 讓同一倉庫同時有多個工作目錄。若使用 Codex App，也可選擇其 Worktree 工作模式；官方 Worktree 文件記錄了建立、檢查和交回本機的方式。

交辦 Codex 的話可以很短：「先讀 handoff.md 和專案規則。先核對『已確認事實』，再依允許範圍實作。每完成一個小步，跑對應測試。若驗收條件與現有程式衝突、需要改資料庫或對外服務，先停下說明。」Worktree 隔離的是檔案改動；若測試會碰共用資料庫、雲端資源或部署環境，那些資源也要另行隔離。這點可參考 Agent Worktree 與資料庫回滾。

⑤ 收據：「用 diff 與測試關閉這一輪」

請 Codex 交出三樣東西：git diff --stat 與完整 diff、實際執行的測試指令及結果、未完成或跳過的驗收。你自己再跑一次關鍵測試與人工操作。看到「測試通過」這句話還不夠；要核對測試確實覆蓋原本的失敗情境，並確認沒有越過任務卡的邊界。若任務在額度限制時中斷，停手收據教學也適用於整理未知副作用與下一步。

完整演練：登入跳轉錯誤怎麼從 Opus 交給 Codex？

假設測試目前重現了這個情況：使用者登入後，重新整理受保護頁面，偶爾回到登入頁。你先建立任務卡，寫明重現路徑、期望行為、禁止改動的資料庫與部署設定。Opus 的規劃若說「可能是驗證狀態在頁面載入前還沒恢復」，把它保留為假設；如果它找到既有測試 auth-redirect.test.ts，才把測試路徑列為已確認事實。

Codex 開工後，先用測試或程式碼確認假設，再修跳轉時機。完成時應交出：哪些檔案改了、原測試能否先失敗再通過、刷新頁面時是否仍留在目標頁、還有哪些情境沒驗。假如它為了方便把所有未登入狀態都改成直接跳首頁，即使測試綠了，也不符合「原目標頁」的完成條件；人要退回這一輪。

這個例子展示的是如何追蹤一輪交接，不是聲稱 Opus 或 Codex 已在 AlphaLab 的環境完成這個案例。你可以把它替換成自己專案中一個能在一小時內驗收的真任務。

同題對照：怎樣判斷雙訂閱接力有沒有省成本？

挑一個有明確測試與人工驗收的任務，從同一個基準提交開三個 Worktree。A 組只用 Codex，B 組只用 Claude Code，C 組由 Opus 規劃、Codex 執行。三組使用同一張任務卡、相同權限與相同停止條件；執行順序輪換，避免先做過的經驗只幫到最後一組。不同模型版本、不同登入方案或不同難度的任務，不要直接合併成單一「誰比較快」結論。

每組記錄五欄：從開始到驗收通過的人類時間、Agent 實際工作時間、提示與修補輪次、訂閱用量變化或 API 帳單、以及未通過驗收的缺陷。把「等模型回覆」和「人要看 diff／修正要求」分開；接力若讓人多讀兩遍計畫、再補兩輪誤解，可能比單 Agent 更慢。只有完成同一驗收門檻的組別，才適合比較成本。

建議先把結果寫成三行紀錄，而非急著算排行榜：A、B、C 各自是否完成、人花多久驗收、哪個交接欄位造成重工。如果 C 組較好，也先問是 Opus 規劃的幫助，還是「寫清楚任務卡」本身帶來的改善。想再往系統化驗收走，可讀 動手做 Agent Harness，把停止條件與工具回饋放進流程。

三個常見失敗點：交接不是複製貼上就好

1. 計畫把猜測寫成事實：請規劃端給出檔案與測試證據；Codex 開工先反查。找不到證據就停在假設層，不按假設直接改程式。
2. 兩邊共用副作用：Worktree 只分開 Git 工作目錄。資料庫、測試帳號、遠端 API、部署目標要在任務卡列明；有寫入權限的外部系統尤其要先確認範圍。
3. 比較只看模型回答：請人根據同一驗收清單看功能、diff 與回歸測試。規劃寫得好看但交不出可合併的修改，也算這輪未完成。

已經用 Claude 與 Codex 互相挑錯的人，可以延伸看 雙工具對抗式審查；若你的難點是換會話保存脈絡，則看 Claude Code 跨會話交接。那兩篇處理互審與會話脈絡，本文的任務卡則專門約束「規劃交給另一家工具執行」。

FAQ：Opus Codex 接力常見的八個問題

Q1：一定要訂兩個付費方案嗎？

不一定。先看你實際能使用的 Claude 與 Codex 入口、方案與剩餘用量；這套交接方法也能用在單一工具的兩個階段。若只是學方法，先拿一個小任務試做，比先加訂閱更能看出價值。

Q2：Claude 訂閱額度能轉給 Codex 嗎？

兩邊依各自帳號與登入方式計量。交接檔只傳遞任務資訊，不是額度轉換。先用兩邊的用量畫面核對當次工作走訂閱還是 API。

Q3：Opus 一定要開 Plan mode 嗎？

Plan mode 很適合先看方案再准許編輯。若你使用聊天介面，也可要求「只讀專案與輸出計畫」，但仍須由人整理並審核交接檔。交接品質由內容與證據決定，介面名稱只是操作入口。

Q4：Codex 可以直接讀取 Claude 對話嗎？

在本文流程裡，Codex 讀的是你提供的任務卡、交接檔與專案檔案。把你批准的結論明寫在檔案中，才能逐項核對；不要假設另一個工具已理解前面的對話。

Q5：Worktree 裡放交接檔，會污染正式分支嗎？

先用 git status --short 檢查交接檔是否被追蹤，再由你決定要把它當版本化規格或任務暫存檔。合併前看完整 diff；Worktree 是隔離工作目錄，不替你決定哪些檔案該提交。

Q6：兩個 Agent 意見相反，信誰？

回到任務卡與可觀察證據。先讓雙方指出對應檔案、測試或產品規格，再做一個能區分兩種說法的小測試。沒有證據時，把分歧標成未知並交給人決策。

Q7：怎樣知道接力真的省額度？

看同一任務、同一驗收門檻下的帳號用量變化，並把人類的規劃、交接、審查時間一起記錄。訂閱容量可用前後畫面比較；若當次走 API，則看帳單或工作階段費用。只看某一輪提示字數會漏掉重做。

Q8：先用哪一題練習？

選一個你已能重現、已有測試入口、範圍不超過幾個檔案的問題。登入跳轉、表單驗證或一個小型資料轉換都可；先把完成條件寫清楚，再決定要不要分成規劃與執行兩段。

給新手的三個重點

• 先把成功條件寫在同一張任務卡，再決定是否請 Opus 規劃。
• 交接檔分開已證實事實、待查假設與禁止改動的邊界。
• 最後用測試、完整 diff、人工操作與實際用量決定接力是否划算。