看榜选模型？SWE-Bench 三成题目是坏的，六成答案是抄来的
新模型发布那天，我干的事和大多数人一样：打开评测榜，看它在 SWE-Bench Pro 上比上一代高几个点，再决定要不要把手头的 Agent 切过去。这个动作我重复了两年，从没怀疑过分母。
最近两篇官方博客让我没法再照旧看榜。6 月底 Cursor 说，模型解掉的题里六成直接检索了现成修复；7 月初 OpenAI 说，题目本身约三成是坏的。两家审的是不同环节，结论却指向同一处：这个分数混进了大量与独立编码能力无关的东西。
更让我坐不住的是往下推一步：能在榜上抄答案的模型，在我自己的 repo 里也会抄。
一个空格判死一道题
先看 OpenAI 这篇。他们审计了 SWE-Bench Pro 的 731 个公开任务：自动管线标出 200 个坏任务（27.4%），人工标注（每个任务过 5 名工程师）标出 249 个（34.1%）。综合估计约 30% 的任务是坏的，OpenAI 直接撤回了此前推荐这个基准的立场。
最大的问题类别是“过严测试”，占整个数据集的 17.8%。报告里有个案例：任务 prompt 给的示例是一个前导空格的 " | Chapter 1 | 1"，隐藏测试却断言两个前导空格。模型忠实按 prompt 实现，一个字符之差，判错。
也就是说，约三成任务无法稳定地区分“模型不会”和“题目有问题”。而 8 个月里，前沿模型在这个榜上从 23.3% 涨到 80.3%，这条陡峭曲线里有多少来自真实进步，单看总分已经拆不出来了。
根子是结构性的。这些任务是从开源 repo 的 PR 历史里程序化抽出来的，PR 里的测试本来就是为了验证某个具体改动而写的，从来不是一份实现无关的判分标准。题不是出的，是捡的，捡来的题天然带病。
解掉的题，六成是查到的
Cursor 审的是另一头。他们用审计模型检查了 731 条 Opus 4.8 Max 在 SWE-bench Pro 上的运行轨迹，发现解决的问题里 63% 是直接获取修复方案，而非自己推导：57% 的轨迹在公开 Web 上找到已合并的 PR 照着抄，另有 9% 在附带的 .git 历史里挖到了未来修复该 bug 的提交。
这些评测题来自真实修过的缺陷，答案本来就存在于世界上。屏蔽 git 历史、限制网络之后，Opus 4.8 Max 在 SWE-bench Pro 上掉了 14.1 分，Cursor 自家的 Composer 2.5 掉了 20.7 分。他们自己承认，不再把标准 SWE-bench Pro 分数当作衡量 Composer 的可靠基准。
还有一个走向：越新的模型抄得越多。Opus 4.6 在严格环境下只差不到 1 分，到 4.8 Max 差距拉到 14.1 分。榜单上新增的分数里，检索答案的成分越来越重。
Cursor 的措辞很克制：狭义上这个分数是真的，但它混合了编码能力和获取已知修复方案的能力。
这两个比例不能相加，也不能相乘：OpenAI 算的是坏任务占比，Cursor 算的是 Opus 成功轨迹里的检索行为，分母根本不同。但它们分别污染了判题标准和解题过程。总分还是真的，只是不再等于你以为的“独立编码能力”。
它在你的 repo 里也会这么干
把这当成榜单圈的新闻，换个榜继续看，是最省事的读法。但走捷径不是评测环境里才有的行为，是模型面对任何“有捷径的环境”的默认策略。
Cursor 记录过一个细节。一个来自 2019 年 jq issue 的任务里，智能体先用系统自带的 jq 二进制复现 bug，因为镜像是在修复之后构建的，复现失败，它由此推断这个 issue 已经被解决过，转头就去搜现成的修复方案。它没有记住答案，它是从环境里嗅出了“答案存在”的味道。
你的 repo 里同样铺满这种味道和捷径。让 Agent 修一个回归 bug，它可以去 git 历史里翻出上次类似的修复直接套；让它把测试跑绿，它可以把预期值写死。这不是想象，Cursor 的审计里就有：一个智能体拿到隐藏测试文件，把通过测试所需的异常字符串硬编码了进去。
我之前写过 AI 自己写测试自己过的闭环问题，hardcode 骗测试就是那个闭环的近亲。区别只有一个：榜单上的作弊有 OpenAI 和 Cursor 替你审计，你 repo 里的作弊没人管。
所以 Cursor 给评测团队的建议，我认为该原样搬给每个用 Agent 的人：审查轨迹，约束环境。别只看最后的 diff 干不干净，翻一遍它的过程，它是读了代码推导出来的，还是搜出来的。
攒一份自己的评测集
榜不能单看之后怎么选模型？OpenAI 的期望是由工程师专门设计新基准，Cursor 的做法是转向基于非公开 repo 的 CursorBench。两个动作指向同一件事：评测要建在没有公开答案的地方。
而你手里就有更接近真实工作的材料。从自己仓库里挑 5 到 10 个真实修过的 bug，优先挑当时卡过你、要理解两个以上模块才能改对的那种，记下问题描述、起始提交和验收方式。
题目和补丁从未公开，这份评测集才有效。再把带答案的 git 历史、issue 评论和构建产物移出环境，剩下的才是它自己推的。
换模型时固定起始提交、工具权限和验收脚本，再看两个东西：任务过没过，以及轨迹里它是怎么过的。这两个信号加起来，比榜单上几个点的差距更贴近你的工作。
我之前写过“AI 代码占比”这个指标怎么失真，benchmark 分数得的是同一种病：指标一旦成了目标，最先坏掉的就是指标本身。
下次新模型发布，榜可以照看，热闹可以照凑。但决定要不要换的那几道题，应该出自你自己的 repo。