全行业盯了两年的编程能力榜，今天退役！OpenAI 停用 SWE-bench Verified：未来标准将看 AI 能顶替多少程序员？

过去两年，行业几乎都盯着同一张榜单追分、比排名、算差距；但从今天起，这套玩法可能要告一段落了。

今天，OpenAI 正式宣布 SWE-bench Verified“退役”。几小时前，OpenAI 的开发者账号发推明确表示：SWE-bench Verified 将逐步退出舞台，已不再适合作为前沿编程模型的主要对标基准；官方更建议大家转向 SWE-bench Pro。

SWE-bench Verified 曾经几乎就是代码评测的“北极星”。OpenAI、Anthropic、Google，包括不少国内开源权重模型，都在同一张榜单上咬得很紧，领先优势往往只差零点几。

但 OpenAI 在最新分析中指出：剩余未解决任务本身存在多重问题，已经不值得继续追求、更不值得继续公布 Verified 成绩。其中最严重的一点是数据污染——几乎所有前沿模型（包括 OpenAI 自己的模型）如今都表现出“复现 SWE-bench 评估数据与解法”的能力，有时甚至只凭任务 ID 就能做到：

另一个原因则更“直白”：测试设计本身就不够可靠。OpenAI 认为，至少有 60% 的未解决问题，从题面描述出发就应该是无法被正确解决的——如果某个模型“解决了它们”，更可能意味着绕过了评测机制（也就是在“刷题 / 作弊”）。他们举的例子之一，是 SWE-bench 中针对 pylint 问题 #4551 的测试用例。

今天，Latent.Space 邀请了 OpenAI 的 Frontier Evals 团队一起解读了这次榜单更迭的原因，并对比了两个新旧不同测评榜的差异。

SWE-bench Verified 题目规模偏小、任务周期过短，90% 的问题对资深工程师来说一小时内就能完成。而 SWE-bench Pro（SuperBench Pro）的题目更大、更难、任务时间被明确拉长到“数小时甚至更久”，覆盖的仓库、语言和问题类型也明显更丰富；更重要的是，目前它还没有被刷爆，污染迹象远低于 Verified，至少在现阶段仍然能区分真实能力差异。

并且 Pro 也不是终点。任何公开榜单，最终都会被追平、被记住、被“学会”，然后再次失效。OpenAI 认为，关键不在于“换哪个榜”，而在于下一代代码评测到底该测什么——他们更希望看到真实世界使用层面的指标：AI 在现实中到底被用了多少、在多大程度上替代了人类工作、又在多大程度上是在增强人类、加速人类。

这个事件的意义，正如一位网友所说：“排行榜的噱头已经过时了！如今的优势在于溯源性、对抗性强的评估以及在生产环境中值得信赖的 Agent”。

这期嘉宾是 OpenAI 的 Olivia Watkins（Frontier Evals 团队）和 Mia Glaese（OpenAI 研究副总裁）。我们整理了这期播客的核心内容，供你快速了解这场“退役 + 换标”背后的关键逻辑。

Olivia： 我们的核心观点是：SWE Bench Verified 一直是这个领域用来衡量代码能力进展的“北极星”级基准之一。但最近我们发现，这个基准上的进展基本停滞了。

我们意识到，这是因为这个评测已经 饱和 了，同时也 高度被污染 了。所以在现阶段，它已经不能很好地衡量代码能力的真实提升了。

我们认为，整个领域应该逐步从它转向其他基准，比如 SuperBench Pro。

主持人：太有意思了。我经常开玩笑说，好像所有实验室都有个群聊，大家轮流把分数往上挪 0.1%，然后就开始说：“行吧，你现在是最强的代码模型了。”但到现在这个阶段，这种“领先”其实已经没什么说服力了。

Olivia： 是的，确实如此。

Olivia：SWE Bench Verified 本质上是对一个学术基准的“清洗”和重构。原始基准来自普林斯顿的一个研究团队，叫 SWE Bench。它的基本设定是：给一个 agent 一个真实世界的代码库，以及一个来自 GitHub issue 的任务，让它去解决问题，然后通过是否通过测试来评分。

在当时，这个基准迅速流行起来，因为整个领域几乎没有真正贴近现实世界的软件工程评测。

但当 OpenAI 把这个基准纳入我们 preparedness framework 中的评测体系后，我们开始发现：很多 agent 的失败，并不是因为模型“太笨”，而是因为问题本身的设置就有问题。

于是 OpenAI 启动了一次规模非常大的人工数据项目，雇佣了将近一百名真实世界的软件工程师，逐题审查这些任务：任务是否描述清晰？测试是否公平？最终我们构建了一个经过严格筛选的、约 500 个任务组成的高质量子集。

Mia： 真的很难夸大这个过程的投入规模。很多经验丰富的软件工程师，对同一道题进行了多轮、逐条的审查。基本上是三位不同的专家独立做出判断。

Mia： 但我们必须这么做。因为这类任务真的非常复杂。你不仅要看问题描述和补丁，还要把它放到整个代码库上下文中去理解，无论是人类还是模型，都是在这个上下文中完成任务的。所以三轮审查是必要的。甚至事后看，也许我们还应该做更多，但即便如此，那已经是非常巨大的投入了。

Mia： 是的。这和我们通常发布评测不太一样。一般我们会加入 canary strings，来检测是否被训练数据“记住”。但当你使用的是开源 GitHub 仓库的数据时，是不可能插入 canary 的。

而且很多题目来自非常流行的项目，比如 Django，你在 GitHub 各处都会看到这些代码片段反复出现。

Olivia： 对。有一个例子是，任务要求 agent 实现一个功能，但问题描述中并没有提到某个参数，而测试却会检查这个参数是否存在。但在 GPT-5.2 的推理过程中，我们看到模型直接推理说：“我记得在这个仓库的后续版本中实现过这个参数，我或许应该加上。”

这类测试，如果没有这种“污染知识”，几乎是不可能通过的。

Mia： 这其实触发了一次更大规模的调查，不只是针对自家模型，也包括市面上的其他前沿模型，去理解整个行业的污染程度。

Olivia： 这部分主要是团队里其他同事完成的。我们做了一项分析：这些测试本身是否公平？方法是先挑出那些模型始终无法稳定解决的问题，然后再让大量人类工程师做一次深度审查。

Olivia&Mia： 不完全一样。这不是原始 Verified 的那套流程，而是一次更深入的调查：这些“谁都解不了”的问题，是因为模型不够聪明，还是因为问题本身就有根本性缺陷？

结果非常明确。在被深入调查的问题中，超过一半都存在问题。最常见的情况是：测试过于狭窄。 测试期待某个具体实现细节，但问题描述里根本没有要求这一点。比如，有的任务要求你实现一个功能，但测试要求你必须用某个特定的参数名或函数名。如果你用了另一个完全合理的命名方式，测试就失败了。

还有一类问题是：测试检查了一些问题描述里从未提及的“额外功能”。这意味着，通过测试当然说明你做得很好，但没通过测试，并不代表你的实现不好。只是评测只接受了极其狭窄的一小部分解空间，而忽略了大量同样正确、同样高质量的实现。

Olivia&Mia： 确实如此。但说实话，在抽象层面发现问题，比起对着一个非常聪明的 agent 的“最佳努力解”来审视，要难得多。

而且我想强调的是：在当年发布时，SWE Bench Verified 是一个非常强的基准。它确实教会了我们，也教会了整个行业很多东西。

但这几乎是所有成功基准都会经历的生命周期：一开始，模型只能做到 20% 甚至更低的正确率，大家能清楚地看到进步空间；等到性能接近天花板后，0.1% 的提升就变得毫无意义。

现在的问题是：在当前这个阶段，这个基准测量的已经不再是我们真正关心的东西——也就是 agent 的代码能力，而更像是在测量模型是否能“猜中”某个特定函数该叫什么名字。

Olivia&Mia： 这个真的很难说。比如在 GPT-5.2 发布之后，我们回头去看，发现它（模型）解出了大概 31 个 属于那种“如果没有污染，应该非常难解出来”的题目。所以我觉得很有可能：如果完全没有污染的话，那个数字（天花板）其实我们可能 早就已经达到了。

Olivia： 第一点很直接：它更难。SWE Bench Verified 里大概 90% 的题，估计一个资深软件工程师不到一小时就能完成。它们通常都很清晰、很自包含、规格也写得很完整。

但 SuperBench Pro 的题目整体更大、更难，而且评测还有更大的提升空间，因为它还没饱和。

Olivia&Mia： 是的。另外它也更多样：仓库更多、语言更多、题型也更丰富，定性上就能感觉到问题类型更不一样——这些都很棒。

从“污染”角度，我们也认为它更好。我们之前衡量 SWE Bench Verified 的污染，用的是一个小工具：我们做了一个“污染审计（contamination auditor）agent”。这个 agent 会拿到任务描述、patch、任务 ID，然后让它去“审问”目标模型——用一组开放式问题，尽量诱导出模型可能藏着的污染线索。

在 SWE Bench Verified 上，我们在很多模型里都看到了污染迹象：包括 OpenAI 自家的模型，也包括像 Claude 4.5、Gemini Flash 等。

我们看到的现象包括：模型会 复述（regurgitate）标准答案，甚至有时会吐出 任务 ID 之类的东西——这至少说明它对相关仓库（repositories）有明显的熟悉度。

比如它直接给出任务 ID，那种就很离谱。

但在 Pro（SuperBench Pro）上，我们目前没看到这种情况。污染审计 agent 只找到了一点非常轻微的迹象：可能有少数模型对一两个源仓库“略微熟悉”，但这和 SWE Bench Verified 的情况完全不是一个量级。所以从污染角度看，确实更好。

不过我们也应该预期：再往后，总有一天它也会变得不再合适。作为一个领域，我们必须持续向前走，去找更难、也更具代表性的问题，作为我们能力的锚点。

Olivia： 我觉得其中一个方向是：开放式的设计决策。也就是问题可能有点“没写死”，看模型能不能做出合理的设计选择。

Olivia： 当然。举个例子：你让它想办法把代码库某一部分提速。但提速的路径可能不止一种。

Mia： 我觉得人们在和软件工程 agent 协作时，会在意非常非常多的东西。SWE Bench Verified 显然衡量了一些重要能力——比如给你一个 GitHub issue 的描述，你能不能产出一个 patch，把问题解决到令人满意的程度。

它确实测到了模型的一个真实能力，只是由于基准本身的各种问题，当我们已经到 80% 的时候，我们不太信任再往上那一点点提升是否真代表能力提升。

但现在作为一个领域，我们正在超越“我的 coding agent 能不能帮我解决一个小的 GitHub issue”这种层级。我们开始关心的是更长期的任务：不是 15 分钟搞定，而是可能要花 一小时，有时甚至是 几天，以及更久。

再进一步，除了“它能解决什么任务”，还有一些更难量化的东西：比如它有没有设计品味（design taste）？它解决问题的方式是不是符合我团队一贯的风格？再比如：代码写得“好不好看”？是否清晰、干净？未来是否可维护？

这些也许更“不那么可触摸”、更难评测，但对真正和 coding agent 一起工作的开发者来说，意义非常大。

Olivia：GDP Eval 是一个评测，由人类数据团队和 Frontier Evals 团队合作完成，目标是衡量 agent 能否完成各种真实世界的白领工作。这个评测的评分非常难，因为需要大量领域知识：在不同情境下，你到底要“看”什么，什么才算好。

Olivia： 也正因为它很难、需要很多领域知识，人类数据团队雇了很多来自这些职业的人，深度参与任务设计、标准答案（gold solutions）的制作、rubric（评分规则）的制定等等，才能把它做出来。

Mia： 我觉得这是个很有意思的方案。你指出了一个关键问题：到底“现实感”应该多强？我们希望 coding agents 写出来的代码，是我们认为“好”的代码。让人类来评审，确实是确保这一点的好方法。但它也会更慢、更复杂。

这也是为什么 SWE Bench Verified 当年会那么流行，以及为什么类似基准会这么流行：它很简单——甚至可以更简单。只要验证“测试全过”，基本就是一键跑出来的：对还是不对，然后你就能汇总统计，快速对比。

但它不会告诉你：它是不是把问题“解决得漂亮”？代码是不是很丑？如果你是那个开源项目的 maintainer，你会不会愿意 merge 这个 PR？它回答不了这些。

尽管如此，“易于跨行业比较”和“能快速运行、无需人工参与”这两点，仍然非常有价值。

Olivia： 抱歉，你的问题是：我们是否也应该为“自我改进能力”构建评测？还是你在问，现在的代码评测有没有覆盖到这一点？

Olivia： 对。我猜很多基准到现在还没太聚焦“AI 代码”，主要原因是数据集很难收集。最先进的 AI 代码库很多都是私有的。如果我们为那类东西做 eval，很可能也没法公开发布。这样一来，外部领域就很难做同类对比，也很难衡量“这是不是一个现实的研究编码工作流”。

但我确实认为，公开地衡量这些技能，对整个领域是有益的，只是更难把它做得足够真实。

Mia： 我觉得从某种意义上，这些是在用不同的尺度衡量同一件事。

如果你说“它能产生多少价值（多少钱）”，这和说“这个问题让人类来做需要两小时”其实差不多。通常它们是高度相关的：一个人类解决这个问题要花多少时间，往往就决定了我们会给解决方案赋予多大的价值。

所以我认为一个很重要的维度是：我们能够把 agent 托付给多复杂、运行时间多长的任务？这些任务到底能有多“长”、多“重”、多“复杂”？这件事本身非常关键。

所以我觉得这是一个很重要的点。但无论是用金钱价值、时间，还是复杂度来衡量，本质上它们都是在试图捕捉同一件事。

Mia： 是的，我们当然知道那套评测，而且我们也和 METR 在这些评测上有合作，所以我们是非常认可它们的。

他们主要是用时间作为度量，而不是用金钱。

我想这正好呼应你刚才的问题。我认为“复杂度”——不管我们用什么方式去量化——对于理解我们正在走向什么样的能力水平、什么样的市场阶段，都是非常重要的。

Olivia：Preparedness Framework 是一个公开的框架，用来说明我们如何追踪前沿风险（frontier risk）。这些风险通常来自一些双用途能力：它们既可以被用于好的事情，也可能被用于坏的事情。我们希望至少能持续监测潜在的负面使用，确保我们作为一家公司、以及整个社会，都能为可能出现的风险做好准备。

目前我们主要追踪三大类能力风险：第一类是生物安全风险（biorisk）；第二类是网络安全（cybersecurity）；第三类是研究自动化与模型自治（research automation & model autonomy）。这第三类正是和代码评测联系最紧密的地方。代码并不等同于研究自动化，但它是其中一个非常关键的组成部分。

所以我们最初创建 SWE Bench Verified，就是作为“模型自治”这一工作流中的一部分评测手段。而现在，我们认为必须继续向前，去评估模型是否真的开始自动化完整的研究工作流。

Mia： 我觉得我最想说的一点是：我们真的非常珍惜整个社区的参与。我们投入了大量精力去构建这些评测，这也是为什么我们会在这个框架下发布 Verified、分享 GDP Eval 等成果。同时，我们也非常鼓励整个领域去共同构建、分享、复用评测。

像 SuperBench Pro 这样，如果它是一个更好的评测，那我们就应该用它。

我非常希望大家能探索更多方式，去创建并共享 eval，让我们以及整个领域，都能更好地衡量不同能力维度上的进展——包括代码能力，因为理解我们现在到底处在什么位置非常重要。

Olivia： 我觉得有几类东西会非常有价值。

第一，是真正非常非常难的任务——那种需要顶尖工程师花几个月、或者一个团队花几周才能完成的事情。如果这些任务的评分是可靠的，而且有经过领域内多方验证的 rubric（评分标准），那会非常有价值。

第二，是端到端产品构建 类的基准。随着越来越多人在用 agent “直接出产品”，这类 benchmark 会变得越来越重要。

第三点，也许不完全算是 eval，但我认为和我们的整体使命高度相关：我希望看到更多真实世界使用情况的指标——AI 在现实中到底被用了多少？在多大程度上替代了人类工作？ 在多大程度上是在增强人类、加速人类？这些真实世界指标，本身非常重要。

Olivia： 我不太方便具体说接下来会发布什么，但从大的方向上来说，肯定会更多关注 真实世界影响——真实使用、真实吞吐、真实效果这类东西。

主持人：太棒了。我也非常期待你们在“真实世界影响”这条线上继续推进。

参考链接：

https://www.youtube.com/watch?v=0HaUD_olwQU

https://x.com/latentspacepod/status/2026027529039990985

声明：本文为 InfoQ 翻译整理，不代表平台观点，未经许可禁止转载。