把20万行代码换一套技术栈，还要行为分毫不差，Claude、GPT全懵了

机器之心发布 从 SWE-bench Verified 到 SWE Pro，再到 DeepSWE，模型们已经把这套题目快刷到头了 —— 修复 bug、实现功能，这些 “ bounded repair ” 任务，当前的大模型已经做得足够好，好到可以放心让它们无人值守地跑。 但真正的软件工程，从来不只是修 bug。 DeepSWE 已经撕开了一道口子 —— 当考题从 “改几行代码” 变成跨文件长任务改写，顶级模型通过率从 96% 跌至 70%。 但 DeepSWE 仍然不是终点。 对 Coding Agents 的终极考验不是本地编辑，而是整个代码库的演进。 把一套 20 万行的系统，从 C 语言整个重写成 Rust，接口不变、行为不变、旧代码全部删掉 —— 这才是工程师日历上真正填满的工作。 而这件事，AI 还远远做不到。 比 DeepSWE 更残酷的 “地狱级” 新基准 Einsia AI 旗下 Navers Lab 最近放出了一个新基准 —— SWE Refactor Bench ，该项目在 X 发布后获得了 50 万次浏览，并引起了海外社区 3000 多个相关讨论。 论文题目：SWE Refactor Bench: Can Coding Agents Complete a Long-Horizon, Whole-Repository Stack Migration? 项目主页：https://lab.einsia.ai/swe-refactor-bench Arxiv：https://arxiv.org/abs/2608.23564 Github repo：https://github.com/Einsia/SWE-Refactor-Bench 如果说 DeepSWE 考的是 “在现有代码库里实现一个新功能”，那 SWE Refactor Bench 考的是 “ 重建 ”。 20 个真实开源项目，包括 SQLite、zlib、libsodium、GraphHopper 这些工业级基础设施，总共 86.7 万行代码、10,594 个文件 。 任务分为四类： 语言重写（7 个） ：C→Rust、C→Java、Python→Go、JavaScript→Rust…… 框架迁移（7 个） ：Flask→Starlette、Express→Fastify、Vue→React…… 平台移植（3 个） ：POSIX→WebAssembly、CommonJS→V8 realm…… 构建工具迁移（3 个） ：Autotools→CMake、Maven→Gradle…… 每一道题的要求都一样：把整个仓库搬到另一个技术栈上，旧代码全部删掉，外部行为分毫不差。 层层设卡：三关之下，无路可退 SWE Refactor Bench 的评测不是跑一遍测试就打分。它设置了三道关卡，顺序执行，任何一关不过即出局。 第一关：迁移审查。 旧技术栈有没有从源码和构建产物中彻底消失？不过则一票否决。 第二关：功能测试。 130,118 项检查，精确校验行为是否分毫不差。 前两关通过之后，迎来最残忍的第三关 ——「 让 AI 当黑客，去黑 AI 自己写的代码 」。六个独立的 Coding Agent 验证器，各有一小时，向这份提交发起攻击，只有可执行的反例才算数。 结果： 验证器找到漏洞的 中位时间：仅 17 分钟 最强验证器（Claude Opus-5）的 破防率超过 50% ，其他模型只有约 24%。 所有模型，全军覆没 8 个前沿模型，26 种配置，20 个任务，总共 520 次独立尝试 ，结果 只有 28 次提交通过了全部三轮评测 —— 成功率 5.4%。 更扎心的是： 3 个模型从头到尾没有产生任何一个可接受的提交 —— 让它们跑 20 个任务，一个都过不了。 把 520 次尝试拆开看： 340 次 （65.4%）通过了 “迁移审查”—— 至少看起来像做了迁移 118 次 （22.7%）达到了 “行为测试的满分”—— 所有预设的测试都通过了 只有 88 次 同时满足这两个条件，进入了第三轮 最终 只有 28 次 活了下来 20 项任务中，13 项无人解出。 两种能力：“完成迁移” 和 “保持行为”，根本不是一回事 偷懒的，和逞强的。 这是 SWE Refactor Bench 最反直觉的设计。 传统 benchmark 的起点是 “有 bug 的代码”—— 测试挂了，修好了就证明你做了事。但迁移任务的起点是一个已经能跑的系统。AI 如果把代码原封不动交回去，测试照样全过 —— 行为满分，但活一点没干。 论文管这叫 “盲区”：不是测试集不够，是它根本看不见 “有没有改”。 而偷懒，只是其中一种。 还有另一条路 —— 逞强。252 次提交硬着头皮把迁移做了，但行为没保住，卡在了功能测试上。代码确实换了，跑起来却不对。 偷懒的，行为满分但没做。逞强的，做了但行为出错。 两条路，都到不了终点。八个模型无一例外，全在这两个方向之间摇摆。 “代码是对的” 和 “迁移是真的”—— 一个都不能少。 而今天最强的模型，至今还没学会同时做到。 最后一公里：99% 的正确率，离交付还差一步 对一次仓库迁移而言，任何一条单元测试不通过都是重大风险 —— 那条失败的测试背后是一个真实的下游消费者，它不会因为另外 99.99% 的行为都对而不出事。 而这恰好是智能体最过不去的一道坎。 在 340 次确实完成了迁移的运行中： 91% 能让固定测试集过半 58% 能到 99% 36% 能到 99.9% 只有 26% 能一条不错 仅最后这一小步就淘汰了已经走到 99.9% 的 123 次运行中的 35 次。而这最后一小步有的导致站点上每一个书签、每一条分享出去的链接都会失效；有的让打出来的包发布出去后，项目主页是一片空白。 这不是测试集吹毛求疵，是迁移本身没做完。 写在最后 SWE Refactor Bench 揭示了三件事： 第一，行为测试在迁移场景下会失效 。 原系统本来就能通过所有测试，AI 交白卷也能拿满分。这不是测试覆盖率的锅，是 “尺子量错了对象”—— 它在测 “有没有改坏”，而不是 “有没有改”。 第二，“完成迁移” 和 “保持行为” 完全是两码事 。 少数模型选择了偷懒压根没做迁移，多数模型选择了逞强最后弄坏了行为。模型能把行为恢复到 99% 以上，但最终经得起全部检查的不到十分之一。难的不是把行为做得接近，而是最后一公里。 第三，AI 会写代码，但还不会做系统级软件工程 。 520 次尝试，仅有 28 次成功。20 项任务，13 项无人解出。 这不是在说 “AI 不行”。 这是在说： 我们终于有了一个能测出 “AI 到底行不行” 的尺子。 代码可以重写。行为分毫不差 —— 这才是最难的部分。 而这，恰恰是软件工程的本质。 © THE END 转载请联系本公众号获得授权 投稿或寻求报道：liyazhou@jiqizhixin.com 文章原文