AI编程进入下半场！新基准不测补丁，拷问真正的工程能力

新智元报道

【新智元导读】AI写代码已从补丁阶段进入全流程工程评估，SWE Atlas 首次系统评测代码理解、测试编写与重构等核心能力。结果显示，尽管GPT-5.4等模型能完成基础功能，但在代码健康、边界覆盖和跨文件协调上仍有明显不足。

当全世界都在用SWE-Bench类基准为编程智能体封神时，Scale AI抛出了一颗深水炸弹：SWE Atlas。

在这套由资深工程师手写的284道考题里，前沿模型集体掉档，Pass@1 最高仅43.49%，做三次能全对的比例骤降30~50%。

更扎心的是，模型们写代码修bug的能力一骑绝尘，但在代码理解、测试编写、重构这些专业工程师真正在做的事情上，几乎全员翻车。论文戳穿了一个残酷真相：当前最强的AI编程智能体，是优秀的补丁工，却仍然是糟糕的工程师。

过去两年，AI写代码的叙事被反复刷新，OpenHands、Agentless、SWE-Bench、SWE-Bench Pro、TerminalBench……每一次榜单更新，都伴随着新一轮AI替代程序员的喧嚣。

但你有没有想过一个问题：所有这些基准，几乎都在做同一件事，修bug和加feature。

而真实世界里的软件工程，远远不止这两件事。一位工程师真正的日常，是阅读陌生代码库、为新功能写测试、对历史代码做重构、回答队友的架构问题、debug一个只在生产环境复现的运行时异常……这些上游和下游的能力，几乎被所有主流benchmark集体无视。

Scale AI团队近期发布的SWE Atlas正是要把这块评测盲区补上。

论文链接：https://arxiv.org/pdf/2605.08366v1

修bug不等于会工程

论文一开篇就给出了一个犀利的判断：

把软件工程等同于功能修复，会制造一个关键盲区。专业的软件工程，是维护代码健康、防止未来回归、理解复杂架构，而这些能力在现有基准中几乎都没有被有效评估。

研究团队进一步指出，过度专注于功能解决，会让 Agent 被训练成excellent patchers（优秀的补丁工），却是poor engineers（糟糕的工程师），能修 bug 能加功能，但写不出可维护的代码、留不住一个仓库的长期健康。

为此，SWE Atlas 选择了三个被严重低估、却在职业开发中无处不在的工作流：

• Codebase Q&A（代码库问答，124题）：上游能力，深度理解陌生代码库，回答架构、运行时行为、安全相关的问题；

• Test Writing（测试编写，90题）：下游能力，为指定行为撰写生产级测试，覆盖单元测试、集成测试和端到端验收测试；

• Refactoring（代码重构，70题）：横向能力，在不改变可观测行为的前提下重组代码，处理重复、迁移、模块化等问题。

全部284道任务，由资深工程师手写，取材自18个活跃维护的开源仓库。

图 1：SWE Atlas一览。左：三大工作流及子类目的任务分布（共 284 题）；右：三个工作流的真实任务样例。

不止跑测试

量化工程素养

SWE Atlas 与以往基准最关键的差异，在评估方式上。

传统基准用 test suite 跑通与否来判定 Pass/Fail，本质上只是衡量能不能用。而 SWE Atlas 引入了rubric-based LLM-as-a-Judge，让 LLM 按照专家编写的结构化打分表，对答案的工程严谨度逐项打分。

每道题平均有多少条打分项？答案让人咋舌：

• Codebase Q&A 平均 10.5 条 rubric

• Test Writing 平均 17.1 条 rubric

• Refactoring 平均 17.4 条 rubric + 平均 18 条测试

这些rubric涵盖的是真正的代码评审视角：测试是否覆盖了边界条件？重构后是否清除了旧定义？文档是否同步更新？是否引入了反模式？是否破坏了接口？这些问题，传统 Pass/Fail 测试根本看不见。

更进一步，所有任务都经过独立专家三审，3 位专家中至少 2 位认为有效，rubric 才会保留。整套数据集、评测脚本、judge prompt 已全部开源。

GPT-5.4摘冠

但全员刚刚及格

研究团队把当前最强的前沿模型与顶级开源模型一同送上考场，分别在厂商自家 scaffold（Codex CLI、Claude Code、Gemini CLI）和极简 mini-SWE-Agent两套环境下运行，跑 3 次取平均。

表 1：SWE Atlas 各模型综合通过率。Pass@1 为单次平均通过率，Pass³ 为三次试验全部通过的比例（一致性指标）。

几个非常扎眼的结论：

1. 第一档：GPT-5.4 与 Opus 4.7 几乎并驾齐驱。

在 native scaffold 下，GPT-5.4（Codex）以43.49%的 Pass@1 拿下第一，Opus 4.7（Claude Code）以41.89%紧随其后，两者在统计意义上几乎打平。

2. 开源模型仍有显著差距。

在 mini-SWE-Agent 这套裸跑环境下，开源最佳 GLM 5 拿到 24.03%，而前沿模型最高（Opus 4.7）能跑到 38.94%，15 个点的鸿沟依然清晰。Kimi K2.5、Minimax M2.5 落在 15–19% 区间。

3. 真正震撼的，是Pass³。

三次都通过的比例，相对单次成绩普遍下滑 30~50%。GPT-5.4 的 Pass³ 仅 29.2%，Opus 4.6 跌到 22.9%，开源模型大多在个位数。换句话说，当前 SOTA 模型在做这些任务时，运气成分依然很大，多跑一次就可能不会做了。

功能对了，为什么分数还是不高？

论文最有意思的部分，是揭示了功能正确和工程合格之间那道巨大的鸿沟。

图 2：工程质量明显落后于功能正确性。上：所有模型通过功能检查（变异测试 / 回归测试）的比例都高于通过 rubric 的比例；下：rubric 类目细分，Test Comprehensiveness、Code Maintainability、Artifact Cleanup 是前沿与开源拉开差距的关键。

在Test Writing任务上，模型们写出的测试套件，通过变异测试（Mutation Test）的比例普遍高于通过rubric的比例，差距在10–15个点。也就是说，模型能写出看起来能跑、能抓bug的测试，但严谨度上仍有明显缺陷。

而Refactoring任务的差距更夸张：

如果只看回归测试是否通过，每个模型的得分都能高达 60–80%，看上去都很能打。但一旦拉上 rubric 打分，分数立刻被腰斩，这正是当前饱和型基准的盲点。

翻译过来就是：模型能在保持行为不变这件事上蒙混过关，但真正完成重构的结构性工作（如清理旧定义、提取模块、修正反模式）大多没做到位。前沿模型与开源模型的差距，正好集中在Code Maintainability（代码可维护性）和Artifact Cleanup（旧产物清理）两项上。

Codebase Q&A：高分模型，都在跑代码

图 3：Codebase Q&A 任务的失败模式。左：解决率与代码执行次数 / 答案长度的关系，会跑代码的模型更能赢；右：四类失败模式的分布，不同厂商模型各有各的病灶。

团队发现了一个非常有意思的相关性：在 Codebase Q&A 任务上得分最高的模型，往往拥有最高的平均代码执行次数。

人工审查这些代码调用后他们发现，最强模型不是在静态看代码，而是在真正把应用跑起来、发请求、做运行时分析。这种实验型行为模式，跟一个资深工程师 debug 时的直觉惊人地相似。

反之，失败的模式可以拆成四类：信息缺失、答案错误、无运行时证据、跑偏目标。GPT 系列模型主要败在信息不完整（Missing Info），做了实验但没覆盖完所有 rubric 子问题；Claude 系列则主要败在缺乏运行时证据（46%），明明是运行时问题，却选择只读静态代码。

Test Writing：测试写得多 ≠ 测试写得好

图 4：Test Writing 任务下，模型在 Manifest / Mutation / Rubric 三类检查上的成功率，以及测试数量与质量的关系。

另一个反直觉的发现来自 Test Writing：

写得越多，不一定写得越好。论文观察到一个清晰的模式：较弱的模型倾向于堆数量，但这些测试大多只验证函数应该做什么，几乎从不测函数不应该做什么、什么应该保持不变，以及那些会暴露细微行为偏差的边界场景。

结果就是：测试套件看起来很丰满，但变异测试一打就漏，一个 mutant 改了代码，测试照样全绿。

研究团队指出，越强的模型反而写得越少、越精准，每个测试都瞄准一个具体的回归点。这才是专业测试工程师该有的写法。

Refactoring：跨文件重构，前沿模型也会漏掉调用点

图 5：重构任务的能力随改动规模衰减。左：按 gold patch 的代码行数分桶，所有模型在改动量增大时全线崩溃；右：file-edit recall 上前沿模型覆盖更多文件，但仍会漏掉关键调用点。

SWE Atlas 中的重构任务，gold patch 改动从 35 行到 2073 行不等。结果如图 5 所示：所有模型的解决率，都随着改动规模增大而显著下降。

更精细的分析揭示，前沿模型确实能覆盖更高比例的需要修改的文件，但即便是最强的 Opus 4.7，也会在跨文件的调用点（call sites）上漏掉一部分。换句话说，它们看到了主要的修改入口，却没能把改动一致地传播到整个调用图。

这意味着：当一次重构需要在多个文件之间做协调一致的改动时，当前最强模型仍然是不可靠的。

补丁工与工程师

还差一个SWE Atlas

SWE Atlas 给出的结论并不绝望，前沿模型在这套更严苛的考试上能拿到 40% 以上的分数，本身已经是惊人的能力跃迁。

但它也清晰地告诉我们：能修 bug 和是工程师，是两件不同的事。

当前的最优模型已经学会探索代码库、跑通应用做运行时分析、覆盖多文件的修改，这些已经远超 18 个月前的状态。但在边界条件覆盖、可维护性把控、跨文件协调修改、旧代码的清理这些专业工程的软实力上，AI 仍有相当长的路要走。

Scale AI的这项工作，本质上是给整个行业重新校准了一把尺子。别再只盯着SWE-Bench的issue resolution跑分了，真正的软件工程，远比修bug复杂得多。

值得一提的是，第三方评测机构Artificial Analysis近期推出的 Coding Agent Index 已经把SWE-Atlas-QnA与 SWE-Bench-Pro-Hard-AA、Terminal-Bench v2一同纳入，作为完整AI编程栈的三大评测之一。即便是当前榜首组合 Cursor CLI + Claude Opus 4.7，综合 pass@1 也仅有61分，整个榜单的顶尖系统均聚集在40~60分区间，无一突破70 分，这从外部视角再次印证了SWE Atlas评测的严苛度。

而下一代的编程智能体如果想真正接管工程师的工作，得先在 SWE Atlas 上拿到一个像样的分数。

参考资料：

https://arxiv.org/pdf/2605.08366v1

编辑：LRST