盲審法官：在36場對決中為Claude Code與Codex評分

Thomas Ricouard（@Dimillian）的描述比任何基準測試都精闢：「Claude Code就像一次非常非常中規中矩的重構，我知道它能執行到位。Codex是最先進的架構設計。但我還不確定它能否在不搞壞東西的情況下真正完成。」¹

我不再猜測，開始實測。我建立了一套系統，讓Claude Code和Codex CLI在相同任務上競速，將輸出隨機標記為Alpha和Beta，在揭曉哪個代理寫了哪份方案之前，先以五個維度進行盲審評分。三十六場對決之後，計分板顯示Claude在12場有明確勝負的對決中贏了8場。但計分板不是重點。重點是盲審法官在評分之後產出的成果：一份綜合方案，結合雙方計畫中最強的元素，產生比任何一位參賽者單獨交付的方案都更優秀的結果。

摘要

三十六場對決。以五個維度（正確性、完整性、簡潔性、分解能力、可操作性）進行盲審評估。在13場具有結構化判斷清單的對決中（其中12場有明確勝者），Claude Code贏了8場，Codex CLI贏了3場，1場未定。真正的產出不是一個贏家，而是綜合步驟——從雙方計畫中精選最佳元素，產出比任何一個代理單獨作業都更強的實作方案。姊妹篇以十個大腦思考探討協作式審議。¹²盲審法官則涵蓋競爭式評估。方法論比計分板更重要。

為什麼比較如此困難

現在每個人都在比較AI程式撰寫代理。沒有人的結論一致。

問題是結構性的。模型比較會沿三個軸線退化：直覺感受（你在每個模型上各試了一個任務，然後憑感覺選擇）、近因偏誤（最近一次成功覆蓋了之前所有的失敗記錄）、以及任務特異性優勢（在重構任務中勝出的模型在安全審查中落敗）。這些不是錯誤的觀察，而是糟糕的實驗。

Alex Finn（@AlexFinn）運行雙重驗證工作流程，讓兩個模型互相檢查對方的輸出。²雙重檢查方法能捕捉到任何單一模型都會遺漏的錯誤。其洞見是正確的：獨立評估能浮現分歧，而分歧正是錯誤藏身之處。

@doodlestein同時運行10個以上的代理——Claude、Codex和Gemini——使用他稱之為「點子巫師」的固定提示詞，從不同角度攻克同一問題。³擅長分解的規劃者可能遺漏一個更注重細節的代理能立即發現的正確性錯誤。

兩種工作流程都優於單模型評估。但都無法消除最大的威脅：確認偏誤。如果你知道哪個模型寫了哪份計畫，你會對你更信任的模型給出更高的分數。每次都是如此。不是因為你粗心，而是因為偏誤在意識之下運作。缺少的關鍵環節是盲審。如果評估者不知道哪個代理產出了哪份輸出，確認偏誤就無處附著。

盲審評估協定

/duel 系統分五個階段運作：

1. 平行執行。 兩個代理接收相同的任務提示和專案上下文。Claude Code在一個程序中運行，Codex CLI在另一個程序中運行。雙方都看不到對方的輸出。
2. 隨機標記。 擲硬幣將一個代理分配為「Alpha」，另一個為「Beta」。系統將對應關係寫入 agent-mapping.json 並封存。在評分完成之前，法官和我都看不到對應關係。
3. 盲審評分。 法官代理閱讀雙方計畫，在五個維度上各評0-4分，最高總分20分。法官只看到「Alpha計畫」和「Beta計畫」。
4. 勝者推薦。 法官宣布勝者（或未定），附帶信心等級和書面推理。
5. 綜合。 法官將雙方計畫中最強的元素結合成一份精煉的實作方案。綜合方案才是實際產出。

五個評分維度：

關鍵設計決策：綜合並非五五對分。它大幅偏重勝者的核心策略，同時精選敗者的真正洞見。早期嘗試等權重綜合時，產出的計畫前後矛盾，繼承了雙方最差的特性。加權綜合產出的計畫結構穩固（來自勝者）且經過徹底強化（來自敗者的有效邊界情況）。

案例研究：安全修復對決

2026年2月，一次三代理安全審計在ResumeGeni（一個使用Supabase認證和Stripe支付的FastAPI應用程式）中發現了7個嚴重和7個高風險發現。⁴我已經部署了兩個簡單修復。剩餘9個。我運行了一場對決來生成修復計畫。

兩個代理接收相同的簡報：包含檔案路徑和行號的發現清單、架構上下文、已在某個檔案中存在經過驗證的修復模式這一約束條件、以及必須產出分階段部署計畫的要求。

Alpha的計畫： 針對9個發現提出11個故事，組織為三個部署波次。一個測試基準故事（SEC-01）阻擋所有後續工作。部署門檻包含具體指標：認證成功率、5xx監控、webhook拒絕計數。詳盡的被拒替代方案討論。故事使用What/Why/Success結構搭配行號範圍。

Beta的計畫： 發現與故事直接1:1對應。三個部署波次：嚴重級別作為單一單元、高優先級可獨立部署、清理。對中介軟體發現採用先調查再修復的方式。每個故事都有具體的行號、函式名稱、匯入路徑和curl驗證指令。

正確性的差距說明了一切。Beta發現了兩個Alpha完全遺漏的問題。

第一：中介軟體發現（C3）將 get_user(jwt=...) 標記為會話污染向量。Beta正確識別出 get_user() 是無狀態驗證呼叫。gotrue-py只在 verify_otp 和 exchange_code_for_session 中呼叫 _save_session()，而非在 get_user 中。Alpha將其視為確定需要與其他兩個路由相同的修復方式，這會在每個認證請求上增加不必要的每請求開銷。Beta說：先調查，確認後才修復。

第二：魔術連結和通行金鑰路由同時使用 admin.generate_link()（需要SERVICE_KEY單例）和 verify_otp()（需要每次請求新建的客戶端）。Alpha的計畫統一套用了新建客戶端模式。按照該計畫實作的開發者會破壞管理操作。Beta明確指出了拆分方式：verify_otp 使用新建客戶端，admin.generate_link() 使用共享單例。

分數：

Alpha是Codex。Beta是Claude。高信心度。⁴

綜合方案結合了Beta的技術精確度與Alpha的運維嚴謹性。以下是綜合產出中的一個故事，展示了它如何融合雙方計畫：

故事1.1（C1——魔術連結共享單例）： 在 magic_link.py 中，新增 _create_auth_client()。僅對 verify_otp（第224行）使用新建的匿名客戶端。對 admin.generate_link()（第213行，需要SERVICE_KEY）保持共享單例。

該故事繼承了Beta的精確行號和關鍵的admin/匿名客戶端拆分，包裝在可嵌入Alpha三波次部署序列的結構中。完整的綜合方案保留了Beta對C3的先調查後行動方式、Beta的具體curl驗證指令、Alpha的部署門檻（認證成功率監控、5xx追蹤）、以及Alpha的迴歸測試策略（Wave 1之後的E2E Playwright認證套件、Wave 2之後的Stripe測試webhook）。結果：一份包含12個故事的3波次計畫，可在一天內執行完畢，具備任何一份單獨計畫都無法提供的運維防護措施。

計分板（以及為什麼它會誤導）

在36場對決中，13場產出了結構化判斷清單。其中一份清單宣布未定，剩下12場有明確勝者：

Claude：8場。Codex：3場。未定：1場。¹¹

不要將計分板視為模型基準測試。它不是。

Claude的勝場集中在審查、驗證和安全任務上：8場勝利中有7場是在涉及程式碼審查、安全分析或技術評估的任務上取得的高信心度勝利。Codex唯一一場高信心度勝利來自一個程式碼審查任務，其程序化的徹底性和明確的依賴鏈超越了Claude較不結構化的方法。其他兩場勝利為低信心度。規律是：Claude產出更具可操作性和技術精確度的計畫。Codex產出更強的運維流程和更廣泛的理論覆蓋。

Ricouard說得對。規劃品質與執行可靠性是一個真實的評估軸線。¹但計分板反映的是我的任務組合（偏重安全和架構審查），而非某種客觀的模型排名。如果有人在全新功能開發或基礎設施自動化上運行對決，很可能會看到不同的結果。Nathan Lambert對後基準測試時代的分析提出了相同觀點：當Opus 4.6和Codex 5.3之間的微小差距取決於任務形態和評估方法時，傳統基準測試已無法傳達有意義的訊號。¹⁰

計分板告訴你的是關於我的工作流程。它不能告訴你哪個模型「更好」。

綜合方案才是產品

獲勝的計畫不是重點。綜合方案才是。

每場對決產出三份成品：Alpha計畫、Beta計畫和綜合方案。綜合方案遵循一致的結構：採用勝者的核心策略，納入敗者的有效邊界情況，刪除雙方不必要的範圍。它不搞外交。它不折中。它對保留哪些元素、捨棄哪些元素做出明確選擇，並為每個決定提供書面理由。

在職缺語料庫擴展對決中，Claude的計畫優先啟用現有基礎設施（為系統尚未輪詢的8,780個已知看板運行種子腳本），然後擴展到新的ATS平台，再建立發現系統。⁶Codex的計畫在擷取任何一個職缺之前，先從程式碼庫審計和儀表化規格開始。Claude在簡潔性和可操作性上勝出。但Codex識別出了Claude遺漏的問題：需要一個看板生命週期狀態機（active/failing/quarantined）。Codex還標記了一個去重迴歸審計，以防止數量擴展掩蓋重複爆炸。綜合方案保留了Claude的優先啟用排序，並將Codex的可觀測性和生命週期追蹤納入為Phase 1.5，在初始種子投放產出可衡量結果之後。同樣的模式出現在職缺擷取系統對決中，Claude的計畫重用了現有的APScheduler和註冊表，而Codex提出了更徹底的兩表溯源架構。綜合方案採用了Claude的務實架構，並精選了Codex的去重雜湊改進。⁷

在ATS審查對決中，Claude發現了P0等級的執行時期崩潰（排程器中的方法簽名不匹配會靜默中斷職缺追蹤），而Codex完全遺漏了。⁵Codex發現了排程器重疊預防和管理端點濫用向量，而Claude未標記這些問題。綜合方案以Claude的P0修復為起點，輔以Codex的運維強化。

跨36場對決的規律：法官模型一致地產出比任何一位參賽者的計畫都更強的綜合方案。法官並不更聰明。對抗性結構迫使了全面覆蓋。⁹每個代理獨立識別風險和邊界情況。法官看到所有這些。綜合方案繼承了雙方代理洞見的聯集，減去各自的盲點。

這個規律與多代理審議的更廣泛發現相呼應：獨立性是其機制。十個審議代理從不同視角評估一項決策，能捕捉任何單一代理會遺漏的偏誤。兩個對決代理從不同架構攻克同一任務，能捕捉任何一個代理單獨作業時會直接交付的實作缺口。兩個系統中的綜合步驟是相同的：將獨立評估合併為一份受益於所有視角的單一成品。

我在另一篇文章中記錄了支撐這兩個系統的協調層。這裡重要的是，對決和審議服務於互補的功能。審議回答「我們應該建立這個嗎？」對決回答「建立它最強的方式是什麼？」

何時對決vs.何時審議

兩個系統都使用獨立評估和綜合。它們服務於不同的決策類型。

我的模式：審議設計，對決實作計畫，執行綜合方案。

一個安全修復決策先經過審議（「這是正確的優先排序嗎？我們是否遺漏了系統性問題？」），然後對決（「執行這些修復的最強分階段計畫是什麼？」），最後從法官的綜合方案執行。審議系統和對決系統共享基礎設施，但在決策管線中服務於不同目的。

我犯的錯誤

早期對決沒有盲審標記。我在知道哪個模型寫了哪份計畫的情況下閱讀雙方方案。確認偏誤是真實且可衡量的：在引入盲審之前，我持續在可操作性維度上給Claude更高的分數，引入隨機Alpha/Beta分配之後，差距縮小了（雖然沒有消失）。盲審協定不是可選的。

我最初使用三個評分維度（正確性、完整性、可操作性）。兩場對決之後，我意識到自己把計畫結構和計畫內容混為一談了。增加簡潔性（是否過度工程？）和分解能力（步驟排序是否合理？）將這些關注點分離，產出了更有用的評分。

最初的綜合嘗試等權重混合雙方計畫。結果前後矛盾：Alpha的測試策略嫁接到Beta的部署序列上，雙方計畫的假設都不成立。加權綜合——法官明確採用勝者的框架並選擇性納入敗者的洞見——是突破性的改進。

N=36在我的任務組合上不是模型基準測試。它是工作流程工具評估。對決系統告訴我的是，在我的特定程式碼庫中，哪個代理為我的特定任務產出了更強的計畫。將其推論為「Claude比Codex好」，正是這個系統存在的目的所要消除的那種基於直覺的推理。

我使用Claude來裁判Claude和Codex之間的對決。我承認這個利益衝突。⁸緩解措施是結構性的：盲審標記、結構化維度、以及Codex贏了3場對決且在數場中接近勝出的事實。更強的測試應該通過非Claude的法官（Gemini或GPT）運行相同的對決，並比較評分分布。我尚未這樣做。在此之前，8比3的比分應附帶一個星號：法官和其中一位參賽者屬於同一模型家族。

參考文獻