AI 写代码不只怕写错，还怕“删不干净”

导语

AI 编程助手越来越擅长补全函数、修复报错和生成补丁，但这篇题为《To Add Is Machine, To Delete Is Human》的论文提醒我们：真正可合并的代码不只取决于“能写什么”，也取决于“能删掉什么”。研究者把问题命名为 deletion avoidance，即大模型在应当删除代码时，系统性地保留旧逻辑。

核心要点

• 通过测试不等于补丁干净。 在 SWE-bench Verified 排行榜上的五个领先模型中，即便是所有模型都能解决的任务，对开发者补丁中应删除内容的召回率最高也只有 71.7%。模型通常能定位到正确文件，比例超过 92%，但真正删到准确行的比例低于 52%。
• “Guard-and-Go” 是典型症状。 研究发现，29.0% 的通过补丁并未移除目标代码，而是把旧逻辑包在 guard、fallback 或条件分支里。这样做可能让现有测试通过，却把过时代码继续留在代码库中。
• 测试常常没有检查“代码是否消失”。 作者为 34 个 Verified 删除密集任务补充了会在目标代码仍存在时失败的测试后，四个前沿模型的解决率从 63.2% 降至 41.9%。这说明原测试集容易奖励“绕开问题”，而非真正清理实现。
• CanItDelete 聚焦纯删除。 研究团队从真实提交中整理了 200 个只需要删除、不需要改写或新增逻辑的任务。即使把复杂的新增工作拿掉，最佳模型仍有约五分之一任务失败，小型开放模型表现更弱。
• 给出精确行号也不够。 在提示消融中，只有提供待删精确行才显著减少漏删；但成功率仍受限，因为模型可能删过界，或又额外添加代码。

意义与影响

这项研究的价值在于，它把代码智能体的一个“工程质量”缺陷量化了。对软件工程师而言，删除废弃逻辑、保持边界、避免引入旁路，是重构和修复的一部分；对大模型而言，这仍是训练不足的能力。论文也给出积极信号：加入少量删除导向数据后，不完整删除下降，SWE-bench Verified 表现也有提升。不过过度删除会随之上升，说明未来训练与评测需要同时奖励“删得掉”和“停得住”。

如果 AI 代码代理要从演示工具走向生产协作者，评测标准不能只看测试是否通过，还应检查补丁是否真正移除了应消失的代码、是否减少维护负担。这对基准设计、代码审查自动化和后训练数据构建都有直接启发。

来源：Hugging Face Daily Papers