生成式编译：让编译器在 AI 写代码时实时介入

导语

AI 编程工具越来越擅长生成代码，但在 Rust 这类拥有丰富静态语义的语言中，“能写出来”和“能编译通过”之间仍有明显距离。严格的类型、所有权与生命周期规则带来了更强的安全保证，也让大模型更容易在中途走入死胡同。来自 arXiv 的论文《Generative Compilation: On-the-Fly Compiler Feedback as AI Generates Code》提出一种思路：不要等代码全部生成完再编译，而是在生成过程中就让编译器参与反馈。

核心要点

• 问题背景：传统做法通常是大模型先生成完整代码，再调用编译器报错，随后修复。这种反馈来得较晚，早期错误可能在后续生成中不断放大，导致诊断和修复都更困难。
• 与约束解码的区别：约束解码可以在采样阶段拒绝非法 token，但往往需要白盒模型访问，并且要为复杂语义约束重新实现大量逻辑。论文希望利用现成编译器，而不是重写一个语义检查系统。
• 关键机制 sealor：研究提出名为 sealor 的轻量转换器，主要依据语法信息，把“部分程序”转换成编译器可以处理的“完整程序”。它的设计目标是：如果当前部分程序仍有可能被补全，就不应被错误拒绝；同时尽量保留上下文，让真正无法继续的错误尽早暴露。
• 形式化与落地：作者在一个 Rust-like 核心演算上构造 sealor，并用 Lean 机械化证明其关键性质；同时将该思路扩展为面向真实 Rust 的部分程序检查器。
• 实验结论：在具有挑战性的仓库级 Rust 编码任务上，论文比较了前沿黑盒模型与开源权重模型。结果显示，生成式编译相比生成后反馈，能够减少无法编译的输出，并改善功能正确性。

意义与影响

这项工作的重要性不在于替代编译器，而在于重新安排编译器进入 AI 编程流程的时机。过去，编译器通常是“最后把关者”；在生成式编译中，它更像是一个持续在线的协作者，在代码还未完全成形时就提供局部而聚焦的诊断。

对开发者工具而言，这可能带来更自然的 AI 辅助编程体验：模型不必等整段代码写坏之后再返工，而可以在更接近错误源头的位置调整方向。对 Rust 这类高约束语言而言，这一点尤其有价值，因为很多错误并非单个 token 的语法问题，而是与上下文、类型和语义约束相关。

当然，论文仍处在研究阶段。如何把这种反馈稳定嵌入真实 IDE、代码代理或云端编程系统，如何控制额外编译开销，以及如何适配更多语言，仍需要后续探索。但它明确指出了一个方向：未来的 AI 编程系统不应只把编译器当作事后测试工具，而应让其成为生成过程中的一等公民。

来源：arXiv