⧖ 规则过时 · 范式断裂
▸ 旧规则：小 PR 文化
代码行数限制
500
行
堆叠 PR 要求
人类增量式提交
▸ 终结标志
AI 特性式输出 打破规则 —— 一次性交付完整功能，小 PR 规则成为负担
灰蓝 → 灰红 · 褪色感表示规则已失效
背景：小 PR 规则的黄金时代与终结
Rootly 曾严格推行小型 PR 文化，要求堆叠 PR 并将原子性变更限制在几百行以内。
当人类手写代码时，这种做法合理且高效——较小的差异便于审查和回滚。
两年来，我们一直推行严格的小型 PR 文化，要求使用堆叠的 PR，并将原子性变更限制在几百行代码内。当人类手写代码时，这种做法是合理的。
Quentin Rousseau Rootly 联合创始人兼 CTO
旧规则核心指标
代码行数 < 500 行 / 堆叠 PR
基于人类编码效率与认知负荷设计
AI 智能体以“特性”而非“增量”为单位思考，能一次性输出完整实现，包括数据库迁移、模型、服务、控制器、测试和前端组件。这使得小 PR 规则反而制造额外开销。
人类编码模式
增量式提交，每次变更有限
AI 编码模式
特性式输出，一次性交付完整功能
AI 引发的漏洞本质属于上下文漏洞。代码本身能够正常运行，只是被用在了错误的场景中。
Rootly 工程团队
尝试堆叠 PR 的后果
代码无技术错误，但整体业务上下文更差
审查时需跨 PR 跳转，心智负担增加 — 迫使评审人员来回切换多个页面，反复梳理逻辑
Rootly 的新方案：风险导向的 AI 代码审查
不再用审查人类代码的方式审查 AI 代码。Rootly 构建内部 AI 代码审查器，针对每个 PR 回答核心问题：如果此变更存在缺陷，会破坏哪些面向用户的功能？
AI 审查器输出结构
风险评估 + 标准化评分 + 置信度评分 + 分类问题列表
区分业务行为变更与性能/界面变更，分别匹配风险等级
代码改动量的大小已不再具备参考价值，真正关键的指标是故障影响范围。
Rootly 工程团队
✦ 特性开关 将安全边界从“合并”阶段转移到“发布”阶段：每个重要特性在特性开关保护下发布，默认关闭；真正审查发生在渐进式发布过程中（团队内部 → 小部分客户 → 10% 用户 → 全部用户）。
新实践：PR 中的“为什么”与“回退计划” — Rootly 现在要求 PR 描述变更的动机、范围、影响及安全回退方法（包括必要的数据修复）。禁止 AI 生成这些内容，必须由人类填写以捕获上下文。
PR 新增必填项
为什么变更？为什么是现在？对应的业务诉求？如何安全回退？
针对 AI 生成的 PR，由使用智能体的人类填写
行业反响：智能体 PR 的反模式趋势
PR 在开源社区中有其存在的意义，因为贡献者之间战略方向未必统一，彼此需要逐步建立信任；但在一个拥有共同上下文和目标的团队内部，当智能体快速迭代时，PR 审查周期就越来越难以证明其存在的合理性。
Patrick Debois Tessl 开发者关系负责人，DevOps 之父
开源社区 PR 价值
建立信任、协调方向
内部团队 + AI 智能体
PR 审查成为反模式，成本高、效率低
AI 词元成本量化
AI 产生的词元消耗可量化，流程低效直接体现在账单上
倒逼开发流程走向规范化（2026 年伦敦 AI 原生开发者大会讨论）
备份与版本控制服务商 Rewind 借鉴 Rootly 模型，其工具 Diff Vader 根据风险标签而非代码行数来评估 PR。
总结：从“快合并”到“快回滚” — Rousseau 在另一篇文章《Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead》中详细阐述了向生产端安全的转变：核心不是审查更快，而是确保回滚能力。
在全员手写代码的时代，采用小型拉取请求模式确实是最优解；但如今团队依靠调度 AI 智能体来交付整套完整功能，这套模式已不再适用。
Rootly 工程团队
✦ 编辑观察
Rootly 的案例揭示了一个趋势：AI 智能体改写开发流程后，传统基于人因工程（如小 PR 降低认知负荷）的规则需要被重新审视。转向风险导向与回滚能力，本质上是将安全边界从代码审查阶段后移至发布与运维阶段，这与“持续交付”理念一脉相承。行业其他玩家（Rewind、Debois 等）的呼应进一步印证了这一变化并非孤例，而是 AI 原生开发范式下的必然挑战。
◆ 最终判断
Rootly 的决策果断且务实 — 放弃一个曾经正确但已过时的规则，拥抱以“爆炸半径”和“特性开关”为核心的新范式。虽然初期会带来不适应，但这是支持“快速交付可靠软件”的必要进化。文章为所有 AI 辅助开发团队提供了一个可参考的转型路径：不再与 AI 生成代码的速度赛跑，而是投资于快速回滚与风险量化。