PR 的目标是让一次变更可以被理解、审查、验证和回滚。
如果 reviewer 无法在合理时间内审完，PR 就太大了。
可以拆成：
小 PR 的价值主要在于更容易理解、更容易回滚、更适合堆叠审查，不要机械承诺“小 PR 一定合并更快”。
有研究发现，变更大小和合并耗时之间并没有稳定相关性。团队仍然应该鼓励小 PR，但理由要放在可审查性、可验证性和可回滚性上，见 Git 工作流经验研究笔记。
Google Code Review 和 Meta Sapling 的公开实践也指向同一个判断：小变更的核心价值是降低理解成本和风险定位成本。AI 生成大 diff 后，也应该先拆回人类可以审查的小单元，见 大厂工程实践决策图谱。
当一个功能天然较大，可以拆成一组有依赖关系的小 PR：
PR 1: data model
PR 2: service logic
PR 3: API
PR 4: tests and docs
这种方式适合大功能、AI 生成大 diff、跨模块重构。
注意事项：
直接使用 Pull Request Template。
AI 生成代码后，PR 描述不能只写“AI generated”。
至少要写清：