想象一下，你是一位建筑大师，多年来致力于设计一座宏伟而复杂的城堡。现在，想象一下你雇佣了一个超级聪明、速度极快的机器人助手来帮助你翻修这座城堡。你的目标不是改变城堡的运作方式——人们仍然需要能从厨房走到卧室而不至于掉进地板里——而是要让走廊更宽敞、房间更明亮，并让结构更易于维护。这就是**代码重构（code refactoring）**的世界：在不破坏其运行的软件的前提下，对计算机代码进行清理和重新组织的工程。

长期以来，我们一直拥有一些工具，它们就像代码的初级拼写检查器，能够指出格式混乱或明显的错误。但最近，一种新型的“机器人”出现了：大语言模型（LLMs）。把它们想象成AI助手，它们读过几乎所有的书籍、手册和说明书。它们非常擅长编写新的故事或修复破碎的句子。然而，当你要求它们去翻修一座复杂的城堡（即一个软件项目）时，它们有时会表现得过于“有创意”。它们可能会移动一堵支撑屋顶的墙，或者以一种让所有人找不到厨房的方式重新命名一扇门。核心问题在于：我们能否信任这些AI机器人安全地进行翻修，还是说它们需要人类监督员来复核它们的工作？

这正是论文 《RefactorAssist: 用于可靠代码重构的代理式精炼》（RefactorAssist: Agentic Refinement for Reliable Code Refactoring） 所研究的内容。研究人员 Jonathan Cordeiro、Shayan Noei 和 Ying Zou 想要观察这些 AI 机器人是否能在不破坏代码的情况下对其进行修复，以及如果它们真的搞砸了，一个聪明的“修复代理（repair agent）”能否修复机器人的错误？

机器人的第一次尝试：喜忧参半

团队首先要求几种不同的 AI 模型（包括像 StarCoder2 这样的开源模型和像 GPT-4o 这样强大的商业模型）对真实的 Java 软件项目进行翻修。他们将软件视为一个带有内置“健康检查”系统的生命体，这个系统被称为单元测试（unit tests）。这些测试就像一系列检查点：如果代码被正确修改，机器人就会通过测试；如果机器人意外破坏了某个功能，测试就会失败。

结果令人震惊。即使是最优秀的 AI 模型（如 GPT-4o），也只能在约 80.8% 的情况下完成正确的翻修。这意味着近 五分之一 的时间里，AI 试图改进代码，却意外地破坏了某些东西，导致软件无法通过健康检查。研究人员发现，仅仅给 AI 提供更多关于如何翻修的示例（一种被称为“少样本提示/few-shot prompting”的技术）并没有起到太大作用。问题不在于 AI 不知道如何翻修，而在于它对*上下文（context）*的理解不够深入，从而无法避免做出微妙且危险的错误。

为什么机器人会失败？

为了找出问题所在，研究人员化身为侦探，对失败的代码进行“犯罪现场”调查。他们发现 AI 的错误可以分为八大类，其中最常见的是：

1. 幻觉与上下文混淆 (24.3%)： AI 会凭空捏造新功能，或者在不需要修改的地方进行修改，因为它误解了代码的“故事”。
2. 不一致的重命名 (15.3%)： AI 会在某处重命名一个变量（比如把“门”改名为“闸口”），却忘记在其他所有地方同步更新名称，导致代码陷入混乱。
3. 添加多余内容 (13.7%)： AI 会意外地添加原本不应该存在的变量或函数。
4. 代码不完整 (11.3%)： AI 在写到一半时突然停止，留下了残缺的部分。
5. 语法与结构错误 (9.7%)： 基础性错误，比如忘记写闭合括号或分号。
6. 边缘情况 (9%)： AI 忘记处理罕见情况，例如当用户输入 0 而不是数字时该怎么办。
7. 类型处理 (8.7%)： 混淆不同的数据类型，比如试图把一条文本信息放入数字框中。
8. 作用域问题 (8%)： 尝试在变量不存在的地方使用该变量。

迎来 RefactorAssist：超级督察

研究人员意识到，仅仅要求 AI 再试一次是不够的。他们需要一个能够自动捕捉并修复这些错误的系统。于是，他们构建了 RefactorAssist，这是一个智能的“修复代理”，充当两阶段质量控制督察员。

第一阶段：快速修复（静态修复）
在询问 AI 重新思考之前，RefactorAssist 会先运行一个基于规则的快速检查。这就像一个不需要理解故事、只需要检查语法的拼写检查器。它修复明显的错误，如缺失的导入（imports）、括号不匹配以及简单的类型错误。这一步成本低且速度快，因为它不需要动用沉重的 AI 大脑。令人惊讶的是，这个简单的步骤修复了很大一部分问题，仅通过清理语法就将成功率从 66.1% 提升到了 74.4%（在最佳配置下甚至达到了 80.3%）。

第二阶段：侦探工作（代理式修复）
对于剩余的损坏代码（即在快速修复后仍然失败的代码），RefactorAssist 进入“代理模式”。它收集所有证据：失败测试产生的错误信息、AI 所做的具体更改（即“diff”）以及周围的代码上下文。然后，它要求一个强大的 AI（如 GPT-4o）扮演侦探的角色，解释代码为什么失败并提出修复建议。这位侦探不仅仅是靠猜，它会利用证据来引导修复过程。

这个两阶段过程的结果令人印象深刻。在经历了初始 AI 尝试、静态修复以及随后的迭代侦探工作后，成功率攀升到了 94.2%。至关重要的是，该系统能够修复在“初始静态修复步骤之后”所剩余的所有失败案例中的 70.8%。这意味着，对于那些 AI 搞砸了且语法检查无法修复的翻修任务，RefactorAssist 侦探代理成功找回了绝大部分，使总成功率接近完美。

什么方法没起作用？

研究人员还测试了一些他们认为可能有用但实际效果较差的想法。例如，他们尝试加入一个“检索（retrieval）”系统，通过搜索整个项目来为 AI 提供额外的背景信息。虽然这在修复最初几秒钟内确实有一点帮助，但它并没有帮助 AI 解决长期的难题。论文指出，拥有一个清晰、准确的关于“为什么出错”的解释（即“诊断”），比拥有海量的额外上下文要重要得多。

总结

这篇论文并不是声称 AI 现在已经可以完美地独立进行代码重构。事实上，它证明了如果没有帮助，AI 出错的概率约为 20%。然而，它表明通过结合简单的、快速的“语法检查”与智能的、基于证据的“侦探代理”，我们可以修复大部分此类错误。

核心结论是，RefactorAssist 可以将一段混乱、损坏的 AI 生成的翻修代码，转化为一段安全、可运行的代码更新，其成功率高达 94.2%。它表明，软件工程的未来不仅仅在于拥有更聪明的 AI，而在于构建一个团队：由 AI 完成繁重的体力活，而由专门的修复代理在错误到达用户之前将其拦截。这提醒我们，即使是超级聪明的机器人，也需要一支优秀的质量控制团队来确保它们能交出最好的作品。