- 准备：改动清单、设计要点、疑难点，控制在 30 分钟内
- 顺序：先背景与目标，再结构变化，最后过关键代码
- 产出：当场记录的决议与遗留问题，回到 PR 中留档
- 适用：跨团队接口变更、大型重构、架构敏感改动
走查不是通过仪式：口头讲不清的部分，评审者仍须亲自读代码。
| 节奏建议 | 先用几分钟讲目标与背景，再走结构与关键代码 |
|---|---|
| 收尾动作 | 当场结论写入 PR，遗留问题建任务 |
作者走查（walkthrough）
作者向评审者当面讲解改动的走查方式：适合大型或高复杂度改动，先讲背景与设计，再进入代码，常常一次抵数轮评论。
易错点
- 走查变单向宣讲：评审者没时间深入阅读，产生虚假安全感
- 只口头过一遍不留记录：结论散失，后来者重新争论
数据来源与参考
- IEEE 1028（软件评审与审计标准，review 类型定义）