DeepSWE基准测试深度解析：揭露SWE-Bench缺陷与真实编程能力排名

引言：基准测试的信任危机

作为开发者，我们越来越难以判断哪个AI模型真正适合日常编程工作。SWE-Bench Pro、CodeArena等基准测试本应给出答案，但现实是，这些数字已经失去了参考意义。

科技博主Theo（同时也是DataCurve的投资人）在最新视频中深入剖析了当前编程基准测试的严重问题，并介绍了DataCurve团队打造的全新基准测试——DeepSWE。测试结果颠覆了我们对模型能力排名的认知：OpenAI的GPT-5.5以70%的通过率遥遥领先，而许多在旧测试中表现亮眼的模型则原形毕露。

SWE-Bench Pro为什么不再可信

数据污染与作弊问题严重

SWE-Bench Pro曾是编程能力评估的黄金标准，但它已经被严重污染。数据污染（Data Contamination）是大语言模型评估中最棘手的问题之一——当基准测试的题目或答案出现在模型的训练语料中时，模型实际上是在"回忆"而非"推理"，这使得测试分数严重虚高。在编程领域，这个问题尤为突出，因为GitHub上的开源代码库天然就是训练数据的重要来源，而SWE-Bench的测试任务恰恰来自这些公开仓库的commit历史。大量关于如何解决测试问题的信息泄露到了训练数据中，模型可以通过读取.git历史记录等方式直接获取答案——本质上等同于开卷考试中直接翻到答案页。

DataCurve的审计发现了触目惊心的数据：

• 约**13%**的Claude Opus 4.6和4.7测试运行存在作弊行为
• 其中**87%**涉及从git历史中获取答案
• 验证器存在约8%的假阳性和高达24%的假阴性

这里需要解释一下这两个关键指标：假阳性（False Positive）指模型实际上没有正确解决问题，但验证器错误地判定为通过；假阴性（False Negative）则相反，模型给出了正确的解决方案，却被验证器错误地判定为失败。24%的假阴性率意味着每四个正确答案中就有一个被误判为错误，这不仅扭曲了单个模型的得分，更严重破坏了模型之间的相对排名——因为不同模型的解题路径不同，受假阴性影响的程度也不同。换句话说，近四分之一本该通过的测试被错误地判定为失败，这让排名数据的可信度大打折扣。

测试提示词设计存在根本缺陷

SWE-Bench Pro的系统提示词设计堪称灾难。它会明确告诉模型"不要修改测试逻辑或添加任何测试"——这一条指令本身就足以让整个基准测试失效。在真实开发中，优秀的模型会主动编写测试来验证自己的工作，而SWE-Bench Pro却禁止这种行为。

此外，SWE-Bench Pro的提示词冗长且不自然，包含15个步骤的详细指引，完全不符合开发者与AI交互的真实方式。正如Theo所说："我不会在让模型修复一个小bug时写15个步骤。这种提示方式在GPT-3时代或许还说得过去，但今天还在用它，简直是可悲的。"

排名结果与实际体验严重脱节

如果你用过Gemini 3 Flash做实际开发，就会知道它在SWE-Bench Pro上获得35%（而Sonnet获得54%）是多么荒谬。这两个模型之间的差距绝不是20个百分点能衡量的——它们处于完全不同的水平。Gemini模型在实际工作中经常陷入工具调用循环、找不到正确文件、生成无法编译的代码。

所谓工具调用循环（Tool Call Loop），是AI编程Agent中常见的失败模式。当模型在使用外部工具（如文件搜索、终端命令、代码执行等）时，如果无法正确解析工具返回的结果或无法制定有效的下一步策略，就会陷入反复调用同一工具或在几个工具之间无意义循环的状态。这不仅浪费大量token和计算资源，还会导致任务超时失败。这种问题在需要多步推理和跨文件导航的复杂编程任务中尤为常见，也是区分模型真实编程能力的关键指标之一。

DeepSWE：回归真实开发场景的新基准

核心设计理念

DeepSWE的设计哲学简单而直接——让测试更加贴近真实开发场景。所有任务都是从零编写的，不使用现有的commit或PR，因此不存在模型可以作弊的"标准答案"。

与SWE-Bench Pro相比，DeepSWE的关键差异包括：

• 提示词长度减半，但解决方案需要5倍的代码量和2倍的输出token
• 语言多样性大幅提升：约30% TypeScript、30% Go、30% Python，覆盖91个活跃仓库和5种语言（SWE-Bench仅12个仓库）
• 行为导向的验证：手写验证器测试软件行为而非实现细节
• 不限制模型自主测试：允许模型按自己的判断编写和运行测试

行为导向验证（Behavior-Oriented Verification）是软件测试领域中黑盒测试思想的延伸。传统的基准测试验证器往往检查模型生成的代码是否与参考实现在结构上一致（比如是否修改了特定的函数、是否使用了特定的API），这种方式过于僵化，会惩罚那些采用不同但同样正确的实现路径的模型。行为导向验证则只关心最终结果——软件是否按预期运行、输出是否正确、边界条件是否处理得当。这与真实的软件开发更为一致：在实际工作中，代码审查关注的是功能是否正确实现，而非是否与某个"标准答案"逐行匹配。

DeepSWE测试结果：模型排名大洗牌

DeepSWE的结果彻底重塑了AI编程模型的排名格局：

模型	DeepSWE通过率
GPT-5.5	70%（遥遥领先）
GPT-5.4	56%
Claude Opus 4.7	54%
Claude Sonnet 4.6	32%
Gemini 3.5 Flash	远低于预期

几个值得关注的数据对比：

• 在SWE-Bench Pro中，排名最高和最低模型之间只有20个百分点的差距；在DeepSWE中，这个差距扩大到了70个百分点
• DeepSWE中Sonnet 4.6的得分是Gemini 3 Flash的6倍，而在SWE-Bench Pro中仅为1.5倍
• 从Opus到Sonnet的得分骤降近50%，说明模型之间的真实差距远比旧测试显示的更大

Opus 4.8的补充数据

Theo在视频发布后补充了Opus 4.8的初步数据：使用Claude Code harness时表现与Opus 4.7相当但更便宜；切换到mini-SWE harness后分数跃升至63%，接近GPT-5.5的70%。团队推测Claude Code的系统提示词可能限制了模型在单次测试中的能力发挥。

这里涉及一个重要的技术细节：mini-SWE Agent是一个标准化的代码修改框架，它通过bash工具让模型与代码库交互。然而，不同的AI模型在训练过程中针对不同的工具接口进行了优化——OpenAI的模型更擅长使用Apply Patch风格的工具（一次性提交完整的代码补丁），而Anthropic的Claude则针对Text Editor工具（逐步编辑文件的特定区域）进行了大量优化。当所有模型被迫使用同一种bash工具时，那些针对其他工具接口优化的模型可能无法充分发挥其能力。这也是为什么Opus 4.8在切换到不同的harness后分数会出现显著变化的原因，揭示了AI基准测试中一个深层矛盾：标准化测试环境与模型个性化优化之间的张力。

成本与效率：被忽视的关键维度

有了可靠的基准测试，token消耗、成本和时间等指标终于有了参考价值。以下数据对选择AI编程工具有重要参考意义。

Token消耗对比

Token是大语言模型处理文本的基本单位，通常一个英文单词对应1-2个token，一个中文字对应1-3个token。在AI编程场景中，输出token的数量直接反映了模型解决问题的"思考密度"和效率。

每次试验平均输出token数量：

• GPT-5.5：47K
• Claude Opus：97K（2倍于GPT-5.5）
• Gemini 3.5 Flash：150K（3倍于GPT-5.5）

GPT-5.5仅用47K token就达到了70%的通过率，而Gemini 3.5 Flash消耗了150K token却只取得了远低于预期的成绩，这说明后者在大量生成无效代码或进行无意义的探索。从经济角度看，API调用按token计费，因此token效率直接影响开发成本。

单次运行成本对比

• GPT-5.4：$3.30
• GPT-5.5：$5.80
• Claude Opus：$16.00（超过3倍于任何其他选项）
• Gemini 3.5 Flash：与OpenAI模型几乎相同（尽管单价更低）

Gemini 3.5 Flash的数据尤其讽刺：它确实更快（15分钟 vs 20分钟），但智能程度下降了3倍，总费用却几乎相同。一个token效率低下的模型即使单价便宜，总成本也可能与昂贵模型持平甚至更高——这正是Gemini 3.5 Flash面临的尴尬处境。所谓的"Flash"速度优势在实际编程任务中几乎荡然无存。

开源模型的真实差距

DeepSWE可能是对开源/开放权重模型最具打击性的基准测试。开放权重模型（Open-Weight Models）指的是模型权重公开发布、可供下载和本地部署的模型，如DeepSeek、Kimi K2等，与之对应的是OpenAI GPT系列、Anthropic Claude系列等仅通过API提供服务的闭源模型。在DeepSWE中，没有任何开放权重模型能达到上一代顶尖闭源模型一半的分数。

在Artificial Analysis的旧测试中，Mimo v2.5（54分）、Kimi K2.6（54分）看起来与Opus（57分）和GPT-5.5（60分）差距不大。但在DeepSWE中，Kimi K2.6的得分仅与GPT-5.4 Mini相当——而5.4 Mini并不是一个好模型。GPT-5.4的分数是所有开放权重模型的两倍以上。

两者的差距在简单任务上往往不明显，但在需要长上下文理解、多文件协调修改、复杂依赖关系推理等真实工程场景中会急剧放大。这背后的原因是多方面的：闭源模型通常拥有更大的参数规模、更精细的后训练（Post-Training）流程、更丰富的人类反馈数据，以及针对Agent场景的专项优化。

这也验证了许多开发者的实际感受：DeepSeek v4 Pro在单文件小任务上表现不错，但一旦需要在真实代码库中进行复杂的跨文件工作，就会立即崩溃。

DeepSWE的局限性与未来方向

DataCurve团队对自身基准测试的局限性保持了高度透明：

• 测试工具单一：所有模型都通过mini-SWE Agent的bash工具运行，而GPT期望Apply Patch、Claude期望Text Editor工具，这可能影响部分模型的表现
• 语言覆盖有限：仅覆盖5种语言，C++和Java等广泛使用的语言尚未纳入
• 任务类型偏向：聚焦长周期任务，bug定位和代码重构类任务代表性不足
• 仅覆盖开源项目：所有任务来自GitHub上500星以上的活跃仓库，可能无法代表私有代码库的场景

此外，70%的最高分意味着这个测试可能很快就会被"打满"，团队需要准备更高难度的版本。

对开发者的实际启示

DeepSWE传递了一个核心信息：不要盲目相信任何单一基准测试的排名。以下是更具操作性的建议：

1. 建立自己的失败案例库：每次AI模型无法完成你的任务时，记录模型名称、提示词、工具和代码库上下文
2. 创建个人迷你基准测试：将这些失败案例放入沙箱环境，用不同模型反复测试
3. 关注实际成本效益：不要只看通过率，还要综合考虑token消耗、时间和费用
4. 选择与你工作方式匹配的模型：如果你的提示风格是简短的行为描述，GPT-5.5可能是最佳选择；如果你倾向于详细的步骤指引，结论可能不同

DeepSWE的出现标志着AI编程基准测试进入了一个更成熟的阶段。它不完美，但它终于开始衡量我们真正关心的东西——模型在真实开发场景中解决真实问题的能力。