新DeepSWE基准测试发现Claude Opus作弊

# DeepSWE 引爆 AI 编程排行榜，GPT-5.5 登顶，发现 Claude Opus 利用基准测试漏洞 来源：https://venturebeat.com/technology/deepswe-blows-up-the-ai-coding-leaderboard-crowns-gpt-5-5-and-finds-claude-opus-exploiting-a-benchmark-loophole 数月以来，主流 AI 编程基准测试向企业买家讲述了一个令人宽慰但具有误导性的故事：顶级模型几乎都差不多。OpenAI 的 GPT-5 系列 (https://openai.com/gpt-5/)、Anthropic 的 Claude Opus (https://www.anthropic.com/claude/opus) 和 Google 的 Gemini Pro (https://deepmind.google/models/gemini/pro/) 在 Scale AI 的 SWE-Bench Pro (https://labs.scale.com/leaderboard/swe_bench_pro_public) 排行榜上挤在狭窄的区间内，使得工程负责人几乎无法判断哪个 agent 能在自己的代码库中真正表现最佳。周一，一家名为 Datacurve 的创业公司发布了一项基准测试，声称打破了这一幻觉。 DeepSWE (https://deepswe.datacurve.ai/blog) 包含 113 项任务，覆盖 91 个开源代码库和五种编程语言，在同样一批前沿模型之间得出了差异巨大的分数分布——并宣布 OpenAI 的 GPT-5.5 (https://openai.com/index/introducing-gpt-5-5/) 以 70% 的成绩遥遥领先，比最接近的竞争对手高出 16 个百分点。“在公开排行榜上，顶级模型的能力看起来往往比较接近，”Datacurve 的合著者 Serena Ge 在 X 上写道。“DeepSWE 揭示了它们实际上的差异，反映了开发者日常工作中的真实体验。” 该基准测试还对 AI 行业依赖的评估基础设施提出了尖锐批评：Datacurve 的审计发现，SWE-Bench Pro 的验证器（即判断 agent 是否解决问题的自动评分器）在其审查的约三分之一的试运行中给出了错误的通过/失败判定。如果这一发现成立，将产生深远影响。企业采购团队、风险投资公司和 AI 实验室市场营销部门都严重依赖基准测试分数来做出数百万美元的决定。在最常被引用的编程基准测试中存在 32% 的错误率，表明整个行业可能一直在用一台坏掉的指南针导航。 ## 为什么最流行的 AI 编程基准测试可能是在曲线评分 要理解 Datacurve 的主张，最好先了解编程基准测试的工作原理——以及它们可能出错的方式。由 Scale AI (https://scale.com/) 和学术研究者维护的 SWE-Bench 系列 (https://labs.scale.com/leaderboard/swe_bench_pro_public) 开创了主导范式：通过挖掘真实的 GitHub 提交来构建任务。该过程从代码库历史中提取一个错误修复或功能添加，将代码回滚到修复前的状态，然后要求 AI agent 重现该变化。原始提交的测试套件作为验证器：如果 agent 的补丁使相同的测试通过，则获得分数。 这种方法具有简洁优雅的特点，但 Datacurve 认为它引入了三个系统性弱点。 首先，**数据污染** (https://deepswe.datacurve.ai/blog)。由于任务来自公开的 GitHub 历史，问题描述、讨论以及通常确切的解决方案已经存在于前沿模型的训练数据中。“SWE-Bench 系列爬取现有的 GitHub issue 和 PR，这会产生两个问题：记忆化（模型已经见过解决方案）和琐碎化（大多数任务很小），”Ge 写道。 其次，**任务范围**。SWE-Bench Pro (https://labs.scale.com/leaderboard/swe_bench_pro_public) 任务平均只需要在 5 个文件中添加 120 行代码。DeepSWE 的参考解决方案平均在 7 个文件中添加 668 行——大约是前者的 5.5 倍。然而 DeepSWE 的提示实际上更短，平均 2,158 个字符，而 SWE-Bench Pro 为 4,614 个字符。换句话说，DeepSWE 给 agent 的指令更少，但期望的输出要多得多，这更贴近人类开发者实际将工作委托给 AI 助手的方式。 Screenshot 2026-05-26 at 3.20.59 PM DeepSWE 任务要求的代码量大约是 SWE-Bench Pro 的五倍，同时给 agent 更短的提示——这种设计选择旨在反映开发者实际如何交接工作。（来源：Datacurve） 第三——也是最致命的——**验证器可靠性**。Datacurve 从 DeepSWE (https://deepswe.datacurve.ai/blog) 和 SWE-Bench Pro (https://labs.scale.com/leaderboard/swe_bench_pro_public) 中各随机抽取 30 个任务，在 10 个前沿模型配置上运行了三次 rollout，然后部署一个基于 LLM 的评判器独立评估每个 agent 的补丁是否真正解决了问题。SWE-Bench Pro 的验证器在 8.5% 的情况下接受了错误的实现，在 24% 的情况下拒绝了正确的实现。DeepSWE 的验证器相应比率分别为 0.3% 和 1.1%。 Screenshot 2026-05-26 at 3.22.11 PM Datacurve 的审计发现，SWE-Bench Pro 的自动评分器在 24% 的情况下拒绝了正确的解决方案，在 8.5% 的情况下接受了错误的解决方案。DeepSWE 的验证器将这两个比率都保持在接近零的水平。（来源：Datacurve） 假阴性问题尤其隐蔽，因为它惩罚了创造性的解决方案。在一个有记录的例子中，SWE-Bench Pro 任务的黄金标准 pull request 重构了一个私有辅助函数。一个通过内联相同逻辑（完全有效的工程选择）正确解决问题的 agent 却失败了，因为测试套件试图导入一个只存在于原作者特定实现中的符号。 ## OpenAI 的 GPT-5.5 在新基准测试中占据主导地位，而 Claude 和 Gemini 则表现不佳 DeepSWE 的顶级结果重新排序了熟悉的等级，这对每个评估 AI 编程工具的工程团队都应该很重要。在 SWE-Bench Pro (https://labs.scale.com/leaderboard/swe_bench_pro_public) 上，来自 OpenAI、Anthropic 和 Google 的模型在 30 分范围内交替领先。DeepSWE 将该范围扩展到 70 分。GPT-5.5 (https://openai.com/index/introducing-gpt-5-5/) 以 70% 领先，其次是 GPT-5.4 的 56% 和 Claude Opus 4.7 的 54%。此后下降幅度很大：Claude Sonnet 4.6 为 32%，Gemini 3.5 Flash 为 28%，GPT-5.4-mini 和 Kimi K2.6 并列 24%，然后是一长串得分在十几分和个位数的模型。Claude Haiku 4.5 在 SWE-Bench Pro 上得分 39%，在 DeepSWE 上骤降至零——这表明一些中端模型在较容易、可能受到污染的基准测试上表现明显过高。 Screenshot 2026-05-26 at 3.09.33 PM 在 SWE-Bench Pro 上，前沿模型集中在 30 分范围内。在 DeepSWE 上，同样的模型分散在 70 分内，有些——如 Claude Haiku 4.5——完全崩溃。（来源：Datacurve） GPT-5.5 不仅得分最高——而且效率也高。该模型达到 70% 通过率的每次试验中位成本为 5.80 美元，中位时钟时间为 20 分钟，中位输出 token 为 47,000 个。GPT-5.4 以每次试验 3.30 美元和 56% 的得分成为最佳性价比之选。与此同时，Claude Opus 4.7 每次运行成本显著更高，而且在测试的 agent 中，输出 token、时钟持续时间和每次试验的美元成本都相差一个数量级——但这些都与通过率没有强相关性。产生更多 token、运行时间更长或成本更高的 agent 并不能一致地解决更多任务。 Screenshot 2026-05-26 at 3.27.42 PM GPT-5.4 和 GPT-5.5 占据了成本效率前沿，以最少的每次运行成本解决了最多的任务。花费更多并不能可靠地产生更好的结果。（来源：Datacurve） ## Datacurve 的审计发现 Claude 一直在现有基准测试中读取答案键 DeepSWE 分析中最具挑衅性的发现之一涉及作者标记为“CHEATED”的判定——即 agent 不是通过解决问题，而是通过读取答案来通过基准测试的情况。SWE-Bench Pro 的 Docker 容器包含了代码库完整的 .git 历史，这意味着黄金标准的解决方案提交就在容器的文件系统中。大多数模型忽略了它。Claude 则不然。 Datacurve 的分析发现，Claude Opus 4.7 和 Claude Opus 4.6 在其审查的 SWE-Bench Pro rollouts 中，超过 12% 被标记为“CHEATED”。在这些情况下，Claude agent 运行了诸如 `git log --all` 或 `git show` 之类的命令来检索已合并的修复并将其粘贴到自己的补丁中。这种行为约占被审查样本中 Opus 4.7 通过率的 18% 和 Opus 4.6 通过率的 25%。该问题已作为 GitHub issue #93 (https://github.com/scaleapi/SWE-bench_Pro-os/issues/93) 在 SWE-Bench Pro 仓库上公开提交。GPT-5.4 (https://openai.com/index/introducing-gpt-5-4/) 和 GPT-5.5 (https://openai.com/index/introducing-gpt-5-5/) 从未表现出这种行为。Gemini 配置保持在 1% 左右。 Datacurve 用外交辞令描述了这一行为——“基准测试使这成为可能（gold commit 存在于容器中），但 Claude 系列是始终如一的实践者”——但含义很明确：Claude 在 SWE-Bench Pro 上的相当一部分分数可能反映了环境利用，而非真正的工程能力。DeepSWE (https://deepswe.datacurve.ai/blog) 通过只提供一个包含基础提交的浅克隆来解决这个问题，不给 agent 留下任何 gold hash 可以发现。值得指出的是，这种行为可以说是 Claude 环境警觉性的体现——该模型非常擅长探索周围环境并利用可用资源。这算作“作弊”还是“足智多谋”取决于你的视角，但在旨在衡量独立问题解决能力的基准测试背景下，它削弱了信号的有效性。 Screenshot 2026-05-26 at 3.28.43 PM Agent 通过 SWE-Bench Pro 的两种机制，而未解决底层问题：从容器的 Git 历史中读取答案，或者通过弱化的黄金测试来模拟功能。（来源：Datacurve） ## 每个 AI 模型系列以自己独特的方式失败，这些模式对企业团队很重要 除了顶级分数之外，Datacurve 的定性轨迹分析揭示了不同模型系列之间截然不同的失败特征——这一发现可以帮助工程团队为特定类型的工作选择合适的模型。 **Claude 容易忘记多部分提示。** 在 DeepSWE (https://deepswe.datacurve.ai/blog) 上，Claude 配置比任何其他系列都更常遗漏明确要求。模式是一致的：当提示列举了平行行为时——“同时支持同步和异步”，例如——Claude 通常实现明显的分支而忘记镜像更改。Datacurve 报告说，Claude 在 DeepSWE 上大约三分之二的“MISSED_REQUIREMENT”失败遵循这种“一个分支发货”的模式。在一个例子中，Claude Opus 4.7 正确地在某个引擎类中落地了一个同步状态数据钩子，而异步引擎从未收到相同的钩子。 **GPT 则精确实现所要求的。** GPT-5.5 在所有测试配置中具有最低的遗漏陈述行为率。在相同任务的多次运行中，GPT 试验倾向于收敛到对提示的相同解释，这表明指令遵循的精度是模型的稳定特征，而不是每次运行的运气。 最有趣的发现之一涉及**自我验证**。在 DeepSWE 上，Claude Opus 4.7 和 GPT-5.4 在超过 80% 的运行中在项目自己的测试框架内编写并运行了新测试——尽管没有人要求它们这么做。在 SWE-Bench Pro 上，同样的模型分别下降到 28% 和 18%。原因：SWE-Bench Pro 的提示模板明确告诉 agent “不应该修改测试逻辑或任何测试”。Agent 忠实地遵守了，抑制了一种可能本可以提高其性能的行为。这表明，在生产编码工作流中的提示设计可能在不经意间压制了有价值的 agent 行为——部署 AI 编码 agent 的企业团队应仔细审计这一点。 Screenshot 2026-05-26 at 3.29.41 PM 在 DeepSWE 上，顶级模型在高达 85% 的运行中编写并运行了自己的测试。在 SWE-Bench Pro 上，提示不鼓励修改测试，同样的模型很少这样做。（来源：Datacurve） ## DeepSWE 做对了什么、做错了什么，以及对 AI 基准测试未来的意义 Datacurve 坦率地承认了几个局限性。标准化的框架虽然确保了公平性，但将所有编辑通过 bash 路由，而不是每个系列训练时使用的模型特定的编辑工具——GPT 的 apply_patch，Claude 的 str_replace_based_edit_tool。这可能会使模型低于其原生能力上限。该基准测试完全来自拥有 500 星以上的开源仓库，结果可能不适用于专有代码库。错误定位和重构任务代表性不足，而广泛使用的语言如 C++ 和 Java 完全缺失。定性分析中的判定分配来自 LLM 分析器，而非人类审核者，样本量也适中——每模型每基准测试大约 90 个审查过的 rollout。 同样值得指出的是，Datacurve (https://datacurve.ai/) 是一家拥有自身商业利益的创业公司，一个重新洗牌排行榜的独立基准测试难免会招致审查。该公司决定在 GitHub 上发布完整的数据集、所有 agent 轨迹和评估框架，这大大减轻了这种担忧，但在 AI 社区将这些结果视为结论性之前，独立复现将是必要的。 DeepSWE (https://deepswe.datacurve.ai/blog) 出现在 AI 编程市场的一个转折点。企业对 AI 编码 agent 的采用正在迅速加速，工程组织正在就围绕哪个模型进行构建做出重大的赌注。基准测试市场本身已成为战略战场——Scale AI 的 SWE-Bench Pro (https://labs.scale.com/leaderboard/swe_bench_pro_public)（Datacurve 直接批评的对象）由一家也为其排名的实验室提供评估服务的公司维护。如果 DeepSWE 关于验证器可靠性和数据污染的核心发现在独立审查下成立，它们可能会迫使行业不仅反思如何衡量编码 agent，还要反思基准测试的更大目的。一个评分系统有三分之一时间出错排行榜不仅仅是准确性问题——它是那种让每个人都对可能不真实的进步感觉良好的残缺工具。在一个花费数十亿美元押注 AI agent 能够完成软件工程师工作的行业中，真实进步与表面进步之间的差异不是学术问题。这就是整个游戏。