LLM 生成的代码中的拼凑问题

LLM 生成的代码通常可以编译、通过测试并且看起来正确，但一旦部署就会​​中断。根本原因通常是结构性的而不是逻辑性的。生成的端点引用了项目中从未声明的配置密钥，导入的目标是任何注册表中都不存在的包，或者新路由省略了应用于每个同级端点的身份验证防护。每个补丁在本地有效，但在全局上不一致，并且标准 CI 工具链很少会出现这些故障。随着 LLM 支持的编码工具得到广泛采用，这个盲点给软件质量带来了越来越大的风险。我们称之为\textbf{拼凑问题}。本文将结构一致性形式化为存储库工件图表示的一致性不变量，包括导入、调用、依赖、配置、模式、资源、控制流和路由图，并引入八类故障分类法，区分 LLM 生成特有的缺陷和仅由其放大的缺陷。我们提出了一个混合验证框架，该框架委托给成熟的静态分析工具，这些工具已经表现出色，并针对现有工具链服务不足的横切不变量部署专门构建的检测器，针对可证明的约束违规而不是启发式模式匹配。在四种提示策略下对两个前沿模型进行的实证评估表明，绝大多数结构故障完全规避了类型检查、测试和 SAST，并且模型之间的故障模式在质量上存在差异，这对与模型无关的缓解策略提出了挑战。对现实世界人工智能生成的存储库的外部验证证实，这些失败不是受控实验的产物，而是在 LLM 在人为监督最少的情况下编写代码的地方普遍存在。