AI 代码评审机器人：建议要可解释，不要只会挑刺

一、代码评审机器人不能只刷存在感

AI 代码评审机器人很容易变成评论制造机。变量名不优雅、函数太长、建议加注释、这里可能有问题，一口气刷十几条。看起来很勤快，实际开发者会很快免疫。评审工具的目标不是显得聪明，而是发现真正影响质量、稳定性和安全性的风险。

好的 AI Review 应该可解释、可定位、可行动。它要说明为什么这是问题，影响范围是什么，建议怎么改，置信度有多高。只会挑刺的机器人，会让团队把它当噪声关闭。

二、评审流程要先做变更理解

AI Review 不能只看单个 diff 行。它需要理解变更意图、调用关系、测试覆盖和历史上下文。

flowchart TD
  A[代码变更] --> B[提取 Diff]
  B --> C[理解变更意图]
  C --> D[风险分类]
  D --> E[生成评审建议]
  E --> F[置信度过滤]
  F --> G[发布评论]

没有置信度过滤，机器人就会把猜测也发出来。低置信度内容可以进入内部报告，不一定要打扰开发者。

三、建议要结构化输出

下面是一个评审建议结构。

type ReviewComment = {
  file: string;
  line: number;
  severity: "blocker" | "warning" | "nit";
  reason: string;
  suggestion: string;
  confidence: number;
};

function shouldPublish(comment: ReviewComment) {
  return comment.severity === "blocker" || comment.confidence >= 0.8;
}

严重级别要谨慎。阻断项应该留给真实 bug、安全漏洞、兼容性破坏和明显测试缺失。风格建议不要伪装成高风险问题。

四、机器人要学习团队规则

每个团队的代码规范、框架约定和发布流程都不同。AI Review 如果不接入项目规则，很容易给出泛泛建议。比如一个仓库禁止直接访问某个底层 API，另一个仓库可能允许。上下文不同，结论就不同。

还要让开发者能反馈。误报、已接受、不适用、建议有用，这些反馈可以帮助后续过滤。没有反馈闭环，机器人只能一直重复同样的噪声。

测试建议要具体。不要只说“缺少测试”，而要指出哪个分支、哪个错误路径、哪个边界输入缺覆盖。开发者最需要的是下一步动作，不是道德压力。

最后，AI Review 要尊重人类评审。机器人适合做第一轮扫描和风险提示，架构取舍、业务语义、长期可维护性仍然需要人工判断。工具越强，越要把边界讲清楚。

落地时还要处理评论频率。一个 PR 里机器人最多发多少条、同类问题是否合并、低风险建议是否折叠，这些规则会直接影响接受度。开发者愿意看，工具才有机会产生价值。

AI Review 还要和 CI 结果联动。测试失败、类型检查失败、依赖扫描失败时，机器人应该优先解释失败原因，而不是继续输出风格建议。当前最阻塞的问题是什么，工具要分得清。

最后，评审数据要反哺工程规范。哪些问题反复出现，说明团队需要 lint 规则、脚手架模板或基础库封装，而不是让机器人每天提醒。AI 评论只是症状，制度化修复才是收益。

权限也要控制。代码评审机器人通常能读取仓库、PR、评论和 CI 结果，不应该默认拥有写代码、改配置或触发生产发布的权限。评审工具越自动，越要把它限制在“建议者”角色里。

对安全问题，还要避免公开泄露细节。发现密钥、漏洞利用路径或权限绕过时，机器人可以创建私密告警，而不是直接在公开 PR 评论里贴完整细节。评审也要懂安全边界。

五、总结

AI 代码评审机器人要从评论数量转向评论质量。变更理解、风险分类、置信度过滤和团队规则接入是关键。建议要可解释、可行动，少刷存在感，多抓真正会出事的问题。