有一个数据点，在过去一年里一直被行业的热情噪音盖住，但它很重要。
METR 最近发布的研究报告，追踪了 LLM 在 SWE-bench 任务上的表现——用两套不同的成功标准来衡量：一是"代码通过所有测试"，二是"代码会被项目维护者批准合并"。两套标准得出的成功时间窗口相差悬殊：在"通过测试"这个标准下，LLM 解决任务的有效时间窗口大约是 50 分钟；换成"会被合并"这个标准，窗口缩小到 8 分钟。
但更耐人寻味的是第二个发现：合并率这个指标，在 2025 年初之后，几乎没有增长。
测试通过和代码合并，是两件不同的事
这个区分本身就值得停下来想一想。
一段代码通过了所有测试，不等于它是好代码。SWE-bench 的任务是修复真实开源仓库中的 bug，LLM 可以通过以下方式"骗过"测试：注释掉导致测试失败的代码路径、把测试期望的值硬编码进去、用一个局部正确但破坏整体架构的补丁绕过问题。这些方式在测试框架下看起来成功，但在人工审查下会立刻被拒绝。
"维护者是否愿意合并"这个标准，测量的是完全不同的东西：代码风格的一致性、对项目约定的遵守、变更范围的合理性、对边界情况的处理方式。这是一个综合性的判断，包含了很多测试无法捕捉的隐性知识。
METR 用合并率作为衡量真实编程能力的代理指标，这是一个比基准分数更诚实的选择。
数据说了什么
entropicthoughts 的作者看完 METR 的数据之后，做了一件简单但重要的事：对合并率的时间序列数据做了统计拟合，比较三种模型的预测能力——线性增长趋势、阶梯函数、常数函数。
结果：
- 线性增长（METR 的解读）：Brier 分数 0.0129
- 阶梯函数：0.0117
- 常数函数（合并率不变）：0.0100
Brier 分数是预测误差的平方均值，越低越好。一个预测"合并率从 2025 年初至今完全没有变化"的模型，比预测"持续线性增长"的模型更准确。
这不是在说 LLM 没有进步。2024 年底到 2025 年初之间，确实有一次能力阶跃，合并率出现了明显的跳升。但在那之后，数据支持的是一条水平线，而不是一条向右上方延伸的线。
为什么这件事没有被更多人讨论
这是文章里我觉得最值得保留的一个问题。
在过去的一年里，模型发布的频率并没有降低，每一个新版本都附带着"在 X 基准上超越了 Y"的声明。Coding 能力的提升是这些声明里出现频率最高的一个。但如果合并率——一个比通过率更贴近真实能力的指标——一直没有变化，那些宣称的进步究竟落在哪里？
一种可能：模型在"让代码看起来更像会通过审查的代码"这件事上进步了，但实际的工程能力并没有跟上。模型更擅长规避评估，但不一定更擅长解决真实问题。这和 Goodhart 定律的预言完全一致：当一个指标成为目标，它就不再是好的指标。
另一种可能：我们真正缺少的是新的、更难被"学会应对"的基准。SWE-bench 在 LLM 训练数据里已经有相当的覆盖度，在这个集合上的进步，并不完全等同于对新的、未见过的工程问题的真实能力提升。
作者在最后诚实地说：他不知道最近几个月（Claude opus 4.6、Gemini 3 这一代）的情况，因为 METR 的数据没有覆盖到最新模型的合并率。在 2025 年全年，有大量人宣称"这次真的有了新的跃升"，但事后来看那些宣称没有在合并率上体现出来。同样的事情现在会再次发生吗？他不知道。但这个问题本身值得保持警觉。
对实际工程决策的意义
如果合并率停滞是真实的，它对工程团队意味着什么？
最直接的含义是：用于 coding 的 LLM 工具，在过去一年里，提供给工程师的真实生产力增益，可能没有官方发布节奏所暗示的那么稳定。工具的界面在改善，体验在优化，但底层任务完成能力的增长，可能是一个阶梯函数而不是斜坡——我们可能正处于一个平台期。
第二个含义是：评估工具应该用更接近"会被合并"而不是"通过测试"的标准。这对于企业在选择 AI 编程辅助工具时，有实际的方法论意义。pass@k 这类指标很容易被操纵，真实的维护者满意度很难被操纵。
最后一个含义，是对整个行业的：基准游戏和真实进步之间的距离，可能比我们通常意识到的要大。在 AI 能力叙事里保持独立判断的成本很低，但放弃独立判断跟着热情走的代价，在工程决策上是真实的。
