AI 代写代码上线前，这 5 项检查别省

AI 编程助手已经把「写」的成本压到接近零，真正稀缺的是「审」。下面这 5 项检查都能在合并前 10 分钟内做完，却能挡住 AI 代码里最常见、也最致命的那几类问题。

1. 查依赖：AI 最爱编不存在的包

大模型生成代码时会「顺手」补全一个听起来很合理的包名，比如把 requests 写成某个不存在的 requests-helper。风险不只是装不上，更在于有人会抢注这些幻觉包名投毒（slopsquatting）。

做法：任何新增依赖先跑 npm ls --all 或 pip index versions <包名> 确认存在；再看仓库的最近提交时间、维护者数量和下载量；最后把版本写死，并跑一次 pip-audit 或 osv-scanner。团队内部能查到的依赖，一律不许 AI 自己造。

2. 查异常处理：吞异常比抛异常更危险

AI 写 try 时特别爱配一个 except Exception: pass，或者 catch (e) {} 里只留一行日志。结果是服务静默失败：任务没跑，监控不报警。

做法：让它逐条列出来——「每个 try 块捕获哪些异常？失败时上层如何感知？会不会继续用默认值往下跑？」正常业务错误应该抛出或返回明确的错误码，而不是被吞掉。日志里至少要有可检索的请求 ID。

3. 查安全边界：密钥、拼接 SQL、越权

三件事必看：一是密钥有没有硬编码，用 gitleaks 或 trufflehog 扫一遍整个 diff；二是 SQL 是不是字符串拼接，必须参数化；三是权限校验有没有只写在前端。

一个高效的提问方式：让 AI 站在攻击者视角，对这段改动写出 3 个具体利用场景。它给出的回答往往比你的自查清单更贴近真实漏洞。

4. 查测试真伪：测的是逻辑还是 mock

AI 生成的测试经常只是「验证某个函数被调用了一次」，把 mock 去掉照样能过，等于没测。

做法：把关键测试里的 mock 全部注释掉再跑一遍，如果照样通过，这个测试就是装饰品。核心模块可以跑一次变异测试，看测试能不能抓到人为注入的 bug。记住：覆盖率不等于有效性。

5. 查重复与漂移：项目里是不是早就有这个函数

AI 看不到你们内部的私有库，所以会再写第二个日期解析、第二个 HTTP 客户端、第二套重试逻辑。半年后没人敢删任何一份。

做法：提交前问它一句「这次改动复用了哪些已有模块？」如果答不上来，就人工搜一遍同类工具函数再决定要不要新增。

把它变成流水线，而不是靠自觉

人只做两件事：确认业务语义对不对、确认这 5 项检查有没有过。其余交给 CI——lint、类型检查、密钥扫描、依赖审计全部卡在流水线里。

另外建议在 commit 信息或 PR 描述里标注「AI 生成 / AI 辅助」，并写明责任人。不是为了追责，而是为了半年后出问题时，能快速判断这段代码当初是怎么来的。

AI 让写代码变便宜了，但线上事故的代价没变。省下的那 10 分钟检查时间，迟早会以十倍的价格还回去。