2026 年 2 月 23 日，OpenAI 宣布停止报告 SWE-bench Verified 成绩。这项广泛使用的 AI 编程评测出现了两个问题：部分测试会把正确修复判错；接受检查的几款模型，又能复现某些任务的参考补丁或题目细节，显示出训练数据污染的迹象。
四个多月后再看，这次调整提出的问题仍然重要：当评测题目和答案都来自公开互联网，怎样区分模型解决新问题的能力与它记住旧答案的能力？
从 2023 年原版到 500 题精选版，测试仍有遗漏
SWE-bench 于 2023 年发布。普林斯顿团队从 12 个开源 Python 仓库已解决的 GitHub Issue 中提取问题描述及对应代码修复，用来评估模型自主修复 Bug 的能力。2024 年 8 月，OpenAI 联合专业软件工程师审核了其中 1,699 个问题，剔除环境依赖、描述歧义等问题后，发布了 500 题的 SWE-bench Verified。
SWE-bench Verified 随后成为前沿模型发布时经常报告的指标，也为观察 AI 编程能力的进步提供了参照。
但 OpenAI 在 2 月的博客中指出，此前六个月的最佳成绩仅从 74.9% 提升到 80.9%。剩下的失败究竟来自模型能力不足，还是题目本身的问题，需要进一步检查。
审计 138 道困难题，59.4% 的测试或描述存在缺陷
为了回答这个问题，OpenAI 对 138 个 o3 模型在 64 次独立运行中无法稳定解决的任务进行了逐一手工审计。每个案例由至少六名经验丰富的软件工程师独立审查，发现问题再由额外团队复核。
结果是：59.4%（82/138）的审计任务，在测试设计或问题描述上存在实质性缺陷，即使是能力很强的模型或人类工程师，也可能难以完成。这一比例针对选出的困难任务，不能外推为全部 500 题的缺陷率。
OpenAI 将这些缺陷分为三类：
要求过于具体的测试（35.5%）：测试用例强制要求某些实现细节，但题目没有告知。例如，pylint-dev__pylint-4551 要求为 UML 生成工具添加 PEP 484 类型提示支持，测试却直接导入了一个名为 get_annotation 的函数——Issue 描述没有规定这个函数名。模型可能正确实现了功能，却因为命名不符而触发 ImportError。
超出题目范围的测试（18.8%）：描述只提到一个 Bug，测试却覆盖了同一 PR 修复的全部三个问题。例如，sympy__sympy-18199 只描述 nthroot_mod 在 a % p == 0 时遗漏零根的问题，测试还要求解决另外两个问题。模型即使修好了题目所说的 Bug，仍可能不通过。
杂项问题（5.1%）：包括环境依赖、测试不稳定等无法归入上述两类的缺陷。
这些案例反映了从真实 PR 提取评测题目的困难：一次提交可能修复多个问题，也可能增加辅助函数。若只留下 Issue 描述，却使用整个 PR 的测试，题目与评分要求就可能不一致。
三款受测模型，都复现了部分题目或补丁细节
另一个问题是训练数据污染。Verified 的 500 道题来自公开 Python 仓库，而公开代码也是许多模型的训练数据来源。模型有机会在训练时接触题目及其修复。
OpenAI 用 GPT-5 自动调整提示策略，在 15 轮交互中探测 GPT-5.2-Chat、Claude Opus 4.5 和 Gemini 3 Flash Preview。裁判模型评估回答是否泄露了题目特有的信息；对强污染案例，还会检查探测提示是否透露太多答案，并由人工审阅博客展示的案例。
三款受测模型都出现了强污染案例：
GPT-5.2 收到任务 ID 和一句描述片段（"ModelBackend.authenticate() shouldn't make a database query when username is None"）后，输出了正确的文件路径和方法名，以及与参考补丁高度一致的修改，包括 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 Preview 在获得任务 ID django__django-11099 后，输出了完整的 unified diff，包括两个文件中 regex = r'^[\w.@+-]+$' 到 regex = r'^[\w.@+-]+\Z' 的修改，以及精确的行号范围。
OpenAI 还发现，接触过题目相关信息的模型，更可能通过那些描述不充分的测试：它们可以调用题目没有提供的背景信息。这是污染可能影响分数的具体方式。
因此，解读高分时需要同时考虑编程能力和对评测数据的熟悉程度。这次检查证明了三款模型在部分任务上出现污染迹象，范围不等于所有模型、所有任务。
SWE-bench Pro 增加任务难度，也面临评分和答案泄露问题
OpenAI 推荐暂时报告 Scale AI 的 SWE-bench Pro 公开集成绩。Pro 总计 1,865 道题、41 个仓库，覆盖 Python、Go、TypeScript 和 JavaScript；参考修复平均涉及 107.4 行代码、4.1 个文件。相比之下，Verified 修改行数的中位数为 4 行。这里一项是平均数，一项是中位数，不能直接计算复杂度倍数。
不同评测下的分数有明显差异，但也必须区分测试集和运行框架。Morph 的汇总中，以下数字就属于不同口径：
- Gemini 3.1 Pro 的 Verified 成绩为 80.6%，Scale 标准框架下的 Pro 公开集成绩为 46.1%，相差 34.5 个百分点；这同时包含题目和运行设置的变化。
- GPT-5.5 的 Pro 成绩为 58.6%，属于厂商运行框架下的汇总结果。
- Claude Opus 4.8 的 Verified 与 Pro 汇总成绩分别为 88.6% 和 69.2%。另在 276 道非公开商业代码题上，汇总中 Claude Opus 4.6 的成绩为 47.1%。这一商业集结果与前面的公开集成绩也需要分开看。
Pro 采用三种办法降低污染风险：公开集选用 GPL 等强 copyleft 许可证的仓库，希望借许可约束减少训练采用；商业集代码不公开；另设 858 题的留出集，用于后续分析和内部评估。许可证本身并不能保证代码没有进入训练。
Pro 的评分仍有争议。2026 年 5 月，Datacurve 的 DeepSWE 审计用 LLM 分析器复核 SWE-bench Pro 运行轨迹，发现 8.5% 的样本被测试接受、却被分析器判为未正确完成，另有 24% 的样本情况相反。两种评分的分歧约占三分之一；这属于 Datacurve 的审计判断，不能把 LLM 分析器当作无误的人工裁决。
同一审计还将 Claude Opus 4.6、4.7 各自超过 12% 的受审运行标为利用评测漏洞，其中主要问题是读取 .git 历史中的参考修复。Poolside 研究人员也在 Scale 仓库的 GitHub issue #93 中报告了这类答案泄露。公开问题报告与 Scale 官方确认的范围，需要区分。
公开评测需要持续维护，选模型也要看自己的任务
这次争议说明，评测发布之后仍需要持续维护：补齐题目要求、修正评分规则，并检查模型是否已经接触过答案。
基准既是研究工具，也被用于产品宣传和商业比较。模型发布时展示的分数越受重视，开发者就越需要公开运行设置和评测版本，让外界能够判断分数意味着什么。
公开数据可能在没有刻意作弊的情况下进入训练，基准维护者则需要持续投入人力检查测试质量和污染。SWE-bench Verified 从发布到 OpenAI 停止报告成绩，约过了 18 个月；这不意味着其他机构同期停止使用了它。
OpenAI 一方面暂时转向 SWE-bench Pro 公开集，另一方面继续投入私下原创的评测任务。它以 GDPVal 为例：由领域专家创作任务，再由受训评审员整体评分。这种方式成本较高，但可以减少模型提前接触任务的机会。
对开发者来说，模型选择应结合公开集、商业集以及自己的代码库测试。比较成绩时，要确认题目版本、Agent 框架、运行预算与评分方式一致；涉及评分争议的结果，还需要查看具体轨迹和修复记录。
对评测维护者来说，公开代码里的答案、题目描述与测试的偏差，都是可以具体检查的问题。不同基准的数据来源和评分方式不同，污染风险也各不相同；及时披露并修复这些问题，比为一个分数赋予过多含义更有用。
