Agent 会开越来越多的 PR：用三条车道分级审查 AI 写的代码

Claude Fable 5.2 这类长时程模型让 agent 能连续多天跑项目、批量开 PR，瓶颈从写代码转移到代码审查。文章给出一套分级审查方案：按风险把 PR 分进三条车道，用固定规则兜底，并把「没测过的部分」放在审查摘要最显眼的位置。

为什么审查成了新瓶颈

• Anthropic 称有工程师让 Fable 5.2 协调超过 1000 个 subagent 跑了八天做原型操作系统，Fable 5.2 定位是 Orchestrator，把简单任务分给小模型
• 一个 agent 一天开一个 PR 还能逐行看，一群 agent 开五十个就不行了，团队容易滑向「不看就批」或「拖慢 agent 等审查」
• 第三条路：在任何人开始读代码之前，先决定每个 PR 需要多严格的审查

三条车道分级

• Auto merge：低风险，如文档、文案、带通过测试的小型独立改动
• Review：合并前必须有人看
• Block：当前状态不应合并
• Auto merge 是低风险不是保证，三条车道都要保留必需的 CI 检查；目标是把注意力花在真正可能造成伤害的 PR 上

用固定规则设定下限

• 认证与权限、会话相关代码必须人工看
• CI 和 workflow 文件（如 .github/workflows/）、数据库迁移、依赖和 lockfile 变更
• 被删除、跳过或弱化的测试，以及疑似密钥的字符串
• 每条规则设定最低车道：迁移至少 Review，出现新密钥直接 Block
• AI 审查者只能把 PR 升到更严格的车道，不能降级，这样每个决定都能用规则名解释

策略文件要从 base 分支读取

• 能写代码的 agent 也能改你的审查配置，如果审查者从 PR 分支读规则，PR 就能改掉评判自己的标准
• 策略应从 base 分支（通常是 main）加载，对策略文件本身的改动至少算 Review

把「没测过的」放在最上面

• 排队的审查者不需要长篇故事，最上面三样：车道及触发它的规则或发现、高风险区域的改动、没检查或没测试的部分
• 最后一点最有用：大文件是否被截断、测试是否被跳过、改动的函数有没有测试
• Anthropic 引用测试者说 Fable 5.2 会承认自己不知道而不是编造，你的审查环节也应对自己的盲区同样诚实

今天就能在 GitHub 搭起来

• 给 main 开分支保护，把 CI 和审查检查设为必需
• 加 CODEOWNERS，让 .github/workflows/、迁移和认证代码的改动总是通知指定的人
• 车道规则放在 base 分支的文件里，先从严，看到足够多安全 PR 后再放宽