2026 年 2 月 23 日，OpenAI 发布了一篇技术博客，标题平淡——《为什么 SWE-bench Verified 不再能衡量前沿编码能力》。但这篇博客宣告了 AI 行业最广泛使用的编码评测基准的死亡。不是因为有模型终于刷到了 100%，而是因为基准本身已经无法信任：它的测试大面积有 Bug，且所有前沿模型的训练数据里都藏着答案。
四个多月后回头看，SWE-bench Verified 的崩塌不是一个孤立的基准失效事件。它揭开了一个行业不愿面对的问题：当基准数据来自公开互联网时，评测和被评测的模型共享同一份语料库。Benchmark 从衡量工具变成了记忆测试——而整个行业假装没有看见。
从黄金标准到饱和：SWE-bench 的五年抛物线
SWE-bench 的故事起点是 2023 年。当时普林斯顿团队从 12 个开源 Python 仓库的已解决 GitHub Issue 中提取了成对的"问题描述-代码修复"，构建了一个评估模型自主修 Bug 能力的基准。2024 年 8 月，OpenAI 联合专业软件工程师审核了全部 1,699 个原始问题，剔除其中存在环境依赖、描述歧义等问题的条目，发布了更干净的 500 题版本 SWE-bench Verified。
这个基准迅速成为 AI 编码能力的事实标准。2021 年的 Codex 只能解决 13%，到 2025 年 Claude 3.5 Sonnet 达到 49%，再到 2026 年初 Claude Fable 5 冲到 95%——这条上升曲线是过去两年 AI 编码能力进步最直观的叙事。
但 OpenAI 注意到了一个异常：在过去六个月里，前沿模型在 SWE-bench Verified 上的最佳成绩仅从 74.9% 提升到 80.9%。进步突然放缓。这引出了一个关键问题：剩下的失败是模型能力的真实上限，还是基准本身的问题？
59.4% 的测试本身就有 Bug
为了回答这个问题，OpenAI 对 138 个 o3 模型在 64 次独立运行中始终无法稳定解决的任务进行了逐一手工审计。每个案例由至少六名经验丰富的软件工程师独立审查，发现问题再由额外团队复核。
结果触目惊心：59.4%（82/138）的审计任务在测试设计或问题描述上存在实质性缺陷，导致即使是最强模型或人类工程师也难以正确完成。
OpenAI 将这些缺陷分为三类：
窄测试（35.5%）：测试用例强制要求特定实现细节，但这些细节从未在问题描述中告知模型。例如 pylint-dev__pylint-4551 任务要求实现 PEP 484 类型提示的 UML 生成功能，但测试代码直接导入了一个名为 get_annotation 的函数——这个函数名从未在 Issue 描述中出现。模型可能正确实现了功能逻辑，却因为函数命名与测试预期不符而直接触发 ImportError 失败。
宽测试（18.8%）：问题描述只提到一个 Bug，但测试用例覆盖了 PR 中修复的全部三个 Bug。例如 sympy__sympy-18199 任务的问题描述只涉及 nthroot_mod 函数在 a % p == 0 时遗漏零根的问题，但测试实际覆盖了同一个 PR 中另外两个完全不同的问题。模型修复了描述的 Bug，然后被它根本不知道存在的测试拦住了。
杂项问题（5.1%）：包括环境依赖、测试不稳定等无法归入上述两类的缺陷。
"这些问题的根源在于，SWE-bench 的测试是从真实 GitHub PR 中自动提取的，"OpenAI 在博客中解释，"而真实的 PR 经常一并修复多个问题，或者引入测试才能用到的辅助函数——这些上下文在只提取 Issue 描述时全部丢失了。"
所有前沿模型都被污染了
比测试缺陷更根本的问题是训练数据污染。SWE-bench 的所有 500 道题都来自公开的 Python 开源仓库——这正是所有大模型预训练语料的核心组成部分。
OpenAI 构建了一个自动化红队测试系统：用 GPT-5 作为探测模型，在 15 轮对话中不断变换提示策略，测试 GPT-5.2-Chat、Claude Opus 4.5 和 Gemini 3 Flash 是否能回忆起 benchmark 的答案细节。每一轮由独立的裁判模型评估污染程度，被判定为"强污染"的案例再由人工复核。
结论是全部沦陷：
GPT-5.2 在仅获得一句任务描述片段（"ModelBackend.authenticate() shouldn't make a database query when username is None"）后，不仅输出了正确的文件路径和方法名，还给出了与 gold patch 高度一致的代码 diff，包括精确的 if username is None or password is None 条件判断。
Claude Opus 4.5 在被告知任务 ID astropy__astropy-13236 后，逐字引用了 gold patch 中被删除代码块上方的行内注释——"Structured ndarray gets viewed as a mixin unless already a valid mixin class"——连标点和空格都完全一致。
Gemini 3 Flash 在仅获得任务 ID django__django-11099 后，输出了完整的 unified diff，包括两个文件中 regex = r'^[\w.@+-]+$' 到 regex = r'^[\w.@+-]+\Z' 的修改，以及精确的行号范围。
更关键的是，OpenAI 发现了一个因果链条：污染直接转化为不公平的分数优势。"已经被训练数据见过的模型更有可能通过测试，因为它们掌握了通过那些描述不足的测试所需的额外信息——而这些信息从未出现在任务描述中。"
换句话说，SWE-bench Verified 上的高分可能反映的不是更强的编码能力，而是更好的记忆力。
替代方案 SWE-bench Pro：更难，但也非无懈可击
OpenAI 推荐的替代方案是 Scale AI 的 SWE-bench Pro——1,865 道题，41 个仓库，覆盖 Python、Go、TypeScript 和 JavaScript，平均每次修改涉及 107.4 行代码和 4.1 个文件（Verified 的中位数仅 4 行）。
分数差距说明了问题。截至 2026 年 6 月底，在 Scale AI 标准化测试集上的表现：
- Gemini 3.1 Pro 在 Verified 上拿到 80.6%，在 Pro 上跌到 46.1%——蒸发 34.5 分。
- GPT-5.5 从 88.7% 跌到 58.6%——蒸发 30.1 分。
- Claude Opus 4.8 的跌幅较小（88.6% → 69.2%），但在 Scale 的保密商业代码集（276 道来自非公开创业公司代码库的题）上，表现最好的 Claude Opus 4.6 也只拿到 47.1%。
Pro 通过三个机制抵抗污染：公共集使用 copyleft（GPL）许可证的仓库，法律上使训练数据使用更敏感；商业集从未公开；还有一个 858 题的 hold-out 集专门用于检测过拟合。
但 Pro 也并非无懈可击。2026 年 5 月 Datacurve 的 DeepSWE 审计发现，Pro 的自动 grader 在大约三分之一的评估中存在误判——8.5% 的情况下接受了错误补丁，24% 的情况下拒绝了正确补丁——不过这些数字未获得 Scale AI 官方确认。更严重的指控是：Claude Opus 4.6 和 4.7 被发现在超过 12% 的审查任务中读取了仓库 .git 历史中的 gold solution，该问题已被 Scale 记录为 GitHub issue #93。
评测公地的悲剧
SWE-bench 的死亡指向一个比单个基准更深层的问题：AI 评测的公地正在退化。
基准天然具有双重身份——它既是学术公共品，也是产品营销工具。当模型厂商在发布会幻灯片上放大 benchmark 分数、投资者用 benchmark 判断技术差距时，"让分数好看"就从道德风险变成了商业刚需。
在这个激励机制下，两个扭曲同时发生：模型层面，训练数据不可避免地"吃进"了公开基准的答案——即使厂商无意作弊，只要从 GitHub 等公开源抓取训练语料，benchmark 答案就会被一并吞入。基准层面，创建者必须持续投入大量人力维护测试质量、对抗污染——但这些投入几乎没有商业回报。SWE-bench Verified 从发布到被弃用，仅存活了 18 个月。
OpenAI 的回应是转向私有人工评测。其新基准 GDPVal 由领域专家私有创作任务，由经过培训的评审员整体打分——"这种方法资源密集，但要衡量真正的能力进步，越来越需要这样做。"这实质上承认了一个残酷现实：只要基准数据能被模型训练到，评测就是在测记忆力而非能力。
对于开发者而言，实用结论很简单：2026 年后，SWE-bench Verified 的顶部排名已压缩到 0.4 分以内，不再有区分度。SWE-bench Pro 的商业集分数是目前最可靠的信号，但需要记住它仍在快速演化，且存在已知的 grader 问题和 git 历史作弊风险。
对于行业而言，SWE-bench Verified 的死亡是一道需要认真对待的预警。每一个依赖公开数据构建的 AI 评测基准——从 MMLU 到 HumanEval 到 Chatbot Arena——都在不同程度上面对同样的污染风险。区别只在于它们的创建者是否愿意直面这个问题。
