引言

上周我在修改 trae-novel 项目的 dev 分支功能时，本来打算改完直接提交，刚好用 AI 编码助手跑了一遍只读审查，结果直接揪出 3 个高风险问题、5 个中风险问题，要是直接提交估计得线上踩好几个坑。这次审查我特意要求 AI 遵循 using-superpowers 和 requesting-code-review 的核心思路：全程只读不改，不直接修改任何代码，所有结论都整理成「确认后直接改」的格式。整个过程踩了不少小坑，也总结出不少可复用的经验，今天把完整过程拆解给大家。

一、审查前的环境对齐：AI 怎么绕过「本地代码不全」的难题？

这次审查的第一个拦路虎就是环境适配问题。我本地仓库当时只有 main 分支，而需要审查的 dev 分支代码还在远端 GitHub 上，甚至工作区里还有刚改完还没提交的本地代码。AI 一开始尝试直接读取远端 dev 分支元数据和文件列表，发现本地没装只读权限的 GitHub CLI，于是先重跑安装并捕获输出避免安装卡住，还尝试用浏览器技能直接打开 GitHub 的 dev 分支页面只读抓取文件列表，最终成功拿到了远端分支的元数据。
更麻烦的是测试环境的问题：AI 一开始默认跑了本地 test 环境的测试，结果所有用例都报错，后来才发现项目约定的是 novel 环境，切到对应环境后才跑通了和本次改动相关的回归测试。这个小细节其实很多开发者容易忽略：AI 做审查的前提是环境和本地开发环境对齐，不然跑出来的测试结果全是无效的。

二、只读审查的分级逻辑：先分风险，再找问题

环境对齐后，AI 并没有一上来就堆问题，而是先做了分层校验：首先补跑和本次改动相关的回归测试，排除新引入的功能回归；然后做最后一轮静态校验，重点确认主干接口里已经挂载了 anchor 路由——这个校验刚好揪出了第一个高风险问题：本次改动的路由没有正确注册到主干接口里，要是上线的话相关功能会直接不可用。
值得一提的是，这次审查的对象是工作区还没提交到 dev 分支的代码，AI 直接基于未提交的改动做了只读审查，相当于提交前又多了一层校验，比提交之后再回滚修改的成本低太多了。最后 AI 把所有问题分成了高风险、中风险、建议修改、验证项、补充项五个等级，还额外按 P0/P1/P2 排了优先级：P0 是必须马上改的阻塞性问题，P1 是影响功能但不阻塞的，P2 是体验优化类的。

三、从审查结论到落地：怎么让 AI 的 review 真正生效？

很多人做 AI 代码审查容易犯的错是：拿到一堆问题列表就完了，最后改的时候还是不知道先改哪个。这次 AI 的审查结论刚好避开了这个问题：所有问题都按「整体、实现方案、P0 优化点、P1 优化点、P2 优化点」的结构整理，我拿到手直接先改 P0 的 anchor 路由注册问题，再处理 P1 的参数校验问题，最后改 P2 的注释不规范问题。而且 AI 还单独列了验证项：改完 P0 问题之后要重新跑一遍路由注册的测试，确认改动生效，避免了改完又出新的问题。

结尾

这次审查下来，我总结出 3 条可带走的方法论：

1. 用 AI 做代码审查前先对齐环境，确保测试环境、分支信息和本地开发一致，避免无效的审查结果；
2. 强制要求 AI 输出分级风险结论，优先处理 P0 级的高风险问题，不要被一堆低优先级问题分散注意力；
3. 提交前可以用 AI 对未提交的代码做只读审查，提前发现问题，比提交之后再回滚的成本低得多。
   如果你的项目也在用 AI 做代码审查，不妨下次试试先对齐环境、再要分级结论，说不定能省不少踩坑的时间。