讲下这个https://x.com/claudedevs/status/2111168901723906176

这是 ClaudeDevs 官方发的一篇工程复盘，讲的是当 ca 写了 Claude Code 约 90% 的代码、Anthropic 主仓日均变更从 5 月的 2500 次暴涨到 9 月的 3 万次之后，他们怎么把 Code Review 从“人肉守门”改造成“机器流水线”，在 6 到 9 月让合入 PR 翻倍的同时把回滚率砍掉 40% 以上（顺带给他们全面开放的商业功能 Code Review for Claude Code 带货）。 背后的核心机制与工程取舍就三件事： 第一，优化目标从“人有没有读过代码”彻底换成了“单位变更消耗的人类注意力 vs 回滚故障率”。 传统 CR 默认必须由另一个人逐行读完才算安全，但在 ca 高频产出下，强行让人审只会变成走过场的橡皮图章。他们的解法是把人从低价值的看 diff 里摘出来，变成“按改动风险分级审批”：用分类器看改了哪些路径，低风险（文档、特性开关后的纯增量）只要自动化检查和 Agent 审查全绿，0 人类审批直接合入；中等风险（普通功能、缓存、自动更新、系统提示词）只需 1 个人批，而发号施令写这个 PR 的工程师本人就算这 1 个人，不需要再拉同事看；只有核心高危路径才强制双人审批。作为兜底，他们把赌注压在极速回滚（秒关 Feature Flag、全量 Merge Queue、金丝雀灰度）上，用事后恢复速度替代事前人肉死防。 第二，如何解决“Agent 审 Agent”最大的工程死穴：噪音与死循环。 这是整篇最干货的实战经验。人对无聊的 nit 意见瞄一眼就忽略了，但 ca 作者看到 ca 审查员提意见就会老实去改，改完再触发新一轮审查——他们内部曾有一个 CLI 的 PR 一晚上自动对线了 50 多轮，最后 git blame 发现 59% 的意见其实第一轮就存在，只是审查 Agent 每轮随机多翻出几个陈年老毛病。 为了压住噪音并强制收敛，他们做了几层硬约束： 1. 多 Agent 并发找 Bug + 独立评审团投票过滤，只有多数同意是真问题的才发出来，纯代码风格和清理类意见直接丢弃。 2. 拆开 CLAUDE.md 和 REVIEW.md。CLAUDE.md 只写怎么写代码，Code Owner 单独维护简短的 REVIEW.md，明确定义“这个模块什么叫挂了”、限制 nit 数量、列出跳过路径，且强制要求给出文件名和行号证据。 3. 把线上真实事故回滚的 PR 收集起来做成每日必跑的离线 Eval，同时统计人类对每条 AI 评论的真实反应（修了、怼回去说本来就这么设计的、还是直接无视），拿真实采纳率反推优化。 第三，废掉“靠看别人的 PR 熟悉代码库”的传统习惯。 以前 CR 的副产物是让团队同步上下文，现在没人读全量代码了，他们干脆放弃让任何人脑子里装下整个仓库的心智模型。需要改哪块代码时，直接让 Claude 现场生成那一块的最新架构解释或可视化小工具，用即时生成的局部上下文替代平时的散装阅读。 对我们自己做工程和用 ca 的启发很直接：当写代码的成本趋近于零时，研发瓶颈必然卡在验证和审查。想要提速，一是必须在提 PR 前就给 ca 配好自验证闭环（跑测试、截图对比、用全新上下文的 subagent 先自审一轮）；二是团队规范不能只写给写代码的 Agent，必须专门维护一份给审代码 Agent 看的判罚标准（REVIEW.md），否则自动化 CR 只会制造出一堆消耗算力和精力的机器内耗。