大家好，这里是最佳拍档。2026年2月24日，OpenAI通过其开发者官方账号正式发布公告，宣布将逐步停用被行业奉为编程能力北极星的SWE-bench Verified（一个用于评估AI编程能力的基准）评测基准，同时明确建议整个行业将SWE-bench Pro（一个由Scale公司发起的、更高级的AI编程模型评测基准）作为前沿编程模型的主要对标标准。这一消息在AI圈和软件工程领域引发了巨大关注，因为在过去的两年里，无论是OpenAI、Anthropic、Google这样的国际科技巨头，还是国内众多的开源大模型团队，都在SWE-bench Verified的榜单上展开了激烈的竞争，彼此的领先优势往往只有零点几个百分点。这份榜单也成为了市场判断各款AI模型编程能力的核心依据。而如今这份榜单的退役，背后不仅是评测基准本身的问题，更折射出AI编程能力发展到现阶段，行业对评测标准的全新需求。

SWE-bench Verified的困境：数据污染与设计缺陷

今天我们就来聊聊SWE-bench Verified停用的核心原因，以及行业头部公司对下一代AI编程评测的思考和布局。从OpenAI官方声明和随后的前沿评估团队核心成员的解读中，我们能找到两个核心且无法回避的问题：一个是数据污染，另一个是测试设计的根本性缺陷。这两个问题叠加，让SWE-bench Verified彻底失去了衡量前沿模型真实编程能力的价值。

先来说数据污染，这也是OpenAI认为最致命的问题。OpenAI在最新的分析中发现，几乎所有的前沿编程模型，包括OpenAI自己的模型、谷歌的Gemini、Anthropic的Claude等，都已经表现出了通过SWE-bench Verified的任务ID就能精准复现评测的原始标准答案和问题描述的能力，甚至在极少的提示下，就能一字不差地还原出评测中的黄金补丁。这种现象在行业内被称为复述（Repetition/Parroting），本质上说明这些模型并非通过自身的编程能力解决问题，而是在训练过程中记住了开源仓库中的相关数据，当遇到熟悉的任务ID时，直接调用了记忆中的答案。

那么，为什么数据污染会在SWE-bench Verified上表现得如此严重？这就要从SWE-bench Verified的诞生说起。SWE-bench Verified并不是OpenAI从零打造的一个评测体系。原始基准是普林斯顿大学一个研究团队开发的SWE Bench，这个基准的核心设定是给AI智能体一个真实世界的代码库，搭配一个来自GitHub issue的实际开发任务，让智能体解决问题后，通过是否能通过测试用例来评分。在当时，这个基准之所以迅速流行，核心原因是整个AI编程领域几乎没有真正贴近现实世界的软件工程评测标准，大多数评测都停留在简单的代码片段编写层面，无法反映模型在实际工程场景中的能力。OpenAI看到了这个基准的价值，将它纳入了自己的风险准备框架（Preparedness Framework: OpenAI的框架，旨在追踪和管理先进AI技术带来的潜在风险，特别是双重用途能力）评测体系中，但同时也发现了原始SWE Bench的许多问题。

为了解决这些问题，OpenAI启动了一项规模巨大的人工数据审核项目，雇佣了将近一百名来自真实世界的资深软件工程师，对原始SWE Bench的任务进行逐题审查。审查的核心包括任务描述是否清晰、测试用例是否公平、是否符合实际的工程逻辑。最终从海量任务中筛选出了大约500个任务，构建了高质量的SWE-bench Verified子集。值得一提的是，这次审核的严谨程度超乎想象，OpenAI要求三位不同的软件专家对同一道题进行独立审查和判断，再综合三方意见确定任务是否合格，这相当于把审核的成本直接提高了三倍。OpenAI的研究副总裁米娅·格莱斯在后续的播客访谈中表示，这个过程的投入规模难以夸大，因为软件工程任务的复杂性极高，不能单独看问题描述和补丁，必须把任务放到整个代码库的上下文环境中去理解，无论是人类工程师还是AI模型，都是在这样的上下文里完成任务的，所以三轮专家审查是必要的，甚至事后看来，还可以做更多的审核工作。也正是因为这份严谨，SWE-bench Verified一经推出，就成为了行业公认的权威基准，甚至开启了整个AI评测领域的Verified风潮，比如后来出现的HLE Verified，都是借鉴了这种人工深度审核的思路。

但是，这份严谨并没有解决数据污染的底层问题。因为SWE-bench Verified的所有任务都来自GitHub的开源仓库，而这些开源仓库的代码片段广泛存在于各大模型的训练数据中。OpenAI通常在发布自研评测基准时，会加入所谓的金丝雀字符串，也就是一段独特的、不会在公开数据中出现的字符串，用来检测模型是否记住了评测数据。但是在基于开源GitHub仓库的SWE-bench Verified上，这种方法完全无法使用，因为所有的任务数据都是公开可查的。更关键的是，SWE-bench Verified中的很多任务都来自Django、Astropy这类非常流行的开源项目，这些项目的代码在GitHub上被反复引用、传播，几乎所有前沿AI模型的训练数据中都包含了这些代码片段，这就为数据污染埋下了伏笔。OpenAI的前沿评估团队成员奥利维亚·沃特金斯在访谈中举了一个非常典型的例子：在对GPT-5.2的推理过程分析中，研究人员发现某个评测任务要求模型实现一个功能，但是问题描述中并没有提到某个关键参数，而测试用例却会检查这个参数是否存在。按照正常的编程逻辑，模型不可能知道这个参数的存在，但是GPT-5.2在推理过程中直接写道：“我记得在这个仓库的后续版本中实现过这个参数，我或许应该加上。”最终模型也因为添加了这个参数通过了测试。而如果没有这种来自训练数据的污染知识，这个测试用例几乎是不可能通过的。这个发现也触发了OpenAI一次全行业的模型污染调查，结果显示，数据污染并非个别模型的问题，而是整个行业的普遍现象。

如果说数据污染是SWE-bench Verified的外部绝症，那么测试设计的缺陷就是其内部硬伤。OpenAI在调查中发现，SWE-bench Verified中至少有60%的未解决问题，从题面的描述出发，本身就是无法被正确解决的。如果某个模型宣称解决了这些问题，那更可能意味着模型绕过了评测机制，也就是我们常说的刷题或作弊。OpenAI举了一个非常具体的例子，就是SWE-bench中针对pylint问题4551号的测试用例。这个任务要求模型为UML生成添加Python类型提示，因为原始的pyreverse工具无法读取Pep 484定义的Python类型提示，当默认值为None时会出现识别错误。但是这个测试用例本身存在严重的技术问题，在测试过程中，系统会提示无法从pylint.pyreverse.utils中导入get annotation函数。这是一个典型的测试环境问题，而这个问题在任务描述中完全没有提及。无论是人类工程师还是AI模型，在仅看到任务描述的情况下，都无法解决这个问题，因为问题的核心并非编程能力，而是测试环境的缺失。

除了这种环境问题，SWE-bench Verified的测试设计还存在两个普遍的缺陷：一是测试过于狭窄，测试用例期待某个具体的实现细节，但是在问题描述中根本没有要求这一点。比如某个任务只是要求实现一个数据筛选的功能，但测试用例却要求模型必须使用某个特定的参数名或者函数名，即便模型用了其他完全合理的命名方式，实现了完全相同的功能，测试也会判定失败。二是测试会检查问题描述中从未提及的额外功能，这意味着通过测试的模型可能做了很多超出任务要求的工作，而未通过测试的模型只是没有做这些额外工作，实现的功能本身是完全符合任务要求的。简单来说，SWE-bench Verified的评测体系只接受了极其狭窄的一小部分解空间，而忽略了大量同样正确、同样高质量的实现方式。这样的评测结果，显然无法反映模型的真实编程能力。

走向SWE-bench Pro与未来评测标准

更关键的是，经过两年的行业竞争，SWE-bench Verified已经达到了饱和状态。所谓饱和，就是前沿模型在这个基准上的性能已经接近天花板，后续0.1%的分数提升完全没有实际意义，甚至可能是模型通过刷题实现的。沃特金斯在访谈中表示，现在很多实验室就像有一个群聊，大家轮流把分数往上挪0.1%，然后就宣称自己的模型是最强代码模型，但是这种领先其实毫无说服力。OpenAI的研究团队发现，GPT-5.2发布后，解出了大约31个如果没有污染，应该非常难解出来的题目。这意味着如果排除数据污染的因素，行业内的前沿模型可能早就达到了SWE-bench Verified的性能天花板，后续的分数竞争不过是一场没有意义的数字游戏。

在这样的背景下，OpenAI提出转向SWE-bench Pro。这是一个由Scale公司发起的评测基准，它的题目难度更高、任务规模更大。SWE-bench Verified中大约90%的问题，一个资深的软件工程师不到一小时就能完成，这些问题通常描述清晰、逻辑自包含、规格也写得非常完整，本质上还是属于小而美的编程任务。而SWE-bench Pro的题目是真正贴近企业级开发的复杂任务，其完成时间被明确拉长到了几个小时甚至更久，还按照耗时分为了1到4小时、4小时以上等不同类别，更能反映模型在实际工程场景中的处理能力。其次，SWE-bench Pro的覆盖范围更丰富，无论是涉及的代码仓库、编程语言，还是问题的类型，都比SWE-bench Verified有了大幅扩展。SWE-bench Verified的任务主要集中在Python等少数主流语言，以及Django、pylint等常见开源项目，而SWE-bench Pro覆盖了更多的编程语言和小众但实用的开源仓库。问题类型也从简单的bug修复、功能实现，扩展到了架构设计、代码重构、性能优化等更综合的软件工程任务。定性上就能感受到，这些问题更符合真实的开发场景。

而最让OpenAI认可的是，SWE-bench Pro目前极低的数据污染程度。为了衡量评测基准的污染情况，OpenAI开发了一个专门的污染审计智能体。这个智能体会拿到任务描述、补丁、任务ID，然后通过一组开放式问题去审问目标模型，尽量诱导出模型可能隐藏的污染线索。在对SWE-bench Verified的审计中，这个智能体在几乎所有前沿模型中都发现了明显的污染迹象，包括模型复述标准答案、吐出任务ID等等。而在对SWE-bench Pro的审计中，仅发现了非常轻微的污染迹象，可能只有少数模型对一两个源仓库略微熟悉。沃特金斯表示，目前的SWE-bench Pro还没有被行业刷爆，能够有效区分不同模型的真实编程能力，这也是它能成为新一代基准的核心原因。

不过，必须明确的一点是，SWE-bench Pro也并非AI编程评测的终极答案。OpenAI在多个场合强调，任何公开的评测榜单，最终都会经历被追平、被记住、被学会，然后再次失效的生命周期，这是由AI模型的学习特性和开源社区的属性决定的。所以这次从SWE-bench Verified到SWE-bench Pro的切换，核心意义并非简单的换一个榜单，而是让整个行业思考一个更根本的问题：下一代的AI代码评测，到底应该衡量什么呢？

在OpenAI的前沿评估团队看来，好的代码评测，首先要跳出固定答案的框架，关注模型的开放式设计决策能力。沃特金斯表示，现在的很多评测都是把问题的要求写得非常死，模型只需要按照要求编写代码即可。但是在真实的工程场景中，大部分问题都没有唯一答案。比如让模型对某个代码库的某一部分进行提速，可能有多种实现路径，有的路径注重代码的可读性，有的路径注重执行效率，有的路径注重资源占用。一个优秀的AI编程助手，应该能根据实际的业务场景做出合理的设计选择，而不是只会执行固定的指令。这种开放式的评测难度远高于传统的封闭式评测，因为它不再有测试用例是否通过的单一评判标准，而是需要衡量模型的设计思路、工程思维是否符合实际需求。

其次，下一代的代码评测需要关注模型处理长期、复杂任务的能力。格莱斯表示，现在的行业发展已经超越了AI智能体能不能帮我解决一个小的GitHub issue的层级。过去的评测任务大多是15分钟就能搞定的小任务，但是在真实的开发中，工程师往往需要花费几个小时、几天甚至更久去完成一个复杂的项目，比如搭建一个完整的业务系统、重构一个大型开源项目的架构。这些任务需要模型具备持续的推理能力、上下文记忆能力、问题拆解能力，而这些能力在现有的短任务评测中是无法被衡量的。

同时，评测还需要关注那些难以量化，但是对实际开发至关重要的能力，比如模型的设计品味、编写的代码是否符合团队的编码风格、代码是否清晰、干净、具备可维护性、是否能被开源项目的维护者接受并合并。这些都是SWE-bench Verified这类仅通过测试用例是否通过来评分的评测体系无法回答的问题，但这些问题恰恰是企业在选择AI编程工具时最关心的核心指标。

那么，如何对这些难以量化的能力进行评测呢？OpenAI提出了两种思路：一种是重人力的专家评审，另一种是用大语言模型做代理评审。而理想的方式，是将这两种思路结合。沃特金斯以OpenAI的GDP Eval评测体系为例，解释了人力评审的价值。GDP Eval是由OpenAI的人类数据团队和前沿评估团队合作完成的评测体系，目标是衡量AI智能体能否完成各种真实世界的白领工作，覆盖了大约十几种占GDP比重较大的高层次专业职业，还有很多细粒度的子任务。这个评测的评分难度极高，因为需要大量的领域知识来判断在不同的业务情境下，什么是好的解决方案。为了做好这个评测，OpenAI雇佣了很多来自对应职业的专业人士，深度参与了任务设计、标准答案制作、评分规则制定，最终打造出了贴近真实工作场景的评测体系。如果把这种思路搬到代码领域，就是雇佣资深的软件工程师、架构师，对模型编写的代码进行人工评审，从功能、性能、可读性、可维护性等多个维度进行打分。这种方式的优势是评测结果最贴近实际，但缺点也很明显，那就是成本高、速度慢，无法进行大规模的模型对比。

而用大语言模型做代理评审，就是训练一个专业的代码评审模型，让它按照人类制定的评分规则，对目标模型编写的代码进行自动评审。这种方式的优势是速度快、成本低，能进行大规模评测，但是核心难点是让评审模型的判断标准和人类工程师的判断标准保持对齐。OpenAI认为，未来的代码评测会是人力评审制定标准，大语言模型代理评审进行大规模执行的结合模式，既能保证评测的真实性，又兼顾评测的效率。

除了评测内容的转变，AI编程评测的维度和指标也在发生着重要的变化。从传统的0到100的百分制打分，转向了以时间、金钱、复杂度为核心的计价方式。现在行业内出现了很多新的评测思路，比如用freelancer、vending bench等方式，将模型的编程能力换算成实际的经济价值。格莱斯认为，这种计价方式和传统的百分制打分本质上是用不同的尺度衡量同一件事，因为人类解决一个任务的时间往往就决定了这个解决方案的经济价值。而评测的核心，其实是衡量我们能够把AI智能体托付给多复杂、运行时间多长的任务。这些任务的长度重量复杂度，才是判断模型能力的关键。在这个过程中，复杂度成为了核心的抽象指标，而时间、金钱、故事点则是复杂度的具体投射维度。格莱斯表示，无论是用时间、金钱还是其他指标，核心都是量化任务的复杂度，因为复杂度直接决定了模型的能力水平，也决定了模型在市场中的应用阶段。毕竟，一个只能解决低复杂度任务的模型，只能作为工程师的辅助工具；而一个能解决高复杂度任务的模型，才能真正成为自动化的开发助手。

说到这里，我们再来介绍一下OpenAI做这些评测的底层逻辑，也就是它提出的风险准备框架（Preparedness Framework）。因为SWE-bench Verified的诞生本身就是这个框架的一部分，而未来的代码评测也会围绕这个框架展开。沃特金斯对这个框架进行了详细的解读。风险准备框架是一个公开的框架，核心目的是追踪前沿AI技术的前沿风险，这些风险通常来自AI的双用途能力，也就是既可以被用于有益的事情，也可能被用于有害的事情。OpenAI希望通过这个框架，持续监测AI能力的潜在负面使用，确保企业和社会都能为可能出现的风险做好准备。目前，这个框架主要追踪三大类能力风险：第一类是生物安全风险，也就是AI被用于设计有害生物制剂、突破生物安全防线的风险；第二类是网络安全风险，也就是AI被用于制作高级网络攻击工具、突破网络安全防护的风险；第三类是研究自动化与模型自治，也就是AI具备自主完成科学研究、工程开发的能力后带来的一系列风险。而这一类，正是和代码评测联系最紧密的领域，因为代码是研究自动化和模型自治的核心工具。一个具备强大编程能力的AI模型，能自主完成从研究设计、代码实现，到实验验证、结果分析的完整研究工作流。这种能力既可以极大地推动科学和工程的发展，也可能带来不可控的风险。所以OpenAI最初创建SWE-bench Verified，就是作为衡量模型自治能力的核心评测手段。而现在，随着模型能力的提升，OpenAI认为评测的重点需要从单一的编程任务解决，转向评估模型是否能真正自动化完整的研究工作流。

也正是基于这个框架，OpenAI非常强调行业社区的协作。格莱斯表示，OpenAI投入了大量精力构建评测体系，也会在风险准备框架下发布各个基准测试成果，核心目的就是推动整个行业共同构建、分享、复用评测体系，因为没有任何一家企业能单独打造出覆盖所有场景、衡量所有能力的评测基准。只有行业协作，才能让评测体系更完善、更贴近实际。OpenAI也向整个行业发出了号召，希望社区能贡献三类更有价值的评测内容：第一类是真正超高难度的任务，也就是那些需要顶尖工程师花几个月或者一个团队花几周才能完成的复杂任务；这些任务如果能制定出可靠的、经过领域内多方验证的评分规则，将能够有效衡量模型的顶尖能力。第二类是端到端产品构建类的基准，随着越来越多的人使用AI智能体直接出产品，从需求分析、架构设计，到代码编写、测试部署的完整产品构建流程，成为了衡量AI编程能力的重要场景，这类评测也会变得越来越重要。第三类是AI真实世界使用情况的指标，这一点甚至不完全算是传统的评测，但却是和OpenAI的整体使命高度相关的内容，也就是统计AI在现实中到底被用了多少，在多大程度上替代了人类的工作，又在多大程度上增强了人类的能力、加速了人类的开发效率。这些真实世界的指标，比任何实验室的评测分数都更能反映AI编程技术的实际价值。

总的来说，这次OpenAI停用SWE-bench Verified，从表面上看，这只是一次评测基准的切换。但是从深层来看，这标志着AI编程领域的发展进入了一个新的阶段，从追求分数的技术竞争，走向了追求价值的实际应用。过去两年，行业通过SWE-bench Verified的榜单，推动了AI编程能力的快速提升，让模型从只能编写简单的代码片段，发展到能解决实际的GitHub issue。但是当分数竞争走到尽头，行业必须把目光转向真实的工程场景，关注模型的实际价值。沃特金斯也表示，OpenAI的前沿评估团队未来会将更多的精力放在关注AI的真实世界影响上，包括真实的使用场景、真实的吞吐效率、真实的应用效果，这些才是决定AI编程技术未来的核心。对于我们从业者和开发者来说，这次的事件也提醒我们，不要过分迷信评测榜单的分数，而要更多地从实际使用出发，判断一个AI编程工具的价值，因为真正的技术竞争力永远只存在于真实的工程场景中，而非实验室的评测榜单上。感谢收看本期视频，我们下期再见。