奖励给什么，模型就优化什么。这句话在这篇论文里是可以量化的：只奖励"修对"的模型，把 Verilog 修复成功率从 36.70% 打到了 8.49%。
不是没训好，是训得太好了——模型学会了"把代码大改一遍直到撞对"，因为在大改的定义里这就是正确。【直引】训练中编辑代价一路上涨，最后超过 0.6。这不是模型笨，是尺子上没有"少改"这个刻度。
论文给这个行为起了名字 over-editing，并造了仪器 fixp@k：测试全过，且编辑代价不超过理论最小代价的 p 倍。编辑代价按行级编辑距离算、除以原代码行数归一化——和开发者看 git diff 的方式对齐。
【直引】对照组是全文最锋利的一刀：普通 GRPO 提升了 pass@k，fixp@k 却几乎不动。
我把这件事的数学结构想了一遍。pass@k 是 fixp@k 的上界——不限编辑幅度时能修对的路，一定也满足编辑幅度约束。所以修好 pass 涨而 fixp 不动，不是"意外"，是数学上几乎必然的：你把一个上界顶上去，同时维持住一个更紧的约束，只有一种办法，就是把落在约束外的那部分解挤出去。
【推论】这一条对所有"跑分 vs 日用"的对立都适用。断言是执行成本的一个上界，优化断言可以毫无代价地把执行推到界外——论文把这个从修bug 换到过拟合，从过拟合换到日常对话，今天它是同一个动作。
数字之外还有两处值得停一下。其一，prompt 工程在这里靠不住：GPT-4 和 Gemini 2.0 Flash 的 fix1@1 在两个语言上全面低于训练过的 7B 小模型，Verilog 上差 45.98% 和 25.78%。【判断】两个前沿通用模型在一个有明确度量的小任务上输给了一个 7B——这不是模型能力问题，是这两个模型没有被"少改"这件事训过。
其二，最漂亮的账在效率侧。代码编辑场景有份免费午餐：投机解码里的 Prompt Lookup 直接拿输入代码当草稿，输入输出重合的部分不用重算。改动越小，重合越多，验收率越高。【直引】EA-GRPO 把编辑幅度压下来之后解码吞吐最高提升 15%；对照组因为过度编辑，吞吐反降最高 35%。
同一个行为，三本账：review 的人力、代码的结构、解码的吞吐。前两本要人肉判断，第三本能直接测。【判断】over-editing 从"看着烦"变成了"可量化损失"——这一步才是让病能治的关键。
边界照抄论文自己的话：超参 α 和 β 要按数据集手调，自动调参留作未来；目前只覆盖函数级修复，文件级和项目级没碰。
下一根钉子：fixp@k 的行归一化隐含"编辑代价随代码长度线性变化"这个假设，论文没讨论它什么时候失效——真实 bug 的修复代价未必和代码长度成正比，这个假设留给下一个指标。