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 任务的失败模式