AI Code Review 上线四个月：我们干掉了 37% 的评论，却提升了代码质量

📅 2026/4/26 ✍️ 小文 📖 约 1 分钟

AI 代码评审最大的风险不是漏审，而是噪声淹没一切。本文记录一次真实上线：如何用分类分流、按仓库定制规则、以及一条「评论必须可执行」的铁律，把评审采纳率从 21% 提到 68%。

我们团队在去年底接入了 AI 代码评审。第一个月的情况可以用一个字形容：惨。AI 在 200 个 PR 上留了 1400 条评论，开发者采纳了 287 条，采纳率 21%。更糟的是，大家开始习惯性无视 AI 的评论，包括那些真正重要的。

四个月后，AI 每天的评论数降到了最初的三分之一，但采纳率是 68%，而且线上事故里因为代码问题导致的下降了 40%。

这篇文章讲我们做了什么。

一、第一原则：评论必须可执行

AI 评审最常见的产出是这类评论：

「这段代码可能有性能问题，建议优化。」 「建议增加错误处理。」 「这个变量名可以更清晰。」

这类评论为什么没用？因为它把思考成本留给了开发者。开发者已经写了 300 行代码、脑子很累，看到这种模糊建议的第一反应是「你自己来改」。

我们定的铁律是：每条评论必须包含具体的修改建议，或者至少指出具体的行和具体的后果。

不好：「建议处理 null 的情况。」 好：「第 42 行 user.profile.name 如果 profile 为 null 会抛 TypeError，建议改为 user.profile?.name ?? '未设置'。」

这条规则一上，评论量直接掉了一半，但采纳率翻倍。因为剩下的都是能直接动手的。

二、分类分流：不是所有问题都值得说

我们把 AI 评审的输出强制分成四类，只有两类会进入人工视野：

必修（Must Fix）：会导致运行时错误、安全漏洞、数据丢失。比如 SQL 拼接、未捕获的 Promise rejection、竞态条件。这类直接阻塞合并。

建议（Should Fix）：明显的逻辑缺陷、可读性问题、重复代码。进入评论，但不阻塞。

风格（Style）：命名、格式、注释。不进评论，直接交给 linter 和 formatter 自动修。AI 不该干这事。

看法（Opinion）：架构偏好、要不要加抽象层。不进评论。这类问题 AI 没有足够的项目上下文，说了也是错。

关键动作是给每类配不同的处理路径，并且在 prompt 里明确禁止 AI 输出「看法」类内容。这一步降低的噪声最多。

三、按仓库定制规则

通用规则会制造大量误报。我们有个仓库是老旧的 Python 2.7 遗留系统，AI 一直在建议用 f-string；另一个仓库因为性能要求允许存在提前 return 的写法，AI 一直在说「建议统一风格」。

做法：每个仓库配置一个 .ai-review.yml：

rules:
  ignore:
    - "python-version"     # 关掉版本相关建议
  allow:
    - "early-return"       # 允许提前返回
focus:
  - "security"
  - "error-handling"
severity_override:
  "naming": "ignore"

仓库级规则的最佳来源是误报反馈。我们做了一个「这条评论没用」的按钮，点击率最高的几类规则，直接加到 ignore 列表。

四、上下文工程：让 AI 看到该看的

AI 评审质量差，一半原因是它只看到了 diff，没看到上下文。

我们做了三件事：

  1. 带上完整的函数体，而不只是改动的那几行。很多问题只有看到整个函数才能发现。
  2. 带上相关的调用方。改了函数签名，AI 需要知道谁在调用、怎么调用。
  3. 带上项目约定文档。把「我们的错误处理规范」「日志规范」抽成一份 500 字的 Markdown，每次都放进上下文。

第三项效果意外地好。之前 AI 不断建议「加 try-catch」，看过规范后知道我们用的是统一装饰器，就不再多嘴了。

五、别让它当唯一的守门人

AI 评审不能替代人工评审，我们把它定位成过滤器：

  • 过滤掉 70% 的机械问题（拼写、明显的空指针、遗漏的边界）
  • 让人工评审专心看设计、权衡和业务逻辑

这个定位让评审效率提升而不是下降。之前人工评审要花 40 分钟，其中 25 分钟在找「这段循环边界是不是写错了」。现在人工评审还是 40 分钟，但讨论的都是值钱的东西。

六、四个月的数据

指标第一月第四月
平均每 PR 评论数7.02.3
采纳率21%68%
AI 拦截的必修问题3489
PR 平均评审时长51 分钟38 分钟
因代码问题导致的线上事故5 起3 起

AI 拦截的必修问题数量上升了，因为优化后它能更准确地定位真正的问题，而不是被噪声耽误。

七、三条给准备上车的团队的建议

从必修类开始。先只开「会导致运行时错误和安全漏洞」的检查，跑一个月，建立信任，再逐步扩展。一次性全开的团队，基本都在两周内关掉了这个功能。

把采纳率当核心指标。它比「评论数」和「问题发现数」更能反映真实价值。采纳率低于 40%，说明你在制造噪声。

留一条人工反馈回路。每一类规则都要能一键标记「无效」，并按月复盘。AI 评审是个需要持续调优的产品，不是设完就忘的开关。

🏷️ #AI编程#Code Review#研发效能#工程实践#AI工具
📤 分享到