AI热榜 事故管理平台服务商 Rootly 发布 博文 ，说明其为何放弃长期以来的“小型拉取请求”规则。
文章指出，在 AI 智能体生成了大部分代码的当下，这一实践已不再适用。
公司描述了其工作重心的转变：从衡量 PR 的代码行数转向评估“爆炸半径”，特性开关和回滚能力的重要性已远超代码行数指标。
在文章中，Rootly 联合创始人兼首席技术官 Quentin Rousseau 解释说，两年来，公司一直推行严格的小型 PR 文化，要求使用堆叠的 PR，并将原子性变更限制在几百行代码内。
他表示，当人类手写代码时，这种做法是合理的，因为较小的代码差异更容易审查和回滚。
他写道，AI 智能体改变了这一局面，因为它们以“特性”而非“增量”为单位进行思考，能够一次性输出完整的实现，包括数据库迁移、模型、服务、控制器、测试和前端组件。
AI 引发的漏洞本质属于上下文漏洞。
代码本身能够正常运行，只是被用在了错误的场景中。
举例来说：某次数据库迁移删掉了后台任务仍在调用的字段，或是某个服务向数据表写入数据，而该数据表正在被其他团队读取使用。
——Rootly 工程团队 文章讲述了他们曾尝试让 AI 智能体生成堆叠式拉取请求，最终产出的代码虽然不存在技术错误，但从整体业务上下文来看，效果反而更差。
审查某一个 PR 时，评论意见往往要依赖另一个 PR 中的修改方案，迫使评审人员来回切换多个页面反复梳理逻辑，增加了心智负担。
他们最终意识到：小 PR 规则原本是为人类编写代码的效率而设计的。
如今 AI 已经打破了人工编码的效率限制，这条旧规则反倒成为额外的开销。
Rootly 的应对方案是，不再用审查人类代码的方式来审查 AI 代码。
公司构建了一个内部的 AI 代码审查器，它会根据工程标准审查每一个 PR，并生成一份包含风险评估、标准化评分、置信度评分以及按严重程度分类罗列的具体问题的结构性审查报告。
关键的区别在于，它并非试图扮演人类审查者的角色；相反，它针对每个 PR 只回答一个问题：如果这个变更存在缺陷，会破坏哪些面向用户的功能？
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接