← 返回 2026-08-04

LLM 代码编辑的删除回避行为：度量、基准与训练缓解 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 📅 2026-07-30 👍 20 2026-08-09 18:30
LLM 智能体 代码编辑 后训练 基准测试 程序修复 经验软件工程
arXiv HuggingFace PDF

揭示 LLM 系统性回避删除代码的偏差，构建 CanItDelete 基准并证明训练可缓解。

前置知识

SWE-bench Verified

用于评测 LLM 在真实 GitHub issue 上进行仓库级修复能力的权威基准，包含 500 个人工核验的任务，每题配套 FAIL_TO_PASS 测试。它只判定补丁能否让行为测试通过，并不检查补丁是否合并就绪、是否保持仓库惯例，这正是本文质疑评测有效性的切入点。

理解本文必须知道 SWE-bench 是当前主流评测，以及它"测通过而不测删除"的盲区，否则无法理解为何 Guard-and-Go 这类保留旧逻辑的补丁也能被记为已解决。

Deletion recall / precision

作者定义的核心度量。设 $G_t$ 为任务 $t$ 的参考删除集合（开发者补丁从非测试 Python 文件中移除的源位置），$M_{t,m}$ 为模型 $m$ 实际删除的位置。删除召回率 $R_{t,m}=|G_t \cap M_{t,m}|/|G_t|$ 衡量模型复现了开发者删除的多少；精确率则衡量模型删除中有多少命中参考位置。两者都按任务做宏平均，使一行删除与二十行删除等权。

整篇论文的实证与基准都围绕这一度量展开，不掌握它就读不懂"召回 71.7%""精确率 74.3%"这些核心数字，也无法区分"找不到"与"找到了但没删"两类失败。

Guard-and-Go 模式

作者识别出的删除回避主导形式：模型保留开发者要删的逻辑，并新加一个条件或绕行分支把执行流引开。比如开发者删除一句赋值，模型却保留赋值再用 `else` 守卫把新输入导向别处。它在通过测试的补丁中占 29.0%，最常见子类"Retained Path as Live Fallback"占 40.2%——保留的旧逻辑仍作为默认路径对未匹配输入运行。

这是论文最具说服力的证据：模型不是不会修，而是用"加守卫"替代"删代码"，让补丁膨胀、可维护性下降。看懂这种结构模式才能真正理解删除回避的工程危害。

诊断阶梯 (Diagnostic ladder)

CanItDelete 的四级累积提示：vanilla（仅给删除请求）、explicit deletion（显式要求删除并禁止 guard/注释/回退）、region pointer（指明相关函数或区域但不暴露边界）、exact lines（给出要删的精确 occurrence-specific 区间并要求保留其余文本）。每级只加一个线索，相邻模式结果之差就能定位失败原因属于意图、搜索还是边界。

论文的关键结论"模型缺的是控制力而非能力"正是靠阶梯拆出来的——只有 exact lines 能让所有模型提升，且即便给了精确区间，GPT-5.6 Sol 仍有 16.5% 因越界编辑失败。不读阶梯就读不懂这个二分。

后训练数据混合 (Post-training mixture) 与删除监督

LLM 在预训练后用于提升特定能力的训练阶段，数据是混合指令样本。作者在一个 7B 模型的 15.9B token 代码后训练混合中加入 12,821 条删除示例（10,000 条文件级 + 2,821 条仓库级，共 112.1M token，约 0.7%），其余配方（6 epochs、global batch 64、128 xPUs）完全相同，仅训练数据相差 0.7% token，从而隔离删除监督的效果。

第五节的干预实验证明"删除是欠训练而非不可达"，并展示增益能迁移到 SWE-bench Verified（+5.3）。理解后训练混合与对照实验设计，才能正确评估这一结论的强度与局限。

研究动机

论文从"测试通过 ≠ 合并就绪"这一裂缝切入。多项证据显示 LLM 编码智能体产出的补丁在可维护性上存疑：在一个大型 GitHub 语料中 46.4% 的智能体补丁被拒（Abujadallah 等 2026）；METR 复审 296 条已通过 SWE-bench Verified 的 PR，其合并率比基准分数低 24 个百分点，维护者专门抱怨"冗长"和"偏离仓库惯例"（Whitfill 等 2026）；GitClear 2026 报告 6.23 亿次变更分析中，AI 删除或更新代码的比例在 2023 年后下降 74%，而掩码式构造上升 47%。作者把这些现象收敛到一个具体机制——删除回避（deletion avoidance）：当一次编辑本该删掉某段代码时，模型系统性地把它留下。图 1 的 psf__request:2317 案例直接展示：开发者删除了 `method = builtin_str(method)` 这句赋值，模型却在原句之外套上 `else` 守卫让它只在非 bytes 输入时执行。两个补丁都让原测试通过、都被记为已解决，但其中一个把废弃代码永久留在了仓库里。这种偏差在工程上的代价是真实的：维护者审 PR 时必须把生成的方法读完才能决定是否删除（Watanabe 等 2026）。

本文的目标是作者有三层递进目标。第一是"定义并量化"：把删除回避从模糊的工程抱怨变成可测量的现象，提出参考删除（reference deletion）的形式定义——开发者补丁从非测试 Python 文件中移除、且未在同一函数/类/模块内重新加入（避免把"搬移"误判为删除）的源位置，并给出删除召回率 $R_{t,m}=|G_t\cap M_{t,m}|/|G_t|$ 与精确率两个度量。第二是"隔离"：现有基准里删除与新增、定位、改写混在一起，无法把失败归因于删除本身，因此构造 CanItDelete——200 道纯删除任务，输入是完整文件、要求只是删除、不需要跨文件定位、不需要替换代码，把所有混淆变量一次剔除。第三是"找出能否缓解"：既然测出偏差，就要判断它到底是模型固有还是训练不足，于是设计诊断阶梯（vanilla→explicit→region→exact）拆分失败来源，并做删除增强后训练的对照试点。

与已有工作不同的是，本文的独特切入在于三点。其一，把"减法"从加法、改写、定位里彻底剥离：先前关于加性偏好（Adams 等 2021 的心理学研究、Winter 等 2023 的语料统计、Santagata 与 De Nobili 2025 的 LLM 任务）都在合成或 no-op 场景，而 Chong 等 2026 又只看 LLM 误删无关代码，没有人正面问"模型是否在真实仓库修复中保留开发者删除的代码"。其二，把失败分解成两个正交能力——"找到每个要删的位置并删完"（deletion completion）与"删到边界就停"（scope preservation）。同一个通过率数字下，可能是删少了、也可能是删过头，论文用阶梯把这两种失败分开，指出 GPT-5.6 Sol 给了精确区间仍失败 19.5%，且失败形式从"删不够"滑向"删过头"。其三，区分"能力缺失"与"训练不足"：作者用 0.7% token 的删除样本就换来 CanItDelete 召回 +7.2 pp、SWE-bench Verified +5.3 pp 的迁移增益，证明删除回避是可训练缓解的，而非不可逾越的天花板。

核心方法

论文按"现场测量→评测有效性→隔离诊断→干预修复"四步展开。直觉上：先用真实 SWE-bench Verified 补丁统计删除回避有多普遍、长什么样；再问"通过测试是否真能发现缺失的删除"，给 34 个删除重的任务追加"删除敏感"测试看多少补丁会暴露；接着构造 CanItDelete 把删除孤立成全部任务、用四级阶梯拆出失败在哪一环；最后用 7B 模型做删除增强后训练，看能否同时降偏差和提通用能力。技术上，所有度量都锚定开发者补丁作为"行为参考"而非"唯一正确解"，因此单条保留不能定性为错误，作者靠跨模型、跨任务的一致趋势（是否一致比开发者删得少、找到代码后是否仍不删、保留逻辑是否取同一结构形式）来建立证据链。

核心创新是把删除做成一个"可诊断"的对象，而不是笼统的修复子任务。形式上，参考删除集合 $G_t$ 由对 base-commit 同时套用两套补丁后比对得到，匹配要求是"同文件同位置"，文字相同但位置不同不算（杜绝把重复行的删除算成命中）。诊断靠三件事：(1) 嵌套三层定位——文件级、作用域级（包含的函数/类/模块）、精确行级，借此把"没找到文件"和"找到了却不删"分开；(2) 用 MiniMax-M2.7 做 LLM 分类器给 2,358 个任务-模型对打 Delete-and-Replace / Guard-and-Go / Non-reference 三标签，并用 Guard-and-Go 的十种子型刻画保留形式；(3) CanItDelete 评估器完全确定性、occurrence-aware、不让任何 LLM 当裁判，且四级阶梯是累积的，相邻级差即为某类信号贡献。这套设计与已有基准的本质区别是：它不评"修得对不对"，而是评"删得准不准、停得稳不稳"，并用阶梯把失败解剖到意图/搜索/边界三个不同维度。

方法步骤详情

整个研究分四块实验。**现场研究（第 2 节）**：固定使用 OpenHands 脚手架，选 5 个最新 leaderboard 提交（GLM-4.6、GPT-5、Kimi-K2、Opus-4.5、Salesforce SAGE，见表 5），筛出 377 个开发者补丁含删除的任务，再聚焦 197 个全模型都解出和 57 个全模型都失败的任务（共 254 个一致结果），逐文件核对参考删除，宏平均计算召回。**测试有效性（第 3 节）**：在 69 个删除占比≥25% 的任务里用 AST 把删除行聚成 166 个删除单元、按表 13 的启发式（控制块删除 +3、整函数/类删除 +2.5、含问题陈述词 +2、独立 import 删除 −4）排序挑目标，构造"删除敏感"F2P 测试——在 base 版失败、在 gold 版通过，最终 34 个通过 host 校验，每个模型各生成一次补丁。**CanItDelete（第 4 节）**：从 Python/JS 各 top-100 仓库挖 79,074 条只删不加的文件编辑，按结构挑战指数 $d_{V2}=(p_L+p_C+p_H)/3$（预编辑行数、删除行数、删除 hunk 数三个经验百分位等权）排序取最难 200 道，GPT-5.6 Sol 起草指令，经 LLM 评分门和作者门双重校验，12 个模型在四级阶梯上跑确定性评估。**训练干预（第 5 节）**：基线 7B 模型在 15.9B token 纯代码混合上后训练，干预组额外加 12,821 条删除样本（10,000 文件级 + 2,821 仓库级，112.1M token≈0.7%），6 epochs、batch 64、128 xPUs，其他完全一致，三跑取均值。

技术新颖性

技术新颖性集中在三点。第一，**首次把删除作为独立目标行为**：SWE-bench 系列和 EditBench/CanItEdit 的参考补丁都混了加、改、删，连"提供定位信息能改善修复"这类研究（Al Awad & Ivanov 2026、Sepidband 等 2026）也无法隔离减法，CanItDelete 让删除成为"全部"任务而非子任务。第二，**确定性、occurrence-aware 评估器**：依靠 hunk-anchored 对齐、Python AST / JS 解析、token 与方言回退，连"注释掉目标""删重复行的一处冒充另一处"都不算通过，避免让 LLM 当裁判引入偏差。第三，**阶梯+失败分类学把单一通过率拆成两个能力**：vanilla→explicit 几乎不动（−2.5 到 +2.5 pp）证明不是意图问题；region 收益有限（0–7 pp）证明搜索不是主瓶颈；只有 exact lines 让全部 5 个模型提升（+6.5 到 +31.5 pp）且把不完整删除压到 0.6–3.0%，但同时又把越界编辑暴露出来（Qwen3-235B 从 20.5% 涨到 26.0%）。这种"完成"与"边界控制"分离的诊断是全新的，对训练目标设计有直接指导意义。

Overview of CanItDelete benchmark construction, cumulative diagnostic modes, and the structural outcome taxonomy.
Figure 2: Overview of CanItDelete benchmark construction, cumulative diagnostic modes, and the structural outcome taxonomy.

实验结果

**现场证据**：在 197 道全模型都解出的任务上，平均删除召回仅 65.2%（Kimi-K2）至 71.7%（Opus-4.5），即便测试通过仍把 28.3%–34.8% 的参考删除留在原处（表 1）。模型修改到目标文件的占 92.5%–94.4%、改到目标作用域的占 68.1%–74.4%，但精确删到该行的只有 44.6%–51.6%（图 5）——粗定位只解释了一部分差距。在 57 道全模型都失败的任务上召回跌到 19.8%–30.4%，Mann-Whitney U 检验 Holm 校正后 $p<10^{-8}$、Cliff's δ 0.485–0.543（大效应）。2,358 个分类对里 Guard-and-Go 占 29.0%、通过率 72.2%，其 550 个子型化样本中"Retained Path as Live Fallback"独占 40.2%（221 个，表 12）；61.1% 的 Guard-and-Go 补丁比开发者补丁大，中位 1.67×，GLM-4.6 高达 97.8%、Opus-4.5 仅 33.0%（表 9）。**测试有效性**：136 次尝试中 86 次（63.2%）过原测试、57 次（41.9%）过删除敏感测试，绝对下降 21.3 pp，29/86（33.7%）保留目标。**CanItDelete**：vanilla 成功率 Claude Opus 4.8 最高 79.0%、GPT-5.6 Sol 74.0%、四个开放权重前沿（GLM-5.2/GPT-5/DeepSeek-V4-Pro/MiniMax-M3/Kimi K2 Thinking）挤在 62–67%、Qwen3-235B 25.0%、Qwen3-30B 仅 18.0%（图 3）；不完整删除在 12 个模型中 10 个占多数失败（合计 69.8%）。**阶梯**：exact lines 让 Claude Opus 4.8 78.6%→97.7%、GPT-5.6 Sol 74.0%→80.5%、Qwen3-235B 25.0%→56.5%（图 4、表 16），但 GPT-5.6 Sol 越界失败 16.0%→16.5%、Qwen3-235B 20.5%→26.0%。**训练**：CanItDelete 成功 +7.2 pp、不完整删除 −13.9 pp、SWE-bench Verified +5.30、CanItEdit +1.40、EditBench −0.19（表 4），证明增益选择性迁移且无显著回归。

Mean deletion recall on 197 tasks all five models solve and 57 all five fail.
Table 1: Mean deletion recall on 197 tasks all five models solve and 57 all five fail.
Patch strategies among 2,358 classifier-labeled pairs.
Table 2: Patch strategies among 2,358 classifier-labeled pairs.
Attempts passing the original suite and, among them, the deletion-sensitive check on 34 tasks per model.
Table 3: Attempts passing the original suite and, among them, the deletion-sensitive check on 34 tasks per model.
7B-model performance before and after deletion-augmented post-training.
Table 4: 7B-model performance before and after deletion-augmented post-training.
Model-generated patch size relative to the corresponding developer patch for passing Guard-and-Go pairs.
Table 9: Model-generated patch size relative to the corresponding developer patch for passing Guard-and-Go pairs.
Distribution of the ten Guard-and-Go structural forms.
Table 12: Distribution of the ten Guard-and-Go structural forms.
Complete five-model diagnostic-ladder results.
Table 16: Complete five-model diagnostic-ladder results.
Vanilla-mode success and failure composition across 12 models.
Figure 3: Vanilla-mode success and failure composition across 12 models.
Diagnostic-ladder outcomes under increasingly precise deletion guidance.
Figure 4: Diagnostic-ladder outcomes under increasingly precise deletion guidance.
File-, scope-, and exact-line overlap across all required deletions in the 197 tasks solved by all five models.
Figure 5: File-, scope-, and exact-line overlap across all required deletions in the 197 tasks solved by all five models.
查看结构化数据
任务指标本文基线提升
SWE-bench Verified 仓库级修复（7B 模型） 解决率（%） 30.70（删除增强后训练） 25.40（纯代码后训练基线） +5.30 pp
CanItDelete 纯删除任务（7B 模型） deletion-compliant 成功率（%） 13.7 6.5 +7.2 pp
CanItDelete 不完整删除率（7B 模型） incomplete deletion 失败占比（%） 66.5 80.4 −13.9 pp
CanItEdit 受指令代码编辑（7B 模型） 成功率（%） 45.70 44.30 +1.40 pp
CanItDelete 精确区间模式（Claude Opus 4.8） deletion-compliant 成功率（%） 97.7（exact lines） 78.6（vanilla） +19.1 pp
删除敏感 F2P 测试下的解决率（4 个前沿模型） 通过删除敏感测试的尝试比例（%） 41.9（57/136） 63.2（86/136 原测试通过） −21.3 pp（评测更严）

局限与改进

作者在结论里坦承了范围、构造、规模三方面的限制。现场分析依赖已提交的 SWE-bench Verified 补丁，解码设置不可控；删除敏感测试只覆盖 34 道删除重的任务，且这些任务本身是"删除重"的，不能代表整个 Verified。CanItDelete 的指令由 GPT-5.6 Sol 起草——而 GPT-5.6 Sol 本身是被评测的模型之一，存在自我评估的循环风险；任务来自 top-starred 仓库，其 post-edit 文件可能已进入训练数据，存在污染。训练试点只跑了一个 7B 模型，报告三跑均值但没有方差，能否在部署规模或其他语言上成立仍是开放问题。我从读者角度再补几点：Guard-and-Go 被当作偏差证据，但作者自己也承认保留目标可能属于"有效的替代修复"，单条保留不能定错——这意味着 29.0% 这个数字是"潜在偏差上限"而非确切错误率；AST 失败时退化为"相邻删除行合并成单组"的兜底，可能在边界判定上引入噪声；十型 Guard-and-Go 分类由 LLM 打标签，虽要求引用证据并抽样 50 条人工核验，但仍是间接证据。

独立分析的弱点

第一，**训练证据仅单点单模型**：只有一个 7B、没有方差、没有 scaling curve。改进方向是做 1B/7B/30B/70B 多尺度对照，并报告多 seed 标准差，验证"删除监督"是否随规模保持或放大。第二，**Guard-and-Go 的语义含糊**：作者自己说保留可能是有效替代，但论文用 29.0% 作为核心叙事。改进方向是引入行为等价性检查（差分测试、变异测试）区分"真偏差"与"等价替代"，给偏差率一个更紧的下界。第三，**训练仍只是把"删不够"换成"删过头"**：表 4 显示 complete-but-invalid 编辑从 13.1% 升到 19.8%、over-deletion +6.2 pp。改进方向是把"边界控制"作为独立训练目标，例如构造"恰好删一行 vs 多删一行"的对比对，专门强化停止行为。第四，**CanItDelete 语言覆盖不均**：49 道 JS 家族 vs 151 道 Python，且全部来自 top-100 高星仓库，对长尾语言（Rust、Go、Java）和大型企业代码无代表性，应扩展语言与仓库谱系。第五，**评估器对 LLM 分类器的依赖**：策略标签和 Guard-and-Go 子型都靠 MiniMax-M2.7，可换成规则化结构匹配（AST diff 模式）减少模型偏差。第六，**自我指令污染**：用被测模型起草 CanItDelete 指令，未来应让不参与评测的模型或人工生成指令。

未来方向

作者明确点出的方向：把删除监督在更大模型、更多语言、部署规模上验证，并把"删除完成"与"边界控制"拆成两个独立训练目标分别强化。基于成果可延伸的方向我能想到几条：(1) 把诊断阶梯思路推广到其他编辑子能力——"修改""搬移""重命名"也都能做"精确区间"对照，系统刻画 LLM 编辑能力的各维度短板；(2) 把删除敏感测试的思路产品化，开发一个"减法覆盖"工具，自动给 SWE-bench 类任务补生成 F2P 测试，让基准分数更接近合并就绪度；(3) 探索 Guard-and-Go 与已知失败模式（specification gaming、weak tests）的因果关系，看是否可用更小的删除敏感测试集廉价预测补丁可维护性；(4) 在 RLHF / RLAIF 阶段引入"删除简洁性"奖励，把训练时的加性偏好直接对冲；(5) 用本文的 occurrence-aware 评估器审计真实生产 PR，量化删除回避在生产代码中的经济损失，给工业部署一个 ROI 视角。

复现评估

复现门槛中等偏高。有利的是：作者声明所有度量与复现代码、CanItDelete 基准、诊断阶梯与分类 prompt 都在补充材料中（因匿名暂不公开，接收后释放）；数据源自公开 GitHub 仓库，挖矿与排序公式（结构挑战指数 $d_{V2}$、删除单元启发式表 13）都写得很细；评估器完全确定性、不让 LLM 当裁判，结果可重复。不利的是：现场分析依赖 5 个 leaderboard 提交的具体补丁，需要从 SWE-bench experiments 仓库拉取特定目录；被测前沿模型（Claude Opus 4.8、GPT-5.6 Sol、GLM-5.2、DeepSeek-V4-Pro 等）多为闭源 API，调用成本与时间窗口受限；训练试点的 7B 模型是"工业部署同族"的匿名内部模型，硬件 128 xPUs 也非通用资源，他人难以精确复现训练曲线；CanItDelete 指令由 GPT-5.6 Sol 起草，若用不同模型重生成会引入分布差异。综合判断：评估与诊断部分可独立复现，训练干预部分需替换模型与硬件近似复现，结论方向可验证但绝对数字会有偏移。

论文图表

Figure 1: An example of deletion avoidance in a solved SWE-bench Verified task.

以 psf__request:2317 为例，并排展示开发者补丁与 Opus 4.5 模型补丁。开发者删除了 `method = builtin_str(method)` 这句赋值；模型保留该句，在外层加 `if isinstance(method, bytes): method = method.decode('utf-8')`，再用 `else:` 守卫让原赋值只在非 bytes 输入时执行。两版都 `return resp`，都通过原测试、都被记为已解决，但模型版把废弃代码永久留在仓库里。图右侧用色块标注"开发者补丁删除的行"vs"模型补丁保留的行"。

这是全文最直观的证据，一张图说清"删除回避"到底是什么、为什么测试通过不等于修对了。读者理解整篇论文的动机都应从这张图入手。

Structural distributions across the 200 CanItDelete tasks.
Figure 6: Structural distributions across the 200 CanItDelete tasks.

附录四张小直方图：预编辑 LOC（中位 1,551，IQR 1,266–1,800）、删除行数（中位 34，IQR 29–39）、删除 hunk 数（中位 4，IQR 3–5）、指令词数（中位 8，IQR 6–10）。说明任务平均涉及 1,500+ 行的文件、删 30+ 行、分散在 4 个 hunk，是有意挑选的"多站点删除"压力测试。

这张图解释 CanItDelete 为什么是 stress test 而非代表性样本——任务刻意选难，读者据此才能正确解读后续绝对成功率（不能拿它和 SWE-bench 直接比数字）。