https://x.com/addyosmani/status/2114604912520921136 看看这篇博客

回复 Erfan 看完了。这篇是 Addy Osmani 写的，讲的是 Claude Code 团队在那么大的代码量下怎么做 code review；背景是他们的 Claude 大概写了 Claude Code 90% 的代码。 先看数据：6 月到 9 月，Claude Code 仓库合并的 PR 数量翻了一倍多，回滚比例反而降了 40% 多。他们的做法不是放弃 review，而是把负责读代码的环节大部分自动化，并让“出错了能快速撤回”变得很方便。 几个我觉得最关键的点： 一是重新定义了 review 的目标。他们不再问“有人读过这段代码吗”，而是问“这次改动可能出什么问题、用哪种检查（自动化或人工）能抓住它”。这个问题一换，review 的时机也变了：从写完 PR 之后的一道关卡，变成写的过程中持续做，有点像拼写检查。 二是分层而不是一道关卡。共六层：PR 前自检（让 Claude 跑测试/构建/截图比对，还要展示结果而不是说“做完了”，再用一个全新上下文的 subagent 审 diff），每个 PR 都有的 AI review，能卡住合并的安全审查，标准 CI 检查，按风险分级的人工批准，最后是 merge queue 加 feature flag 灰度，再加回滚作为兜底。每层都会漏一些 bug，但很少能全部漏过。 三是把人工时间当成双面成本。他们的目标是最多一个人参与就能合并，同时回滚率和事故率不上升——因为“省了读代码的时间，却把时间花在修坏代码上”等于没省。 四是最有意思的一段：review 要能收敛。他们发现 agent 作者和 agent 审查者会无限循环，有个 CLI 的 PR 一晚上来回改了五十多轮。一查 git blame，审查系统反复报的问题里约 59% 是首次就存在的老代码，并不是每轮都在发现新 bug。于是他们限制轮次，超过三轮就要求作者重新评估方案；后面几轮只审新增 diff；一次性说明问题类别，而不是一行一行报；已经报过的不重复报。 五是人的定位。人留下来做的是：该不该做这件事、审美和产品目标、审计危险代码（计费、自动更新、CI 流程、安装器）、架构决策、验证证据，还有最终负责——“你合进去，你负责”。另外有个细节我很认同：agent 的批准不算人工批准；如果 PR 是 agent 写的，操作 agent 的那个人必须算作必需的审查者之一；推了新 commit，旧批准作废。这跟群里之前讨论的 agent 权限和身份问题是一致的。 他们还有个诚实的坦白：如果读 diff 这件事交给了机器，新同事怎么理解代码库？他们也没正式机制，答案是直接让 Claude 针对你要改的那块生成一份最新的讲解，比逐行读一行文案改动的 diff 学到的多。 我自己的看法：这篇文章表面在讲 review 流程，实际在讲怎么把“人类注意力”当成稀缺资源来调度。整套设计的隐含前提是爆炸半径要小、能秒回滚、能灰度——没有这三条，前面所有自动化都是在放大风险，而不是省时间。另外那句“把事故当 eval 集”我认为是最可迁移的一条：不是先攒一个评测集再上线，而是先跑起来、把每次翻车收集成回归样本，再拿它天天给审查系统打分。这跟个人攒 badcase 的路子是一回事，只是他们从组织层面做了。