盲评裁判：在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. 融合。 裁判将两份方案中最强的要素组合成一份精炼的实施简报。融合方案才是真正的产出。

五个评分维度：

关键设计决策：融合不是50/50的混合。它重度倾斜于胜者的核心策略，同时精选败者的真正洞察。早期尝试等权融合时产出的方案前后矛盾，继承了双方最差的特性。加权融合产出的方案在结构上是健全的（来自胜者），在细节上是经过充分强化的（来自败者的有效边界情况）。

案例研究：安全修复对决

2026年2月，一次三代理安全审计在ResumeGeni中发现了7个严重和7个高危问题。ResumeGeni是一个使用Supabase认证和Stripe支付的FastAPI应用。⁴我已经修复了两个简单问题，还剩九个。我运行了一场对决来生成修复计划。

两个代理收到了相同的简报：包含文件路径和行号的问题清单、架构上下文、一个约束条件（某个文件中已存在经验证的修复模式），以及产出分阶段部署计划的要求。

Alpha的方案： 针对9个问题的11个故事，组织为三个部署波次。一个测试基线故事（SEC-01）阻塞所有后续工作。带有具体指标的部署门禁：认证成功率、5xx监控、webhook拒绝计数。详尽的备选方案讨论。故事使用What/Why/Success结构并附带行号范围。

Beta的方案： 问题与故事直接1:1映射。三个部署波次：严重问题作为单一单元、高优先级问题可独立部署、清理。针对中间件问题采用先调查再修复的策略。每个故事都有具体的行号、函数名、import路径和用于验证的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/anon客户端拆分，包裹在一个可以嵌入Alpha三波次部署序列的结构中。完整的融合方案保留了Beta的先调查再修复C3的策略、Beta的具体curl验证命令、Alpha的部署门禁（认证成功率监控、5xx跟踪），以及Alpha的回归测试策略（波次1后运行端到端Playwright认证套件，波次2后运行Stripe测试webhook）。结果：一个包含12个故事的3波次计划，可在一天内执行，并具备任何单一方案都无法提供的运维防护措施。

记分板（以及为什么它具有误导性）

在36场对决中，13场产出了结构化评判清单。其中1份清单宣布未分胜负，剩余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的可观测性和生命周期跟踪纳入为1.5阶段，在初始种子投放产出可衡量结果之后执行。同样的模式出现在职位录入系统对决中，Claude的方案复用了现有的APScheduler和注册表，而Codex提出了一个更完善的双表溯源方案。融合方案采纳了Claude务实的架构，并精选了Codex的去重哈希改进。⁷

在ATS审查对决中，Claude发现了Codex完全遗漏的P0级运行时崩溃（调度器中的方法签名不匹配，会静默破坏职位跟踪）。⁵Codex发现了Claude未标记的调度器重叠预防和管理端点滥用向量。融合方案以Claude的P0修复为起点，辅以Codex的运维强化。

36场对决中的规律：裁判模型始终产出比任何一个参赛者方案都更强的融合方案。裁判并不更聪明，是对抗结构迫使了全面覆盖。⁹每个代理独立识别风险和边界情况。裁判看到所有这些。融合方案继承了两个代理洞察的并集，减去了各自的盲点。

这一规律与多代理审议中的更广泛发现相呼应：独立性是核心机制。十个审议代理从不同视角评估一个决策，能发现任何单一代理会遗漏的偏差。两个对决代理从不同架构攻克同一任务，能发现任何一个代理单独交付时都会放过的实现缺口。两个系统中的融合步骤是相同的：将独立评估合并为一个受益于所有视角的单一产物。

我另外记录了支撑这两个系统的编排层。这里重要的是，对决和审议服务于互补的功能。审议回答”我们应该构建这个吗？”对决回答”构建它的最强方式是什么？”

何时对决，何时审议

两个系统都使用独立评估和融合。它们服务于不同的决策类型。

我的模式：审议设计，对决实施计划，执行融合方案。

一个安全修复决策先经过审议（”这个优先级排序正确吗？我们是否遗漏了系统性问题？”），然后对决（”执行这些修复的最强分阶段计划是什么？”），最后从裁判的融合方案执行。审议系统和对决系统共享基础设施，但在决策管线中服务于不同的目的。

我做错了什么

早期对决没有盲化标记。我在知道哪个模型写了哪份方案的情况下阅读两份方案。确认偏差是真实且可衡量的：在引入盲化之前，我在可执行性维度上始终给Claude打更高的分，引入随机Alpha/Beta分配后差距缩小了（尽管没有消失）。盲化协议不是可选的。

我最初只有三个评分维度（正确性、完整性、可执行性）。两场对决后，我意识到自己把方案结构和方案内容混为一谈了。增加简洁性（是否过度工程化？）和分解能力（步骤是否有序排列？）分离了这些关注点，产出了更有用的评分。

最初的融合尝试等权混合两份方案。结果前后矛盾：Alpha的测试策略嫁接到Beta的部署序列上，两份方案的假设前提都不成立。加权融合——裁判明确采纳胜者的框架并选择性纳入败者的洞察——才是突破。

在我的任务组合上N=36不是一个模型基准测试。它是一个工作流工具评估。对决系统告诉我的是，在我的特定代码库中，哪个代理为我的特定任务产出了更强的方案。将其外推为”Claude比Codex更好”，与这个系统旨在消除的凭感觉推理如出一辙。

我使用Claude来裁判Claude和Codex之间的对决。我承认这个利益冲突。⁸缓解措施是结构性的：盲化标记、结构化维度，以及Codex确实赢了3场对决且在其他几场中接近获胜的事实。更强的测试应该通过非Claude裁判（Gemini或GPT）运行相同的对决并比较评分分布。我还没有这样做。在此之前，8比3的比分应该附带一个星号：裁判和一名参赛者属于同一模型家族。

参考文献