想象一下，你拥有一座巨大的、古老的图书馆，里面装满了用一种非常特定的语言（Java）编写的书籍。这些书运行得非常完美，但其中的故事却很混乱：章节太长，角色命名混乱，有些场景还散落在不同的房间里。**代码重构（Code refactoring）**就是清理这些书籍的过程，目的是让它们更易于阅读和维护，而不改变实际的故事内容或结局。
长期以来，我们一直在教计算机（特别是大型语言模型或 LLM）如何从头开始编写新的故事。但教它们如何在不破坏情节的前提下修复现有的故事，要困难得多。
这篇论文介绍了 SWE-Refactor，这是一个全新的“考试”，旨在测试这些 AI 计算机在清理代码方面的表现。以下是简单的术语拆解：
1. 问题所在：旧的考试存在缺陷
在此之前，研究人员尝试测试 AI 进行代码清理的能力，但这些测试存在三个大问题：
- 过于简单： 它们只要求 AI 进行微小的、单步的修复（比如重命名一个变量），忽略了需要移动整个章节等复杂的任务。
- 数据带有噪音： 有时提供的“正确答案”并不只是清理，还包含了修复漏洞或添加新功能。这会让 AI 感到困惑：“我是应该打扫房间，还是顺便把墙也刷了？”
- 缺失上下文： 真实的代码就像一张网；改变一行代码往往会影响到其他十行。旧的测试没有给 AI 提供足够的“大局观”（整个图书馆），使其无法理解其中的关联。
2. 解决方案：一个真实的 AI “健身房”
作者构建了 SWE-Refactor，一个高质量的、大规模的训练场和考试场。
- 真实的人类工作： 他们没有捏造虚假的例子，而是研究了 18 个真实的、流行的 Java 软件项目。他们找到了 1,099 处人类开发者成功进行代码清理的实例。
- 纯粹的清理： 他们使用了专门的工具来过滤掉任何不属于“纯粹清理”的改动。如果一名开发者在清理的同时修复了一个漏洞，那么这个例子会被剔除。他们只保留了那些“纯粹”的清理过程。
- 完整的图书馆： 他们不仅给了 AI 一页纸，还给了它整本书、图书馆的地图以及谁在阅读什么的清单，以便 AI 理解上下文。
- “金标准”检查： 为了确保 AI 没有作弊，他们检查了三件事：
- 代码是否仍然可以编译（页面是否依然稳固）？
- 所有的测试是否仍然通过（故事是否依然逻辑通顺）？
- AI 是否真的完成了请求的具体清理任务，还是仅仅写了一些能运行的东西？
3. 考试结果：AI 擅长小任务，但在大任务面前表现不佳
作者在这一新考试上测试了 9 种不同的 AI 模型（包括像 GPT-4o 和 DeepSeek 这样著名的模型）。
- 通用型选手胜出： 大型通用 AI 模型（如 GPT-4o）的表现远好于较小的专用编码模型。这表明理解“大局观”比仅仅掌握语法更为重要。
- 简单 vs. 复杂： AI 在处理简单的单步清理（例如“提取方法”，就像把一段话从长章节中抽离出来，并将其变成一个新的短章节）方面表现尚可。
- 复合挑战： AI 在面对**复合重构（compound refactorings）**时表现得非常吃力。这些任务需要同时完成多个步骤，比如“把这段话移到另一个章节，并重命名那个角色”。
- 类比： 想象要求一个机器人搬动一张沉重的沙发。它可以做到。但如果你要求它“搬动沙发，同时刷一下沙发背后的墙，再重新布置地毯”，它往往会忘记某个步骤或者弄乱顺序。
- 数据统计： 即使是一个非常先进的 AI 智能体（OpenAI Codex），在这些复杂的、多步骤的任务中的成功率也仅为 39% 左右。
4. 如何帮助 AI 取得成功
论文还测试了给予 AI 更多帮助是否有效：
- 检索（RAG）： 给 AI 提供类似的清理示例会有一定帮助。
- 多智能体工作流（团队协作模式）： 这是最终的赢家。与其让一个 AI 完成所有工作，不如设置一个“开发 AI”来编写代码，以及一个“评审 AI”来批评它并要求修改。这种“团队”协作模式解决了最多的问题，表明 AI 需要检查自己的工作才能处理复杂任务。
总结
SWE-Refactor 是一个全新的、严格且真实的 AI 代码重构测试。它证明了虽然 AI 在处理小型代码修复方面已经做得很好，但在处理需要理解软件项目各部分如何连接的复杂、多步骤改造时，仍然感到困难。作者发布了所有数据和结果，以便其他研究人员可以使用这个“健身房”来训练未来更好的 AI。
技术摘要：SWE-Refactor
问题陈述
尽管大型语言模型（LLMs）在代码生成方面展现出了显著的能力，但代码重构提出了截然不同的挑战。重构要求进行精确的、保持语义不变的编辑，以在不改变行为的前提下改进程序结构。这项任务需要仓库级的推理能力、对复杂依赖关系的理解以及迭代验证能力——这些能力对于当前模型而言难以评估，且往往超出了它们的能力范围。
现有的代码重构基准测试存在四个关键缺陷：
- 场景覆盖有限： 它们主要关注原子重构类型（单步转换），而非现实开发中常见的复合重构（多步协调转换）。
- 缺乏自动化构建： 许多基准测试依赖于人工策展或 LLM 生成的地面真值（ground truth），这引入了偏差和可扩展性问题。
- 缺乏仓库级上下文： 现有数据集通常缺乏实现现实评估所需的结构化信息（例如类继承关系、调用者/被调用者关系）。
- 数据噪声： 许多基准测试包含了“不纯”的提交，其中重构与 Bug 修复或功能添加混合在一起，导致难以隔离并评估模型的重构能力。
此外，该领域也存在编程语言多样性不足的问题，大多数近期的基准测试仅专注于 Python，尽管 Java 是企业级系统中占主导地位的语言。
方法论：SWE-Refactor
为了填补这些空白，作者引入了 SWE-Refactor，这是一个基于真实世界 Java 项目构建的仓库级基准测试。该基准测试通过一个完全自动化的四步流水线构建：
- 通过静态分析进行挖掘： 作者利用基于 AST 的工具 RefactoringMiner，从 18 个广泛使用的 Java 项目中提取包含重构的提交。
- 纯净重构的策展： 使用 PurityChecker（RefactoringMiner 的扩展）过滤掉不纯的变更（如 Bug 修复），以保留仅有的“纯净”重构。作者手动验证了 200 个随机实例，以确认检测器的可靠性。
- 多层级信息增强： 为了支持仓库级推理，流水线使用 Eclipse JDT 提取全面的上下文，包括项目结构、完整的类体、方法调用者/被调用者以及构建配置。
- 验证： 流水线通过使用适当 JDK 版本编译项目并运行完整的测试套件（使用 JaCoCo）来确保功能正确性，从而验证重构是否保持了原有行为。
数据集组成：
- 规模： 1,099 个由开发者编写的、保持行为不变的重构。
- 来源： 18 个多样化的 Java 项目。
- 类型： 包括 922 个原子实例和 177 个复合实例。
- 重构类型： 涵盖三种原子类型（提取方法 Extract Method、移动方法 Move Method、内联方法 Inline Method）和三种复合类型（提取并移动、移动并内联、移动并重命名）。
评估指标：
该基准测试从两个维度评估 LLM 的性能：
- 功能正确性： 通过编译成功率、测试通过率以及基于 AST 的重构验证（使用 RefactoringMiner 确保预期的转换发生且未产生意外副作用）来衡量。
- 类人程度： 使用 CodeBLEU 来评估与开发者编写的地面真值的相似度。
核心贡献
- SWE-Refactor 基准测试： 一个高质量的新数据集，包含来自 18 个 Java 项目的 1,099 个纯净重构，涵盖了原子和复合转换。它是第一个提供全面仓库级上下文和自动化验证的 Java 基准测试。
- 自动化构建流水线： 一个可复现的四步流水线，用于提取真实世界的重构、过滤纯净度、增强结构化数据，并在无需人工标注或 LLM 生成地面真值的情况下验证正确性。
- 全面评估： 对 9 种广泛使用的 LLM（包括 GPT-4o-mini、DeepSeek-V3 以及各种 CodeLLaMa/Qwen 变体）在不同重构类型和提示策略（简单提示、RAG 和多智能体工作流）下进行了广泛评估。
实验结果
作者在 1,099 个实例上评估了 9 种 LLM。主要发现包括：
- 整体性能： 通用模型优于开源的代码专用模型。DeepSeek-V3 取得了最高的成功率（41.58%），紧随其后的是 GPT-4o-mini（39.85%）。像 CodeLLaMa-7B 这样的开源模型仅实现了 1.10% 的成功率。
- 原子 vs. 复合： 模型在原子重构（局部编辑）上的表现明显优于复合重构（跨文件、多步转换）。
- DeepSeek-V3 在提取方法（Extract Method）方面表现出色（301 次成功）。
- GPT-4o-mini 在移动方法（Move Method）等跨文件任务中展现了更广泛的泛化能力（92 次成功）。
- 开源模型几乎完全无法处理复合类型。
- 先进技术的影响：
- 多智能体工作流： 使用开发者智能体（Developer Agent）和评审者智能体（Reviewer Agent，使用 GPT-4o-mini）的工作流实现了最高的整体成功数（579 个实例），显著优于简单提示和检索增强生成（RAG），特别是在复杂的复合重构任务上。
- 智能体脚手架（OpenAI Codex）： 即便是强大的智能体（GPT-5.1-Codex），在复合实例上的成功率也仅为 39.4%，而在原子实例上为 82.6%，这凸显了多步、强约束转换任务的持续难度。
意义与主张
本文将 SWE-Refactor 定位为软件工程基准测试的一次必要演进。其意义在于：
- 真实性： 通过使用来自真实项目的开发者编写的提交，它避免了与合成或 LLM 生成的基准测试相关的偏差和幻觉。
- 复杂度： 它明确针对原子重构与复合重构之间的差距，为仓库级推理能力提供了严格的测试。
- 语言多样性： 它通过提供稳健的 Java 基准测试，解决了当前文献中以 Python 为中心的偏差，反映了大规模企业系统中所使用的语言。
- 可靠性： 自动化流水线确保了地面真值是保持行为不变且结构正确的，为未来的研究提供了一个值得信赖的标准。
作者总结道，虽然 LLMs 在代码生成方面展现出前景，但在复杂的复合重构任务面前仍面临重大挑战，这表明目前的智能体框架在没有人类监督的情况下，尚不足以可靠地处理多步软件维护任务。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。