事故管理平台服务商 Rootly 发布博文，说明其为何放弃长期以来的“小型拉取请求”规则。文章指出，在 AI 智能体生成了大部分代码的当下，这一实践已不再适用。公司描述了其工作重心的转变：从衡量 PR 的代码行数转向评估“爆炸半径”，特性开关和回滚能力的重要性已远超代码行数指标。
在文章中，Rootly 联合创始人兼首席技术官 Quentin Rousseau 解释说，两年来，公司一直推行严格的小型 PR 文化，要求使用堆叠的 PR，并将原子性变更限制在几百行代码内。他表示，当人类手写代码时，这种做法是合理的，因为较小的代码差异更容易审查和回滚。他写道，AI 智能体改变了这一局面，因为它们以“特性”而非“增量”为单位进行思考，能够一次性输出完整的实现，包括数据库迁移、模型、服务、控制器、测试和前端组件。
AI 引发的漏洞本质属于上下文漏洞。代码本身能够正常运行，只是被用在了错误的场景中。举例来说：某次数据库迁移删掉了后台任务仍在调用的字段，或是某个服务向数据表写入数据，而该数据表正在被其他团队读取使用。
——Rootly 工程团队
文章讲述了他们曾尝试让 AI 智能体生成堆叠式拉取请求，最终产出的代码虽然不存在技术错误，但从整体业务上下文来看，效果反而更差。审查某一个 PR 时，评论意见往往要依赖另一个 PR 中的修改方案，迫使评审人员来回切换多个页面反复梳理逻辑，增加了心智负担。他们最终意识到：小 PR 规则原本是为人类编写代码的效率而设计的。如今 AI 已经打破了人工编码的效率限制，这条旧规则反倒成为额外的开销。
Rootly 的应对方案是，不再用审查人类代码的方式来审查 AI 代码。公司构建了一个内部的 AI 代码审查器，它会根据工程标准审查每一个 PR，并生成一份包含风险评估、标准化评分、置信度评分以及按严重程度分类罗列的具体问题的结构性审查报告。关键的区别在于，它并非试图扮演人类审查者的角色；相反，它针对每个 PR 只回答一个问题：如果这个变更存在缺陷，会破坏哪些面向用户的功能？
这个 AI 审查器会区分两类代码变更：一类会改变系统实际业务行为，另一类仅影响系统运行性能或是界面展示效果，并分别为二者匹配对应的风险等级，从而为人类审查者提供一个结构化的参考依据，而不仅仅是一个原始的代码差异对比。
Rousseau 强调，特性开关的使用已将安全边界从“合并”阶段转移到了“发布”阶段，因为每个重要特性现在都会在特性开关的保护下发布。当 PR 被合并、代码被推送到生产环境后，该特性默认是关闭的。真正的审查发生在渐进式发布过程中：首先在团队内部启用该特性，然后是一小部分客户，接着是 10% 的用户，最后才是所有用户。
代码改动量的大小已不再具备参考价值，真正关键的指标是故障影响范围。
——Rootly 工程团队
在 2026 年伦敦 QCon 技术大会的演讲中，Michael Webster 讨论了无界面 AI 智能体（Headless AI Agent）的兴起及其对软件交付流水线的影响。他提到，由 AI 生成的大规模拉取请求会给人工审核人员带来严重瓶颈，还会累积持续性技术债务。业内其他公司也有类似的观点。备份和版本控制服务商 Rewind 近期表示，其代码审核工具 Diff Vader 借鉴了 Rootly 这套基于风险的审核模型。Rewind 团队在其博客文章中写道，一个 PR 的风险与其代码行数几乎无关。Diff Vader 会根据审查结果为每个 PR 分配一个风险标签，而不是根据变更的行数。
“智能体驱动的拉取请求”是行业活动中的一个热门话题。在 2026 年 6 月的伦敦 AI 原生开发者大会上，一个小组讨论（现 Tessl 开发者关系负责人、被广泛誉为 DevOps 之父的 Patrick Debois 参与了讨论）探讨了为何一旦以智能体速度进行开发，基于 PR 的工作流在企业内部就会成为一种反模式。Debois 认为，PR 在开源社区中有其存在的意义，因为贡献者之间战略方向未必统一，彼此需要逐步建立信任；但在一个拥有共同上下文和目标的团队内部，当智能体快速迭代时，PR 审查周期就越来越难以证明其存在的合理性。在本次大会录制的一期播客节目里，Debois 和其他小组成员描述了使用 AI 智能体产生的成本正在倒逼开发流程走向规范化。过去纯人工开发阶段，流程中的低效之处很难被察觉；而如今 AI 产生的词元消耗可以量化，各类资源浪费会实实在在体现在账单成本中。
Rootly 现在的理念是提出那些真正能预测生产事故的问题。PR 中的“为什么”和“是什么”部分要求开发人员解释变更的动机、范围及其可能的影响。对于 AI 生成的 PR，由使用智能体的人类来填写这些内容。Rootly 明确要求 AI 助手不要生成这些内容，因为其核心目的是捕获上下文信息：为什么要做这个变更、为什么是现在、对应的业务诉求是什么。每个 PR 都需要描述如何安全地回退，包括必要的数据修复。
Rousseau 在文章结尾解释说，废除“小型 PR”规则——一个曾经感觉非常正确的流程——起初让人很不适应，但为了支持“快速交付可靠软件”，这么做是必要的。他在另一篇题为“Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead“的文章中更详细地阐述了这种向生产端安全的转变。
总而言之，该团队总结道：在全员手写代码的时代，采用小型拉取请求模式确实是最优解；但如今团队依靠调度 AI 智能体来交付整套完整功能，这套模式已不再适用。
查看英文原文：https://www.infoq.com/news/2026/08/rootly-small-pr-agentic-ai/
