AI智能体主导编码，Rootly取消小型PR规则

近期，事故管理服务商Rootly宣布废除长期推行的小型拉取请求（PR）规则，这一调整源于AI智能体已经承担了绝大多数编码工作，旧有的流程规范已经不再适配当前的开发模式。公司将工作重心从衡量PR的代码行数，转向评估变更的“爆炸半径”——也就是故障影响范围，特性开关和回滚能力的重要性已经远超代码行数指标。

Rootly在过去两年间一直严格执行小型PR文化，要求使用堆叠式PR，将单次原子性变更限制在几百行代码以内。在人类手写代码的时代，这种规则是合理的：较小的代码差异更容易被审查，也更便于后续回滚操作。但AI智能体的出现彻底改变了这一局面——AI是以完整的“特性”为单位进行开发，能够一次性输出涵盖数据库迁移、模型、服务、控制器、测试用例乃至前端组件的完整实现，而非逐行的增量修改。

团队曾经尝试让AI智能体生成堆叠式拉取请求，但最终产出的代码虽然没有技术错误，从业务上下文来看效果却更差。审查单个PR时，评审意见往往需要依赖其他PR的修改内容，评审人员不得不反复切换多个页面梳理逻辑，大幅增加了心智负担。团队最终意识到，小型PR规则原本是为人类手写代码的效率设计的，如今AI已经打破了人工编码的效率瓶颈，这条旧规则反而成了额外的开发开销。

AI 引发的漏洞本质属于上下文漏洞。代码本身能够正常运行，只是被用在了错误的场景中。举例来说：某次数据库迁移删掉了后台任务仍在调用的字段，或是某个服务向数据表写入数据，而该数据表正在被其他团队读取使用。

——Rootly 工程团队

Rootly不再沿用审查人类代码的方式来审核AI生成的PR。他们搭建了内部的AI代码审查工具，会基于工程标准对每个PR进行审查，并生成结构化的审查报告，其中包含风险评估、标准化评分、置信度评分，以及按严重程度分类的具体问题。和人类审查者不同，这个AI审查工具只会聚焦一个核心问题：如果这个变更存在缺陷，会破坏哪些面向用户的功能？

该工具会区分两类代码变更：一类是会改变系统实际业务行为的变更，另一类仅影响系统运行性能或是界面展示效果，并为两类变更分别匹配对应的风险等级，为人类审查者提供结构化的参考依据，而非单纯的代码差异对比。

Rootly的CTO Quentin Rousseau强调，特性开关的普及已经将安全边界从“代码合并”阶段转移到了“发布”阶段。每个重要特性都会在特性开关的保护下发布：当PR被合并、代码推送到生产环境后，该特性默认是关闭的。真正的审查发生在渐进式发布过程中：先在团队内部启用，再面向小部分客户，接着覆盖10%的用户，最终才推广至全部用户。

代码改动量的大小已不再具备参考价值，真正关键的指标是故障影响范围。

——Rootly 工程团队

业内已经有不少公司认同这一思路。2026年伦敦QCon技术大会上，Michael Webster讨论了无界面AI智能体的兴起对软件交付流水线的影响，他提到AI生成的大规模拉取请求会给人工审核带来严重瓶颈，还会累积持续的技术债务。备份和版本控制服务商Rewind的代码审核工具Diff Vader就借鉴了Rootly的基于风险的审核模型，该工具不会根据变更行数来评估PR风险，而是会根据审查结果为每个PR分配风险标签。

“智能体驱动的拉取请求”已经成为行业活动中的热门话题。2026年6月的伦敦AI原生开发者大会上，一场小组讨论邀请了DevOps之父Patrick Debois等人，探讨了在智能体驱动的开发节奏下，基于PR的工作流为何会成为企业内部的反模式。Debois认为，PR在开源社区仍有存在意义：开源贡献者之间的战略方向未必统一，需要通过PR逐步建立信任；但在拥有共同上下文和目标的团队内部，当开发速度由AI智能体驱动时，PR审查周期越来越难以证明其合理性。他还提到，使用AI智能体产生的成本正在倒逼开发流程规范化：在纯人工开发阶段，流程中的低效之处很难被察觉；而如今AI的词元消耗可以被量化，各类资源浪费会直接体现在账单成本中。

Rootly现在的核心理念是提出真正能预测生产事故的问题。每个PR都需要包含“为什么”和“是什么”部分，要求开发人员解释变更的动机、范围和可能的影响。对于AI生成的PR，这些内容需要由使用智能体的人类开发者填写，Rootly明确要求AI助手不要生成这些信息，因为其核心目的是捕获上下文：为什么要进行这次变更、为什么选择在此时进行、对应的业务诉求是什么。此外，每个PR都必须描述如何安全回退，包括必要的数据修复方案。

Rousseau在文章结尾提到，废除小型PR规则——这个曾经被认为完全正确的流程，起初让人很不适应，但为了支持“快速交付可靠软件”的目标，这一调整是必要的。团队最终总结道，在全员手写代码的时代，小型拉取请求模式确实是最优解；但如今团队依靠调度AI智能体交付完整功能，这套模式已经不再适用。