返回
原文
HuggingFace Daily Papers（社区热门论文）
精选
73AI 编辑部评分，满分 100

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

2026-07-30 08:00· 5天前
跳到正文
精选理由

这项研究将代码AI补丁的可维护性痛点归结为一种系统性偏差，其基准和训练方法为团队在实际采纳前评估模型提供了更具体的指标。

AI 摘要

研究发现，领先模型在 SWE-bench Verified 上对开发者补丁的删除召回率最高仅 71.7%，29.0% 的通过补丁采用 Guard-and-Go 模式保留目标代码。新基准 CanItDelete 含 200 个纯删除任务，最佳模型仍失败 19.5%。在 7B 模型后训练中加入 12.8k 删除示例（占 0.7% token）可将删除回避降低 13.9 个百分点。

正文 · AI 翻译

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 引言

Refer to caption
图 1：一个已解决 SWE-bench Verified 任务中删除回避的示例。开发者补丁删除了一个语句，而模型将其保留在“else”守卫之下。

前沿大语言模型如今已处于编码智能体的核心位置，这些智能体能在极少监督下解决问题、审查代码并提交拉取请求。它们产出的内容是否达到可合并标准——即维护者愿意将其纳入项目——与它能否运行是两回事。在一个大型 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 直接展示了这一行为：一位开发者移除了一个过时的赋值语句，而面对同一问题的模型却保留了该赋值，并让执行流程有条件地绕过它。两个补丁都通过了相同的测试，也都记录为已解决。我们将此称为“回避删除”，即系统性地倾向于保留本应被预期编辑所移除的代码；我们用这个术语来描述可观察到的补丁行为，而非内部意图。

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

在 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 研究设计

补丁。我们分析了五个模型（GLM-4.6、GPT-5、Kimi-K2、Opus-4.5 和 Salesforce SAGE）各自在基于 OpenHands 的 SWE-bench Verified 排行榜上最新的提交。不同脚手架在调用工具和定位代码的方式上存在差异，而这些差异本身就可能影响编辑行为，与底层模型无关。因此，我们固定脚手架不变，以减少这一来源的变异性。附录 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）。最后，为区分搜索与执行，我们在三个嵌套层级上检查每个参考删除：模型补丁是否修改了对应文件，是否修改了其所在作用域（即包含的函数、类或模块）内的至少一行，以及是否删除了精确的那一行。

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）。无论是在已解决还是失败的任务中，每个模型的删除量都少于开发者。

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）。

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

媒体内容 · 前往原文查看
模型 失败率（） 解决率（）
GLM-4.6 24.0% 67.5% 0.532
GPT-5 29.9% 68.5% 0.485
Kimi-K2 19.8% 65.2% 0.543
Opus-4.5 30.4% 71.7% 0.504
Salesforce SAGE 27.5% 68.0% 0.501
表 1：五个模型全部解决的 197 个任务和全部失败的 57 个任务上的平均删除召回率。表示效应量。
媒体内容 · 前往原文查看
策略 数量 通过率
删除并替换 1,197 50.8% 85.2%
Guard-and-Go 684 29.0% 72.2%
非引用替代方案 477 20.2% 39.6%
表 2：2,358 个经分类器标注的补丁对中的补丁策略分布。占比指整体出现频率；通过率指各策略在 SWE-bench Verified 中的解决率。表 12（附录 B）列出了十种 Guard-and-Go 形式。

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

媒体内容 · 前往原文查看
通过的尝试
模型 任务数
原始
测试套件
加入删除
检查后
下降
（百分点）
GPT-5.6 Sol 34 21（61.8%） 15（44.1%） 17.6
Opus 4.8 34 21（61.8%） 14（41.2%） 20.6
GLM-5.2 34 26（76.5%） 18（52.9%） 23.5
DeepSeek-V4-Pro 34 18（52.9%） 10（29.4%） 23.5
总体 136 86（63.2%） 57（41.9%） 21.3
表 3：每个模型 34 个任务中，通过原始测试套件、且其中通过删除敏感检查的尝试数量。Drop 以百分点（pp）计；每个任务约合 2.9 个百分点。

第 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：一个用于删除回避的诊断基准

Refer to caption
图 2：CanItDelete 基准构建、累积诊断模式以及结构性结果分类的概览。

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

Refer to caption
图 3：12 个模型在普通模式下的成功与失败构成。成功率基于 200 个任务衡量；失败机制则基于每个模型的失败任务进行衡量。

4.1 基准设计

构建过程。

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

评估。

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

Refer to caption
图 4：在越来越精确的删除指引下，诊断阶梯（diagnostic-ladder）的结果表现。四个模型使用 200 个任务；Claude Opus 4.8 使用 173 个。

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

抑制不完整删除后，又暴露出第二种倾向——过度编辑。GPT-5.6 Sol 的无效编辑率在获得精确代码行后几乎不变，从 16.0% 变为 16.5%，而 Qwen3-235B 的无效编辑率则随着其保留率的下降从 20.5% 上升到 26.0%。因此，这个阶梯模型将单一通过率所混淆的两种能力区分开来：即找到所有需要删除的出现位置，并在其边界处停止。总体成功率无法说明模型改进的是哪一方面，也无法说明它是否像 Qwen 那样，用一种失败换取了另一种失败，而模式差异（mode deltas）和机制拆分（mechanism split）则可以做到。当前模型缺乏的是控制力，而非能力。我们在附录 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 训练 6 个 epoch。基线模型在 15.9B token 的纯代码混合数据上进行后训练；干预组在同一混合数据中加入删除子集，其余设置不变，因此两次运行的差异仅在于 0.7% 的训练 token。CanItDelete 用于衡量目标行为。其余三个基准覆盖了该部署模型所服务的代码编辑工作负载：SWE-bench Verified 评估基于真实 issue 报告的仓库级修复（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 个百分点。因此，该干预措施使模型更有可能完成所需的删除操作，但尚未教会模型删除应在何处停止。

媒体内容 · 前往原文查看
CanItDelete 结果 基准成功率
成功 不完整 完整但无效 过度删除 SWE-b. Verified EditBench CanItEdit
基线 6.5 80.4 13.1 10.6 25.40 39.26 44.30
+删除 13.7 66.5 19.8 16.8 30.70 39.07 45.70
+7.2 +6.7 +6.2 +5.30 -0.19 +1.40
表 4：7B 模型在删除增强后训练前后的性能对比。数值为三次运行的平均值（%）；为绝对百分点变化。过度删除是完整但无效编辑的一个子集。

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

所研究的基准中，没有一个下降超过 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) Can it edit? 评估大语言模型遵循代码编辑指令的能力。收录于语言建模会议（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 的 PR 并不会被合并到主分支。注：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 脚手架的所有提交。随后，我们以 2025 年 7 月 1 日为截止日期，剔除超过一年的旧提交。最后，对每个符合条件的模型家族，我们选取其基于 OpenHands 的最新提交。该流程在保持智能体脚手架一致并确保所评估提交为近期提交的同时，覆盖了多样化的模型家族。所选模型汇总见表 5。

媒体内容 · 前往原文查看
模型家族 所选模型 提交目录 提交日期
GLM GLM-4.6 20250930_zai_glm-4.6 2025 年 9 月 30 日
GPT GPT-5 20250807_openhands_gpt5 2025 年 8 月 7 日
Kimi Kimi K2 20250716_openhands_kimi_k2 2025 年 7 月 16 日
Claude Claude Opus 4.5 20251127_openhands_claude-opus-4-5 2025 年 11 月 27 日
SAGE Salesforce SAGE 20251103_SalesforceAIResearch_SAGE_OpenHands 2025 年 11 月 3 日
表 5：从官方 SWE-bench Verified 仓库中选取的模型提交。对每个模型家族，我们保留了使用 OpenHands 脚手架的最新提交。提交日期取自仓库目录名开头的 YYYYMMDD 部分。

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

媒体内容 · 前往原文查看
五个模型均未通过
()
五个模型均通过
()
模型 精确率 召回率 精确率 召回率
GLM-4.6 34.6% 24.0% 70.7% 67.5%
GPT-5 35.6% 29.9% 69.3% 68.5%
Kimi-K2 35.0% 19.8% 70.6% 65.2%
Opus-4.5 47.0% 30.4% 74.3% 71.7%
Salesforce SAGE 36.7% 27.5% 66.2% 68.0%
表 6：每项任务的平均删除精确率与召回率。匹配要求模型生成的补丁与官方人工补丁删除相同的基线提交（base-commit）源码位置。

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

媒体内容 · 前往原文查看

面板 A：描述性统计

全部通过 全部未通过
模型 中位数 四分位距（IQR） 中位数 四分位距（IQR）
Salesforce SAGE 1.00 0.75 0.07 0.50
GLM-4.6 1.00 0.75 0.00 0.33
GPT-5 1.00 0.71 0.00 0.50
Kimi-K2 1.00 0.80 0.00 0.25
Opus-4.5 1.00 0.61 0.17 0.50

面板 B：统计比较

模型
Holm 校正后
Cliff's 效应量
Salesforce SAGE 8,426.50 0.50 大
GLM-4.6 8,599.50 0.53 大
GPT-5 8,338.00 0.49 大
Kimi-K2 8,662.00 0.54 大
Opus-4.5 8,444.50 0.50 大
表 7：各评估模型在全部通过（）与全部失败（）的合格任务上的删除召回率对比。面板 A 报告了中位数和四分位距（IQR）。面板 B 报告了经 Holm 校正的 Mann–Whitney 检验 -值及 Cliff's 效应量。
媒体内容 · 前往原文查看

面板 A：描述性统计

全部通过 全部失败
模型 中位数 IQR 中位数 IQR
Salesforce SAGE 1.000 0.684 0.038 0.929
GLM-4.6 1.000 0.667 0.000 1.000
GPT-5 1.000 0.684 0.000 1.000
Kimi-K2 1.000 0.667 0.000 1.000
Opus-4.5 1.000 0.500 0.400 1.000

面板 B：统计比较

模型
Holm 校正
Cliff's 效应量
Salesforce SAGE 7,707.5 0.373 中等
GLM-4.6 8,014.0 0.427 中等
GPT-5 7,861.0 0.400 中等
Kimi-K2 7,867.5 0.401 中等
Opus-4.5 7,504.0 0.337 中等
表 8：各评估模型在全部通过（）与全部失败（）的合格任务上的删除精确率对比。面板 A 报告了中位数和四分位距（IQR）。面板 B 报告了经 Holm 校正的 Mann–Whitney 检验 -值及 Cliff's 效应量。

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

Refer to caption
图 5：五个模型全部解决的 197 个任务中，所有必需删除操作在文件、作用域和精确行层面的重叠情况

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

媒体内容 · 前往原文查看
表 9：在通过 Guard-and-Go 的配对中，模型生成补丁相对于对应开发者补丁的大小。LOC 以新增行与删除行之和计算。
模型 配对数量
模型
更大
相等
LOC
模型
更小
GLM-4.6 91 89 (97.80%) 0 (0.00%) 2 (2.20%)
GPT-5 120 58 (48.33%) 10 (8.33%) 52 (43.33%)
Kimi-K2 92 75 (81.52%) 3 (3.26%) 14 (15.22%)
Opus-4.5 91 30 (32.97%) 20 (21.98%) 41 (45.05%)
Salesforce SAGE 100 50 (50.00%) 14 (14.00%) 36 (36.00%)
总计 494 302 (61.13%) 47 (9.51%) 145 (29.35%)

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

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

开放式编码和主轴编码。

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

媒体内容 · 前往原文查看
轮次 已编码配对 新增 修订 总计
1 5 12 0 12
2 10 4 0 16
3 15 4 0 20
4 20 3 0 23
5 25 0 0 23
6 30 0 0 23
表 10：每轮主轴编码后不断更新的分类体系中的类别。每轮覆盖五个新的配对。
媒体内容 · 前往原文查看
子类型 定义
保留路径作为实时回退 对报告的情况进行守卫，但将官方补丁删除的逻辑保留为默认路径，允许不匹配的输入继续执行被保留的逻辑。
特例豁免绕过 为某一输入类别添加分支或放宽前置条件，同时保持通用解析机制不变。
缺失元素存在性绕过 检查所需的运行时元素，当该元素不存在时返回默认值，而不是评估被保留的逻辑。
故障点症状补丁 在故障点抑制或补偿症状，同时保持产生问题的控制流不变。
异常捕获绕过 捕获被保留逻辑引发的异常并返回默认值，而不是移除根本原因。
事后输出修正 在存在缺陷的计算已完成之后，修正一个错误的结果。
缺失功能注入 引入新的逻辑或参数来处理所报告的情况，而不是采用官方补丁所进行的重构。
保留分支的上游绕行 将有问题输入从保留分支重定向走，使过时分支成为不可达的遗留逻辑。
并行重复路径保留 保留官方补丁所合并的逻辑，同时引入一条额外的执行路径，该路径也能满足行为要求。
值兼容性垫片 针对特定输入，有条件地恢复遗留常量或解码行为。
表 11：模型生成补丁中识别出的 Guard-and-Go 结构子类型。

合并。

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

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

媒体内容 · 前往原文查看
结构形式 通过率
保留路径作为活动回退 221 40.2% 68.3%
特例切分绕过 95 17.3% 52.6%
缺失元素存在性绕过 60 10.9% 81.7%
失败点症状补丁 51 9.3% 66.7%
异常捕获绕过 43 7.8% 53.5%
缺失功能注入 35 6.4% 74.3%
事后输出修正 20 3.6% 80.0%
绕过保留分支的上游重路由 10 1.8% 90.0%
并行重复路径保留 8 1.5% 87.5%
值兼容性垫片 7 1.3% 71.4%
所有已分类配对 550 100.0% 67.3%
表 12：十种 Guard-and-Go 结构形式的分布。在 684 个 Guard-and-Go 配对中，闭源分类器为 550 个分配了子类型，对其余 134 个弃权。占比基于 550 个已分类配对计算，通过率是 SWE-bench Verified 记录为已解决的配对比例。

封闭式编码。

一名最终标注员（MiniMax-M2.7，温度 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、函数或类代码块）。只有当 import 语句与依赖它们的代码一起被移除时，才被视为有意义的删除。这一过程在 63 个任务中识别出 166 个删除单元；在排除非代码行和结构上无关紧要的行之后，剩余的两个任务不包含有意义的代码删除。

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

媒体内容 · 前往原文查看
表 13：用于对行为上重要的删除单元进行优先级排序的启发式规则。
信号 得分
删除的行未在其他位置重新引入
完整的控制块被移除
保护现有代码的条件被修改或移除
控制流语句被移除
完整的函数或类被移除
装饰器被移除
比较或布尔逻辑被移除
函数或类签名被修改
赋值被移除
函数或方法调用被移除
删除的代码包含问题陈述中的术语
较大的多行删除单元
该导入语句及其依赖代码已被移除
独立的导入语句已被移除

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

媒体内容 · 前往原文查看
表 14：以删除为重点的 F2P 构建过程中的任务数量统计。
筛选阶段 数量
删除比例至少达到 25% 的任务 69
纳入删除单元分析的任务 65
包含有效代码删除的任务 63
不包含有效代码删除的任务 2
识别出的删除单元 166
被列出的可见测试覆盖的目标 24
未被列出的可见测试覆盖的目标 39
经宿主验证的以删除为重点的 F2P 任务 34

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 中删除块的数量。去除重复的仓库–提交–文件组合后，剩余候选任务数为 。对于 ，我们计算右连续经验百分位数

（1）

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

（2）

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

最终任务筛选。

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

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

Refer to caption
图 6：200 个 CanItDelete 任务的结构分布。

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

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

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

D.3 诊断模式

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

媒体内容 · 前往原文查看
表 15：四种累积式的 CanItDelete 诊断模式。
模式 累积信号 诊断问题
基础模式 除开发者风格的请求外无额外信号 模型能否端到端地推断并执行完整的删除操作？
显式删除 要求完整移除，并禁止使用保护性代码、注释、禁用分支、回退方案、替换代码及其他变通做法 失败是否源于没有选择真正意义上的减法式编辑？
区域指针 识别相关函数、方法或区域，而不暴露删除边界 找到所有必需区域是否是主要障碍？
精确行 提供针对具体出现位置的跨度，并要求所有未标记文本必须保留 一旦意图、位置和边界已知，模型能否执行精确删除？

D.4 删除合规性评估器

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

评估器从编辑前到参考的 diff 中推导出针对具体出现位置的单元。源代码坐标、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 报告了完整的结果划分。

媒体内容 · 前往原文查看
表 16：完整的五模型诊断阶梯结果。四个模型每种模式使用 200 个任务；Claude Opus 4.8 使用 173 个。单元格报告计数（百分比）。
模式 成功 删除不完整 删除完整，但编辑无效
GLM-5.2
常规 133 (66.5) 30 (15.0) 37 (18.5)
显式删除 128 (64.0) 36 (18.0) 36 (18.0)
区域指针 147 (73.5) 29 (14.5) 24 (12.0)
精确行 175 (87.5) 6 (3.0) 19 (9.5)
GPT-5.6 Sol
常规 148 (74.0) 20 (10.0) 32 (16.0)
显式删除 144 (72.0) 21 (10.5) 35 (17.5)
区域指针 148 (74.0) 19 (9.5) 33 (16.5)
精确行 161 (80.5) 6 (3.0) 33 (16.5)
MiniMax-M3
常规 134 (67.0) 36 (18.0) 30 (15.0)
显式删除 134 (67.0) 32 (16.0) 34 (17.0)
区域指针 137 (68.5) 33 (16.5) 30 (15.0)
精确行 170 (85.0) 6 (3.0) 24 (12.0)
Claude Opus 4.8
常规 136 (78.6) 25 (14.5) 12 (6.9)
显式删除 138 (79.8) 27 (15.6) 8 (4.6)
区域指针 143 (82.7) 19 (11.0) 11 (6.4)
精确行 169 (97.7) 1 (0.6) 3 (1.7)
Qwen3-235B-A22B
常规 50 (25.0) 109 (54.5) 41 (20.5)
显式删除 55 (27.5) 105 (52.5) 40 (20.0)
区域指针 54 (27.0) 99 (49.5) 47 (23.5)
精确行 113 (56.5) 35 (17.5) 52 (26.0)

相对于常规模式，显式删除仅使成功率改变几个百分点。区域指针使成功率改变 0.0–7.0 个百分点，其中 GLM-5.2 的提升最大。只有精确行模式提升了全部五个模型的性能，提升幅度为 6.5–31.5 个百分点。此时，四个模型的删除不完整率降至 0.6–3.0%，而 Qwen3-235B 在 17.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 个训练样本。

编码论文/研究
阅读原文导出 Markdown
返回
精选73导出 Markdown

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

HuggingFace Daily Papers（社区热门论文）·2026-07-30 08:00·5天前
阅读原文· arxiv.org
精选理由

这项研究将代码AI补丁的可维护性痛点归结为一种系统性偏差，其基准和训练方法为团队在实际采纳前评估模型提供了更具体的指标。

AI 摘要

研究发现，领先模型在 SWE-bench Verified 上对开发者补丁的删除召回率最高仅 71.7%，29.0% 的通过补丁采用 Guard-and-Go 模式保留目标代码。新基准 CanItDelete 含 200 个纯删除任务，最佳模型仍失败 19.5%。在 7B 模型后训练中加入 12.8k 删除示例（占 0.7% token）可将删除回避降低 13.9 个百分点。

正文 · AI 翻译

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 引言

Refer to caption
图 1：一个已解决 SWE-bench Verified 任务中删除回避的示例。开发者补丁删除了一个语句，而模型将其保留在“else”守卫之下。

前沿大语言模型如今已处于编码智能体的核心位置，这些智能体能在极少监督下解决问题、审查代码并提交拉取请求。它们产出的内容是否达到可合并标准——即维护者愿意将其纳入项目——与它能否运行是两回事。在一个大型 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 直接展示了这一行为：一位开发者移除了一个过时的赋值语句，而面对同一问题的模型却保留了该赋值，并让执行流程有条件地绕过它。两个补丁都通过了相同的测试，也都记录为已解决。我们将此称为“回避删除”，即系统性地倾向于保留本应被预期编辑所移除的代码；我们用这个术语来描述可观察到的补丁行为，而非内部意图。

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

在 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 研究设计

补丁。我们分析了五个模型（GLM-4.6、GPT-5、Kimi-K2、Opus-4.5 和 Salesforce SAGE）各自在基于 OpenHands 的 SWE-bench Verified 排行榜上最新的提交。不同脚手架在调用工具和定位代码的方式上存在差异，而这些差异本身就可能影响编辑行为，与底层模型无关。因此，我们固定脚手架不变，以减少这一来源的变异性。附录 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）。最后，为区分搜索与执行，我们在三个嵌套层级上检查每个参考删除：模型补丁是否修改了对应文件，是否修改了其所在作用域（即包含的函数、类或模块）内的至少一行，以及是否删除了精确的那一行。

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）。无论是在已解决还是失败的任务中，每个模型的删除量都少于开发者。

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）。

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

媒体内容 · 前往原文查看
模型 失败率（） 解决率（）
GLM-4.6 24.0% 67.5% 0.532
GPT-5 29.9% 68.5% 0.485
Kimi-K2 19.8% 65.2% 0.543
Opus-4.5 30.4% 71.7% 0.504
Salesforce SAGE 27.5% 68.0% 0.501
表 1：五个模型全部解决的 197 个任务和全部失败的 57 个任务上的平均删除召回率。表示效应量。
媒体内容 · 前往原文查看
策略 数量 通过率
删除并替换 1,197 50.8% 85.2%
Guard-and-Go 684 29.0% 72.2%
非引用替代方案 477 20.2% 39.6%
表 2：2,358 个经分类器标注的补丁对中的补丁策略分布。占比指整体出现频率；通过率指各策略在 SWE-bench Verified 中的解决率。表 12（附录 B）列出了十种 Guard-and-Go 形式。

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

媒体内容 · 前往原文查看
通过的尝试
模型 任务数
原始
测试套件
加入删除
检查后
下降
（百分点）
GPT-5.6 Sol 34 21（61.8%） 15（44.1%） 17.6
Opus 4.8 34 21（61.8%） 14（41.2%） 20.6
GLM-5.2 34 26（76.5%） 18（52.9%） 23.5
DeepSeek-V4-Pro 34 18（52.9%） 10（29.4%） 23.5
总体 136 86（63.2%） 57（41.9%） 21.3
表 3：每个模型 34 个任务中，通过原始测试套件、且其中通过删除敏感检查的尝试数量。Drop 以百分点（pp）计；每个任务约合 2.9 个百分点。

第 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：一个用于删除回避的诊断基准

Refer to caption
图 2：CanItDelete 基准构建、累积诊断模式以及结构性结果分类的概览。

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

Refer to caption
图 3：12 个模型在普通模式下的成功与失败构成。成功率基于 200 个任务衡量；失败机制则基于每个模型的失败任务进行衡量。

4.1 基准设计

构建过程。

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

评估。

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

Refer to caption
图 4：在越来越精确的删除指引下，诊断阶梯（diagnostic-ladder）的结果表现。四个模型使用 200 个任务；Claude Opus 4.8 使用 173 个。

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

抑制不完整删除后，又暴露出第二种倾向——过度编辑。GPT-5.6 Sol 的无效编辑率在获得精确代码行后几乎不变，从 16.0% 变为 16.5%，而 Qwen3-235B 的无效编辑率则随着其保留率的下降从 20.5% 上升到 26.0%。因此，这个阶梯模型将单一通过率所混淆的两种能力区分开来：即找到所有需要删除的出现位置，并在其边界处停止。总体成功率无法说明模型改进的是哪一方面，也无法说明它是否像 Qwen 那样，用一种失败换取了另一种失败，而模式差异（mode deltas）和机制拆分（mechanism split）则可以做到。当前模型缺乏的是控制力，而非能力。我们在附录 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 训练 6 个 epoch。基线模型在 15.9B token 的纯代码混合数据上进行后训练；干预组在同一混合数据中加入删除子集，其余设置不变，因此两次运行的差异仅在于 0.7% 的训练 token。CanItDelete 用于衡量目标行为。其余三个基准覆盖了该部署模型所服务的代码编辑工作负载：SWE-bench Verified 评估基于真实 issue 报告的仓库级修复（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 个百分点。因此，该干预措施使模型更有可能完成所需的删除操作，但尚未教会模型删除应在何处停止。

媒体内容 · 前往原文查看
CanItDelete 结果 基准成功率
成功 不完整 完整但无效 过度删除 SWE-b. Verified EditBench CanItEdit
基线 6.5 80.4 13.1 10.6 25.40 39.26 44.30
+删除 13.7 66.5 19.8 16.8 30.70 39.07 45.70
+7.2 +6.7 +6.2 +5.30 -0.19 +1.40
表 4：7B 模型在删除增强后训练前后的性能对比。数值为三次运行的平均值（%）；为绝对百分点变化。过度删除是完整但无效编辑的一个子集。

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

所研究的基准中，没有一个下降超过 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) Can it edit? 评估大语言模型遵循代码编辑指令的能力。收录于语言建模会议（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 的 PR 并不会被合并到主分支。注：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 脚手架的所有提交。随后，我们以 2025 年 7 月 1 日为截止日期，剔除超过一年的旧提交。最后，对每个符合条件的模型家族，我们选取其基于 OpenHands 的最新提交。该流程在保持智能体脚手架一致并确保所评估提交为近期提交的同时，覆盖了多样化的模型家族。所选模型汇总见表 5。

媒体内容 · 前往原文查看
模型家族 所选模型 提交目录 提交日期
GLM GLM-4.6 20250930_zai_glm-4.6 2025 年 9 月 30 日
GPT GPT-5 20250807_openhands_gpt5 2025 年 8 月 7 日
Kimi Kimi K2 20250716_openhands_kimi_k2 2025 年 7 月 16 日
Claude Claude Opus 4.5 20251127_openhands_claude-opus-4-5 2025 年 11 月 27 日
SAGE Salesforce SAGE 20251103_SalesforceAIResearch_SAGE_OpenHands 2025 年 11 月 3 日
表 5：从官方 SWE-bench Verified 仓库中选取的模型提交。对每个模型家族，我们保留了使用 OpenHands 脚手架的最新提交。提交日期取自仓库目录名开头的 YYYYMMDD 部分。

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

媒体内容 · 前往原文查看
五个模型均未通过
()
五个模型均通过
()
模型 精确率 召回率 精确率 召回率
GLM-4.6 34.6% 24.0% 70.7% 67.5%
GPT-5 35.6% 29.9% 69.3% 68.5%
Kimi-K2 35.0% 19.8% 70.6% 65.2%
Opus-4.5 47.0% 30.4% 74.3% 71.7%
Salesforce SAGE 36.7% 27.5% 66.2% 68.0%
表 6：每项任务的平均删除精确率与召回率。匹配要求模型生成的补丁与官方人工补丁删除相同的基线提交（base-commit）源码位置。

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

媒体内容 · 前往原文查看

面板 A：描述性统计

全部通过 全部未通过
模型 中位数 四分位距（IQR） 中位数 四分位距（IQR）
Salesforce SAGE 1.00 0.75 0.07 0.50
GLM-4.6 1.00 0.75 0.00 0.33
GPT-5 1.00 0.71 0.00 0.50
Kimi-K2 1.00 0.80 0.00 0.25
Opus-4.5 1.00 0.61 0.17 0.50

面板 B：统计比较

模型
Holm 校正后
Cliff's 效应量
Salesforce SAGE 8,426.50 0.50 大
GLM-4.6 8,599.50 0.53 大
GPT-5 8,338.00 0.49 大
Kimi-K2 8,662.00 0.54 大
Opus-4.5 8,444.50 0.50 大
表 7：各评估模型在全部通过（）与全部失败（）的合格任务上的删除召回率对比。面板 A 报告了中位数和四分位距（IQR）。面板 B 报告了经 Holm 校正的 Mann–Whitney 检验 -值及 Cliff's 效应量。
媒体内容 · 前往原文查看

面板 A：描述性统计

全部通过 全部失败
模型 中位数 IQR 中位数 IQR
Salesforce SAGE 1.000 0.684 0.038 0.929
GLM-4.6 1.000 0.667 0.000 1.000
GPT-5 1.000 0.684 0.000 1.000
Kimi-K2 1.000 0.667 0.000 1.000
Opus-4.5 1.000 0.500 0.400 1.000

面板 B：统计比较

模型
Holm 校正
Cliff's 效应量
Salesforce SAGE 7,707.5 0.373 中等
GLM-4.6 8,014.0 0.427 中等
GPT-5 7,861.0 0.400 中等
Kimi-K2 7,867.5 0.401 中等
Opus-4.5 7,504.0 0.337 中等
表 8：各评估模型在全部通过（）与全部失败（）的合格任务上的删除精确率对比。面板 A 报告了中位数和四分位距（IQR）。面板 B 报告了经 Holm 校正的 Mann–Whitney 检验 -值及 Cliff's 效应量。

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

Refer to caption
图 5：五个模型全部解决的 197 个任务中，所有必需删除操作在文件、作用域和精确行层面的重叠情况

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

媒体内容 · 前往原文查看
表 9：在通过 Guard-and-Go 的配对中，模型生成补丁相对于对应开发者补丁的大小。LOC 以新增行与删除行之和计算。
模型 配对数量
模型
更大
相等
LOC
模型
更小
GLM-4.6 91 89 (97.80%) 0 (0.00%) 2 (2.20%)
GPT-5 120 58 (48.33%) 10 (8.33%) 52 (43.33%)
Kimi-K2 92 75 (81.52%) 3 (3.26%) 14 (15.22%)
Opus-4.5 91 30 (32.97%) 20 (21.98%) 41 (45.05%)
Salesforce SAGE 100 50 (50.00%) 14 (14.00%) 36 (36.00%)
总计 494 302 (61.13%) 47 (9.51%) 145 (29.35%)

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

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

开放式编码和主轴编码。

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

媒体内容 · 前往原文查看
轮次 已编码配对 新增 修订 总计
1 5 12 0 12
2 10 4 0 16
3 15 4 0 20
4 20 3 0 23
5 25 0 0 23
6 30 0 0 23
表 10：每轮主轴编码后不断更新的分类体系中的类别。每轮覆盖五个新的配对。
媒体内容 · 前往原文查看
子类型 定义
保留路径作为实时回退 对报告的情况进行守卫，但将官方补丁删除的逻辑保留为默认路径，允许不匹配的输入继续执行被保留的逻辑。
特例豁免绕过 为某一输入类别添加分支或放宽前置条件，同时保持通用解析机制不变。
缺失元素存在性绕过 检查所需的运行时元素，当该元素不存在时返回默认值，而不是评估被保留的逻辑。
故障点症状补丁 在故障点抑制或补偿症状，同时保持产生问题的控制流不变。
异常捕获绕过 捕获被保留逻辑引发的异常并返回默认值，而不是移除根本原因。
事后输出修正 在存在缺陷的计算已完成之后，修正一个错误的结果。
缺失功能注入 引入新的逻辑或参数来处理所报告的情况，而不是采用官方补丁所进行的重构。
保留分支的上游绕行 将有问题输入从保留分支重定向走，使过时分支成为不可达的遗留逻辑。
并行重复路径保留 保留官方补丁所合并的逻辑，同时引入一条额外的执行路径，该路径也能满足行为要求。
值兼容性垫片 针对特定输入，有条件地恢复遗留常量或解码行为。
表 11：模型生成补丁中识别出的 Guard-and-Go 结构子类型。

合并。

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

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

媒体内容 · 前往原文查看
结构形式 通过率
保留路径作为活动回退 221 40.2% 68.3%
特例切分绕过 95 17.3% 52.6%
缺失元素存在性绕过 60 10.9% 81.7%
失败点症状补丁 51 9.3% 66.7%
异常捕获绕过 43 7.8% 53.5%
缺失功能注入 35 6.4% 74.3%
事后输出修正 20 3.6% 80.0%
绕过保留分支的上游重路由 10 1.8% 90.0%
并行重复路径保留 8 1.5% 87.5%
值兼容性垫片 7 1.3% 71.4%
所有已分类配对 550 100.0% 67.3%
表 12：十种 Guard-and-Go 结构形式的分布。在 684 个 Guard-and-Go 配对中，闭源分类器为 550 个分配了子类型，对其余 134 个弃权。占比基于 550 个已分类配对计算，通过率是 SWE-bench Verified 记录为已解决的配对比例。

封闭式编码。

一名最终标注员（MiniMax-M2.7，温度 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、函数或类代码块）。只有当 import 语句与依赖它们的代码一起被移除时，才被视为有意义的删除。这一过程在 63 个任务中识别出 166 个删除单元；在排除非代码行和结构上无关紧要的行之后，剩余的两个任务不包含有意义的代码删除。

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

媒体内容 · 前往原文查看
表 13：用于对行为上重要的删除单元进行优先级排序的启发式规则。
信号 得分
删除的行未在其他位置重新引入
完整的控制块被移除
保护现有代码的条件被修改或移除
控制流语句被移除
完整的函数或类被移除
装饰器被移除
比较或布尔逻辑被移除
函数或类签名被修改
赋值被移除
函数或方法调用被移除
删除的代码包含问题陈述中的术语
较大的多行删除单元
该导入语句及其依赖代码已被移除
独立的导入语句已被移除

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

媒体内容 · 前往原文查看
表 14：以删除为重点的 F2P 构建过程中的任务数量统计。
筛选阶段 数量
删除比例至少达到 25% 的任务 69
纳入删除单元分析的任务 65
包含有效代码删除的任务 63
不包含有效代码删除的任务 2
识别出的删除单元 166
被列出的可见测试覆盖的目标 24
未被列出的可见测试覆盖的目标 39
经宿主验证的以删除为重点的 F2P 任务 34

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 中删除块的数量。去除重复的仓库–提交–文件组合后，剩余候选任务数为 。对于 ，我们计算右连续经验百分位数

（1）

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

（2）

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

最终任务筛选。

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

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

Refer to caption
图 6：200 个 CanItDelete 任务的结构分布。

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

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

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

D.3 诊断模式

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

媒体内容 · 前往原文查看
表 15：四种累积式的 CanItDelete 诊断模式。
模式 累积信号 诊断问题
基础模式 除开发者风格的请求外无额外信号 模型能否端到端地推断并执行完整的删除操作？
显式删除 要求完整移除，并禁止使用保护性代码、注释、禁用分支、回退方案、替换代码及其他变通做法 失败是否源于没有选择真正意义上的减法式编辑？
区域指针 识别相关函数、方法或区域，而不暴露删除边界 找到所有必需区域是否是主要障碍？
精确行 提供针对具体出现位置的跨度，并要求所有未标记文本必须保留 一旦意图、位置和边界已知，模型能否执行精确删除？

D.4 删除合规性评估器

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

评估器从编辑前到参考的 diff 中推导出针对具体出现位置的单元。源代码坐标、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 报告了完整的结果划分。

媒体内容 · 前往原文查看
表 16：完整的五模型诊断阶梯结果。四个模型每种模式使用 200 个任务；Claude Opus 4.8 使用 173 个。单元格报告计数（百分比）。
模式 成功 删除不完整 删除完整，但编辑无效
GLM-5.2
常规 133 (66.5) 30 (15.0) 37 (18.5)
显式删除 128 (64.0) 36 (18.0) 36 (18.0)
区域指针 147 (73.5) 29 (14.5) 24 (12.0)
精确行 175 (87.5) 6 (3.0) 19 (9.5)
GPT-5.6 Sol
常规 148 (74.0) 20 (10.0) 32 (16.0)
显式删除 144 (72.0) 21 (10.5) 35 (17.5)
区域指针 148 (74.0) 19 (9.5) 33 (16.5)
精确行 161 (80.5) 6 (3.0) 33 (16.5)
MiniMax-M3
常规 134 (67.0) 36 (18.0) 30 (15.0)
显式删除 134 (67.0) 32 (16.0) 34 (17.0)
区域指针 137 (68.5) 33 (16.5) 30 (15.0)
精确行 170 (85.0) 6 (3.0) 24 (12.0)
Claude Opus 4.8
常规 136 (78.6) 25 (14.5) 12 (6.9)
显式删除 138 (79.8) 27 (15.6) 8 (4.6)
区域指针 143 (82.7) 19 (11.0) 11 (6.4)
精确行 169 (97.7) 1 (0.6) 3 (1.7)
Qwen3-235B-A22B
常规 50 (25.0) 109 (54.5) 41 (20.5)
显式删除 55 (27.5) 105 (52.5) 40 (20.0)
区域指针 54 (27.0) 99 (49.5) 47 (23.5)
精确行 113 (56.5) 35 (17.5) 52 (26.0)

相对于常规模式，显式删除仅使成功率改变几个百分点。区域指针使成功率改变 0.0–7.0 个百分点，其中 GLM-5.2 的提升最大。只有精确行模式提升了全部五个模型的性能，提升幅度为 6.5–31.5 个百分点。此时，四个模型的删除不完整率降至 0.6–3.0%，而 Qwen3-235B 在 17.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 个训练样本。

编码论文/研究
阅读原文arxiv.org