GPT-5 编程测评“表面不及格”：实际 63.1% 的任务没交卷，全算上成绩比 Claude 高一倍

Scale AI 的新软件工程基准 SWE-BENCH PRO 显示出顶级模型在新测试中的表现不佳，GPT-5 和 Claude Opus 4.1 的解决率分别为 23.3% 和 22.7%。尽管表面上看似“翻车”，但深入分析显示，模型在更复杂的任务上仍有潜力。

Scale AI 的新软件工程基准 SWE-BENCH PRO，出现反转！

表面上看，“御三家”集体翻车，没一家的解决率超过 25%：

GPT-5、Claude Opus 4.1、Gemini 2.5 分别以 23.3%、22.7%、13.5% 的解决率**“荣”登前三**。

但深入数据背后，则暗藏玄机。

前 OpenAI 研究员 Neil Chowdhury 表示，如果只看已提交的任务，GPT-5 能达到 63% 的准确率，比 Claude Opus 4.1 的 31%，高了近一倍！

（这怎么不算 G 又赢！？）

换句话说，GPT-5 在擅长的题目上依旧稳健，与老基准 SWE-Bench-Verified 的 74.9% 差距不大，而 Claude 跟其他模型则直接拉垮到底。

那么，究竟是什么基准测试，让这些顶级模型如此狼狈？

SWE-BENCH PRO

先说结论，不是模型变菜了，而是题变难了。

与平均正确率高达 70% 的 SWE-Bench-Verified 相比，SWE-BENCH PRO 严格得可不止一星半点。

一方面，作为 OpenAI 于 2024 年 8 月发布的测试集，SWE-Bench-Verified 中的很多代码库已被用作大语言模型的预训练语料，存在着数据污染的风险。

另一方面，SWE-Bench-Verified 还包含不少琐碎的问题，例如 500 个问题中有 161 个只需一两行修改。

这与工业软件工程中通常涉及的跨多文件、数百行修改的场景差距较大，从而无法真正反映实际开发场景中所面临的挑战。

基于此，SWE-BENCH PRO 主打全新题目，以确保模型在训练阶段从未接触过测试内容，从而更真实地考验模型的实际能力。

具体来说，SWE-BENCH PRO 将这些代码库构建为以下三个子集：

（注：公共集将在 HuggingFace 上发布，商业集和保留集保持私有，商业集的测试结果会公开，保留集用于验证模型是否过拟合。每个问题由任务描述、相关测试集和可运行环境构成。）

这些从强 Copyleft 许可证（GPL）代码库和真实的初创公司获取的商业代码库能够有效地解决 SWE-Bench-Verified 存在的数据污染问题。

为了确保任务的复杂性，研究团队还排除了像 1-10 行代码编辑这样琐碎的编辑，保留了需要进行大量多文件修改的问题。

此外，为了防止模型对任何单一代码库产生过拟合，这些代码库都处于活跃状态并覆盖消费者应用、B2B 服务和开发者工具平台。

接下来，就让我们看看研究者是如何在这些问题上进行测试的。

为了将模型评估的重点放在当模型获得充分细节后，能否实现给定的修复或补丁上。

研究团队在 SWE-Bench Verified 的基础上，将 SWE-BENCH PRO 中的每个问题都经过了人工增强，并加入了问题陈述、需求说明以及接口信息。

首先，研究团队提供一个待解决问题的问题陈述并在必要时补充上下文信息。

其次，针对潜在的歧义问题，对于每个问题，列出了一系列需求并指定相应的类和函数。

之后，在环境方面，每个任务都在一个容器化的、用于特定语言的环境中进行评估。

在测试阶段，研究通过 fail2pass 测试验证问题是否已解决，通过 pass2pass 测试确保现有功能保持完整。

其中，为了确保测试质量，fail2pass 测试会经过人工筛选，去掉与任务不相关或过于宽泛的测试。

对于偶尔失败的测试，则会运行三次，以确保结果稳定。

正如我们开头提到的，大语言模型在 SWE-BENCH PRO 上的解决率仅为中等水平，远低于 SWE-Bench Verified 中的 70% 。

其中，在公共集上，GPT-5 和 Claude Opus 4.1 分别实现了 23.3% 和 22.7% 的最高解决率，显著优于小规模模型，Claude Sonnet 4 也达到了 16.3% 的解决率。

不过，像 DeepSeek Qwen-3 32B 和 GPT-4o 这样的老模型表现就多少有点不尽人意了，仅为 3.4% 和 3.9%。

在商业集上，即便是最优模型的得分也低于 20%。

这表明当前模型在解决真实商业场景中的问题时，能力仍然非常有限。

针对这一苦涩的实验结果，研究人员展开了进一步的分析，结论如下：

首先，编程语言的难度、代码库以及模型的种类被视为影响模型表现的关键因素。

Go 和 Python 通常表现较好，一些模型在这些语言上的解决率超过 30%，而 JavaScript 和 TypeScript 则波动较大，从 0% 到超过 30% 不等。
不同代码库的解决率差异也很明显，一些代码库普遍偏低（低于 10%），另一些则超过 50%。
前沿模型如 Claude Opus 4.1 和 GPT-5 在大多数编程语言和代码库中表现稳定，小规模模型则更易出现接近零的解决率。

其次，不同的模型的失败原因往往各不相同。

OPUS 4.1 的主要失败模式是语义理解不足，错误解答占 35.9%，语法错误占 24.2%，表明其技术执行能力较强，但在问题理解和算法正确性方面存在挑战。
GPT-5 的结果显示在工具使用的有效性上可能存在差异，但错误解答相对较少。
SONNET 4 的主要失败模式是上下文溢出（35.6%）和显著的无休止文件读取行为（17.0%），表明其在上下文管理和文件导航策略上存在局限。
GEMINI 2.5 的失败模式则较为均衡，涵盖工具错误（38.8%）、语法错误（30.5%）和错误解答（18.0%），显示其在多个维度上保持了一定能力。
QWEN3 32B 作为开源模型，表现出最高的工具错误率（42.0%），凸显了集成化工具使用对于高效代理的重要性。

不难看出，GPT-5 虽然延续了以往“会就会，不会就不会”的答题策略，但面对高企的未回答率（63.1%），它的表现仍然不够看。

那么，谁会成为第一个突破 30% 的大模型呢？

参考链接