🤖 machine learning

Generative Compilation: On-the-Fly Compiler Feedback as AI Generates Code

本文引入了“生成式编译”，这是一种利用轻量级“sealor”转换的新颖方法，旨在使标准编译器能够在 AI 代码生成过程中对部分程序提供实时反馈，从而在无需白盒模型访问权限的情况下，减少错误级联并提高像 Rust 这样复杂语言的功能正确性。

原作者： Niels Mündler-Sasahara, Hristo Venev, Dawn Song, Martin Vechev, Jingxuan He

发布于 2026-07-16

📖 1 分钟阅读☕ 轻松阅读

原作者： Niels Mündler-Sasahara, Hristo Venev, Dawn Song, Martin Vechev, Jingxuan He

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

想象一下，你正在教一个非常有天赋但有点冲动的机器人如何写故事。这个机器人是一个大型语言模型（LLM），它非常擅长预测句子中的下一个词，但它并不真正了解语法或逻辑规则。它可能会写出一个听起来很有诗意但违反物理定律的句子，或者在编程世界里，它可能会写出一个看起来很酷但会导致计算机崩溃的程序。为了解决这个问题，我们通常会让机器人完成整个故事，然后把它交给一位严厉的编辑（编译器）来检查规则。如果编辑发现了错误，他会带着红笔把整个故事退回，机器人必须重新开始或尝试修复这一团乱麻。问题在于，当编辑开口说话时，机器人可能已经基于那一个微小的错误又写了五十个句子，从而制造出了一个难以解开的巨大混乱。

这篇论文探讨了一种帮助机器人的新方法：与其等到最后，如果编辑能在机器人写作的过程中实时进行纠错呢？这群计算机科学家将这种方法称为“生成式编译”（Generative Compilation）。他们想出了一个聪明的技巧，让标准的、现成的代码编辑器（编译器）能够在机器人工作时进行实时检查，而无需从头构建一个新的编辑器，也不需要窥探机器人的大脑内部。他们在 Rust 语言上测试了这种方法，这种语言以极其严格的安全机制而闻名，但也因极难编写正确代码而著称。他们的研究结果表明，通过及早发现错误，机器人可以犯更少的错误，编写更好的代码，并更快地完成任务，而且这一切都不需要一个极其昂贵的定制化编辑器。

问题所在：那位“太迟了”的编辑

把编写代码想象成在一位非常严格的建筑师指导下盖房子。在旧的方法中（被称为“生成后反馈”），建造者（AI）在没有任何求助的情况下，一砖一瓦地构建整座房子。一旦屋顶盖好了，建筑师走进来，看到地基裂了，然后说：“推倒重来。”建造者不得不拆掉整座房子，尽管错误发生在第一块砖的时候。这既浪费又令人沮耗。

另一种方法被称为“约束解码”（Constrained Decoding），它试图阻止建造者铺设坏砖。但这要求建造者必须是透明的（像一座玻璃房），以便建筑师能看清建造者的每一个想法，并在其行动前将其制止。但当今大多数优秀的 AI 建造者都是“黑盒”——我们无法看到他们的内心世界，因此无法使用这种方法。此外，为一个像 Rust 这样拥有复杂规则的语言构建一个定制的建筑师，是非常困难且昂贵的。

解决方案：“Seal-or”技巧

作者引入了一种折中方案，称为生成式编译。这里的秘密武器是一个他们称之为 Seal-or（取自单词 "seal" 的谐音）的工具。

想象 AI 正在写一封信，但在句子中间停了下来：“猫坐在……”
一个普通的编译器（严厉的编辑）会看着这个不完整的句子说：“我无法评分；这不是一个完整的句子。”
Seal-or 是一个聪明的翻译器。它会立即填补空白，用“虚拟词”使句子在语法上完整，哪怕只是瞬间的事。它把 “猫坐在……” 变成了 “猫坐在 [魔法占位符] 上。”

现在，严厉的编译器可以查看这个被“密封”（sealed）后的句子。如果语法错误（例如，猫不能坐在魔法占位符上），编译器就会大喊：“嘿，猫不能坐在那个上面！”随后，Seal-or 会将该投诉翻译回给 AI：“你不能把猫放在占位符上；尝试换一个词。”于是，AI 在写下一句之前就立即修正了错误。

Seal-or 的神奇之处在于它设计得非常谨慎。它只会在空白处填充那些可能是正确的词。如果 AI 的部分句子最终可能变成一个完美的句子，Seal-or 会确保编译器不会仅仅因为它不完整就拒绝它。但如果 AI 犯了致命错误（比如在 Rust 中的“所有权/借用”错误，即一个变量同时在两个地方被使用），Seal-or 能确保编译器立即捕捉到它。

他们的发现：及早发现错误

团队在真实的编程任务上测试了这个想法，要求七个不同的 AI 模型编写 Rust 程序。他们对比了三种方法：

AI 单独作业： 仅仅靠猜测。
AI + 生成后反馈： AI 写完整个程序，收到纠正，然后重试。
AI + 生成式编译： Seal-or 在 AI 写作的同时进行检查。

结果令人印象深刻。使用生成式编译时：

更少的崩溃： 无法编译通过的程序数量显著下降。对于某些模型，错误率从超过 60% 降到了个位数。
更好的代码： 运行成功的程序在正确性上也表现更好。
更快的修复： AI 花在生成垃圾代码上的时间减少了。因为 Seal-or 及早捕捉到了错误（通常就在出错后的几行之内），AI 不会浪费时间基于一个错误的思路去写一整章代码。
更精简的投诉： AI 不再是在最后得到一份包含 20 个错误的庞大清单，而是得到了关于特定错误的、小巧且集中的提示，这使得理解哪里出了问题变得更容易。

为什么这很重要

这种方法之所以意义重大，是因为它不需要我们去重建 AI 或编译器。它适用于我们现有的“黑盒”模型，并使用程序员已经信任的标准编译器。它将编译器从一个“最终裁判”转变为了一位“现场教练”。

作者使用一种名为 Lean 的形式化语言在数学上证明了他们的 Seal-or 是安全的：它既不会误导编译器接受错误的代码，也不会错误地拒绝那些本可以被修复的代码。随后，他们为真实的 Rust 语言构建了一个工作版本，并证明了它在实践中是有效的。

简而言之，生成式编译就像是给 AI 提供了一个安全网，在它跌落之前就接住它，而不是等它摔在地上后再告诉它摔倒了。它让 AI 编程变得更安全、更快、更可靠，尤其是在那些对精确度要求极高的语言中。

技术摘要：生成式编译 (Generative Compilation)

问题陈述

大语言模型（LLMs）已成为代码生成的标准工具，但它们生成的代码往往容易出错，尤其是在具有丰富静态语义的语言（如 Rust）中。虽然 Rust 的所有权和借用机制提供了强大的内存安全保证，但这些严格的编译时规则使得生成有效代码变得困难。

现有的解决策略存在显著局限性：

生成后编译器反馈 (Post-Generation Compiler Feedback)： 标准做法是等待完整程序生成后，运行编译器并将诊断信息反馈给模型。这引入了一个“延迟反馈”循环。生成过程早期的错误会产生连锁反应，导致模型在收到任何修正之前，就在无效的假设上浪费大量 Token。此外，整个文件的累积诊断信息可能过于冗长，阻碍模型专注于根源问题。
约束解码 (Constrained Decoding)： 这种方法在 Token 采样过程中进行干预，拒绝那些无法导致有效程序的 Token。虽然这能保证在终止时程序的有效性，但它需要对模型的分布进行白盒访问（排除了前沿的黑盒 API），并且需要对编译器语义分析（例如重新实现 Rust 的借用检查器）进行代价高昂的、特定于语言的重实现。对于表达能力强的语言，这通常是不切实际的。

方法论：生成式编译

作者引入了生成式编译，该框架允许离线编译器在生成过程中检查部分程序（partial programs），在不修改 LLM 采样过程的情况下提供编译器风格的诊断。

核心概念：Sealor

其核心技术手段是 sealor，一个轻量级的、主要由语法引导的变换 $S$ ，它将部分程序（代码的前缀）转换为一个完整的、符合规范的程序，以便标准编译器进行诊断。

机制： Sealor 通过填充缺失的语法结构并插入类型良好的占位符（例如，用于值的 holeval()，用于发散控制流的 holediv()）来封闭部分程序。
反馈循环： 被“密封”（sealed）后的程序被传递给现有的编译器（如 rustc）。如果编译器拒绝该密封程序，产生的诊断信息会被映射回原始部分程序的源码范围（source spans），并反馈给 LLM。LLM 随后根据这些集中的反馈对代码进行修订。
设计目标： Sealor 被设计为满足两个属性：
- 完备性 (Completeness)： 它绝不会拒绝一个能够实现有效完成的部分程序（避免产生令模型困惑的假阳性）。
- 健全性 (Soundness, 选择性)： 它应该拒绝那些确实是死路的程序。虽然对于表达能力强的语义而言，全局健全性是不可判定的，但作者针对特定类别的程序（例如在语句边界处）实现了健全性，以尽早捕获错误。

形式化与实现

轻量级 Rust (Featherweight Rust, FR)： 作者首先在 FR 上形式化了该方法，FR 是一个捕捉了 Rust 所有权和借用机制的紧凑演算。他们定义了一个语法引导的 sealor ( $S_{FR}$ )，并证明了其全局完备性和选择性健全性。整个开发过程（包括证明）均在 Lean 中进行了机械化实现。
真实 Rust (Real Rust)： 该方法被扩展到真实的 Rust ( $S_{RS}$ $S_{R S}$ )。Sealor 处理 Rust 特有的语法、控制流以及未来依赖型错误（例如，稍后才会定义的未解析名称）。
- 占位符： 它使用 holediv() (panic!) 来关闭发散分支而不触发借用检查错误，并使用 holeval() (一个泛型函数调用) 来提供值而不施加特定的类型约束。
- 错误抑制： 为了保持完备性，系统会抑制仅由不完整代码引起、但会被后续生成解决的特定编译器错误（例如“缺失 trait 项”）。
- 投影 (Projection)： 来自密封程序的诊断信息被投影回原始部分程序的源码范围，以确保 LLM 接收到相关的反馈。

该系统作为 LLM 的并发模块运行，向 sealor/编译器流式传输部分代码，并在拒绝时重启生成，仅通过纯文本进行通信，以支持黑盒模型。

核心贡献

生成式编译框架： 一种全新的框架，使标准编译器能够在生成过程中检查部分程序，弥合了生成后反馈与约束解码之间的鸿沟。
Sealor 理论： 定义了 sealors，并证明了其完备性和健全性属性可以提升到诱导的生成式编译器上。
机械化 FR 实现： 在 Lean 中对用于 Featherweight Rust 的语法引导 sealor 进行了完全机械化的实现，并对原始 FR 形式化进行了修正。
首个 Rust 部分程序检查器： 一个针对真实 Rust 的实用实现，它在处理语法、控制流和占位符的同时，将语义推理委托给 rustc。
实证评估： 在仓库级 Rust 任务（C-to-Rust 转换和 API 适配）上，对七种前沿黑盒和开源权重模型进行了广泛评估。

结果

评估表明，生成式编译 (GC) 的表现优于标准的生成后编译器反馈 (PC) 和原始 LLM 生成：

减少编译器错误： GC 显著降低了无法编译输出的比例。例如，在 UpdatedAPI 任务中，GC 将 Claude Opus 4.8 的编译器错误率降至 0.0%（相比之下，PC 为 6.7%），并将 GPT-5 的错误率降至 3.3%（相比之下，PC 为 13.3%）。
提高功能正确性： 在 14 个模型-数据集配置中，GC 在 11 个配置中取得了最高的功能正确性。
早期错误检测： GC 能在更接近错误源头的地方检测到错误。报告错误的中间延迟仅为错误主要范围后的 3 行，而函数级检查为 14 行，生成后反馈则为 89 行。
集中的诊断： 通过在第一个不可恢复的错误处中断生成，GC 产生了更小、更具针对性的错误报告（平均 5.5 个诊断，而 PC 为 13.8 个），从而防止了错误级联。
运行时效率： 尽管存在即时检查的开销，但 GC 通过避免生成长篇且无法编译的文件，减少了需要多次反馈轮次的模型的总运行时间。

重要性与主张

论文声称，生成式编译代表了使编译器成为 AI 辅助编程中“一等公民”的一步，使其在生成过程中保持活跃，而非仅仅作为事后的独立检查。

实用性： 与约束解码不同，它适用于黑盒模型并复用了现有的编译器基础设施，避免了大规模语义重实现的需要。
有效性： 它提供了早期、集中的反馈，防止了错误的“雪崩效应”，从而产生更高质量的代码并实现更快收敛。
通用性： 该概念适用于任何可以通过自然语言提示引导的代码生成方法，不仅限于 LLM。

作者对错误信息的形式化保持了谦逊，指出虽然他们在经验上抑制了 sealing 产物，但形式化证明诊断信息对应于原始部分程序中真实缺陷的工作仍是未来的研究方向。他们也承认，自动从语言规范构建 sealor 是未来研究的一个开放方向。