过度把关是什么
过度把关指评审者用个人偏好阻塞改动、要求完美才放行：大量本可以后续处理的意见被标成阻塞，或者反复要求再改改却不说清标准。它抑制贡献意愿、拉长交付周期，与「改动整体变好即可放行」的评审标准背道而驰。
基本信息
| 典型信号 | 大量本可后续处理的意见被标为阻塞 |
|---|---|
| 另一信号 | 反复要求再改改，但不给出通过条件 |
| 判断依据 | 评审标准：让代码整体变好，而不是一次做到完美 |
| 校准动作 | 区分个人偏好与必须项，团队规则公开 |
典型使用场景
- 要求改成个人习惯的等价写法：交给格式化工具与团队规范
- 反复打回却不说标准：直接给出问题位置与达标要求
- 小瑕疵一律列为阻塞：先评估是否影响正确性，不影响就标非阻塞
- 对新人改动提高标准：先讲清规则与原因，再给一次性修改清单
- 讨论陷在措辞上：把话题拉回可验证的行为与后果
意见分级的三个判据
- 影响正确性、安全或可维护性吗
- 有团队规则或事实依据吗，还是只有个人偏好
- 如果定为阻塞，通过标准具体是什么
意见分级流程
意见分级流程
1. 影响正确性、安全或可维护性吗？否，则标 nit 或非阻塞，不挡合并。
2. 有团队规则或事实依据吗？只有偏好，则降级为非阻塞并注明理由。
3. 定为阻塞：写清通过标准，改到什么程度可以合并。
阻塞项只保留少数几条，其余转入后续任务或单独讨论。过度把关场景与校准
| 场景 | 校准动作 |
|---|---|
| 要求改成个人习惯的等价写法 | 风格交给格式化工具与团队规范，聚焦可验证问题 |
| 反复要求再改改，不说标准 | 给出明确通过条件：问题位置与达标要求 |
| 小瑕疵一律列为阻塞 | 先评估是否影响正确性，不影响则标非阻塞放行 |
| 对新人改动提高标准 | 先讲清规则与原因，再给一次性的修改清单 |
评审的目标是让代码前进，而不是证明评审者更聪明。
把个人偏好当作放行条件：作者被迫反复重写等价代码，评审变成消耗战。