AI Code Review 实战：规则、提示词与边界

今年做了一次尝试：

不改变现有流程的前提下，让大模型参与到 Code Review 里，当一个「辅助 reviewer」。

它不会替代人类审核，只做三件事：

• 帮忙找明显 bug / 边界问题
• 帮忙发现重复逻辑、代码味道
• 帮忙写结构化的改进建议

1. 我们希望 AI 扮演什么角色？

一开始就想清楚边界：

1. 不负责通过/拒绝 PR

   • 不修改状态，只给评论和建议
   • 最终决策仍然是人类 reviewer

2. 关注「模式」而不是细枝末节

   • 比如错误处理缺失、越界风险、循环里请求等
   • 而不是变量名叫 a 还是 data

3. 输出要尽量具体

   • 指出文件、位置、问题和建议
   • 避免空话：「可以优化」「可以重构」这种直接过滤掉

2. 整体方案：在 CI 里多插一段「AI Review」

流程：

1. CI 获取本次 PR 的变更文件 + diff
2. 对每个文件构造一个「上下文 + diff」的 payload
3. 调用大模型，让它产出结构化的 review 结果
4. 再由机器人账号把评论贴回 PR（或者汇总成一条）

为控制成本和复杂度：

• 优先只分析变更行附近的代码
• 超长文件只截取相关片段

3. Prompt 设计：告诉 AI「只看这四件事」

一个简化的系统提示大致是：

你是一名资深前端/全栈工程师，正在做 Code Review。
请只关注以下问题：

1. 明显的 bug 或潜在边界问题
2. 异常处理和错误提示是否合理
3. 性能隐患（多余循环、重复请求等）
4. 安全/权限风险

不要评论代码风格、缩进、单双引号之类的问题，这些交给 Lint 工具。

输出 JSON：

{ "comments": [ { "file": "", "line": 0, "severity": "info|warning|error", "comment": "", "suggestion": "" } ] }

然后把类似下面的内容作为用户输入：

{
  "changes": [
    {
      "file": "src/components/UserForm.tsx",
      "diff": "...",
      "content": "..." // 必要时提供片段
    }
  ]
}

4. 降噪：不让 AI 把 PR 评论刷爆

第一版的体验是「AI 太热情」，几乎每段代码都要说两句。
优化手段主要有三类：

1. Prompt 里强调「只输出你认为最重要的 3～5 条建议」
2. 引导把相似问题合并成一条（比如相同模式的空值判断）
3. 在后处理里过滤：
   • severity = info 且内容过泛的建议直接丢弃
   • 连文件/位置都不明确的建议丢弃

这样下来，评论量基本控制在「有用但不吵」的范围。

5. 几种典型的「有用建议」

实战中，AI 比较擅长抓这些点：

1. 缺少错误处理

submitForm 中调用接口失败时没有任何提示，建议增加错误提示和按钮状态恢复，否则用户会以为点击没反应。

2. 越界 / 空值风险

在通过 userList[index] 访问数据时没有检查 index 合法性，当 index 来自路由参数时可能出现越界错误。

3. 重复逻辑

createUser 和 updateUser 中存在完全相同的参数校验代码，建议提取成工具函数，避免后续修改不一致。

4. 异步流程问题

fetchUserDetail 未处理加载过程中的中断或组件卸载，可能出现「请求返回后组件已卸载」的异常 log。

这些其实都是人类 reviewer 也能看出来的东西，但在时间有限时容易漏，看成「AI 帮我补盲区」就比较舒服。

6. 边界：哪些事情不该交给 AI

我们明确把这几类事情排除在 AI 职责之外：

1. 架构层级决定

   • 要不要拆模块、引入新依赖、换技术栈
   • 必须结合团队整体规划讨论

2. 业务规则正确性

   • 金融、合规等领域细节
   • AI 不懂具体监管要求，再聪明也只能猜

3. 敏感安全策略

   • 是否打开某个接口、是否信任某个参数
   • AI 的意见最多当作「提醒」，不能作为依据

Prompt 里会补充一句：

对不确定的地方，只能提示「可能存在风险」，不要给出肯定结论。

7. 团队落地：怎么让大家愿意用？

几个实践：

1. 明确标识 AI 评论

   • 用单独机器人账号或给评论加 [AI] 前缀
   • 让大家一眼知道这是机器说的

2. 可选而不是强制

   • 紧急修复、特别小的改动可以跳过 AI Review
   • 避免给研发多加形式主义负担

3. 持续收集反馈

   • 哪些评论有帮助
   • 哪些太啰嗦、太不靠谱
   • 定期根据反馈调整 Prompt 和过滤规则

最终效果是：人类 review 更聚焦业务和设计，AI 补充细节和模式识别。

8. 小结

这次实践下来，我对「AI + Code Review」的预期大概是：

• 它不会让你瞬间变成更好的工程师
• 但会帮你少漏一些本来就应该注意到的问题
• 前提是你要把边界、规则、流程设计好，而不是一句「接个 API」就完事

如果你也想试试，可以先从最轻量的形式开始：

1. 离线生成 review 报告，不直接评论 PR
2. 手动挑几次看看建议质量
3. 觉得靠谱之后，再接入到 CI + 机器人评论

这样风险可控，也更容易被团队接受。