Claude Code 與 Codex 雙引擎套件：功能與數據揭密

如果你在同一個專案中同時使用 Claude Code 和 Codex，你可能需要維護兩份規則檔，手動審查，並比你希望的更頻繁地推送程式碼。這個「雙引擎套件」是我用來運行這兩個引擎的檔案集合，打包成一個腳本即可安裝。

我從最初的 Codex 和 Claude CLI 版本開始建構這個套件，以下的所有數據都來自我在自己專案中的日誌紀錄。這篇文章將逐步介紹套件的每個部分、其功能以及促使我加入它的衡量標準。

在我的設定中，Claude Code 負責撰寫程式碼，而 Codex 則負責審查。Claude Code 中的一個協調器（orchestrator）會規劃工作、撰寫簡報、在各自的 Git 工作樹中啟動工作代理、讀取它們的差異、運行本地閘門並合併。

工作代理從不直接推送程式碼。對於每個準備好的拉取請求（pull request），一個 Codex 會話會在唯讀沙盒中讀取差異，並必須以一個「裁決」（verdict）結束。我選擇了來自不同公司的審查者，因為它有不同的盲點。

本月的一個拉取請求中，第一次 Codex 審查回報了 2 個阻礙性問題和 8 個建議修復的發現。這是一個數據點，也是這個審查循環存在的理由。套件中的任何部分都不會阻止你交換這兩個引擎的角色。

我讓兩個引擎執行相同的任務：在 10 月 12 日，針對 44 個隱藏測試實作一個 Tetris 遊戲，每個引擎運行三次。結果顯示，Claude Code 的 Opus 5.5 模型在三次運行中都以 21 分 17 秒的平均時間通過所有 44 個測試，花費 4.47 美元。

Codex 的 GPT-6.1-Sol 模型則以 18 分 13 秒的平均時間通過所有測試，花費 0.50 美元。兩者得分相同，但 Opus 的成本是 Codex 的 8.9 倍。

在 Claude Code 內部，當努力程度設為「高」（effort high）時，Opus 5.5 和 Sonnet 5.5 都能在每次運行中通過所有 44 個測試，而 Haiku 5.5 則在三次運行中通過了兩次。Opus 的平均成本為 1.61 美元，Sonnet 為 0.72 美元，Haiku 為 0.19 美元。

因此，這個套件會根據錯誤的成本來分配工作。有明確簡報的有限實作會交給 Sonnet。Haiku 5.5 則負責搜尋、提取和列表等任務，因為這些任務的錯誤很容易被發現且修復成本低。

「xhigh」和「max effort」設定則用於設計複雜的部分、拉取請求的首次審查以及困難的偵錯。路由規則儲存在 config/efforts.md 檔案中的表格裡，你可以編輯它，而且每個模型名稱都是純文字，因此當名稱變更時，你也可以隨時修改。

為了解決兩個引擎使用兩個規則檔導致每次規則變更都必須重複操作的問題，套件中只需編輯一個檔案：rules/RULES.md。Claude Code 會透過 ~/.claude/CLAUDE.md 中的 @imports 讀取它。

同時，sync.sh 腳本會從相同的來源為 Codex 建構 ~/.codex/AGENTS.md。第一條規則設定了當兩條規則衝突時的優先順序：你的當前訊息、專案的規則檔、全域規則，然後是記憶筆記。

安裝程式還會關閉 Claude Code 的提交和拉取請求歸因功能，因為規則規定提交中不允許 AI 歸因。它也會將 Codex 的 project_doc_max_bytes 提高到 64 KiB，因為超過預設限制的 AGENTS.md 會被截斷，導致 Codex 無法看到末尾的規則。

審查循環腳本 cross-review.sh 會拒絕包含未提交或未追蹤檔案的程式碼，然後運行 Codex 審查，並僅從審查者的最終訊息中讀取裁決。它只在 Codex 退出碼為 0、程式碼未被修改且最終訊息中只有一行「Verdict:」時才接受結果。

接著，它會寫入一個以被審查提交命名的裁決檔案。如果發生崩潰、答案被截斷或程式碼被移動，則會導致退出碼為 1 且不產生裁決檔案。

我在十月的一個晚上發現四個從未被審查的僅測試提交後，才加入了這個裁決檔案。其中一個已經被合併，另外三個則在合併佇列中。現在，當設定 REQUIRE_REVIEW=1 時，merge-pr.sh 會拒絕任何沒有該精確提交的 ACCEPT 檔案的提交。

一個私人儲存庫在其託管 CI 的前五天內，消耗了約 2,100 分鐘的 GitHub Actions 時間，而免費方案每月只有 2,000 分鐘。此後，所有檢查都會先在我的機器上運行，只有通過後才會推送工作。

workflow/bin/local-ci.example.sh 是一個骨架腳本，你可以用自己的測試指令來填充它。它會取得一個機器級別的鎖定，確保兩個閘門不會共用 CPU 和埠。

它在乾淨的環境中運行，以避免意外的 .env 檔案改變結果。在乾淨的樹上完整通過後，它會寫入一個以提交命名的通過記錄。merge-pr.sh 會拒絕推送任何沒有該精確提交和樹的記錄的程式碼。

推送後，它會使用 GitHub 的 sha 參數進行合併，這樣如果分支頭在期間移動，GitHub 就會拒絕合併。設定 DRY_RUN=1 會運行所有本地檢查，並印出推送和 API 呼叫，而不是實際執行它們。

我自己的閘門運行 40 到 43 個檢查。如果一個接一個地運行，完整通過需要 35 到 40 分鐘；如果分成五個平行通道，則在那台機器上大約需要 11 分鐘。套件中的骨架腳本沒有平行通道，指南中也說明了這一點。

最多同時運行三個代理，這個數量包括審查會話以及工作代理啟動的任何輔助代理。在我設定上限一週後，我發現有四個代理正在運行，而我的列表只顯示三個，因為一個工作代理啟動了一個輔助代理。

從那以後，worker-rules.md 的第一行就禁止工作代理啟動輔助代理。由於一台機器上兩天的經驗，清理（cleanup）是 RULES.md 中的一條硬性規則。

在 10 月 7 日，一次清理移除了 29 個已合併的工作樹（24 GB）和 31.2 GB 的 Docker 建構快取。在 10 月 17 日，另一次清理移除了 69 個工作樹和 88 個已合併分支，磁碟使用量從 184 GB 降至 76 GB。

如果你運行自己的 MCP 記憶體伺服器，記憶體模組允許兩個引擎將決策和事實保存為簡短的筆記。當一個回合完成了實際工作但沒有保存任何內容時，一個「停止」掛鉤（Stop hook）會每回合詢問一次是否需要筆記。

每週一次，一個 Claude Code 會話會提出修正建議，第二個會話會在寫入任何內容之前，將每個建議與原始筆記進行核對。9 月 22 日的首次運行中，提出了 9 個建議，應用了 8 個，驗證器拒絕了 1 個。

召回測試在之前和之後都是 18 個中的 18 個。套件中不包含伺服器，如果沒有伺服器，安裝程式會跳過這個模組。

你需要 bash 4 或更新版本、python3 3.9 或更新版本、git，以及已登入的 Claude Code 和 Codex CLI。gh 僅用於合併和鏈式腳本。

它可以在 WSL2、Linux 和 macOS 上運行。我已在安裝 Ubuntu 24.04 的 WSL2 上進行測試，Linux 和 macOS 在設計上支援但尚未經過測試。原生 Windows 不受支援。

bash install.sh 會預覽每個變更，並在每個步驟詢問你是否確認（y/N）。你現有的 CLAUDE.md 和 AGENTS.md 規則在兩個引擎中都會保持啟用。

它替換或建立的每個檔案都會進入一個私人備份，而 uninstall.sh 會逐位元組地恢復它們。

你可以先試用免費部分。免費的 MIT 授權「雙引擎閘門」（two-engines-gate）包含核心檢查功能：一個以提交雜湊儲存的唯讀審查、一個測試通過記錄，以及一個同時需要這兩者的合併檢查。

運行 bash demo.sh 可以觀看一個包含替補審查者的循環。付費的「雙引擎套件」（Two Engines Kit，目前版本為 v1.0.2）則增加了共享規則書、掛鉤、帶備份的安裝程式、包含 merge-pr.sh 和 chain.sh 的完整審查循環、記憶體模組，以及包含上述所有數據的指南。

這個雙引擎套件是根據自最初的 Codex 和 Claude CLI 以來收集到的資訊所建構的。