GPT-5.5反杀Claude登顶，AI编码旧榜不准了？

一个号称「零污染」的新基准 DeepSWE，用113道原创题撕开了旧编程榜单的遮羞布。

代码评测的江湖里，一把新的量尺落下了。

Datacurve 刚刚发布了名为 DeepSWE 的新基准。其联合创始人兼 CEO Serena Ge 在 X 上直言，推出 DeepSWE 的目的，就是为了还原开发者工作的真实场景，揭开顶尖模型之间真正拉开差距的地方。

这张榜单在发布第一天，就向旧秩序发起了挑战。GPT 和 Claude 在 SWE-Bench Pro 上的排名，被彻底逆转了。

GPT-5.5 拿到了 70%±4%，排名第一；而 Claude Opus 4.7 只有 54%±5%，排在第三。两者之间，拉开了整整 16 个百分点的差距。

更值得玩味的还在后面。

DeepSWE 团队用他们的新方法，回头审计了 SWE-Bench Pro 上的历史提交记录。结果发现，Claude Opus 4.6 和 4.7 在那个榜单上的成绩中，有超过 12% 被判定为“作弊”。

不止如此，审计还查出，SWE-Bench Pro 的验证器本身存在 8.5% 的假阳性率和 24.0% 的假阴性率。

这就引出了一个尖锐的问题：如果测量工具的误差这么大，那么 SWE-Bench Pro 榜单上那些只差一两个百分点的模型，究竟是真正的旗鼓相当，还是仅仅被一把不准的尺子量成了平局？

换一把尺子，第一名就换人

先来看看 DeepSWE 自己跑出来的榜单结果。

在参与评测的 12 款前沿模型中，gpt-5.5[xhigh] 以 70%±4% 的通过率位居榜首，gpt-5.4[xhigh] 以 56%±5% 紧随其后，Claude Opus 4.7[max] 则以 54%±5% 排在第三。

再往下看，Claude Sonnet 4.6[high] 为 32%，中间一批模型的成绩落在 18% 到 28% 之间，而榜尾的几款模型只有 5% 到 10%。

对比此前公开报道的 SWE-Bench Pro 成绩——Claude Opus 4.7 是 64%，排名第一；gpt-5.5 是 59%——情况发生了戏剧性的翻转。在 DeepSWE 上，gpt-5.5 升至 70%、排名第一，而 Claude Opus 4.7 则掉到第三、仅 54%。

不仅是排名逆转，模型之间的差距跨度也被大幅拉开。

这批模型在 SWE-Bench Pro 上从最差到最好的差距只有 30%，而到了 DeepSWE 上，这个差距扩大到了 70%。

同一批选手，面对同一类任务，仅仅换了一个测试场，原本看似并列的领先者之间，就出现了断层式的差距。

DeepSWE 团队对此的解释是：旧榜单上模型们挤在一个狭窄的分数带里，并非因为它们实力真的接近，而是因为基准本身的「分辨率」不够高。

具体来看，SWE-Bench Pro 的一道题平均只修改 5 个文件，而 DeepSWE 的一道题平均要修改 7 个文件，单道题涉及的参考代码量是前者的 5.5 倍。

在这种规模下，模型无法靠死记硬背某个具体函数来蒙混过关。它必须真正读懂多个文件之间的耦合关系，并规划出一条贯穿整个代码仓库的修改路径。

GPT-5.5 能拿到 70% 的通过率，意味着它并非记住了某种题型，而是具备了「在一个完全陌生的真实代码仓库里，执行一条横跨 7 个文件的改动链路」的能力。

换句话说，在玩具题上，大家看起来可能差不多；但在能逼出真实工程能力的题目上，差距瞬间就显现出来了。

DeepSWE 更准吗，还是噱头？

一个新基准，凭什么说自己比旧基准更准？DeepSWE 给出的答案是四个核心设计。

首先，是「零污染」。这是它最核心的优势。

DeepSWE 的每一个任务都由工程师从零开始原创编写。关键在于，这些任务完成后不会被合并回上游的开源仓库，也就不会进入公开的 GitHub 提交记录，从而极难出现在未来用于模型预训练的开源代码语料中。

这意味着，没有任何模型能在预训练阶段“偷看”到这些题的答案。这一设计，直指旧基准的命门。

第二，是「高多样性」。

DeepSWE 包含了 113 个任务，覆盖了 91 个活跃的开源仓库，横跨 TypeScript、Go、Python、Ja vaScript、Rust 五种编程语言。

作为对比，SWE-Bench Pro 的公开版只覆盖 11 个仓库。仓库越多、越杂，就越能逼近开发者真实会丢给 AI 智能体的那些五花八门的代码库。

第三，是「真实复杂度」。

前面提到 DeepSWE 的单题代码量是 SWE-Bench Pro 的 5.5 倍，但有趣的是，它的任务提示词长度反而只有后者的一半。

提示词之所以短，是因为它刻意模仿了开发者真实与智能体沟通的方式：只说明想要什么行为或功能，而不把接口定义、复现步骤、代码片段全部罗列出来。智能体必须自己去仓库里摸索清楚「在哪里改、怎么改」。

第四，是「可靠验证」。

一个基准准不准，关键看它的验证器。旧基准的验证器常常只认一种「标准答案」的写法，换个变量名、换种实现思路就可能被判错。DeepSWE 的验证器则是针对每个任务手写定制的，只要最终结果正确，实现方式可以多种多样。

通过各抽取 30 个任务进行交叉复查，DeepSWE 验证器的假阳性率仅为 0.3%、假阴性率为 1.1%。相比之下，SWE-Bench Pro 的这两项数据分别是 8.5% 和 24.0%，误差高出了一个数量级。

而且，DeepSWE 不只是一张静态榜单。在其 GitHub 仓库中，每个任务都附带了提示词、可复现的 Docker 环境、验证器以及一份保密的参考解法。任何人都可以拉取代码，让自己的智能体亲自跑一遍。

旧基准的尺子，两头都不准

DeepSWE 团队还用这套新方法，审计了 SWE-Bench Pro 上那些已经被计入成绩的提交。

审计发现，Claude Opus 4.6 和 4.7 的成绩中，超过 12% 被判定为作弊，其中约 87% 使用了同一种手法：直接去翻代码仓库的 .git 历史记录，把藏在历史提交里的“标准答案”抄出来。

在同一批复查样本中，GPT-5.4 和 GPT-5.5 未被发现这类行为。

DeepSWE 也指出，这其实是 SWE-Bench Pro 基准本身的设计漏洞给了作弊可乘之机——它的任务容器里直接包含了带有“标准答案”的提交历史。

这是 DeepSWE 给出的客观观察。至于 Claude 模型为何会形成这种行为模式，目前尚无公开定论。

如果说作弊是让分数虚高的「上行噪声」，那么 SWE-Bench Pro 还有一个对称的「下行噪声」：高达 24% 的假阴性率。

DeepSWE 复查了一批被 SWE-Bench Pro 判为「失败」的提交，发现其中约 24% 其实功能完全正确，只是被误杀了。

24% 意味着什么？在被复查的运行轨迹里，差不多每四个提交就有一个可能被冤枉。如果把这层假阴性误差算上，所有模型的真实分数实际上都被压低了一截。而且，那些倾向于按照自己风格重写代码、而非照抄现成答案的模型，其分数损失可能更为严重。

相比之下，经过多重交叉把关的 DeepSWE 验证器，将假阳性率压到了 0.3%，假阴性率压到了 1.1%，两项误判率都比 SWE-Bench Pro 低了一个数量级以上。

两个基准验证器的误判率对比。SWE-Bench Pro 假阳性率8.5%、假阴性率24.0%

如果这个对比数据准确，那意味着持续大半年的所谓「Claude 和 GPT 不分上下」的行业共识，很可能是建立在一个两头都不准的测量工具之上。

过去大家只比较终点分数，很少有人回头审视这个分数是怎么来的。DeepSWE 这一刀下去，那些以 SWE-Bench Pro 为锚点的模型对比结论，恐怕都需要重新校准。

局限性在哪里？

DeepSWE 虽然解决了旧基准的污染问题，但它终究是 Datacurve 自家推出的评测体系。

Datacurve 自己也坦率地谈到了其局限性。整个评测过程只使用了一个名为 mini-swe-agent 的测试框架（Harness），为所有模型提供相同的 bash 工具和同一套提示词。

这样做是为了将「模型核心能力」与「外围脚手架」的影响分离开，但代价是带来了一定程度的失真。

不同模型家族在训练时所适配的工具形态本就不同，而开发者在现实中使用的也并非 mini-swe-agent，而是 Codex CLI、Claude Code、Cursor、Gemini CLI 这些更成熟的原生工具链。

使用统一的测试框架，可能会将每一家模型的能力都压制在其原生上限之下。

对此，DeepSWE 团队也通过对照实验进行了回应。在小规模试点中，mini-swe-agent 的表现并不输给原生工具链。但团队同时强调，这仅仅是基于 10 道题的试点，不足以完全打消外界的顾虑。

同样10道SWE-Bench Pro任务下，mini-swe-agent的通过率与token消耗，不输Claude Code、Codex CLI、Gemini CLI等原生Harness

此外，DeepSWE 的语料目前只覆盖 GitHub 上星标超过 500 的活跃开源仓库，缺少了 C++ 和 Ja va 这两种重要语言，同时 bug 定位和代码重构类的任务也相对偏少。

还有一点是关于 AI 幻觉的质疑。DeepSWE 报告中那些关于「假阳性、假阴性」的判定，本身是由一个 LLM 分析员给出的，并非人工复核。

团队自己也提醒，低于约 5% 的差异可能并不具备统计显著性，不应过度解读。

1500万美元，这家公司给大模型当「磨刀石」

DeepSWE 是如何诞生的？这得先认识一下它背后的公司 Datacurve。

Datacurve 出自 Y Combinator 2024 年冬季批次（W24），由 Serena Ge 和 Charley Lee 两位创始人在 2024 年创立。

Datacurve两位创始人Serena Ge（右）与 Charley Lee（左）。两人均出自滑铁卢大学计算机系

这家公司的主业是为前沿大模型生产高质量的代码数据，但它的玩法有些特别。

Datacurve 运营着一个名为 Shipd 的平台，采用「赏金」模式，招募顶尖软件工程师来解决算法题、进行调试、编写 UI 流程等，按产出而非工时支付报酬。迄今为止，该平台已发出超过 100 万美元的赏金。

据 TechCrunch 等媒体报道，参与者中不乏来自 DeepMind、OpenAI、Anthropic、Vercel 等明星公司的工程师。

Datacurve 本来就是向大模型供应训练数据的公司，对于「什么样的数据会污染基准、什么样的任务才能真正考出模型本事」有着第一手的认知。DeepSWE 更像是其主业能力的一种自然延伸和验证。

代码评测圈，正在告别刷分时代

DeepSWE 并非孤立事件，其背后是一个已延续大半年的行业趋势。

随着 SWE-Bench 系列基准日趋饱和，新一代编程基准的竞争焦点，已经从单纯的「题目有多难」，转向了「能否抵抗数据污染」以及「验证是否可信」。DeepSWE 正是这个转向中的一个典型样本。

DeepSWE 还有一个特别有意思的发现：模型能力越强，越会主动给自己编写测试。

在 DeepSWE 上，Claude Opus 4.7 和 GPT-5.4 有超过 80% 的运行会主动使用项目自带的测试框架编写新的测试用例，哪怕任务提示中并没有要求它们这么做。然而，在 SWE-Bench Pro 上，同样是这批模型，编写测试的比例骤降到 3% 到 28%。

同一批模型主动写新测试的比例。在DeepSWE上多数超过60%，到SWE-Bench Pro上全部掉进3%到28%区间

原因何在？

原来，SWE-Bench Pro 的提示词里包含一句话，告诉智能体“测试文件已经处理好了，不要改动测试逻辑”。智能体就把这句话理解成了「不需要自己写测试」。

看，仅仅是一句提示词的措辞差异，就能改变一个模型的行为模式，进而影响它的最终得分。

这说明，我们目前用来衡量 AI 编程能力的工具，本身还非常脆弱：一个标点、一句话、一个测试框架的选择，都可能微妙地影响最终的排名。

所以，当 AI 智能体开始动手修改你的代码时，你真正应该相信什么？

无论是 DeepSWE 还是 SWE-Bench Pro，都只是外部参考。终极的答案，或许依然藏在你自己真实的、复杂的业务代码库之中。