实操三：风险分级与度量——分支保护、CODEOWNERS、手写风险表与回滚看板，给评审装上护栏

循环渐进实操 · 2026-10-29 · 本篇为 ”AI 代码评审 ” 系列第 5 篇（终篇），第 1 篇解读 · 第 2 篇选型 · 第 3 篇实操一 · 第 4 篇实操二 · 对应 Anthropic 七层的 L4-L7（门禁 / 审批 / 发布 / 回滚） · 前置：已完成实操一、二

前三篇把 L1-L3 落地了：本地验证环、AI 评审、安全门禁。终篇收尾剩下的四层——但注意，这四层里 没有任何一层需要新工具 ：L4 是你已经有的 CI 加上必选检查；L5 是分支保护里的一项配置加一张手写的风险分级表；L6 是合并队列开关；L7 是两个查询加一块看板。Anthropic 文章里最贵的是第 2 层的多 agent 投票，而最便宜的恰恰是这四层——它们全是 GitHub 原生能力。本篇还补上整个系列的收官件： 护栏指标（回滚率与轮次），让 ” 省下的评审时间 ” 可被证明而不是自我感觉。

多数仓库已有 CI，缺的是 ” 必选 ” 属性与检查完整性：

Settings → Branches → Branch protection → Require status checks，把以下 workflow 设为 required：lint、typecheck、unit tests、integration tests、build。任何一个不绿，合并按钮灰掉——这就是 L4 的全部。

补一个 PR 模板（.github/PULL_REQUEST_TEMPLATE.md），对应第 1 篇的 ” 怎么测的 / 风险 / 怎么撤销 ” 三问：

## What & Why
<!-- 一句话：改了什么，为什么 -->

## How tested
<!-- 具体命令 + 关键输出片段；" 手动验证 " 需附截图 -->

## Risk
<!-- low / medium / high + 理由；涉及 auth/billing/workflows 直接写 high -->

## How to revert
<!-- 回滚方式：revert commit / flag 关闭 / 数据回滚脚本 -->

CI 挂上后，agent 会自动填三问，但 提出变更需求的人负责签字——这条纪律写进 CONTRIBUTING.md：模板空着或明显敷衍的 PR，评审器有权直接打回。

第一步：手写风险分级表。Anthropic 用两个分类器做这件事，小团队的正解是一张手写表（放 docs/risk-tiers.md，REVIEW.md 引用它）：

# Risk Tiers

## Tier 0 — no human approval needed
- docs/, comments, typo fixes
- additive changes behind a feature flag (default off)
- test-only changes (no src/ touched)

## Tier 1 — one approval (can be author + AI green)
- ordinary product changes
- new endpoints without auth/billing surface

## Tier 2 — one senior approval (CODEOWNERS)
- src/auth/**, src/billing/**
- migrations/, schema changes
- dependency major bumps

## Tier 3 — two approvals, always human
- .github/workflows/**
- release/installer scripts
- auto-updater, telemetry/credential handling

第二步：把 Tier 2/3 映射进 CODEOWNERS（.github/CODEOWNERS）：

# Tier 3 — always two humans via branch protection
/.github/workflows/    @platform-team @senior-staff
/src/auth/             @security-team
/src/billing/          @billing-team @senior-staff

# Tier 2 — one owner
/migrations/           @dba

第三步：分支保护两条关键开关 ：Require review from Code Owners（Tier 2/3 自动找对审批人）；N required approvals 按 Tier 设（GitHub 免费版只能全局设一个数——设 1，Tier 3 的 ” 第二人 ” 用 CODEOWNERS 的双人组实现）。 可信作者：GitHub 没有原生可信名单，等价物是 ” 组织成员 + CODEOWNERS 之外默认需 1 人审批、外部 fork 永远需 2 人 ”——够用了。

第四步：agent 的审批不算人头——GitHub 的 requested reviewer 机制天然满足（bot 不是 reviewer）；再补一条分支保护：Dismiss stale reviews（新 commit 落地自动撤销旧审批）——这就是第 1 篇 ” 审批只覆盖一个 commit” 的实现开关。

开源 GitHub 的对应物：Merge queue（Settings → Branches → Require merge queue，GitHub Team/ 企业版功能）——把 PR 排队，逐个对最新 main 重跑必选检查，消灭 ” 两个各自通过的 PR 合出坏 main”。免费版的替代：收紧 main 的推送权限 + 快速 revert 纪律。

Flag 即渐进发布：新行为默认关，FEATURE_FLAGS 常量或配置中心控制，先给自己人开。最小实现可以只是一个环境变量清单加一页文档说明每个 flag 的回滚命令——第 1 篇说的 ”flag 无需部署即可关闭 ”，在自托管场景就是改配置重启。

护栏指标落地为 两个每周例会必看的数字：

Revert rate——git log --merges --since="1 week" main 配合 revert 标记，或直接用 GitHub Insights → merged vs reverted。护栏线：不升高（对照启用双评审前的四周基线）
Rounds-to-pass——评审轮次。PR-Agent 每次评论是一个 issue comment，数一下每个 PR 从开到合并收到的 bot 评论数，取中位数与 P95

一块最小看板（GitHub Actions 周任务 + 输出到 pinned issue 即可，不必上 Grafana）：

name: weekly-review-metrics
on:
  schedule: [{cron: "0 9 * * 1"}]  # 每周一
jobs:
  metrics:
    runs-on: ubuntu-latest
    steps:
      - run: |
          gh pr list --state merged --limit 50 --json number,reviews,comments \
            --jq '[.[] | {n: .number, rounds: ([.comments[]? | select(.author.login | endswith("[bot]"))] | length)}] \
            | sort_by(-.rounds) | .[0:10]' > report.md
          # 贴到 pinned issue，标红 rounds > 3 的 PR

事故复盘模板 加上第 1 篇的必问句：” 哪一层本该抓住它？”——每次事故后把答案变成一处配置改动（REVIEW.md 加一条失败模式 / hooks 加一条检查 / 风险表调一级）。这就是 ” 事件即评估 ” 的小团队版：不必有每日跑的 eval 集，但每次事故必须变成一道新的闸门。

[] L1：CLAUDE.md/REVIEW.md/hooks 四件套入库，agent 能展示真实测试输出
[] L2：每个 PR 有 AI 评审，findings 以计数开头、分三级、带 file:line
[] L3：安全评审为 required check，发现未关闭不能合并，可自动解除
[] L4：lint/type/test/build 全部 required
[] L5：风险分级表入库，CODEOWNERS 映射 Tier 2/3，stale review 自动撤销
[] L6：合并队列（或等效纪律）+ flag 清单文档
[] L7：周度 revert rate 与 rounds-to-pass 两个数字有人看，事故必问 ” 哪层漏了 ”

七项全勾，你就有了 Anthropic 七层的全部等价物——用原生 GitHub 能力 + 每月几十美元 token。

五篇走完，回到第 1 篇的那个核心替换——” 有没有人读过代码 ”→” 哪层检查抓哪类问题 ”。实操三篇给出的是一个可伸缩的答案：$0 起步覆盖 L1-L4（四件套 + 双评审 + 必选 CI），两个原生开关加一张手写表覆盖 L5-L7，护栏指标（revert rate + rounds-to-pass）证明时间真的被省下了。Anthropic 的 30,000 日变更架构不必抄全，但它的三条纪律——findings 必答、轮次上限、事件即评估——任何规模的仓库都值得当天抄走。

参考与延伸

系列：第 1 篇 · 七层架构精读 · 第 2 篇 · 选型 · 第 3 篇 · 仓库改造 · 第 4 篇 · 双评审
原文：How the Claude Code team does code review · Redesigning source control
工具：The-PR-Agent · claude-code-security-review

by 飞熊 · yunying（增长运营官）· 配置以 GitHub 当前功能为准（merge queue 需 Team 计划）；系列五篇全部使用 GitHub 原生能力 + MIT 工具，无锁定

实操三：风险分级与度量——分支保护、CODEOWNERS、手写风险表与回滚看板，给评审装上护栏

写在前面

一、L4：把 CI 变成必选检查

二、L5：风险分级表 + CODEOWNERS + 可信作者

三、L6：合并队列与 flag

四、L7：两个数字 + 一块看板

五、验收清单：七层部署完整度自检

六、小结：系列的收官判断

近期文章

近期评论