响应速度为什么重要
Google 评审文档把速度单列一节：改动停在队列里等待时，团队整体交付被拖慢，作者对改动的上下文也在流失——等得越久，返工和冲突越多。文档给出的口径是在约一个工作日内给出回应；做不到时应主动说明或转交他人，不要让改动静静挂着。
基本信息
| 响应准则 | 约一个工作日内给出回复（Google 文档口径） |
|---|---|
| 回应含义 | 可以只是确认已看到并给出预计时间，不要求当天评完 |
| 例外处理 | 忙不过来时明确告知作者，或请对方转交其他评审人 |
| 时间选择 | 大改动建议在精力充沛的时段看，与快速回应并不矛盾 |
为什么等待代价高
- 作者上下文在流失：等待期间可能已开始另一项工作，回头再改成本更高。
- 冲突随时间累积：主干持续前进，越晚合并越容易产生大面积冲突。
- 反馈延迟削弱评审价值：小问题拖成返工，评审逐渐被视为流程负担。
- 队列积压会传染：一个人的延迟会让下游多个改动同时排队。
不同情形怎么回
| 情形 | 建议做法 |
|---|---|
| 暂时没空细看 | 先回复已收到并给出预计评审时间 |
| 改动很小 | 当场评完，避免进入队列 |
| 自己不熟悉该模块 | 尽快请更合适的人接手，而不是拖着 |
| 需要作者补充信息 | 立刻提问，别等看完才一并回复 |
两段式回应
- 第一段：确认收到，并给出大致时间点（如今天下午细看）。
- 第一段可以先提明显问题：格式、缺测试、描述缺失，作者能并行修改。
- 第二段：完整逐文件评审，给出结论（批准或阻塞清单）。
- 评审中发现需要大改：尽早沟通，别等到评完才说方向不对。
快速响应不等于草率批准：先保响应速度，再保评审质量，两者并不冲突。
团队可以把「首次响应时间」与「评审停留时长」当作可观测指标，比逐个催人更有效。