面向可信增强的 LLM 生成代码缺陷框架与优先级模型

现有研究分别从功能正确性、安全性、幻觉现象和代码质量等角度揭示了 LLM 生成代码中的局部问题，但对缺陷表象、形成根因与治理优先级之间系统联系的讨论仍相对不足。基于此，本文在综合既有研究的基础上，从可信性视角构建一个面向 LLM 生成代码可信增强的三层四维分析框架，将缺陷表象、形成根因与治理优先级纳入统一分析过程，并进一步提出可信性优先指数 TPI（Trustworthiness Priority Index），用于刻画不同类型缺陷的治理优先顺序，从而为后续可信增强系统的设计提供结构化依据。

1. 可信性缺陷的定义与研究边界

本文认为，LLM 生成代码的可信性不应被简化为pass@k或少量样例测试的通过率，而应被界定为生成代码在给定上下文中满足可执行、功能正确、安全、上下文一致与演化可接受等要求的综合程度。《Evaluating Large Language Models Trained on Code》指出，代码生成评价不能由表面文本相似度替代功能正确性，且模型在长链规格理解、变量绑定和未定义引用上存在明显局限（pp.1-2, 10-12）。《Is Your Code Generated by ChatGPT Really Correct?》进一步表明，现有基准测试集常因测试规模与边界覆盖不足而高估模型真实正确率，增强测试后pass@k可显著下降（pp.1-6, 9-10）。与此同时，《Security Assessment of Generated Code》说明，功能正确与安全正确并不等价，传统pass@k无法反映不安全 API、输入校验缺失或漏洞传播问题（pp.1-3, 5-9）。

"we provide evidence that BLEU score may not be a reliable indicator of functional correctness by showing that functionally inequivalent programs generated by our model (which are guaranteed to disagree with the reference solution on some input) often have higher BLEU scores than functionally equivalent ones." （《Evaluating Large Language Models Trained on Code》）

"we find that Codex can recommend syntactically incorrect or undefined code, and can invoke functions, variables, and attributes that are undefined or outside the scope of the codebase."（《Evaluating Large Language Models Trained on Code》）

"Current programming benchmarks often only include on average less than 10 tests for each coding problem."（《Is Your Code Generated by ChatGPT Really Correct?》）

"there could be one or more possible solutions that are functionally correct but insecure."（《Security Assessment of Generated Code》）

据此，本文将可信性缺陷定义为：LLM 生成代码在可执行、功能语义、安全防护、项目上下文一致性或演化维护性方面偏离开发任务要求的结构化失配现象。该定义强调三点。第一，可信性是多维概念，不能被单一功能测试替代。第二，可信性缺陷不仅表现为显性报错，也包括能运行但不可信的隐蔽偏差。第三，可信性分析的目的不是简单列举错误，而是为后续系统建立可治理、可排序的优化靶点。

2. LLM 生成代码可信性缺陷分类体系

本文认为，现有研究虽已分别识别语法错误、漏洞、幻觉、过时 API 等问题，但尚缺少一个以可信增强为目标的统一分类框架。基于此，本文从可信性视角对相关缺陷进行归纳，并构建五类可信性缺陷体系，将其置于三层框架的表象层中。

图 1 LLM 生成代码可信性缺陷三层框架图

表 1 给出本文的缺陷分类体系。该表的目的不是重新命名已有 bug，而是将分散在不同研究中的错误表征纳入同一个可信性视角中。

本文认为，可执行性缺陷是最直观的一类问题。《A Static Evaluation of Code Completion by Large Language Models》指出，未定义名称、未使用变量、解释器版本不匹配是大规模真实代码补全中的高频静态错误，其中上下文错误还会被模型放大并传播到生成结果（pp.1-6, 9）。这说明 LLM 并非只在“复杂推理任务”中犯错，基础作用域和语言版本约束同样会造成可执行性失配。

相关研究原文写道：

"Undefined Name and Unused Variable are the most prominent static errors." （《A Static Evaluation of Code Completion by Large Language Models》）

"Interpreter version mismatch is one of the major reasons"（《A Static Evaluation of Code Completion by Large Language Models》）

本文进一步认为，功能语义缺陷才是可信性研究的核心难点，因为它具有较强隐蔽性。《Program Synthesis with Large Language Models》显示，模型对多约束任务、复合子问题和长规格描述尤为脆弱，往往只实现部分子目标（pp.8-12）。《Is Your Code Generated by ChatGPT Really Correct?》则说明弱测试会掩盖边界条件和逻辑漏洞，使模型表现被系统性高估（pp.1-6, 9-10）。

"few-shot performance is quite sensitive to the particular examples given in the prompt."（《Program Synthesis with Large Language Models》）

"the model often generated a partial solution"（《Program Synthesis with Large Language Models》）

安全性缺陷对应“功能可用但安全不可接受”的情形。《Security Assessment of Generated Code》指出，即使代码可通过功能性测试，仍可能包含不安全实现，因此需要同时引入静态和动态安全评估（pp.1-3, 5-9）。这意味着安全性不是功能正确性的附属指标，而是可信性中的独立维度。

上下文与知识一致性缺陷主要发生在仓库级和工程级场景。《LLM Hallucinations in Practical Code Generation》将仓库级幻觉细分为任务需求冲突、事实知识冲突和项目上下文冲突三大类，并进一步包含库知识、API 知识、环境、依赖与非代码资源冲突（pp.2, 4-10）。《LLMs Meet Library Evolution》则从 API 演化角度表明，模型容易因训练知识滞后和推理阶段缺乏后验知识而生成过时 API 使用（pp.1-2, 6-11）。

"LLM hallucinations in code generation can be divided into three major categories"（《LLM Hallucinations in Practical Code Generation》）

"We identify four potential factors that cause hallucinations"（《LLM Hallucinations in Practical Code Generation》）

"All the evaluated LLMs faced issues with deprecated API usages"（《LLMs Meet Library Evolution》）

"absence of API deprecation knowledge during model inference"（《LLMs Meet Library Evolution》）

演化与可维护性缺陷虽然不一定立刻触发运行错误，却会在长期维护中累积技术债。《A Static Evaluation of Code Completion by Large Language Models》中出现的未使用变量、未使用导入等问题说明，生成代码常带有表面可运行但结构松散的“残留噪声”（pp.5-6）。这类问题与《LLM Hallucinations in Practical Code Generation》中归纳的非功能需求冲突形成呼应，表明风格、性能、代码异味等问题也应被纳入可信性研究范畴（pp.4-5）。

3. 可信性缺陷的四源根因机制

本文认为，若只将上述缺陷笼统归因于幻觉，难以为后续系统设计提供精确靶点。基于前述分类，本文进一步将缺陷形成机制归纳为模型架构与解码机制、训练数据质量与偏差、编程语言规范与语义复杂性、仓库级上下文与环境约束缺失四类来源，以形成四源根因分析框架。

图 2 缺陷形成机制图

3.1 模型架构与解码机制

本文认为，decoder-only 的 next-token 目标使模型更擅长“局部流畅续写”，却不天然保证全局语义一致。《Program Synthesis with Large Language Models》明确指出，模型对多约束、多子目标问题容易只完成局部子任务，并且对提示示例高度敏感，不同 prompt seed 会带来明显性能波动（pp.5, 8-10）。《Evaluating Large Language Models Trained on Code》也显示，模型在长链规格理解、变量绑定和作用域一致性上存在局限（pp.1-2, 10-12）。据此，本文将可执行性缺陷与功能语义缺陷中的一部分视为“解码局部最优压倒全局一致性”的结果。

3.2 训练数据质量与偏差

本文认为，训练语料并不是中性的代码知识库，而是错误、过时和不安全实践的混合体。《LLM Hallucinations in Practical Code Generation》指出，低质量训练数据、docstring 与代码错配、不安全实现与 API 误用都会被模型吸收，并转化为任务需求冲突与知识冲突（p.8）。《LLMs Meet Library Evolution》进一步表明，开放代码语料中同时存在 deprecated API 与 replacing API，模型训练阶段若不显式过滤，就会把两者同时纳入参数化知识，进而在推理中复现过时调用（pp.6-7）。因此，安全性缺陷、上下文知识冲突和演化性缺陷都与训练数据质量直接相关。

3.3 编程语言规范与语义复杂性

本文认为，编程语言不是单纯的 token 序列，而包含类型规则、前置条件、运行时语义和版本规范。《A Static Evaluation of Code Completion by Large Language Models》将 Python2/3 解释器差异视为非 EOF 语法错误的重要来源（p.5）。《MultiPL-E》则显示，不同语言的类型注解、语言特性和 API 组织方式会显著影响生成正确率，并且语言特定错误在跨语言迁移中尤为突出（pp.1-2, 10-12）。因此，语言语义复杂性既解释了可执行性缺陷，也解释了为什么上下文一致性问题在多语言和多框架任务中更突出。

相关研究原文写道：

"Code generation performance is correlated with language popularity"（《MultiPL-E》）

"performance is sensitive to prompt design"（《MultiPL-E》）

3.4 仓库级上下文与环境约束缺失

本文认为，仓库级可信性问题的根源并不只在模型参数，而在于推理时可见上下文严重不足。《LLM Hallucinations in Practical Code Generation》指出，环境冲突、依赖冲突与非代码资源冲突是实际工程场景中的重要幻觉来源，原因在于模型难以完整访问配置、依赖、资源文件和内部 API 结构（pp.2, 4-10）。该文进一步提出仓库级检索增强能够缓解这一问题（pp.9-10）。这意味着，上下文与知识一致性缺陷本质上是“参数化知识无法覆盖项目特定事实”的表现。

4. 可信性优先指数 TPI 及关键治理顺序

为了把缺陷研究从“描述问题”推进到“确定治理顺序”，本文引入可信性优先指数 TPI 作为辅助分析工具。TPI 由四个维度构成：严重性S、隐蔽性H、传播性P与检测难度D。每个维度采用 1 到 5 分离散评分，指数定义如下：

TPI = 0.35S + 0.25H + 0.20P + 0.20D

本文采用这一权重的原因是：严重性直接关系到系统失效与安全后果，因此占比最高；隐蔽性决定缺陷是否会“带病上线”，因此次之；传播性与检测难度共同刻画工程治理成本。

这个表的排序体现了本文的一个核心判断：最危险的缺陷不一定是最显眼的缺陷。可执行性缺陷虽然常见，但通常会被解析器、编译器、AST 检查或基础单测较早发现，因此其隐蔽性和检测难度相对较低。《A Static Evaluation of Code Completion by Large Language Models》中的高频静态错误恰恰说明，这类问题适合作为前置过滤层处理（pp.1-6）。相比之下，功能语义缺陷和安全性缺陷常常“可运行、可编译、甚至可通过弱测试”，却在边界输入、攻击路径或真实项目约束下暴露失效，因此 TPI 更高。《Is Your Code Generated by ChatGPT Really Correct?》和《Security Assessment of Generated Code》共同支持这一判断（前者 pp.1-6, 9-10；后者 pp.1-3, 5-9）。

本文进一步认为，上下文与知识一致性缺陷应高于可执行性缺陷进行治理，因为其传播性更强。一旦错误 API、过时依赖或错误资源访问嵌入仓库级开发流中，它们会影响后续文件、测试与部署流程。《LLM Hallucinations in Practical Code Generation》与《LLMs Meet Library Evolution》都表明，这类错误具有明显的工程级扩散效应（前者 pp.2, 4-10；后者 pp.6-11）。

5. 缺陷-根因-治理策略三元映射与系统设计启示

基于此表，后续可信增强系统的模块设计可以形成清晰映射。可执行性缺陷对应前置静态防线，包括 AST 解析、语法检查、版本识别和导入修复。功能语义缺陷对应中层验证防线，包括测试增强、反例生成、执行反馈和约束分解。安全性缺陷对应专门的安全治理模块，如规则库、静态分析工具与漏洞修复闭环。上下文与知识一致性缺陷则提示系统必须具备 RAG、仓库级检索、依赖感知和文档增强能力。演化与可维护性缺陷虽然优先级相对靠后，但应通过风格规范、重构建议和 API 更新知识库进行持续治理。

据此，本文的核心工作可进一步概括为：在综合现有正确性、安全性与幻觉研究的基础上，本文从缺陷表象、形成根因到治理优先级与系统策略之间建立了一套统一分析思路。这一框架有助于解释 LLM 生成代码为何会出现多维失配，也为后续系统采用分层治理而非单点修补提供了分析依据。

6. 可信性缺陷探针实验与可视化分析

6.1 实验目标与研究问题

为了避免“三层四维”框架停留在概念层，本文进一步构建一个小型验证性探针集，对不同可信性缺陷的可检测差异进行实验观察。该实验不以形成通用 benchmark 为目标，而是服务于三个问题：RQ1，不同可信性缺陷是否呈现出显著不同的可检测特征；RQ2，单一检测手段能否覆盖全部缺陷类型；RQ3，实验中的检测难度是否与 TPI 所刻画的治理优先级基本一致。

6.2 探针集构建方法

本文构建了一个包含 30 个样本的迷你评测集，覆盖五类一级缺陷，每类固定 6 个样本，分别对应可执行性缺陷、功能语义缺陷、安全性缺陷、上下文与知识一致性缺陷、演化与可维护性缺陷。样本设计遵循三个原则：一是每个样本只突出一种主缺陷；二是每个样本只绑定一个主导根因；三是每个样本都映射一个优先治理策略。每个样本统一记录id、defect_type、probe_name、code_snippet、expected_signal、detector_type、root_cause和governance_strategy等字段。

6.3 检测流程与指标

检测流程分为四步：第一，载入结构化样本集；第二，按 AST/语法检测、运行时执行检测、规则检测和增强测试检测四类检测器依次执行；第三，记录命中与漏检现象并输出结果表；第四，结合 TPI 计算结果绘制统计图。为突出“基础前置防线”和“深层验证防线”的差异，本文额外定义基础检出难度为：

基础检出难度 = 100% - basic_pipeline_detected

其中，basic_pipeline_detected表示样本能否被 AST、运行时或规则检测中的任一基础检测手段识别。该指标主要用于与 TPI 进行对照，而不替代 TPI 本身。

6.4 结果统计与可视化

实验脚本 trustworthiness_probe_benchmark.py 会自动生成样本文件 trustworthiness_probe_cases.json、结果文件 trustworthiness_probe_results.csv 以及图 3 至图 6。表 4 给出了不同缺陷类型的汇总结果。

图 3 五类可信性缺陷样本构成

图 4 不同检测方式的命中率对比

图 5 缺陷类型与检测方式热力图

图 6 TPI 与实验检出难度对照图

从图 4 和图 5 可以看出，五类缺陷确实表现出显著不同的可检测特征。可执行性缺陷主要由 AST 与运行时检测前置发现，说明这类缺陷适合在生成后第一时间进行静态过滤。功能语义缺陷几乎完全依赖增强测试暴露，表明这类缺陷虽然“可运行”，却难以被基础检测发现。安全性缺陷和上下文一致性缺陷的命中率明显低于可执行性缺陷与维护性缺陷，说明单靠通用规则或即时执行仍不足以覆盖真实工程风险。演化与可维护性缺陷则更多体现为代码异味和规范偏离，因此规则检测的覆盖率相对较高。

6.5 与 TPI 排序的一致性分析

从 RQ1 的角度看，实验结果支持“不同可信性缺陷具有显著不同的可检测性”这一判断。从 RQ2 的角度看，图 5 清楚表明不存在能够覆盖全部缺陷类型的单一检测手段，可信增强系统必须采用“前置静态过滤 + 中层执行反馈 + 后置测试与安全治理”的组合式结构。从 RQ3 的角度看，图 6 显示高 TPI 缺陷总体位于更靠右上区域，即它们要么基础检出难度更高，要么即便具备一定规则命中率，仍因严重性和隐蔽性而保持较高治理优先级。特别是功能语义缺陷与安全性缺陷，分别体现了“测试依赖型隐蔽错误”和“规则可见但后果严重的高风险错误”两类典型高优先问题。相比之下，可执行性缺陷和演化与可维护性缺陷虽然在工程实践中同样常见，但更适合作为前置过滤层和持续维护层处理，这与第 4 节给出的 TPI 排序基本一致。

由此可见，这一迷你评测并不追求大规模统计显著性，而是验证了本文提出框架的三个关键性质：其一，三层框架能够把不同缺陷区分为具有不同检测特征的对象；其二，缺陷类型与治理手段之间存在稳定映射；其三，TPI 可以作为后续系统设计中安排治理先后顺序的辅助依据。

附录 A：探针样本与脚本说明

本实验的复现实物包括三部分：

附录中的这些材料主要承担“可复现支撑”作用，而正文第 6 节负责给出方法、统计结果和结论解释。 AtomGit | GitCode - 全球开发者的开源社区,开源代码托管平台

附录 B：证据定位表