用LLM写代码，看起来很对，但一跑就报错。 苏黎世联邦理工、加州大学伯克利分校等团队，让LLM生成可运行代码，通过率提高了50%！ 他们做的事很简单——在原有的“预测下一个token”机制外，加了一层“类型守门员”。 也就是在生成代码的过程中，实时检查它的类型是否正确，从源头上避免生成出的代码无法编译问题。 具体来说，他们有3大创新： 1、前缀自动机（Prefix Automaton）：它能动态记录代码上下文中的类型状态，比如一个变量是啥类型、函数期望返回啥类型等。比起传统语法检查，它更像一个“实时类型分析器”。 2、类型约束解码（Type-Constrained Decoding）：每当模型要生成一个新 token，先用一个前缀自动机看这个token合不合类型规则，不符合就直接砍掉这个路径，换一个。 3、类型可达性算法：用来判断“当前这段半成品代码，有没有可能写成目标类型的表达式”，从而避免模型进入“写不下去”的死胡同。 为验证方法的可行性，团队选择了TypeScript做实验，一方面是因为它的类型系统足够有代表性，另一方面也有大量真实项目可以参考。 模型在两个经典数据集（HumanEval 和 MBPP）上测试，结果很亮眼： - 编译失败率减少超过50%； - 功能正确率提升3.5%~5.5%； - 在修bug任务上，准确率提升37%。 更重要的是，这种方式对模型体积几乎没有要求，无论是LLaMA家族还是其他开源 LLM，只要支持token-level解码逻辑，就可以集成。 此外，论文还强调这套机制不仅限于代码生成，还可用在代码翻译（比如把 Python转成TypeScript）、修复（自动Debug），甚至能用在文档生成任务中。 见此情形，不少开发者”脑洞大开“，纷纷献策： - 有人提出可以用这种方式训练专精单一语言的“垂类LLM”； - 也有人建议将这种类型约束机制和现有的LSP工具（语言服务器）结合，进一步提升智能； - 还有开发者呼吁扩展到像Rust、Haskell、甚至Coq这种更强类型语言，把编译器的静态检查能力真正用起来。 未来的大模型或许真的会像程序员一样，一边写一边检查，一边Debug，生成的代码直接就能跑。 项目代码已开源：eth-sri/type-constrained-code-generation 论文：
