速评：10 月 22 日挂上 arXiv 的那篇 13 页论文，值得每个还在引用 SWE-bench 分数的人翻一遍。不是因为它提出了什么新框架，而是因为它顺手把判分器拆开看了。
拆出来一句话：任务说明是自然语言写的，判分用的是上游项目自带的测试，这两样东西压根不在一个话语体系里。测试里 import 哪个模块、硬编码了哪个字符串常量、路径写死成什么形式，说明里一个字没有，推也推不出来。作者给这道缝起了个名字，叫规范与判分器之间的缺口。说白了就是，智能体要拿分，得先猜中上游那位作者当年给变量起的名。
这不是嘴上说说的隐患。作者做了个实验，从参考实现里藏掉一个名字，128 次里有 126 次编译不过。一个名字，就是一道开关，拨一下整片测试就黑了。
还有个数字更直白：SWE-Milestone 那 98 个计分里程碑里，25 个含有这种依赖没说明也推不出来的测试，四分之一出头。含这类依赖的构建单元，80.6% 的运行里挂掉；没有这类依赖的同批单元，48.4%。
先别急着喊榜全是水。48.4% 也不是零，一半的失败还是正常的失败，这条得说清楚，不然就跟那种看见一个 bug 就宣布整个领域完蛋的号混成一类了。
真正让我坐直的是另一组结果：把这些受影响的测试删掉重算，排行榜的总体名次基本没动，但仓库内部的分数变了，而且变的方向是更有利于那些能复现上游名称的智能体。
这句话有两层，两层都是坏消息。
好的一层是：名次稳，说明头部那几家的相对位置可能真是能力差距撑出来的，别一竿子打成浪得虚名。麻烦的一层是：名次是相对序，分数是绝对值，而所有人引用的时候引的都是分数。“某某模型解决率 62%”，这个 62% 的口径从来没人校准过，它不是一把尺子，是一堆上游测试临时拼起来的量具。它测出来的不是模型有多能干，而是模型离上游作者的命名习惯有多近。
至于它是真懂还是背下来的，这道缝不问这个问题，也不打算问。
那这缝是怎么来的？成本。出题的人把上游项目现成的测试直接拿来当判分器，一行都不用重写。省下来的每一分工，都变成题里那一小块考“猜名字”的地方。这不是谁偷懒，是这套拼装方式本身就长这样。
论文里有一段我觉得比前面所有数字都该抄下来贴在每个做 bench 的人显示器边上：缺口比例取决于任务怎么造的。说明来自发布说明或者大模型摘要的，至少三分之一的任务中招；任务经过筛选、或者专为测试写的，几乎没事。
这条直接把枪口调到现在这波用 LLM 批量生成评测任务的动向上面。你图省事让模型把 commit 总结成任务说明，模型总结得确实流畅，通顺，像个正经需求文档，然后它把上游实现里那些必须知道的名字全漏了。省下的那点人工，最后从分数的可信度里扣。
顺带说一句，工具本身做得挺扎实，五种语言，按名称、路径、字面量三层扒依赖，留出数据上精确率 89.2%、召回率 92.9%，还把多个依赖任务串起来之后互相打架的情况也纳进去了。能做形式化描述这件事本身就是个判断：这不是某几个仓库的疏忽，它是一类结构性缺陷。缺陷能被定义，就说明它能被成批复现。
这里我得承认一句，我上个月还说过榜单第一的保质期撑不过一个月、看榜一选型是偷懒。这话我还认。但这次的剧本不一样：不是新王登基把旧王挤下去，是旧榜的计分口径被翻出来重算。前一种等一个月就完事，后一种得等有人愿意花力气去审计，而审计这件事，除了发论文没别的好处。
作者把审计工具、修正后的过滤列表、补充材料都公开了。好人。我打个问号的是：会有几个 bench 维护者真的跑一遍，然后回去把自己 README 上那个数字改小？
立个 flag：半年之内，会有一个主流编码 bench 推出重算版分数，旧数字被悄悄从首页换掉，通稿里不会提一句为什么。
一个需要你猜中别人仓库里常量名才能拿到的分数，到底在考什么？这些榜有用，但它现在的用处是给你一个大致区间，不是给你小数点后一位。谁再拿“某榜提升 0.3 个点”当发布会的核心卖点，我建议先去查查那 0.3 里有多少是名字猜对了。