在人工智能编码能力评估领域，SWE-bench 系列基准曾被视为衡量模型解决真实软件工程问题能力的黄金标准。然而，2026 年初 OpenAI 的一篇技术博客彻底打破了这一共识 —— 该公司正式宣布停止报告 SWE-bench Verified 分数，并直言该基准已无法可靠反映前沿模型的实际编程能力。这一决策的背后，是数据泄露与测试设计缺陷的双重困境，它们共同导致了一个更为根本的问题：基准评测分数的膨胀与真实能力之间的鸿沟正在急剧扩大。
测试用例缺陷：59.4% 的问题根源
SWE-bench Verified 最初于 2024 年 8 月发布，旨在解决原始 SWE-bench 评估中存在的任务不可能完成的问题。OpenAI 组建了专家工程师团队，对 1699 个 SWE-bench 问题进行人工审核，每个问题由三名专家独立审查，最终筛选出 500 个问题形成 Verified 版本。这一筛选过程本应消除原有基准中的测试设计缺陷，但后续的深入审计揭示了一个更为严峻的现实。
在针对 138 个 OpenAI o3 模型在 64 次独立运行中未能一致解决的问题进行的审计中，OpenAI 发现至少有 59.4% 的受审问题存在测试设计或问题描述方面的实质性缺陷，使得这些任务即便对于最强大的模型或人类工程师也几乎无法解决。具体而言，35.5% 的任务包含所谓的「窄测试用例」，这些测试强制要求特定的实现细节，导致许多功能上正确的解决方案被判定为不合格。例如，在 pylint-dev__pylint-4551 任务中，PR 引入了一个名为 get_annotation 的新函数，但这个函数名并未出现在问题描述中，测试却直接导入它。许多模型可能正确实现了问题所要求的修复，却因为没有创建这个特定名称的函数而在导入阶段失败。
另有一部分任务存在「宽测试用例」问题，占比约 18.8%。这类任务的测试检查了问题描述中未涵盖的额外功能。以 sympy__sympy-18199 为例，该任务源于一个修复三个独立问题的 PR，但 SWE-bench Verified 的描述仅涵盖其中一个问题，测试却覆盖了全部三个问题。模型通常能正确实现描述中的修复，却随后因未实现其他两个问题的功能而失败。这种测试与问题描述之间的错配，本质上创造了一个不可能满足的条件 —— 即便模型完美理解了问题意图并给出了正确的解决方案，也无法通过测试。
训练数据污染：所有前沿模型均已「见过答案」
如果说测试设计缺陷还只是导致能力被低估，那么训练数据污染则走向了另一个极端 —— 它导致分数被系统性地高估。OpenAI 的分析发现，所有前沿模型都能够复现原始人类编写的 bug 修复补丁（即所谓的「金补丁」），或者逐字复现某些任务的特定问题细节。这一发现意味着这些模型在训练过程中已经见过这些问题和解决方案，它们并非在「考试」，而是在「回忆」。
这种污染的影响是深远的。当模型在训练时已经接触了问题的描述和解决方案，它就获得了额外的、解决问题所需的信息。OpenAI 指出，见过问题的模型更容易成功，因为它们拥有通过测试所需的额外信息 —— 即便这些信息从未在问题描述中明确给出。这就好比在考试前将试题和答案一起交给学生，虽然学生可能没有刻意记忆答案，但见过答案的学生肯定比没见过的学生表现更好。
OpenAI 通过自动化红队测试进一步量化了这一问题。他们使用 GPT-5 探测 GPT-5.2-Chat、Claude Opus 4.5 和 Gemini 3 Flash Preview 的污染情况。测试中，GPT-5 获得了 SWE-bench Verified 任务的 ID、描述、金补丁和 PR 测试，在 15 轮交互中尝试不同的提示策略来诱发目标模型泄露任务特定信息。结果显示，所有测试模型都存在不同程度的污染：给定任务描述的简短片段，GPT-5.2 就能输出精确的金补丁，包括具体的类名、方法名和新引入的早期返回条件；Claude Opus 4.5 不仅能回忆完整的四行功能变更，还能量出精确的文件名、方法名，甚至逐字引用 diff 中的内联注释；Gemini 3 Flash 在仅知道任务 ID 的情况下，就能输出问题描述和金补丁的详细内容，包括新的用户名验证正则公式和变更的具体行号。
基准复杂度的结构性错配
更深层的问题在于，SWE-bench Verified 的任务复杂度与当前前沿模型的能力之间存在结构性错配。在过去六个月中，SWE-bench Verified 的最优成绩仅从 74.9% 提升至 80.9%，进步速度明显放缓。这一现象引发了一个关键疑问：剩余的失败究竟反映了模型的能力上限，还是基准本身的设计缺陷？
答案是明确的：两者兼有，但基准的问题更为根本。当 59.4% 的受审任务存在测试设计缺陷时，任何模型在这些任务上的失败都不能准确反映其真实能力。同时，当所有前沿模型都能通过污染途径获得问题时，基准就失去了区分能力高下的能力。分数的提升不再代表模型软件工程能力的增强，而是越来越多地反映了模型在训练时对基准的接触程度。
这种错配的结果是灾难性的。OpenAI 坦承，他们发现 GPT-5.2 解决了 31 个被标识为几乎不可能完成的任务。在 django__django-14725 任务中，测试要求一个名为 edit_only 的新参数，但问题描述中并未明确要求此参数。GPT-5.2 在推理过程中展示了它拥有来自发布说明的代码库变更信息，并正确识别出 edit_only 参数是在 Django 4.1 中引入的。这种「作弊」能力使得模型能够在不真正理解问题的情况下给出正确答案。
行业应对与替代方案
面对这一危机，OpenAI 已采取行动。他们停止了在前沿模型发布中报告 SWE-bench Verified 分数，并建议其他模型开发者也这样做。作为替代方案，OpenAI 推荐使用 SWE-bench Pro 的公共部分。SWE-bench Pro 是该系列的更新版本，其实证研究表明受污染问题的影响较小。OpenAI 的污染检测管道在 SWE-bench Pro 中发现了一些污染案例，但这些案例显著少于 SWE-bench Verified，且没有任何模型能够输出完整的金补丁。
更重要的是，OpenAI 正在投资构建原创的、私有 authored 的基准测试。在 GDPVal 等基准中，任务由领域专家私有 authored，减少了暴露风险，解决方案由经过培训的评审者进行整体评分。这种方法虽然资源密集，但对于衡量真正的能力改进而言越来越必要。
基准设计的根本教训
从 SWE-bench Verified 的失败中，可以提取出基准设计的两个根本教训。首先，来源于公开材料的基准存在污染风险，训练数据暴露会悄然抬高分数。如果在基准构建中使用公开抓取的数据，模型开发者应进行额外的污染检测。基准及其解决方案一旦公开发布，就可能进入训练数据。需要在数据集发布方式（如密码保护）和训练数据过滤（如严格遵守 canary 字符串）方面格外谨慎。
其次，自动化评分很难做到完美。完美的测试用例应该完全验证正确功能，既要 agnostic 于不重要的实现细节，也要对捷径解决方案具有鲁棒性。这些问题本质上复杂且难以解决。OpenAI 发现这些问题需要多轮大量的人工标注工作。这提醒我们，基准评测不是一个一次性的工程任务，而是一个需要持续投入和迭代的复杂系统。
对于从业者而言，SWE-bench Verified 的案例提供了一个明确的警示：在使用基准分数评估模型能力时，必须保持审慎态度。分数应当被视为进步的指标，而非能力的确凿证明。随着模型能力的持续提升，基准设计也需要不断演进，以保持对真实能力的准确衡量。在那一天到来之前，SWE-bench Pro 和私有 authored 的基准测试是更为可靠的选择。
资料来源：OpenAI 官方博客《Why SWE-bench Verified no longer measures frontier coding capabilities》（2026 年 4 月）。