# Claude Code 與 Codex 一起使用：3 種工作模式 > Claude Code 與 Codex 協作：撰寫與審查程式碼、草擬與架構設計、分離基礎設施與商業邏輯，以及同步指示。 Source: https://ailoot.ai/blog/zh-hant-tw/claude-code-codex-together/ Canonical: https://ailoot.ai/blog/zh-hant-tw/claude-code-codex-together/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-047 Revision: sha256-dd074da6892f20595de99134391d15f640ba469911ed32a31f23f3e926fcfa78
重點摘要 一個代理、一種步調：要嘛仔細推敲架構，要嘛快速產出草稿。Claude Code + Codex 的組合可以涵蓋這兩種模式。Claude Code 會深思熟慮、提出問題並謹慎行事。Codex 則在沙箱中一路推進，直到完成目標。到了 2026 年，多數實力堅強的團隊都會同時使用兩者，並視情況切換。
代理與氛圍式寫程式的實用資料：[Ailoot 文件](https://ailoot.ai/docs/)。 ## 為什麼 2026 年只用一種工具已經不夠？
重點摘要 到了 2026 年 6 月，「一個對的代理就能處理所有事情」這個迷思已經破滅。Claude Code 擅長架構工作與長時間的重構。Codex 處理自主 PR 和平行沙箱任務的速度更快。
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 指南](https://ailoot.ai/blog/zh-hant-tw/codex-vs-claude-code-choice/)——這裡就直接來談兩者如何搭配。 到了 2026 年，沒有單一的贏家。最常見的模式是：團隊保留 Codex 來處理成本低廉的自主工作，並使用 Claude Code 做高風險的架構決策。 決定如何分配工作的關鍵差異： - **Claude Code 是研究者。** 它能維持長時間、深入的對話，質疑假設，並在選定解法前考量幾種做法。適合一開始就無法明確判斷正確做法的情況。 - **Codex 是執行者。** 它接下任務，並在沙箱中一路推進到完成。適合目標明確、需要快速「交辦—取得成果」循環的任務。 如果兩種工具都在手邊，就不必在「思考」和「執行」之間二選一。你可以依任務類型分派工作。如果還沒決定要先安裝哪一種，可以參考[Codex 與 Claude Code 指南](https://ailoot.ai/blog/zh-hant-tw/codex-vs-claude-code-choice/)中的正面比較。 ## 模式 1：Claude Code 撰寫程式碼，Codex 負責審查
重點摘要 這是最容易上手的模式。Claude Code 在 Plan Mode 中推敲架構，並在理解背景後撰寫功能。Codex 取得拉取請求中的差異內容，執行測試、檢查邊界情況，並找出 Claude 因幻覺而漏掉的錯誤。適合需要品質把關和第二雙眼睛的情況。
在這種模式中，Claude Code 仍是主要編輯者。Codex 只會透過雲端模式在 PR 階段加入審查（Codex 直接從 ChatGPT 或 GitHub App 執行，因此不需要第二個終端機）。 **實際做法如下：** 1. ### 步驟 1：在 Claude Code 中撰寫功能 在 VS Code 中開啟儲存庫，啟動 Claude Code，切換到 [Plan Mode](https://ailoot.ai/blog/zh-hant-tw/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 整理架構
重點摘要 這是模式 1 的鏡像做法。Codex 快速寫出粗略草稿——例如模型、表單或端點——幾分鐘內就能交付。接著在 Claude Code 中開啟檔案，請它整理架構、分離各層、加入型別並修正命名。適合快速開始比一開始就精雕細琢更重要的情況。
2026 年一個案例中的專案採用了這種模式，當時必須在一個晚上完成具備電子郵件通知的註冊流程原型。在這種情況下，你可以花一小時和 Claude Code 討論架構；而 Codex 在 12 分鐘內就產出可運作的草稿。 **運作流程：** | 階段 | 負責者 | 時間 | 產出 | |----|----|----|----| | 規格 | 任務撰寫者 | 5 分鐘 | 1 個段落：想做什麼、有哪些欄位、有哪些限制 | | 粗略草稿 | Codex | 5-15 分鐘 | 可運作的程式碼、測試、文件 | | 架構整理 | Claude Code | 20-30 分鐘 | 分離的層、嚴格型別、清楚的命名 | | 最終測試 | Claude Code | 10 分鐘 | 完整涵蓋，沒有缺漏 | 流程是這樣：前 15 分鐘由 Codex 負責繁重的基礎工作，接著由 Claude 將成果提升到正式環境的品質。 要求 Codex 一開始就做到精緻完善，它會卡在模糊之處。要求 Claude Code 一開始就追求速度，它就會開始反覆斟酌。把各自擅長的工作交給它們。 **模式 2 的風險：** - Codex 產出的草稿可能包含假設，之後很難整理。如果草稿方向錯了，丟掉重來比修正更省力。 - Claude Code 可能花半小時重新命名變數，卻忘了真正的架構問題。請指定具體修改，不要只說「整理一下」。 - 工作階段之間會遺失背景脈絡。若要讓 Claude Code 理解 Codex 的原意，需要 `AGENTS.md`（見模式 5）或檔案開頭的詳細評論。 ## 模式 3：Codex 負責基礎設施，Claude Code 負責商業邏輯
重點摘要 這是最適合 2-5 人團隊的進階模式。Codex 負責基礎設施——CI/CD、測試、遷移、基礎設施即程式碼和設定。Claude Code 負責商業邏輯——模型、產品功能和使用者情境處理。每個工具都在各自的職責範圍內運作。
概念很簡單：程式碼庫的不同部分，適合不同的工作方式。 這種模式補充了[平行執行多個 Claude Code 執行個體](https://ailoot.ai/blog/zh-hant-tw/claude-code-parallel-worktree-agents/)的做法——後者透過 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？
重點摘要 搭配兩工具時，請核對指示是否一致。兩個檔案都可共用專案事實、測試命令、程式規則、限制及對話偏好；複製 Markdown 本身不會必然讓 Codex 出錯。應檢查工具特定命令與設定，一個做法是在 `/context/` 保存正規來源，再由它產生兩個檔案。
在並行使用 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+ 種代理都會讀取它。[另一篇指南](https://ailoot.ai/blog/zh-hant-tw/agents-md-guide-template/)會更詳細地介紹 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`。 ## 同時使用兩者要花多少錢？節省又從何而來？
重點摘要 大約來說：Claude Code Max（5x）每月 \$100，Codex Plus 每月 \$20，Codex Pro 每月 \$200。個人使用者選擇 Claude Max + Codex Plus，每月共 \$120。只要省下一小時的工作時間就值得。主要的節省來自更快找到正確解法；在這裡，token 是次要因素。
以下是 2026 年 6 月的價格（[Anthropic 和 OpenAI 官方訂閱頁面的資料](https://www.anthropic.com/pricing)，以及 [Codex 官方頁面](https://openai.com/codex/)）： | 訂閱方案 | 價格 | 內容 | |-----------------|-----------|--------------------------------------| | Claude Pro | \$20/月 | Claude.ai + Claude Code（Pro 使用額度） | | Claude Max 5x | \$100/月 | Claude Code，Pro 使用額度的 5 倍 | | Claude Max 20x | \$200/月 | Claude Code，Pro 使用額度的 20 倍 | | ChatGPT Plus | \$20/月 | Codex CLI + 雲端（Plus 使用額度） | | ChatGPT Pro 5x | \$100/月 | Codex CLI + 雲端，Plus 使用額度的 5 倍 | | ChatGPT Pro 20x | \$200/月 | Codex CLI + 雲端，Plus 使用額度的 20 倍 | **最低限度的實用組合：** 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-2 個功能的個人專案、嚴格限制在每月 \$20 的預算、沒有 CI/CD 的簡單架構，以及 Claude Code 已能可靠處理所有任務的團隊。在這些情況下，加入 Codex 代表要花時間同步規則，換取不確定的效益。
這種搭配並不適合所有人。很多時候，它只會增加雜訊。以下是四種不需要第二種工具的情況： 1. **剛起步的個人專案。** 如果你只有一個點子，還在測試階段，只用 Claude Code + Plan Mode 就足以應付一個月。遇到速度瓶頸時再加入另一種工具。 2. **預算嚴格受限。** 如果每月上限是 \$20，就選 Claude Pro，不必多想。Claude 單獨就能處理氛圍式寫程式者 80% 的任務。 3. **架構簡單。** 有表單的網站、只有幾種情境的機器人、API 包裝指令碼——在這些情況下依層分工沒有幫助。一個 Claude Code 就能處理。 4. **目前一切運作正常。** 如果你一直在使用 Claude Code，過去一個月沒有任何任務讓它卡住或失敗，就不要改動已經有效的做法。等到需求變得明確時再加入 Codex。 反過來說，以下是該引進第二種工具的明確跡象： - Claude Code 已成為瓶頸：你在等它完成，而不是繼續工作。 - 出現大量樣板基礎設施工作（遷移、CI、測試），而你不想再用 Claude 處理這些工作。 - 團隊中的不同成員已經在使用不同工具，因此需要共通的語言。 - 基準測試顯示 Codex 能更快處理你的任務類型（例如終端機操作）。 ## 如何在一個晚上設定好這組工具
重點摘要 利用一個晚上的時間逐步完成：在 Claude Code 旁安裝 Codex CLI，於 AGENTS.md 重用共通技術規則並分開工具特定指示，再選擇 3 種模式之一、用它處理 3-5 個功能，並與過去的工作速度比較。接著持續調整：更換模式、同步規則，並加入 MCP 伺服器。
第一個晚上可以照著以下具體計畫進行： 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 文件](https://ailoot.ai/docs/)。
### 來源 - [Anthropic - Claude Pro 和 Max 定價](https://www.anthropic.com/pricing) - [OpenAI - Codex 定價](https://openai.com/codex/) - [Codex 更新日誌 - OpenAI Developers](https://developers.openai.com/codex/changelog) - [Claude Code 文件 - CLAUDE.md 格式](https://code.claude.com/docs/en/memory) - [AGENTS.md 開放標準](https://agents.md/)
更多資料與工具：[Ailoot](https://ailoot.ai/)。 ## 常見問題：Claude Code 與 Codex 一起使用：3 種工作模式 | Ailoot ### CLAUDE.md 的內容能重用在 AGENTS.md 嗎？ 可以。確認兩款工具都適用後，可共用專案事實、測試指令、程式慣例與限制。工具特定指令及設定引用要調整；複製 Markdown 本身不會必然弄壞 Codex。 ### 如何比較雙代理流程與目前做法？ 先選一種協作模式，用一週處理幾個真實功能，記錄耗時與抓到的缺陷，與先前相似的單工具工作比較，再增加同步或更多代理。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。