一、引言：AI 写代码的速度越快，Review 越重要
AI 编程工具正在改变软件开发的生产方式。
过去，开发者需要花费大量时间编写代码，Code Review 的主要任务是检查代码是否存在 Bug、是否符合规范，以及是否影响现有系统。
如今，Claude Code、Codex 等 AI 编程工具可以在很短时间内完成大量代码修改，甚至通过多个 Agent 并行开发不同模块。
代码生产效率大幅提升，但随之而来的问题也越来越明显：
- 代码生成速度超过了人工审查速度。
- 开发者容易接受 AI 给出的看似合理、实际存在问题的实现。
- 多个 Agent 并行开发，增加了模块之间的兼容性风险。
- AI 能够生成测试代码，但测试通过不代表业务逻辑正确。
- 开发者容易陷入 AI 编写、AI 审查、AI 修改的无限循环。
- 代码变更越来越频繁，传统依赖人工逐行阅读的 Review 模式难以持续。
因此，AI 时代需要重新思考 Code Review 的定位。
Review 不应该只是代码提交之后的一道检查程序，而应该成为贯穿需求分析、代码开发、自动化验证、合并发布和线上监控的完整质量保障体系。
本文结合 Anthropic Claude Code 团队公开的工程实践，总结一套值得借鉴的 AI 时代 Code Review 方法论。
核心理念：
让 AI 负责规模化检查，让自动化工具负责客观验证，让人类负责关键决策和风险控制。
二、重新认识 AI 时代的 Code Review
传统 Code Review 主要依赖开发者之间互相阅读代码。
其典型流程是：开发者编写代码 → 提交 PR → 同事阅读代码 → 提出修改意见 → 开发者修改 → 审批合并。
这种方式在团队规模较小、代码变更频率较低时比较有效。但 AI 时代出现了三个变化。
1. 代码生产者发生变化
代码不再全部由人类编写。AI Agent 可以根据需求独立完成代码修改，甚至同时处理多个任务。
因此，Review 不应该只检查代码写得是否漂亮，而应该重点验证：AI 是否正确理解了需求？是否实现了预期功能？是否引入了新的 Bug？是否破坏了现有功能？是否符合系统架构和业务约束？
2. Review 的执行者发生变化
过去主要由人类 Reviewer 承担审查工作。现在可以引入多个职责不同的 AI Reviewer：
- 功能审查 Agent：检查需求实现是否正确。
- Bug Hunter：寻找潜在缺陷。
- Security Reviewer：检查安全问题。
- Architecture Reviewer：检查架构和模块边界。
- Code Simplifier：检查是否存在不必要的复杂度。
通过职责拆分，可以让不同 Agent 从不同角度检查同一份代码。
3. 质量保障的边界发生变化
Review 不应该在代码合并时结束。代码合并后仍然可能出现运行环境差异、并发问题、数据异常、线上性能问题、与其他模块集成时出现的错误。
因此，完整的 Review 体系必须包含上线后的监控、回滚和问题复盘。
三、建立七层质量防线
建议将 AI 时代的 Code Review 拆分成七个阶段。
第一层：开发阶段自验证（Pre-PR Validation）
AI Agent 完成代码编写后，不能直接将任务标记为完成，而必须先执行自验证。不同类型的项目应采用不同的验证方式：
| 项目类型 | 验证方式 |
|---|---|
| 后端服务 | 单元测试、集成测试、API 请求验证 |
| 前端应用 | 页面启动、浏览器实际操作、交互验证 |
| UI 开发 | 截图对比、布局检查、响应式测试 |
| 数据库修改 | Migration 验证、数据一致性检查 |
| API 开发 | 请求参数、返回结果、异常情况验证 |
| 基础设施 | 配置检查、部署测试、服务健康检查 |
需要特别强调：AI 说测试通过，不等于测试真正通过。
必须提供真实执行证据，例如命令执行结果、测试报告、构建日志、浏览器操作结果、截图或接口响应。
另外，可以安排一个独立上下文的 Agent 对本次 Diff 进行审查，减少编写代码的 Agent 因为熟悉自己的实现而忽略潜在问题的情况。
核心规范：没有实际验证证据，不允许提交 PR。
第二层：AI Code Review
每一个 PR 都应该经过 AI Review。AI Reviewer 不应该只检查修改的几行代码，而应该结合完整上下文进行判断，主要检查四个方面：
- 功能正确性：是否满足需求、是否存在遗漏的业务场景、是否处理异常情况、是否存在边界条件问题。
- 代码正确性：逻辑错误、空值/类型/状态处理、竞态条件、资源泄露。
- 系统兼容性：是否影响其他模块、是否破坏现有 API、数据库兼容问题、是否影响已有用户数据。
- 架构合理性：是否违反模块职责、是否引入不必要的依赖、过度设计、维护成本。
多 Agent 独立审查机制
可以采用多个 Agent 并行审查：Agent A 检查功能逻辑、Agent B 检查潜在 Bug、Agent C 检查安全问题、Agent D 检查架构和兼容性。每个 Agent 独立提交 Findings，随后由 Review Coordinator 归并、验证和去重。
注意：多个 Agent 同时发现一个问题，并不能自动证明这个问题真实存在，最终仍需根据代码上下文和实际行为验证。
Review Finding 的分类
| 级别 | 含义 | 处理要求 |
|---|---|---|
| Critical | 严重安全漏洞、数据丢失、核心业务不可用 | 阻断合并 |
| Important | 确认存在的功能缺陷或重要兼容性问题 | 修复后合并 |
| Nit | 轻微改进建议 | 非阻断，可记录 |
| Pre-existing | 修改前已经存在的问题 | 记录，不归因于本次修改 |
每个 Finding 必须包含：问题所在文件及代码行、问题产生的具体原因、可以复现的场景、可能造成的影响、建议的修复方式。不要接受只有模糊描述、没有实际依据的 Review 意见。
核心规范：Review 必须发现真实问题，而不是制造修改任务。
第三层：独立 Security Review
安全审查不应该完全依赖普通 Bug Review，建议设置独立的 Security Reviewer，重点检查：身份认证与授权、用户数据隔离、API 权限校验、SQL 注入与 XSS、SSRF 等服务端请求风险、敏感信息泄露、密钥与环境变量管理、文件上传与下载安全、依赖包漏洞、支付和账单相关逻辑。
对于涉及身份认证、支付、权限和敏感数据的修改，应提高审查等级。发现未解决的严重安全问题时，必须阻断合并。
核心规范：安全审查必须独立执行，不能因为普通测试通过就默认安全。
第四层：CI 自动化检查
AI Review 不能代替自动化测试。CI 应负责执行可以被客观验证的检查：
| 检查项目 | 目的 |
|---|---|
| Lint | 代码规范 |
| Type Check | 类型安全 |
| Unit Test | 单元逻辑 |
| Integration Test | 模块集成 |
| E2E Test | 核心业务流程 |
| Build | 构建成功 |
| Dependency Audit | 依赖安全 |
| Migration Check | 数据库变更安全 |
对于重要业务功能，建议设置必要的测试覆盖率和关键路径测试要求。但不要单纯追求覆盖率数字——测试覆盖率高不代表测试质量高，真正重要的是测试是否能发现实际的功能错误。
第五层：基于风险的人工审批
并不是每一个 PR 都需要人工逐行审查，应该根据变更风险决定人工介入程度。建议建立三级风险制度：
| 风险等级 | 典型修改 | 审批要求 |
|---|---|---|
| Low | 文档、文案、非关键 UI、低风险配置 | AI Review + CI |
| Medium | 普通业务功能、缓存、API、数据库一般变更 | 1 名人类 Reviewer |
| High | 支付、认证、权限、数据库核心结构、部署与 CI 工作流 | 2 名人类 Reviewer |
注意：风险等级必须由实际变更内容决定，不能仅由开发者自行申报。
另外还应设置敏感文件清单，例如 auth/、billing/、payments/、permissions/、database/migrations/、.github/workflows/、deployment/。只要修改涉及这些路径，就应触发更严格的审批规则。AI Agent 可以提供审查意见，但不能替代真人审批。
核心规范：低风险变更追求效率，高风险变更优先保障安全。
第六层：Merge Queue 与渐进式发布
所有检查通过之后，也不建议立即无条件发布。
首先需要考虑代码与最新主分支之间是否存在冲突，建议采用 Merge Queue：PR 进入合并队列 → 与最新主分支结合 → 重新执行必要的 CI 检查 → 所有检查通过后才允许合并。
对于重要功能，应采用渐进式发布：内部环境验证 → 小范围用户测试 → 逐步扩大开放范围 → 全量发布。
对于高风险功能，应优先使用 Feature Flag——即使出现问题，也可以先关闭功能，而不必立即回滚整个系统。
核心规范：代码通过 Review，不代表已经证明它可以安全地全量发布。
第七层：线上监控与快速回滚
Review 体系必须延伸到线上。建议建立：错误率监控、API 响应时间监控、核心业务流程监控、数据库异常监控、服务可用性监控、关键操作审计。
同时必须确保：重要功能能够快速关闭、数据库修改具有回滚或前向修复方案、重要版本能够快速 Revert、出现严重异常时有明确的负责人。
线上事故发生后，不应该只追究是哪段代码写错了，更应该思考：**这次问题本来应该由哪一层 Review 防线发现？为什么没有发现？**然后将问题转化为新的测试案例或审查规则。
四、建立统一的项目 Review 规范文件
要让 AI Review 长期保持稳定，不能每次都依赖开发者临时编写 Prompt，应该把项目规范沉淀到代码仓库中。建议至少建立三个文件。
1. CLAUDE.md：项目开发规范
主要内容：项目介绍、技术栈、系统架构、目录结构、模块职责、编码规范、开发和测试命令、重要业务约束。目标是让 AI Agent 在开发之前理解项目。
2. REVIEW.md：项目审查规范
这是最重要的审查规则文件，建议包含：
审查目标：优先寻找可能影响用户、数据、安全和系统稳定性的真实问题。
审查重点：业务逻辑是否正确、是否破坏原有功能、异常处理缺失、权限问题、数据一致性问题、模块兼容性影响。
审查输出：每个问题必须给出 Severity、File、Line、Description、Reproduction Scenario、Suggested Fix。
禁止事项：不要把个人代码风格偏好当成 Bug；不要重复报告已有问题；不要提出无法复现的猜测；不要为了增加 Findings 而制造问题；不要把无关的重构建议作为阻断条件。
3. ARCHITECTURE.md：架构与系统约束
记录：系统架构图、模块之间的依赖关系、数据流、核心业务流程、数据库结构、关键接口、不允许违反的架构约束。这样 Review Agent 就不需要仅仅根据局部代码猜测系统设计意图。
五、建立 Review 收敛机制，避免 AI 无限循环
AI Agent 容易出现一个问题：AI 写代码 → AI Review → AI 修改 → AI 再次 Review → 再次修改。如果没有约束，可能出现几十轮修改，最终代码反而越来越复杂。
规则一：最多三轮 Review
- 第一轮：完整审查，发现主要问题。
- 第二轮：验证修复结果，检查新增问题。
- 第三轮：确认剩余问题及最终状态。
如果三轮后仍然无法通过，应该停止继续打补丁，重新评估整体实现方案。
规则二：后续轮次优先检查新增 Diff
第一次 Review 可以检查完整变更，后续 Review 应重点关注新增代码、修改代码、上一轮问题的修复结果、修复是否引入新的问题，避免每一轮都重新扫描所有内容。但如果发现新的重大问题，仍然可以扩大审查范围。
规则三：同类问题一次性修复
如果 Reviewer 发现多个相同类型的问题，应归纳问题模式（如多处缺少权限验证、多个接口缺少异常处理、多处存在重复的数据转换逻辑），一次性修复同类问题，而不是逐条打补丁。
规则四：禁止重复 Findings
已经报告的问题，不应在后续轮次重复提出，除非修复后出现了新的问题，或者原问题仍然没有解决。
核心规范：Review 的目标是让代码质量收敛，而不是让 Agent 永远保持活跃。
六、建立 Reviewer 的持续评估体系
AI Reviewer 自己也可能判断错误。因此，不能只评估开发 Agent 的代码质量，也应该持续评估 Reviewer 的审查能力。建议建立历史 Bug 测试集。
1. 收集历史问题
来源包括：线上事故、已经回滚的 PR、用户反馈、安全漏洞、测试环境发现的严重缺陷。
2. 建立标准案例
每个案例至少包含：原始代码、引入问题的代码变更、问题描述、复现步骤、正确修复方式。
3. 定期运行 Reviewer
让 AI Reviewer 审查这些历史变更，检查它是否能够发现真正的问题、指出正确的位置、准确描述问题原因、避免大量误报。
4. 重点关注四项指标
| 指标 | 含义 |
|---|---|
| Recall | 历史真实 Bug 的发现率 |
| Precision | AI 报告中真实问题的比例 |
| False Positive Rate | 误报比例 |
| Rounds-to-pass | PR 平均通过轮数 |
Recall 衡量有没有漏掉重要问题，Precision 衡量报告是否值得开发者信任。不能只追求高 Recall 而忽略 Precision，否则开发者很容易对 AI Reviewer 产生审查疲劳。
5. 用线上事故反哺 Review
每次事故结束后，都应该追问：哪个 Agent 理论上应该发现这个问题？为什么没有发现？是否缺少测试？是否缺少架构约束？是否需要更新 REVIEW.md？是否应该增加历史回归案例？
这才是 Review 体系真正持续进化的关键。
七、AI 时代的开发责任与团队协作规范
AI 可以编写代码，也可以审查代码，但不能因此模糊责任归属。建议明确以下规则：
- 谁提交，谁负责：无论代码由人类还是 AI 编写，提交 PR 的负责人都需要对最终变更负责。
- AI 审查不能替代人类责任：对于高风险变更，必须有真人审批，AI 的批准结果不能替代人工授权。
- 需求正确性由人类负责：AI 可以判断代码是否满足给定要求，但无法独立决定产品需求是否正确。需求目标、业务规则和验收标准必须由人类确认。
- 重大架构变更必须提前评审：涉及技术栈、核心数据模型、系统边界和关键业务流程的重大修改，应在开发前进行设计评审。
- Review 意见必须有依据：不应该因为某个 Agent 的身份是 Reviewer，就默认它的意见正确。每一个阻断性问题都必须有明确证据。
八、推荐的一套 AI Review 工作流
将前面的规范整合起来，可以形成以下标准流程：
需求分析 → 明确验收标准与风险等级 → AI Agent 编写代码 → 开发阶段自验证
→ 提交 Pull Request
→ AI Bug Review + AI Security Review（并行）
→ Review Findings → 问题验证与去重 → 作者修复问题 → 再次 Review
→ CI 自动化检查 → 风险等级审批 → Merge Queue → 合并主分支
→ 渐进式发布 → 线上监控
→ 正常：持续运行｜异常：关闭功能/回滚
→ 事故复盘与规则更新 → Reviewer 持续改进
九、不同规模团队的落地建议
并不是每个团队都需要一开始就建立七层完整体系，应该根据开发规模和风险逐步建设。
个人开发者 / AI Solo Founder
推荐配置：1 个主开发 Agent、1 个独立 Review Agent、自动化测试与 CI、一份 CLAUDE.md、一份 REVIEW.md、Git 版本控制与快速回滚。
建议流程：AI 开发 → 自验证 → 独立 Agent Review → CI → 人工确认 → 合并发布。个人开发者最需要解决的是 AI 自我审查和代码质量失控的问题。
小型 AI SaaS 团队
推荐配置：多个开发 Agent、独立 Bug Reviewer、Security Reviewer、CI 自动化流水线、基于风险的人工审批、Feature Flag、线上错误监控。
建议重点保护：用户数据、支付流程、身份认证、权限控制、数据库结构、核心业务流程。
中大型工程团队
在小团队体系基础上增加：多 Agent 并行审查、自动风险分类、Merge Queue、双人审批机制、Reviewer 历史 Bug 评估集、事故驱动的规则迭代、质量指标仪表盘。
十、最终总结：Review 将成为 AI 软件工程的核心基础设施
AI 编程工具解决的是代码生产效率问题，但代码生产效率提高，并不意味着软件质量会自动提高。
当代码生产速度越来越快，Review 就必须从单纯的人工检查，升级为系统化的质量保障机制。Anthropic 的实践带给我们的最大启发，不是简单地增加几个 AI Reviewer，而是建立一套完整的工程闭环：
- 开发阶段要求 AI 自验证。
- PR 阶段使用独立 AI Agent 审查。
- 安全问题独立检查。
- CI 提供客观验证结果。
- 根据风险决定人工审批。
- 合并发布采用渐进式策略。
- 线上问题反哺测试与 Review 规则。
最终形成：AI 负责生产，AI 负责初步审查，自动化工具负责验证，人类负责关键决策，线上反馈负责持续改进。
这套体系并不意味着人类不再需要阅读代码，而是让人类把有限的注意力集中在真正重要的地方。在 AI 时代，优秀的工程团队不一定是写代码最快的团队，而是能够以更低的成本持续交付可靠软件的团队。
参考资料
- Anthropic Engineering：《How the Claude Code team does code review》 — https://claude.dev/blog/solving-code-review-at-anthropic/
- Claude Code 官方文档：Best Practices — https://code.claude.com/docs/en/best-practices
- Claude Code 官方文档：Code Review — https://code.claude.com/docs/en/code-review
- Claude Code 官方文档：Security — https://code.claude.com/docs/en/security
本文为基于 Anthropic 公开工程实践进行的经验提炼与方法论整理。文中提出的团队分级配置、SOP 和部分流程建议属于通用化落地方案，并非 Anthropic 官方逐条规定。
