代码修复不只是答对：大模型为何总爱改得太多

2026年9月7日阅读约 3 分钟

导语

当大模型被用于修复代码时，“程序最终能运行”只是最低要求。对真实工程团队而言，补丁还应尽量小、容易审查，并且保留原有实现中的设计意图。否则，一个看似正确的修复可能同时引入无关重构，增加代码审查、回归测试和后续维护的成本。

Hugging Face Daily Papers 收录的一项研究，专门考察了这种被称为“过度编辑”的现象：模型为了修复一个局部缺陷，修改了超出必要范围的代码。

研究者从400道 BigCodeBench 题目出发，在参考答案中注入受控的 AST 级错误。由于错误的注入过程是已知的，研究者可以确定修复所需的最小补丁，再将模型生成的结果与这个理想修改进行比较。

这种设计补充了传统的 Pass@1 指标。Pass@1 主要回答“代码是否通过测试”，而新框架还关注几个问题：

实验结果显示，过度编辑并非弱模型的专属问题。包括 GPT-5.5 在内的前沿模型，也可能在取得较高 Pass@1 的同时，提交规模明显超过必要范围的补丁。这说明“正确性”和“编辑忠实度”是两个不能相互替代的质量维度。

研究还测试了明确要求模型“保留原有代码、只进行必要修改”的指令。加入这类保留性约束后，平均额外 Levenshtein 距离从0.195降至0.131，新增认知复杂度降低26.6%，Pass@1提升2.3个百分点。

值得注意的是，改善并不能简单归因于更大的模型或更多的推理预算。换言之，让模型思考更久，并不自动意味着它会更克制地编辑代码。模型可能拥有更强的重写能力，却仍然缺少对变更边界的明确判断。

研究者进一步比较了不同后训练路径。监督微调在面对训练中见过的错误模式时能够学习相应行为，但容易对这些模式过拟合；强化学习则在分布外的编辑忠实度与性能保持之间取得了更好的平衡。

这项工作对代码智能工具的启示很直接：未来的代码代理不能只以测试通过率作为目标，还应把补丁规模、无关变更和审查成本纳入训练与评测。对于开发者而言，使用代码模型时加入“最小修改”或“不要重构无关部分”的约束，也可能比单纯增加上下文或推理预算更有效。

总体来看，研究把“少改且改对”明确提出为代码修复能力的一条独立轴线。它并不否定模型完成复杂重构的价值，而是提醒我们：在定位明确的缺陷修复任务中，克制本身也是一种能力。