先说明一下背景：我刚把一个用 AI 辅助写的功能模块推到生产环境，前后花了差不多一个下午做上线前检查。身边很多人问我“AI 生成的代码敢直接上生产吗”，我的回答是：敢，但绝不敢直接上。AI 写代码的速度确实快，可它没有对业务负责的包袱，也没有被线上故障毒打过，所以任何 AI 生成的代码在进入生产环境之前，都必须走一套明确的上线前检查流程。这篇文章把我现在每天在用的四道检查完整拆给你，每道检查该看什么、用什么工具、会踩哪些坑，都按实际经历过的方式写。

1. 先别急着提交：静态审查是第一道门槛

1.1 为什么静态审查要放在最前面

AI 生成的代码有个典型特征：表面很干净，甚至比很多新人的代码格式还要规范，但内部逻辑可能在你意想不到的地方出问题。比如它可能假设某个接口永远返回非空列表，可能把一个全局变量改得无声无息，可能在不同文件里各写了一套日期处理逻辑，这些问题靠跑测试不一定能立刻暴露，却会在生产环境流量稍大时突然跳出来。

所以我把静态审查放在所有步骤之前，核心原因是成本最低、反馈最快。在本地把 diff 拉出来读一遍，再用工具扫一遍，基本能把语法错误、明显的坏味道、不规范的资源管理问题挡在门外，比部署到测试环境再发现问题省太多时间。我自己会把 AI 生成的代码当成一个刚从简历上看很漂亮的新人写的 Pull Request，上线前必须有人认真 review，而这个“人”首先是我自己。

1.2 我用的审查工具组合

不同语言的项目，我用的静态工具组合也不太一样，但思路一致：一个 linter 管代码规范，一个静态分析器管潜在缺陷，再加一个格式化工具统一风格。下面是我近期在用的组合，你可以直接抄走：

在本地我用git diff先看 AI 实际改动了哪些行，不只看新增代码，更要看它有没有顺手删掉或改动原有的防御逻辑。机器检查完，我还会单独过一遍它生成的复杂函数，尤其是超过 40 行的函数，AI 很擅长把多个功能挤在一个函数里，这种代码后续维护会非常痛苦。

提示：千万不要只跑 linter 就完事。Linter 只能告诉你“这里不太规范”，不会告诉你“这个函数在并发下会有一致性问题”。工具只是帮人省力，不能替代人眼。

1.3 人工审查时盯住哪几行

工具扫完后，我会重点盯几个固定位置，这些都是踩过坑之后养成的习惯：

第一个是边界条件。AI 生成的循环、递归和列表处理，经常不考虑空值、极端值和溢出。比如让 AI 写一个“取最近 N 条记录”的函数，它可能直接records[-N:]，正常数据没事，一旦列表长度小于 N，结果就完全不是预期。我审查时会故意把每段涉及下标、截断、除法的代码画出来，问自己一句：如果输入是空、负数、超大值，这段代码还成立吗？

第二个是状态变更和副作用。AI 写代码时经常忽略函数对外部状态的影响，比如在工具函数里偷偷改全局配置、在查询接口里写了写库操作、在循环里打开文件却不在 finally 里关闭。我会特别看所有global、static、环境变量赋值、文件句柄和数据库连接。这类问题用肉眼看比用测试发现更高效，因为测试环境很难模拟生产环境的全部状态组合。

第三个是异常处理路径。AI 生成的代码很喜欢只写成功路径，异常分支要么留空，要么只logger.error一下就不管了。审查时我会找所有catch和except块，如果异常之后没有任何降级处理、没有返回兜底值、没有触发告警，那这段代码上线后就是一颗定时炸弹。我一般要求 AI 生成的代码里，所有外部调用必须有明确的三段式：成功做什么、失败做什么、超时做什么。

2. 第二道检查：安全与依赖体检

2.1 依赖树里藏着大坑

AI 生成代码时，如果让它“顺便解决一个问题”，它最常见的偷懒方式就是顺手装一个新依赖。有时候依赖名看起来很正常，版本号却不是最新的，甚至可能带着已知漏洞。我有一次让 AI 写一个 CSV 解析功能，它在 requirements 里加了pandas，我当时没细看就提交了，后来安全扫描发现那个 pandas 版本有个中危漏洞，虽然实际风险不大，但劳动法意义上的“上线前检查”就卡住了。

所以第二道检查我固定会用工具扫依赖树。不同生态对应不同命令：

# Node.js 项目 npm audit --production npm outdated # Python 项目 pip-audit pip list --outdated # Go 项目 govulncheck ./... go list -m -u all

扫描出漏洞后，不要盲目升级，要看 AI 引入这个依赖到底是图什么。如果只是用了一个小工具函数，那直接自己写十几行替代，把依赖删掉更干净。如果确实需要大依赖，那就要确认这个依赖是否被项目其他部分使用、版本升级是否会破坏 API，以及许可证是否符合公司规范。AI 可不会帮你判断GPL代码能不能放到闭源商业项目里，这些必须人来做。

2.2 密钥管理：AI 不会替你保密

这是我在审查 AI 代码时最警惕的问题之一。AI 在训练语料里见过太多少写死密钥的示例，于是生成代码时默认把数据库密码、API Token、第三方密钥直接写在配置里，甚至写在代码的字符串里。代码能跑，但这相当于把保险柜钥匙贴在保险柜门上。

我的检查办法很机械但很有效：在仓库里搜常见密钥关键词，线上环境我会用 gitleaks 在 CI 里自动拦，本地先用肉眼确认一遍关键字。

grep -rniE "(api[_-]?key|secret|password|token|access[_-]?key)" --include="*.py" --include="*.js" --include="*.ts" --include="*.env*" .

搜出来之后，凡是真实值全部从代码里删除，改成从环境变量或密钥管理系统读取。如果 AI 生成的代码里已经有硬编码值，还需要检查这个值是不是已经在 git 历史里出现过了，出现过的就要立即轮换密钥，不能只改代码，否则历史提交里仍然暴露着。

2.3 注入、越权和反序列化

AI 生成代码时对安全边界的理解非常有限，最常见的是把用户输入直接拼进查询字符串或命令里。我最近 review 过一段 AI 写的 Python 查询代码，它是这么写的：

# 危险写法，请勿模仿 def get_user(user_id): query = f"SELECT * FROM users WHERE id = '{user_id}'" cursor.execute(query) return cursor.fetchone()

看起来没什么问题，但user_id一旦是用户可控的输入，就会变成 SQL 注入。正确的写法应该是参数化查询：

def get_user(user_id): query = "SELECT * FROM users WHERE id = %s" # 或者 ? cursor.execute(query, (user_id,)) return cursor.fetchone()

除了注入，我还要检查 AI 是否暴露了不该暴露的接口。比如让 AI 写一个内部管理接口，它可能会顺手把所有字段都返给前端，包括数据库自增 ID、内部状态码、甚至手机号这些敏感信息。它也不知道哪些角色能访问哪些接口，所以我检查时会逐个接口确认：有没有鉴权？有没有越权？是不是把服务端内部错误信息直接抛给了用户？

还有一个隐蔽点是反序列化。如果 AI 代码里有pickle.loads、eval()、yaml.load这种动态解析，要格外小心。yaml.load在 Python 旧版本里可以执行任意对象，AI 生成这种代码的概率不低，我遇到过一次就再也不信任它了，一律改成yaml.safe_load。

2.4 性能和资源额度

生产环境里跑挂服务的往往不是逻辑错误，而是资源耗尽。AI 生成的代码特别容易出现这类问题：一个while循环没有退出条件、一个列表推导式读取了整张表、一个并发任务没有限制线程数。我检查时会专门看三样东西：是否有无界数据读取、是否有无界并发、是否有无超时时间的外部调用。

具体来说，如果 AI 生成了一段“把所有数据加载到内存再进行筛选”的代码，我会把它改成用数据库查询或流式处理。如果它启动了线程池但没限制最大线程数，我会在审查时直接打回。如果它调用外层 HTTP 接口没有设置超时，我会一律要求补上。生产环境里最怕的不是“代码错了”，而是“代码没问题但把内存吃光了”，这种故障往往比逻辑错误更难定位，因为日志看起来一切正常，只是机器慢慢卡死。

我习惯在代码审查阶段就预设失败场景：如果下游服务延迟 10 秒，这段代码会不会拖垮线程池？如果上游数据量翻十倍，这段代码会不会 OOM？如果用户并发翻倍，这段代码会不会把数据库连接池打满？这些问题的答案在代码里，不在测试用例里，所以人工过这一遍特别重要。

3. 第三道检查：测试和可观测性

3.1 单测别只测“开心路径”

AI 生成代码的能力很强，生成单元测试的能力同样不弱，但它生成的测试大多是对着源码的“标准答案”写的，基本只覆盖最顺利的路径。我见过 AI 给一个登录接口写测试，覆盖了用户名密码正确、返回 token、token 里有正确字段，却完全不测密码错误、用户不存在、账号锁定、数据库超时这些情况。

所以第三道检查我不会直接信任 AI 生成的测试，而是把测试当代码一样 review。重点看几个“伤心路径”：输入错误时是否返回了友好提示而异常信息有没有泄露内部细节、依赖服务返回 500 时是否走了重试或降级逻辑、并发请求时共享状态是否被正确保护。AI 生成的测试如果缺少这些，我会自己补上，或者让 AI 基于这些场景重新生成测试用例。

我用一个非常简单的标准判断测试质量：把被测代码里的if分支逐个列出来，看看测试有没有覆盖到每个分支的两种情况。如果只覆盖了其中一个方向，说明测试和代码一样只在“顺风局”里验证过，上线遇到逆风就是事故。

3.2 用真实数据做集成测试

单元测试只能验证函数内部逻辑，但生产环境的错误大量发生在多个模块交互时。AI 生成的代码里最容易出现的问题是：它假设了外部接口的参数格式和返回结构，但实际测试环境和生产环境可能不完全一致。所以我要求所有 AI 生成的代码必须跑一遍集成测试，而且是针对真实数据库、真实中间件、真实下游测试桩的集成测试。

我自己的做法是准备一套独立的测试环境，数据库用脱敏后的真实数据子集，Redis、Kafka 等中间件都用本地容器跑起来，然后把 AI 生成的代码完整部署上去走接口。这里有一个容易踩的坑：有些 AI 会生成“自适应”的代码，比如根据一个枚举值切换不同处理逻辑，但测试数据里这个枚举只出现了两种值，结果生产环境遇到第三种值就崩了。用真实数据子集跑集成测试，能很大概率撞出这类问题。

如果没有条件用真实数据，至少要用契约测试。AI 生成前端代码时，我要校验它调用的后端接口字段是否和后端契约一致；AI 生成后端代码时，我要用 schema 工具校验它返回的数据结构。这类不一致问题在微服务架构里特别常见，而且往往是“测试环境好好的，一上生产就报字段不存在”的根源。

3.3 日志、指标与追踪必须提前埋

代码能跑只是第一步，生产环境上出了问题，你必须有足够的信息快速定位。AI 生成的代码默认不会帮你埋日志，它只写业务逻辑，不写“业务逻辑失败时怎么定位”。所以上线前检查里，我会明确检查这段代码有没有可观测性。

至少要做到三点：第一，重要操作必须有日志，而且日志里要包含业务标识，比如订单号、用户 ID、请求 ID，不能只打一句“处理失败”。第二，关键业务指标要有 Metric，比如成功次数、失败次数、处理耗时、排队长度。第三，涉及多服务调用的部分要接入链路追踪，至少保证入口请求的 Trace ID 能贯穿所有调用链。

我一个很深的体会是：AI 生成的代码平时看起来没问题，一但出问题，如果日志只有Error: exception on DB，你就会陷入一种特别无力的状态。你知道它挂了，但不知道哪条链路、哪个参数、哪次调用。所以我的习惯是上线前专门跑一轮“故障模拟”：把下游接口故意返回 500，看日志里能不能定位到具体代码行；把某个数据表字段故意改成 null，看报错信息里有没有足够上下文。如果模拟过一次，日志还是一团浆糊，那就不允许上线，先补可观测性再说。

4. 第四道检查：灰度发布与回滚预案

4.1 灰度策略怎么定

就算前几道检查都过了，AI 生成的代码依然可能在真实流量下暴露出意想不到的问题。最稳妥的上线方式不是一次全量发布，而是灰度。灰度不是“随便放点流量试试”，而是要有明确策略，我一般按这个节奏走：

• 先让内部账号或测试账号走新版本，确认基础功能没问题。
• 外部流量先放 1%，观察错误率和延迟指标，持续观察 15 到 30 分钟。
• 如果指标平稳，放大到 5% 到 10%，再观察一个完整业务周期。
• 确认无异常后再逐步放大到 50%、100%。

这里的“观察”不是看监控页面有没有变红，而是要看错误率、P95 延迟、业务成功率、数据库慢查询这些具体指标有没有明显波动。AI 生成的代码如果涉及数据库结构变更，灰度前还必须先兼容旧逻辑。我在实际工作中就让 AI 生成过一个改表字段的迁移脚本，它直接改了列名，没有做双写和兼容，如果当时直接上线，所有旧数据都读不到，还好灰度阶段用兼容逻辑发现了这个问题。

4.2 回滚方案的三个层次

灰度期间一旦发现问题，回滚必须快，不能等到用户开始投诉了才找方案。我把回滚方案分为三个层次，每次上线前都要确认清楚：

第一层是功能开关回滚。最好的情况是代码没变，只有功能开关切换。比如新逻辑放在一个配置项后面，发现有问题直接关掉配置，旧逻辑立刻恢复。这个方案最快也最安全，我强烈建议 AI 生成的代码一律默认走开关方式接入，不要直接替换旧逻辑。

第二层是代码版本回滚。如果功能开关没法控制，那就回滚到上一个发布版本。这里的坑是数据库反向变更。如果新代码带了数据库迁移脚本，回滚代码后数据库可能还是新结构，旧代码不一定兼容。所以在设计阶段就要把数据库变更设计成可逆的，比如加字段时先用可空字段、加索引时先创建再启用，让回滚代码后新旧两边都能跑。

第三层是数据层修复。如果代码已经在生产环境跑了一段时间，产生了脏数据，光回滚代码不够，可能还要写数据修复脚本。AI 生成的代码如果涉及数据写入，上线前我会先确认有备份、有 binlog 开启、有恢复演练。没有备份的情况下数据被误删，那不是回滚能解决的问题，那是灾难恢复问题，最好永远不要让 AI 生成的代码把你带进那种处境。

4.3 上线后的黄金时段监控清单

发布不是结束，是运维的开始。我给自己定了一个“黄金一小时”规定：上线后的第一个小时，我不会离开电脑，每隔五分钟刷一次监控面板，重点盯以下几项：

• 错误率：接口 5xx / 4xx 比例是否异常，业务错误日志是否出现新的错误类型。
• 延迟：P95 和 P99 延迟有没有明显上升，有没有出现慢调用拖垮线程池的迹象。
• 资源利用率：CPU、内存、磁盘 IO 和 GC 频率是否异常，AI 代码如果有潜在内存泄漏，往往在高峰期才能看出来。
• 数据库：慢查询数量、连接数、锁等待有没有跳变。
• 业务指标：核心流程的转化率、完成率、失败率是否维持正常水平。

除了这些自动化监控，我还有一个很土但很有效的方法：跑一遍最关键的业务链路，用真实小流量验证一遍。比如支付回调、用户注册、文件上传，每个功能手动点一遍或者用脚本跑一遍，确认 AI 生成的代码在这些真实场景里没有糊弄。黄金一小时里如果真的发现异常，立即执行回滚预案，不要抱着“再观察观察”的心态，因为 AI 生成的代码出故障时，定位成本往往比人写的代码更高。

5. 我踩过的坑和最终上线检查清单

5.1 三个真实案例

第一个案例是 AI 写的一段 Python 爬虫脚本。它用来批量抓取第三方接口数据，AI 把所有结果都放到一个列表里再统一落库，本地测试时数据量只有几百条，一点问题没有。上线后跑了几个小时，内存直接飙到接近上限，最后进程被杀。原因是第三方接口返回的数据量比测试时大一个数量级，无界列表导致内存爆炸。后来我给它改成流式处理，边读边写，问题立刻消失。从那以后我审查 AI 代码时，看到任何“先收集全部再处理”的结构都会格外敏感。

第二个案例是 AI 生成的一个用户查询接口，它把用户传进来的排序字段直接拼进 SQL 的ORDER BY里。幸好在 code review 的时候同事眼尖看到了，否则这就是一个标准的 SQL 注入点。这件事情让我明白，AI 生成的代码在安全方面完全不可信，它只是把数据当成数据，并没有意识到某些数据是攻击者的输入。所以我现在对 AI 代码的安全审查，尺度比人写代码更严格。

第三个案例是 AI 生成的一段前端代码，它调用后端接口后直接渲染返回对象里的某个字段，但当时后端接口因为路由调整返回了 404，前端没有处理错误分支，页面直接白屏。测试环境里接口是好的，所以没发现这个问题。后来在后端逻辑变更时暴露了。从那以后，所有 AI 生成的前端异步代码，我都要检查有没有catch和错误提示，没有的一律打回。

5.2 最终上线检查清单

现在我把这四道检查浓缩成一张清单，每次上线 AI 相关代码时逐项打勾：

• 静态审查：人工读 diff，工具跑 lint 和静态分析，重点看边界条件、状态变更、异常处理。
• 安全依赖体检：依赖漏洞扫描、密钥硬编码检查、注入点排查、反序列化排查、资源额度确认。
• 测试可观测：单元测试覆盖关键分支，集成测试用真实数据子集，补日志、指标和链路追踪。
• 灰度回滚预案：功能开关优先，代码可回滚，数据库变更可逆，黄金一小时监控列表就绪。

这张清单不是让你机械执行的，而是提醒你：AI 生成的代码可以帮你把项目推进得更快，但“上线前检查”这个环节一定不能省。我见过很多刚开始用 AI 写代码的团队，头几次很兴奋，代码能跑就直接发布，结果一出生产事故就再也不敢用了。实际上更好的姿势是：把 AI 当成一个效率极高的初级工程师，它会犯错，但只要你给它配好完善的审查流程和兜底机制，它的产出是完全可以放心上生产的。

我个人现在的习惯是：AI 写完代码后，我会先让它自己解释一遍实现思路，再按清单逐项检查，最后必须有一次真实流量的灰度验证。这套流程看着繁琐，但每次上线后能睡个好觉，比什么花哨的工具都值。