要在运行前审查 AI 生成代码，就检查完整 diff 和每条拟执行的命令，再核对范围、依赖、权限、secret、外部副作用、测试和回退。不要只因补丁在模型解释里“能编译”或附带自信的总结就执行它。

这份清单从代码生成之后开始。任务定义和安全的上下文共享，请看 AI 编程入门工作流；遇到具体故障时，先用基于证据的 AI 调试流程，再决定是否真的需要补丁。

关键要点

阅读实现细节前，先把 diff 与获授权的任务对照。

把依赖、锁文件、构建钩子、权限和迁移的变化当作单独的风险决策。

查找 secret，以及跨越命令、查询、路径、URL 和模板边界的不可信数据。

执行前复核命令，并从受限、可丢弃的环境开始。

要求测试；风险需要时安排独立复核人，并准备可行的回退路径。

从外向内审查：任务边界、文件清单、供应链、接口、数据流、副作用、失败行为、测试和执行计划。GitHub 的负责任使用指南指出，生成的代码可能不准确或不安全，应当彻底审查和测试。［1］

这份清单不能证明代码安全。它用来找出“暂时还不能运行”的常见原因，并把较高风险的变更交给合适的复核人。改一个拼写错误和迁移认证系统，不应受同等审查。

审查开始前要冻结哪些输入？

保存确切的提示词或任务、验收标准、生成的 diff 和拟执行的命令。确认 diff 完整，而非挑选的片段。审查期间文件有变，就作废过时的审查，重查新版本。

记录模型能访问什么：代码库路径、环境变量、网络、外部工具和账户身份。这有助解释意外的文件或命令如何进入结果。

步骤一：审查 AI 生成代码的范围和文件意图

列出每个新增、修改、重命名和删除的文件，各写一行理由，说明它为何是获授权任务所必需。无法解释的文件是停止信号，不是顺手清理的机会。

问一问：

补丁是在解决所要求的行为，还是在重新设计更大的子系统？
生成的文件是否与手工编辑的源码混在一起？
格式化是否改写了无关的行，从而掩盖了语义上的 diff？
测试、文档、配置或 schema 是否同步修改？
补丁是否删除了防护、校验分支、错误处理或审计事件？

除非事先明确批准，否则否决“顺便重构”的改动。diff 小不保证正确，但让意图和回退更易评估。

先读配置，再读应用代码

配置能改变未修改源码的含义。在关注看似实现功能的函数之前，先检查权限、功能开关、构建脚本、CI 工作流、环境默认值、路由和部署文件。

留意从“拒绝”改为“允许”的默认值、从 CI 删掉的校验命令或更宽的通配路径，它们的风险可能比主要代码改动还大。

步骤二：检查依赖和供应链

把新增或升级依赖当作独立变更。核实包名、仓库或注册表、版本约束、锁文件条目、传递依赖变化、安装脚本、维护状况和许可证，留意与常见包只差一个字符的名称。

“这个库很流行”不是证据。问一问：代码库是否已有合适的依赖？几行标准库代码是否更清楚？审查后，在正确环境运行项目既有的依赖审计。

AI 建议可能与公开代码匹配。GitHub 代码引用文档说明，受支持的 Copilot 体验可显示匹配的代码库和发现的许可证信息，也写明了索引和覆盖范围的限制。［2］把匹配提示当作复核来源和许可证的线索，而非证明未标记的代码是原创。

检查构建和安装行为

检查包脚本、编译器插件、代码生成、钩子和下载的二进制文件。很小的源码补丁也可能在安装或构建时触发代码执行。确认项目要求的校验和、签名或固定来源仍完好；不要只因代码由 AI 生成就另加一套完整性方案。

步骤三：追踪数据、secret 和权限

从入口到影响，追踪不可信输入。输入包括请求字段、请求头、文件名、压缩包、URL、Issue 文本、代码注释、环境变量、数据库行和工具输出。

检查输入是否到达：

敏感终点	核对问题
Shell 或子进程	参数是否与 shell 语法分离？可执行文件是否固定？
数据库查询	值是否参数化？授权过滤能否被绕过？
文件路径	路径是否规范化并限制在允许的根目录下？链接是否安全处理？
URL 或网络调用	协议、主机、重定向、凭证和响应大小是否受限？
模板或渲染器	不可信内容是否按实际输出上下文转义？
反序列化器	类型、深度、大小和意外字段是否有上限？

在修改行及附近代码中搜索凭证、令牌、私钥、Cookie、连接字符串和签名 URL，再检查补丁是否把敏感值写日志、返回、缓存或发往新目的地。secret 扫描器有用，但运行时拼接的值可能匹配不到静态模式。

复核每个副作用所用的身份。工具不应只因生成的实现处理不了更窄的角色就获得管理员权限。

步骤四：审查外部和破坏性副作用

把计算与副作用分开：准备请求不同于发送请求，校验迁移也不同于执行迁移。

这份受控的本地审查材料使用合成的 diff 和命令清单，不含生产代码或 secret，也不代表该示例已获批准或已执行。

对每个外部副作用，确认目的地、身份、发送的数据、幂等行为、超时、重试策略、响应校验、审计事件和恢复路径。网络重试可能重复付款或消息；文件系统重试可能覆盖较新文件；悄然回退可能把安全的失败变成意外的成功。

OpenAI 把 sandbox、审批政策、受限网络访问、凭证管理和遥测描述为编码 Agent 的不同治理控制。［3］复核拟议执行是否真用了项目的控制措施；一句“在 sandbox 中运行”的注释不会凭空创建 sandbox。

Migration 要单独 Review

schema 或数据迁移要检查正向和回退行为、事务边界、锁、长时间操作、与新旧应用版本的兼容性和重启行为。触碰共享数据前先用副本或 fixture。回退会丢数据时明确写出，并要求相应负责人批准。

步骤五：阅读失败行为和并发假设

复核每条新错误路径：代码是否失败即拒绝（fail closed）、是否在不泄露 secret 的前提下提供足够上下文、是否释放资源、持久状态是否一致。留意把错误变成空结果或成功的宽泛异常处理。

不要为一次性本地脚本凭空增加并发复杂度，但要检查真实执行模型。多个 worker、webhook、部署或用户可能触碰同一状态时，检查加锁、唯一性、幂等、陈旧读取和重试归属。“先检查再写入”在单进程中可能正确，在共享服务中却可能不安全。

对于由 Agent 产出的多步骤变更，AI Agent 的工作原理一文说明了为什么工具权限、状态、退出条件和交接，与模型的回答本身同样重要。

步骤六：运行测试前先阅读测试

把测试当作主张阅读：确认它们在旧行为下会失败、测试公共契约，且没把声称覆盖的风险 mock 掉。

要求相应的场景：

保持预期行为的正常用例；
空值、最大值、重复或 Unicode 输入等边界值；
格式错误和未经授权的输入；
相关时，依赖、网络、磁盘或子进程故障；
对共享状态而言，重试、重启、回退或重复投递；
捕获所报告 bug 的回归用例。

检查有无被删的断言、大范围快照更新、被跳过的测试、放宽的超时，或为避开失败而缩小的测试命令。生成的测试可能只是复述实现，仍漏掉需求。

NIST 的安全软件开发框架同样把代码审查、分析和测试放在更广泛的验证实践之中。［4］这就是为什么可读的 diff 和独立的测试证据是互补的，而不能相互替代。

步骤七：规划受限执行和回退

从静态和只读检查开始，再用适合项目的一次性 fixture、sandbox、容器、临时数据库或隔离工作树。除非测试需要访问已批准的目的地，否则禁用网络。使用低权限身份，别为方便而加载生产凭证。

执行之前，写下：

确切的命令；
它可能影响的文件、服务和账户；
预期的输出和耗时；
停止条件；
清理和回退步骤；
必须保存的证据。

回退须与副作用相匹配。回退源码不能恢复被删数据、撤销泄露的令牌、撤回已发消息，也不能降级不兼容的 schema。无法测试恢复过程时，批准前写明这一缺口。

取得对应领域审核

涉及认证、密码学、支付、个人数据、迁移、部署控制、许可证或不熟悉的语言特性时，请相应领域的复核人参与。模型可帮你准备审查材料包，但无法授予接受风险所需的组织权限。

运行前的最终判断：代码可以开始受控测试了吗？

只要以下任何一项答案未知，就先不要运行：

任务与修改的文件清单一致。
新依赖和公开代码引用已经弄清。
secret 和不可信数据不会到达不安全的终点。
权限和外部副作用有边界并已获授权。
失败、重试、迁移和回退行为可以接受。
测试覆盖的是契约和风险，而不只是实现。
首次执行环境尽可能受限且可丢弃。
高影响变更由一位具名的人作最终决定。

通过这份清单，只意味着代码可以开始受控测试，而不是可以上生产。

总结

先审查获授权的范围和完整的 diff，再看实现细节。
检查配置、依赖、锁文件、安装钩子和代码来源。
追踪不可信输入、secret、权限和外部副作用。
检查失败、重试、并发、迁移和回退行为。
运行测试前先阅读测试，并保留独立复核。
在受限环境中开始执行，生产验证另行进行。

常见问题

AI 生成代码比人工代码更危险吗？

两者都可能包含缺陷和不安全的假设。AI 输出应受到同样的工程控制，并额外留意编造的 API、意外的范围、与公开代码的匹配，以及自信却缺乏依据的总结。

代码能编译就可以运行吗？

编译检查的是语法和部分类型契约，并不能证明授权、数据安全、依赖可信度、失败行为或业务正确性。

应接受 AI 建议的新依赖吗？

只有在核实了它的身份、来源、版本、对锁文件的影响、安装行为、许可证、维护状况和必要性之后才接受。如果项目已有的依赖能满足需求，优先使用它们。

如何检查 secret？

使用代码库的 secret 扫描器，检查修改的行和日志，并追踪运行时拼接的值。任何已暴露的真实凭证都要删除并轮换。

运行生成命令前检查什么？

确认可执行文件、参数、工作目录、环境、文件、网络目的地、身份、预期输出和破坏性潜力。不要复制一条你看不懂的复合命令。

Sandbox 测试能证明生产安全吗？

不能。它能降低影响，并为已覆盖的场景提供证据。生产环境的身份、配置、流量、操作系统、依赖和外部服务，仍需要单独验证。

何时需要安全 reviewer？

当代码改动涉及认证、授权、secret、密码学、不可信输入的终点、供应链控制、个人数据、外部操作或安全监控时，就需要安全复核人参与。

免责声明：本文仅提供一般技术信息，不能替代组织的安全、法律、许可证、隐私和变更审批流程。

来源:

GitHub Docs — Responsible use of GitHub Copilot Chat in GitHub — https://docs.github.com/copilot/responsible-use/chat-in-github
GitHub Docs — GitHub Copilot code referencing — https://docs.github.com/en/copilot/concepts/completions/code-referencing
OpenAI — Running Codex safely at OpenAI — https://openai.com/index/running-codex-safely/
NIST — Secure Software Development Framework — https://csrc.nist.gov/projects/ssdf

Sources checked 2026 年 8 月 24 日。

延伸阅读：

运行前如何审查 AI 生成代码：从 diff、依赖到权限和回退逐项检查