LLM 生成的代码补丁如何通过编译验证检测幻觉？

LLM 生成的代码补丁看起来语法合理，却可能引用不存在的函数、传入错误参数、导入项目中没有的模块，或者使用未定义变量。这类“代码幻觉”最可靠的检测方式不是再让另一个模型判断文本是否可信，而是把补丁放回真实项目环境，运行编译器或类型检查器，让语言工具链给出可复现结果。

为什么文本评审难以识别代码幻觉

语言模型擅长生成外观合理的标识符和 API 调用。一个方法名符合项目命名风格、参数类型看似匹配，文本评审模型就可能认为它正确，但该符号在目标版本依赖中根本不存在。不同评审模型还会对同一补丁给出不同结论。

静态文本相似度也不足。正确补丁可能与参考答案写法不同，却同样可编译；错误补丁可能只差一个方法名，与参考答案高度相似。需要把判断锚定在语言和项目实际规则上。

Delulu 提供了怎样的验证基准

Microsoft 的 Delulu 是面向填空式代码补全幻觉的多语言验证基准。每个样本包含前缀、后缀、正确补全和幻觉补全。正确版本必须在原项目环境中编译通过，幻觉版本则必须由编译或类型检查明确判定失败。

仓库列出的数据包含 7 种语言：C++、C#、Go、Java、TypeScript、Python 和 Rust，共 1947 个样本、947 个独立填空上下文。幻觉类型分为无效导入、错误方法、错误参数和未定义变量四类。

这些样本来自采用宽松许可证的真实 GitHub 项目，每行记录来源仓库和许可证。真实 API 与依赖环境比人工编造小题更能暴露模型对库版本、项目符号和调用约定的错误记忆。

一条样本为什么需要独立容器

代码能否编译取决于编译器版本、依赖锁定、构建脚本、平台库和项目配置。同一段代码在开发者电脑上失败，可能只是环境缺失；在另一个版本依赖中通过，也不代表目标提交正确。

Delulu 为每个样本提供自包含 Docker 验证环境，将原始项目、工具链和验证命令固定下来。验证器可以分别运行正确补全、幻觉补全或用户提交的 patch，避免环境漂移把标签变成偶然结果。

一条样本对应一个镜像虽然增加存储和构建成本，却带来可复现性。任何人都能重新运行同一编译或类型检查，确认标签来自工具链而非作者或模型意见。

编译验证流程如何设计

第一步保存目标代码的前缀与后缀，明确插入区域。第二步将模型补全放入两者之间，构造候选文件或补丁。第三步在锁定容器中应用候选，并运行项目原生的编译、构建或类型检查命令。

验证器需要返回退出状态、标准输出、标准错误和超时信息。退出状态为零代表通过本次编译门禁；非零时应解析首个根因，例如符号不存在、参数数量错误、类型不兼容或模块无法解析。

执行完毕后丢弃容器，下一条样本从干净镜像开始。这样模型补丁不会污染后续验证，缓存、生成文件或依赖修改也不会让结果互相影响。

四类幻觉如何被工具链发现

无效导入会在模块解析阶段失败。模型可能根据其他语言或新版文档臆造包路径，也可能把开发依赖当作生产依赖。锁定项目依赖后，编译器能确定该模块是否真实存在。

错误方法包括对象没有该成员、方法名拼写错误或可见性不符。文本上合理的方法调用会被类型系统与符号表直接否定。动态语言若缺少完整静态类型，则可能需要项目自带类型检查器或最小运行测试。

错误参数涵盖数量、名称、顺序和类型不匹配。编译器能验证函数签名，但无法判断一个合法值是否符合业务含义。未定义变量通常来自模型遗漏声明、作用域误判或复制了不存在的上下文。

如何评估模型生成的补丁

Delulu 的编译型 pass@1 将模型第一次补全逐条送入样本验证器，统计通过比例。它还提供精确匹配、与正确补全的字符级归一化编辑相似度，以及候选更接近幻觉版本的比例。

精确匹配很严格，能编译的不同实现也会被判不相同；编辑相似度反映文本距离，却不等于正确性；编译通过更接近工程有效性，但仍不能证明行为。多个指标组合起来，才能区分“写法不同但合法”和“外观接近却不可用”。

仓库还提供 LLM 评审模式：评审模型同时判断正确与幻觉补全，只有正确版本得一分且幻觉版本得零才算识别成功。它适合研究模型能否从文本识别幻觉，但生产门禁应优先采用真实工具链。

怎样把方法用于 Code Agent

Agent 应在隔离工作树生成 patch，应用后根据文件类型选择验证命令。Python 可运行编译和类型检查，TypeScript 运行项目配置下的类型检查，Go、Rust、Java、C# 和 C++ 使用各自项目构建工具。命令必须来自仓库配置，不应凭语言名称随意拼接。

验证失败时，把文件、行列、错误代码和最小上下文结构化反馈给 Agent，让它在有限次数内修正。下一轮仍要从明确状态开始，避免失败补丁与新补丁层层叠加。

多文件补丁需要先全部应用再编译，因为符号定义和引用可能分散在不同文件。若应用阶段部分失败，应事务式回滚，不能在半完成代码上解释编译错误。

编译通过为什么仍可能是幻觉

编译器只验证它理解的规则。模型可能调用真实 API，却使用错误业务参数；可能返回错误算法结果、遗漏权限检查或制造竞态条件。弱类型、反射、动态导入和字符串形式的 SQL 也可能绕过静态分析。

因此，编译通过只能排除一类可证伪幻觉，不能作为最终正确证明。后续仍需运行单元测试、集成测试、静态安全分析和业务不变量检查。对于没有测试覆盖的新行为，还需要人工审查或增加测试。

反过来，编译失败也不一定是模型幻觉。基础镜像缺依赖、网络下载失败、平台不兼容或仓库本身基线失败都会产生非零退出。验证前必须先确认原始代码和正确样本在相同环境中能够通过。

如何避免把环境故障误标为幻觉

每个验证器应有三项基线：未修改项目能够构建、正确补全能够通过、已知幻觉补全稳定失败。只有三者都满足，才接受该样本。构建日志要区分依赖安装、编译、类型检查和测试阶段。

镜像应锁定基础版本与依赖摘要，避免使用会随时间变化的 latest 标签。外部网络最好关闭或只允许预先缓存资源，验证命令设置确定性环境变量、时间和资源上限。

连续运行同一样本可以发现偶发失败。若结果受并行、时间或网络影响，就不适合作为确定标签，应该修复或移出基准。

生产验证的安全边界

模型补丁属于不可信代码。构建脚本可能执行任意命令，因此验证必须在无凭据、有限 CPU、内存、磁盘和时间的容器中运行。不要把宿主 Docker socket、SSH 密钥或云令牌挂入候选代码环境。

网络访问、文件系统写入和子进程数量也要限制。验证完成后销毁环境，只导出经过过滤的日志和结果。即使来源仓库可信，模型也可能修改构建脚本引入危险行为。

推荐的多层门禁

• 补丁格式和目标路径检查。
• 文件解析与基础语法检查。
• 项目原生编译或类型检查。
• 受影响模块的单元测试。
• 跨模块集成与业务不变量测试。
• 静态安全、依赖和范围审查。
• 最终 diff 与人工审批。

门禁应从快到慢排列，早期失败可减少无效计算。每层输出统一诊断对象，Agent 才能知道是补丁未应用、符号幻觉、测试回归还是安全策略拒绝。

适用范围与局限

Delulu 面向 Fill-in-the-Middle 补全，不等同于完整自主 Agent 的仓库级任务。数据集中四类幻觉集中在编译和类型阶段，不能覆盖逻辑、安全、性能和需求理解错误。7 种语言的结果也不能直接推广到未包含语言。

它的价值在于提供一种可审计标签构造方法：正确样本真实通过，错误样本真实失败，环境随样本一起交付。构建其他 Agent 基准时，可以沿用这种“执行证据优先”的原则。

结论

检测 LLM 代码补丁中的可编译性幻觉，应把候选放回锁定的真实项目环境，运行编译器或类型检查器，而不是只依赖文本相似度或另一个模型判断。独立容器、基线验证和可复现日志能让每个标签具有执行证据。

编译验证擅长发现不存在的导入、方法、参数签名和变量，但它只是多层质量门禁的一部分。Code Agent 还需要测试、业务不变量、安全审查和 diff 审批。以真实工具链证伪幻觉，再用行为验证证明功能，才能更可靠地接受自动生成补丁。