引言
代码评审，这件开发者最熟悉也最容易敷衍的小事，正在被 AI 悄悄改变。过去，评审靠的是资深工程师的直觉、经验和”看得不顺眼”的警觉；而现在，AI 可以在你提交 PR 的几十秒内，扫完几千行代码，标出潜在 bug、风格问题甚至安全隐患。于是问题来了：当一个”永不疲倦的评审人”坐在工位上，人类评审还剩下什么不可替代的价值？这篇文章聊聊我的思考与实践。
AI 评审：把”例行公事”交给机器
最早用 AI 做代码评审，我的第一反应是”它还太嫩”——它会为了讨好你而漏掉关键问题，也常常把”建议性优化”当成”必须修复的缺陷”来大呼小叫。但用久了你会发现，AI 真正擅长的恰恰是那70%我们其实很想省略的例行工作：命名是否规范、边界条件有没有漏、有没有复制粘贴的重复逻辑、注释与代码是否脱节。
这些单靠肉眼看不出效率的琐碎问题，恰恰是拉高评审”拖延症”的元凶。当 AI 先把这层”机械劳动”做掉，人类评审者就能把注意力从”挑毛病”转向”看架构”，从”这段代码能不能跑”转向”这会引入什么长期债务”。我慢慢意识到，AI 评审的价值不是替代人，而是帮人省下精力，用在真正需要判断的地方。
人机分工：判断力才是护城河
AI 有个隐蔽的软肋：它擅长”局部正确”，却很难看清”全局语境”。它知道你这段函数写得对不对，却未必知道你为什么要这样权衡性能与可读性——因为那个”为什么”只存在于你和需求方开过的会、踩过的坑里。而这，恰恰是资深工程师最值钱的能力。
于是在我的工作流里，评审被拆成了两层：第一层交给 AI 做”硬校验”——安全检查、错误处理、边界测试、代码规范，这层确定性高，AI 足够可靠；第二层留给人做”软评审”——这段设计的商业假设是否成立、接口是否符合长期演进方向、是否与团队风格一致。把这两层分开，既不会错过低级错误，也不会让人被海量琐碎评论淹没。
有意思的是，当人从”盯细节”里解放出来，团队里原本不爱发言的同事也开始愿意贡献观点了——因为评审终于变成了”聊设计”而不是”被挑刺”。环境的氛围，比想象中更依赖工具的引导。
别让 AI 评审变成新的”形式主义”
任何工具都会制造新的惯性。AI 评审也不例外：它那种”每条都标注建议”的输出方式，很容易让人养成”直接全员通过”的被动习惯，或者反过来，把每个 AI 建议都当真、一个个机械地改到代码”面目全非”。这两种都背离了初衷。
我的原则是：把 AI 的建议当作”提醒”而非”判决”。看到它指出的问题，先问一句”这里为什么会这样写”，而不是立刻照改。很多时候，一个看起来是疏漏的地方，背后是刻意的权衡；改掉它，可能就破坏了原本的设计意图。评审的最终目的是让代码更健壮、更容易维护，而不是让工具指标变好看。守住这个底线，AI 才从”监督者”变成真正的”协作者”。
结语
技术会不断演进，今天帮我们审代码的 AI，明天可能还会帮我们审架构、审方案、审需求本身。但一套好的实践永远是相通的：把确定的交给机器，把不确定的留给人，然后用人类的判断力为最终结果负责。当工具帮你扫清了”低垂的果实”，真正考验你的，就只剩下那些”高度的问题”了。而这，既是挑战，也是机会。