为什么需要对抗式：静态榜的区分度正在消失
先看这场实验的背景压力。2026 年 10 月初的编码智能体榜单呈现出一种「处处饱和」的格局：LMArena Code 榜前五名挤在约 1700–1818 Elo 的区间；LiveBench 编码榜前三名分差仅 0.2 分；CursorBench v4.0 榜首与第三名相差约 11 分但前三被 Claude 系包揽；Artificial Analysis 综合指数前两名仅差 1.6 分。多个旗舰模型在多套固定基准上同时清题，意味着「再涨 2 分」的榜单读数已经很难翻译成「实际好用 2 分」。
同时，固定测试集还有一个更根本的缺陷，这次实验把它演示得淋漓尽致：隐藏测试集只能考出出题人想到的失败模式。一个测试套件无论多少用例，都是一份有限的失败枚举；智能体只要在枚举内的失败模式上全部正确，就能拿满分——而满分不等于没有 bug，只等于没有「被想到的」bug。helloai 的对抗赛把这个抽象论点变成了可复现的具体过程。
这场比赛最有价值的产出不是名次，而是一个结构性对照：固定隐藏测试集（801 道用例）两次给出全员满分、零区分度；三个参赛者互相找出的反例却在每轮都分出了胜负。失败面的来源从「出题人的想象力」换成了「对手的创造力」，区分度立刻回来了——代价是这种评测无法给出可比的绝对分数，只能给出相对胜负。
赛制拆解：哈希锁死的隐藏测试包与独立裁判
这场比赛的公信力设计值得单独一节，因为对抗式评测最容易被质疑的就是「事后换题」「裁判偏袒」。helloai 的赛制针对这些质疑逐条做了防御：
- 同题同刻：三个智能体解同一任务、同时开始，各自在自己的 git clone 中交付，杜绝先后手与信息差。
- 哈希预承诺：开赛前，裁判先公布隐藏测试包的 sha256 哈希；赛后揭示测试包并校验哈希一致。三轮的揭示结果都与赛前哈希匹配——测试集不可能被中途替换。
- 独立裁判：评判由一个单独的 Claude Sonnet 会话承担，不参与比赛，与任何参赛智能体不存在同会话利益。
- 全部留痕：赛题规格、揭示的隐藏测试、每位参赛者的被判代码全部发布在公开目录（docs/briefs/worktree-cup-2026-10-04/），任何人可以复核。
这套流程把「信任评测方」转化为「验证哈希与文件」。对准备自建内部评测的工程团队而言，哈希预承诺 + 留痕公开是零成本可借用的两条纪律。
量化结果：两轮满分平局与半分差决赛
比赛共三轮。Round 1 为热身任务；Round 2 要求修复一个预设缺陷的语义化版本（SemVer）库，隐藏测试集含 190 个用例；Round 3 要求从零实现一个精确有理数计算器，隐藏测试集含 611 个用例。最终排名：Claude Opus 5.5 拿 6.5 分，Grok 4.7 拿 6 分，GPT-6 Astra 拿 5.5 分——三位参赛者各差半分。
| 轮次 / 任务 | 隐藏测试用例数 | Opus 5.5（Claude Code） | Grok 4.7 | GPT-6 Astra（Codex） |
|---|---|---|---|---|
| Round 1 — 热身任务 | 128（Astra 迟交后补测） | 满分通过 | 满分通过 | 128/128（迟交） |
| Round 2 — 修复 SemVer 库 | 190 | 100% | 100% | 100% |
| Round 3 — 精确有理数计算器 | 611 | 100% | 100% | 100% |
| 最终得分 | — | 6.5 | 6 | 5.5 |
表格的读法要倒过来：Round 2 与 Round 3 两轮，固定测试集给出的信息量是零——三个当时被称为头部水平的智能体全部满分，两次平局。也就是说，在这两轮里，801 道题没有测出任何一个参赛者的任何差异。所有区分度都来自测试集之外：参赛者互相提交的「反例」（counterexample）——即「你的代码在我的输入上错了」的证明。
致胜反例：4300 位整数陷阱与超时攻击
两轮互测中暴露的 bug 模式非常具体，也极具代表性：
| 轮次 | 攻击者 → 受害者 | 反例输入 | 触发的缺陷 |
|---|---|---|---|
| Round 2 | 两名参赛者 → Grok 4.7 | 4,301 位大数字 | 命中 Python 默认 4,300 位整数转字符串限制，代码崩溃 |
| Round 2 | Grok 4.7 → 另外两名参赛者 | 百万位级输入 | 拖垮每用例 10 秒超时，其中一个用例耗时 35 秒 |
这两类反例揭示了固定测试集的盲区结构。4,300 位整数转换限制是 Python 的一个真实运行时行为——语义化版本比较逻辑在常规测试数字上完全正确，只有越过 4,300 位这个临界值才崩；出题人如果没想到这个临界值，就不会写出这道用例。而超时攻击则更微妙：代码在语义上完全正确，只是性能上可被拖垮，「正确性测试集」通常根本不度量时间维度。每个满分隐藏分背后都藏着一个真实的规格失败——这是原文给出的判断，两轮结果为此提供了直接证据。
裁判也会犯错：评测者自身的中招记录
这场比赛最有诚意的部分，是裁判把自己的错误也公示了。Round 2 中，裁判自己的参考解犯了与 Grok 4.7 同样的 4,300 位整数 bug，并在轮中被当场公开修正。Round 3 吸取教训后，裁判显式加了输入边界，并用一个独立 oracle 对 15 万条模糊生成的表达式做了校验——即便如此，仍在冻结前又抓到一个 bug。
这个细节把问题推深了一层：用大模型当裁判，裁判的参考解本身就是一份「智能体代码」，它同样受制于出题人的盲区。评测链条上的每一个环节——出题、判题、参考实现——都可能共享同一批认知盲区，而参赛者的对抗恰恰能命中这些盲区，因为三个独立训练的模型的盲区并不重合。这是对抗式评测区别于固定测试集的深层价值：它利用了不同智能体失败模式的相关性差异。
运营影响结果：审批点击与用量配额的暗变量
结果之外，运营细节对名次的影响同样值得记录。Round 1 中，GPT-6 Astra 因为在等待一次人工审批点击而错过提交期限；赛后组织方承认其迟交作品实际得分为 128/128。Round 3 中，Astra 的用量配额耗尽，组织方单独为它暂停了比赛。这三件事与模型能力毫无关系，却直接改变了比赛进程。
对照本站此前对智能体评测口径的多轮讨论（Harness 贡献近 50 分的 GAIA 三口径、Terminal-Bench 的 hacks 罚分、METR 揭示的评测与现实 24 分落差），运营变量是又一个被普遍低估的评测噪声源：审批流、配额、超时设置、沙箱环境——它们不出现在任何分数里，却能决定一次运行是完成还是失败。任何严肃的智能体评测报告，都应该像这场小赛一样把运营事件写进结果页。
方法论启示与这场实验的边界
把这场实验放进更大的坐标系，可以得到三条对评测方法论的启示。其一，静态榜与对抗测是互补而非替代：静态榜给出可比的、跨时间的绝对分数，适合跟踪长期趋势；对抗测给出真实失败面的相对胜负，适合在候选集内做决胜。其二，哈希预承诺与留痕公开是把评测公信力从「信任」升级为「验证」的最小成本方案。其三，裁判与参考解自身需要被评测——独立 oracle 校验与模糊测试应该成为评测流程的内建环节。
同时必须诚实标注这场实验的边界。规模上，它只有三轮、三个参赛者、一台机器，不构成任何统计意义上的排名；来源上，这是一次自家实测——源码包由获胜者 Claude Opus 5.5 编译，而记录文章本身由参赛者 Grok 撰写，原文对这两重利益相关都做了明确声明，读者可以对照公开的哈希与文件自行核验；泛化上，「对抗互测分出胜负」不等于「互测名次等于产品能力名次」，不同任务分布、不同 harness 配置下的结果可能完全不同。作为参照，同一时期的独立榜单给出了不同的相对格局：vals.ai 的 Terminal-Bench 4.0 榜上，Opus 5.5 与 Sonnet 5.5 在极简 harness Mini-SWE-agent 中分别以 65.15% 与 64.14% 领先，GPT-6 Astra 为 59.60%（10 月 1 日读取口径），而产品级 harness 的 9 月 22 日快照中 Codex+Astra 58.2% 与 Claude Code+Fable 5.1 57.9% 几乎并列——两份快照的配置与时间不同，不可做精确比较，但它们与对抗赛共同指向一个结论：在头部区间，模型之间的排序高度依赖测量方式本身。
对抗式互测不会取代 Terminal-Bench 或 SWE-bench 这类基础设施，但它演示了一个正在被越来越多评测者接受的判断：当固定测试集饱和之后，评测的下一波区分度只能来自「未被想到的输入」——而对手，是目前已知的最好的「未想到」生成器。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。