AI 编程模型又暴露出一个比“会不会写”更贴近工程现场的问题：它们常常会修好 bug，但不肯只修 bug。针对 400 个程序化造错代码样本的评测显示，主流模型普遍会多改一截代码，像是在修补丁，也像在顺手接管函数。

这对高频使用 Cursor、Copilot、Claude Code 的团队很现实。棕地开发里，最稀缺的不是生成能力，而是边界感。你让它当编辑，它却很容易演成重构者。

这项评测测的不是会不会修，而是会不会只改该改的地方

研究者从 BigCodeBench 里取了 400 个样本，再程序化注入单点错误。比如把 < 改成 <=，把 + 改成 -，把 True 改成 False。因为错误是人工构造且只有一处，最小修复路径也就不是拍脑袋定义的。

这很关键。它让“最小改动”从主观审美，变成了可验证目标。对于衡量修 bug 场景，这比泛泛讨论“代码写得优不优雅”更有用。

评测看了三类东西：

  • 能不能修对.Pass@1
  • 修对之外多改了多少.token-level Levenshtein distance
  • 多出来的理解负担有多大.Added Cognitive Complexity

光看 Pass@1，其实不够。测试通过，只能说明结果没错；它不能告诉你 reviewer 还要不要重新读半个函数。后两项指标，盯的就是这笔隐藏成本。

模型正确率表现改动幅度结论
Claude Opus 4.6最高，Pass@1 达 0.912/0.900Levenshtein 0.06/0.08，最接近最小修复修得对，也收得住
GPT-5.40.723/0.770，不突出0.395/0.327，过度编辑最明显改得多，收益却不高
Gemini 3.1 Pro、GLM 5、Qwen 3.6 Plus整体中上改动明显小于 GPT-5.4可用，但风格差异很大

这里最值得看的一点，不是谁“能写代码”，而是谁尊重补丁边界。Claude Opus 4.6 在正确率和最小改动上都占优。GPT-5.4 则相反：改动幅度最大，正确率也没有拉开差距。

研究里的一个典型例子是 off-by-one 错误，本来只要把 range(len(x) - 1) 改回 range(len(x))。但有的模型会连输入校验、数组处理、绘图逻辑一起改。测试可能照样过，工程上却未必算合格。

受影响最直接的，是棕地开发团队和做 code review 的人。单点 bug 本来只该审局部逻辑；一旦 AI 把半个函数都翻一遍，评审就从“验补丁”变成“验新代码”。工时会上去，信任会下来。

一句提示词就能压住，说明默认风格有问题，不是能力做不到

这项评测还做了一个很实用的对照：在提示词里明确要求“尽量保留原代码和原有逻辑”。结果很直接，几乎所有模型都更收敛了。

Levenshtein 距离普遍下降。多数模型的 Pass@1 还一起变好。推理模型的改善更明显。

这至少说明一件事：过度编辑不是纯粹能力缺陷，更像默认风格。模型不是不会少改，而是默认更愿意多写、多补、多换实现。

我不太买账的一种说法是，把这种行为包装成“更智能”。在真实仓库里，很多“看起来更聪明”的改写，最后只是把审查成本、回滚风险和维护债务转嫁给团队。所谓“天下熙熙，皆为利来”，放到模型产品上，利未必是钱，也可能是训练目标和产品激励：更完整的回答、更强的存在感、更像一个会主动发挥的资深工程师。

问题在于，修 bug 不是写样板房。棕地开发讲的是可审、可控、可回滚。多写出来的每一行，理论上都要重新承担一次责任。

这里也要把边界说清。不能把这个结果直接写成“推理模型更差”。更准确的表述是：它们默认更爱扩写，但在明确约束后也更能收住。这个差别不小。前者是在下结论，后者是在谈可控性。

对一线团队来说，马上能做的动作其实很具体：

角色/场景更现实的做法原因
高频用 AI 修 bug 的开发者把“尽量保留原逻辑、最小改动、不要重构无关代码”写进默认提示词或规则文件成本最低，收益最直接
技术负责人/评审者评估工具时把 diff 大小、复杂度变化纳入检查，不只看通过率测试过了，不等于 review 成本可接受
正在采购或续用编码助手的团队暂时别只按 benchmark 排名拍板，先用自家仓库的修 bug 任务做对比这类场景最能暴露“改得太多”的真实代价

如果你的团队主要让 AI 写新模块，这项评测的杀伤力没那么大。可如果你们拿它处理老代码、线上补丁、遗留系统，那这件事就很要命。场景不同，结论也该有分寸。

真正要观察的，不是哪家模型更会写，而是哪家愿意把“克制”做成默认值

这项研究当然有边界。它用的是程序化单点 corruption，更适合衡量最小修复能力，不等于覆盖复杂需求变更、多文件联动、架构调整这些真实任务。所以，不能把它泛化成“AI 编程整体不行”。

但它确实把一个长期被 benchmark 稀释的问题拎了出来：测试通过，不等于工程上合格。软件工程里，很多成本都不在生成那一刻，而在后面的 review、回归、回滚、交接。模型把代码改得越多，这些成本就越容易被偷偷放大。

这不是什么新戏码。早年的自动格式化、自动重构工具也碰过同一个坑：自动化最麻烦的地方，往往不是做错，而是越权。AI 只是把“越权编辑”放大了，因为它写得更快，也更像有道理。韩非子讲“治大国若烹小鲜”未必适合所有场景，但拿来形容修补老代码倒很贴切：火候太猛，锅先糊。

接下来最该观察三件事：

  • 模型厂商会不会把“最小改动”做成默认策略，而不是藏在提示词里
  • 工具链会不会把 diff 大小、复杂度增量做成显式评估项
  • 更多评测会不会把单点修复之外的真实仓库任务也纳入，看看结论能扩展到哪一步

如果这三件事都没有发生，那所谓 AI 编程进步，很可能只是把“会写更多”继续误当成“更适合工程”。代码生成会越来越便宜，审查注意力不会。真正稀缺的，还是后者。