橡皮图章式评审
橡皮图章指不看、或只草草扫一眼就点批准：评审信号因此失真，缺陷照常流入主干。成因通常不是态度问题，而是流程问题——强制要求批准人数、评审队列长期过长、或者一个人待审的改动量远超能认真读完的量。
基本信息
| 典型症状 | 评审耗时极短、评论为空、批准紧跟提交 |
|---|---|
| 常见成因 | 强制批准人数、队列过长、评审人过载 |
| 核心对策 | 控制队列长度、轮值评审人、给评审留时间预算 |
| 可观测信号 | 空批准率、评审时长分布、批准人员集中度 |
典型使用场景
- 团队要求每个 PR 至少两人批准：凑人头时最容易出现盖章
- 发布窗口临近：为了赶时间，几百行的改动被快速放行
- 评审人同时挂着十几个 PR：注意力被摊薄，只能扫一眼
- 改动看起来很小：小改动也可能藏着权限与配置变更
- 同一人反复批准同一作者的改动：人情式通过替代了技术判断
批准前的三问自检
批准前的三问自检
1. 不看描述，能说清这次改动做了什么、为什么这么做吗？
2. 能说出自己读过的关键文件，以及错误路径与边界条件看过没有？
3. 能说出验证方式：测试覆盖了什么，失败时会怎样？
三问都答不上来就该补读，不要把批准当盖章。
批准时留一句结论：看过哪些文件、验证了哪些行为。抽查已批准记录时看什么
| 抽查项 | 异常表现 | 说明 |
|---|---|---|
| 时间间隔 | 数百行改动在几分钟内被批准 | 审读时间与改动规模严重不匹配 |
| 对话状态 | 批准时仍有未回复的提问 | 问题被跳过，而不是被解决 |
| 人员分布 | 批准长期集中在个别人身上 | 队列过载或责任过度集中 |
评审不是签字仪式：没有内容的批准对质量零贡献，还会稀释责任，事后没人说得清当初究竟看了什么。
把空批准率与评审时长分布透明化，比反复强调「认真一点」有效：数据暴露的是队列问题，不是态度问题。