AI 写的代码不能直接上线。不是它写得差——很多时候它生成的代码看着工整、跑起来也没报错——而是它对"安全"没有真正的敬畏心：它会顺手把密钥写进代码，会忘了校验用户输入，会给每个接口都开最大权限。合并之前过一遍下面这 4 道检查，十分钟能挡掉大部分线上事故。
检查一：密钥和依赖，别让秘密躺在代码里
AI 最常见的坏习惯是把 API Key、数据库密码直接写成字符串常量。它这么写是因为训练数据里有大量示例这么写，不是因为这样做对。
检查方法很机械：全局搜一遍 key、secret、password、token 这些词，看有没有硬编码的凭证；确认所有密钥都走了环境变量或密钥管理服务。其次看依赖：让 AI 引入新库时，问它一句"这个库的最新稳定版是多少、有没有已知高危漏洞"，版本太旧或长期没人维护的库直接换掉。个人项目至少做到前者，团队项目两条都要进 CI 检查。
检查二：输入校验，凡是用户能碰到的都要防
SQL 注入、命令注入、路径穿越，这些老问题在 AI 生成的代码里一点没少。AI 写查询时经常直接拼接字符串，写文件操作时经常不校验路径。
重点看三个地方：所有拼进 SQL、shell 命令、文件路径的字符串，是不是都经过参数化或白名单校验；上传文件的类型和大小有没有限制；错误信息会不会把堆栈和内部路径吐给前端。改法不用复杂，原则就一条：不信任任何外部输入，包括你以为"只有内部人会调"的接口。
检查三：认证和授权边界，默认拒绝而不是默认放行
AI 生成的接口有个倾向：先让功能跑通，权限以后再说。结果就是很多接口"能调"，但没校验登录态，或者校验了登录、没校验"这个用户有没有资格操作这条数据"。
合并前逐个接口过一遍：要不要登录才能调？登录了能不能操作别人的数据？管理接口有没有二次确认？记住一个判断标准：AI 默认给你的是"功能正确"的代码，"权限正确"需要你显式要求。以后让 AI 写接口时，直接在需求里加一句"每个接口先写权限校验"，能省掉一半返工。
检查四：让 AI 做二审，人工做终审
前三道是查具体问题，这一道的分工是流程。正确姿势是：让 AI 先审一遍自己的代码，提示词写成"以安全审计视角 review 这段代码，列出所有可能的注入、越权、敏感信息泄露风险，按严重程度排序"；然后人再看一遍 AI 标出来的风险点，决定修不修。
注意顺序不能反：人先看容易漏，AI 先看容易把小问题夸大。AI 的二审报告里，凡是它说"可能有问题但不确定"的地方，就是你最该亲手验证的地方。另外，安全检查不能替代测试——至少把核心流程的自动化测试跑通再合并，AI 写的测试用例本身也要抽查，它也会写出"永远通过"的假测试。
最后记住责任归属
AI 不背锅。代码是谁合并的，线上出事就是谁的责任。这 4 道检查的本质是把"你以为 AI 考虑到了"的东西，变成"你亲手确认过"的清单。团队里可以把这份清单做成 PR 模板，每次 AI 生成的代码合并前逐项打勾；个人开发者至少养成习惯：密钥、输入、权限这三处，永远不跳过。
