ARTICLE · 软件编程
AI 智能体改变代码评审逻辑，Rootly 废止小 PR 规则
一语总结Rootly 因 AI 智能体生成大块代码而废除小 PR 规则，转向评估爆炸半径并使用 AI 代码审查器与特性开关保障生产安全。
文章讲述了事故管理平台 Rootly 官宣取消长期实施的“小型拉取请求”规则。原因在于 AI 智能体如今能够以特性为单位一次性输出完整实现（包括数据库迁移、模型、服务、控制器、测试和前端组件），使得以代码行数衡量 PR 大小的旧做法失效。Rootly 将审查重点从代码行数转移到“爆炸半径”，即评估变更可能影响的用户功能范围。为此，公司构建了内部 AI 代码审查器，该审查器不模拟人类审查者，而是根据工程标准给出结构化报告，包含风险评估、置信度以及按严重程度分类的具体问题，帮助人类聚焦真正的安全边界。同时，特性开关的使用把安全边界从合并阶段转移到发布阶段，重要特性默认关闭，通过渐进式发布（内部→小范围客户→10%用户→全部用户）进行真实审查。文章还引用了行业共识：如 Rewind 的 Diff Vader 等工具也采用基于风险标签而非代码行数的审查模式，并强调人类需要在 PR 中补充“为什么”“是什么”“如何回滚”的上下文说明，而不应让 AI 生成这些内容。整体表明，在 AI 驱动的代码生成时代，传统的小 PR 工作流已成为反模式，需以风险导向、特性开关和渐进发布为核心的新流程取而代之。
- 小型 PR 规则因 AI 智能体生成大块代码而失效，需转向评估“爆炸半径”。
AI 以特性为单位输出完整实现，代码行数不再是审查负担的主要衡量标准，真正关键的是故障影响范围。
- Rootly 构建内部 AI 代码审查器，关注变更对用户功能的潜在影响，而非仅仅代码差异。
审查器输出结构化报告，包含风险评估、置信度及按严重程度分类的具体问题，帮助人类审查者聚焦真正的安全边界。
- 特性开关将安全边界从合并阶段转移到发布阶段，结合渐进式发布降低风险。
重要特性默认关闭，先在内部小范围启用，再逐步扩大到 10% 用户及全部用户，真正的审查发生在发布过程。
- 行业共识：AI 驱动的大规模 PR 成为瓶颈，风险与代码行数无关，需基于风险标签的审查模式。
如 Rewind 的 Diff Vader 等工具已采用类似做法，印证 Rootly 的方法，表明这是一种广泛的最佳实践。
- 人类需在 PR 中补充上下文说明（为什么、是什么、如何回滚），而不应让 AI 生成这些内容。
捕获业务诉求和回滚计划是保证生产安全的关键，AI 只负责代码生成，上下文由人类提供。
AI 智能体改变代码评审逻辑，Rootly 废止小 PR 规则
文章讲述了事故管理平台 Rootly 官宣取消长期实施的“小型拉取请求”规则。原因在于 AI 智能体如今能够以特性为单位一次性输出完整实现（包括数据库迁移、模型、服务、控制器、测试和前端组件），使得以代码行数衡量 PR 大小的旧做法失效。Rootly 将审查重点从代码行数转移到“爆炸半径”，即评估变更可能影响的用户功能范围。为此，公司构建了内部 AI 代码审查器，该审查器不模拟人类审查者，而是根据工程标准给出结构化报告，包含风险评估、置信度以及按严重程度分类的具体问题，帮助人类聚焦真正的安全边界。同时，特性开关的使用把安全边界从合并阶段转移到发布阶段，重要特性默认关闭，通过渐进式发布（内部→小范围客户→10%用户→全部用户）进行真实审查。文章还引用了行业共识：如 Rewind 的 Diff Vader 等工具也采用基于风险标签而非代码行数的审查模式，并强调人类需要在 PR 中补充“为什么”“是什么”“如何回滚”的上下文说明，而不应让 AI 生成这些内容。整体表明，在 AI 驱动的代码生成时代，传统的小 PR 工作流已成为反模式，需以风险导向、特性开关和渐进发布为核心的新流程取而代之。
文章金句
"AI 引发的漏洞本质属于上下文漏洞。代码本身能够正常运行，只是被用在了错误的场景中。
"代码改动量的大小已不再具备参考价值，真正关键的指标是故障影响范围。
"特性开关的使用已将安全边界从'合并'阶段转移到了'发布'阶段。