尽管AI辅助编程或“氛围编码”已成为趋势，甚至被选为年度词汇，但相关研究揭示了一个根本性问题：大型语言模型在生成代码时，仅能保证约一半情况下的安全性。这引发了对其在软件开发中应用的根本性安全担忧。

核心问题在于，LLM能够预测语法，却无法理解网络安全。风险等语义概念超出了其理解范围。同时，有限的上下文窗口（或短期记忆）意味着当前的LLM可能会忽略整体情况，包括安全漏洞。即使最大的模型也无法持有理解哪些数据是危险的及其原因所需的那种记忆。

AI生成的代码在表面上可能看起来正确且安全，但细微的漏洞几乎总是隐藏其中。LLM的训练历史一直优先考虑准确性而非网络安全。虽然投入了大量精力来提高正确性，较新、较大的模型现在能生成功能高度完善的代码，但对其代码是否真正安全的关注却少得多。

一个主要问题是，开发者在AI提示中无需指定安全约束就能获得他们想要的代码。例如，开发者可以提示模型生成数据库查询，而无需指定代码应使用预处理语句（安全）还是字符串拼接（不安全）来构建查询。因此，选择权留给了模型。对于一些漏洞，模型可能无法确定哪些特定变量需要清理（即哪些变量被用户控制的数据“污染”）。

这些弱点并非偶然，而是源于大型语言模型理解上下文、意图和风险的方式存在根本性限制。向安全AI生成代码的进展已经停滞，近期研究发现，尽管该领域持续发展，但主要LLM提供商在安全方面几乎没有进展。

造成这种情况的一个重要原因在于训练数据。LLM通过从互联网上消耗大量数据和信息进行学习，其中许多包含隐藏或未解决的安全漏洞。这些数据并未被标记为安全或不安全，因此模型对两种类型一视同仁。对AI而言，一个不安全的数据库查询和一个安全的查询只是完成请求的两种有效方式。

此外，LLM不区分数据与指令，而是简单地将所有内容作为令牌流处理。这为提示注入攻击打开了大门，攻击者可以将恶意指令混入看似普通的用户输入中。如果模型无法区分，它就可能被诱骗做出开发者从未预期的行为。

安全风险会出现在不同层面。有些漏洞源于模型本身，即AI解释或生成内容的方式存在缺陷。另一些则出现在应用层，即开发者将LLM集成到实际系统中时。在这些情况下，风险来自系统如何处理外部输入、用户权限以及与其他组件的交互。

对于开发者而言，生成式AI工具有潜力改变效率，但它们应始终仅用作提高生产力的助手，并需结合严格的人工安全审查与测试。