LLM生成代码安全：从“不要犯错”到确定性防线

这个标题我其实纠结了很久。去年某个项目上，团队希望用 LLM 快速实现一个 JWT 解析和生成的公共模块，模型输出的代码看起来非常体面：类型标注齐全、异常处理完整、注释清晰。结果在 code review 时发现，其中用于校验签名算法的那段逻辑，在alg为none时会直接跳过验证。更讽刺的是，当我把这段代码贴回同一个 LLM，问它“这段代码安全吗”，它回答“看起来是安全的”。

这不是某一个模型的问题，也不是某个人的操作失误。它指向一个更深层的事实：LLM 生成的代码，最大的风险不是“明显错误”，而是“看起来完全正确、却在特定条件下变成漏洞”。所以我才坚持用“不要犯错远远不够”这个说法。你根本没有办法靠一句“请写出安全的代码”来让 LLM 不犯错，它甚至可能根本不知道自己在哪里犯了错。这篇内容想聊清楚的，就是这件事到底为什么会发生，以及我们作为开发者，能靠什么东西真正兜住 LLM 生成代码的安全底线。适合正在用 AI 辅助编程工具、依赖 LLM 写生产代码的开发者，也适合那些准备把 LLM 接入研发流程、但还没想清楚安全边界该怎么画的团队。

1. 不安全代码的四种典型形态：LLM 到底会怎么坑你

我见过太多团队在讨论“LLM 代码安全”时，默认把问题等同于“模型会写出语法错误或者逻辑错误”。实际根本不是这么回事。LLM 生成的不安全代码，绝大多数时候长得非常正常，正常到让人根本不会多看一眼。我把这几年在实际项目里遇到的情况归纳成四种形态，每一种都在生产环境里真实出现过。

1.1 形式正确，语义危险

先看一段看起来很常见的代码：

def preview_file(filename): path = os.path.join(UPLOAD_DIR, filename) return open(path).read()

这段代码是 LLM 生成的，语法完全正确，类型也没问题，甚至os.path.join看起来还很讲究。可filename是用户传进来的，攻击者只需要传一个../../etc/passwd，就能读到服务器上的任意文件。为什么 LLM 会写出这种代码？因为在训练数据里，这种简化版文件读取的写法出现了上百万次。博客教程、论坛回复、开源项目示例，到处都是“先拼接路径再打开文件”的写法。LLM 从这些样本里学到的不是“应该怎么做才安全”，而是“代码在统计上最可能长什么样”。

这就是形式正确与语义危险的区别。LLM 犯的错不是“写错了”，而是“抄了一个错误的模板”。更麻烦的是，这种错误在 code review 时极难被发现，因为每个看代码的人都会下意识地相信“这种常规写法应该没问题”，尤其是当这段代码是 AI 生成的时候，审查者还会额外降低一档警惕性。

1.2 对依赖的过度自信：幻觉版本号与投毒风险

LLM 在生成依赖列表时，会非常自然地补全一个具体的版本号。我遇到过它把一个第三方库的版本“补全”到3.9.2，但那个版本实际上从未发布过，训练数据里混入了一份恶意文档，文档里煞有介事地写着这个版本号。这种情况下，如果开发者直接pip install package==3.9.2，很可能会从一个恶意镜像里拉下一个被篡改的包——这就是供应链投毒。

如果你正在做 RAG 检索增强，这个问题会更严重。从向量库里拉回来的文档本身都可能包含错误的版本号，LLM 并不会去验证，它只会把检索到的内容当作事实直接拼进代码里。我后来养成了一个习惯：LLM 写的任何requirements.txt，版本号必须逐条去官方源核对，绝对不直接采用。别嫌麻烦，一次投毒攻击的成本远远大于那十分钟的人工核对。

1.3 吞掉异常的“静默失败”

还有一种特别阴险的形态，是 LLM 把错误处理写得“太体贴”了：

try: result = authenticate(username, password) except Exception: result = True

看起来这像是模型在“防止程序崩溃”，实际上这段代码的意思是：只要authenticate函数抛出任何异常，认证结果就被当作成功。攻击者不需要猜对密码，只需要让函数抛个异常就能登录进去。LLM 之所以会写出这种代码，是因为在训练样本里有大量“try-except 兜底返回默认值”的模式，这些模式在处理非安全场景时可能问题不大，但在认证、授权、支付回调这些场景里，吞掉异常就等于把安全防线拆了。

我在一个实际项目里排查过类似问题，那个函数是 LLM 生成的支付回调处理，except Exception里居然写了return True。代码上线后，有一批伪造回调直接绕过了验签逻辑。后来排查到这一行的时候，整个团队都沉默了——没有一个人会在 review 的时候专门去看异常分支里返回了什么。

1.4 最隐蔽的自洽性幻觉

最后这种形态，是最难防的。LLM 在对话中会顺着你的话往下说。你问它“这段代码安全吗”，它说“看起来安全”；你问“这段代码是不是有漏洞”，它说“是的，这里有问题”。它的回答不是独立评估的结果，而是被你的提问方向锚定了。

这种自洽性幻觉最危险的地方在于：它会给开发者虚假的安全感。当一个人把代码贴给 LLM 问“安不安全”，LLM 回答“安全”，开发者就真的信了。可事实上，LLM 只是根据对话的语气和措辞生成了一段听起来合理的文本，它没有运行代码，没有追踪数据流，更没有任何系统上下文。把 LLM 的“安全结论”当作评审依据，等于在问一个只读过后记摘要的人要不要给这栋楼发验收合格证。

2. 为什么“不要犯错”的指令会失效：安全约束在概率编排里的真实处境

理解了上面四种形态，再来看标题里的问题：为什么我们反复告诉 LLM“不要犯错”“要写安全代码”，它还是照样犯错。这就要从 LLM 的工作原理说起。

2.1 安全指令是提示词里最容易被稀释的部分

LLM 生成代码的过程，本质上是在做逐 token 的概率采样。它训练数据里见过的“正常业务代码”有亿万次，而“安全边界处理代码”的出现频率可能只有前者的百分之一。当你把“请确保代码安全”写进提示词，这句话确实会成为生成主题的一部分，但在真正生成每一行代码的时候，模型内部的高频模式会持续占据主导地位。

我做过一个简单对比测试：同一段需求，不加安全说明和加安全说明，生成结果的漏洞数量没有显著性差异。这不是说安全提示完全没用，而是说它的约束力比大多数开发者想象中弱得多。就像一个读了一辈子武侠小说的人，你告诉他“不要用剑”，他写到决斗场景时还是会让角色下意识地摸剑——那是他脑子里最根深蒂固的文本模式，一句提示词根本压不住。

2.2 自洽优先于正确：锚定效应如何带偏模型的“安全评估”

人的判断会被第一印象锚定，LLM 也一样。在对话里，先出现的措辞会强烈影响后续生成的内容方向。如果你先说“这段代码性能可能有问题”，LLM 会给你找出一堆性能问题；如果你先说“这段代码可能不安全”，它就会顺着找出几个安全问题。问题在于，它找出的问题是按“文本相关性”排序的，不是按“真实风险优先级”排序的。

这就造成了一个很尴尬的局面：开发者以为 LLM 是安全评审，其实它只是在配合你的怀疑方向写小作文。更糟的是，如果 LLM 给出“看起来安全”的结论，开发者会下意识地减少自查；如果给出“有漏洞”的结论，开发者又会只修 LLM 提到的那几处，忽略真正关键的隐患。无论哪种情况，LLM 都在输出一种“自信的盲区”。

2.3 已犯过的错误不会“遗传修正”，只会“平行迁移”

有些人觉得，只要在发现 LLM 写的代码有漏洞后，告诉它“下次别这么做”，它就会记住。实测下来，这个方法基本无效。我告诉过模型“不要再用os.path.join拼接用户输入路径”，它下一次生成时确实没有再拼接路径，但它开始用open(filename)直接读取——同一个漏洞换了件马甲又回来了。

安全是一个系统属性，它不是某一行代码的问题，而是整个数据流、信任边界、错误处理共同作用的结果。LLM 没有运行上下文，它只是在生成一段看起来合理的文本。当你修正了一个点，它会在另一个完全没有被警示过的地方引入新问题。尤其当你把任务交给一个 autonomous agent，让它在多步循环里自己调用工具修改代码时，每一步新决策都在扩大新的假设空间——相当于每轮都把安全边界重画了一遍。把安全交给一个概率系统，本质上就是把安全交给运气。

3. 三道确定性闸门：把安全要求从“愿望”变成“结构”

既然“提示词层面的愿望”靠不住，那什么能靠得住？我的答案是：把安全要求搬出概率世界，放进确定性系统。别指望模型“自觉”，要让它根本没有机会犯某些错误。下面这三道闸门是我在多个项目里跑下来的实际配置，每一步都是可以直接落地的。

3.1 第一道闸门：规划先行，把“生成代码”拆成“先生成设计”

大多数人在用 LLM 写代码时，都是丢一句“帮我实现一个 XX 功能”，然后等它吐出一大段完整代码。这是最容易触发整段幻觉的方式。我现在的做法是强制分两阶段：第一阶段，只让 LLM 输出步骤列表，比如“1. 输入校验；2. 权限校验；3. 安全调用；4. 错误处理”；第二阶段，等我把步骤确认后，再要求它按步骤逐段编码。

分段生成能显著压缩整段幻觉的空间。原因在于，一个很大的 token 序列里，模型很难全程保持语义一致；但切成小段后，每一段的生成都更可控。我在实测中发现，分段生成后的代码，明显漏洞率下降很多，尤其是那种“整段代码看起来合理但整体逻辑有问题”的情况，基本可以杜绝。这不费时间，只是改变了工作流习惯。

3.2 第二道闸门：安全 API 白名单与黑名单

第二道闸门更硬核一些：在代码库里维护一份安全 API 白名单，LLM 生成代码时只允许使用白名单里的函数和类。我把常用的规则整理成了表格，放到团队的代码规范里：

这张表要同时写进两处：一处是代码库根目录的SECURITY.md，另一处是 LLM 的提示词。我一般会直接把它贴进系统提示词，让模型在生成前看到这份约束。但要记住，白名单规则如果只是写在文档里，那就只是一句空话；它必须和第三道闸门联动，才能真正生效。

3.3 第三道闸门：静态分析，让机器替模型“长记性”

这是最重要的一道闸门：任何 LLM 生成的代码，在合并到主分支之前，必须通过静态分析工具的检查。我目前的生产组合是这三件套：

• bandit：Python 的安全 linter，覆盖常见的注入、路径穿越、不安全的反序列化等问题。
• semgrep：多语言规则扫描，支持自定义规则，非常适合把我们团队的白名单禁令变成自动检查项。
• gitleaks：专门扫密钥，能在代码里发现疑似 AWS Key、GitHub Token、数据库密码等敏感信息。

CI 里的配置大概长这样：

- run: pip install bandit gitleaks - run: bandit -r app/ -q - run: semgrep --config=security_rules.yml - run: gitleaks detect --no-banner

为什么静态分析工具能弥补 LLM 的短板？因为它们是确定性系统，不会“以为”，不会“顺着你的话说”，只要模式匹配到就报警。它们不会产生幻觉，不存在被对话节奏带偏的问题。安全审查是唯一一个我觉得“理直气壮拒绝 LLM 自评”的领域——因为这里要的不是语言上的自信，而是规则上的确定。

3.4 别忘了：模型生成的补丁同样需要审查

还有一个很隐蔽的盲区。在使用 AI 辅助编辑器的时候，模型往往只修改十几行代码，diff 很小。很多团队的流程是“diff 小就直接合”，这恰恰是漏洞温床。模型在小窗口里看不到整个系统，它可能为了修复一个 XSS 加了输出转义，却在存储端引入双重编码问题；也可能为了修一个越权漏洞，把权限校验写错了层。我自己见过太多类似的事故了，所以现在团队里有一条硬性约定：不管 diff 大小，只要是 LLM 生成的补丁，必须走和整段代码一样的静态分析流程，绝不允许因为改动少就跳过扫描。

4. 密钥泄露：LLM 时代最该被写进教科书的一条泄漏链

聊完通用型安全问题，我想单独花一章讲密钥泄露。原因是这个话题在 LLM 工作流里已经不只是“代码问题”了，它直接升级成了数据治理问题。很多人问我怎么防止 LLM 生成代码时把密钥带出来，我的回答是：先别管生成端，先管输入侧。

4.1 提示词即泄漏面

最隐蔽的密钥泄露方式不是代码，是提示词。我见过好多开发者为了定位一个配置错误，直接把.env文件内容原封不动粘贴给 LLM，说“帮我看看这个配置哪里有问题”。这一瞬间，密钥就已经离开你的控制范围了。大型模型的厂商通常会明文存储对话用于质量审计，即使不存储，“提问即暴露”这个事实也是不可逆的。

不管你是用 OpenAI、Claude 还是 DeepSeek 这类国产模型，只要把含密钥的内容粘贴进对话，泄漏面就成立了；模型选型改变不了这个事实，只有工具链能挡住它。我在团队里立了一条铁律：任何包含真实密钥、Token、内网地址、生产库连接串的文件内容，一律禁止进提示词。如果真的要排查配置问题，先把密钥替换成占位符，或者让模型看脱敏后的版本。

4.2 循环污染：逻辑代码里“复读”出的密钥

密钥泄露还有一条更隐蔽的链路，我称之为循环污染。某个团队曾经把含 AWS Access Key 的历史提交推到公开仓库，后来虽然删掉了，但那段数据已经被训练语料收录。再后来，团队里有位同事用 LLM 生成一个“云存储配置示例”，模型自动补全了一组形似 AWS 密钥的字符串——看起来像占位符，实际是在训练数据里“复读”出来的真实密钥模式。

这个案例说明一件事：删除提交根本来不及，训练数据已经把密钥“记住”了。密钥一旦进入过公开或半公开的传播渠道，最有效的处置方式不是清理历史，而是立刻在服务商侧轮换密钥。不要抱侥幸心理，觉得“应该没人扫到过”——市面上专门扫描公开仓库密钥的工具多的是，速度和覆盖范围都超乎想象。轮换密钥的成本要比事后的数据泄露应急低一个数量级。

4.3 自动化的密钥治理闭环

现在我们团队跑通的密钥治理闭环大概是这样：

• 本地开发：一律用.env，且必须通过.gitignore排除，杜绝本地文件顺手提交。
• CI 检查：每次提交自动跑gitleaks扫描 commit history，不只看当前 HEAD，也检测历史提交记录，因为历史提交一旦带着密钥进过仓库，就相当于广泛传播过了。
• 远端轮换：一旦检测到疑似真实密钥，立刻在云服务商侧调用密钥轮换 API，同时吊销旧密钥，不等人工介入。
• 提示词规则：任何 LLM 交互界面里，都禁止粘贴真实敏感信息，统一用脱敏样本或占位符替代。

这套闭环跑下来之后，我们团队没有再出现过一次真正的密钥泄露事故。我不确定是扫描工具起了作用，还是“禁止粘贴真实密钥进提示词”这条铁律起了作用，但大概率两者都有。关键点在于，别把防密钥泄露当成开发者的个人自觉问题，而是把它变成一条自动化流水线。

5. 一个真实任务的安全改写全程：从危险实现到安全实现

前面讲了这么多理论和工具，我拿一个真实任务来串一遍，你会更直观地看到“不安全版本”和“安全版本”之间的差距，以及每一步改造在做什么。

5.1 第一次生成：看起来很正常的危险代码

任务很简单：写一个文件上传预览接口，接收文件名和内容，把文件保存到上传目录。LLM 第一次生成的代码大概是这样：

def upload_preview(filename, content): path = os.path.join(UPLOAD_DIR, filename) with open(path, "w") as f: f.write(content) return path

这段代码表面上看完全正常。但它同时踩了三个雷：路径穿越（filename=../../etc/cron.d/evil会写到目录外）、文件类型不受限（可以上传任意可执行文件）、没有大小限制（可以撑爆磁盘）。更有意思的是，如果你把这段代码直接贴给某个 LLM 问“安全吗”，它大概率会说“安全”。

5.2 逐项改造：从替换危险调用到补充边界

第一步，先用安全 API 白名单替换危险调用：文件路径不允许直接用拼接逻辑，必须用resolve()做规范化，并校验目标路径是否在指定目录之内。第二步，要求模型先输出安全设计再编码，它会自动意识到需要文件类型白名单和大小限制。第三步，用semgrep跑自定义规则扫描，通常会提示“文件名未验证字符集”，第四步再补上 Unicode 混淆字符的过滤。

最终版本长这样：

def upload_preview(filename, content): if not filename.isascii(): raise ValueError("invalid filename") base = Path(UPLOAD_DIR).resolve() target = (base / filename).resolve() if not target.is_relative_to(base): raise PermissionError("path traversal") ALLOWED_EXT = {".txt", ".md", ".pdf"} if Path(filename).suffix not in ALLOWED_EXT: raise ValueError("file type not allowed") if len(content) > MAX_LIMIT: raise ValueError("file too large") target.write_text(content, encoding="utf-8") return str(target)

每一步改造都在回答一个问题：这条数据流里，用户的输入有没有机会触碰到安全边界？LLM 不会主动想这个问题，所以我们必须替它把问题拆开、钉死。

5.3 与 LLM 协作的安全提示词模板

如果你不想像我这样手把手改代码，也可以一开始就给 LLM 一个比较硬核的提示词模板。我常用的模板大概是这样的：

任务：实现 upload_preview 函数。 约束条件（请先逐条复述，再编码）： - 不使用 os.system、requests、eval、exec - 文件路径必须校验并限制在指定目录内 - 文件类型用白名单限制 - 上传大小必须显式限制 - 不要吞掉任何异常，安全相关的异常必须向上抛出 - 所有常量必须通过参数传入，禁止硬编码任何密钥

有一个小技巧是：让 LLM 先逐条复述一遍约束条件，再开始写代码。这个动作会提高约束条件在生成时的权重，因为复述的过程等于把安全要求放进了最近的上下文里。但请注意，这句“提高权重”不等于“完全遵守”，它只是第一道闸门的辅助手段。真正决定安全的是后面那几道确定性的检查，提示词永远只是让 LLM“走在更安全的概率分布上”，而不是“保证安全”。

6. 把安全防线固化进工作流：一份可以直接抄的清单

文章的最后，我把自己在工作流里沉淀下来的东西整理成了一份可以直接抄的清单和机制。它不是理论，是每天都会用到的东西。

6.1 提交前自查清单

每次合入 LLM 生成的代码前，我会带着这些问题过一遍：

• 这个函数允许用户输入进来吗？我是否验证了它的类型、长度、字符集？
• 有没有在不该出现的地方用了eval、exec、os.system、拼接 SQL？
• 路径操作是否做了规范化，并限制在明确指定的目录内？
• 异常处理里有没有把安全相关的错误吞掉？except Exception分支返回了什么？
• 代码、注释、日志、README 里有没有出现任何疑似密钥或内网地址？
• 依赖的版本号是否能在官方源确认存在，且没有已知 CVE？
• 权限校验是放在数据入口处，还是散落在中间逻辑里？
• 文件写入有没有大小限制？上传的文件有没有类型白名单？
• 模型生成的函数，它的权限边界是否小于等于实际需求？

这九个问题不是要让你每次逐字回答，而是帮你建立一个节奏：看到 LLM 代码的第一反应，不是“这个功能对不对”，而是“这个功能的安全边界在哪里”。

6.2 最小权限原则：模型生成的函数不该拥有更大的权力

我自己的经验里有一条最重要的体会：给 LLM 的任务描述越模糊，它生成的代码权限边界就越宽。比如你只说“写一个读取用户信息的函数”，它可能顺手加了管理员查询逻辑；你说“写一个上传文件预览”，它可能直接让你传.exe。所以，每次让 LLM 生成代码时，我会刻意在提示词里写明这个函数“能做哪些事、不能做哪些事”。

最小权限原则在 AI 辅助编程里的实际意义是：不能因为模型生成了一个函数，就给它一个比需求更大的权限边界。如果它生成的是一个只需要读取的函数，就不该有写入逻辑；如果它处理的是公开数据，就不该引入管理员权限校验分支。把需求边界收窄，模型能犯的错误空间也会同步收窄。

6.3 团队协作配置：用 SECURITY.md 固化规范

最后是团队层面的机制。我们团队在代码仓库根目录维护了一份SECURITY.md，内容包含前面说的安全 API 白名单、禁止模式列表、扫描工具与阈值、LLM 生成代码的审查流程。它既是一份规范，也是新成员入职时最高优先级要读的文件。

我还做了一件事：把团队遇到过的 LLM 安全事故沉淀成一个“LLM 安全规则 wiki”，每条事故记录都写清楚“模型怎么犯的错、工具怎么拦住的、规则需要怎么改”。这个 wiki 比收藏一堆提示词模板有用得多——因为它记录的是真实发生的边界，而不是想象出来的边界。现在团队里谁在 PR 描述里标注了“LLM 生成 + 已过扫描”，评审的人心里就有底；没标的，默认按最高风险代码处理，一步步过六.1 清单。

我自己最深的感受是，LLM 是这个世界从来没有过的工具：它既能高效地写出功能代码，又能自信地把安全隐患伪装成常规代码。它不是一个“会犯错但可以教育的实习生”，更像一台随时可以生成代码但完全不保证安全的无限灵感机。“不要犯错”这句话从提示词里删掉吧，因为它在模型眼里只是一串没有权重的文本。真正有用的，是用工具、流程、权限和人工评审，组成一个不依赖模型自律的安全网。我自己的习惯是，每个月把团队这一个月的 LLM 生成代码样本抽出来，让安全工具全量扫一遍，统计漏洞类别。这个习惯坚持了半年后，我对“模型的能力边界”有了直觉：模型擅长的是搭出功能骨架，我们负责的是往骨架上钉安全护栏。最后再分享一个小技巧：每次让 LLM 写代码前，先把自己仓库里出过安全事故的失败案例喂给它，让它先列一遍风险清单——但这只是让它在生成时更警惕，绝对不能替代扫描。