在软件工程的世界里，修复缺陷和实现功能的任务已经被先进的大语言模型掌握得相当成熟，这使得它们可以在相对无人监督的情况下有效执行这些“有限修复（bounded repair）”的工作。然而，真正的工程师工作远不止于此。DeepSWE模型开始向我们展示当考题从简单的“改几行代码”演变为跨文件的复杂重构时，顶级模型的表现将面临巨大的挑战，从之前的96%通过率骤降至70%。然而，DeepSWE并不是最终的挑战，真正考验Coding Agents能力的在于整个代码库的演进。

这项令人鼓舞但颇具挑战性的任务是将一个包含20万行代码的系统，从C语言完全重写为Rust，要求接口保持不变、行为完全一致，并且旧代码必须彻底删除。AI目前的能力尚无法应对这一巨大挑战。最近，Einsia AI旗下的Navers Lab发布了一项新的基准测试——SWE Refactor Bench。该项目一经推出便引起了广泛关注，短时间内获得了50万次浏览，并且在海外社区引发了3000多次讨论。论文题目为《SWE Refactor Bench: Can Coding Agents Complete a Long-Horizon, Whole-Repository Stack Migration?》，项目主页提供了相关详细信息。

SWE Refactor Bench与DeepSWE的侧重点不同，前者着重于“重建”。该基准涉及20个真实开源项目，包括SQLite、zlib、libsodium和GraphHopper等，总行数高达86.7万，涵盖了10,594个文件。任务分为四个主要类别：语言重写（如C到Rust、C到Java等）、框架迁移（例如Flask到Starlette、Vue到React等）、平台移植（如POSIX到WebAssembly）、构建工具迁移（如Autotools到CMake）等。每个任务的核心要求是将整个代码库迁移到新的技术栈，同时确保旧的代码完全消失，外部行为保持完全一致。

SWE Refactor Bench的评测过程并非简单的跑一遍测试，设置了三道严格的关卡，任一关卡未通过则视为出局。第一关是迁移审查，要求旧技术栈从源码和构建结果中全面消失，否则直接否决。第二关是功能测试，需要在130,118项检查中确保行为的一致性。若前两关均通过，最后迎来的将是最具挑战性的第三关——模拟AI自身编写的代码遭到黑客攻击。六个独立的Coding Agent验证器，每个拥有一小时时间，向提交的代码发起攻击，只有找到可执行反例的情况才被认可。

结果显示，验证器发现漏洞的中位时间仅为17分钟，最强的验证器（Claude Opus-5）其破防率超过50%，而其他模型的破防率则约为24%。在此次测试中，众多模型未能取得成功，最终只有28次提交在所有评测中获胜，成功率仅为5.4%。更令人沮丧的是，有三个模型在所有任务中都没有生成任何可接受的提交。520次尝试中，340次（65.4%）通过了迁移审查，而118次（22.7%）达到了完整的行为测试，只有88次同时满足这两个条件进入第三轮，最后生存下来的是可怜的28次，20项任务中更是有13项无人成功解答。

在此环境下，“完成迁移”和“保持行为”并不是同一回事，这便是SWE Refactor Bench给出的反思。

传统基准测试通常以“有缺陷的代码”为起点，成功修复之后便能证明工作完成。然而，迁移任务的出发点却是一个已经正常运行的系统。若AI将原代码原封不动地提交，测试依旧通过——尽管行为一致，但实际上并未完成迁移。论文提到这种现象为“盲区”：其问题并不在于测试不够，而是AI根本无法察觉“是否已修改”。而且，这种拖延并非唯一的问题——模型们也曾选择冒险，252次提交中坚持执行迁移，但却未能保持功能的一致性，留下了无数的挑战等待解决。