从 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 到底行不行” 的尺子。
代码可以重写。行为分毫不差 —— 这才是最难的部分。
而这，恰恰是软件工程的本质。
热门跟贴