目录一、它确实能抓到的 5 类二、它基本抓不到的 3 类三、怎么问才有用四、放进流程的两个位置五、几个实际的坑六、什么情况下不用它小结让 AI 审查代码最容易得到的是一堆正确的废话「建议添加错误处理」「变量命名可以更清晰」「建议补充单元测试」这些话对任何一段代码都成立等于没说。用了一段时间之后我发现问题不在于 AI 不会 review而在于大多数人给它的信息不足以做出有价值的判断。它只看到了你改动的那几十行看不到这些行在项目里意味着什么。这篇说清楚三件事它实际能抓到哪几类问题、哪几类根本抓不到、以及怎么问才能拿到有用的结果。一、它确实能抓到的 5 类第一类改动的影响面遗漏这是我认为最有价值的一类前提是工具能看到调用关系。典型场景你改了一个函数的返回值语义本文件内所有调用点都更新了但另一个包里通过接口间接调用的实现没动。编译能过接口签名没变测试也过那条路径没覆盖。这类问题人工 review 很难发现因为它不在 diff 里。reviewer 看到的是你改的那几个文件那个漏掉的实现根本不在视野内。能不能抓到这类问题取决于工具是否掌握调用关系。如果它只能看到 diff 文本那和人工 review 的视野是一样的自然也发现不了。我现在提交前会做一次自检git:changes 这次改动有没有遗漏的调用方 特别检查通过接口间接调用的地方。wescode 能看到 diff也能看到这些改动涉及的调用关系所以这个问题它答得比较实。抓到过两次真问题一次是改了函数签名漏了接口实现一次是改了返回值语义但没更新依赖这个顺序的下游。第二类和项目既有写法不一致错误处理方式、命名规范、分层约束这些。比如全仓都用errors.Wrap你这次用了fmt.Errorfhandler 都是Handle开头你写了个processXxx。这类问题的特点是单看这段代码完全正确放在项目里才不对。所以 AI 必须知道项目的既有写法光看 diff 判断不了。我在 wescode 里做这步不用额外交代规范——它会对照项目里已有的写法而不是通用的「最佳实践」。这个区别挺重要通用最佳实践有时候和项目现状是冲突的按前者改反而制造了新的不一致。第三类机械性的疏漏这类它抓得又快又准新增的错误分支没有对应的测试改了函数签名但注释还是旧的加了配置项但文档没更新日志里打了不该打的字段资源申请了没有对应的释放这些都是「有模式可循」的不需要理解业务就能发现。人工 review 也能抓但容易累了就漏AI 不会累。第四类边界条件没处理空值、空集合、零、负数、越界、并发写。AI 对这类情况相当敏感因为训练数据里这类 bug 太多了。我会专门问一句这次改动新引入的分支有哪些输入会走到没处理的路径 只列你确信没处理的不要罗列所有可能性。最后那句很重要。不加的话它会把所有理论可能性都列一遍一半是噪音。第五类安全上的低级错误SQL 拼接、硬编码密钥、日志打印敏感信息、路径拼接没校验。这几类它识别率很高。不过要注意这只覆盖了「模式明显」的部分。复杂的权限逻辑漏洞它看不出来下面会说。二、它基本抓不到的 3 类这部分比上面更重要。知道边界在哪才不会把 AI review 当成免检通行证。第一类业务逻辑对不对这是最根本的限制。比如折扣计算代码写的是先打折再加运费。AI 看不出这有什么问题——从代码角度它完全合理。但如果业务规则是运费不参与折扣、且应该先加运费再整体打折那这段就是错的。AI 只能从代码推断意图而代码可能正好把意图写错了。这类问题只有懂业务的人能发现或者靠明确的需求文档和测试用例。我的做法是涉及核心业务规则的改动AI review 只当辅助人工 review 不能省。第二类这个改动该不该做AI 会告诉你这段代码写得怎么样不会告诉你这段代码不该存在。比如为了一个边缘场景加了一层抽象代码质量没问题但引入的复杂度不值得。或者这个功能其实和已有模块重复了应该复用而不是新写。这类判断需要对项目演进方向的理解AI 给不出来。第三类历史原因造成的约束那段看起来多余的判断可能是三年前踩过坑加的补丁。AI 看到的是「这个 if 永远为真建议删除」但删了线上就炸。这类信息在 git blame 和当年的 issue 里不在代码结构里。所以 AI 建议删代码的时候我一般会先看一眼 blame。wescode 能告诉我这段代码被谁调用、改了会影响什么但回答不了「当年为什么要加这个判断」。结构问它历史问 git这个分工得拎清楚。三、怎么问才有用给 diff不要给整个文件review 的对象是改动不是全部代码。给整个文件它会把无关的既有代码也评论一遍噪音很大。git:changes 帮我 review 这次改动这样它聚焦在变化上。改动分散在多个文件时这个方式比一个个贴文件方便得多。明确要求「不确定就说不确定」这条能大幅减少废话review 这次改动要求 - 只报你确信有问题的地方不确定的标注「需人工确认」 - 不要提「建议加注释」「建议补测试」这类通用建议 - 每个问题说明在哪、为什么是问题、怎么改 - 如果没发现问题就直接说没发现最后一句很关键。不加的话它总要挤出几条建议来哪怕代码没问题——模型有「必须给出有用回答」的倾向你得明确告诉它「没问题」也是合格答案。分轮次别一次问全部一次让它同时看逻辑、性能、安全、风格每样都浅尝辄止。分开问效果好得多第一轮这次改动有没有遗漏的调用方或影响面 第二轮新引入的分支有哪些边界情况没处理 第三轮和项目既有写法有没有不一致的地方三轮下来比一轮问全面得多成本也没高多少。四、放进流程的两个位置位置一提交前自检这是我用得最多的。写完git add之前在 wescode 的 Chat 里让它扫一遍改动。好处是这时候还没推上去发现问题改起来没有心理负担。抓到的多是机械性疏漏——漏更新的注释、忘了的测试、不一致的写法。位置二review 别人的 PR 之前拿到一个大 PR先让 AI 过一遍把机械性问题列出来。然后我自己的注意力就可以集中在业务逻辑和设计上——那正好是 AI 抓不到的部分。这个分工我觉得是对的AI 负责「有模式可循」的部分人负责「需要判断」的部分。反过来用就危险了让 AI 判断业务逻辑对不对自己只看格式那是把两边的长处都浪费了。五、几个实际的坑它倾向于挑出问题哪怕没有前面提过模型有给出「有用回答」的倾向。如果代码确实没问题它可能会编几条无关痛痒的建议。所以看到「建议优化变量命名」这类时直接忽略就行别真去改。判断标准是这条建议有没有说清楚「为什么现在这样是问题」。说不清楚的基本都是凑数的。大改动会漏一次改了二十个文件让它一次 review 完后面的会明显变敷衍。改动大的话拆开分批看。它不知道你的测试覆盖情况它说「这个分支需要测试」但可能已经有测试了只是在另一个文件里。这类建议要自己核实一下再动手。六、什么情况下不用它改动特别小的时候。改一行配置自己看一眼比走一轮流程快。纯业务规则的改动。前面说了这是它的盲区找产品或者业务方确认更靠谱。已经有完善 lint 和 CI 的项目。机械性问题 lint 已经拦住了AI 再扫一遍收益不大。这种情况下它的价值主要在影响面分析上。小结AI 做 code review 的实际价值我觉得可以概括成一句它替你完成「需要耐心但不需要判断」的那部分。漏掉的调用方、不一致的写法、没处理的边界、忘了更新的注释——这些人工也能发现但需要逐行盯着看累了就会漏。AI 不累这部分交给它很划算。但涉及判断的部分——业务对不对、这个设计该不该做、这行代码为什么当年要这么写——它给不出可靠答案。这些仍然是人的工作而且应该是 review 时真正投入注意力的地方。把 AI review 当成一道前置过滤而不是终审这个定位比较合适。文中用到的 diff 引用和调用关系检查都是在 wescode 里做的官网是 weisyn.com。你们把 AI 放进 review 流程的哪个环节效果如何欢迎评论区交流。
