AI 写代码越来越快，但“能运行”不等于“能上线”。真正容易被忽略的风险，往往不是语法错误，而是业务逻辑、边界条件、安全、性能、维护性和依赖权限。本文整理一套 AI 生成代码上线前的检查思路，适合在使用 Cursor、Copilot、Claude Code、Codex 等工具时作为人工复核清单。

现在用 AI 写代码，最容易产生一种错觉：

只要代码能跑，问题就不大。

尤其是让 AI 改一个接口、补一个方法、写一个组件、生成一段 SQL，它通常很快就能给出一份看起来还不错的结果。

语法没报错。
单测也许能过。
页面也能打开。
接口也能返回。

但真正危险的地方，往往不在这些表面结果里。

AI 生成代码最容易埋的坑，不是语法错误，而是“看起来能跑，但和真实项目不完全匹配”。

这类问题最麻烦，因为它不会立刻红屏，也不会马上编译失败。它可能在上线后某个边界场景、某个异常输入、某次并发请求、某个权限组合里才暴露出来。

所以我现在用 AI 写代码时，不会只问它“这段代码有没有问题”。

我会先按 6 类风险过一遍。

1. 业务逻辑偏差：代码对了，需求错了

AI 很擅长根据字面描述写代码，但它不一定真正理解你的业务上下文。

比如你让它写一个“订单取消逻辑”，它可能会很自然地写出：

判断订单状态；
更新订单为已取消；
释放库存；
返回成功结果。

从代码结构看，没什么问题。

但真实业务里可能还有这些规则：

已支付订单不能直接取消；
部分发货订单只能走售后；
优惠券是否退回要看活动规则；
库存释放要区分实物库存和预占库存；
取消订单还要写操作日志；
某些渠道订单需要同步第三方系统。

这些东西如果没有写进提示词，AI 很可能不会主动补全。

所以 AI 写完业务代码后，第一步不是看代码漂不漂亮，而是问：

它有没有完整覆盖需求文档？
关键业务流程有没有走偏？
异常分支有没有处理？
和旧逻辑相比，有没有偷偷改变规则？

我常用的检查提示是：

请你不要修改代码，只根据当前实现，逐条说明它是否符合以下业务规则。
如果有不确定的地方，请标记为“需要人工确认”，不要自行假设。

这个提示比“帮我看看有没有 bug”更有效。

因为“有没有 bug”太宽泛，AI 容易给你一堆安慰性结论；而逐条对照业务规则，能逼它把不确定的地方暴露出来。

2. 边界条件遗漏：正常输入没问题，特殊情况全漏

AI 生成代码常见的问题，是只覆盖“最顺的路径”。

比如：

数组有值；
字段一定存在；
接口一定返回成功；
用户一定有权限；
数据库一定能查到记录；
第三方服务一定正常响应。

但真实项目里，问题经常出在这些地方：

空数组；
空字符串；
null；
undefined；
重复提交；
超长文本；
特殊字符；
并发请求；
接口超时；
数据库无记录；
用户状态异常。

如果你只让 AI 写实现，它可能默认“理想世界”。
如果你让它先列边界条件，它反而会更谨慎。

我一般会补一句：

在修改代码前，请先列出这个功能可能出现的边界条件和异常输入。
不要写实现，先列清单。

这一步很关键。

因为一旦 AI 先写了代码，它后面检查时容易顺着自己的实现解释。
先列边界条件，再写代码，质量通常会好很多。

3. 安全风险：AI 不一定知道你的权限边界

AI 写出来的代码，最需要重点看的就是安全问题。

尤其是这几类：

用户输入是否校验；
SQL 参数是否安全；
接口是否校验权限；
文件上传是否限制类型和大小；
敏感信息是否写进日志；
前端是否暴露不该暴露的字段；
后端是否只依赖前端判断权限。

举个常见场景。

你让 AI 写一个“根据用户 ID 查询订单详情”的接口，它可能直接生成：

const order = await db.order.findUnique({
  where: { id: orderId }
})

这段代码语法没问题。

但它可能漏掉一个关键判断：
当前登录用户是否有权限查看这个订单？

如果只按订单 ID 查，不校验归属关系，就可能出现越权访问。

这类问题特别危险，因为测试时你用自己的账号测，通常看不出来。
但真实环境里，只要有人猜到或拿到订单 ID，就可能访问不属于自己的数据。

所以凡是 AI 生成接口代码，我都会强制检查：

是否校验登录态？
是否校验角色权限？
是否校验数据归属？
是否避免敏感字段返回？
日志里有没有 token、手机号、邮箱、密钥等信息？

可以直接这样问：

请从安全角度审查这段代码，重点检查越权访问、注入风险、敏感信息泄露和权限校验遗漏。
只指出风险，不要直接改代码。

注意最后一句：先不要改代码。

因为安全审查阶段，先发现问题比立刻修更重要。

4. 性能问题：小数据没事，大数据直接炸

AI 很容易写出“逻辑正确但性能很差”的代码。

比如：

循环里查数据库；
一次性加载大量数据；
没有分页；
没有索引意识；
重复计算；
递归没有退出限制；
前端一次性渲染超大列表；
接口串行调用太多。

这些代码在开发环境可能完全没问题。

因为本地只有几十条数据，接口也只有你一个人在调。
但上线后数据量一上来，问题就出现了。

例如 AI 可能写出这种逻辑：

for (const user of users) {
  const orders = await getOrdersByUserId(user.id)
}

看起来很直观。
但如果 users 有 1000 个，就可能变成 1000 次数据库查询。

这不是语法错误，也不一定会被测试立刻发现，但会变成线上性能问题。

所以 AI 生成涉及列表、统计、查询、批处理的代码时，一定要问：

有没有 N+1 查询？
有没有分页？
有没有批量处理？
有没有缓存策略？
有没有不必要的重复计算？
数据量扩大 100 倍后还能不能接受？

我常用提示：

请从性能角度审查这段代码，假设数据量扩大到当前的100倍，指出可能变慢或资源消耗过高的地方。

这个提示比“优化一下代码”更好。

因为“优化一下”容易让 AI 乱重构；
而“指出风险”更适合人工决策。

5. 可维护性差：今天能跑，三个月后没人敢改

AI 写代码还有一个问题：它很容易写出“当下能用，但后面不好维护”的实现。

常见表现是：

函数太长；
命名含糊；
重复代码多；
逻辑嵌套太深；
注释解释了表面，没有解释原因；
把多个职责塞进一个方法；
为了完成当前需求，硬编码很多特殊判断。

这类代码短期看不一定出错，但会慢慢增加项目负债。

尤其是在老项目里，AI 不理解团队已有风格时，很容易写出和原项目不一致的代码。

比如原项目一直用 service 层处理业务逻辑，AI 却把大量逻辑塞进 controller。
原项目一直用统一错误码，AI 却自己返回一套 message。
原项目已有工具函数，AI 又重新写了一遍。

所以我会让 AI 做一次“项目风格对齐检查”：

请检查这段代码是否符合当前项目已有风格。
重点看命名、分层、错误处理、日志、工具函数复用和返回结构。
不要追求重构，只指出不一致的地方。

这一步对团队项目尤其重要。

AI 写得快，但团队维护要靠一致性。
风格不一致的代码，后面会让人越来越不敢改。

6. 依赖与权限不清：它为了完成任务，可能偷偷引入新东西

有些 AI 工具在生成代码时，会很自然地引入新依赖。

比如为了处理日期，引入一个库；
为了发请求，引入一个库；
为了做校验，引入一个库；
为了生成文件，引入一个库。

单看当前功能，确实方便。
但项目里未必需要。

新依赖会带来几个问题：

版本兼容；
包体积增加；
安全漏洞；
许可证风险；
部署环境不支持；
团队维护成本上升。

还有一种情况是权限扩大。

比如原本一个脚本只需要读文件，AI 改完后需要写文件；
原本一个接口只查一张表，AI 改完后访问了更多表；
原本一个任务不需要外部网络，AI 改完后调用了第三方服务。

这些变化如果没有被记录，很容易在上线后造成隐患。

所以 AI 改完代码后，我会加一个检查：

请列出这次修改新增或扩大了哪些依赖、权限、环境变量、文件读写、数据库访问和外部接口调用。
如果没有，请明确说明没有发现。

这个问题很实用。

它能帮你发现 AI 是否为了完成任务，悄悄扩大了影响范围。

我的实际流程：先跑通，再审查，最后小步合并

我现在不会完全拒绝 AI 写代码。
相反，AI 在写样板代码、补测试、查日志、解释项目结构方面很有价值。

但我不会把“AI 生成完成”当作“开发完成”。

比较稳的流程是：

第一步，让 AI 先理解需求和项目结构。
第二步，让 AI 列边界条件和风险点。
第三步，再让 AI 写最小范围修改。
第四步，人工审查业务逻辑、安全和性能。
第五步，补测试。
第六步，小步合并，保留回滚方案。

也就是：

能跑，只是第一关。
能测，才开始可信。
能审，才适合合并。
能回滚，才适合上线。

可以直接复制的审查提示词

如果你经常用 AI 写代码，可以把下面这段保存下来：

请你审查这次 AI 生成的代码，不要直接修改。

重点检查以下 6 类问题：

1. 业务逻辑是否符合需求，有没有自行假设；
2. 边界条件是否覆盖，包括空值、异常、重复提交、并发和超长输入；
3. 是否存在安全风险，包括越权、注入、敏感信息泄露和权限校验遗漏；
4. 是否存在性能问题，包括 N+1 查询、无分页、大数据量下资源消耗过高；
5. 是否符合项目已有风格，包括命名、分层、错误处理、日志和返回结构；
6. 是否新增或扩大了依赖、权限、环境变量、文件读写、数据库访问或外部接口调用。

请按“风险位置 / 问题说明 / 可能后果 / 建议处理方式”的格式输出。
不确定的地方标记为“需要人工确认”，不要自行脑补。

这段提示词的重点不是让 AI 直接修代码，而是让它先当审查员。

AI 最怕的是你让它“一口气写完并自我证明没问题”。
更稳的做法，是把生成和审查拆开。

总结

AI 生成代码最容易埋的坑，不在语法错误。

语法错误通常很快就能暴露。
真正麻烦的是那些能运行、能返回、能通过简单测试，但在真实业务、边界场景、安全权限、大数据量和长期维护里出问题的代码。

所以，用 AI 写代码时，不要只问：

“这段代码能不能跑？”

更应该问：

业务逻辑有没有偏？
边界条件有没有漏？
权限校验有没有少？
数据量变大后会不会慢？
团队后面能不能维护？
它有没有偷偷引入新的依赖和权限？

AI 写代码越快，人工审查越不能省。

因为上线后出问题，背锅的不是 AI，是你。