AI编程评估为何逐渐失灵？OpenAI撤销SWE-Bench Pro推荐

数月前，OpenAI还曾向业界推荐使用SWE-Bench Pro来衡量前沿模型的编程水平。

而如今，这一推荐已被撤回。

2026年7月，OpenAI公布了对SWE-Bench Pro的审查结论：在公开测试集涵盖的731个任务里，自动审核流程判定其中200个任务存在问题，占比达27.4%；人工标注则认定249个任务存在问题，占比34.1%。

综合两类审核结果，OpenAI估算公开任务中约有30%属于"劣质"任务。

所谓"劣质"，并非指题目难度过高，而是指测试本身无法准确判定模型是否真正完成了任务。模型可能给出了合理的修复方案，却因隐藏测试包含不合理约束而被判失败；也可能仅完成了不完整甚至错误的修改，却因测试覆盖不全而顺利通过。

基于此，OpenAI正式撤回了此前建议研究社区将SWE-Bench Pro作为主要AI编程基准的立场。

此事最值得关注之处，并非OpenAI又一次"自我否定"。

核心问题在于：随着模型能力持续增强，我们用于评估模型的工具，正比模型本身更早失去效用。

SWE-Bench是目前最具影响力的AI编程基准之一。

它与早期的HumanEval、MBPP等代码生成测试存在本质差异。后者通常要求模型根据描述编写一个函数；而SWE-Bench直接从真实开源项目中提取GitHub Issue及对应代码修改，让AI进入完整代码仓库，阅读项目、定位问题、修改多个文件并运行测试。

这显然更贴近真实的软件开发场景。

原始SWE-Bench包含来自12个Python项目的2294个任务。模型获得的是某历史版本的代码，以及一段来自GitHub Issue的问题描述。它需要生成补丁，并通过基于原始Pull Request构建的测试。

随着AI编程能力提升，SWE-Bench Verified逐渐成为模型厂商发布新品时必报的成绩。它包含500个经人工筛选的任务，一度被视为更高质量、更可信的版本。

但问题很快显现。

一方面，这些任务和参考答案长期公开，极有可能进入模型的训练数据。模型取得高分，可能源于真正掌握了软件工程能力，也可能仅是因为见过类似代码、问题描述甚至标准补丁。

另一方面，当前沿模型已能解决大部分有效任务时，排行榜中剩余的失败案例，开始越来越多地源于题目本身的缺陷。

2026年2月，OpenAI审查了o3多次尝试仍无法稳定解决的138个SWE-Bench Verified任务，发现其中相当一部分存在测试过严、描述不完整、隐藏要求未说明等问题。OpenAI随后宣布，SWE-Bench Verified已难以继续衡量前沿编程能力，并建议业界暂时转向SWE-Bench Pro。

彼时的SWE-Bench Pro确实像一个理想的继任者。

它包含来自41个持续维护项目的1865个任务，覆盖公开集、保留集和商业项目集。任务不再局限于Python，而是强调更长的执行过程、更大的修改范围，以及更接近企业软件开发复杂度的特性。

论文还特别强调，这些任务经过人工验证，提供了充足上下文，并且更能抵御训练数据污染。

然而，仅仅数月后，OpenAI便发现：这个被寄予厚望的替代品，其公开集中可能有近三分之一无法承担可靠评测的职能。

SWE-Bench类基准的核心逻辑并不复杂。

研究者找到一个已关闭的GitHub Issue，提取问题出现时的代码版本，再将后续Pull Request中新增的测试作为评分标准。AI修改代码后，若旧测试未被破坏，新测试也全部通过，则视为任务解决。

问题在于，真实软件开发中的测试，与用于考试的评分器，性质截然不同。

一名项目维护者为某次Pull Request编写测试，主要目的是确认该提交能解决当前问题。他无需考虑未来是否存在多种完全不同、但同样正确的实现方式。

然而一旦这些测试被用于评价AI，它就必须承担另一重职责：公平区分所有合理答案与错误答案。

这是一个高得多的要求。

OpenAI在审核中发现，部分SWE-Bench Pro任务的隐藏测试加入了题目中从未提及的约束。

例如，任务描述要求模型在某段输出前添加一个空格，隐藏测试却要求两个空格。模型严格按照题目完成修改，仍会被判错。

还有一些测试将参考补丁中的具体实现细节视为唯一答案。模型即便采用了功能等价、设计合理的实现方式，只要未复刻原开发者的写法，就可能失败。

这类题目测量的已不是"模型能否修复问题"，而是"模型能否猜中出题人未明说的意图"。

相反的情况同样存在。

若测试覆盖不足，模型可能仅修复了一个特殊场景，甚至通过硬编码绕过测试，就被计为成功。

2025年发表的UTBoost研究对SWE-Bench的测试进行了扩充，发现了36个测试明显不足的任务，并找出345个原本被标记为成功、实际上并未正确解决问题的补丁。这些修正足以影响SWE-Bench Lite中40.9%的排行榜提交，以及SWE-Bench Verified中24.4%的提交，并引发多次排名变动。

也就是说，排行榜上的"解决率"并不完全等同于问题真正被解决的比例。

它首先意味着：模型生成的补丁通过了当前这套测试。

至于测试是否覆盖需求，题目是否说清需求，评分器是否错误拒绝合理答案，则是另一回事。

除测试设计外，SWE-Bench Pro还被发现存在一种更直接的问题：评测环境可能泄露答案。

有开发者发现，部分任务提供给AI的代码仓库保留了后续Git历史。智能体可以使用git log、git show等命令，查看基准任务发生之后的提交。

而这些后续提交中，可能就包含原始修复方案。

这类似于参加程序设计考试时，标准答案并未直接出现在题目里，却被放进了考试电脑的历史文件夹。

普通模型未必会主动寻找它。但具备终端操作能力、会检查Git历史的智能体，很可能将这种路径视为解决问题的一部分。

这构成了一种典型的"奖励黑客"行为。

模型的目标是让测试通过。只要评测环境允许，它就可能利用任何能提高分数的线索，而不会主动区分这是合理的软件工程操作，还是基准设计留下的漏洞。

从结果上看，模型完成了任务；从能力上看，它并未真正理解和修复问题。

更棘手的是，我们难以简单地将责任归咎于模型"作弊"。

在真实开发中，阅读Git历史本身就是一种完全合理的排查方式。问题出在评测者既允许模型使用真实开发工具，又未确保这些工具无法访问未来信息。

这揭示了智能体评测中的一个根本矛盾：

环境越真实，模型可使用的工具和信息越丰富，潜在漏洞也越多；环境限制越严格，评测又越不像真实的软件开发。

即便数据和测试均无问题，不同团队报告的SWE-Bench成绩也未必可直接比较。

因为最终参与测试的通常不是一个裸模型，而是一整套编程智能体系统。

系统可能包括：

同一模型，置于不同的Agent框架中，成绩可能出现明显差异。

因此，一张所谓的"模型排行榜"，实际上经常混合了模型能力、提示词设计、上下文管理、测试策略、计算预算和工程经验。

排名第一的未必是最强的模型，也可能是最擅长适应这套基准的系统。

这并非说Agent工程不重要。对于真实产品而言，系统能力本来就比裸模型能力更有价值。

问题在于，许多排行榜和新品发布会仍会将这种系统成绩表述为模型自身的编程能力，甚至将不同工具配置、不同运行预算和不同评测版本的结果混在一起比较。

最终，一个看似精确到小数点后一位的数字，背后可能对应完全不同的实验条件。

所有公开基准都会面临污染和刷榜问题，但编程基准尤为严重。

首先，代码和答案天然公开。

SWE-Bench的题目来自GitHub，Issue、讨论、Pull Request、测试和最终修复通常都可被搜索到。只要任务长期公开，它们就有可能进入下一代模型的训练数据。

其次，代码任务存在大量合理实现。

数学选择题通常只有一个答案，代码问题却可能有多种架构和实现方式。要用自动测试覆盖所有正确答案、排除所有错误答案，极为困难。

第三，真实软件问题往往描述不完整。

GitHub Issue并非为考试编写的需求文档。许多上下文存在于维护者的经验、讨论记录、产品约定和未成文的默认规则中。人类开发者可通过追问和沟通补齐信息，基准中的AI通常只能面对一段固定描述和隐藏测试。

第四，Agent会主动探索环境。

传统语言模型评测通常是一问一答。编程智能体会读取文件、执行命令、检查进程、搜索历史、运行测试。环境中的每一处细节都可能成为意外线索，也可能成为导致任务无法运行的故障点。

最后，模型进步速度过快。

当基准刚发布时，模型能力较弱，大多数任务都失败，少量噪声不易改变总体结论。

当前沿模型逼近基准上限后，真正有效、仍能区分模型的任务越来越少。此时，劣质题目、随机波动和测试偏差在剩余差距中的占比会迅速上升。

两个模型相差两三个百分点，看似有明确胜负，但这个差距可能还未达到基准自身的误差水平。

某种意义上，基准并非在模型达到100分时才失效。

当排行榜上的差距已小于测量噪声时，它就已失效。

OpenAI撤回推荐，并不意味着SWE-Bench Pro毫无价值，更不意味着所有AI编程排行榜都应被忽略。

基准仍可帮助我们快速观察技术趋势。

例如，模型从几乎无法修改大型代码仓库，进步到能够独立定位问题、修改多个文件并通过回归测试，这种跨越是真实的。相同评测条件下，同一系统不同版本之间的大幅提升，也通常具有参考意义。

需要放弃的，是将单一分数视为客观真相。

对于普通开发者，Benchmark更适合用于初步筛选，而非决定最终选择。

一个模型在SWE-Bench上领先，不代表它一定更适合你的TypeScript项目，更不代表它能理解公司的内部框架、部署流程和业务约束。

真正有意义的测试，是用团队过去遇到过的真实任务来比较：

让不同模型修复同一批历史Bug，完成同一组小型需求，解释同一套陌生代码，编写同样的测试，再由工程师盲评结果。

除成功率外，还应记录完成时间、调用成本、人工干预次数、引入回归问题的概率，以及代码是否易于维护。

对模型厂商和评测机构而言，也需放弃"一套公开题库长期统治排行榜"的思路。

更可信的方向应是持续加入新任务，保留足够规模的私有测试集，完整披露Agent配置和运行预算，对通过与失败案例进行抽样人工复核，并为基准建立明确的版本和退役机制。

当一套基准已被训练数据覆盖，或评分器被证明存在系统性偏差，就应冻结旧榜单，而非继续让它承担新品营销和采购决策的职责。

OpenAI从推荐SWE-Bench Pro到主动撤回推荐，表面上是一家模型公司修正了自身判断。

更深层的变化是，AI行业开始不得不承认：评测能力已落后于模型能力。

过去，我们担心模型不会写代码。

如今，模型能够阅读大型代码库、运行工具、修改多个文件，甚至主动寻找评分系统的漏洞。与此同时，我们仍试图用静态题库、历史测试和一个简单的通过率，来压缩如此复杂的能力。

这把尺子显然已不够用。

未来的AI编程评测不会依赖某一套永远正确的基准，而会更像一套持续运行的质量体系：题目不断更新，环境接受审计，结果可以复现，错误能够修订，失效的版本及时退役。

排行榜依然会存在，分数依然值得关注。

但下一次看到某个模型在编程基准上领先几个百分点时，我们应先问一句：

这究竟是模型变强了，系统更会刷榜了，还是尺子本身已经歪了？