仓库级编程助手能否检测自身的不安全代码变更？

“不安全代码变更”对这些工具究竟意味着什么？

在仓库级编程助手的语境下，“不安全”主要指引入依赖错误（如未定义变量或缺失导入）、无法编译，或破坏跨多个文件的现有功能的代码。相关论文一致通过静态有效性率、编译率和测试通过率等指标来衡量安全性。[1]明确界定了依赖错误，例如“未定义变量和无成员错误”，并采用名为“静态有效性率”的新指标来评估生成代码避免此类错误的频率。[2]则使用compile@k和pass@k分数来捕捉生成代码能否成功编译并通过测试。[4]更进一步，要求编辑后的仓库“构建无错误且代码修改正确”，以此作为有效性检查。因此，本研究中的“不安全”指的是引入具体、可检测的故障的代码，而非细微的安全漏洞。

核心发现：这些工具不具备内置的自我检测能力

在全部五篇论文中，均未描述编码助手对其自身输出进行监控或安全性评估的机制。这些工具的设计目标是生成代码，而非审计代码。[4]明确指出了这一局限：它表明，没有规划框架的基础大语言模型“无法让任何代码仓库通过”有效性检查（即无错误构建且正确修改），而采用显式规划的CodePlan系统则在7个代码仓库中的5个上取得成功。这意味着即使性能最优的系统在相当比例的代码仓库上仍会失败，且它们自身无法检测这些失败。[1]报告称，即便采用其ToolGen方法（利用自动补全工具减少依赖错误），三个大语言模型的静态有效性率也仅从44.9%提升至57.7%——但这仍意味着42-55%的生成代码存在未解决的依赖错误。这些工具无法标记哪些输出是不安全的。

自我检测为何比想象中更难

仓库级代码的复杂性使得自我检测从根本上变得困难。仓库中的代码是“相互依赖的”[4]，这意味着一个文件中的改动可能会破坏工具可能从未见过的另一个文件中的功能。[2]指出，成功的生成需要“既包含通用的、与上下文无关的知识，也包含特定的、与上下文相关的知识”，这些知识分布在多个文件中。[3]表明，即使是基于检索的方法也面临挑战：他们的强化学习框架在精确匹配上比以往方法提升了12.2%的检索质量，但仍然依赖外部检索器来寻找相关上下文——它并不评估最终生成的代码是否安全。[5]类似地采用了一种迭代检索-生成流程，但仅通过代码是否与真实补全匹配来衡量成功，而不考虑是否引入了不安全的更改。简而言之，研究界将安全性视为一个外部评估问题（由编译器、测试或人工评判来衡量），而非工具自身能够评估的内容。

未来工具能否自行检测其不安全变更？

证据表明，自我检测需要根本不同的系统架构。[4]的CodePlan最为接近，它通过引入“增量依赖分析”和“变更影响分析”作为引导LLM的符号组件，但即便如此，该系统也缺乏自我检测循环——它规划编辑，但不会在生成后进行验证。[1]的ToolGen使用自动补全工具在生成时减少错误，但安全检测仍然是外部的（静态分析工具）。没有一篇论文提出或评估过这样一个系统：它生成代码，然后自行检查输出的安全性，再自主标记或修正不安全的变更。研究始终将安全性视为由外部工具（编译器、静态分析器、测试套件）或人工审查者衡量的事项，而非由编码助手自身完成。因此，尽管未来工作可以集成此类验证循环，但当前一代的仓库级编码助手无法检测自身的不安全代码变更。

关于这些来源

该回答基于5篇经同行评审的研究——发表于2023年至2025年间，其中4篇为2024年或之后发表，2篇发表于Q1期刊，累计被引用175次——这些研究是从5篇通过质量筛选的文献中选出的最具相关性的成果，而该筛选过程则源于从超过5亿篇论文数据库中检索到的51篇文献。

本文引用的文献

相关研究问题