Rootly 废掉了小 PR 规则：审查的对象从行数换成了影响半径

Rootly 是做事故管理的，两年来一直推行严格的小 PR 文化：要求堆叠 PR，把一次原子变更限制在几百行以内。联合创始人兼 CTO Quentin Rousseau 说明为什么这条规则被废掉——而理由不是它错了，是它当初为之设计的那个前提没有了。

智能体改变的是工作的单位

人手写代码时，小 diff 更好审、更好回滚，所以小 PR 是最优解。智能体不是这样工作的：它以特性而不是增量为单位思考，一次性输出完整实现——数据库迁移、模型、服务、控制器、测试、前端组件一起给出来。

他们试过把这套流程套上去，让智能体生成堆叠 PR。结果是技术上挑不出错、整体业务上下文里反而更糟：审查某一个 PR 时，意见往往要依赖另一个 PR 里的改法，评审人被迫来回翻页重新梳理逻辑。这是一次带负面结果的尝试，不是一次直觉判断。

缺陷的形态也变了

工程团队给出的描述很精确：AI 引发的漏洞本质是上下文漏洞——代码本身能正常运行，只是被用在了错误的场景中。 举的两个例子都不需要读代码就能懂：某次数据库迁移删掉了后台任务仍在调用的字段；某个服务往一张表里写数据，而那张表正被另一个团队读取。

这正是本站《完成判定与验收信号》里那条判据的生产版本：一次成功的调用不等于一次正确的行动。 类型检查、测试、lint 全绿，仍然可以是错的。

换掉的是判据，不是工具

三件事一起动：

1. 爆炸半径取代代码行数。 团队的原话是「代码改动量的大小已不再具备参考价值，真正关键的指标是故障影响范围」。
2. 内部 AI 审查器只回答一个问题：如果这个变更存在缺陷，会破坏哪些面向用户的功能？它明确不试图扮演人类审查者，产出的是一份结构化报告——风险评估、标准化评分、置信度评分、按严重程度分类的问题列表——并把「会改变业务行为」的变更和「只影响性能或界面展示」的变更分开定级。给人类的是一个结构化的参考面，不是一份原始 diff。
3. 安全边界从合并挪到发布。 每个重要特性都在特性开关后面上线：PR 合并、代码进生产之后，特性默认是关的。真正的审查发生在渐进放量的过程里——先团队内部，再一小批客户，再 10%，最后全量。

两条容易被跳过的细节

PR 里的「为什么」和「是什么」由使用智能体的那个人填写，而且 Rootly 明确要求 AI 助手不要生成这部分——因为这一段存在的目的就是捕获上下文：为什么要做这个变更、为什么是现在、对应什么业务诉求。让生成代码的同一个东西去解释这段代码，等于把这段的价值抵消掉。

另一条：每个 PR 都必须描述如何安全回退，包括必要的数据修复。

不是一家公司的孤例

备份与版本控制服务商 Rewind 的审查工具 Diff Vader 借鉴了同一套基于风险的模型，其团队写道：一个 PR 的风险与它的代码行数几乎无关。2026 年伦敦 QCon 上，Michael Webster 讨论了无界面智能体产出的大 PR 给人工审核造成的瓶颈与持续累积的技术债。同年 6 月的伦敦 AI 原生开发者大会上，被广泛称为 DevOps 之父的 Patrick Debois 提出了更激进的一版：PR 在开源社区里有意义，因为贡献者之间的方向未必一致、需要逐步建立信任；而在一个共享上下文与目标的团队内部，当智能体快速迭代时，PR 审查周期越来越难证明自己的合理性。

同一场讨论里还有一句值得单独记下来的：过去纯人工开发阶段流程中的低效很难被察觉，而如今智能体的 token 消耗可以量化，浪费会实实在在体现在账单上。 这与本站那条 180 万美元的账单信号是同一个机制的两面——账单先是灾难，然后成了唯一诚实的度量。

边界

这是一家公司的实践复盘，不是对照实验：没有给出改动前后的缺陷率、审查耗时或事故数。可迁移的是判据与失败形态，不是「废掉小 PR 一定更好」这个结论。Rousseau 自己也写明，废掉一条曾经感觉非常正确的流程，起初让人很不适应。