Scale AI推出的SWE-BENCH PRO软件工程基准测试，其难度远超以往，旨在更真实地评估大语言模型在实际开发场景中的能力。与旧基准不同，SWE-BENCH PRO使用全新代码库，避免数据污染，并专注于复杂的多文件修改任务。测试结果显示，即使是GPT-5和Claude Opus 4.1等顶级模型，在该基准上的解决率也远低于预期，普遍在25%以下。文章深入分析了模型在不同编程语言和代码库上的表现差异，并详细阐述了各模型的失败原因，如语义理解不足、工具使用错误或上下文管理限制等，揭示了当前大模型在解决复杂软件工程问题上仍面临巨大挑战。

🎯 **SWE-BENCH PRO挑战升级，真实反映模型工程能力**：新的SWE-BENCH PRO基准测试相较于之前的SWE-Bench-Verified，在难度和真实性上有了显著提升。它采用了全新的、模型未曾训练过的代码库，并侧重于工业级软件工程中常见的跨多文件、大规模代码修改任务，而非以往测试中存在的琐碎或易受数据污染的问题。这使得该基准能够更准确地衡量大语言模型在实际软件开发环境中的真实解决问题能力。

📉 **顶级模型表现均不理想，揭示当前局限性**：在SWE-BENCH PRO的测试中，包括GPT-5、Claude Opus 4.1和Gemini 2.5在内的最先进大语言模型，其代码修复解决率普遍低于25%，远低于旧基准的70%以上。这一结果表明，尽管模型在特定擅长领域表现尚可，但在应对复杂、全新的软件工程挑战时，其能力仍有待提高。GPT-5在仅考虑已提交任务时表现相对较好，但整体未回答率依然很高。

🔧 **模型失败原因多样，指向不同技术瓶颈**：文章详细分析了不同模型在SWE-BENCH PRO上的失败模式。例如，Claude Opus 4.1主要受语义理解不足和语法错误影响；GPT-5可能在工具使用有效性上存在差异；Claude Sonnet 4则面临上下文溢出和文件导航的限制；Gemini 2.5的失败原因较为均衡，涉及工具、语法和解答错误；而开源模型Qwen-3 32B则工具错误率最高。这些分析揭示了当前大模型在理解复杂指令、有效利用工具、管理上下文和生成正确代码等方面存在的具体技术挑战。

💡 **编程语言与代码库复杂性影响模型表现**：实验结果显示，模型在不同编程语言和代码库上的表现存在显著差异。Go和Python通常表现较好，而JavaScript和TypeScript的表现波动较大。不同代码库的解决率也差异明显。前沿模型在多数情况下表现稳定，而小模型则更容易出现接近零的解决率。这种差异性表明，模型的泛化能力和对特定语言及代码库的适应性是影响其工程能力的关键因素。

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主打全新题目，以确保模型在训练阶段从未接触过测试内容，从而更真实地考验模型的实际能力。

涵盖1865个商业应用、B2B服务和开发者工具的多元化代码库

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

公共集：来自采用copy-left许可证的11个公共代码库的731个问题。

商业集：来自276个源自初创公司代码库的问题。

保留集：来自采用copy-left许可证的12个公共代码库的858个问题。

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

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

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

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

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

human in the loop的测试环节

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

研究团队在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%的大模型呢？

参考链接

[1]https://x.com/vbingliu

[2]https://scale.com/leaderboard/swe_bench_pro_public

[3]https://x.com/ChowdhuryNeil/status/1969817448229826798

[4] https://scale.com/research/swe_bench_pro

本文来自微信公众号“量子位”，作者：关注前沿科技，36氪经授权发布。