此前的基准测试（从 SWE-bench 到 DeepSWE）已经显示：大型模型在修 bug、实现小范围改动这类“有限修复”任务上非常可靠，甚至能无人值守地运行。但真正的软件工程远不止这些。把一个运行良好的代码库整体迁移到另一套技术栈、同时保持对外行为一模一样，这才是对自动化编码代理的终极考验。

最近由 Einsia/ Naver Labs 发布的 SWE Refactor Bench 就直指这一难题。它选取了 20 个真实开源项目（包括 SQLite、zlib、libsodium、GraphHopper 等工业级基础设施），覆盖共计约 86.7 万行代码、10,594 个文件。任务分四类：语言重写（如 C→Rust、Python→Go 等，7 项）、框架迁移（如 Flask→Starlette、Vue→React 等，7 项）、平台移植（如 POSIX→WebAssembly，3 项）和构建工具迁移（如 Autotools→CMake，3 项）。每道题都要求把整个仓库搬到目标栈上、删除旧代码，并确保外部行为丝毫不差。

评测由三关依次把关，任何一关不过即宣告失败。第一关是迁移审查：检查旧技术栈是否已从源码与构建产物中彻底移除；未通过直接否决。第二关是功能测试：通过约 130,118 项精确检查以验证行为等价。通过前两关后进入最残酷的第三关——让六个独立的 Coding Agent 在限定时间（各一小时）内尝试攻击提交，只有能跑出的、可执行的反例才算有效漏洞。

结果相当残酷：总计 8 个前沿模型、26 种配置、20 个任务，共 520 次独立尝试，只有 28 次提交通过了全部三轮评测，成功率仅 5.4%。拆开看，340 次（65.4%）看起来完成了迁移审查；118 次（22.7%）在功能测试上取得满分；两者兼具、进入第三轮的只有 88 次；最终仅 28 次活了下来。更糟的是，有 3 个模型对 20 个任务一分未得；20 项任务中有 13 项无人能解。验证器发现漏洞的中位时间仅 17 分钟，其中表现最强的验证器（Claude Opus‑5）破防率超过 50%，其余模型破防率约 24%。

这份基准揭示了一个关键结论：把代码“迁过去”和把外部行为“保持住”是两种截然不同的能力。传统基准从“有 bug 的代码”出发，修好测试就算完成；而迁移题目的起点是一个本就能跑的系统，模型只要把旧代码原封不动交回，测试照样会过——这便是所谓的“盲区”。在这种场景下，AI 既可能选择偷懒（表面上通过迁移审查但实际上没做实质改动），也可能逞强（强行重写导致行为偏离，测试不通过）。

总的来看，DeepSWE 已经显示出当任务从“改几行”扩展为“跨文件长任务改写”时，模型通过率会从高位显著下滑；而 SWE Refactor Bench 更进一步，把挑战扩展到整个仓库和跨栈迁移，结果表明现有的大模型距离能独立完成这类工程级迁移仍有很大差距。