一句话结论：AI 代码审查的正确姿势，是让智能体先做机械扫描（风格、类型、缺失的错误处理、重复工具函数），人只保留”追溯关键路径 + 盯安全边界”这两件不可自动化的判断工作。按本文的 6 步流水线配置，一个常规 PR 的人工审查能从 10 分钟压到 4～5 分钟，漏检反而更少。
一、为什么”让 AI 看一遍”不够用
很多团队把 AI 审查做成：合并前丢给模型问一句”这段代码有问题吗”。这有三个硬伤：模型拿不到你的业务约束，它不知道哪些是”我们刻意这么写的”；它的反馈没有优先级，几十条评论里混着真 bug 和风格洁癖；最关键的是它不会替你判断”这次改动会不会影响线上那条核心链路”。
GitHub 官方在《 Agent pull requests are everywhere 》里给的判断很直接：代码面积在涨、 PR 数量在涨，应该压缩的是你扫样板代码的时间，而不是你脑子里那套没写下来的系统上下文——那才是审查真正的价值所在。
| 环节 | 擅长者 | 原因 |
|---|---|---|
| 风格一致性、类型不匹配、明显逻辑错 | AI 自动审查 | 规则明确、可批量、无需业务上下文 |
| CI 配置是否被削弱 | 人（硬停项） | 涉及交付体系的可信度，AI 不知道团队红线 |
| 新增工具函数是否重复造轮子 | AI + 人复核 | AI 负责全库搜索，人判断是否该复用 |
| 关键路径端到端追溯 | 人 | 需要边界条件、权限、异常分支的业务认知 |
二、 6 步审查流水线（每步都给了时间预算）
- 第 1～2 分钟：扫文件列表和 diff 体积，先分类——是”窄任务”（文档、 CI 、小改动）还是”复杂任务”（多文件、逻辑、性能、测试）。分类决定后面投入多深。
- 第 2～3 分钟：先看 CI 改动。任何碰到 .github/workflows 、测试配置、覆盖率阈值、构建脚本的改动都优先看；凡是削弱 CI 的直接打回。
- 第 3～5 分钟：让 AI 扫新增工具函数/helper/module，对每一个做一次全仓库重名搜索，标记重复实现。
- 第 5～8 分钟：挑最核心的那条逻辑改动，端到端走一遍：输入 → 变换 → 输出，重点看边界条件、权限校验、异常分支。这步不能省。
- 第 8～9 分钟：如果 PR 会调用大模型或处理不可信输入，过一遍安全清单——工作流 YAML 用最小权限（read-all 是合理默认）、不可信内容进提示词前先清洗转义、分析步骤和执行步骤分离、绝不 eval 模型输出。
- 第 9～10 分钟：要求证据。非平凡的逻辑改动必须附一个”改动前会失败”的测试；高风险改动没有回滚方案就要求补上。
三、怎么把你的清单固化成自动检查
GitHub 工程师分享过一个小技巧：与其每次靠记忆跑同一套检查，不如用 Copilot SDK 把个人清单（管理端接口是否鉴权、测试是否真跑、环境变量处理是否安全）写成工作流，自动跑在 diff 上，发现致命问题直接拦住合并。
落地思路：把团队红线写成一份 REVIEW_RULES.md，让智能体在每次 PR 时对照输出”命中/未命中”，你只复核命中项。配合 Claude Code Hooks 这类机制，还能把规则变成提交前的强制动作。
自定义审查指令示例（可直接抄）
四、太大的 AI PR 怎么办
智能体最容易产出”一个 PR 改 20 个文件”的巨型 diff，人类根本看不动。 GitHub 的做法是把它拆成可审查的 stack：数据层、 API 层、接线层、 UI 层各一个 PR，每层单独跑 CI，按 CODEOWNERS 分派给对应负责人。
- 要求智能体严格限定单一职责，一次只做一层；
- 每层都有独立 CI，审查只针对本层；
- 触发”该拆了”的信号：diff 超过 5 个不相关文件、一句话说不清 PR 目的、 PR 描述为空、 CI 红了但 diff 里只改了测试文件。
更多关于 AI 编程智能体的协同方式，可参考 GitHub Copilot coding agent 与 Copilot 和 Claude Code 怎么选。
五、三个常见误区
- 把 AI 审查当审批：它给的是线索，不是结论；最终合并责任永远在人。
- 不设硬停项：CI 被削弱必须无条件打回，这是唯一不该讨价的红线。
- 要求 AI 输出越多越好：噪音会淹没真问题，宁可要 3 条高置信度发现。
评论 (0)