知识卡片：当模型修改过多——最小代码编辑的忠实度

说明：本次未能抓取论文正文，以下内容仅依据 arXiv 元数据与候选摘要整理；实验细节、具体数值与结论表述均待核实。

一句话结论

候选摘要提出，大语言模型修复代码时常出现“过度编辑”（over-editing）现象：即使补丁能通过测试，也可能对原实现做了超出必要范围的大幅修改；通过“保留原实现”的提示可缓解这一问题，而在后训练阶段，强化学习比监督微调更能帮助模型学会最小编辑。（待核实）

事件概述或研究问题

• 大语言模型越来越多地被用于编辑既有代码；但“修复成功”不应只看代码是否正确，还要求补丁是最小化的、可审查的，并且忠实于原实现。
• 论文研究的问题是模型的“过度编辑”倾向：为了修一个 bug，模型是否会把代码改得远超必要范围。
• 候选摘要显示，作者基于 400 个 BigCodeBench 问题构建评测框架，通过向参考解法中注入受控的 AST 级破坏，使每个修复任务都有一个已知的最小补丁。（待核实）

方法/产品要点

• 数据与任务：400 个 BigCodeBench 问题，向参考代码中注入“AST 级破坏”，作为需要修复的 bug。（待核实）
• 评测指标：Pass@1、多余编辑距离（excess Levenshtein distance）、新增认知复杂度（added cognitive complexity）等。
• 测试对象：前沿大语言模型，候选摘要中特别提到“GPT-5.5”（名称与版本待核实）。
• 干预手段：
  • 加入“保留性指令”（preservation instruction），要求模型尽量保留原实现；
  • 在后训练阶段比较监督微调（SFT）与强化学习（RL）是否能让模型学会最小编辑。（待核实）

主要结果或产业意义

• 前沿模型中“过度编辑”现象普遍存在；高 Pass@1 完全可以与不必要的大幅改动、新增认知复杂度并存。
• 保留性指令显著减少了过度编辑：平均多余 Levenshtein 距离从 0.195 降至 0.131；新增认知复杂度降低 26.6%；Pass@1 提升 2.3 个百分点。
• 但这种改进不能简单归因于更大的推理预算或更大的模型。
• 监督微调会过拟合到已见过的破坏模式；强化学习则在域外编辑忠实度与性能保持之间取得更好的权衡。
• 产业意义：面向代码评审、持续集成或编程助手的落地中，应把“编辑忠实度”作为与“通过测试”并列的修复质量维度。（待核实）

为什么重要

“编辑忠实度”提示我们：代码修复质量不仅是“能否通过测试”，还包括 diff 是否可审查、是否尊重原实现的意图和结构。已有相关卡片分别关注具身推理中的忠实性、世界模型可辨识性和插件生态维护；本条把类似问题带入代码编辑场景，指出模型可能“修对了却改太多”，这对自动代码修复工具的可信度和工程可用性有直接影响。

局限与不确定性

• 论文正文未抓取到，无法核实评测设计、提示词内容、模型版本、后训练算法细节等。
• “认知复杂度”的具体计算方式、AST 破坏类型、训练/测试分布如何划分，均待核实。
• 基于 BigCodeBench 的结果能否推广到真实代码库、其他编程语言和真实 PR 场景，尚不清楚。
• 候选摘要表明保留性指令有效，但仍未说明其在更复杂、更真实的修复任务上的边界条件。（待核实）

可用于图书/PPT/简报的角度

• 以“修好了，但改得太多”为切入点，展示同一 bug 的最小修复与过度改写 diff。
• 把 Pass@1、多余 Levenshtein 距离、新增认知复杂度并置，说明代码修复评估需要多维指标。
• 讨论一条简单指令如何改变模型行为：保留性指令能降低过度编辑，却不能完全消除。
• 对比“记忆”与“学习”：SFT 容易过拟合已知模式，RL 更能学到跨场景的最小编辑策略。

原始材料

• 英文标题：When Models Edit Too Much: On the Fidelity of Minimal Code Edits
• 英文关键词：foundation-model（来自元数据 Topics；如有正式关键词字段需以原页面为准）
• 原始来源：https://arxiv.org/abs/2609.04061v1
• 备注：该页面正文未能抓取；以上内容基于候选摘要整理，详细信息待核实原文。