给 AI 做 Code Review：审查清单与对话话术模板

AI Review 能做什么、不能做什么

AI 适合做第一轮：找明显 bug、风格不一致、缺失测试、可疑权限逻辑。它不适合做最终责任人：业务正确性、产品取舍、合规签字仍须人类承担。

把 AI 当「不知疲倦的初级审查员」，而不是「自动合并机器人」。

推荐审查维度

按 diff 过一遍：

1. 正确性：边界条件、空值、并发与重试

2. 安全：鉴权、注入、敏感信息（可对照 API 安全清单）

3. 可读性：命名、函数长度、是否过度抽象

4. 测试：是否覆盖关键路径与失败路径

5. 性能：明显 N+1、无界循环、过大同步 IO

6. 一致性：是否符合仓库 Rules / Skills 约定

对话话术模板

把下列模板存成 Skill 或固定 Prompt：

「你是本仓库的审查员。只根据提供的 diff 发言。输出结构：必须修改 / 建议修改 / 可选优化。每条指出文件与理由。不要重写无关文件。若信息不足，先列出需要我补充的问题。」

然后粘贴 diff 或指出分支。比「帮我看看代码行不行」有效得多。

工作流建议

个人开发

提交前本地让 AI Review 一轮，自行消化「必须修改」；再开 PR。

团队

• CI 可跑静态检查；AI Review 作为可选机器人评论
• 人类 Reviewer 聚焦业务与架构，不重复抠格式
• 争议项以团队 Rules 为准，而不是模型口吻

防幻觉技巧

• 要求「引用具体行或符号」，禁止空泛「建议优化性能」
• 对「必须修改」项要求给出反例或复现思路
• 不把 AI 的「看起来安全」当成渗透测试结论

与 Skills 的结合

将审查维度写成 code-review Skill，并在反模式中写明：禁止为了让 CI 绿而删除测试；禁止引入未讨论的新依赖。格式见 SKILL.md 指南。

在 RuleHub 搜索 可发现社区 review 类 Skills，合入前改成你们的语言与严重级别定义。

度量

观察两周：

• PR 首轮人类评论中「低级问题」是否减少
• 回滚或热修次数是否变化
• 审查耗时是否下降（而不是上升——若上升说明话术或范围失控）

小结

AI Code Review 的价值是压缩低级错误与统一视角，不是取代工程师判断。用结构化输出、人工终审、Skill 固化标准，才能形成可持续的质量闸门。

下一步：选一个中等大小的 PR，用本文话术跑一遍，把反复出现的问题写进团队 Rules。