用 AI 做代码审查：把每一条 review 意见列清楚改到位
它该干啥，不该干啥
先说清楚边界。AI 做 code review，适合查三类问题：明显的 bug（空指针、越界、资源没关）、风格和重复（重复代码、命名不一致）、基础安全检查（硬编码密钥、危险函数）。它不适合替你判断架构要不要这么改、这个需求该不该这么实现——那种得人来。
我把它定位成"第一道过滤网"。人在看 PR 之前，先让 AI 扫一遍，把低级问题消掉，reviewer 的精力就能放在真正要动脑子的地方。说白了，它干的是重复劳动，人干的是判断。边界划清了，它才不会被你拿去干它干不了的事。
把上下文喂足
只贴改动片段，AI 经常看不懂为什么要这么改。我会把三样东西一起给它：改动的 diff、相关函数的完整代码、还有这条 PR 想解决的问题是什么。缺了任何一样，它的意见都会飘。
比如我就说："这是修复登录失败后没记日志的 PR，diff 如下，LoginService 完整代码附后，请重点看异常处理分支有没有漏。"这样它的意见才贴着真实场景，不会泛泛而谈"建议加注释"。上下文越具体，它越不容易瞎建议。
让它按清单输出
我常用的 prompt 是："按'严重程度 / 问题位置 / 具体现象 / 修改建议'四栏给我，分必修和建议两类。"结构化输出比一大段散文好用太多，你直接对着清单改，改完勾掉就行，不用在一段长文里找重点。
还可以让它模拟不同角色：先当严谨的测试工程师挑边界，再当安全工程师挑注入，再当新手看可读性。一轮多视角，比单次提问覆盖得全。我一般在 PR 较大的时候才这么做，小改动没必要这么折腾。
它给的意见，要过一遍脑子
AI 有一个老毛病：为了"显得有用"，会建议你加一些其实不需要的防御、或者改一个没问题的写法。我见过它坚持说某个变量"可能为空"，但上下文里那个变量上一行刚被断言非空。
所以 AI 列的每一条，我都会判断：这条在我这段代码里真成立吗？不成立就跳过，别为了凑改动而改。reviewer 最烦的就是那种"AI 说要改所以改了"的无意义 commit。筛选这一步，才是人价值的体现。
我一般会先扫它标"必修"的，这些通常是真问题、处理成本低；再扫"建议"的，挑和当前代码确实相关的吸收。一轮下来，十分钟能消化完它半小时扫出来的东西，效率差就在这里。要不要改，最后拍板的还是你。
落到实际工作流
我们现在的做法是：PR 一开，CI 里先跑静态检查和 AI review，结果自动评论在 PR 下面。作者先消化一轮，再 @ 人 review。人只看 AI 标"建议"以上、且自己拿不准的点。
说白了，AI 帮你把"看得见的雷"排了，把"说不清的模糊"留给懂得权衡的人。这套分工跑下来，review 来回轮次少了一半，作者也少挨无谓的骂，reviewer 也省了盯着低级错误的眼力。
别指望它替你背锅
最后提醒一句：AI review 的结论，责任还在你。它说"没问题"不等于真没问题，它说"有 bug"你也得自己确认。把它当同事提的建议，不是当裁判的判决。线上出了事，背锅的是写代码和合代码的你，不是模型。
所以我的习惯是，AI 标"必修"的我会逐条处理或逐条反驳，标"建议"的挑有价值的吸收。它再能看，也只是你 review 流程里的一环，不是替代。把它用顺了，你才有空去想那些它永远替你不了的设计取舍。
