ARTICLE · 人工智能

Rootly 取消小 PR 规则,智能体 AI 改变代码审查经济学

作者:Matt Saunders 来源:InfoQ 2026-08-07 16:00 4 分钟 4 阅读 906 字
AI 编程AI 智能体Pull Request代码审查功能开关
一语总结

Rootly 解释了为何废除其小 Pull Request 规则,认为 AI 智能体现在会生成完整功能代码,使基于代码行数的审查过时,并将焦点转向影响范围、功能开关和 AI 辅助的风险评估。

AI 总结

Rootly 联合创始人兼 CTO Quentin Rousseau 描述了公司长期以来实行的小 PR 策略——最初是为了让 diff 足够小、便于人工审查——在 AI 智能体开始生成公司大部分代码后变得适得其反。AI 智能体以完整功能而非增量变更的方式思考,会在一个 PR 中输出迁移、模型、服务、控制器、测试和前端组件。试图强制 AI 生成堆叠式 PR,结果产生了技术上正确但上下文混乱的变更,迫使审查者在多个标签页之间处理依赖关系。团队意识到,小 PR 规则是针对人类编写速度优化的,而 AI 消除了这一限制,使该规则变成不必要的开销。为此,Rootly 不再以审查人类代码的方式审查 AI 生成的代码,而是构建了一个内部 AI 代码审查器,根据工程标准评估每个 PR,并返回包含风险评估、标准化评分、置信度评分和按严重程度分组结果的结构化审查,回答核心问题:如果这个变更存在 bug,哪些面向用户的行为会被破坏?该审查器会区分改变系统行为的变更与影响性能或外观的变更,并分配相应的风险档案。Rootly 还将安全边界从合并阶段移到发布阶段,把每个重要功能都包裹在功能开关后面;真正的审查发生在逐步向内部团队、一小部分客户群、再向更广泛受众推出的过程中。文章还引用了类似的行业举措,如 Rewind 的 Diff Vader 工具,并提及 QCon London 2026 和 AI Native DevCon London 上的讨论,专家们认为基于 PR 的工作流在智能体速度下会变成反模式。Rootly 现在要求作者填写“Why and What”部分,以捕获 AI 缺乏的上下文,并且每个 PR 都必须描述如何安全地自我撤销,包括任何数据修复。Rousseau 总结道,放弃小 PR 规则虽然最初令人不适,但在 AI 驱动的开发环境中快速交付可靠软件是必要的。

核心要点
  1. AI 智能体会生成完整功能,使基于代码行数的 PR 审查变得过时。

    Rootly 发现,AI 生成的 PR 在单个 diff 中包含迁移、模型、服务、控制器、测试和前端代码,因此再以代码量来评判,已无法预测审查工作量或风险。

  2. 团队将关注点从 PR 大小转向影响范围,并使用功能开关来保障安全。

    通过衡量变更的潜在影响(影响范围)并在功能开关后发布特性,Rootly 将安全门从合并阶段移至渐进式发布阶段,在真实环境中进行验证。

  3. 内部 AI 代码审查器提供结构化、以风险为中心的反馈,而不是原始 diff。

    AI 审查器会根据工程标准检查每个 PR,输出风险评估、标准化分数和置信度分数,并按严重程度对结果分组,回答这样一个问题:如果此变更有 bug,哪些面向用户的行为会被破坏?

  4. 每个 AI 编写的 PR 都必须包含“Why and What”部分以及回滚计划,以补全缺失的上下文。

    由于 AI 缺乏业务上下文,人类编写提示词时需要补充动机、范围和影响;每个 PR 还必须描述如何安全地自我撤销,包括任何必要的数据修复。

Rootly 取消小 PR 规则,智能体 AI 改变代码审查经济学

Rootly 联合创始人兼 CTO Quentin Rousseau 描述了公司长期以来实行的小 PR 策略——最初是为了让 diff 足够小、便于人工审查——在 AI 智能体开始生成公司大部分代码后变得适得其反。AI 智能体以完整功能而非增量变更的方式思考,会在一个 PR 中输出迁移、模型、服务、控制器、测试和前端组件。试图强制 AI 生成堆叠式 PR,结果产生了技术上正确但上下文混乱的变更,迫使审查者在多个标签页之间处理依赖关系。团队意识到,小 PR 规则是针对人类编写速度优化的,而 AI 消除了这一限制,使该规则变成不必要的开销。为此,Rootly 不再以审查人类代码的方式审查 AI 生成的代码,而是构建了一个内部 AI 代码审查器,根据工程标准评估每个 PR,并返回包含风险评估、标准化评分、置信度评分和按严重程度分组结果的结构化审查,回答核心问题:如果这个变更存在 bug,哪些面向用户的行为会被破坏?该审查器会区分改变系统行为的变更与影响性能或外观的变更,并分配相应的风险档案。Rootly 还将安全边界从合并阶段移到发布阶段,把每个重要功能都包裹在功能开关后面;真正的审查发生在逐步向内部团队、一小部分客户群、再向更广泛受众推出的过程中。文章还引用了类似的行业举措,如 Rewind 的 Diff Vader 工具,并提及 QCon London 2026 和 AI Native DevCon London 上的讨论,专家们认为基于 PR 的工作流在智能体速度下会变成反模式。Rootly 现在要求作者填写“Why and What”部分,以捕获 AI 缺乏的上下文,并且每个 PR 都必须描述如何安全地自我撤销,包括任何数据修复。Rousseau 总结道,放弃小 PR 规则虽然最初令人不适,但在 AI 驱动的开发环境中快速交付可靠软件是必要的。

文章金句

"

AI 的 bug 是上下文 bug。代码本身能运行,但被应用到了错误的地方。

"

diff 的大小已不再是有效信号,影响范围才是。