来源：https://academy.claude.com/courses/ai-native-sdlc-playbook/ai-in-the-pr-review-loop 读这篇之前：05 CLAUDE.md、06 skills、07 subagents 有帮助 不确定：ZH 是 Clint 译官方英文课体，不是 Anthropic 中文。
本课词汇
| English | 中文 | 怎么记 |
|---|---|---|
| REVIEW.md | 审查说明 | 仓库根目录，规定过几遍、什么算 Important、什么跳过 |
| Nit | 吹毛求疵 | 风格和命名；课说每份审查最多报五条 |
| Important | 重要发现 | 会弄坏行为、漏数据、或破政策的才配这个标签 |
| branch protection | 分支保护 | 还是要 code owner 人批才能合 |
| @claude | 在 PR 里点名 Claude | 处理评论并推修复；托管服务里 @claude review 是再审一次 |
| separation of duties | 职责分离 | 写代码的 agent 不能批准同一份代码 |
对照正文
EN Claude both gives and receives reviews. It reviews incoming PRs against the organization’s policies and addresses review comments on its own PRs. This allows engineers to focus on behavior in their PR review, which boils down to judging intent and risk.
ZH Claude 既给审查也收审查。它按组织政策审进来的 PR，也处理自己 PR 上的审查评论。这样工程师审 PR 时可以盯行为，也就是判断意图和风险。
什么变了 / What changes
EN | Traditional | AI-native | | --- | --- | | Review capacity is planned around human output. A PR waits for a reviewer to read all of it, review quality varies with the reviewer’s load, and the author chases while the backlog grows. | All PRs get an identical set of review passes, with findings ranked by severity. Human attention moves up a level, to whether the change does what the plan intended and whether the risk is acceptable. |
ZH | 传统 | AI-native | | --- | --- | | 审查产能按人的产出配。PR 等审查者读完；审查质量随负荷变；作者追着，积压变厚。 | 所有 PR 走同一套审查 pass，发现按严重度排序。人的注意力上移一层：这次改动是不是计划要的、风险能不能接受。 |
怎么起步 / Getting started
EN - Prerequisites: An updated CLAUDE.md file from Stage 3: Build, skills, if the review passes are to enforce written policies, and defined subagents.
- Infrastructure: A repo with the Claude integration installed, either the managed Code Review (research preview) service enabled by an admin or the claude-code-action running in your own CI, with model calls through Amazon Bedrock, Google Cloud’s Vertex AI, or Microsoft Foundry where needed (the CI/CD play covers the deployment options). Branch protection policies that require a code owner’s approval are also worthwhile.
ZH 先决条件：一份更新过的 CLAUDE.md（Stage 3: Build）；若审查 pass 要强制书面政策，还要 skills；以及定义好的 subagents。
- 基础设施：仓库装了 Claude 集成：管理员打开托管 Code Review（research preview），或自己 CI 里跑 claude-code-action；需要时模型调用走 Amazon Bedrock、Google Cloud Vertex AI 或 Microsoft Foundry（部署选项见 CI/CD 打法）。要求 code owner 批准的 branch protection 也值得开。
怎么做 / How to execute it
EN 1. The managed Code Review service is the fastest start. An admin enables it and selects repositories. Run the review in your own CI with the claude-code-action when you need control of the pipeline or want API calls routed through your own cloud agreement (the CI/CD play covers that plumbing).
2. The tech lead writes the review policy as REVIEW.md at the repo root, divided into the passes the organization cares about: bugs and logical errors; security and vulnerabilities; compliance against the spec (spec.md from the requirements play), the implementation plan (plan.md from the plan mode play), and design principles. REVIEW.md also defines what counts as Important as opposed to a Nit, and what to skip.
3. The tech lead sets the human threshold. Findings do not approve or block a PR on their own, and branch protection still requires approval from a code owner. A platform engineer who wants to gate merges on findings can read the severity counts that the check run publishes as a machine-readable tally.
4. When a reviewer or the author tags @claude on a review comment, Claude addresses the comment and pushes the fix. The PR thread records both the request and the change. This fix loop runs through the claude-code-action. In the managed service, commenting @claude review requests a fresh review instead. For PRs Claude opened, go further and let Claude babysit the PR to merge. Teams wrap the loop in a custom slash command that sweeps the unresolved review comments and failing checks on the PR, addresses them, and pushes the fixes, until the PR is green and waiting only on code owner approval.
5. Review findings feed back into CLAUDE.md. When a review flags a mistake for the second time, the correction goes into CLAUDE.md as part of that review, and because review reads CLAUDE.md, the mistake is caught from the next PR onwards. Review also flags when a change has made CLAUDE.md outdated.
6. Once a month the tech lead tunes the setup by rating findings so the reviewer improves and by capping Nit volume in REVIEW.md. Generated paths and anything CI already enforces are excluded.
ZH 1. 托管 Code Review 起步最快。管理员打开并选仓库。若要自己控流水线，或 API 走自己的云协议，就在自己的 CI 里用 claude-code-action 跑审查（管道见 CI/CD 打法）。
2. 技术负责人把审查政策写成仓库根的 REVIEW.md，按组织在意的 pass 划分：缺陷和逻辑错误；安全和漏洞；对照 spec（需求打法的 spec.md）、实现计划（plan mode 的 plan.md）和设计原则的合规。REVIEW.md 还定义什么算 Important、什么算 Nit、什么跳过。
3. 技术负责人设人的阈值。发现本身不批准也不拦截 PR，branch protection 仍要 code owner 批准。想按发现卡住合并的平台工程师，可以读 check run 以机器可读计数发布的严重度。
4. 审查者或作者在评论里点 @claude，Claude 处理评论并推修复。PR 线程记下请求和改动。这条修复环走 claude-code-action。托管服务里，评论 @claude review 则是再要一次新审查。Claude 自己开的 PR，可以更进一步让它看到合并。团队把环包成自定义 slash command：扫未解决评论和失败检查，处理并推修复，直到 PR 变绿，只等 code owner 批。
5. 审查发现回写进 CLAUDE.md。同样的错被标第二次，改正写进 CLAUDE.md，作为这次审查的一部分；审查会读 CLAUDE.md，下一份 PR 起就会抓住。审查也会标出改动是否让 CLAUDE.md 过时。
6. 技术负责人每月调一次：给发现打分让审查器变好，并在 REVIEW.md 里给 Nit 设上限。生成路径和 CI 已经强制的东西排除掉。
长什么样 / What it looks like
EN REVIEW.md:
ZH REVIEW.md：
# Review instructions
## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles
## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.
## Cap the nits
Report at most five nits per review; summarize the rest as a count.
## Do not report
Generated files under src/gen/ and anything CI already enforces.ZH 官方示例，保持英文。
治理 / Governance considerations
EN Separation of duties is preserved, because the agent that wrote the code has no way to approve it. The review policy in REVIEW.md is applied to all PRs, and findings, fixes, ratings, and approvals are logged in the PR history, so the PR is the audit record. Approval comes from a human through branch protection, informed by the findings.
ZH 职责分离保住了，因为写代码的 agent 没法批准代码。REVIEW.md 里的审查政策套到所有 PR；发现、修复、打分、批准记在 PR 历史，所以 PR 就是审计记录。批准来自人，经 branch protection，参考这些发现。
怎么衡量 / How to measure it
EN - Leading indicator: Time to first review, which should fall to minutes, and the share of review comments resolved without a human touching the branch, with data stored directly on Git.
- Lagging indicator: Defects and vulnerabilities caught before merge set against those escaping to production, from the PR history and the incident tracker.
ZH 领先指标：到第一次审查的时间，应降到分钟级；以及无人碰分支就解决掉的审查评论占比，数据直接在 Git。
- 滞后指标：合并前抓住的缺陷和漏洞，对照逃到生产的，来自 PR 历史和事故追踪。
读完能记住的三句话
EN Claude reviews every PR the same way. Humans judge intent and risk. ZH Claude 用同一套方式审每份 PR。人判意图和风险。
EN Findings do not merge the PR. A code owner still approves through branch protection. ZH 发现不会把 PR 合并。还是 code owner 经 branch protection 批准。
EN A mistake flagged twice goes into CLAUDE.md so the next PR catches it.
ZH 同样的错标两次，写进 CLAUDE.md，下一份 PR 就能抓住。