LLM生成的Python代码库如何审计？快速逐步审计工作流解析

早些时候，我第一次接触一个由 LLM 生成的 Python 代码库：目录结构完整，接口封装规范，日志系统也搭好了，第一次运行甚至能正常输出结果。但当我试图向同事解释一个函数为什么在异常情况下会返回一个“看起来很合理”的默认值时，我在代码里找不到能支撑这个行为的逻辑链路。那个瞬间让我意识到，传统代码审查方法套在这种代码库上会失效。LLM 生成的代码最大的问题不是质量差，而是缺少人工代码里的可解释性：你能看到每个文件写了什么，却很难快速说清它为什么要这么组织，以及下一步会触发什么。

这就是“快速逐步审计 LLM 生成的 Python 代码库”这类工具真正要解决的问题。它不只是跑一遍静态扫描，而是一种工作流：把代码库拆成入口、调用链、数据流和异常分支，然后一步一眼地复查，让审计者不用通读整个项目，也能建立起对代码的信任。

我一开始也以为这是个“多写点测试就行”的问题。后来发现不是。单次跑通只能说明流程没有断，不能说明代码在真实输入、外部依赖异常、并发调度和长期维护时仍然可靠。真正需要的是把“我可以运行它”转换成“我理解它，并且能判断它是否适合进生产环境”。下面我想从审计思路、工作流、常见风险和落地路径四个层面，把这个题目拆开聊。

1. 为什么 LLM 生成的代码库需要“逐步审计”，而不是整体审查

1.1 生成代码与人工代码最大的差异，不是质量，而是可解释性

传统代码审查是围绕人写的代码设计的。人写代码时有意图，有上下文，有 git 记录，有 PR 描述，甚至当面问一句就能搞清楚“这里为什么这么写”。代码质量好不好是一回事，但它的演化过程是可以在仓库里追溯的。LLM 生成代码不一样，尤其是当你用一个 Agent 或者一次性生成得到一个完整目录时，它更像是模型基于训练分布产出的“最终成品”，没有决策记录，没有废弃方案，也没有作者能够解释取舍。

这带来的直接问题是：你可以在十分钟内读完一个文件里的每个函数，但依然不知道它和旁边的模块是怎么协作的。整体审查在这种情况下很容易变成“读过一遍”，而不是“理解一遍”。尤其是代码生成工具经常把 prompt 构建、模型调用、结果解析、缓存、日志散落在不同文件里，静态阅读一遍根本无法快速建立因果链。

所以，逐步审计的价值不是“看得更仔细”，而是把审计动作从“读代码”变成“跟踪代码”。它的核心判断是：你不需要理解这个代码库的每一个字节，你只需要沿着关键入口和关键调用路径，验证每一步的行为是否和预期一致。只要把核心路径上的可解释性补回来，这个代码库就能进入下一步优化和维护。

1.2 “能跑”和“可维护”之间，需要一条验证路径

LLM 生成的代码库经常带有一种迷惑性：它会把函数拆得很细，会加注释，会做防御式判断，看起来非常有工程素养。但这些表面特征并不等于可维护性。你真正需要回答的是几个更具体的问题：

• 当外部 API 返回超时或者格式变化时，这个函数会怎样表现？
• 某个关键字段如果为空，程序会走哪条分支？
• 如果批量任务中途崩溃，重跑一次会不会产生重复数据？

这些问题只靠 review 代码本身回答不了，因为它们发生在代码执行过程中。要回答，就必须让代码在一个受控环境里被“走一遍”。逐步审计本质上是把静态审查和动态执行结合，形成一条验证路径：先看入口，再看调用链，再看数据流，最后看异常分支。这样每一个关键判断点都有机会被真实输入检验，而不是只靠大脑模拟。

从工程经验看，这也是审计 LLM 代码库时最容易被忽略的一层。很多人拿到生成代码后第一件事是部署测试，第二件事是等线上出 bug，中间缺少一个“先把关键路径走一遍，把行为记录下来”的步骤。等线上出问题时，你已经很难判断是哪一段生成逻辑有问题了。

2. 先读骨架，再跟逻辑，最后验证数据

2.1 骨架导航：快速定位代码库的入口和核心模块

进入一个新生成的代码库，第一步不要读代码，而是先建立“地图”。这个地图通常包含三样东西：目录结构、模块依赖关系、外部资源依赖。对于 Python 项目，目录结构往往能透露不少信息：LLM 应用一般会有一个入口文件、一个负责 prompt 构建的模块、一个调用模型客户端的地方、一个持久化目录或数据库连接模块、以及一堆工具函数。

依赖关系可以用静态分析工具生成，比如pydeps或者 IDE 内置的依赖图。你需要关注的是：

• 哪些模块被大量引用，是整个系统的“中心”。
• 哪些模块是入口，入度低、出度高。
• 是否存在循环依赖，尤其是 A 导入 B、B 又导入 A 的情况。
• 哪些模块负责外部 I/O，比如 HTTP 请求、文件写入、数据库连接。

这些信息帮你快速判断代码库的“心脏”在哪里。很多 LLM 生成的代码看似结构匀称，但真正核心的逻辑往往集中在少数几个模块里。找到了核心模块，后续审计就不需要浪费时间在边缘工具函数上。

2.2 调用路径跟踪：从某个入口逐级下钻

有了地图之后，第二步是选择一个入口，然后沿着真实调用路径逐级下钻。入口常见的有这么几类：CLI 命令、HTTP 路由、定时任务函数、消息队列消费者。入口就是审计的起点。

逐个入口展开后，你的注意力应该放在几个关键节点上：

• 这个入口拿到的输入是什么格式？有没有做校验和清洗？
• 输入经过哪些函数转换，才最终传给模型或者外部服务？
• 每次调用是同步还是异步？有没有超时控制？
• 调用外部服务前后的异常分支是否覆盖了可能的失败模式？

这一步要解决的问题是“逻辑链路是否成立”。很多生成代码的问题并不是某个函数写错了，而是函数与函数之间的协作方式有问题：参数在传递过程中被隐式修改，异常被吞掉，返回值在不同模块被当成不同结构使用。逐级下钻正是为了抓住这些节点之间的缝隙。

2.3 数据映射：真正难审查的是上下文如何流动

代码的控制流相对容易跟踪，真正难的是数据流，尤其是“上下文”在系统中的流动。

在 LLM 项目中，数据流往往经历这样的过程：原始用户输入 → 清洗和截断 → 拼接到 prompt 模板 → 调用模型 → 解析模型输出 → 后处理 → 存储或返回。最常出问题的不是某个环节的代码，而是“上一层输出”和“下一层输入”之间的假设不一致。举例来说，模型返回的 JSON 里有一个content字段，生成代码假设它一定存在，但某些返回条件下这个字段可能被省略，直接导致下一行解析抛异常。

审计时，工具应该支持你沿着某个数据项从产生到消费的完整链路做高亮跟踪，而不是让你自己在多个文件里搜索变量名。你需要确认的是：每个数据项在传递过程中是否发生了类型变化、格式变化、空值处理和敏感信息泄露。这一步做扎实了，审计的意义才真正体现出来。

3. 一个可落地的逐步审计工作流

3.1 第一步：准备受控运行环境

在做代码级分析之前，先把环境隔离好。这一步看起来基础，但很多审计失败都源于环境不可控。比如代码在全局安装了旧版本依赖，运行时没有报错，但行为和预想不同；又比如审计过程中代码突然访问了外部服务，造成数据污染或额外费用。

最少的环境准备包括：

• 使用venv或conda创建独立虚拟环境。
• 安装依赖后，用pip freeze固定版本快照。
• 运行pip check检查依赖冲突。
• 数据库、向量库、缓存等外部服务尽量使用临时实例。
• 对需要调用付费 API 的模块，先设置 mock 或者强制使用本地模型。

不要跳过这些步骤。LLM 生成的代码在库依赖上的“隐身问题”非常常见，比如它生成了openai新版本的调用写法，但环境里装的是旧版本，甚至还有一些包在requirements.txt里根本没写全。先锁定环境，再开始审计，可以少走很多弯路。

3.2 第二步：建立从入口到关键函数的跟踪清单

接下来不要随机看代码，而是先建立一个跟踪清单。这个清单相当于审计路线图，每完成一项就标记一项。一个比较实用的清单顺序是：

1. 找到所有外部可触达的入口：HTTP 路由、CLI 命令、定时任务、队列消费者。
2. 找到核心处理函数：哪些函数处理了 prompt、调用模型、解析输出。
3. 列出所有外部依赖链：外部 HTTP/API、数据库读写、文件系统操作、环境变量读取。
4. 优先检查异常分支：每个外部调用有没有 try/except，异常分支做了什么。
5. 为每个入口准备一个“正常输入”和“极端输入”，用于后续动态验证。

这个清单不是给你增加负担，而是让审计过程可追踪。你会发现自己很快就知道哪些文件优先看，哪些函数需要进调试器，哪些模块可以先跳过。很多人在审计生成代码时效率低，不是因为代码量大，而是因为没有建立优先级。

3.3 第三步：三遍验证法，动态对照设计意图

静态跟踪完成之后，最有效的动态验证方式是“三遍验证法”。

第一遍，输入正常数据，走一遍系统主链路。注意观察：

• 响应是否符合预期。
• 代码路径是否和你从调用链判断的一致。
• 有没有走到你意料之外的分支。

第二遍，输入空值、异常值、超长值。重点观察：

• 输入校验是否存在漏洞。
• 异常分支是否真的能被触发。
• 程序是否会崩，还是返回一个含糊的 None。

第三遍，模拟外部依赖异常。比如 mock 的模型调用超时、返回空字符串、返回畸形 JSON、数据库连接失败。这一步能暴露很多隐藏问题：

• 超时后有没有重试机制。
• 返回异常结构时，解析代码能否优雅失败。
• 错误信息有没有被记录到日志中。

如果一个代码库能通过这三遍，那它至少在核心路径上是可信的，可以进入更严格的安全审查或性能测试。如果三遍中途就崩了，那也不坏，你正好发现了最需要修的问题。

注意：不要一上来就把批量数和并发数拉满，先用一条样例确认输入、输出和日志都正常，再逐步放大，这样定位问题会容易得多。

4. 这类审计最需要盯住的五类问题

4.1 依赖版本不匹配，而不是“最新就是合适”

LLM 生成的代码在依赖声明上经常有两个问题：一是漏写依赖，二是写了依赖但版本范围过宽。模型训练时的代码快照可能来自某个特定时期的文档，当你安装最新版依赖时，API 签名可能已经变了。

常见的例子包括：openai包从旧接口迁移到新接口时，模型调用参数完全不同；pydantic的Field导入位置变了；langchain的组件在不同小版本里移动了模块路径。这些问题在运行前很难发现，因为代码本身没有语法错误，只是运行时会报AttributeError或ImportError。

审计时不要只看requirements.txt，要看虚拟环境里真实安装的版本。更稳妥的做法是把依赖锁定文件纳入版本管理，而不是信任一个范围宽泛的声明。

4.2 防御式代码掩盖了错误原因

LLM 非常喜欢生成这样的代码：

try: result = api.call() return result["data"] except Exception: return None

这种代码在快速验证时看起来没问题，但一旦进入生产环境，错误信息就消失了。网络错误、认证失败、限流、返回格式异常，全都变成一个None。调用方的代码可能因为拿到了None而再次抛出另一个错误，但真正的根因已经被吞掉了。

审计时要特别关注：

• except Exception有没有保留上下文日志。
• 是否对不同异常类型做了区分处理。
• 返回值会不会把“失败”伪装成“正常结果”。

一个比较好的判断标准是：异常分支的信息量不能低于正常分支。如果异常分支只是return None或pass，那大概率是有问题的。

4.3 全局状态和并发共享带来的隐患

LLM 应用如果把模型客户端、数据库连接、缓存这类对象直接放在模块顶层，在脚本场景下没有问题，但一旦部署成 Web 服务或者异步 Worker，就可能出现并发问题。

常见隐患有三类：

• 全局可写对象被多个请求同时修改，出现竞态条件。
• 异步环境中调用阻塞式同步 I/O，导致事件循环卡住。
• 模块级实例在多进程部署中被反复创建，造成连接池耗尽或资源浪费。

审计时需要区分“模块级常量”和“模块级可变状态”。常量可以接受，可变状态就必须检查是否有锁、连接池或依赖注入机制。生成代码往往直接写client = OpenAI()在文件顶部，这在单脚本里没问题，但未必适合生产部署。

4.4 日志齐全，但没有可检索性

很多 LLM 生成的代码会加上logging，格式看着也挺规范。但真正排查线上问题时，你需要的不是“有日志”，而是“日志能帮你还原一次请求的完整路径”。如果每条日志只有内容，没有请求 ID、没有链路 ID、没有关键参数摘要，那问题出现时你只能知道系统报错了，无法定位到具体是哪次会话、哪个输入触发的。

审计时建议检查：

• 入口处是否生成并传递了 Request ID 或 Trace ID。
• 关键调用点是否记录了 prompt 长度、模型名称、耗时、token 数等关键指标。
• 日志是否对敏感信息做了脱敏，比如 Key、Token、用户隐私内容。

如果这些都没有，代码可能不需要大改，但需要为可观测性留出扩展点。

4.5 缺少幂等和重试机制

LLM 生成的代码在单次任务里表现不错，但放到批量任务场景，问题就会暴露。比如批量生成文章摘要，循环调用模型接口，一旦中间某个请求超时，程序抛异常退出；你重启之后，之前已经生成的摘要可能会被重复写入，或者重新调用一遍模型，浪费时间和费用。

一个健壮的批处理流程至少需要考虑三件事：

• 外部调用失败时，是否按指数退避重试。
• 处理进度是否支持断点恢复，而不是每次都从头开始。
• 写入结果时是否有幂等键或去重机制。

审计时，与其读完整代码，不如直接追问这些场景有没有对应处理。没有的话，就标记为风险项，而不是等它真正出事后再修。

5. 把审计经验变成团队可复用的检查基线

5.1 用表格沉淀一个最小审计基线

审计的价值不只是解决眼前这一个代码库，而是沉淀出自己的判断体系。当团队的多个成员都在审计 LLM 生成代码时，最好能有一份共享的检查基线，避免每个人只凭自己的经验随意判断。

下面是一个可以参考的最小审计基线，按维度列出检查项：

这个表格可以根据团队实际项目不断调整。关键是，你要有“基线”。没有基线，每一次审计都是从头摸索；有了基线，审计效率会成倍提升。

5.2 自动化扫描与人工作判断的边界

自动化扫描能解决一部分问题，比如未使用的 import、过大的函数、明显的循环依赖、不一致的异常捕获模式。这些无需求代码语义就能发现。但真正的判断仍然需要人来做。

自动化和人工的边界划分可以这样理解：

• 工具负责把代码库拆成步骤，标注风险点，提供上下文。
• 人负责判断这些风险点与业务预期是否冲突。
• 工具可以提供“疑似问题”，但最终的“是否接受”需要人来决定。

这就像在阅读一本厚书之前先看目录和书评，目录能帮你快速定位，但内容好坏还是要自己读。审计工具也一样，它降低的是“理解成本”，而不是“判断成本”。

5.3 哪些场景不能完全依赖逐步审计

逐步审计虽然高效，但它不是万能的。下面几种场景需要更完整的审查方案：

• 性能基准测试：逐步审计能发现明显瓶颈，但不能替代压测和 profiling。
• 安全合规审查：涉及数据安全、合规审计时，需要专业安全工具和流程。
• 复杂算法正确性：生成代码若包含数学算法或加密逻辑，需要人工做推导和验证。
• 微服务链路问题：代码库分布在多个服务中时，单仓库审计无法覆盖跨服务链路，需要结合链路追踪。

在这些场景里，逐步审计更适合作为第一道防线，而不是最终结论。它的定位是帮助你快速建立信心，找到重点风险，再决定下一步投入什么资源。

6. 如果现在就想用起来，从哪里开始

6.1 先不用等专用工具，用现有工具组合

如果团队还没有引入专门的 LLM 代码库审计工具，也完全可以先用现有工具组合搭建一套最小工作流。下面是一组常见组合：

• 用pydeps或 IDE 的依赖图功能画模块依赖。
• 用 VS Code 或 PyCharm 的调试器实现逐步断点执行。
• 用logging或trace模块在受控环境中记录函数调用链。
• 用unittest或pytest写几个关键路径的测试样例。
• 用 Markdown 文件记录审计过程中发现的风险项和判断依据。

这套组合不需要额外采购工具，只需要按照“先环境、再骨架、再调用链、再异常分支”的顺序推进。只要流程稳定，有没有专用工具都能达到快速审计的目的。

6.2 让审计工具发挥价值的几个习惯

如果已经有了专用工具，还要注意几个使用习惯，否则工具价值会大打折扣：

第一，每次打开新代码库，第一个动作一定是“生成骨架”，而不是直接读 README。先看地图，再决定从哪里开始。

第二，为每条高风险的调用路径设置一个标记，比如在审计笔记里记录“需要重点验证”的地方。不要让所有代码共享同一个审计级别。

第三，运行审计前，先保存环境快照。这样即使后来发现问题是依赖版本造成的，也能快速复现。

第四，每完成一个关键路径的验证，马上记录结果，不要等全部跑完再补笔记。审计过程中的临时判断往往最有价值，错过就丢了。

6.3 一个最小审计流程的通用示例

这里给出一个通用流程，它并不代表任何特定工具的命令，只是帮助你理解整体步骤：

1 进入项目根目录，创建虚拟环境 python -m venv .venv source .venv/bin/activate 2 安装依赖并锁定版本 pip install -r requirements.txt pip freeze > requirements.lock pip check 3 生成模块依赖图，输出骨架统计 python -m pydeps . --show-deps 4 从入口文件开始，定位第一个 API 路由或主函数 5 用调试器在关键调用点设置断点 （不需要修改业务代码，用 IDE 调试功能即可） 6 第一遍：正常样本输入，观察路径和输出 7 第二遍：空值、异常值、超长值输入，观察异常分支 8 第三遍：mock 外部服务的超时与错误返回，检查重试降级 9 在审计过程中，将结果整理到 review.md

这是一个通用结构，实际执行时可以根据项目规模和团队工具栈调整。核心顺序是：先确认环境干净可复现，再建立代码地图，然后从入口逐级走查，最后用边界输入验证逻辑和异常分支。

回到文章开头那个问题：为什么 LLM 生成的代码库需要一个快速逐步审计的工作流？因为生成代码真正缺少的不是质量，而是可解释性。这类工具和流程的意义，不在于让每一行代码都变得更漂亮，而在于把未知变成已知，把黑盒变成白盒。当你面对一个能运行但不能解释的代码库时，最不该做的事是直接部署上线，最该做的事是拿几十分钟沿关键路径走一遍，先确认它的边界在哪里。这个动作做多了，你对生成代码的判断力会稳定提升，团队对 AI 辅助开发的信任也才能跟着建立起来。## 1. 为什么 LLM 生成的代码库需要“逐步审计”，而不是整体审查

1.1 生成代码与人工代码最大的差异，不是质量，而是可解释性

传统代码审查是围绕人写的代码设计的。人写代码时有意图，有上下文，有 git 记录，有 PR 描述，甚至当面问一句就能搞清楚“这里为什么这么写”。代码质量好不好是一回事，但它的演化过程是可以在仓库里追溯的。LLM 生成代码不一样，尤其是当你用一个 Agent 或者一次性生成得到一个完整目录时，它更像是模型基于训练分布产出的“最终成品”，没有决策记录，没有废弃方案，也没有作者能够解释取舍。

这带来的直接问题是：你可以在十分钟内读完一个文件里的每个函数，但依然不知道它和旁边的模块是怎么协作的。整体审查在这种情况下很容易变成“读过一遍”，而不是“理解一遍”。尤其是代码生成工具经常把 prompt 构建、模型调用、结果解析、缓存、日志散落在不同文件里，静态阅读一遍根本无法快速建立因果链。

所以，逐步审计的价值不是“看得更仔细”，而是把审计动作从“读代码”变成“跟踪代码”。它的核心判断是：你不需要理解这个代码库的每一个字节，你只需要沿着关键入口和关键调用路径，验证每一步的行为是否和预期一致。只要把核心路径上的可解释性补回来，这个代码库就能进入下一步优化和维护。

1.2 “能跑”和“可维护”之间，需要一条验证路径

LLM 生成的代码库经常带有一种迷惑性：它会把函数拆得很细，会加注释，会做防御式判断，看起来非常有工程素养。但这些表面特征并不等于可维护性。你真正需要回答的是几个更具体的问题：

• 当外部 API 返回超时或者格式变化时，这个函数会怎样表现？
• 某个关键字段如果为空，程序会走哪条分支？
• 如果批量任务中途崩溃，重跑一次会不会产生重复数据？

这些问题只靠 review 代码本身回答不了，因为它们发生在代码执行过程中。要回答，就必须让代码在一个受控环境里被“走一遍”。逐步审计本质上是把静态审查和动态执行结合，形成一条验证路径：先看入口，再看调用链，再看数据流，最后看异常分支。这样每一个关键判断点都有机会被真实输入检验，而不是只靠大脑模拟。

从工程经验看，这也是审计 LLM 代码库时最容易被忽略的一层。很多人拿到生成代码后第一件事是部署测试，第二件事是等线上出 bug，中间缺少一个“先把关键路径走一遍，把行为记录下来”的步骤。等线上出问题时，你已经很难判断是哪一段生成逻辑有问题了。

2. 先读骨架，再跟逻辑，最后验证数据

2.1 骨架导航：快速定位代码库的入口和核心模块

进入一个新生成的代码库，第一步不要读代码，而是先建立“地图”。这个地图通常包含三样东西：目录结构、模块依赖关系、外部资源依赖。对于 Python 项目，目录结构往往能透露不少信息：LLM 应用一般会有一个入口文件、一个负责 prompt 构建的模块、一个调用模型客户端的地方、一个持久化目录或数据库连接模块、以及一堆工具函数。

依赖关系可以用静态分析工具生成，比如pydeps或者 IDE 内置的依赖图。你需要关注的是：

• 哪些模块被大量引用，是整个系统的“中心”。
• 哪些模块是入口，入度低、出度高。
• 是否存在循环依赖，尤其是 A 导入 B、B 又导入 A 的情况。
• 哪些模块负责外部 I/O，比如 HTTP 请求、文件写入、数据库连接。

这些信息帮你快速判断代码库的“心脏”在哪里。很多 LLM 生成的代码看似结构匀称，但真正核心的逻辑往往集中在少数几个模块里。找到了核心模块，后续审计就不需要浪费时间在边缘工具函数上。

2.2 调用路径跟踪：从某个入口逐级下钻

有了地图之后，第二步是选择一个入口，然后沿着真实调用路径逐级下钻。入口常见的有这么几类：CLI 命令、HTTP 路由、定时任务函数、消息队列消费者。入口就是审计的起点。

逐个入口展开后，你的注意力应该放在几个关键节点上：

• 这个入口拿到的输入是什么格式？有没有做校验和清洗？
• 输入经过哪些函数转换，才最终传给模型或者外部服务？
• 每次调用是同步还是异步？有没有超时控制？
• 调用外部服务前后的异常分支是否覆盖了可能的失败模式？

这一步要解决的问题是“逻辑链路是否成立”。很多生成代码的问题并不是某个函数写错了，而是函数与函数之间的协作方式有问题：参数在传递过程中被隐式修改，异常被吞掉，返回值在不同模块被当成不同结构使用。逐级下钻正是为了抓住这些节点之间的缝隙。

2.3 数据映射：真正难审查的是上下文如何流动

代码的控制流相对容易跟踪，真正难的是数据流，尤其是“上下文”在系统中的流动。

在 LLM 项目中，数据流往往经历这样的过程：原始用户输入 → 清洗和截断 → 拼接到 prompt 模板 → 调用模型 → 解析模型输出 → 后处理 → 存储或返回。最常出问题的不是某个环节的代码，而是“上一层输出”和“下一层输入”之间的假设不一致。举例来说，模型返回的 JSON 里有一个content字段，生成代码假设它一定存在，但某些返回条件下这个字段可能被省略，直接导致下一行解析抛异常。

审计时，工具应该支持你沿着某个数据项从产生到消费的完整链路做高亮跟踪，而不是让你自己在多个文件里搜索变量名。你需要确认的是：每个数据项在传递过程中是否发生了类型变化、格式变化、空值处理和敏感信息泄露。这一步做扎实了，审计的意义才真正体现出来。

3. 一个可落地的逐步审计工作流

3.1 第一步：准备受控运行环境

在做代码级分析之前，先把环境隔离好。这一步看起来基础，但很多审计失败都源于环境不可控。比如代码在全局安装了旧版本依赖，运行时没有报错，但行为和预想不同；又比如审计过程中代码突然访问了外部服务，造成数据污染或额外费用。

最少的环境准备包括：

• 使用venv或conda创建独立虚拟环境。
• 安装依赖后，用pip freeze固定版本快照。
• 运行pip check检查依赖冲突。
• 数据库、向量库、缓存等外部服务尽量使用临时实例。
• 对需要调用付费 API 的模块，先设置 mock 或者强制使用本地模型。

不要跳过这些步骤。LLM 生成的代码在库依赖上的“隐身问题”非常常见，比如它生成了openai新版本的调用写法，但环境里装的是旧版本，甚至还有一些包在requirements.txt里根本没写全。先锁定环境，再开始审计，可以少走很多弯路。

3.2 第二步：建立从入口到关键函数的跟踪清单

接下来不要随机看代码，而是先建立一个跟踪清单。这个清单相当于审计路线图，每完成一项就标记一项。一个比较实用的清单顺序是：

1. 找到所有外部可触达的入口：HTTP 路由、CLI 命令、定时任务、队列消费者。
2. 找到核心处理函数：哪些函数处理了 prompt、调用模型、解析输出。
3. 列出所有外部依赖链：外部 HTTP/API、数据库读写、文件系统操作、环境变量读取。
4. 优先检查异常分支：每个外部调用有没有 try/except，异常分支做了什么。
5. 为每个入口准备一个“正常输入”和“极端输入”，用于后续动态验证。

这个清单不是给你增加负担，而是让审计过程可追踪。你会发现自己很快就知道哪些文件优先看，哪些函数需要进调试器，哪些模块可以先跳过。很多人在审计生成代码时效率低，不是因为代码量大，而是因为没有建立优先级。

3.3 第三步：三遍验证法，动态对照设计意图

静态跟踪完成之后，最有效的动态验证方式是“三遍验证法”。

第一遍，输入正常数据，走一遍系统主链路。注意观察：

• 响应是否符合预期。
• 代码路径是否和你从调用链判断的一致。
• 有没有走到你意料之外的分支。

第二遍，输入空值、异常值、超长值。重点观察：

• 输入校验是否存在漏洞。
• 异常分支是否真的能被触发。
• 程序是否会崩，还是返回一个含糊的 None。

第三遍，模拟外部依赖异常。比如 mock 的模型调用超时、返回空字符串、返回畸形 JSON、数据库连接失败。这一步能暴露很多隐藏问题：

• 超时后有没有重试机制。
• 返回异常结构时，解析代码能否优雅失败。
• 错误信息有没有被记录到日志中。

如果一个代码库能通过这三遍，那它至少在核心路径上是可信的，可以进入更严格的安全审查或性能测试。如果三遍中途就崩了，那也不坏，你正好发现了最需要修的问题。

注意：不要一上来就把批量数和并发数拉满，先用一条样例确认输入、输出和日志都正常，再逐步放大，这样定位问题会容易得多。

4. 这类审计最需要盯住的五类问题

4.1 依赖版本不匹配，而不是“最新就是合适”

LLM 生成的代码在依赖声明上经常有两个问题：一是漏写依赖，二是写了依赖但版本范围过宽。模型训练时的代码快照可能来自某个特定时期的文档，当你安装最新版依赖时，API 签名可能已经变了。

常见的例子包括：openai包从旧接口迁移到新接口时，模型调用参数完全不同；pydantic的Field导入位置变了；langchain的组件在不同小版本里移动了模块路径。这些问题在运行前很难发现，因为代码本身没有语法错误，只是运行时会报AttributeError或ImportError。

审计时不要只看requirements.txt，要看虚拟环境里真实安装的版本。更稳妥的做法是把依赖锁定文件纳入版本管理，而不是信任一个范围宽泛的声明。

4.2 防御式代码掩盖了错误原因

LLM 非常喜欢生成这样的代码：

try: result = api.call() return result["data"] except Exception: return None

这种代码在快速验证时看起来没问题，但一旦进入生产环境，错误信息就消失了。网络错误、认证失败、限流、返回格式异常，全都变成一个None。调用方的代码可能因为拿到了None而再次抛出另一个错误，但真正的根因已经被吞掉了。

审计时要特别关注：

• except Exception有没有保留上下文日志。
• 是否对不同异常类型做了区分处理。
• 返回值会不会把“失败”伪装成“正常结果”。

一个比较好的判断标准是：异常分支的信息量不能低于正常分支。如果异常分支只是return None或pass，那大概率是有问题的。

4.3 全局状态和并发共享带来的隐患

LLM 应用如果把模型客户端、数据库连接、缓存这类对象直接放在模块顶层，在脚本场景下没有问题，但一旦部署成 Web 服务或者异步 Worker，就可能出现并发问题。

常见隐患有三类：

• 全局可写对象被多个请求同时修改，出现竞态条件。
• 异步环境中调用阻塞式同步 I/O，导致事件循环卡住。
• 模块级实例在多进程部署中被反复创建，造成连接池耗尽或资源浪费。

审计时需要区分“模块级常量”和“模块级可变状态”。常量可以接受，可变状态就必须检查是否有锁、连接池或依赖注入机制。生成代码往往直接写client = OpenAI()在文件顶部，这在单脚本里没问题，但未必适合生产部署。

4.4 日志齐全，但没有可检索性

很多 LLM 生成的代码会加上logging，格式看着也挺规范。但真正排查线上问题时，你需要的不是“有日志”，而是“日志能帮你还原一次请求的完整路径”。如果每条日志只有内容，没有请求 ID、没有链路 ID、没有关键参数摘要，那问题出现时你只能知道系统报错了，无法定位到具体是哪次会话、哪个输入触发的。

审计时建议检查：

• 入口处是否生成并传递了 Request ID 或 Trace ID。
• 关键调用点是否记录了 prompt 长度、模型名称、耗时、token 数等关键指标。
• 日志是否对敏感信息做了脱敏，比如 Key、Token、用户隐私内容。

如果这些都没有，代码可能不需要大改，但需要为可观测性留出扩展点。

4.5 缺少幂等和重试机制

LLM 生成的代码在单次任务里表现不错，但放到批量任务场景，问题就会暴露。比如批量生成文章摘要，循环调用模型接口，一旦中间某个请求超时，程序抛异常退出；你重启之后，之前已经生成的摘要可能会被重复写入，或者重新调用一遍模型，浪费时间和费用。

一个健壮的批处理流程至少需要考虑三件事：

• 外部调用失败时，是否按指数退避重试。
• 处理进度是否支持断点恢复，而不是每次都从头开始。
• 写入结果时是否有幂等键或去重机制。

审计时，与其读完整代码，不如直接追问这些场景有没有对应处理。没有的话，就标记为风险项，而不是等它真正出事后再修。

5. 把审计经验变成团队可复用的检查基线

5.1 用表格沉淀一个最小审计基线

审计的价值不只是解决眼前这一个代码库，而是沉淀出自己的判断体系。当团队的多个成员都在审计 LLM 生成代码时，最好能有一份共享的检查基线，避免每个人只凭自己的经验随意判断。

下面是一个可以参考的最小审计基线，按维度列出检查项：

这个表格可以根据团队实际项目不断调整。关键是，你要有“基线”。没有基线，每一次审计都是从头摸索；有了基线，审计效率会成倍提升。

5.2 自动化扫描与人工作判断的边界

自动化扫描能解决一部分问题，比如未使用的 import、过大的函数、明显的循环依赖、不一致的异常捕获模式。这些无需求代码语义就能发现。但真正的判断仍然需要人来做。

自动化和人工的边界划分可以这样理解：

• 工具负责把代码库拆成步骤，标注风险点，提供上下文。
• 人负责判断这些风险点与业务预期是否冲突。
• 工具可以提供“疑似问题”，但最终的“是否接受”需要人来决定。

这就像在阅读一本厚书之前先看目录和书评，目录能帮你快速定位，但内容好坏还是要自己读。审计工具也一样，它降低的是“理解成本”，而不是“判断成本”。

5.3 哪些场景不能完全依赖逐步审计

逐步审计虽然高效，但它不是万能的。下面几种场景需要更完整的审查方案：

• 性能基准测试：逐步审计能发现明显瓶颈，但不能替代压测和 profiling。
• 安全合规审查：涉及数据安全、合规审计时，需要专业安全工具和流程。
• 复杂算法正确性：生成代码若包含数学算法或加密逻辑，需要人工做推导和验证。
• 微服务链路问题：代码库分布在多个服务中时，单仓库审计无法覆盖跨服务链路，需要结合链路追踪。

在这些场景里，逐步审计更适合作为第一道防线，而不是最终结论。它的定位是帮助你快速建立信心，找到重点风险，再决定下一步投入什么资源。

6. 如果现在就想用起来，从哪里开始

6.1 先不用等专用工具，用现有工具组合

如果团队还没有引入专门的 LLM 代码库审计工具，也完全可以先用现有工具组合搭建一套最小工作流。下面是一组常见组合：

• 用pydeps或 IDE 的依赖图功能画模块依赖。
• 用 VS Code 或 PyCharm 的调试器实现逐步断点执行。
• 用logging或trace模块在受控环境中记录函数调用链。
• 用unittest或pytest写几个关键路径的测试样例。
• 用 Markdown 文件记录审计过程中发现的风险项和判断依据。

这套组合不需要额外采购工具，只需要按照“先环境、再骨架、再调用链、再异常分支”的顺序推进。只要流程稳定，有没有专用工具都能达到快速审计的目的。

6.2 让