核心观点 - 事故管理平台Rootly宣布放弃长期执行的“小型拉取请求(PR)”规则，因为AI智能体生成大部分代码的当下，该实践已不再适用[2] - 公司工作重心从衡量PR代码行数转向评估“爆炸半径”(故障影响范围)，特性开关和回滚能力的重要性远超代码行数指标[2][9] 小型PR规则的失效原因 - Rootly曾推行两年严格的小型PR文化，要求使用堆叠PR并将原子性变更限制在几百行代码内，当人类手写代码时这种做法合理，因为较小代码差异更容易审查和回滚[5] - AI智能体以“特性”而非“增量”为单位思考，能一次性输出完整实现，包括数据库迁移、模型、服务、控制器、测试和前端组件[5] - AI引发的漏洞本质属于上下文漏洞，代码本身能正常运行但被用在错误场景，例如数据库迁移删掉后台任务仍在调用的字段，或服务向被其他团队读取的数据表写入数据[5] - 尝试让AI生成堆叠式PR后，产出代码虽无技术错误，但从整体业务上下文看效果更差，审查一个PR时评论依赖另一PR的修改，迫使评审人员来回切换页面，增加心智负担[6] - 小型PR规则原本为人类编写代码效率设计，AI打破人工编码效率限制后，该规则反成额外开销[7] 应对方案：AI代码审查器 - Rootly构建内部AI代码审查器，根据工程标准审查每个PR，生成包含风险评估、标准化评分、置信度评分及按严重程度分类问题的结构性审查报告[7] - 该审查器不试图扮演人类审查者，而是针对每个PR回答一个问题：如果变更存在缺陷，会破坏哪些面向用户的功能[7] - AI审查器区分两类代码变更：一类改变系统实际业务行为，另一类仅影响系统运行性能或界面展示效果，并分别匹配对应风险等级，为人类审查者提供结构化参考依据[7] 特性开关与发布流程转变 - 特性开关的使用将安全边界从“合并”阶段转移到“发布”阶段，每个重要特性在特性开关保护下发布[8] - PR合并、代码推送到生产环境后，该特性默认关闭，真正审查发生在渐进式发布过程中：先在团队内部启用，然后是一小部分客户，接着是10%用户，最后是所有用户[8] 行业趋势与观点 - 在2026年伦敦QCon技术大会上，Michael Webster讨论无界面AI智能体兴起及其对软件交付流水线的影响，指出AI生成的大规模PR会给人工审核带来严重瓶颈并累积持续性技术债务[10] - 备份和版本控制服务商Rewind的代码审核工具Diff Vader借鉴Rootly基于风险的审核模型，一个PR的风险与其代码行数几乎无关，Diff Vader根据审查结果为每个PR分配风险标签而非根据变更行数[10] - 在2026年6月伦敦AI原生开发者大会上，DevOps之父Patrick Debois参与小组讨论，探讨以智能体速度开发时基于PR的工作流在企业内部成为反模式[11] - Debois认为PR在开源社区有意义，因贡献者战略方向未必统一需逐步建立信任，但在拥有共同上下文和目标的团队内部，当智能体快速迭代时PR审查周期越来越难证明其合理性[11] - Debois和其他小组成员描述使用AI智能体产生的成本倒逼开发流程走向规范化，过去纯人工开发阶段流程低效难察觉，如今AI词元消耗可量化，资源浪费体现在账单成本中[11] 新理念与PR内容要求 - Rootly理念是提出能预测生产事故的问题，PR中的“为什么”和“是什么”部分要求开发人员解释变更动机、范围及可能影响[11] - 对于AI生成的PR，由使用智能体的人类填写这些内容，Rootly明确要求AI助手不要生成，因为核心目的是捕获上下文信息：为什么做变更、为什么是现在、对应的业务诉求是什么[11][12] - 每个PR需描述如何安全回退，包括必要的数据修复[12] - Rootly联合创始人兼CTO Quentin Rousseau解释，废除“小型PR”规则起初让人不适应，但为支持“快速交付可靠软件”是必要的[12] - 团队总结：全员手写代码时代小型PR模式是最优解，但如今依靠调度AI智能体交付整套完整功能，该模式已不再适用[12]