🤖 AI

The Order Is the Guarantee: Verifier-Budgeted Code Deletion with Static-First Learned Proposals

本文介绍了 DELSCOUT，这是一个将代码删除候选对象的排序优先级置于模型置信度之上的框架，旨在有限的验证预算下安全地移除冗余代码，并证明了静态提案与学习型提案的混合调度方案能在通过执行权限确保行为一致性的同时，实现经验证删除量的最大化。

原作者： Ruitong Li, Binjie Guo, Aisheng Mo, Guowei Su, Han Wang, Jie Li, Ru Zhang

发布于 2026-08-06

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Ruitong Li, Binjie Guo, Aisheng Mo, Guowei Su, Han Wang, Jie Li, Ru Zhang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

背景：当 AI 写得太多时

想象一下，你正在用乐高积木搭建一座宏伟而复杂的城堡。在过去，你必须亲手放置每一块积木，这既缓慢又费力。现在，想象有一个超级快速的机器人，可以在几秒钟内拼装好整座塔楼。这就是现代 AI 编程模型所做的：它们能以惊人的速度编写可运行的计算机程序，其解决问题的能力往往能媲美甚至超越人类专家。

但问题在于：仅仅因为机器人能快速建造城堡，并不意味着这座城堡是整洁的。如果你要求机器人“修复这面墙”或“增加一扇新门”，它往往只是在旧积木之上堆叠新的积木，而没有把破碎或无用的部分移除。久而久之，你的城堡会变成一个由多余的门、重复的墙和没人需要的隐藏陷阱组成的臃肿废墟。在软件领域，这被称为“技术债”。它会让代码变得难以阅读、难以修复且难以信任。

这篇论文探讨的核心问题是：我们如何教会 AI 成为一名优秀的编辑，而不不仅仅是一名优秀的建筑师？ 我们知道如何要求 AI 编写代码，但要求它“删除”代码却非常危险。如果 AI 删错了部分，整个城堡可能会坍塌。挑战在于，如何让 AI 能够提出删除建议，同时拥有一套严格的安全系统，只有在百分之百确定城堡依然稳固的情况下才允许执行删除。

论文：代码删除的“运算顺序”

开发出 DelScout 系统的研究人员意识到，实现安全代码删除的关键不在于 AI 有多“聪明”，而在于 AI 检查其想法的顺序。

这就像博物馆里的保安，在有限的时间内检查画作是否造假。保安有一份待检查的画作清单。如果他们先检查最像伪造品的画作，可能会很快抓到造假者。但如果他们先检查一幅显而易见的真迹，可能会在还没来得及检查可疑画作之前就用尽了时间。论文指出，对于删除代码而言，调度（检查顺序）比 AI 的置信度得分更为重要。

两种策略：“混合模式”与“安全网”

团队测试了两种不同的组织 AI 建议的方式，使用的是一个拥有五次检查次数的“预算”（就像拥有五张检查画作的门票）。

“验证混合模式”（智能替换）：
如果团队拥有特定项目的相关数据，他们会使用混合策略。他们保留前三次检查用于“稳妥选择”——即一些简单的、显而易见的事情，比如移除未使用的导入或基础程序可以证明是无用的短行代码。然后，他们将剩余的两个名额用于 AI 的“学习型”建议。这些建议是 AI 对复杂、棘手代码的最佳猜测，而基础检查器无法理解这类代码。
- 结果： 在针对标准编程基准测试 MBPP 的测试中，这种混合方式比仅使用基础安全检查成功地多删除了 9.5% 的代码。他们平均多实现了 6.7 次 成功的删除，且无需运行额外的安全检查。
“前缀保留增强”（安全网）：
如果 AI 正在处理一个完全陌生的项目类型，且没有可信的历史数据怎么办？研究人员意识到，将“稳妥选择”替换为 AI 猜测是有风险的。如果 AI 猜错了，它可能会错过基础检查器本能发现的删除项。
因此，他们设计了一个“安全网”规则：绝不跳过稳妥选择。 他们强制系统先检查所有五个“安全”建议。只有当这五个建议全部失败时，系统才可以使用额外的名额去尝试 AI 的高级猜测。
- 保证： 这确保了系统的删除量永远不会少于基础方法所能达到的水平。它可能会发现更多删除项，但绝不会漏掉基础方法能捕捉到的任何一项。
- 代价： 缺点是这个安全网有时会增加时间成本。根据测试的不同，它需要多出 4.8% 到 62.5% 的安全检查（验证器调用），因为系统必须在尝试 AI 的想法之前先跑完整个安全建议列表。

论文排除了哪些可能性

作者非常谨慎地展示了哪些做法是无效的。他们证明了你不能仅仅依靠 AI 的“置信度得分”来决定删除什么。即使 AI 说“我 99% 确定这一行是无用的”，如果测试环境发生变化，它仍可能出错。

他们还表明，仅仅通过训练让 AI 变得更“擅长”删除代码并不能解决问题。如果他们在没有安全网的情况下，直接用“AI 检查”替换“安全检查”，那么在面对陌生代码时，系统的表现反而会变差。论文明确拒绝了“单纯靠更聪明的 AI 模型就能解决问题”的观点；真正的解决方案是 AI 与安全检查之间协作的结构。

核心结论

论文总结道，AI 编程的未来不仅仅在于编写更多代码，更在于保持代码的整洁。最佳方法是分工协作：

AI 扮演创意探索者的角色，提出人类可能忽略的、具有复杂上下文关系的删除建议。
顺序扮演交通警察的角色，确保 AI 不会阻碍那些枯燥但可靠的安全检查。
测试扮演最终法官的角色，只有在代码实际运行且不崩溃的情况下，才允许执行删除。

在实验中，这种方法成功地移除了冗余代码，同时保证了软件的安全。然而，作者警告说，这是一种维护工具，而非万能灵药。如果测试本身很薄弱，或者代码正在执行某些未被测试到的关键功能（如安全检查），那么 AI 就不应该进行删除。目标是帮助软件保持精简和易读，确保随着 AI 编写更多内容，我们的数字城堡不会变成由大量无用积木构成的无法管理的丛林。

技术摘要：顺序即保证：基于“静态优先”学习提议的验证器预算化代码删除

1. 问题定义

本文探讨了 AI 编程中的“逆问题”：与其生成新代码，AI 系统应如何删除冗余代码，尤其是在执行验证能力有限的情况下？虽然前沿模型生成的代码可以通过基准测试，但“氛围编程”（vibe coding，即迭代式提示与修补）往往会导致冗余的分支、守卫语句（guards）和回退逻辑（fallbacks）积累速度快于过时逻辑被移除的速度。这会产生技术债，从而掩盖不变性并扩大代码审查面。

作者将冗余代码减少建模为一个在有限预算下的**提议调度（proposal scheduling）**问题。

输入： 一个程序 $x$ 以及一组语法有效的单语句 AST 删除候选集 $C(x)$ 。
约束： 一个确定性验证器 $V$ （一个执行套件）只能评估有限数量的候选者（预算为 $m$ ）。
目标： 对候选者进行排序，使得第一个通过 $V(x \setminus c_j)$ 的候选者 $c_j$ 被提交，从而最大化接受的删除数量（覆盖率）和删除的代码量（字符缩减量）。
核心洞察： **顺序（order）**是部署时可以推理控制的控制面，而非模型的置信度分数。错误的删除会悄无声息地移除必要的行为；因此，执行套件必须保留否决权。

2. 方法论：DelScout

DelScout 系统将搜索（提出候选者）与接受（验证候选者）分离。它采用了两种异构的排序器：

静态排序（Static Orders）： 确定性的、无参数的策略。
- 最短优先（Shortest-first）： 按跨度长度、字符长度及位置进行排序。对于语法残余（如未使用的导入、赋值语句）非常有效。
- 零引用（Zero-reference）： 倾向于选择标识符在文件中出现频率最低的语句。
学习排序器（Learned Ranker）： 一个序列分类器，根据验证器的结果来预测删除是否安全。它使用包含候选节点类型、文本和上下文行的提示词。其训练目标是列表排序（listwise），旨在优化位于列表前端的已验证删除项的概率质量，而非独立的分类。

调度策略

论文提出了两种不同的调度方案，用于管理静态保证与学习搜索之间的权衡，具体取决于目标领域验证数据的可用性：

验证混合模式（当存在目标验证时）：
- 分配固定预算（例如 5 个槽位）。
- 将前 3 个槽位用于确定性的静态核心（ $S_3$ ）。
- 将剩余 2 个槽位用于不在静态核心中的高排名学习候选者。
- 原理： 通过经验验证授权，可以用静态槽位交换学习槽位，以提高覆盖率。
前缀保持增强模式（当不存在目标验证时）：
- 首先评估完整的静态排序（例如所有 5 个静态槽位）。
- 仅当所有静态候选者均失败时，才追加学习候选者。
- 原理： 这确保了学习排序永远不会取代静态成功的案例。通过构造方式，它提供了非递减的覆盖率保证，无论是否存在分布偏移，尽管这可能会增加验证器成本。

3. 核心贡献

问题建模： 将冗余代码减少定义为有限执行验证预算下的提议调度，清晰地分离了学习搜索与接受边界。
调度策略： 引入了目标验证的静态-学习混合策略和前缀保持增强策略。后者通过候选者排序本身，在无需校准模型分数的情况下，保证了非递减的覆盖率。
经验验证： 在 MBPP 上进行了涵盖不同模型规模（0.5B, 0.6B, 8B）的九次重复实验。研究包含了客观对照实验，以排除特权训练损失、预算统计、跨基准测试偏移分析，以及针对更强验证器（MBPP+, HumanEval+）的测试。

4. 结果

固定预算增益： 在 MBPP 的九次运行中，相比于静态基准，验证混合模式将已验证删除的覆盖率相对提升了 9.5%（平均增加了 6.7 个接受的任务），同时消耗的验证器调用次数略少。
互补性： 这种增益是架构性的，而非源于特定的训练目标。静态提议覆盖了“简单”的语法候选者（如未使用的导入），而学习提议贡献了不同的维度，专注于上下文控制流候选者（如条件语句、表达式），这些是静态分析无法认证的。
效率： 每千次验证器调用的已验证删除次数增加了 19.5%（从 43.9 增加到 52.5），因为成功的提议通常出现在混合调度中较早的位置，从而提前终止了搜索。
分布偏移： 仅靠学习的排序在发生偏移时是不可靠的（例如，在 MBPP 上训练的模型在 DS-1000 和 BigCodeBench-Hard 上性能显著下降）。然而，前缀保持增强恢复了在这些偏移基准上的非递减覆盖率，尽管这带来了可量化的验证器调用开销（范围从 4.8% 到 62.5%）。
更强的验证器： 当针对更严格的域内规范（MBPP+）进行测试时，混合模式的优势消失了；所有策略都收敛到了相同的低覆盖率（6.47%）。这表明调度控制的是搜索，而测试套件本身才决定了什么是“保持行为”。

5. 意义与主张

论文认为，AI 编程的下一个前沿不仅是生成可运行的程序，而且是维护易于理解且极简的软件。

可审计的分工： 该系统建立了一个清晰的分离：模型扩大了可删除代码的搜索范围，顺序限制了错误排序提议可能造成的破坏，而执行则对每一次提交的删除保留最终权威。
顺序即保证： 核心主张是，候选者的顺序而非模型的置信度，才是可控变量。通过保留静态前缀，系统保证了学习模型可以在不减损既定安全性的前提下增加价值。
局限性： 作者明确指出，该方法依赖于基准程序，而非现实世界的维护历史；此外，绝对覆盖率的增益较为温和（在 MBPP 上从 ~14% 移动到 ~15%）。他们强调，“已验证”仅指通过所述 Oracle（预言机）的验证；该系统并不提供语义证明，不应取代人工审查或安全性检查。

总之，DelScout 证明了，一种纪律严明的调度策略——即在验证器预算下，结合确定性静态分析与上下文敏感的学习提议——可以有效地减少 AI 生成代码中的技术债，同时维持严格的安全保证。