一个问题正在拖慢代码审查的效率

Over-Editing：被忽视的AI编程副作用

4月22日，一篇关于”Over-Editing”问题的技术博客在Hacker News上引发热议，获得了259个点赞和190条评论。作者通过实验发现：当前的AI编程助手（包括GPT-5.4）有一种倾向——在修复一个简单bug时，会重写整个函数，引入大量不必要的修改。这个现象正在成为代码审查的新瓶颈。

一个bug换一个函数，值得吗？举一个典型例子：用户让AI修复一个range()函数中的off-by-one错误（range(len(x) – 1)应该是range(len(x))），正确的修改是一行代码。但GPT-5.4（高推理模式）的反应是把整个函数重写了：加了None检查、np.asarray转换、有限值掩码、数组大小验证、curve_fit调用签名变更、绘图逻辑重写——等等。功能上是对的，测试也都通过了。但diff（代码差异）极其庞大。问题在于：这让代码审查变得极其困难——reviewer需要理解”什么变了、为什么变、是否安全”。一个bug的修复变成了整个函数的审查任务。

为什么这很重要？

首先，在”brown-field”开发场景中（也就是在已有代码库上工作），现有代码是团队已经理解并有意这样写的。AI的职责是修复问题，而不是重新设计。其次，常见的建议”多加测试就行了”在这里失效了——Over-Editing不是正确性问题，而是代码质量静默下降的问题。测试可以通过，但代码库在不知不觉中变得更复杂、更难维护。第三，随着AI生成代码的比例越来越高，工程师需要审查的代码量在增加，而Over-Editing让这个审查工作变得更耗时、更容易出错。

研究给出的解法

作者提出了几个评测指标来量化Over-Editing的程度，包括Token级Levenshtein距离（相对字符级距离更能反映真实代码变化）。通过这个方法，可以对比不同模型在修复相同bug时的”最小改动程度”。研究还测试了多个主流模型，发现Over-Editing是一个普遍现象，不同模型之间只有程度差异，没有本质区别。这意味着这不只是某个模型的问题，而是当前AI辅助编程范式的共同缺陷。

影响社会的思考

这件事揭示了AI编程工具的一个深层问题：我们太关注”能否解决问题”，而忽视了”解决问题的代价”。 AI能修bug，但修得太暴力。这是效率与精准度的矛盾，也是现在AI工具的通病——追求通过率，追求”完成任务”，而忽略了协作开发中的人类需求。对于开发者来说，这意味着不能盲目依赖AI的代码审查。理解每一行改动的意图，仍然是不可替代的能力。对于AI工具的开发者来说，评价一款编程助手的指标可能需要更新：Pass@1不够，还需要看’最小改动率’——AI是否在保持修复效果的同时尽量少改动原本的代码。

【新闻来源标注】 Over-Editing研究，来源：nrehiew.github.io Blog，发布时间：2026年4月22日原文链接：https://nrehiew.github.io/blog/minimal_editing/ Hacker News讨论：https://news.ycombinator.com/item?id=47864393