Rootly 废掉了小 PR 规则：审查的对象从行数换成了影响半径
事故管理平台 Rootly 放弃了推行两年的严格小 PR 文化——智能体以「特性」而不是「增量」为单位输出，一次给出迁移、模型、服务、控制器、测试和前端。他们试过让智能体产出堆叠 PR，结果技术上没错、业务上更糟。最终的替换不是换工具而是换判据：衡量代码行数改成衡量爆炸半径，安全边界从合并挪到渐进发布，内部审查器对每个 PR 只回答一个问题——如果这个变更有缺陷，会坏掉哪些面向用户的功能。
Marked important, but published more than 30 days ago, so it moved down to this band.
On this page11 sections
This signal comes from a Chinese-language source and is written in Chinese.
Record
The signal
#Rootly 是做事故管理的，两年来一直推行严格的小 PR 文化：要求堆叠 PR，把一次原子变更限制在几百行以内。联合创始人兼 CTO Quentin Rousseau 说明为什么这条规则被废掉——而理由不是它错了，是它当初为之设计的那个前提没有了。
智能体改变的是工作的单位
人手写代码时，小 diff 更好审、更好回滚，所以小 PR 是最优解。智能体不是这样工作的：它以特性而不是增量为单位思考，一次性输出完整实现——数据库迁移、模型、服务、控制器、测试、前端组件一起给出来。
他们试过把这套流程套上去，让智能体生成堆叠 PR。结果是技术上挑不出错、整体业务上下文里反而更糟：审查某一个 PR 时，意见往往要依赖另一个 PR 里的改法，评审人被迫来回翻页重新梳理逻辑。这是一次带负面结果的尝试，不是一次直觉判断。
缺陷的形态也变了
工程团队给出的描述很精确：AI 引发的漏洞本质是上下文漏洞——代码本身能正常运行，只是被用在了错误的场景中。 举的两个例子都不需要读代码就能懂：某次数据库迁移删掉了后台任务仍在调用的字段；某个服务往一张表里写数据，而那张表正被另一个团队读取。
这正是本站《完成判定与验收信号》里那条判据的生产版本：一次成功的调用不等于一次正确的行动。 类型检查、测试、lint 全绿，仍然可以是错的。
换掉的是判据，不是工具
三件事一起动：
- 爆炸半径取代代码行数。 团队的原话是「代码改动量的大小已不再具备参考价值，真正关键的指标是故障影响范围」。
- 内部 AI 审查器只回答一个问题：如果这个变更存在缺陷，会破坏哪些面向用户的功能？它明确不试图扮演人类审查者，产出的是一份结构化报告——风险评估、标准化评分、置信度评分、按严重程度分类的问题列表——并把「会改变业务行为」的变更和「只影响性能或界面展示」的变更分开定级。给人类的是一个结构化的参考面，不是一份原始 diff。
- 安全边界从合并挪到发布。 每个重要特性都在特性开关后面上线：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 自己也写明，废掉一条曾经感觉非常正确的流程，起初让人很不适应。
Why now
Why it matters
#它是一次少见的、把流程规则连同它的前提一起写出来的复盘：小 PR 之所以正确，是因为人类写代码时 diff 大小与审查成本相关；智能体让这个相关性失效，于是规则本身失效。更有用的是它给出的替换——衡量爆炸半径而不是行数、把安全边界从合并挪到渐进发布、让审查器对每个 PR 只回答「坏了会影响谁」——三件都是可以照搬的具体做法。而它对缺陷形态的描述（代码能跑，只是用错了场景）正是这个站点反复遇到的那条判据在生产环境里的样子。
Background
Technical context
#Rootly 此前要求堆叠 PR、单次原子变更控制在几百行内。替换方案包含三部分：以爆炸半径而非 diff 大小定级；内部 AI 审查器输出风险评估、标准化评分、置信度评分与按严重程度分类的问题列表，并区分「改变业务行为」与「仅影响性能或展示」两类变更；所有重要特性经特性开关上线，合并后默认关闭，按团队内部→小批客户→10%→全量渐进放量。PR 的 why/what 由使用智能体的人填写，明确禁止 AI 生成；每个 PR 须描述安全回退方式，含数据修复。Rewind 的 Diff Vader 采用同类风险模型。
Audience
Who should care
#Next
Learning path
#- 先把那句判据记住：代码能正常运行，只是被用在了错误的场景中——这类缺陷测试与类型检查都拦不住
- 拿你团队现有的一条评审规则，写出它成立所依赖的前提，再看那个前提今天还在不在
- 读《人在回路的审查》：这条正是「按不可逆性放检查点」的实践版——合并变得可逆之后，检查点自然移到了放量
- 读《智能体工作流设计》里那条判据：如果模型决定越界，是什么在物理上阻止它？特性开关是一个真实的答案
- 把「这个变更坏了会影响哪些面向用户的功能」写成模板，先用人工填一周，再考虑要不要做成工具
Network
Where it sits in the network
#How this signal connects to neighbouring technologies, skills and background knowledge. Follow any link to keep exploring.
Further thought
Follow-up questions
#- 你们的评审规则里，哪几条的成立前提是「代码由人手写」？其中哪几条今天还成立？
- 一个变更出问题时，你能在几分钟内说出它会坏掉哪些面向用户的功能吗？如果不能，评审在评什么？
- 特性开关把关口挪到了放量阶段——那么谁在看放量期间的指标，看多久？
- PR 里的「为什么」如果由生成代码的智能体来写，你还能从中得到什么信息？
Publication record
Featured in
#The briefings that carried this signal, newest first; the last row is the weekly review of its week. The tag is the section it ran in.
技术简报 - 2026-08-18
Immediate attentionWeekly review · Aug 17 – Aug 23
Worth tracking
Sources