LLM生成Python代码审计实战：步进执行与依赖核查

如果你最近在用大模型辅助写 Python 代码，大概率遇到过这样的场景：模型几秒钟生成一个完整的模块，跑通主流程只花了几分钟，但真正把代码合入项目前，你却开始犹豫——这段代码真的对吗？依赖是真的存在吗？异常处理是故意留空，还是模型压根没想到？安全边界有没有被突破？

这其实是 LLM 辅助开发的普遍困境：生成速度不再是瓶颈，代码审计才是。模型输出的代码是概率采样的结果，不是形式化推导的结果，它可以语法正确、风格规整，但在依赖真实性、错误恢复、权限控制等关键维度上，依然可能错得“很有自信”。所以，一个能快速步进执行并审计 LLM 生成 Python 代码库的工具，正在从“可选优化”变成“工程刚需”。

这篇文章会从真实的审计痛点出发，拆解这类工具应该具备的核心能力，然后给你一套可以直接落地的审计方法论：从环境准备、静态扫描、依赖核查到步进执行和测试验证，全部用可复制的代码和命令演示。读完你会知道，审核 LLM 代码不能只靠肉眼读，也不该完全信任自动工具，正确姿势是“工具做客观检查，人做价值判断”。

1. 这篇文章真正要解决的问题

先给结论：LLM 生成的 Python 代码，最大的风险不是语法错误，而是“看起来合理但不可信”。

语法错误在运行第一秒就会暴露，IDE 也能直接标红。真正消耗时间的是另一类问题：

• 代码 import 了一个不存在的第三方库，或者版本要求冲突；
• 模型“幻觉”出一个 API，比如调用了某个库根本不存在的函数；
• 异常处理写得完整，但所有分支都只是pass，失败时静默吞掉错误；
• 把 API Key、数据库连接串直接写进代码常量，方便测试但留下泄密口子；
• 功能逻辑能跑通，但边界条件、并发安全、资源释放完全没考虑；
• 测试用例写了一大堆，却只覆盖了理想路径，等于白写。

这些问题，传统的人工 Code Review 可以发现，但效率太低；传统的静态扫描工具可以发现一部分，但很难覆盖业务语义和调用链行为。于是，一个新的工具方向出现了：把“步进执行”和“审计”结合，让工具像调试器一样走进代码运行过程，同时按审计规则逐项检查。这就是标题里 “step through and audit” 的含义。

谁最需要这类能力？

• 用 Copilot、ChatGPT、Claude 等工具批量生成代码的个人开发者；
• 团队里引入 AI 编码助手后，负责代码评审的技术骨干；
• 需要评估 LLM 生成代码质量的平台开发者；
• 任何“生成代码速度 >> 审查代码速度”的团队。

如果你正被“AI 写代码一时爽，Review 火葬场”困扰，这篇文章适合你。

2. LLM 生成 Python 代码的典型问题与审计难点

2.1 依赖幻觉与版本漂移

LLM 在生成代码时，会从训练数据中学习常见的 import 写法，但它不会实时查证某个包是否存在、某个版本是否兼容。我见过最典型的案例：模型生成了一段使用pip install some-package的代码，但some-package在 PyPI 上根本不存在，或者是同名但用途完全不同的另一个项目。

这种问题在人工 Review 时容易漏掉，因为代码看起来非常自然——import、函数调用、参数传递都符合惯例，唯独包名经不起验证。

审计要点：

• 所有第三方依赖必须能在 PyPI 或私有源中解析到；
• 锁定版本范围，避免>=裸奔导致环境漂移；
• 生成代码前，先让模型列出它假设的依赖清单，再交叉验证。

2.2 API 幻觉与“自信的谎言”

大模型生成代码时，如果训练数据中某个函数名出现频率足够高，它就倾向于“编造”一个合理但错误的使用方式。比如把json.dumps的ensure_ascii写成encoding，或者调用一个根本不存在的requests.get_async。

更隐蔽的是，有些模型会把不同库的 API 混在一起。例如把pandas的read_csv参数和csv模块的参数混用。单独的静态检查可能发现不了，因为函数名存在，但参数校验要运行到那一行才会报错。

审计要点：

• 对关键 API 调用，要做“参数名 + 参数类型 + 返回值”的契约校验；
• 优先用有类型标注和文档字符串的代码生成，降低 API 幻觉概率；
• 通过步进执行，让代码实际跑过每个分支，而不是只做静态检查。

2.3 错误处理的形式化

这是 LLM 生成代码里最隐蔽的坑。模型知道“好代码要有异常处理”，所以会生成 try/except 结构，但 except 块里常常是pass或print，等于把错误信息直接丢掉。在生产环境里，这种代码会让系统在异常状态下继续运行，数据损坏了都不知道。

审计要点：

• 禁止裸except: pass，至少要有错误上下文记录；
• 区分“预期异常”和“非预期异常”，非预期异常要上抛或触发告警；
• 检查资源释放逻辑，文件、连接、锁是否在异常路径下正常释放。

2.4 安全边界缺失

LLM 本身不做安全判断，它只会模仿训练数据中的代码模式。如果训练数据里很多代码是“为了快速演示”写的，那么模型生成的生产代码也可能带着：

• 硬编码的密钥、Token、数据库密码；
• 关闭了 TLS 验证的 HTTPS 请求；
• 存在 SQL 注入风险的字符串拼接查询；
• 直接对用户输入执行eval()或exec()；
• Debug 模式默认开启，甚至暴露在公网端口。

安全审计不能靠“肉眼印象”，必须用规则和工具辅助扫描。

2.5 测试缺失与“测试幻觉”

更麻烦的是，LLM 也会生成测试代码，而且这些测试往往和被测代码共享同一个“错误的世界观”。模型实现了一个错误的业务逻辑，然后写了测试来验证这个错误逻辑，测试全部通过，反而给了开发者虚假的信心。

审计要点：

• 测试用例要由人类理解业务需求后补充，不能只信任模型生成的测试；
• 使用覆盖率工具检查分支覆盖，尤其是异常分支和边界分支；
• 对关键业务逻辑，建议采用“契约测试”思路，先定义输入输出约束，再验证实现。

3. 审计工具的核心设计思路：从“读代码”到“跑代码”

传统代码审计是“人读代码 + 静态工具扫描”。对 LLM 生成代码来说，这远远不够，因为模型最大的问题恰恰是“语义正确性”。于是，“快速步进执行 + 审计”这一思路成为关键。

3.1 核心模块拆解

一个合适的审计工具，通常由五个模块组成：

3.2 “步进执行”为什么比“静态扫描”更适合审计 LLM 代码

静态扫描适合发现“已知的坏味道”：危险函数、硬编码密码、过度复杂的函数。但它发现不了“一个不存在的 API 直到运行时才崩溃”，也发现不了“一个参数语义理解错误但恰好在当前输入下能工作”的隐含问题。

步进执行则相反，它让代码真正跑起来，在运行时校验函数是否存在、参数是否合法、返回值是否符合预期。这种“动态验证”和 LLM 生成代码的特点非常匹配：

• LLM 代码往往没有全局设计约束，但局部行为可以通过执行验证；
• 错误通常发生在具体调用点，运行到那里就会暴露；
• 步进执行可以结合断言，把“隐式行为”变成“显式检查”。

当然，步进执行也有代价：需要构造输入、需要处理外部依赖（数据库、网络、文件系统）、需要处理无限循环风险。所以，完整方案是“静态扫描快速筛查 + 步进执行精准验证 + 人工判断业务语义”。

3.3 流水线设计

实际使用中，审计工具应该是一条流水线，而不是单个命令：

原始 LLM 代码 -> 依赖核查 -> AST 静态扫描 -> 调用链追踪 -> 步进执行 -> 行为验证 -> 审计报告

每一阶段如果发现严重问题，都可以提前终止，避免浪费时间运行不可靠的代码。审计报告需要标注问题等级、文件位置、原因和建议修复方式，而不仅仅是“有问题”三个字。

4. 环境准备与前置条件

下面进入实操环节。为了保证审计过程可重复、可复现，建议使用隔离的 Python 环境。这里不会绑定某个具体工具，而是演示一套你可以直接复用到自己项目里的审计流程。

4.1 操作系统与 Python 版本

• 操作系统：macOS / Linux / Windows 均可，示例命令以 bash 为主，Windows 用户可将命令对应调整为 PowerShell 或使用 Git Bash。
• Python：建议 3.10 及以上，版本请以项目实际为准，本文重点演示通用思路。
• 包管理：推荐使用venv+pip，复杂项目可使用poetry或uv。

4.2 推荐安装的工具

以下工具都是 Python 社区主流且真实存在的，可以作为审计工具链的基础组件：

安装命令：

python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install --upgrade pip pip install ruff bandit pip-audit pytest coverage

注意：这些工具版本更新很快，建议以官方最新稳定版为准。安装完成后，先执行ruff --version、bandit --version确认可用。

4.3 项目结构建议

为了便于审计，把 LLM 生成的代码放在独立目录，并配好标准项目结构：

llm_generated_project/ ├── app/ │ ├── __init__.py │ ├── main.py │ └── utils.py ├── tests/ │ └── test_main.py ├── requirements.txt ├── pyproject.toml └── README.md

固定结构的好处是：审计工具可以基于约定路径扫描，不用每次做一堆配置。

5. 完整示例：搭建一个可复用的 LLM 代码审计流程

为了让流程可落地，下面用一组示例代码演示如何对 LLM 生成的 Python 项目做审计。这里会构造一段“典型 LLM 生成风格”的代码，其中包含若干常见问题，然后演示审计工具如何识别。

5.1 示例目标代码

# 文件路径：app/main.py import requests import pandas as pd import os def fetch_data(api_url: str): response = requests.get(api_url) return response.json() def process_data(df): df["total"] = df["price"] * df["quantity"] return df def load_config(): api_key = "sk-1234567890abcdef" return {"api_key": api_key} def run_pipeline(api_url: str, data_path: str): try: raw_data = fetch_data(api_url) df = pd.DataFrame(raw_data) df = process_data(df) df.to_csv(data_path, index=False) except Exception as e: print(f"Error: {e}") if __name__ == "__main__": run_pipeline("https://api.example.com/orders", "orders.csv")

这段代码包含了多个需要审计的问题：

1. api_key硬编码；
2. except Exception后只打印错误，缺少日志与回滚；
3. process_data对price、quantity列没有存在性校验；
4. 没有对requests.get设置超时，可能长时间阻塞；
5. df.to_csv使用相对路径，运行目录不同会产生副作用。

光用肉眼可能能看出部分问题，但我们可以用工具链快速、可重复地发现它们。

5.2 第一步：依赖核查

先生成依赖清单：

pip freeze > requirements.txt

然后用pip-audit检查依赖漏洞：

pip-audit

预期输出类似：

No known vulnerabilities found

如果发现漏洞，它会列出受影响的包和修复版本。这一步解决的是“模型引用的依赖本身是否可信”的问题。除了漏洞扫描，还要主动验证依赖是否真实存在：

python -c "import requests, pandas; print(requests.__version__, pandas.__version__)"

如果某个包不存在，import 会立刻抛出ModuleNotFoundError，省去后续大量无效审计时间。

5.3 第二步：静态规则扫描（ruff + bandit）

先用ruff做常规检查：

ruff check app/

对于上面这段示例代码，ruff可能提示未使用的osimport、行过长等问题。这些都是浅层问题，但值得先修掉，保持代码整洁。

真正重要的是bandit的安全扫描：

bandit -r app/ -f txt

在示例代码中，bandit大概率会发现：

Issue: [B105:hardcoded_password_string] Possible hardcoded password: 'sk-1234567890abcdef' Severity: Medium Confidence: Medium Location: app/main.py:11

这就直接把硬编码密钥问题抓出来了。第 11 行的api_key = "sk-1234567890abcdef"正是 LLM 生成代码里常见的安全隐患。

此外，bandit还会检查eval、exec、subprocess等危险调用。对 LLM 生成代码来说，这类检查必须做，因为模型很容易“顺手”写出不安全的模式。

5.4 第三步：步进执行与调用链追踪

静态扫描解决“有什么问题”，步进执行解决“真正跑起来会发生什么”。Python 标准库的trace模块可以追踪每一行代码的执行情况：

python -m trace --count --file trace_report.txt app/main.py

执行后，trace_report.txt会记录每一行代码被执行的次数。如果某一行显示>>>>，说明它从未被覆盖到。例如，在示例代码中，except Exception分支如果没触发，它的子块就不会出现执行计数。这能直观暴露出“测试只覆盖理想路径”的问题。

如果需要交互式步进调试，可以使用pdb：

python -m pdb app/main.py

在pdb提示符下输入n执行下一行，输入p打印变量值，输入c继续执行，输入q退出。调试 LLM 生成代码时，重点关注：

• 外部 API 返回的数据结构是否和pd.DataFrame(raw_data)匹配；
• 处理过程中是否出现 NaN 或类型不一致；
• 异常分支是否真的进入过。

5.5 第四步：行为验证（pytest + coverage）

上面的步骤是“发现问题”，下面需要“验证正确行为”。针对示例代码，写一个最小测试用例：

# 文件路径：tests/test_app.py import pandas as pd from app.main import process_data def test_process_data_calculates_total(): df = pd.DataFrame([ {"price": 10, "quantity": 2}, {"price": 5, "quantity": 4}, ]) result = process_data(df) assert result["total"].tolist() == [20, 20]

运行测试并查看覆盖率：

pytest --cov=app tests/

预期输出：

Name Stmts Miss Cover --------------------------------- app/main.py 15 7 53% --------------------------------- TOTAL 15 7 53%

53% 的覆盖率说明大量代码行未被测试，尤其是异常分支和配置加载分支。对于一个 LLM 生成的模块，这种覆盖率是危险的——等于把错误处理、边界逻辑留在了未验证状态。

5.6 生成审计报告

把上述工具的输出汇总成一份简明报告，记录问题等级、位置、原因和修复建议。这里给出一份参考格式：

# LLM 代码审计报告 ## 高危 - B105: 硬编码 API Key - 位置：app/main.py:11 - 建议：使用环境变量注入，禁止提交到版本库 ## 中危 - 异常处理过于宽泛 - 位置：app/main.py:19 - 建议：区分预期异常（requests 超时）与非预期异常，记录日志并向上抛出 - requests.get 未设置超时 - 位置：app/main.py:5 - 建议：添加 timeout 参数，例如 `timeout=5` ## 低危 - 未使用 import os - 位置：app/main.py:3 - 建议：删除

报告越结构化，后续人工 Review 的负担越小。

6. 运行结果与效果验证

6.1 验证方式

每执行完一个工具，都应该有明确的验证标准：

6.2 判断成功的标准

审计成功的标准不是“所有工具零告警”，因为零告警不代表业务语义正确。真正可靠的判断标准是：

1. 依赖树中的所有包都可解析、无已知高危漏洞；
2. 安全扫描没有硬编码密钥、危险反序列化、命令注入等风险；
3. 步进执行覆盖了主流程和关键异常分支，没有在运行时出现 API 参数不匹配；
4. 针对业务核心逻辑的测试全部通过，且覆盖率达标；
5. 人工对着审计报告逐项确认，每一条都能给出“接受风险”或“修复”的决定。

如果第一步执行就发现依赖不存在，立刻返回“依赖不可信”，不要浪费时间继续步进执行。

6.3 失败排查起点

如果工具执行失败，按顺序检查：

1. 当前 Python 环境是否激活：which python；
2. 依赖是否安装完整：pip list | grep <package>；
3. 代码路径是否写错：pwd确认当前目录；
4. 审计工具版本是否过旧：pip install --upgrade <tool>。

7. 常见问题与排查方法

8. 最佳实践与工程建议

8.1 把审计嵌入 CI/CD，而不是等合入前再做

一个常见的错误是：开发者本地用 LLM 生成代码，跑通后直接提交 PR，然后在 Review 阶段才开始审计。此时大量问题已经混入 diff，审查者容易视觉疲劳。

更合理的做法是：在 CI 流水线中增加一个ai-code-audit任务，对新增或变更的 Python 文件自动执行依赖核查、静态扫描、基础测试。一旦代码提交，工具先自动筛查一遍，人工再关注剩余问题。这样既能拦截明显问题，也能让人把精力放在业务判断上。

8.2 给 LLM 下“约束性提示词”

审计不是只能事后补救，还可以从源头减少问题。在使用 LLM 生成代码时，要求它遵守约束：

你是一名资深 Python 工程师。生成代码时请遵守： 1. 每个第三方依赖必须在 requirements.txt 中声明，且是真实存在的包； 2. 禁止硬编码密钥，统一通过环境变量读取； 3. 所有异常处理需要记录日志并考虑回滚，禁止裸 `except: pass`； 4. 对网络请求必须设置 timeout； 5. 关键业务函数需要类型标注、docstring 和最小测试用例； 6. 生成完成后，列出你认为可能存在风险的地方。

这种提示词不能保证模型 100% 遵守，但可以显著降低“依赖幻觉”和“错误处理缺失”的概率。审计工具依然是刚需，但提示词约束能让后续审计轻松不少。

8.3 对审计结果分级，避免“一刀切”

LLM 生成代码的审计结果要分级处理：

• 高危问题（硬编码密钥、命令注入、危险反序列化）：必须修复才允许合入；
• 中危问题（异常处理过于宽泛、无超时、缺乏资源释放）：原则上应修复，如果暂不修复，需要技术负责人明确记录风险接受理由；
• 低危问题（代码风格、未使用 import）：自动修复或批量清理即可。

8.4 使用 mock 外部依赖，避免审计时触发真实副作用

步进执行时，如果代码会调用外部 API、写数据库或发邮件，务必先用 mock 替换外部依赖。审计的目标是验证代码逻辑，而不是真的产生业务影响。一个安全的做法：

# 文件路径：tests/conftest.py import pytest import requests @pytest.fixture def mock_requests_get(monkeypatch): def fake_get(url, **kwargs): class FakeResponse: def json(self): return [{"price": 1, "quantity": 2}] return FakeResponse() monkeypatch.setattr(requests, "get", fake_get)

这样在验证数据流转时，不会向真实服务发起请求。

8.5 保留人工 Review 环节

工具链可以发现“技术性错误”，但“业务语义是否匹配需求”只有人才能判断。LLM 可能生成一段技术上完全正确但业务上跑偏的代码，这不是任何 linter 能解决的。所以，最佳实践是“工具做客观检查，人做价值判断”。建议团队内部明确：LLM 生成代码的 PR，必须至少有一个对业务足够熟悉的人参与 Review。

8.6 记录审计结果，建立“模型错误模式”知识库

在实际使用中，把每次发现的 LLM 生成代码问题归类记录。时间久了，你会总结出自己使用的模型最常犯的错误类型。例如：某个模型特别容易在日期时间处理上出错，另一个模型容易在异步代码上误用同步库。有了这个知识库，下次提示词里就可以针对性加强约束，审计工具也可以增加定制规则。

9. 总结与后续学习方向

这篇文章不是让你去迷信某个现成的审计工具，而是提供一套适用于 LLM 生成 Python 代码的审计方法论：依赖核查、静态扫描、步进执行、行为验证、人工确认，五步形成闭环。

核心观点是：LLM 生成代码最大的风险不在“能不能跑”，而在“是否值得信任”。语法错误是显性的，几秒钟就能暴露；而依赖幻觉、API 误用、异常处理缺失、安全边界突破是隐性的，只有通过系统化审计流程才能有效拦截。

如果你正在做 AI 辅助开发的落地，下一步可以这样实践：

1. 把你现在最常用的 LLM 生成代码方式整理成规范，配上约束性提示词；
2. 搭一套最小审计流水线（venv + ruff + bandit + pip-audit + pytest + coverage），从新项目开始跑；
3. 每次审计完记录问题类型，建立自己团队的“LLM 代码错误模式库”。

工具的意义不是替代人，而是把大量重复、可自动化的检查从人身上卸下来。真正稳定可靠的代码，永远是“生成速度快”和“审计严谨度高”共同作用的结果。