从“小而美”到按风险评审

事故管理平台服务商 Rootly 近期发布博文称，已放弃长期坚持的“小型拉取请求”规则，因为在 AI 智能体生成大部分代码的开发环境中，按代码行数控制 PR 大小不再是最有效的安全手段。公司将评审重点从“这个 PR 有多少行”转向“如果出错，会影响哪些用户功能”，也就是更关注爆炸半径——故障可能波及的范围。

Rootly 联合创始人兼首席技术官 Quentin Rousseau 表示，过去两年公司推行严格的小 PR 文化：使用堆叠式 PR，将原子变更限制在几百行代码内。对人类手写代码而言，这种方式有明确价值：差异小，更容易阅读、评论和回滚。但 AI 智能体改变了代码生产方式，它们通常按“完整特性”而非“细小增量”组织工作，可能一次生成数据库迁移、模型、服务、控制器、测试和前端组件。

AI 代码的问题不只在语法

Rootly 工程团队认为，AI 引入的漏洞很多属于“上下文漏洞”：代码本身可运行，却被放在错误业务场景中。例如，数据库迁移删除了后台任务仍在调用的字段，或某个服务写入的数据表正被其他团队读取。换言之，问题不一定出现在单个函数，而可能出现在系统协作边界。

公司曾尝试让 AI 智能体输出堆叠式 PR，但结果并不理想。单个 PR 往往没有明显技术错误，整体业务语义却更难判断；评审者在评论一个 PR 时，需要参考另一个 PR 的修改，反复切换页面理解上下文，心智负担上升。Rootly 由此得出结论：小 PR 规则是为人类编码效率设计的，而 AI 已经突破了这部分效率瓶颈，旧规则反而可能成为额外流程成本。

内部 AI 审查器与发布端安全

Rootly 的新做法不是让人更快地审查 AI 写出的代码，而是改变审查问题本身。公司构建了内部 AI 代码审查器，依据工程标准检查每个 PR，并生成结构化报告，包括风险评估、标准化评分、置信度评分，以及按严重程度分类的问题清单。

关键区别在于，这个工具并不试图替代人类评审者，而是聚焦一个问题：如果这个变更有缺陷，会破坏哪些面向用户的功能？ 它会区分两类变化：

• 改变系统实际业务行为的代码；
• 主要影响性能或界面展示的代码。

不同类型对应不同风险等级，为人工评审提供比原始 diff 更清晰的判断依据。

与此同时，Rootly 将安全边界从“合并”阶段后移到“发布”阶段。重要特性通过特性开关发布；代码进入生产环境后，功能默认关闭，再逐步面向内部团队、小部分客户、10% 用户，最后扩展到全部用户。特性开关是一种控制功能启停的机制，可在不重新部署代码的情况下调整可见范围。Rousseau 强调，代码改动量已不再具备核心参考价值，真正关键的是故障影响范围和回滚能力。每个 PR 都需要说明变更动机、范围、影响以及安全回退方式；对 AI 生成的 PR，这些“为什么”和“是什么”由使用智能体的人类填写，Rootly 明确不让 AI 助手代写，以保留真实业务上下文。

行业共识正在形成

类似讨论并不只发生在 Rootly。Michael Webster 在 2026 年伦敦 QCon 技术大会上谈到，无界面 AI 智能体正在影响软件交付流水线，大规模 AI 生成 PR 可能让人工审核成为瓶颈，并累积持续性技术债务。备份和版本控制服务商 Rewind 也表示，其代码审核工具 Diff Vader 借鉴了 Rootly 的风险模型：PR 风险几乎不取决于代码行数，而应根据审查结果打风险标签。

在 2026 年 6 月伦敦 AI 原生开发者大会上，围绕“智能体驱动的 PR”的讨论也指向同一趋势。Patrick Debois 等人认为，PR 在开源场景仍有价值，因为贡献者需要建立信任；但在目标一致、上下文共享的企业团队内部，当智能体高速迭代时，传统 PR 周期的合理性会被重新审视。AI 还把流程浪费转化为可见成本：词元消耗能被量化，低效评审会直接反映到账单和交付节奏上。

走向：少看行数，多看事故半径

Rootly 的转向并不意味着代码评审失去意义，而是评审对象从“代码片段是否优雅”扩展为“变更能否安全进入生产”。在 AI 参与开发后，团队更需要明确业务上下文、发布控制、监控与回滚方案。未来的软件交付流程可能不会简单取消 PR，而会把 PR 从唯一防线变成风险登记、上下文捕获和发布治理的一环。对普通工程团队而言，真正值得借鉴的不是盲目放大小 PR，而是建立能回答生产风险的问题：影响谁、如何灰度、怎样回退。