AI 生成代码进生产前，开发团队应该保留哪些人工关卡？

现在用 Cursor、Claude Code、Copilot 做原型很快。一个后台页面、几个接口、一组数据库表，几小时内跑起来并不稀奇。

但我不太赞成把“能跑起来”直接等同于“可以交付”。尤其是企业内部系统、SaaS、AI 应用、小程序后台这类项目，真实上线后要面对权限、数据、旧系统迁移、第三方接口、备份和后续维护。AI 可以参与开发，但生产责任还是要有人接住。

我现在更倾向于给 AI 生成代码设置几道人审关卡。

第一关：业务规则有没有落到代码里

AI 很擅长根据上下文补页面和接口，但它不知道业务里哪些动作会带来真实后果。

比如一个客户管理后台，演示时有客户列表、新增、编辑、搜索，看起来没问题。上线前还要问：销售能不能看到别人的客户？主管能不能改成交归因？重复客户怎么合并？离职员工的客户怎么交接？哪些字段不能导出？

这里要看的重点不是样式或 CRUD，是业务规则。代码能跑，不代表这些规则已经被实现。

如果 PR 里只写“完成客户管理模块”，review 基本没法做。更好的方式是把任务写成可检查的用户动作：

销售可以创建客户跟进记录；

主管可以查看本部门客户；

普通销售不能导出客户手机号；

客户转移后保留操作记录。

这样 review 时才知道该看什么。

第二关：权限不能只靠前端

AI 生成的后台代码，经常会把权限处理得很轻：页面上判断一下角色，按钮隐藏掉，看起来就结束了。

生产系统不能这样。

读取、修改、导出、删除都要在服务端检查身份、组织、资源归属和操作范围。尤其是多租户、部门数据、客户资料、合同、金额和审批记录，只要有一个接口漏了，前端按钮藏得再好也没用。

review 时我会专门看这些点：

• 查询是否绑定当前组织或租户；

• 导出接口是否复用同样的权限判断；

• 失效账号和越权 ID 是否有测试；

• 操作日志是否记录关键修改；

• 错误信息有没有泄露不该看的数据。

这些检查不复杂，但很容易被“功能已经跑通”掩盖。

第三关：失败路径有没有设计

AI 生成的正常路径通常很顺，失败路径才是生产项目的坑。

数据库迁移失败，能不能回滚？第三方接口超时，状态会不会卡住？重复提交，会不会创建两条订单？部署中断，能不能退回上一版？用户误删数据，备份在哪里？

这些问题不适合做演示，但上线后最容易救命。

我会要求高风险改动至少说明三件事：

1. 失败时系统会留下什么状态；

2. 谁能看到错误并处理；

3. 能不能重试、回滚或恢复。

没有失败路径的“成功演示”，离生产交付还差一截。

第四关：下一位开发者能不能接手

AI 写出来的代码，如果只有当前会话知道来龙去脉，过两周就会变成负担。

需求背景、数据结构、关键业务规则、部署方式和已知限制，不能只留在聊天记录里。至少要沉淀到 README、PR 描述、测试、部署说明或交接文档里。

我会把交付物拆成几类：

• 源码和可重复启动方式；

• 环境变量和第三方账号说明；

• 数据库结构和迁移说明；

• 测试记录和已知限制；

• 备份、恢复和回滚方法；

• 维护期内谁负责处理问题。

这些内容不一定都要很重，但必须能让下一位开发者找到入口。

AI 适合做什么

这不是说 AI 不能用于生产项目。

相反，AI 很适合生成初版页面、接口样板、测试草稿、文档初稿，也适合帮忙解释 diff、找空值路径、补边界用例。它能让团队更早拿到可运行版本。

但省下来的时间，不应该全部从项目里删掉。更好的用法，是把时间挪到需求确认、权限检查、异常流程、上线准备和交接文档上。

我把这个话题整理成了一篇更完整的文章，里面从业务理解、需求判断、技术实现、上线运维和价值跟踪几个环节讲 AI 开发项目到底该交付什么：

AI 辅助开发的工程验收方式

如果你们团队已经把 AI 放进开发流程里，可以讨论一下：你们现在最容易漏掉的是权限、失败恢复，还是交接文档？

本作品采用《CC 协议》，转载必须注明作者和本文链接