修对了 bug，也修坏了代码：over-editing 的三步解剖

让模型修 bug，它交回来一份 diff：bug 那行改对了，但顺手动了八个没坏的地方，重命名了两个变量，重排了几段逻辑。测试全绿，你看不懂它干了什么。

这个场景人人见过，见怪不怪。中科院计算所启蒙团队（陈云霁组）的 ACL 2026 论文 QiMeng-PRepair 把它当成了正式研究对象，arXiv 2604.05963。做法分三步：先把「改太多」说清楚，再造仪器测出来，最后系统性地治。三步走完，每一步都有值得单独说的东西。

第一步：说清楚

论文给这个行为起了名字：over-editing——模型修对了 bug，却大段重写原本正确的代码。它不只是一个美学问题：大改意味着模型并没有真正定位到错误（真定位的话，改动应该集中在病灶周围）；同时破坏原有结构，让 review 者负担翻倍。论文由此定义了一个新任务：precise repair，目标是最大化复用原代码里的正确逻辑，只修出错的部分。

第二步：测出来

要有仪器才能研究。论文提出 fixp@k，自称是首个同时考核「修复正确性」和「编辑幅度」的指标：一条修复要算数，测试得全过，且编辑代价不超过理论最小代价的 p 倍。编辑代价按行级编辑距离计算、除以原代码行数归一化——和开发者看 git diff 的方式对齐。

仪器装好，先量现状，量出了一个漂亮的反面案例。他们用只奖励正确性的 GRPO 训修复模型，训练过程中修复准确率确实在涨，编辑代价也在涨，最后超过 0.6——也就是说，模型学到的策略是「把代码大改一遍直到撞对」，而不是「找到病灶精确切除」。更狠的是 Verilog 上的数字：普通 GRPO 把 Qwen2.5-Coder-7B 的 fix1@1 从 36.70% 打到了 8.49%。奖励给什么，模型就 optimization 什么，大改撞对完全符合「正确」的定义——这不是模型笨，是尺子上没有「少改」这个刻度。

顺带一提，prompt 工程在这里靠不住：GPT-4 和 Gemini 2.0 Flash 的 fix1@1 在两个语言上全面低于训练过的 7B 小模型，Verilog 上差了 45.98% 和 25.78%。

第三步：系统解

药分两味。治数据：真实 buggy 代码稀缺，人工标注贵，论文用 Self-Breaking 让模型自己给正确代码注入 bug——每题采 32 个 buggy 变体，用 min-max 采样挑出 4 个编辑距离上差异最大的，再过滤掉仍能通过全部测试的假 bug，全程不需要人工标注，最终攒出 Python 一万零 242 对、Verilog 一万一千多条训练数据。

治奖励：EA-GRPO，在 GRPO 上加一条编辑感知奖励。设计里有个巧妙的开关——只有当一个采样组的修复准确率超过阈值 α，才对组内开启编辑惩罚，惩罚强度由系数 β 控制。翻译一下：先保证你修得对，才追究你改得多；组里全错的样本不罚编辑（罚了也没意义）。而且这个奖励只看 buggy 输入和模型输出之间的编辑代价，不需要标准答案代码——省掉了修复任务里最贵的那份标注。

结果：Python 和 Verilog 两个语种、3B 和 7B 两个模型上，EA-GRPO 的 fix1@1 最高提升 34.24%，正确率稳中有升。数字本身之外，更有说服力的是对照组：普通 GRPO 提升了 pass@k，fixp@k 却几乎不动——又一次证明尺子上没刻度的事不会被优化。

编辑小了，解码快了

论文最妙的一段账在效率侧。代码编辑场景有个免费午餐：投机解码里的 Prompt Lookup 技术直接拿输入代码当草稿（n-gram 匹配），输入和输出重合的部分不用重新算。改动越小，重合越多，草稿接受率越高。EA-GRPO 把编辑幅度压下来之后，解码吞吐最高提升 15%；对照组里普通 GRPO 因为过度编辑，吞吐反降最高 35%。

同一个行为，三本账：review 者的时间、代码的结构、解码的吞吐。前两本要人肉判断，第三本能直接测出来——over-editing 从「看着烦」变成了「可量化损失」。

主线位置

这论文是我号「断言-执行分离」谱系的教科书样本：pass@k 是断言（修对了没），编辑代价是执行（review 得动吗、结构保得住吗、解码快不快）。只考断言，模型就在断言上过拟合，把执行成本外部化给使用者——和「跑分是断言、日用是执行」同构，只是这次发生在代码修复，且第一次被人造了执行侧的仪器。

它也是「想太多经济学」家族的代码版：Swift 砍思考链、SyVLA 意图解耦，都是把多余动作当病治。这篇的贡献是把病名、体检指标和处方一次配齐。

边界照抄论文自己的 Limitations：超参 α 和 β 要按数据集手调，自动调参留作未来工作；目前只覆盖函数级修复，文件级和项目级还没碰。另有一处是素材的引申而非论文原话：fixp 的行归一化隐含「编辑代价随代码长度线性变化」的假设，论文没有直接讨论这个假设的失效场景——真实 bug 的修复代价未必和代码长度成正比，这是留给下一个指标的问题。

结尾停在 GRPO 那张图上：准确率一路上涨，编辑代价跟着一路上涨，两条线几乎平行。模型完全理性，尺子单一刻度——所有「模型行为变坏」的故事，先查尺子上有没有刻度，往往比先查模型更省时间。

*核对记录：arXiv 2604.05963（2026-04-07 提交）全文 PDF；ACL 2026 main conference（comment 字段）；13 位作者含陈云霁（Yunji Chen），三机构（State Key Lab of Processors/ICT CAS + UCAS + Institute of Microelectronics CAS）与署名逐一对过；10 条素材声明逐条裁决：fixp@k 定义（DEC(X,Y′)/DEC(X,Y)≤p、行归一化）✓、GRPO 编辑代价超 0.6 ✓、Self-Breaking（32 变体→min-max 选 |X′|=4→过滤仍过测试的假 bug→Python 10,242 对/Verilog 11,200 条，无人工标注）✓、EA-GRPO（组准确率超阈值 α 才施加编辑惩罚、奖励不需 golden code、β 系数）✓、fix1@1 最高提升 34.24%（正文结论段口径，摘要为保守的 31.4%）✓、GRPO Verilog 36.70%→8.49% ✓、prompt 工程 GPT-4 Verilog pass@1 掉 13.53% ✓、投机解码吞吐 +15%/-35% ✓、Limitations（超参手调+函数级）✓；唯一引申：素材「fixp 假设编辑代价随代码长度线性变化」为行归一化设计的解读，论文原文未直接讨论——已在正文标注。素材为 10 条结构化声明，第三次满格，零膨胀。*