给 AI 代码做评审：5 个检查点，省 3 轮返工

AI 写代码的效率已经不用再争论，真正让人头疼的是返工。把生成结果直接合进主干，问题往往两周后才爆出来，而那时的修复成本是当场发现的十倍。下面 5 个检查点，是我在实际项目里反复用、也确实能省下几轮返工的。

一、先看 import 和依赖，再看业务逻辑

AI 最容易幻觉的地方不是算法，而是「这个库存在」和「这个函数有这个参数」。所以打开 diff 第一件事不是读循环体，而是扫一遍新增的 import 与依赖版本。

具体动作：对每个新包，在本地 pip show / npm view 跑一次，确认包真实存在且版本支持你调用的 API；遇到不常见的包名，去官方仓库核对，不要只信 AI 附上的说明（说明文字同样可能是编的）；顺手看一眼 License，MIT 和 AGPL 在商用场景完全是两回事。

安全圈把「AI 编出不存在的包名、攻击者抢先注册」这套手法叫 slopsquatting。你不必记住这个词，但要养成「新依赖必验证」的习惯。

二、边界条件，让 AI 自己说「不处理会怎样」

生成的函数通常主路径很漂亮，空值、超长输入、并发、超时全是空白。与其自己找，不如直接问它：

「列出这个函数在输入为 null、空数组、10 万条数据、网络超时四种情况下的行为，并指出哪些没处理。」

它会给你一份自查表，你照着补。这比「帮我加错误处理」有效得多，因为它必须先承认缺口。其中超时与重试要重点盯，AI 默认写法经常是无上限重试。

三、测试不能让写代码的人自己出题

让同一个模型既写实现又写测试，等于让考生自己出卷子，它只会测自己写对的部分。做法是拆开：

• 用另一个模型或新开会话，只给函数签名与注释，让它写测试；

• 你至少手工验算 2 个用例，尤其是金额、权限、时间这类算错后果严重的逻辑；

• 比起覆盖率，更该看断言是否有意义，assert result is not None 这种等于没测。

四、把「自信陈述」翻译成可验证命令

AI 说「这样性能更好」「这是线程安全的」，都属于待验证假设，而不是结论。把它转成命令：

• 性能：写个最小 benchmark，或至少打印耗时做前后对比；

• 并发：查清共享状态在哪、锁加在哪，别只看注释；

• 安全：用 gitleaks 扫密钥、semgrep 跑规则集，硬编码 token 与字符串拼接 SQL 的命中率很高。

跑一遍静态检查通常只要几十秒，比事后回滚便宜太多。

五、沉淀团队级提示词与 PR 清单

个人技巧不可复制，清单可以。把前四条整理进 PR 模板：

1. 新增依赖是否逐一验证过？

1. 边界条件自查表是否附在描述里？

1. 测试是否由独立会话生成、是否人工验算？

1. 静态检查与密钥扫描是否通过？

再把项目常用的技术栈、目录约定、错误码规范写进系统提示词。新人照着走，第一周就能产出可以直接进评审的代码，而不是一堆需要老手重写的片段。

结语

AI 编码的瓶颈早就不是「能不能写出来」，而是「敢不敢合并」。多花十分钟做上面五件事，换掉的是两周后的深夜排查。