先说结论：AI 做 CR 最大的价值不是找 bug，而是统一团队认知。

一开始我让 AI 做 CR，期望它能找出逻辑漏洞、潜在的空指针、竞态条件这些。结果发现，这类深层 bug 它找到的概率大概只有 30%——因为它不懂业务上下文，不知道"这个字段在某些场景下可能为空"。

但它特别擅长的是另一类问题：

1. 规范一致性

   • “这里用了 moment，项目规范要求用 dayjs”
   • “这个函数用了 function 声明，应该用箭头函数”
   • “这个文件没有放在正确的目录下”

2. 模式识别

   • “这段逻辑跟 src/view/member/xxx 里的实现重复了，建议抽成公共方法”
   • “这个 useEffect 缺少依赖项”
   • “这个组件超过 300 行了，建议拆分”

3. 文档补全

   • “这个工具函数缺少 JSDoc 注释”
   • “这个接口的入参类型定义不完整”

这些问题人工 CR 也能发现，但现实是：大部分团队的 CR 流于形式。reviewer 时间紧，看个大概就 approve 了。

AI CR 的真正价值是：它永远不会因为赶工期而放水。

我现在的做法是把 CR 规则也写成 Skill，每次提交自动跑一遍。不是替代人工 review，而是在人看之前先过一遍基础规范。人只需要关注业务逻辑对不对。

一个月下来的数据：

📊 AI代码审查工作流程

下面是AI代码审查与传统人工审查的对比流程图：

🔄 AI CR的价值实现路径

• 规范类问题减少了约 70%（因为写代码时 AI 就已经遵守规范了）
• CR 时间从平均 30 分钟/MR 降到 15 分钟（基础问题 AI 已经过滤了）
• 团队代码风格一致性明显提升（新人也不会写出"老人才知道的潜规则"之外的代码）

💬 你们团队的 CR 是认真做的还是走形式的？（不用不好意思说）