大数跨境
首页
>
一半通过测试的 AI 代码，维护者不收 | SWE-bench 的分数，被高估了多少？
>

一半通过测试的 AI 代码，维护者不收 | SWE-bench 的分数，被高估了多少？

一半通过测试的 AI 代码，维护者不收 | SWE-bench 的分数，被高估了多少？ 经纬出海
2026-11-02
5
导读：METR 请 4 位开源维护者盲审了 296 个通过 SWE-bench 测试的 AI 补丁，约一半不会被合并。代码评测的下一步，是从「能不能跑」走到「能不能被团队接受」。
Image
代码一直被认为是最容易评估的领域：有测试，跑一遍就知道对不对。今天这篇研究恰恰质疑这一点：测试通过，只能说明代码能跑，不能说明它是一段好代码。

  • 研究：Many SWE-bench-Passing PRs Would Not Be Merged into Main（很多通过 SWE-bench 的代码，不会被合并进主分支）
  • 作者：METR，Parker Whitfill、Cheryl Wu、Joel Becker、Nate Rush
  • 时间：2026 年 3 月

一、SWE-bench 的分数到底说明了什么

SWE-bench Verified 的题来自真实的 GitHub issue：把代码回退到修复前，让 AI 去修，再用仓库原有的单元测试判断修得对不对。过去两年，它几乎是衡量 AI 写代码能力的头号指标。

但在真实的开源项目里，代码进主分支要过的是维护者这一关。维护者要看的不只是测试过没过，还有：
  • 问题是不是真的解决了
  • 有没有弄坏别的地方
  • 写法符不符合项目的规范，以后好不好维护
METR 想知道的是：那些通过了测试的 AI 代码，拿给真正的维护者看，会有多少被收下？

二、实验怎么做的？
  1. 请真正的维护者：从 SWE-bench 涉及的仓库里，找到 4 位活跃维护者：scikit-learn 2 位，Sphinx 和 pytest 各 1 位。按小时付费；如果同行认为他们的评审质量高，还有额外奖金。
  2. 只审通过测试的补丁：从 5 个模型的运行结果里（Claude 3.5 Sonnet、3.7 Sonnet、Opus 4、Sonnet 4.5，以及 GPT-5），挑出已经通过自动评分的补丁，共 296 个，覆盖 95 个 issue。
  3. 盲审：在 GitHub 上像平时审 PR 一样评审，维护者不知道补丁是谁写的。每个补丁给出：接受还是要求修改、拒绝原因、离可合并还差多少（0 到 100%）。
  4. 用人类补丁做基线：评审里还混进了 47 个当年真正被合并的人类补丁。结果维护者这次只收了其中约 68%。

第 4 点是这篇研究里最值得学的设计。维护者本身就有噪声：同一段当年被合并的代码，换个时间、换个人看，也可能被要求修改。所以作者不直接报告 AI 补丁的合并率，而是除以人类补丁的合并率。比如 AI 的原始合并率是 34%，人类基线是 68%，换算后就是 50%。

另外，这次评审对 AI 其实是宽松的：没有跑 CI，也让维护者忽略「有没有补测试」这类要求。所以下面的差距，更可能是低估，而不是高估。

三、关键发现
1. 约一半通过测试的补丁，维护者不会合并
扣掉维护者自身的噪声后，自动评分器的通过率，平均比维护者的合并率高出 24.2 个百分点。换句话说，通过测试的 AI 补丁里，大约一半不会被合并。
图源：METR, Many SWE-bench-Passing PRs Would Not Be Merged into Main, Figure 1。橙色是自动评分器的通过率，蓝色是维护者的合并率，都已换算成人类补丁基线的百分比

每个模型的蓝点都明显低于橙点。差距最大的是 GPT-5：测试通过率在 65% 左右，维护者合并率不到 30%。

三个仓库都有差距，pytest 最大，达到 43.1 个百分点。作者还看了趋势：模型越来越新，维护者合并率的提升速度比测试通过率慢了约每年 9.6 个百分点，也就是图里两条线越拉越开。但这个趋势的统计显著性较弱，作者自己也说结论不稳。

2. AI 能独立完成的任务长度，被高估了好几倍
METR 有一个常用指标叫「时间视野」：一个模型有 50% 把握完成的任务，相当于人类专家多少分钟的工作量。

按测试通过算，Claude Sonnet 4.5 的时间视野约 50 分钟；按维护者愿意合并算，只有约 8 分钟，相差约 7 倍。


3. 维护者为什么不收
作者把拒绝原因从轻到重分成四类：代码质量问题、其他问题、破坏了别处的代码、核心功能没有真正解决。
图源：METR, Many SWE-bench-Passing PRs Would Not Be Merged into Main, Figure 3。每根柱子从下往上依次是：被合并、代码质量、其他、破坏其他代码、核心功能没解决、没通过测试，加起来是 100%（未归一化的原始比例）

从图上大致读数：Claude Sonnet 4.5 约 31% 被合并，因代码质量被拒和因核心功能被拒各约 17%，没通过测试的约 33%。GPT-5 只有约 18% 被合并，因代码质量被拒的却接近 29%，是五个模型里最高的。

代码质量问题长什么样？下面是 pytest 维护者的一条真实评审意见：
图源：METR, Many SWE-bench-Passing PRs Would Not Be Merged into Main, Maintainer Review Example 1

翻译过来是：「同样的代码在别处已经出现过（至少第 92 行），应该抽成一个可复用的函数。」功能没错，测试也能过，但任何一个认真的维护者都不会这样合进去。

这里有一个很有意思的观察：模型的进步，很多发生在「从功能错误变成只剩代码质量问题」。 从 Claude 3.5 Sonnet 到 3.7 Sonnet，通过测试的补丁变多了，但被指出核心功能有问题的也变多了；从 3.7 Sonnet 到 Opus 4，通过率没怎么涨，但失败原因从功能问题转向了代码质量问题；到 Sonnet 4.5，提升主要在代码质量。同期的 GPT-5，代码质量明显弱于 Claude。

也就是说，测试分数和维护者看重的东西，是两条不同的进步曲线。 只看测试分数，你看不到第二条。

四、实验结论
1. 测试是「能跑」的裁判，不是「好」的裁判
模型优化的是你测量的东西。测试能检查功能，检查不了风格、范围、可维护性，也检查不了「有没有顺手弄坏别的地方」。

METR 自己也提到，这个差距也许能部分解释他们去年的另一项发现：资深开源开发者用了 AI 之后，完成任务反而慢了约 19%。代码写出来很快，但要改到能合并，还得花时间。

2. 评估者也需要基线
「人类当年真正合并的代码，这次也只收了 68%」这个数字，比主要结论更值得记住。它说明：专家评审本身有噪声，不能当成绝对标准。

这篇研究的处理方式值得借鉴：
  1. 把人类作品混进去一起盲审，测出评审者自己的「挑剔程度」
  2. 用这个基线去归一化结果
  3. 给评审者的评审质量打分，并和报酬挂钩

3. 代码评测正在从「对不对」走向「能不能被团队接受」
这篇研究之后，行业已经开始跟进。据 Latent Space 报道，Cognition 在 2026 年 6 月推出了 FrontierCode：和开源维护者一起出题，每道题投入 40 多个小时，从回归安全、整洁度、改动范围、测试正确性、可维护性等维度打分。在最难的子集上，最强模型只有约 13%。在 SWE-bench 式的评测上，这些模型通常能拿到 50% 以上。

可合并性比能不能跑难评得多，因为它依赖懂这个项目的人。代码评测最贵、最稀缺的部分，又一次落在了专家判断上。

这篇研究给了我们三条可以直接用的做法：
  1. 请懂行的人按「维护者标准」审代码：问题是否真正解决、是否破坏其他部分、是否符合规范、以后是否好维护，而不只看能否运行
  2. 把已知的好作品混进去当基线：校准每位评审者自己的标准松紧
  3. 评审者也要被评审：评审意见的质量，要被同行和事后结果检验
能跑是门槛，好代码才是作品。

Relia｜Where frontier AI teams meet researchers and builders.
Relia 是面向 AI 研究型人才的招聘平台，连接前沿 AI 团队和 AI 硕博研究者、builder，我们覆盖的方向：

大模型：预训练 / 后训练 / 评测
智能体：Agent 算法与开发
具身智能：多模态、具身、机器人
AI Infra：推理系统、AI 芯片
量化金融：数据挖掘、交易系统
AI4Science：药物发现、蛋白质、科学智能体

🙋 求职者：在 Relia 浏览前沿岗位，一键直投 
🏢 招聘方：免费发布岗位，触达全球 AI 人才 
🌐 https://www.relia.ai/（阅读原文）
🤝 专家招募 / Benchmark合作：dylanmiao7

【声明】内容源于网络
0
0
经纬出海
1234
内容 23
粉丝 0
经纬出海 1234
总阅读1.1k
粉丝0
内容23