Vibe Coding 上线前需要检查什么？AI 生成代码的五道安全关

AI 生成的应用在上线前，应经过身份、数据、依赖、业务行为和恢复能力五个环节的检查。页面可用、主流程能跑通，只能说明原型具备功能，不能证明它适合处理真实用户数据。

第一关：身份与权限

先列清哪些操作允许匿名访问，哪些需要登录，哪些仅管理员可执行。用两个普通账号测试横向越权：账号 A 能否通过修改对象编号读取或修改账号 B 的记录？隐藏按钮并不构成服务端授权。

数据库视图也需要单独检查。PostgreSQL 默认以视图所有者权限检查底层关系；设置 `security_invoker` 后可使用调用者权限，RLS 策略也受这一选择影响。应按实际数据库版本验证访问身份，不能认为开启 RLS 后所有视图就自动满足预期隔离。PostgreSQL 文档

第二关：数据和密钥

检查前端代码、构建产物、日志和版本库是否含服务端密钥。确认敏感字段确有必要返回，错误响应不会泄露完整内部信息。

用户口令应使用适合密码存储的加盐慢哈希，由成熟库处理参数和验证逻辑；通常不应采用可逆加密，更不能自行用一次快速哈希代替。OWASP 密码存储指南

第三关：依赖与执行环境

把 AI 建议新增的包逐一对应到官方项目和包仓库，检查名称、维护者及版本，保存锁文件。安装脚本、数据库迁移和部署脚本应在隔离环境检查后再接触生产凭证。

第四关：业务行为与异常路径

让需求变成可验证的规则，例如“重复支付请求不能重复扣减”“库存不足时不能创建成功订单”。同时测试空输入、超长输入、第三方超时、重复提交和权限撤销后的行为。

SAST 可辅助发现代码问题，SCA 可辅助分析组件风险，但业务授权与状态转换仍需要场景测试。用另一轮 AI 回答复核代码，也不等于获得独立的正确性证明。

第五关：发布与恢复

上线前保存可回退版本，实际验证备份恢复，并确认日志能够定位操作人和异常。先以受控范围发布，再依据运行结果扩大使用。

架构选择应服务于团队规模和业务复杂度。结构清楚、边界明确的单体应用也可以是合理起点；拆成微服务不会自动消除授权、数据一致性或运维问题。

原型也需要全部生产检查吗？ 使用模拟数据、隔离环境的原型可以简化流程；接入真实身份、数据或支付能力时，应补齐对应验证。

谁负责 AI 代码的最终质量？ 应由能够解释关键逻辑并承担发布职责的人负责，审查结论需要测试和证据支持。