LLM生成代码中的拼凑问题

# LLM 生成代码中的补丁问题
来源：https://arxiv.org/html/2607.08981
Viraaji Mothukuri, Reza M\. Parizi  
去中心化科学实验室，计算与软件工程学院  
肯尼索州立大学，美国佐治亚州  
vmothuku@students\.kennesaw\.edu  
rparizi1@kennesaw\.edu

###### 摘要

LLM 生成的代码通常能编译通过、通过测试、看起来正确，但一旦部署就会出问题。其根本原因常常是结构性的，而非逻辑性的。一个生成的端点引用了项目中从未声明的配置键；一个导入指向了任何软件仓库中都不存在的包；或者一个新路由遗漏了应用于所有同级端点的身份验证守卫。每个补丁在局部有效，但在全局上不连贯，而标准的 CI 工具链很少能揭示这些失败。随着 LLM 驱动的编码工具被广泛采用，这一盲点对软件质量构成了日益增长的风险。我们称此为**补丁问题**。本文通过将存储库工件（包括导入图、调用图、依赖图、配置图、模式图、资源图、控制流图和路由图）的图表示上的一致性不变量来形式化结构连贯性，并引入了一个八类别的故障分类法，以区分 LLM 生成特有的缺陷与仅被 LLM 放大的缺陷。我们提出一个混合验证框架，将成熟的静态分析工具在其擅长的领域进行委托，并针对现有工具链未充分服务的跨领域不变量部署专用检测器，目标是可证明的约束违反，而非启发式模式匹配。在两个前沿模型、四种提示策略下的实证评估表明，绝大多数结构故障完全避开了类型检查、测试和 SAST，并且模型之间的故障模式在性质上存在差异，这对模型无关的缓解策略提出了挑战。在真实世界 AI 生成的代码仓库上的外部验证证实，这些故障并非受控实验的产物，而是在 LLM 在最少人工监督下编写代码的任何地方都很普遍。

关键词：LLM 代码生成，结构连贯性，静态分析，图不变量，代码质量，神经代码合成。

## 1 引言

大型语言模型的代码生成在孤立编程任务上取得了显著成果[7 (https://arxiv.org/html/2607.08981#bib.bib1),4 (https://arxiv.org/html/2607.08981#bib.bib2),11 (https://arxiv.org/html/2607.08981#bib.bib3),1 (https://arxiv.org/html/2607.08981#bib.bib4)]，推动了快速采用，每天有数百万工程师使用 LLM 驱动的助手。然而，基准性能与生产实用性之间仍存在差距[8 (https://arxiv.org/html/2607.08981#bib.bib5)]。单独看起来正确的代码在集成到真实软件系统时常常失败[27 (https://arxiv.org/html/2607.08981#bib.bib7)]，而主要的故障模式是结构性的而非功能性的。生成的补丁可能编译通过、通过类型检查、满足局部测试，但违反了跨越存储库的不变量。考虑一个 FastAPI 端点引用了带有虚构字段名的 Pydantic 模型，或者一个 Django 视图假设了项目配置中从未声明的环境变量。这样的补丁展示出局部正确性但全局不连贯：它们通过了开发者依赖的检查，并且只有在完整系统的上下文中执行时才会失败。

当前的评估方法并未系统地揭示这些故障。类型检查和代码检查经常遗漏跨文件边界的语义不一致性。测试套件无法覆盖每一个集成点。SAST 工具通常关注污点流而非结构连贯性。结果是一个盲点，生成的代码携带潜在缺陷进入代码库，而标准工具链对这些缺陷视而不见。我们称此为**补丁问题**。LLM 生成的补丁可能各自格式良好，但未能连贯成一个整体，尤其是在存储库规模下，其中一致性约束跨越了导入、依赖、配置、模式和安全契约[12 (https://arxiv.org/html/2607.08981#bib.bib10)]。

我们的方法将结构连贯性形式化为存储库工件图表示上的不变量[25 (https://arxiv.org/html/2607.08981#bib.bib8)]。一个关键的设计洞见是，可靠的检测需要将每个不变量类与适当的验证策略相匹配。成熟静态分析工具已经捕获相关语言语义的类别可以委托给这些工具，而需要跨图推理且现有工具链中缺失的类别，则需要专门的检测器，这些检测器在明确假设下针对约束违反，并生成可操作的证据。这项工作做出了三个贡献：(1) 我们引入了一个**八类结构性故障分类法**，每个类别由基于图的一致性不变量定义，区分了 LLM 生成补丁特有的故障和仅被 LLM 放大的问题。(2) 我们提出了一个**多图验证框架**，将成熟的静态分析工具（mypy, tsc, pylint, ESLint）与八个存储库图上的专用跨图检测器集成，为每个违规生成局部化的证据轨迹。(3) 我们提供了跨越**两个前沿模型**、**四种提示条件**下的 **336 次生成**的实证研究，以及在 43 个真实世界 AI 生成的代码仓库上的外部验证。

## 2 相关工作

表 1 (https://arxiv.org/html/2607.08981#S2.T1) 将我们的贡献与先前在四个研究方向上的工作进行了比较。幻觉特征描述工作[27 (https://arxiv.org/html/2607.08981#bib.bib7),20 (https://arxiv.org/html/2607.08981#bib.bib9)]确立了生成代码中结构性缺陷的实证普遍性，但描述性地而非作为可验证的约束违反来刻画它们。仓库级基准，包括 RepoBench[12 (https://arxiv.org/html/2607.08981#bib.bib10)]、SWE-bench[8 (https://arxiv.org/html/2607.08981#bib.bib5)]、EvoCodeBench[9 (https://arxiv.org/html/2607.08981#bib.bib6)]、BaxBench[22 (https://arxiv.org/html/2607.08981#bib.bib11)]、SecRepoBench[19 (https://arxiv.org/html/2607.08981#bib.bib12)]、SecureVibeBench[3 (https://arxiv.org/html/2607.08981#bib.bib13)] 和 SWE-agent[26 (https://arxiv.org/html/2607.08981#bib.bib14)]，证明了片段级性能不能可靠地转移到仓库级任务，但其评估标准仍然是结果导向的（测试通过、利用成功），而非诊断哪些结构性不变量被违反。基于图的表示，如代码属性图[25 (https://arxiv.org/html/2607.08981#bib.bib8)]、CODE-MVP[23 (https://arxiv.org/html/2607.08981#bib.bib15)]和GALLa[28 (https://arxiv.org/html/2607.08981#bib.bib16)]，将图作为表示基础，但并未将其作为约束验证层来操作。安全生成方法，包括CodeGuard+[6 (https://arxiv.org/html/2607.08981#bib.bib17)]和SafeGenBench[10 (https://arxiv.org/html/2607.08981#bib.bib18)]，专注于漏洞预防，但未将结构连贯性形式化。我们的工作通过将结构不连贯定义为跨图表示的一致性约束违反，并生成将故障归因于特定约束违反的局部化证据轨迹，填补了这一空白。

表 1：相关工作总结
## 3 结构性故障分类法

补丁问题通过**结构性故障**表现出来，这些故障被定义为仓库规模下的一致性不变量违反，可通过静态图分析在不执行的情况下验证。这些故障不同于功能性错误，因为单个补丁看起来正确，但整体上违反了项目契约。我们的分类法包含八个类别，每个类别由形式不变量、所需的图工件以及 LLM 输出特有的故障特征定义。表 2 (https://arxiv.org/html/2607.08981#S3.T2) 总结了分类。

**符号解析故障 (SRF)**：当引用的名称无法在仓库的模块图中解析时，发生符号解析故障。形式上，对于文件 `f` 中的符号引用 `r`，模块图为 `M`，不变量要求 `∀r ∈ refs(f): ∃d s.t. resolve(r,f,M) → d`。检测需要导入图和符号表，并可选择性地使用类型信息进行泛型解析。证据轨迹记录文件、行号、符号、预期模块和解析结果。这类故障在 LLM 输出中**被放大**，因为模型在上下文不完整的情况下经常虚构看似合理但实际不存在的模块名或引用已弃用的 API。

**幻影内部 API (PIA)**：幻影 API 故障发生在生成代码调用具有不正确签名或与声明接口不一致语义的内部函数时。不变量要求签名兼容性：对于调用点 `c` 调用符号 `s`（签名注册表为 `Σ`），`compatible(sig(c), Σ(s)) = true`。检测利用从类型注解和协议声明中提取的调用图和签名注册表。这类**强烈被放大**，因为 LLM 根据命名约定而非实际声明来虚构方法签名，尤其是对于训练数据中代表性不足的内部 API。

**依赖幻觉 (DHI)**：算法 2 (https://arxiv.org/html/2607.08981#alg2) 验证所有外部导入是否引用了在项目依赖清单中声明的包。在依赖图中未找到的外部导入将触发对 PyPI 或 npm 的注册表查询，从而区分完全虚构的包（在注册表中不存在）与未声明但存在的包。对于 npm 包，导入名称与注册表名称直接匹配。对于 PyPI，检测器假定导入名称与包名称之间存在直接对应关系，这对于大多数包成立，但对于导入名称与分发名称不同的情况（例如 `yaml` 与 `PyYAML`，`cv2` 与 `opencv-python`）则不成立。生成的幻影模块集随后向下游的 `SRF` 和 `PIA` 检测提供信息。

**构建/配置不连贯 (BCI)**：构建配置故障发生在生成代码假设的配置与仓库声明的状态不一致时。不变量要求对于由生成代码隐含的每个配置假设 `a`，在配置空间 `C` 中存在一个满足声明的声明。检测操作在构建图和配置图上进行，配置图包含入口点、环境变量和框架设置。四条不变量类适用于所有语言，即入口点存在性、环境变量声明、模块系统一致性和框架配置对齐。在检索上下文较弱的情况下，模型默认采用与项目设置不同的标准配置，这类故障**被放大**。

**资源连贯性故障 (RCF)**：资源连贯性故障发生在代码未能提供声明的资源时，涵盖文件系统资源和计算契约。文件系统资源故障发生在代码引用不存在的文件、资源、模板或迁移时，存在性不变量要求对于每个资源引用 `r`，`exists(resolve_path(r, root)) = true`，并且对于顺序资源（如数据库迁移）还有额外的排序约束。返回契约故障发生在具有声明返回类型的函数包含不产生与声明类型匹配的值的执行路径时，违反了函数的签名向调用者承诺的契约。模式完整性故障发生在模型定义遗漏消费代码所需的字段时。检测操作在将代码引用映射到文件系统路径的资源图上，用于返回路径可达性分析的 CFG 上，以及用于字段完整性验证的模式图上。LLM 在所有三个子类别中表现出**放大的**故障率，通过基于约定而非实际仓库结构生成看似合理的路径，在错误处理分支上遗漏返回语句，并产生不完整的模式定义。

**控制流连贯性 (CFC)**：控制流故障表现为 CFG 异常，包括不可达块、矛盾条件、异常流误用和死错误处理。不变量要求从入口点完全可达（`∀v: reachable(v₀, v)`）以及异常处理程序类型一致性。检测操作在带有异常边标注的过程内 CFG 上进行。虽然不可达代码是一类通用错误，但 LLM 表现出**放大的**特征模式，例如过宽的异常处理、冗余的空检查和复制粘贴控制流不一致。

**跨文件契约违反 (CCV)**：契约违反发生在生产者模块和消费者模块之间在文件边界上出现接口不匹配时，包括错误的字段名、不兼容的序列化、不正确的错误代码和不对齐的假设。不变量要求模式兼容性：`schema(P.output) ⊇ schema(C.input)`，并且类型一致。检测需要跨文件边的调用图和从 OpenAPI 规范、Pydantic 模型或 Zod 模式中提取的模式图。LLM 通过根据命名约定虚构响应字段来**放大**这类故障。

参见说明图 1： Proposed Framework 概述
**安全结构性退化 (SSR)**：安全结构性退化发生在应用连线违反安全契约但没有经典的污点流漏洞时。不变量要求守卫覆盖：对于安全关键路由 `R` 和所需守卫 `M`，`∀r ∈ R: guarded_by(r, M)`。检测需要特定于每个框架的路由和中间件连接图。我们将检测范围限定为 FastAPI（依赖注入守卫）、Django（权限装饰器）、Express（中间件链）和 Next.js（中间件匹配器）。LLM 通过错误地连接中间件来**放大**这类故障，即使生成了语法正确的代码。

表 2：结构性故障分类法
## 4 验证框架

**架构概述**：验证框架采用混合架构，遵循精度优先的设计理念，每个分类法类别都匹配到能够为其不变量类最大化检测精度的验证策略。在成熟静态分析工具已经处理相关语言语义（符号解析、签名兼容性）的类别中，将其委托给这些工具，继承其多年来的边界情况处理。控制流连贯性采用混合方法，结合自定义图可达性和模式匹配与 SAST 工具委托，反映了单一层无法单独实现足够覆盖率的观察。需要跨图推理且现有工具链缺失的类别（配置不连贯、依赖幻觉、安全退化、资源连贯性、跨文件契约）采用专门的检测器，这些检测器针对可证明的约束违反而非启发式模式匹配。这种划分反映了经验观察，即从零开始重新实现已建立的分析会产生低精度的结果。