结对与即时评审是什么
即时评审在写代码的同时完成反馈：两个人一起写，或一个人写、另一个人在旁看。它把评审成本摊进开发过程，特别适合危急修复、复杂逻辑和新人任务。局限同样明确——缺少书面记录，团队之外的人看不到讨论过程，结论容易随对话结束而散失。
基本信息
| 常见形态 | 结对编程、旁站评审、共享屏幕即时评审 |
|---|---|
| 适用场景 | 紧急修复、复杂算法、新人任务、跨模块改动 |
| 主要局限 | 缺少书面记录，团队外部不可见 |
| 收尾动作 | 把结论回写到 PR 描述或置顶评论 |
典型使用场景
- 线上故障紧急修复：两人一起定位根因，边改边核对
- 复杂算法或并发逻辑：两个人对着推演边界条件
- 新人第一次独立改动：老手在旁即时纠偏
- 跨模块改动：模块负责人在场解释既有约定
- 讨论陷入文字拉扯：改成共享屏幕，十分钟说清
结论回写的四个要素
- 参与者：谁参加了这次即时评审
- 结论：哪些做法被认可，哪些被否决
- 未决项：还需要谁在什么时候确认
- 后续动作：谁在哪个任务里继续跟进
回写模板
回写模板
即时评审记录
参与者：张三、李四
结论：重试上限改为 3 次，退避策略沿用现有实现
未决：是否需要对第三方超时单独告警，由张三确认
后续：李四在本轮提交中补测试，任务单 #1421 跟踪即时评审与 PR 评审对比
| 维度 | 即时评审 | PR 评审 |
|---|---|---|
| 反馈速度 | 秒级到分钟级 | 通常以小时计 |
| 记录留存 | 默认没有，需要手动回写 | 平台自动留存 |
| 覆盖范围 | 参与者在场才能获知 | 团队成员都能看到 |
| 适用场景 | 紧急、复杂、教学 | 常规改动，需要留痕 |
结对不能替代 PR 流程：书面记录保障后来人与审计可追溯，两者是互补关系而不是二选一。