删除回避：LLM 代码编辑中的系统性缺陷与缓解之道

Amir M. Ebrahimi, Mohammed Mehedi Hasan, Aaditya Bhatia,

Gopi Krishnan Rajbahadur, Ahmed E. Hassan

摘要

大语言模型越来越多地编写和修复生产代码，然而越来越多的证据表明，它们通过测试的补丁会让代码库变得更难维护。我们找到了一个具体的原因：删除回避，即系统性地倾向于保留本应被预期编辑所移除的代码。在官方 SWE-bench Verified 排行榜上排名前五的模型中，即使是在五个模型都能解决的任务上，针对开发者补丁的删除召回率最高也仅为 71.7%；模型在超过 92% 的必要删除场景中能定位到正确的文件，但在不到 52% 的情况下能精确删除到具体行。相反，29.0% 的通过补丁会将目标代码包裹在守卫或回退逻辑中，我们将这种模式称为“Guard-and-Go”。这类补丁之所以能通过，是因为原始测试很少检查删除行为：当我们为 34 个 Verified 任务改造测试，使其在目标代码仍然存在时判定失败，四个涵盖闭源和开源权重的前沿模型从 63.2% 下降到 41.9%。由于真实修复往往同时涉及删除和新增，我们构建了 CanItDelete 基准，包含从真实提交中挖掘的 200 个任务，其全部所需编辑仅为删除。即使去掉了新增工作，最好的模型仍然每五个任务中失败一个，而较小的开源模型则降至 18.0%。随后，我们在四种累积提示条件下对 GPT-5.6 Sol 进行消融实验；在提供精确行号之前，成功率几乎没有变化，而提供精确行号后几乎消除了不完整删除，但成功率仅提升到 80.5%，因为模型随后会删除超出目标范围的内容或转而添加代码。最后，通过一项试点研究，我们展示了一种潜在的修复方案：在后训练阶段教授删除行为可以减少删除回避，并提升更广泛的代码编辑性能，这表明该行为是训练不足所致，而非无法实现。

1 引言

前沿大语言模型如今已处于编码智能体的核心位置，这些智能体能在极少监督下解决问题、审查代码并提交拉取请求。它们产出的内容是否达到可合并标准——即维护者愿意将其纳入项目——与代码能否运行是两回事。在一个大型 GitHub 语料库中，46.4% 由智能体编写的修复被拒绝（Abujadallah et al. 2026; Alam et al. 2026），而且多个项目明确拒绝接受 AI 生成的贡献（QEMU Project 2025）。维护者审阅了三个 SWE-bench Verified 仓库中 296 个已通过测试的智能体拉取请求，其合并率比基准分数低 24 个百分点，理由是代码冗长且偏离仓库惯例（Whitfill et al. 2026）。

提交统计数据也指向同样的结论。在分析的 6.23 亿次变更中，删除或更新超过十二个月旧代码的编辑在 2023 年后下降了 74%，而掩盖错误的构造则上升了 47%（GitClear 2026）。智能体补丁显得臃肿的一个原因是，模型会把本应被该变更删除的代码保留在原处。审阅智能体编写的拉取请求的审查者通常会删除生成的函数，而他们在决定之前必须完整阅读这些函数（Watanabe et al. 2026）。

图 1 直接展示了这一行为：一位开发者移除了一段过时的赋值语句，而面对同一问题的模型则保留该赋值，并通过条件分支让执行绕开它。两个补丁都通过了相同的测试，且都被标记为已解决。我们将此称为“删除回避”（deletion avoidance），即系统性地倾向于保留本应被预期编辑删除的代码；我们用这一术语来描述可观察到的补丁行为，而非内部意图。

现实世界中的删除回避现象。

在 SWE-bench Verified 的五个领先提交方案中，即使在五个方案都能解决的任务上，补丁仍会保留开发者删除内容中四分之一到三分之一的代码。模型并非找不到代码：对于超过 92% 的目标行，它们会编辑包含所需删除内容的文件，并且对于 68.1% 到 74.4% 的情况会编辑包含该行的函数、类或模块，但在 44.6% 到 51.6% 的情况下才会删除确切的那一行。它们实际写出的内容遵循一种主导策略：模型保留开发者删除的逻辑，并在其周围添加条件或绕过方式。我们将此称为“Guard-and-Go”，它占所有通过补丁的 29.0%。这类补丁之所以能通过，是因为原始测试很少检查删除操作。当我们为 34 个删除密集型的 Verified 任务改造检查逻辑，使已验证的删除目标仍然存在时测试失败，四个前沿模型的解决率下降了 21.3 个百分点，86 个先前通过的尝试中有 29 个失败。

CanItDelete：孤立环境下的删除能力评估。

这些都不能将失败归因于删除本身：SWE-bench 任务中没有任何一项要求删除操作，定位问题本身在基准测试中就很困难（Al Awad 和 Ivanov 2026；Sepidband 等人 2026），而且开发者补丁将删除与新增工作混合在一起。CanItDelete 消除了这些干扰因素：从真实提交中挖掘出 200 个任务，其全部所需编辑就是删除，任务基于完整的编辑前文件提出，并由确定性的、感知出现次数的评估器进行评分。在涵盖前沿和开放权重模型的十二个模型中，成功率从 79.0% 一直下降到 18.0%，并且对于十二个模型中的十个来说，不完整的删除主导了失败原因。随后，一个诊断阶梯逐步添加了明确的删除指令、区域指针，最后是精确的待删除范围；只有提供精确范围才对每个模型都有帮助。即使提供了这些，GPT-5.6 Sol 仍然在 19.5% 的任务上失败，现在失败的主要原因是删除超出了边界或添加了代码，而不是保留了目标。删除在两方面都会失败：当边界不确定时删除过少，一旦给出边界又删除过多。模型缺乏的是控制力，而非能力。

最后，删除行为是可学习的，而非模型能力缺失。在 7B 模型的代码后训练数据混合中加入 12.8k 条删除示例（仅占其 token 的 0.7%），即可将 CanItDelete 上的删除回避率降低 13.9 个百分点，且这一收益可迁移至训练数据从未针对的基准，使 SWE-bench Verified 提升 5.3 分、CanItEdit 提升 1.4 分。因此，删除行为在代码后训练中可能只是代表性不足，而非超出模型能力范围。我们将此作为单一规模下的概念验证进行报告。

贡献。

我们在真实仓库修复中定义、刻画并量化了删除回避行为，识别出 Guard-and-Go 为其主要形式，并展示了在通过删除敏感检查后，已报告的问题解决率还剩多少。我们发布了 CanItDelete——一个纯删除基准，配备确定性的事件感知评估器，以及一个可定位删除失败环节的诊断阶梯。所有测量与复现代码、基准及提示词均包含在补充材料中，为保持匿名性暂不公开，将在论文被接收后发布。

2 大语言模型在实践中是否会回避删除代码？

SWE-bench Verified 衡量的是补丁能否解决问题，而非补丁如何改变代码。当开发者修复是删减性的时，这一区别至关重要：模型可能删除了同样的过时逻辑，也可能在新增控制流之后保留该逻辑，同时仍满足被测行为。我们探究的问题是：模型是否在这一方向上系统性地偏离开发者修复，以及它们用什么样的代码替代了开发者删除的代码。

我们将开发者补丁视为行为参照，而非唯一正确答案。保留参照删除内容的模型可能拥有有效的替代修复方案，因此仅凭不一致并不能判定为错误。相反，我们寻找跨模型、跨任务反复出现的证据：模型是否始终比开发者删除得更少、在到达相关代码后这一差距是否依然存在，以及被保留的逻辑是否呈现某种共同的结构形式。

2.1 研究设计

补丁。我们分析了五种模型各自在基于 OpenHands 的 SWE-bench Verified 排行榜上最新的提交记录：GLM-4.6、GPT-5、Kimi-K2、Opus-4.5 和 Salesforce SAGE。不同的脚手架在调用工具和定位代码的方式上有所差异，而这些差异本身就可能影响编辑行为，与底层模型无关。因此，我们固定脚手架不变，以减少这一变量带来的影响。附录 A.1 中的表 5 列出了各提交记录、其日期以及筛选流程。

任务。我们将随每个 SWE-bench 任务一起发布的人工编写补丁称为开发者补丁。当该补丁从某个非测试 Python 文件中删除至少一行，且未在同一函数、类或模块内将该行恢复时，我们保留该任务；500 个 Verified 任务中有 377 个满足此标准。我们分析了 254 个结果一致的任务：其中 197 个五个模型全部解决，57 个五个模型全部失败，其余 123 个暂不纳入分析。通过将比较限定在结果一致的任务上，我们在各模型之间同时固定了任务和结果两个变量。我们以描述性的方式解读解决与未解决任务之间的差异，因为没有任何模型能解决的任务，其难度可能源于与删除行为无关的其他因素。

参考删除。参考删除是指开发者补丁从非测试 Python 文件中移除的源代码位置。我们通过将两个补丁都应用到基线提交上来识别这些位置。如果被删除的行在开发者补丁的新增内容中，于同一外层函数、类或模块内再次出现，我们会将其排除，因为这属于代码移动而非删除。只有当模型删除了同一文件的同一位置时，才视为匹配了一次参考删除；在其他位置删除相同文本不算匹配。我们会检查模型接触到的每一个非测试 Python 文件，包括开发者补丁未涉及的文件，从而确保模型做出的、开发者未做出的删除操作也能被记录下来，而不是被遗漏。

指标。设 为任务 的参考删除集合， 为模型 删除的位置。删除召回率是指开发者删除中模型同样执行删除的比例：我们对各任务的召回率进行宏平均，使一行删除与二十行删除获得相同权重。由于召回率衡量的是模型复现开发者删除的比例，我们将其作为首要指标。我们还计算删除精确率，即模型删除与参考位置匹配的比例，并在附录 A.2 的表 6 中报告。各任务的召回率有界且呈偏态分布，因此我们使用双侧 Mann–Whitney 检验比较成功与失败任务，并报告 Cliff's 及经 Holm 校正的 -值（附录 A.3 的表 7）。最后，为将搜索与执行分离，我们在三个嵌套层级检查每个参考删除：模型补丁是否修改了对应文件，是否修改了其所在作用域（即包含的函数、类或模块）内的至少一行，以及是否删除了精确的那一行。GttMt,mmRt,m=|Gt∩Mt,m||Gt|.Uδp

2.2 通过测试的补丁仍会保留开发者删除的代码

被 SWE-bench Verified 判定为正确的补丁，平均每个任务仍会保留 28.3% 至 34.8% 的参考删除。在 197 个已解决任务中，平均删除召回率从 Kimi-K2 的 65.2% 到 Opus-4.5 的 71.7% 不等（表 1）。因此，通过测试缩小了与开发者删除之间的差异，但并未消除这一差异。

模型无法删除它从未触及的代码，因此我们接下来探究定位是否解释了这一差异。在这同样的 197 个任务中，模型修改包含删除的文件的比例为 92.5% 至 94.4%，修改其所在作用域（即包含的函数、类或模块）的比例为 68.1% 至 74.4%，但仅在 44.6% 至 51.6% 的情况下删除了精确的那一行（附录 A.4 的图 5）。定位解释了从文件到作用域的下降。但它无法解释在模型已修改所在作用域之后，进一步出现的 21.4 至 27.8 个百分点的下降。修改一个作用域并不能证明模型检查了其中的每一行，但我们不能将剩余差异归因于编辑了错误的文件。

在模型失败的场景中，这种分歧更为显著。在全部五个模型都失败的 57 个任务中（表 1），召回率降至 19.8% 至 30.4% 之间，且这两个任务集在每个模型上都以 Holm 校正后的显著差异分离，Cliff's 值介于 0.485 至 0.543 之间，全程呈现大效应量。删除精确率的表现类似（附录 A.3 表 8）。无论任务成功还是失败，每个模型的删除量都低于开发者。p<10−8δ

2.3 模型用新增控制流替代删除操作

较低的删除召回率仍可能反映有效的替代实现方式，因此我们考察模型在开发者删除的逻辑位置上实际写了什么。基于 LLM 的分类器 MiniMax-M2.7 为每个任务-模型对分配三个标签之一。Delete-and-Replace（删除并替换）移除或替换了开发者删除的大部分逻辑。Guard-and-Go（守护并绕过）保留该逻辑，并在其周围引入条件判断或旁路。非参照替代（non-reference alternative）则两种模式都不符合，而是在其他位置解决问题。分类器接收问题描述、两个补丁以及预计算的删除特征，并且必须用所提供 diff 中的代码行来支撑其标签；凡引用的证据不存在的标签，我们一律拒绝。由于这种分类不需要成功-失败的对比，我们在五个官方排行榜提交中所有可用的任务-模型对上运行，而非仅限于 254 个一致任务，共得到 2,487 个候选对。我们排除了 129 个无法解析开发者补丁的对，剩余 2,358 个。附录 B 报告了所提供的特征、验证流程以及完整的标签定义。提示词可在复现包中获取。

在 1,703 个通过的对中，有 494 个（29.0%）保留了开发者删除的逻辑并在其周围路由执行（表 2）。Guard-and-Go 占通过对的 29.0%，巧合的是，它也占全部 2,358 个已标注对的 29.0%。Guard-and-Go 在 72.2% 的情况下通过，低于 Delete-and-Replace 的 85.2%，但远高于非参照替代的 39.6%，且 655 个失败对中有 190 个采用了相同的策略。因此，同样的替代模式既出现在基准测试接受的补丁中，也出现在其拒绝的补丁中。

我们开源了这些配对数据，每一轮之后都会修订类别，直到类别趋于饱和，最终将结果整合为十种结构形态。随后由一名封闭编码员将其应用于全部 684 对 Guard-and-Go 数据，其中 550 对成功归类，其余 134 对因不符合条件而放弃；附录 B 给出了具体流程和完整定义。“保留原路径作为实时后备”这一形态在 550 对已归类数据中占 221 对（40.2%），比紧随其后的三种形态之和还要多。在这种形态下，新增的防护逻辑负责处理被报告的问题场景，而开发者删除的逻辑仍然是所有其他输入的默认路径。

这类补丁以可执行形式保留了开发者删除的路径，因此阅读者必须自行判断原有路径和新增路径是否都仍有必要存在。维护者在审查智能体生成的补丁时也报告了同样的负担：他们必须先阅读生成的代码，然后才能将其删除（Watanabe 等，2026）；此外，当补丁已通过自动化评分器时，他们也会因代码冗长、不符合仓库既有规范而予以拒绝（Whitfill 等，2026）。

避免删除往往会扩大补丁的规模。在 61.1% 的配对中，通过 Guard-and-Go 的补丁比对应的开发者补丁更大，规模中位数比值为 1.67。不同模型之间的差异相当显著：GLM-4.6 有 97.8%、Kimi-K2 有 81.5% 的 Guard-and-Go 补丁更大，而 Opus-4.5 仅为 33.0%（见附录 A.5 表 9）。仅凭补丁大小并不能证明新增代码是不必要的。然而，如果结合策略标签一起看，就会发现模型往往会把开发者的减法式修复变成更大的补丁——保留原有逻辑，同时额外增加一条控制路径。×

3 通过测试能否检测缺失的删除？

第 2 节表明，模型反复保留了开发者已移除的逻辑，并将其置于新增的 guard 和绕过逻辑之后，包括在 SWE-bench Verified 记录为已解决的补丁中也是如此。将模型补丁与开发者补丁进行对比，无法确定如何解读这种差异。保留的目标可能属于一种充分的替代性修复，也可能原始测试并不要求将其删除。因此，我们修改的是评估标准而非模型本身，为 Verified 任务加装检查逻辑——当已验证的删除目标仍然存在时检查失败——并衡量报告的解决率在多大程度上得以保留。

在 69 个删除内容至少占开发者补丁四分之一的 Verified 任务中，我们通过一种感知 AST 的流程识别出实质性的删除目标，该流程优先处理被移除的条件、控制流语句和完整代码块。随后我们构建了一个源码级的删除敏感检查，要求该目标不得存在于其所在作用域中，并且仅当该检查在基线版本上失败、而在应用开发者补丁后通过时，才保留该任务。最终留下 34 个具有已验证删除目标、且存在可移除这些目标的已验证修复的任务（参见附录 C 中的补充材料）。

我们没有复用第 2 节中分析的提交，而是用四个前沿模型生成了补丁，涵盖闭源与开源权重：GPT-5.6 Sol、Opus 4.8、GLM-5.2 和 DeepSeek-V4-Pro。这些提交都早于 2025 年 12 月，因此对它们应用删除敏感性检查，无法说明当前系统是否仍表现出该行为（SWE-bench Team 2025; OpenAI 2026）。我们在第 4 节中使用相同的模型，在受控条件下考察删除行为。

在我们生成的 136 次尝试中，86 次（63.2%）通过了原始测试套件，57 次（41.9%）同时满足删除敏感性检查。绝对下降幅度为 21.3 个百分点，86 个被接受的尝试中有 29 个（33.7%）保留了已验证的目标。每个模型都有下降，幅度在 17.6 到 23.5 个百分点之间（表 3）。

由于每个任务和模型补丁在两种标准下都是固定的，成对下降反映的是更严格的评估，而非任务或生成设置的变化。在这些删除密集的任务上，原始套件接受的补丁中约有三分之一保留了开发者修复所移除的已验证目标。

然而，我们的每个检查都源自开发者补丁移除的目标，而我们的实验衡量的是在该移除要求下的表现，而非证明删除是唯一行为上有效的修复方式。另一种修复方式可能保留目标，同时仍然满足原始行为规范。这 34 个任务在构造上也是删除密集型的，并不代表整个 SWE-bench Verified。因此，这种回溯性改造识别出了评估缺口，但并未隔离出模型为何无法生成删除性修复的原因。完整仓库任务仍然将删除决策与定位、边界识别以及配套实现工作纠缠在一起。

4 CanItDelete：用于删除回避的诊断基准

第2节和第3节表明，模型会保留开发者已删除的代码，而行为测试套件会接受许多包含此类保留代码的补丁。这两项研究都没有将失败归因于删除本身：在完整仓库修复中，遗漏删除可能源于定位环节、替换代码或周围的实现工作，而且任务中没有任何内容明确要求必须删除。因此，我们构建了CanItDelete，这是一个包含200个任务的基准，这些任务来自真实提交，其中删除是唯一需要的完整变换。由于参考编辑不添加任何内容，每个合规解决方案都必须执行相同的删除操作，同时保留无关代码，而失败输出反映的是模型的编辑行为，而非任务要求本身的歧义。图2总结了设计：构建流程（A）、信号阶梯（四种累积模式，每种模式增加一个定位线索）（B），以及我们的评估器所判定的失败分类（C）。分类和阶梯正是让该基准能够进行诊断而非简单排名的关键。附录D详细说明了基准构建与验证，附录D.4规定了删除合规性评估器。

4.1 基准设计

构建。

我们从 Python 和 JavaScript 各自星标数最高的 100 个活跃仓库中，挖掘出 79,074 次删除源代码行且不新增任何行的文件编辑。我们依据编辑前长度、删除行数和删除块这三个软件维护研究中确立的变更复杂度维度（Nagappan 和 Ball 2005；Kamei 等人 2013）的等权指数对这些编辑进行排序，并保留最难的 200 个任务，每个仓库-提交对仅取一个文件（图 2A）。我们刻意选择高压力场景：每个任务至少跨越三个相互分离的删除块，因此该基准强调多点删除而非单行清理。这 200 个任务来自 35 个仓库；其中 151 个为 Python，49 个属于 JavaScript 家族，53 个修改测试文件。我们仅在筛选之后才生成指令，使用 GPT-5.6 Sol 根据完整的编辑前文件和参考差异草拟简短的删除请求，并且每个任务都需通过 LLM 评分标准和作者审核，两者都要求请求覆盖每一次实质性删除，且仅凭编辑前文件即可定位（附录 D.2）。

评估。

我们使用确定性的、感知出现次数的评估器对输出进行评分；没有任何 LLM 评判任何输出。当完整目标缺失、其外部的可执行结构得以保留、且未引入任何影响行为或无关的变更时，输出即视为符合删除要求。注释掉或禁用目标不算数，删除重复行的一个副本也不会因另一个要求出现的不同位置而获得分数。我们按所需代码是否残留，将失败分为不完整删除和带无效编辑的完整删除两类；图 2C 列出了每一类中的具体机制，从“新增并保留”到“过度删除”。诊断阶梯提供四种累积模式：基础模式、显式删除、区域指针和精确行号，每种模式各增加一个线索，因此模型从一种模式到下一种模式的结果变化，可以揭示缺失的是意图、搜索还是边界知识（图 2B；定义见附录 D.3）。

4.2 删除回避在隔离条件下依然存在

表现最佳的前沿模型在五分之一仅需删除的任务中失败。Claude Opus 4.8 在我们评估的十二个模型中领先，删除合规成功率为 79.0%，GPT-5.6 Sol 以 74.0% 紧随其后（图 3）。即使我们排除了上述混杂因素，这些失败仍然存在：我们提供了完整文件，只要求删除，且任务不需要跨文件定位，也不需要替换代码。因此，第 2 节中在真实场景中测得的回避行为，在模型直接收到文件且删除就是全部任务的情况下依然存在，并且表现形式相同。“添加并保留”是这里最主要的失败机制，在受控条件下就是“守卫即放行”：用一次添加来顶替一次删除。

开放权重模型的领先者落后前沿模型约十二个百分点，其余开放模型则落后更多。其中最强的 Kimi K2 Thinking、MiniMax-M3、GLM-5.2 和 DeepSeek-V4-Pro 集中在 65.0%–67.0% 的狭窄区间内，而 Qwen 的 instruct 系列模型和更早的 MiniMax 版本仅达到 18.0%–47.5%，且失败的主要方式是遗留了本应删除的代码。任务集对这些模型具有区分度，而非在两端饱和：200 个任务中有 9 个被全部十二个模型解决，19 个没有任何模型解决，而每个中间的被解决数量也都出现在两者之间。

在这些通过率背后是两种截然不同的失败模式。不完整删除是十二个模型中十个的主要失败方式（合并占比 69.8%），但 GPT-5.6 Sol 和 GLM-5.2 定义了第二种模式：它们通常会移除目标，然后过度删除或越界编辑。模型落入哪种模式并不由能力决定。在图 3 的 GPT 系列中，不完整删除从 114 次下降到 20 次，而完全删除后的无效编辑从 14 次上升到 32 次；Qwen 在较低能力水平上表现出同样的此消彼长，而 MiniMax-M3 则同时降低了两者。单一的通过率只能记录进步；只有机制分解才能显示这是哪种进步。

4.3 即使给出需要删除的确切行，模型仍然失败

即使给出了需要删除的确切代码行，也没有任何模型是完美无瑕的，只有一个模型接近完美。在提供了具体出现位置的代码片段后，Claude Opus 4.8 达到了 97.7% 的成功率，而其他四个阶梯模型的成功率在 56.5% 到 87.5% 之间（图 4）。Qwen3-235B 在被告知确切要删除的内容后，仍有 17.5% 的任务保留了所需代码，这是删除回避行为持续存在的最明显迹象；并且在五个模型中，即使完整目标代码已被删除，仍有 1.7%–26.0% 的尝试失败，因为编辑操作超出了目标范围。

精确的代码片段是唯一能让所有模型产生变化的信号。它们将成功率提高了 6.5–31.5 个百分点，并将五个模型中的四个的不完全删除率降至 0.6–3.0%，而成本更低的信号则收效甚微：明确的“禁止变通”指令仅将成功率改变了几个百分点。区域指针将成功率改变了 0.0–7.0 个百分点，其中 GLM-5.2 的提升最大。删除回避并非对意图的误读，搜索也不是主要瓶颈；在我们提供精确代码片段之前，模型所缺乏的是对删除边界在哪里的认知。−2.5+2.5

抑制不完全删除暴露了第二种倾向——过度编辑。GPT-5.6 Sol 的无效编辑率在获得精确代码行后几乎没有变化，从 16.0% 变为 16.5%，而 Qwen3-235B 的无效编辑率则随着其保留率的下降从 20.5% 上升到 26.0%。因此，这个阶梯区分了单一通过率所混淆的两种能力——找到所有必需的代码出现位置并在其边界处停止：总体成功率无法判断模型在哪一方面有所改进，也无法判断它是否像 Qwen 那样，用一种失败换取了另一种失败，而模式差异和机制分解则可以做到这一点。当前模型缺乏的是控制力，而非能力。我们在附录 D.5 中报告了所有四种模式的逐模型结果。

5 针对删除的后期训练能否减少删除回避？

第 4 节表明，模型能够执行删除操作，但并不能可靠地主动选择删除，也无法保持删除的边界。一个合理的解释是，人们在语言模型中观察到的“加法偏好”与编码智能体中观察到的“行动偏差”相结合：当一项变更需要删除时，模型可能默认通过新增代码来行动（Adams et al. 2021; Santagata and De Nobili 2025; Gloaguen et al. 2026）。数据和目标函数都没有纠正这一点。加法偏差存在于模型所学习的文本中（Winter et al. 2023），而基于行为正确性的评估会接受“Guard-and-Go”方案，因为第 3 节表明，原始测试套件接受的三分之一补丁仍保留了应删除的目标。我们推测，在代码后训练阶段，删除行为没有得到充分强化——无论是在模型是否选择删除方面，还是在删除停止的位置方面。

由于删除是一种跨领域的代码编辑行为，而非独立的下游任务，我们将删除监督加入通用的代码后训练混合数据中，而不是训练一个专门针对删除的适配器。

概念验证干预。

我们使用了一个 7B 参数的内部模型，因为同一模型家族中更大的成员在我们的工业场景中支持编码工作流。222 模型和硬件细节已匿名化。我们向其纯代码后训练混合数据中增加了 12,821 个删除示例：其中 10,000 个为文件级编辑，2,821 个为使用 CanItDelete 流水线构建的仓库级修复。这些示例为 15.9B token 的混合数据贡献了 112.1M token，约占总量的 0.7%。附录 E 给出了构建和拒绝流程；我们将所有 CanItDelete 评估问题排除在训练之外。

两个检查点采用完全相同的训练方案：在 128 个 xPU 上以全局批大小 64 训练六个 epoch。基线模型在 15.9B token 的纯代码混合数据上进行后训练；干预组在同一混合数据中加入了删除子集，其余设置不变，因此两次运行的差异仅在于 0.7% 的训练 token。CanItDelete 用于衡量目标行为。其余三个基准覆盖了部署模型所服务的代码编辑工作负载：SWE-bench Verified 评估基于真实问题报告（Jimenez 等人，2024；OpenAI，2024）的仓库级修复，而 CanItEdit 和 EditBench 评估根据自然语言请求（Cassano 等人，2024；Chi 等人，2025）对现有代码进行指令式编辑。这些基准均不针对删除任务，因此它们共同检验该干预措施是否产生迁移或引入性能回退。我们对每个基准运行三次推理，并报告平均值。

删除训练减少了不完整删除的情况，并暴露了范围保持方面的失败。

CanItDelete 的成功率从 6.5% 提升至 13.7%，而不完整删除率从 80.4% 下降至 66.5%（表 4）。13.9 个百分点的降幅几乎对半分：7.2 个百分点转化为合规编辑，6.7 个百分点转化为完整但无效的编辑，而仅过度删除一项就上升了 6.2 个百分点。因此，该干预措施使模型更有可能完成所需的删除操作，但尚未教会模型删除应在何处停止。

增益集中在删除属于任务本身的场景。SWE-bench Verified 提升了 5.3 个百分点，而 CanItEdit 提升了 1.40，EditBench 则保持不变：在 500 个 Verified 任务中，有 377 个要求至少从非测试文件中进行一次删除（第 2 节），而两个指令式编辑基准都不以删除为导向。因此，该效果是选择性的而非均匀的，这正是删除特定机制所预测的结果。−0.19

所研究的基准中，没有任何一个下降超过 0.2 分，因此该干预措施通过了本次试点旨在检验的回归门槛。我们将这一结果视为一个信号而非解决方案：减少加性替换并未消除对代码采取行动的倾向，这种倾向现在以过度删除的形式浮现出来，因此删除完成与边界控制是两个不同的训练目标。两者在部署规模下是否仍然成立，留待未来工作验证。

6 相关工作

加性偏差与删除行为。

人们系统性地偏好加性变化而非减性变化（Adams 等，2021），这种偏差在英语语料库统计中有所体现（Winter 等，2023），并且大语言模型在受控任务中也继承了这一倾向（Santagata 和 De Nobili，2025）。编码智能体表现出相关倾向，即在不作为才是正确选择时仍然采取行动（Gloaguen 等，2026）。大语言模型补丁也可能朝相反方向出错，删除无关代码并破坏正常工作行为（Chong 等，2026）。这些研究都是在合成、无操作或相邻编辑场景中进行的，没有一项研究考察模型在真实代码库修复中是否会保留开发者删除的代码。

基于测试的代码编辑评估的有效性。

通过基准测试的测试用例并不能证明所请求的修改已正确实现。对 SWE-bench 的审计报告指出，存在测试用例薄弱、通过标记错误以及任务规范有缺陷等问题（Aleithan 等人，2024；Yu 等人，2025；OpenAI，2026）。覆盖范围也很窄：EDIT-Bench 中 56% 的测试仅覆盖被编辑区域（Ebrahimi 和 Rajbahadur，2026），这为规范博弈留下了空间（Krakovna 等人，2020；Ma 等人，2026）。仅做删除的 Kali 补丁则从另一个角度说明了问题——它们通过了测试，却并未修复缺陷（Ginelli 等人，2022）。这些工作均未将删除行为单独作为目标行为进行隔离研究。

用于代码编辑与修复的基准测试。

SWE-bench 及其 Verified 子集基于真实问题报告评估仓库级修复能力（Jimenez 等人，2024；OpenAI，2024），而指令式编辑基准则评估以自然语言提出的修改请求（Cassano 等人，2024；Chi 等人，2025；Guo 等人，2025）。先前的研究还表明，提供定位信息有助于提升修复效果（Al Awad 和 Ivanov，2026；Sepidband 等人，2026）。在所有情况下，参考补丁都同时包含新增、修改和删除操作，因此没有任何一个基准能够单独评估大语言模型执行纯减法编辑的能力。CanItDelete 将删除设为必需行为，并增加了一个诊断阶梯，用于区分意图失败、定位失败和范围保持失败。

7 结论与局限性

删除回避行为在当前的代码模型中普遍存在：被 SWE-bench Verified 标记为已解决的补丁，仍保留了开发者删除内容中的四分之一到三分之一，用新增控制流替代了删除操作，并且由于测试很少检查这一点，这些补丁得以通过，因此解决率高估了可直接合并的就绪行为。当删除成为全部任务时，这一差距依然存在，而精确跨度只是将保留问题换成了过度删除问题：模型缺乏的是对删除的控制能力，而非删除能力本身。适度的删除监督可以减少该行为并提升仓库级修复效果，因此这一缺陷更像是训练不足所致，而非模型固有能力缺失。

这些研究发现在范围、构建方式和规模上均存在局限性。野外分析基于提交的 SWE-bench Verified 补丁，且解码设置不受控；删除敏感性检查覆盖了 34 个删除密集型任务。CanItDelete 指令由 GPT-5.6 Sol（其本身即为被评估模型）根据星标最多的代码仓库起草，这些仓库编辑后的文件可能出现在训练数据中。该试点研究训练了一个 7B 模型，并报告了三次运行的平均值而未给出方差；删除监督在部署规模或其他语言上是否依然有效，仍有待探索。

参考文献

• M. Abujadallah, A. Arabat, and M. Sayagh (2026) 理解智能体拉取请求生成的修复被拒绝的原因：来自 AIDev 数据集的见解。arXiv 预印本 arXiv:2606.13468。引用于：§1。
• G. S. Adams, B. A. Converse, A. H. Hales, and L. E. Klotz (2021) 人们系统性地忽视减法式变更。Nature 592 (7853), pp. 258–261。外部链接：文献。引用于：§5, §6。
• M. N. Al Awad and S. Ivanov (2026) Loc2Repair：一个评估文件级问题定位在仓库级 LLM 修复中影响的框架。arXiv 预印本 arXiv:2606.30963。引用于：§1, §6。
• K. Alam, S. Mondal, and B. Roy (2026) 为什么涉及 AI 智能体的拉取请求（与修复相关）仍未合并？一项实证研究。ArXiv abs/2602.00164。外部链接：链接。引用于：§1。
• R. Aleithan, H. Xue, M. M. Mohajer, E. Nnorom, G. Uddin, and S. Wang (2024) SWE-Bench+：面向 LLM 的增强编码基准。arXiv 预印本 arXiv:2410.06992。引用于：§6。
• F. Cassano, L. Li, A. Sethi, N. Shinn, A. Brennan-Jones, A. Lozhkov, C. J. Anderson, and A. Guha (2024) 它能编辑吗？评估大语言模型遵循代码编辑指令的能力。收录于语言建模会议（COLM）论文集。引用于：§5, §6。
• W. Chi, V. Chen, R. Shar, A. Mittal, J. Liang, W. Chiang, A. N. Angelopoulos, I. Stoica, G. Neubig, A. Talwalkar, and C. Donahue (2025) EDIT-Bench：评估 LLM 执行真实世界指令式代码编辑的能力。收录于第 42 届国际机器学习大会（ICML）论文集。外部链接：链接。引用于：§5, §6。
• C. J. Chong、M. Ahmed、Z. Yao 和 I. Neamtiu（2026）《大语言模型能否成为高效的代码贡献者？一项关于开源项目的研究》。载于《软件工程评估与评价国际会议（EASE）论文集》，外部链接：Link，被引于：§6。
• A. M. Ebrahimi 和 G. K. Rajbahadur（2026）《编辑，但需验证：对指令式代码编辑基准的实证审计》。arXiv 预印本 arXiv:2604.05100。外部链接：Link，被引于：§6。
• D. Ginelli、M. Martinez、L. Mariani 和 M. Monperrus（2022）《自动程序修复中代码删除补丁的综合研究》。《实证软件工程》27 卷（第 4 期）。外部链接：Document，被引于：§6。
• GitClear（2026）《可维护性差距：2026 年 AI 代码质量》。技术报告，GitClear。注：https://www.gitclear.com/the_ai_code_quality_maintainability_gap，被引于：§1。
• T. Gloaguen、N. Mündler、M. Müller、V. Raychev 和 M. Vechev（2026）《编程智能体不知道何时该行动》。arXiv 预印本 arXiv:2605.07769。外部链接：Link，被引于：§5、§6。
• J. Guo、Z. Li、X. Liu、K. Ma、T. Zheng、Z. Yu、D. Pan、Y. Li、R. Liu、Y. Wang、S. Guo、X. Qu、X. Yue、G. Zhang、W. Chen 和 J. Fu（2025）《CodeEditorBench：评估大语言模型的代码编辑能力》。载于 ICLR 2025 第三届 DL4C 研讨会：《代码深度学习的涌现可能性与挑战》，注：发表于 OpenReview，外部链接：Link，被引于：§6。
• A. E. Hassan（2009）《利用代码变更的复杂度预测缺陷》。载于《第 31 届国际软件工程会议（ICSE）论文集》，第 78–88 页。外部链接：Document，被引于：§D.1。
• C. E. Jimenez、J. Yang、A. Wettig、S. Yao、K. Pei、O. Press 和 K. Narasimhan（2024）《SWE-bench：语言模型能否解决真实的 GitHub 问题？》。载于《第十二届国际学习表征会议（ICLR）论文集》，被引于：§5、§6。
• Y. Kamei、E. Shihab、B. Adams、A. E. Hassan、A. Mockus、A. Sinha 和 N. Ubayashi（2013）《即时质量保证的大规模实证研究》。《IEEE 软件工程汇刊》39 卷（第 6 期），第 757–773 页。外部链接：Document，被引于：§D.1、§4.1。
• V. Krakovna、J. Uesato、V. Mikulik、M. Rahtz、T. Everitt、R. Kumar、Z. Kenton、J. Leike 和 S. Legg（2020）《规格游戏：AI 创造力的另一面》。备注：DeepMind 博客，https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/ 访问于 2026 年 7 月。引用自：§6。
• Y. Li、F. Guerin 和 C. Lin（2024）《LatestEval：通过动态且时效敏感的测试构建解决语言模型评估中的数据污染问题》。载于 AAAI 人工智能会议论文集，外部链接：Link。引用自：§D.2。
• Y. Ma、B. Kereopa-Yorke 和 B. Schultz（2026）《为测试而构建：编程智能体交付的是你检查的内容，而非你要求的内容》。arXiv 预印本 arXiv:2606.28430。外部链接：Link。引用自：§6。
• M. A. Merrill、A. G. Shaw、N. Carlini、B. Li、H. Raj、I. Bercovich、L. Shi、J. Y. Shin、T. Walshe、E. K. Buchanan 等人（2026）《Terminal-bench：在命令行界面中对智能体进行困难、真实任务的基准测试》。arXiv 预印本 arXiv:2601.11868。引用自：§E.2。
• R. Moser、W. Pedrycz 和 G. Succi（2008）《变更度量与静态代码属性在缺陷预测中效率的比较分析》。载于第 30 届国际软件工程会议（ICSE）论文集，第 181–190 页。外部链接：Document。引用自：§D.1。
• N. Nagappan 和 T. Ball（2005）《使用相对代码变更量度量预测系统缺陷密度》。载于第 27 届国际软件工程会议（ICSE）论文集，第 284–292 页。外部链接：Document。引用自：§D.1、§4.1。
• Z. Ni、H. Wang、S. Zhang、S. Lu、Z. He、Z. Tang、S. Hu、B. Li、C. Hu、B. Jiao 等人（2026）《Gittaskbench：一个通过代码仓库利用解决真实世界任务的代码智能体基准》。载于 AAAI 人工智能会议论文集，第 40 卷，第 32564–32572 页。引用自：§D.2。
• OpenAI（2024）《推出 SWE-bench Verified》。备注：https://openai.com/index/introducing-swe-bench-verified/ 引用自：§5、§6。
• OpenAI（2026）《为什么 SWE-bench Verified 不再衡量前沿编程能力》。备注：https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/ 访问于 2026 年 7 月。引用自：§3、§6。
• S. Ouyang、D. Huang、J. Guo、Z. Sun、Q. Zhu 和 J. M. Zhang（2026）DSCodeBench：一个用于数据科学代码生成的现实基准测试。载于《AAAI 人工智能会议论文集》，第 40 卷，第 32628–32636 页。引用自：§D.2。
• QEMU 项目（2025）代码溯源：AI 内容生成器的使用。注：https://github.com/qemu/qemu/blob/master/docs/devel/code-provenance.rst 引用自：§1。
• L. Santagata 和 C. De Nobili（2025）多多益善：大语言模型中的加法偏差。《人类行为中的计算机：人工智能人类》。注：https://doi.org/10.1016/j.chbah.2025.100143 引用自：§5、§6。
• M. Sepidband、H. V. Pham 和 H. Hemmati（2026）论故障定位上下文在基于 LLM 的程序修复中的作用。arXiv 预印本 arXiv:2604.05481。外部链接：链接 引用自：§1、§6。
• SWE-bench 团队（2025）提交至 SWE-bench。注：SWE-bench 排行榜提交文档。官方提交维护在 SWE-bench 实验仓库中；访问于 2026 年 7 月。外部链接：链接 引用自：§3。
• K. Watanabe、T. Shirai、Y. Kashiwa 和 H. Iida（2026）该删什么？预测智能体代码生成中的冗余方法。载于《第 23 届国际软件仓库挖掘会议（MSR）论文集》。外部链接：文档 引用自：§1、§2.3。
• P. Whitfill、C. Wu、J. Becker 和 N. Rush（2026）许多通过 SWE-bench 的拉取请求并不会被合并到主分支。注：METR 研究笔记。https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/ 引用自：§1、§2.3。
• B. Winter、M. H. Fischer、C. Scheepers 和 A. Myachykov（2023）更多即更好：英语语言统计偏向于加法。《认知科学》47（4），第 e13254 页。外部链接：文档 引用自：§5、§6。
• B. Yu、Y. Zhu、P. He 和 D. Kang（2025）UTBoost：对 SWE-Bench 上编码智能体的严格评估。载于《计算语言学协会第 63 届年会（ACL）论文集》。引用自：§6。
• Q. Zhu、J. Cao、Y. Lu、H. Lin、X. Han、L. Sun 和 S. Cheung（2024）Domaineval：一个自动构建的多领域代码生成基准测试。arXiv 预印本 arXiv:2408.13204。引用自：§D.2。

附录 A：删除规避行为的定量分析

A.1 实证分析的模型选择

为控制智能体脚手架（agent scaffolding）引入的变量，我们采用一致的程序，从官方 SWE-bench Verified 提交仓库中筛选模型。我们首先识别出在开放权重和专有模型家族中均使用 OpenHands 脚手架（scaffold）的提交。随后，我们以 2025 年 7 月 1 日为截止日期，剔除超过一年的旧提交。最后，对于每个符合条件的模型家族，我们选取其基于 OpenHands 的最新提交。该程序在保持智能体脚手架不变并确保所评估提交为近期提交的同时，覆盖了多样化的模型家族。所选模型汇总见表 5。

A.2 开发者补丁与模型补丁之间的删除精确率与召回率

A.3 精确率与召回率的统计检验

A.4 从定位角度探究删除规避行为

A.5 开发者补丁与使用 Guard-and-Go 的模型生成补丁的补丁大小对比

附录 B Guard-and-Go 分类体系的构建

我们分析了主论文“模型用新增控制流替代删除”小节中策略分类器标记为 Guard-and-Go 的每一个任务-模型配对。在每个配对中，模型保留了官方人工补丁删除的代码，并新增了一个守卫，使执行绕过被保留的代码。分类器必须同时引用被保留的代码行和新增的守卫来证明其标签的合理性，我们只保留了两个引用均被成功恢复的配对。这一过程最终保留了 684 个配对用于分析。

开放式编码和主轴编码。

两个模型，MiniMax-M2.7 和 Claude Sonnet 5，在检查了问题陈述、官方人工编写的补丁、模型生成的补丁以及分类器的判定依据后，独立对每个配对进行开放式编码。编码分六轮进行，每轮五个配对，共覆盖 30 个配对。每轮之后，一名主轴编码员（Claude Opus 4.7）将新编码与不断更新的分类体系进行比较，并添加、合并或修订类别。表 10 报告了每轮的结果。第五轮和第六轮没有新增类别，23 个定义全部保持不变，因此我们停止了编码，并将该分类体系视为在 23 个类别处达到饱和。

合并。

23 个类别中有许多在不同语境下描述了相同的行为。例如，有三个类别描述了从保留代码中捕获异常并返回默认值。它们仅在捕获的异常类型数量上有所不同，因此我们将它们合并为一种行为，即“异常捕获绕过”，列于表 12 中。另有五个类别描述了为特殊输入添加分支，且仅在输入类型上有所不同：属性对象、正则表达式或数据库连接。我们将它们合并为一种行为，即“特例切出绕过”。将此规则应用于全部 23 个类别，得到了表 12 中的十种类型：其中六种类型合并了两个或更多类别，而四种保持不变。Claude Opus 4.7 提出了分组方案，作者对其进行了审查，并在标记任何配对之前最终确定了这十个定义。

我们保留了两种相似类型的区分。在“绕过保留分支的上游重路由”中，守卫重定向了有问题的输入，因此保留代码无法再运行。而在“保留路径作为活动回退”中，保留代码仍然会对守卫未捕获的每个输入运行。由于保留代码在第一种情况下是死代码，在第二种情况下是活代码，因此我们将其作为不同类型分别报告。

封闭式编码。

一名最终标注员（MiniMax-M2.7，temperature 0）将固定的十类 Guard-and-Go 类型体系应用于全部 684 个配对。对于每个配对，标注员选择最具体的类型，并引用模型生成补丁中的相应行作为证据。标注员也可以拒绝分配类型。134 个任务-模型配对被标记为“其他”，表示这十种类型未涵盖的行为。因此，主论文的表 2 及随附分析覆盖了获得类型的 550 个配对。

为核验这些标签，一位作者从十种类型中各抽取五个配对，共 50 个配对，并确认所引用的行确实表现出所分配定义描述的行为。该验证评估的是标签是否符合类型体系的结构定义；它不评估每个补丁的正确性、可维护性或意图。我们在第 11 节中提供了每个子类型的定义。

附录 C 面向删除的 F2P 测试构建

我们为选定的 SWE-bench Verified 任务补充了面向删除的（F2P）测试。构建过程首先识别出现有可见测试未覆盖的、具有行为重要性的删除，然后创建一个仓库原生的测试，该测试在删除的代码仍然存在时失败，在执行删除后通过。

C.1 选择具有行为重要性的删除

我们从 69 个任务开始，在这些任务中，删除行占开发者补丁中变更行的至少 25%。我们的分析覆盖了其中 65 个任务。由于删除的行可能包含注释、空行、文档字符串、分隔符以及其他结构上无关紧要的变更，我们并不将每一行删除都视为一个独立的目标。相反，我们分析开发者补丁之前的源版本，并将相关的删除行分组为删除单元。对于 Python 文件，我们利用源代码结构将删除行与其外围的语法元素关联起来。当源代码无法解析时，附近的删除行会被归并为一个单元。

一个删除单元可能代表一个被移除的条件、控制流语句、函数签名、赋值、调用、装饰器，或完整的复合语句，例如 if、for、try、函数或类代码块。只有当导入语句与被其依赖的代码一起被移除时，才被视为有意义的删除。这一过程在 63 个任务中识别出 166 个删除单元；在排除非代码和结构上无关紧要的行之后，其余两个任务不包含有意义的代码删除。

我们使用表 13 中的启发式规则对删除单元进行排序。该评分优先考虑那些改变控制流、移除完整程序结构、与问题陈述中提到的实体相对应、并且从开发者补丁中完全消失的删除。独立的导入移除会获得负分，因为它们通常反映的是由另一次删除引发的清理工作，而非任务所需的主要行为。每个任务中得分最高的单元被选为删除目标。

在补丁级分析中，我们认为当模型删除了某个单元至少一半的行时，即视为其采用了该选定的删除操作。在选定的 63 个单元中，有 24 个被列出的可见测试所覆盖。其余 39 个构成了面向删除的 F2P 构建的候选池。

C.2 回溯改造与验证 F2P 测试

对于 39 个候选中的每一个，我们首先建立一个源码级判定标准（oracle），用以区分基础版本与开发者修补后的版本。选定的删除操作必须存在于基础源码中，并且在应用开发者补丁后，在相应位置不再存在。因此，所得到的谓词在基础版本上会失败，因为目标代码仍然存在；而在黄金版本上会通过，因为预期的删除已经发生。

该测试从当前检出（checkout）中读取目标源文件，并比较规范化后的源码行。它不会导入或执行目标项目的代码。这种设计将结构性编辑与项目初始化、数据库夹具、框架设置以及其他运行时副作用隔离开来。当选定的行从开发者修补后的文件中完全消失时，谓词会检查整个文件中是否不存在这些行。当相同的文本被移动到其他位置、重写或在别处重复时，检查则限定在一个稳定的外层函数或类范围内。如果没有任何稳定的作用域能够区分基础版本和黄金版本，则该候选将被排除。

每个测试都被放置在仓库现有的测试组织结构中。对于 Django 项目，测试以 unittest 模块的形式添加到原始任务所使用的同一个测试应用中。对于 SymPy，测试以与该仓库选择器格式兼容的普通测试函数形式表达。对于其他基于 pytest 的仓库，测试文件被放置在原始任务测试位置的旁边。派生出的 SWE-bench 记录在其 test_patch 中仅包含专注于删除的测试，将生成的选择器列在 下，并将 留空。这样就将评估结果与任务原有的可见测试隔离开来。

我们针对物化的基础版本和黄金版本源码树验证每一个生成的测试。保留要求测试能够被正确收集，在基础版本上以预期的删除断言失败，并在黄金版本上通过。那些报错、跳过、未被收集或无法区分两个版本的测试会被丢弃。我们将满足这些条件的测试称为宿主验证；工具链验证则额外表示在完整的 SWE-bench 评估环境中执行。在 39 个候选测试中，34 个满足宿主验证。其余五个被排除，因为不存在稳定的源码级谓词能够区分基础版本和黄金版本。

附录 D CanItDelete 扩展设计与结果

D.1 候选挖掘与结构排序

仓库群体。

对于 Python 和 JavaScript，我们分别选取星标数最高的 100 个活跃、非 fork 的公共仓库，并遍历其可达的非合并提交历史。2024 年 1 月 1 日之后的活动定义了仓库群体；这些仓库中较早的提交仍然符合条件。

仅删除的文件编辑。

对于每次提交，我们都会重建编辑前后每个被修改文件的内容。我们保留那些不增加行数、编辑前文件大小不超过 100 KB、修订版本可恢复且可解码、且编辑后文件非空的 Python、JavaScript、JSX 和 JavaScript 模块编辑。我们排除二进制变更和文件删除，但保留测试文件。选择是在文件级别进行的，因此提交中的其他文件可能包含新增或修改。这产生了 79,074 个符合条件的编辑，每个编辑都以从 Git 获取的编辑后文件作为参考。

结构性挑战指数。

由于 CanItDelete 是一个诊断性压力测试，而非具有代表性的 GitHub 样本，我们根据三个既定的变更复杂性维度对候选任务进行排序：编辑前代码规模、变更规模和分散度（Nagappan 和 Ball 2005；Hassan 2009；Kamei 等人 2013；Moser 等人 2008）。我们使用这些维度，但不使用缺陷预测系数，因为缺陷风险与编辑难度是两种不同的概念。

设 为编辑前非空行数， 为参考编辑删除的非空源行数， 为在带有三行上下文的统一 diff 中删除块的数量。去除重复的仓库–提交–文件标识后，剩余候选任务数为 。对于 ，我们计算右连续经验百分位数LCHN=74,485k∈{L,C,H}

以及等权重的结构性挑战指数

百分位数避免了分布假设和人工选择的饱和阈值。等权重避免了在文件阅读、删除量和多点协调之间强加一个没有依据的换算比率。因此， 衡量的是结构性挑战；它并非经过校准的失败概率。dV2

最终任务选择。

我们保留每个仓库–提交对中得分最高的文件，防止一个逻辑变更占据多个位置，并在不使用模型性能的情况下选择前 200 个编辑。该基准涵盖来自 35 个仓库的 200 次提交：151 个 Python 任务和 49 个 JavaScript 系列任务，其中包括 53 个测试文件。每个任务至少包含三个分离的删除块。

图 6 汇总了该基准测试的结果。中位数（四分位距）分别为：编辑前代码行数 1,551（1,266–1,800）行，删除行数 34（29–39）行，删除块数 4（3–5）个，指令词数 8（6–10）个。

D.2 指令生成与任务验证

结构筛选完成后，GPT-5.6 Sol 接收编辑前文件、参考差异、文件路径和提交信息作为弱上下文。它会生成一条简短的、现在时态的请求，涵盖完整的删除操作，不包含新增内容、虚构动机，也不提及补丁或差异。机械检查会拒绝格式错误的请求、超出删除范围的请求、包含禁用措辞的请求以及涉及补丁导向术语的请求。复现包中提供了完整的提示词。

每个任务都要通过大语言模型门控和作者门控。仅凭指令和编辑前文件，大语言模型求解器视角会检查任务是否非平凡、是否有据可依，以及所有编辑位置是否可定位。凭借完整的前后记录，其评估器视角会检查忠实度、多位置一致性、参考正确性、范围以及跨领域连贯性。随后，作者会验证请求是否覆盖了 Git 中的每一项实质性删除而未扩大任务范围，并且所有位置和边界在缺少隐藏差异、编辑后文件、仓库上下文或测试的情况下仍可恢复。类似清单式的请求会被缩短并重新验证。这种将 Git 来源、生成的描述和确定性评估相分离的做法，遵循了近期基于仓库构建的基准测试方法（Ni 等，2026；Ouyang 等，2026；Zhu 等，2024；Li 等，2024）。

D.3 诊断模式

这四种模式是累积式的：每种模式都保留先前模式的指导信息，并额外增加一个受控信号。各阶段之间的差异用于识别缺失的信息；在提供意图、区域和边界之后，精确行上的失败则用于隔离执行和范围控制方面的问题。

D.4 删除合规性评估器

没有 LLM 法官来评估输出。当完整目标不存在、剩余可执行结构与参考一致、且未引入影响行为的指令或无关代码更改时，输出即为删除合规。格式、空白和普通解释性注释可接受；注释掉或禁用目标则不可接受。类型检查、lint 和覆盖率指令在可能影响行为时计入考量。精确参考匹配始终被接受，包括针对不支持的源方言。

评估器从编辑前到参考的差异中推导出针对具体出现位置的单元。源代码坐标、hunk 成员资格和锚点防止重复行的一次出现为另一次出现获得信用。决策结合 hunk 锚定对齐、Python AST 或 JavaScript 解析器结构、token 和方言回退，以及针对保留在注释、字面量 false 分支、提前返回包装器或类似非执行形式中的目标的原始源码检查。

失败按必需代码是否保留进行划分。不完整删除涵盖部分移除、目标代码保留时的新增、缺失与过度删除混合、错误位置或错误边界删除、无更改、禁用或注释掉的目标，以及保留目标的语法无效输出。完整删除但编辑无效涵盖过度删除、改变范围的编辑，以及目标移除后语法无效的输出。该划分将不完整移除与未能保留其边界区分开来。

D.5 完整诊断阶梯结果

GLM-5.2、GPT-5.6 Sol、MiniMax-M3 和 Qwen3-235B 在每种模式下都使用了全部 200 个任务。由于提供商故障，Claude Opus 4.8 仅有 173 个任务在全部四种模式下获得了可用响应，因此其轨迹使用该配对子集。因此，每个模型内部的比较都保持其任务集固定；只有 Opus 面板的任务数少于常规分析。表 16 报告了完整的结果划分。

与常规模式相比，显式删除仅使成功率改变了几个百分点。区域指针使成功率改变了 0.0–7.0 个百分点，其中 GLM-5.2 的提升最大。只有精确行模式对所有五个模型都有提升，幅度为 6.5–31.5 个百分点。随后，四个模型的删除不完整率降至 0.6–3.0%，而 Qwen3-235B 在 17.5% 的任务中仍保留了目标代码。−2.5+2.5

其余失败暴露了另一个独立的边界控制缺陷。Claude Opus 4.8 以 1.7% 的完全删除无效编辑收尾，但 GPT-5.6 Sol 仍高达 16.5%。对于 Qwen3-235B，随着不完整删除的减少，这一比率从 20.5% 上升至 26.0%。因此，精确定位可以用删除目标但改动过多的编辑来替代遗漏的删除。这个阶梯将“找到每个目标出现位置”与“在其边界处停止”区分开来。

附录 E 面向删除的训练数据筛选

E.1 文件级示例。

与保留结构上最难编辑的 CanItDelete 不同，我们跨仓库、跨语言、跨删除难度进行采样。给定一条指令和完整的编辑前文件，DeepSeek-V3.2 生成完整的编辑后文件。我们使用第 4.1 节中的标准应用确定性拒绝采样，得到 10,000 条被接受的响应，其所需删除均限定在单个文件内。

E.2 仓库级示例。

我们保留非根、非合并提交，其 Python 变更仅包含删除操作、涉及至少两个文件、且变更行数在 3–1,500 行之间。对于每个提交，我们生成一条指令和一个 F2P 测试，该测试在参考编辑之前失败、之后通过，并以 Harbor 格式打包任务（Merrill 等人，2026）。我们使用以 MiniMax-M2.7 为教师的 mini-SWE-agent，并基于生成的 F2P 测试应用拒绝采样，获得 2,821 个训练样本。