# AI 辅助重构：方法与证据

规范 HTML：https://aogavrilov.com/zh/research-notes/ai-assisted-refactoring-evidence/
英文版本：https://aogavrilov.com/research-notes/ai-assisted-refactoring-evidence/
文档语言：zh-Hans
来源论文：https://aogavrilov.com/zh/publications/inspectable-control/
英文论文全文：https://aogavrilov.com/publications/inspectable-control/full-text/
DOI：https://doi.org/10.1145/3803437.3807386

评估近期 AI 辅助重构方法时，不把看似合理的生成补丁误认为已经验证的行为保持，并要求编译、测试、静态检查与重构检测形成证据链。

## 直接回答

### 评估 AI 辅助、行为保持的重构时，哪些方法和证据最重要？

把变换建议与可信执行和验证分开。条件允许时，让模型识别重构，再由重构引擎执行；随后要求编译、测试和静态检查通过，并确认预期变换确实发生。

## 为什么这一区分重要

重构通常要求在改善内部结构的同时保持可观察行为。语言模型可以提出看似可信的重写，却没有证明这两个条件，因此表面合理性并不够。

近期工作以不同方式分离职责：模型可以识别已知变换，再交由可信引擎执行；也可以生成补丁，然后接受编译、测试、静态分析和重构检测。验证界面与模型本身同样重要。

## 实用步骤

1. **明确预期重构。** 命名结构变换和必须保持稳定的行为，而不是只提出笼统的“清理代码”要求。
2. **已知变换优先采用可信执行。** 如果重构引擎支持该操作，让模型负责检测或参数选择，让引擎负责应用变换。
3. **在仓库级验证生成补丁。** 执行编译和相关测试，应用静态检查，并确认预期重构发生且没有引入无关变更。
4. **审计剩余风险。** 记录未覆盖行为、不稳定测试、跨文件影响，以及无法验证的可疑补丁。

## 应要求哪些证据

- 明确识别具体变换，而不是只称其为代码质量改进。
- 变更后能够编译并通过相关测试。
- 静态检查和重构检测支持所声称的结构变化。
- 测量或审查预期范围之外的无关 diff。
- 披露仓库上下文和测试覆盖的限制。

## 相关研究实际报告了什么

- 站内分层潜在控制论文提供的是有边界生成的邻近证据，而不是行为保持重构基准。
- 其中的解析率、编辑自由度和多样性测量可帮助设计控制界面，但不能替代编译、测试或重构检测。
- 对于重构主张，证据契约仍应面向行为和仓库上下文。

## 适用边界

- 通过现有测试不能证明未测试行为也语义等价。
- 更小的 diff 不一定就是正确重构。
- 相关站内实验只覆盖短 Python 函数，没有评估仓库级重构。

完整研究指南：https://aogavrilov.com/zh/projects/discrete-latent-generation/#control-ai-assisted-refactoring

## 主要与邻近来源

- [An Empirical Study on the Potential of LLMs in Automated Software Refactoring](https://arxiv.org/abs/2411.04444)：研究由大语言模型提出重构、再由可信重构引擎重新执行的潜力。
- [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712)：采用仓库级编译、测试和面向重构的评估。
- [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/publications/inspectable-control/)：相关的有边界生成证据与明确局限。

这篇维护型笔记只总结已有证据，不添加超出引用来源的新实验结果。