技术摘要：增是机器，删是人类

问题陈述

虽然大型语言模型（LLMs）正日益成为能够解决问题并生成拉取请求（PR）的编程智能体，但有证据表明，它们的补丁往往会降低代码的可维护性。本研究识别出一种特定的、系统性的失效模式：删除规避（deletion avoidance），即模型倾向于保留原本需要删除的代码。模型并非执行减法编辑，而是通过添加条件保护或回退机制来绕过过时的逻辑，从而保留这些逻辑。这种被称为 “守卫并跳过”（Guard-and-Go） 的行为，使得补丁能够通过现有的测试套件（这些测试很少验证代码的移除情况），却导致代码库变得臃肿且难以维护。本文指出，当前的评估基准（如 SWE-bench Verified）可能高估了模型的生产就绪度，因为它们未能对这种非移除策略进行惩罚。

研究方法

本研究采用了一种多维方法，结合了对现有基准的实证分析、专门诊断基准的创建以及受控的后训练干预。

1. 对 SWE-bench Verified 的实证分析

作者使用一致的 OpenHands 框架来控制智能体差异，分析了 SWE-bench Verified 排行榜上的五个领先提交（GLM-4.6, GPT-5, Kimi-K2, Opus-4.5, 和 Salesforce SAGE）。

• 指标： 通过将模型补丁与开发者补丁进行对比，计算删除召回率（deletion recall），衡量开发者删除的行数中模型也成功删除的部分。
• 定位检查： 研究通过检查文件、作用域（函数/类/模块）和精确行修改，区分了是找不到代码（定位错误）还是未能删除代码（执行错误）。
• 策略分类： 使用基于 LLM 的分类器将通过的补丁分为：“删除并替换”（Delete-and-Replace）、“守卫并跳过”（Guard-and-Go，保留逻辑并添加保护）或“非引用替代方案”（Non-reference alternative）。

2. 删除敏感型重构（Deletion-Sensitive Retrofitting）

为了确定通过测试是否真正验证了代码的移除，作者为 SWE-bench Verified 中的 34 个具有高度删除特征的任务重新配置了新的 FAIL_TO_PASS (F2P) 测试。这些测试明确规定：如果目标代码仍存在于文件中，则测试失败，从而将移除需求从其他行为规范中隔离出来。

3. CanItDelete 基准测试

为了将删除行为与定位难度或增加代码的需求等干扰因素分离，作者策划了 CanItDelete。

• 构建： 从真实的提交中挖掘了 200 个任务，在这些任务中，整个 所需的编辑均为删除操作（无新增内容）。任务选自按结构复杂度（编辑前大小、删除行数和删除块）排序的前 100 个热门 Python 和 JavaScript 仓库。
• 评估： 一个确定性的、感知出现的评估器根据目标是否完全消失、无关结构是否被保留以及是否引入了影响行为的增加内容来对输出进行评分。
• 诊断阶梯： 该基准利用四个累积模式来诊断失效点：
  1. 基础版（Vanilla）： 标准的开发者风格请求。
  2. 显式删除（Explicit Deletion）： 指令禁止使用守卫或回退。
  3. 区域指针（Region Pointer）： 识别相关的函数或区域。
  4. 精确行（Exact Lines）： 提供要删除的精确跨度。

4. 后训练干预（概念验证）

一个 7B 参数的模型通过增加以删除为核心的后训练混合数据进行了增强。

• 数据： 在训练集中增加了 12,821 个删除示例（10,000 个文件级和 2,821 个仓库级）。这些示例贡献了 112.1M token 到 15.9B-token 的混合数据中，约占总 token 数的 0.7%。
• 评估： 在 CanItDelete、SWE-bench Verified、CanItEdit 和 EditBench 上测试该模型，以衡量针对性的改进及潜在的回归。

关键结果

1. 删除规避的普遍性

• 低召回率： 即使在五个模型都解决的 197 个任务中，删除召回率也仅在 65.2% 到 71.7% 之间。模型保留了 28.3% 到 34.8% 应被删除的内容。
• 定位 vs 执行： 模型成功定位了 >92% 的删除文件和 ~70% 的包围作用域，但在仅 44.6% 到 51.6% 的案例中删除了精确的行。这一差距主要是执行失败，而非定位失败。
• “守卫并跳过”的主导地位： 在分析的 1,703 个通过任务-模型对中，有 494 个（29.0%）遵循了“守卫并跳过”模式，即模型保留了开发者已删除的逻辑并添加了一个条件绕过。这些补丁的平均体积比开发者的补丁大 61.1%。

2. 评估差距

当使用删除敏感型检查重新评估 34 个删除密集型任务时：

• 四个前沿模型的解决率从 63.2% 下降到 41.9%（下降了 21.3 个百分点）。
• 33.7% 的通过原测试套件的补丁仍然保留了经验证的删除目标。

3. CanItDelete 研究发现

• 性能差异： 在 200 个仅限删除的任务中，成功率从 Claude Opus 4.8 的 79.0% 到较小开源模型的 18.0% 不等。
• 失效模式： 在所有模型中，不完全删除（保留了所需代码）占失败原因的 69.8%。然而，随着模型定位目标的能力提升，出现了第二种失效模式：过度删除（over-deletion）（删除了目标边界之外的代码）。
• 引导的影响： 提供精确删除跨度（“精确行”模式）使五个模型中的四个几乎消除了不完全删除的问题，但并未解决过度删除问题。例如，GPT-5.6 Sol 的成功率上升到了 80.5%，但它仍因删除了指定跨度之外的内容而导致 16.5% 的任务失败。这表明问题在于对删除边界的控制能力缺失，而非寻找代码的能力缺失。

4. 后训练干预

在 7B 模型的后训练混合数据中加入删除监督后：

• 在 CanItDelete 上减少了 13.9 个百分点的未完成删除（失败率从 80.4% 降至 66.5%）。
• 在 SWE-bench Verified 上提升了 5.3 点，在 CanItEdit 上提升了 1.4 点。
• 未在其他基准测试中引入显著的回归。
• 权衡： 该干预增加了过度删除（带有无效编辑的完整删除）的比例，这表明虽然模型学会了如何删除，但仍难以处理在哪里停止。

重要性与主张

论文声称，删除规避是当前 LLM 中一种系统性的、训练不足的行为，而非本质的局限性。作者认为：

1. 当前基准不足： 标准的测试通过指标掩盖了“守卫并跳过”模式，导致高估了模型在代码维护方面的就绪度。
2. 控制是瓶颈： 模型具备定位待删除代码的能力，但缺乏执行精确、有界移除而不产生过度编辑或添加守卫的控制力。
3. 删除是可学习的： 概念验证干预表明，针对性的后训练可以减少删除规避并提高更广泛的代码编辑性能，这表明缺陷源于数据表示（训练数据中的加法偏差）而非模型架构。

作者对研究范围保持谦逊，指出该干预仅在单个 7B 模型上进行了测试，且“过度删除”的权衡表明，删除完成度和边界控制是两个不同的训练目标，需要进一步研究才能在大规模场景下同时解决。