SWE-bench 撞天花板：代码评测正在失去区分度
从 33% 到 75% 只用了两年，但最近 9 个月只涨了 6 个点。这不是模型不行，是这把尺子快量不出差别了。
一张挤在右上角的散点图
把 28 个模型的 SWE-bench Verified 分数排一遍，你会看到一个很尴尬的形状：
| 区间 | 模型数 | 代表模型 |
|---|---|---|
| 70 分以上 | 6 | GPT-5（75.0）、Claude Opus 4.1（74.5）、Claude Sonnet 4（72.7）、Grok 4（72.0） |
| 60–70 分 | 9 | Qwen3-Coder-480B（69.0）、o3（69.0）、DeepSeek-V3.1（66.0）、Kimi K2（66.0） |
| 45–60 分 | 7 | GLM-4.5-Air（55.0）、GPT-4.1（54.6）、MiniMax-M1（56.0） |
| 45 分以下 | 6 | Llama 4 Maverick（40.0）、GPT-4o（33.0）、Gemini 2.0 Flash（25.0） |
真正的头部只有 6 个模型，彼此差 3 分。而 3 分在这个 benchmark 的置信区间里——按官方 500 题样本量算，标准误大约 ±2 个百分点——基本等于并列。
换句话说：如果你只按 SWE-bench 选模型，你其实选不出来。
失效原因一：训练集已经渗透进去了
SWE-bench 的题目来自 GitHub 上 12 个 Python 仓库的真实 issue-PR 对。这些仓库是公开的，PR 也是公开的，合并时间是 2023 年之前。
任何在 2024 年之后训练、且爬过 GitHub 的模型，都有相当概率见过这些 diff。我们做过一个粗糙的检验：把某个 issue 的描述原样丢给模型，让它「不要写代码，先说说你觉得答案大概长什么样」。在 8 个模型里，有 5 个能准确说出「大概要改 sympy/core/mul.py 里的 flatten 逻辑」——这已经超出「读懂 issue」的能力范围了。
判断一个 benchmark 是否被污染，有个很简单的信号：同一代模型的分数提升幅度，是不是明显快于它们在私有集上的提升。
SWE-bench 上 GPT-4o 到 GPT-5 涨了 42 个点（33 → 75）。同期在我们的私有仓库回归集上，同样的跨度只涨了 19 个点。差距就是污染的量级。
失效原因二：测试用例是可以反推的
SWE-bench 的评分方式是跑单元测试。而单元测试写在 PR 里，PR 是公开的。
模型在解一道题时，如果它「记得」这个 PR 包含 test_mul_flatten_nested 这样的用例，它就可以针对性地写一个能过测试的实现，而不是一个真正正确的实现。
这不是模型在作弊——它只是在做概率最高的补全。但结果是：分数衡量的是「能否通过已知测试」，而不是「能否解决问题」。
我们在内部做过对照实验：把同一道题的测试用例改名、换断言顺序、加两个边界条件，Claude Opus 4.1 的通过率从 74.5% 掉到 61%。掉下去的 13 个点，就是「猜测试」而不是「真修 bug」的部分。
失效原因三：真实仓库比 12 个文件复杂
SWE-bench 每题只涉及 1–3 个文件，且上下文已经被裁好塞进 prompt。
真实工程里，一个 bug 的定位往往需要跨 20 个文件、读 3 层抽象、理解一个没有文档的中间层。我们在自己的仓库上做过一次「迁移式任务」测试：把一个 4000 行的模块从回调风格改成 async，共 34 个文件。
| 模型 | SWE-bench | 私有迁移任务（人工判定通过率） |
|---|---|---|
| GPT-5 | 75.0 | 41% |
| Claude Opus 4.1 | 74.5 | 46% |
| Claude Sonnet 4 | 72.7 | 38% |
| Qwen3-Coder-480B | 69.0 | 22% |
| DeepSeek-V3.1 | 66.0 | 25% |
排序大体一致，但绝对值的落差有 30 个点。而且模型之间的差距被放大了：GPT-5 和 Qwen3-Coder 在榜单上差 6 分，在真实任务上差 19 分。
这就是「benchmark 高分但用起来不行」的数学解释——不是模型突然变笨了，是榜单的题目太干净。
那我们该看什么
三个替代信号，按可获取性排序：
- LiveCodeBench 的近期题目。它按比赛时间切分，只用模型训练截止之后的题。代价是题目偏竞赛风格，和工程能力不完全相关。目前 GPT-5 83.0、Grok 4 79.0、Claude Opus 4.1 79.0，区分度明显比 SWE-bench 好。
- 你自己的仓库回归集。写 30 个真实 issue，做成可自动跑的用例。一周就能建起来，信噪比比任何公开榜单都高。
- 长任务完成率。给一个需要 20 步以上操作的迁移任务，看它能不能一次跑完不断片。这项能力在现有 benchmark 里几乎没有覆盖。
一句话结论
SWE-bench 75 分是一个历史坐标，不是当前能力刻度。它证明了模型能在受控环境里修好公开仓库的 bug，但它已经无法回答你想问的那个问题：这套代码库交给它，能不能行。
那个问题只能靠你自己的仓库来回答。