AI 代码审查

Pull Request 需要 人审；AI 可以当 第二读者：找明显 bug、风格问题、遗漏测试。合并权、线上责任仍在人类 reviewer——AI 建议不可一键信任。

学习目标

• 设计「人工 + AI」双审流程
• 会用 AI 读 diff，但保留测试与静态分析兜底
• 衔接 testing-essentials 的验收观念

为什么 AI 不能替代 Code Review

• 看不到 完整产品意图 与历史决策
• 对 安全边界（权限、注入）常过于乐观或漏报
• 幻觉：编造「已覆盖测试」或不存在的方法

AI 适合：初筛、清单提醒、措辞更好的 review comment 草稿。

推荐双审流程

作者：小 PR + 本地绿测 + 自审 diff
     ↓
AI：  「列出此 diff 的风险点、缺测试处、命名问题」（不含 secrets）
     ↓
人：  逐条验证 → 跑 CI → Approve / Request changes
     ↓
合并：遵循 git-merge 与分支保护

与 git-remote 的 PR 文化一致：AI comment 也要被人类采纳或驳回。

给 AI 的有效 review prompt

这是 PR diff（已脱敏）。请：
1. 列潜在 bug 与边界情况
2. 指出是否缺单元测试（对照 test-pyramid）
3. 不要假设已跑 CI；不要建议提交密钥
输出 bullet，每条标注置信度 high/medium/low。

low 置信度 项往往最多——人工快速扫即可丢弃幻觉。

与测试衔接

AI 说「应该没问题」≠ 绿测。权威顺序：

1. 本地 / CI 测试（test-ci）
2. 静态分析、lint
3. 人类逻辑审查
4. AI 摘要 仅供参考

缺测试时，可让 AI 起草 test-mockito 风格用例，你改断言。

审查讲义 PR

draft 须核对 /tracks/... 链接、代码示例与仓库一致；禁止 暗示 Copilot/Cursor 可免审发布。AI 查术语，事实 由 maintainers 负责。

练习

• 选一个小 PR diff，让 AI 列 5 条风险，逐条标记真/假
• 写团队约定：哪些文件 AI review 必跑、哪些禁止上传云端

小结

AI 是 review 助手，不是 LGTM 按钮；测试与人是最终门禁。 下一课 AI 辅助重构与迁移。