Claude Code 與 Codex 一起使用：3 種工作模式

代理與氛圍式寫程式的實用資料：Ailoot 文件。

為什麼 2026 年只用一種工具已經不夠？#

2026 年 5 月，OpenAI 以 Codex CLI 中的 GPT-5.5 模型進入 Anthropic 的領域。近期基準測試顯示，Codex 在終端機任務和 SWE-bench Verified 模式上明顯領先。Anthropic 則以 Opus 4.8 和 Dynamic Workflows 回應，並維持在 SWE-bench Pro 上的領先地位（這項測試旨在防止資料外洩；使用基準測試資料訓練模型並無助益）。詳細的正面比較請見Codex 與 Claude Code 指南——這裡就直接來談兩者如何搭配。

到了 2026 年，沒有單一的贏家。最常見的模式是：團隊保留 Codex 來處理成本低廉的自主工作，並使用 Claude Code 做高風險的架構決策。

決定如何分配工作的關鍵差異：

• Claude Code 是研究者。 它能維持長時間、深入的對話，質疑假設，並在選定解法前考量幾種做法。適合一開始就無法明確判斷正確做法的情況。
• Codex 是執行者。 它接下任務，並在沙箱中一路推進到完成。適合目標明確、需要快速「交辦—取得成果」循環的任務。

如果兩種工具都在手邊，就不必在「思考」和「執行」之間二選一。你可以依任務類型分派工作。如果還沒決定要先安裝哪一種，可以參考Codex 與 Claude Code 指南中的正面比較。

模式 1：Claude Code 撰寫程式碼，Codex 負責審查#

在這種模式中，Claude Code 仍是主要編輯者。Codex 只會透過雲端模式在 PR 階段加入審查（Codex 直接從 ChatGPT 或 GitHub App 執行，因此不需要第二個終端機）。

實際做法如下：

1. 步驟 1：在 Claude Code 中撰寫功能

   在 VS Code 中開啟儲存庫，啟動 Claude Code，切換到 Plan Mode，並討論功能架構。你會得到程式碼草稿、測試和遷移檔。將變更提交到功能分支。

2. 步驟 2：在 GitHub 建立 PR

   從功能分支向 main 開啟拉取請求。在說明中輸入 @codex review this PR for edge cases, security issues, and test coverage gaps。

3. 步驟 3：Codex 非同步審查

   在雲端模式中，Codex 會將儲存庫複製到沙箱，讀取差異內容、執行測試和程式碼檢查工具，並尋找漏洞。5-15 分鐘後，它會直接在 PR 上留下評論。

4. 步驟 4：在 Claude Code 中修改

   回到 Claude Code，並將 Codex 的評論當作背景資訊交給它：「這是審查發現的問題；請修正第 1、3、5 項。」Claude 會進行修改並推送到儲存庫。

這種模式有效，是因為 Claude 和 Codex 使用不同資料集訓練，思考方式也不同。Codex 能看出 Claude 因模型盲點而忽略的問題，反之亦然。

模式 1 的風險：

• Codex 可能在漏看架構問題的情況下核准並關閉 PR。請自行檢查重要決策。
• Token 成本加倍：Claude 和 Codex 會分析相同的程式碼。對複雜功能來說值得，但用在小型功能上很昂貴。
• 雲端模式中的 Codex 看不到你的本機環境，例如環境變數或本機資料庫。如果功能會接觸這些項目，請改用手動執行。

模式 2：Codex 起草，Claude Code 整理架構#

2026 年一個案例中的專案採用了這種模式，當時必須在一個晚上完成具備電子郵件通知的註冊流程原型。在這種情況下，你可以花一小時和 Claude Code 討論架構；而 Codex 在 12 分鐘內就產出可運作的草稿。

運作流程：

流程是這樣：前 15 分鐘由 Codex 負責繁重的基礎工作，接著由 Claude 將成果提升到正式環境的品質。

要求 Codex 一開始就做到精緻完善，它會卡在模糊之處。要求 Claude Code 一開始就追求速度，它就會開始反覆斟酌。把各自擅長的工作交給它們。

模式 2 的風險：

• Codex 產出的草稿可能包含假設，之後很難整理。如果草稿方向錯了，丟掉重來比修正更省力。
• Claude Code 可能花半小時重新命名變數，卻忘了真正的架構問題。請指定具體修改，不要只說「整理一下」。
• 工作階段之間會遺失背景脈絡。若要讓 Claude Code 理解 Codex 的原意，需要 AGENTS.md（見模式 5）或檔案開頭的詳細評論。

模式 3：Codex 負責基礎設施，Claude Code 負責商業邏輯#

概念很簡單：程式碼庫的不同部分，適合不同的工作方式。

這種模式補充了平行執行多個 Claude Code 執行個體的做法——後者透過 git worktrees 讓相同模型處理不同任務；這裡則由兩個不同的代理分工負責不同領域。

基礎設施層（Codex）：

• GitHub Actions：新增工作、調整快取、加快 CI。
• 測試：重構後撰寫一套整合測試。
• Prisma 遷移：產生遷移並確認可以回復。
• Docker / Coolify 設定：新增環境變數、更新健康檢查。
• Cron 工作：撰寫一組 cron 處理常式。

Codex 在這裡表現出色，因為基礎設施任務通常涉及大量帶有樣板程式碼的小檔案。Codex 不會因為「需要仔細想一想」而停滯不前，而是會一路推進到結束。

商業邏輯（Claude Code）：

• 註冊流程：在每個步驟向使用者顯示什麼內容。
• 考量折扣、分期付款和贈品促銷碼的價格計算。
• 自動通知工作流程：使用哪些觸發條件和條件。
• 外部 API 整合：錯誤處理、重試、快取。
• 財務模型：單位經濟效益計算和收入預測。

Claude Code 在這些任務上表現出色，因為它們需要結合產品思維的深入對話。如果不討論各種情境，最後得到的技術解法可能無法回應使用者真正的痛點。

在儲存庫中的工作分配：

project/
├── .github/workflows/      ← Codex (CI, tests)
├── infra/                  ← Codex (Docker, Coolify, migrations)
├── scripts/                ← Codex (task scripts)
├── tests/                  ← Codex (integration tests)
├── src/
│   ├── lib/                ← Claude Code (business logic)
│   ├── app/                ← Claude Code (routes, forms, pages)
│   └── components/         ← Claude Code (UI)
└── prisma/
    └── schema.prisma       ← Claude Code (data models—product decision)

這不是硬性規定。工作有時會重疊，例如某個 GitHub Action 若具有產品意義（例如發布後傳送通知），Claude Code 也可以編輯它。不過，80% 的任務都適合這樣分工。

如何同步 CLAUDE.md 和 AGENTS.md？#

在並行使用 Claude Code 和 Codex 的經驗中，出現了一個意料之外的問題。Claude Code 遵循 CLAUDE.md 中的規則（「未經確認，不要碰遷移檔」）。Codex 看不到這些規則，便毫不遲疑地在工作環境中執行遷移。資料庫壞了三次之後，才開始設法讓兩個檔案保持正確同步。

兩個檔案都可包含專案上下文、對話偏好、測試命令、排除目錄與提交規範。重用兩者適用的規則，再分開各工具特定命令與設定；若禁止修改遷移檔適用兩代理，就應在兩份指示都保留。

兩個檔案共通的內容：

• 技術堆疊：使用哪些框架、資料庫和 ORM。
• 專案描述：專案用途、目標對象和主要實體。
• 禁止事項：哪些資料夾不能碰，以及哪些命令不能執行。

兩者不同的內容：

• Claude Code 特定 hooks、設定層及 MCP 設定應放在對應設定檔。CLAUDE.md 可描述或引用慣例，但複製文字不會自動變成可攜設定。
• AGENTS.md 是開放標準。Codex、Cursor、Aider、Continue、Cline 和 Factory Droid 等 25+ 種代理都會讀取它。另一篇指南會更詳細地介紹 AGENTS.md 格式。Codex MCP 設定儲存在 ~/.codex/config.toml（TOML 格式，不像 Claude 使用 JSON）。

2026 年常見的模式是在 monorepo 的 /context/ 資料夾中建立規則的正規來源，再由同步指令碼產生 CLAUDE.md、.cursor/rules/*.mdc 和 AGENTS.md。工具專屬的檔案標示為唯讀；只編輯來源檔。

透過 pre-commit hook 或 GitHub Action 執行同步指令碼。如果直接修改 CLAUDE.md，CI 就會失敗。這能防止不同工具的規則逐漸偏離。

另一種選擇是官方的 Claude Code 專用 Codex Plugin（於 2026 年 3 月 30 日公布，版本 1.0.4）。它會在 Claude Code 中加入 /codex:review、/codex:adversarial-review 和 /codex:rescue 命令。Codex 會以子代理的身分執行，使用自己的 ~/.codex/config.toml 和 AGENTS.md。這樣就不需要第二個終端機，但仍需要 AGENTS.md。

同時使用兩者要花多少錢？節省又從何而來？#

以下是 2026 年 6 月的價格（Anthropic 和 OpenAI 官方訂閱頁面的資料，以及 Codex 官方頁面）：

最低限度的實用組合： Claude Pro（$20）+ ChatGPT Plus（$20）= 每月 $40。對每天進行幾次工作階段的個人專案來說已經足夠。

適合積極使用氛圍式寫程式者的實用組合： Claude Max 5x（$100）+ ChatGPT Plus（$20）= 每月 $120。在分享的經驗中，最近 2 個月都使用了這個組合，期間有三個專案上線，而且 Claude 的使用額度從未用盡。

適合團隊的組合： Claude Max 20x（$200）+ Codex Pro（$200）= 每月 $400。如果 PR 審查和雲端任務持續執行，並與本機工作平行進行，這樣的組合就很合理。

節省來自以下幾點：

• 每個功能花的時間更少。 作者的測量結果：在 5 月至 6 月完成的 12 項功能中，從「想到一個點子」到「正式上線」的時間，從只用 Claude Code 的 4 小時縮短到搭配使用時的 2.5 小時。這是以作者的任務測得的結果；你的使用情況會得到不同數字。
• 缺陷更少。 根據文中分享的觀察，Codex 的 PR 審查能抓出 Claude 漏掉的 10 個問題中的 2-3 個。每個正式環境中的問題都要花一兩個小時修復，還可能造成停機。
• 平行作業。 Codex 在雲端模式處理功能 A 的同時，使用者可以用 Claude 處理功能 B。產能因此加倍。

如果你每週只寫 1-2 個功能，這樣不划算。這種情況下，只用一個 Claude Code Pro 就足夠了。

什麼時候不需要第二種工具？#

這種搭配並不適合所有人。很多時候，它只會增加雜訊。以下是四種不需要第二種工具的情況：

1. 剛起步的個人專案。 如果你只有一個點子，還在測試階段，只用 Claude Code + Plan Mode 就足以應付一個月。遇到速度瓶頸時再加入另一種工具。

2. 預算嚴格受限。 如果每月上限是 $20，就選 Claude Pro，不必多想。Claude 單獨就能處理氛圍式寫程式者 80% 的任務。

3. 架構簡單。 有表單的網站、只有幾種情境的機器人、API 包裝指令碼——在這些情況下依層分工沒有幫助。一個 Claude Code 就能處理。

4. 目前一切運作正常。 如果你一直在使用 Claude Code，過去一個月沒有任何任務讓它卡住或失敗，就不要改動已經有效的做法。等到需求變得明確時再加入 Codex。

反過來說，以下是該引進第二種工具的明確跡象：

• Claude Code 已成為瓶頸：你在等它完成，而不是繼續工作。
• 出現大量樣板基礎設施工作（遷移、CI、測試），而你不想再用 Claude 處理這些工作。
• 團隊中的不同成員已經在使用不同工具，因此需要共通的語言。
• 基準測試顯示 Codex 能更快處理你的任務類型（例如終端機操作）。

如何在一個晚上設定好這組工具#

第一個晚上可以照著以下具體計畫進行：

1. 步驟 1：安裝 Codex CLI

   在終端機中執行：npm install -g @openai/codex。使用 codex login 登入——瀏覽器會開啟，你可以使用 ChatGPT 帳號登入。Codex 會識別你的訂閱方案（Plus / Pro），並使用其額度。

2. 步驟 2：將 AGENTS.md 寫成操作文件

   審查 CLAUDE.md，將兩工具都適用的測試與 lint 命令、提交格式、禁止資料夾及技術堆疊重用在 AGENTS.md，對話偏好也可共用。調整工具特定命令引用，將可執行 hook 與 MCP 設定留在各工具自己的設定檔；只複製 Markdown 不會完成設定。

3. 步驟 3：為你的專案選擇一種模式

   如果你是使用 CI 的個人開發者，採用模式 1（Claude 撰寫，Codex 審查）。如果是新專案且需要速度，採用模式 2（Codex 起草，Claude 整理）。如果是具有基礎設施層的既有專案，採用模式 3（依層分工）。

4. 步驟 4：試用一週

   使用選定的模式處理 5-7 個功能。記錄花費時間，並記下每個功能由哪種工具處理得比較好。一週後，你就會對自己的實際使用情況有真實了解。

5. 步驟 5：設定規則同步

   新增 scripts/sync-agent-rules.sh 指令碼（請參閱規則同步一節）。設定為 pre-commit hook，或透過 GitHub Action 連接。設定之後，規則就會自動同步到兩個檔案。

這種搭配並非魔法，只是讓兩種思考方式互相補足弱點。關鍵是別再陷入「Claude 還是 Codex」的爭論；早已有了正確答案：「Claude 和 Codex 都用，分別處理不同類型的任務。」

代理工作的實用資料：Ailoot 文件。

更多資料與工具：Ailoot。