To Add Is Machine, To Delete Is Human: Measuring and Mitigating Deletion Avoidance in LLM Code Editing
Amir M. Ebrahimi, Mohammed Mehedi Hasan, Aaditya Bhatia, Gopi Krishnan Rajbahadur, Ahmed E. Hassan
cs.SE, cs.AI, cs.LG
2026-07-31
顶尖 LLM 改代码删除召回率最高仅 71.7%,29% 的通过补丁靠加判断绕开删除;补上删除校验,四个前沿模型从 63.2% 跌到 41.9%。
用 AI 编程代理改代码,测试一路绿灯,代码库却越来越难维护。这篇把锅具体指到了一个行为上:删除规避(deletion avoidance),也就是模型系统性地不肯删掉本该删的代码。
作者先给了几条现场证据。在一个 6.23 亿次变更的大规模分析里,删除「年龄」超过十二个月的旧代码的编辑,在 2023 年后掉了 74%,而掩盖错误的写法涨了 47%。在 GitHub 上,46.4% 的代理提交被拒;维护者审 296 个代理 PR 的合并率,比基准分还低 24 个百分点。
测试通过和代码变干净是两回事。原版测试很少检查「这段代码到底删没删」,所以删不掉的补丁照样能过。这是问题所在。
核心是把「删得对不对」量化成一个指标:删除召回率(deletion recall)。对每个任务,拿开发者补丁里真正删掉的行当作金标,看模型 reproduce 了多少,公式是 |模型删的 ∩ 该删的| / |该删的|。
在这个指标下,作者从 SWE-bench Verified 上五个排行榜前列的模型(GLM-4.6、GPT-5、Kimi-K2、Opus-4.5、Salesforce SAGE)的 2358 个标注补丁里,认出三种策略:
Guard-and-Go 是关键。它有十种结构形态,最常见的一种(占 40.2%)是「保留路径当兜底」:表面上挡住了报错的 case,真该删的逻辑还在默认分支里跑。GLM-4.6 的 Guard-and-Go 补丁比开发者补丁大 97.8%,Kimi-K2 大 81.5%。
为了证明这不是无关紧要的整洁度问题,作者做了删除敏感测试(deletion-sensitive check):给 34 个删除密集的任务补上「目标代码还在就挂」的测试。四个前沿模型从 63.2% 集体掉到 41.9%,其中 GLM-5.2 和 DeepSeek-V4-Pro 各掉 23.5 个点。
接着是 CanItDelete,一个全是删除任务的基准。200 个任务,全部从真实 commit 里挖出来,每条的完整要求就是删东西,且至少跨三个不相邻的删除块,用确定性、按出现次数感知的评估器判分,不用 LLM 当裁判。
最后是一把诊断梯子:四级逐步加料的提示,从原始指令、显式要求不准绕开、指到大致区域,一直到直接给出要删的确切行,看哪一级才管用。
删除召回率上,五个模型在全部解出的任务里最高也就 71.7%(Opus-4.5),其余都在 65% 到 68% 之间。它们定位到正确文件的比例超过 92%,但精确删到目标行的不到 52%。
CanItDelete 上,把添加工作全去掉、只剩删除时,最强模型依然每五个错一个:
| 模型 | 通过率 |
| Claude Opus 4.8 | 79.0% |
| GPT-5.6 Sol | 74.0% |
| Kimi K2 Thinking / MiniMax-M3 | 67.0% |
| Qwen2.5-0.5B | 18.0% |
失败的 69.8% 是「没删干净」。诊断梯子显示,前三档提示基本没用,直到把要删的确切行喂给模型,没删干净的比例才降到 0.6% 到 3.0%。但成功率也只被抬到 80.5%,因为模型开始删过头,或者在删完的地方又添代码。GPT-5.6 Sol 的无效编辑率基本没动(16.0% 升到 16.5%)。
试点研究给了出路。给一个 7B 模型的后训练里掺入 12,821 条删除样本(只占 0.7% 的 token),CanItDelete 从 6.5% 涨到 13.7%,SWE-bench Verified 从 25.40 涨到 30.70,而 CanItEdit、EditBench 基本持平。这说明删除规避是欠训练,不是没法教。
每个在用 Claude Code、Cursor、Copilot 这类代理的人都在吃这个亏。代码库越改越乱、死代码堆积、靠 if 兜底而不是真删,这些是日常体感。这篇把它量化了:模型找得到该删的地方(文件级定位 92% 以上),卡的是到了行这一级下不去手,而且测试还护着它。
对做基准和做代理的人,「测试是否检查删除」是个被忽略的维度,CanItDelete 和删除敏感测试可以直接拿来用。对做后训练的人,「补一点删除样本就能整体涨分」是个低成本信号。
作者自己列了几条硬伤。CanItDelete 的任务指令是用 GPT-5.6 Sol 起草的,而它自己又是被测模型,有自评嫌疑;任务来自最多 star 的仓库,改后的文件可能进了训练集。删除敏感测试只有 34 个任务,代表不了整个 SWE-bench Verified。试点只训了一个 7B 模型、报告三次均值但没给方差,「放大到部署规模、换语言还成不成立」是开放的。
还有一点没说清:诊断梯子里,给到确切行之后成功率卡在 80.5%,作者归因于「删过头或添代码」,但没把这两类失败拆开量化,所以「模型到底更倾向哪种错」其实没交代。