很多团队把“评审”等同于看代码，但真正的高杠杆其实在更前面——技术方案评审（design review）。代码评审救的是“实现对不对”，方案评审救的是“方向对不对”：方向一旦选错，代码写得越漂亮，返工越惨烈。本文给一套可落地的 技术方案评审 玩法：设计文档怎么写、评审怎么开、把关清单有哪些，配合 代码评审文化：高效 CR 落地实战指南、技术复盘实战：用 Postmortem 把故障变成团队资产 形成“方案→代码→复盘”三道闸。
一、为什么方案评审总被低估
一个典型悲剧：需求评审时大家都说“没问题”，开发到一半才发现方案根本撑不住流量，或者和另一个团队撞车。等到代码评审阶段，架构已经焊死，只能打补丁。方案评审的价值，就是用文档把“隐含假设”逼到台面上——谁来做、依赖谁、边界在哪、失败怎么回滚，提前对齐一小时，往往省下后期一周返工。这也是 技术骨干到 Tech Lead：工程师晋升实战指南 里 Tech Lead 最核心的职责之一：在写代码之前先把方向锁住。
更隐蔽的坑是“伪对齐”：会上没人反对，不等于真同意，只是没人有动力当场拆台。设计文档的最大作用，是让反对意见有处可写——白纸黑字列出来，要么被证伪，要么被采纳，而不是在项目中期以“当时我就觉得不对”的形式爆发。把分歧前置，比事后追责有用一百倍。
二、先写设计文档，再谈评审
没有文档的“口头方案”最容易在评审里跑偏。一份轻量设计稿不必像论文，关键是覆盖背景、非目标、方案选型、风险与回滚。下面是个够用的模板：
# 设计文档模板（轻量 RFC）
## 1. 背景与目标
- 要解决什么问题？不解决会怎样？
- 成功标准（可量化的指标）
## 2. 非目标（Not Goals）
- 明确本次不做的事，防范围蔓延
## 3. 方案选型
- 候选 A / B / C 的权衡，附决策矩阵（见《技术选型实战》）
- 为什么选 A 而不选 B（链接到 ADR）
## 4. 设计细节
- 数据模型 / 接口契约 / 关键流程图
## 5. 风险与回滚
- 最坏情况、监控指标、一键回滚方案
## 6. 里程碑
- 分期交付与评审节点注意“非目标（Not Goals）”这一节——它比目标更难写，却能精准防范围蔓延。方案选型部分直接套用 技术选型实战：用决策矩阵避免拍脑袋 的决策矩阵，把“为什么选 A 不选 B”写清楚，评审时就不会陷入感觉之争。
三、评审会的正确开法
方案评审最容易变成“全员 brainstorm”，三小时过去没结论。高效做法是：异步评审为主、会议只解决争议。作者提前发出文档，2–3 名 reviewer 各自批注；会议只讨论批注里的分歧点，由决策人拍板。这里要和 代码评审文化：高效 CR 落地实战指南 区分开：代码评审盯“实现细节”，方案评审盯“方向与权衡”，两者标准不同、不可互相替代。
reviewer 的挑选也有讲究：不能全是“无利害关系”的人，也不能全是“利益强相关”的人。理想组合是 1 名领域专家（能挑技术硬伤）+ 1 名隔壁系统 owner（能发现跨团队耦合）+ 1 名新人（敢问傻问题，往往戳中假设漏洞）。一个对业务一知半解的新人问出的“这里为什么不能更简单”，经常让整页设计推倒重来。
四、把关清单：六维不漏项
评审时人容易凭感觉，最好有一张固定清单逐条过。下面六个维度基本能兜住绝大多数坑：
| 维度 | 关键检查点 |
|---|---|
| 一致性与边界 | 和现有架构/接口是否冲突？非目标是否被守住？ |
| 可观测性 | 关键路径有没有埋点、日志、告警？出问题能否 5 分钟定位？ |
| 回滚与降级 | 能否一键回滚？最坏情况下的降级方案是什么？ |
| 安全 | 鉴权、越权、注入、敏感数据是否覆盖？ |
| 性能预算 | 预估 QPS/RT/容量，是否超出单实例上限？ |
| 成本 | 新增的依赖、存储、算力，长期账单能否承受？ |
清单的意义不是限制创新，而是把“容易忘的事”变成“必过的关”。每次评审照单打钩，漏掉的概率骤降。
五、留下决策记录 ADR
方案定下来不等于结束。半年后新人会问“当初为啥不用 B 方案”，如果没人记得，就可能被悄悄推翻重来。用 ADR（Architecture Decision Record）把决策固化：
# ADR-007 为什么用消息队列解耦订单与积分
## 状态：已采纳
## 背景
订单完成后需同步通知积分、物流、风控，直连调用导致订单接口 RT 高、耦合重。
## 决策
引入 Kafka，订单服务仅发事件，其余消费者各自订阅。
## 备选
- 仍用同步 HTTP：被否决，RT 与可用性拖累主链路。
- 用定时轮询：被否决，时效性差、空转浪费。
## 影响
主链路 RT 下降 60%；代价是引入中间件运维与最终一致性处理。ADR 是给未来的自己和小伙伴看的。它和 技术复盘实战：用 Postmortem 把故障变成团队资产 的复盘一脉相承——一个记录“当初怎么决定的”，一个记录“后来怎么翻车的”，合起来就是团队最值钱的知识资产。
六、三道闸：方案评审 → 代码评审 → 复盘
把评审拆成三个阶段，各管一段：方案评审管方向，代码评审管实现，复盘管改进。三者串起来，质量不是靠某个人神勇，而是靠流程兜底。而 技术分享怎么做才有效：工程师知识沉淀指南 的分享，则是把评审中沉淀的取舍与教训对外输出，让一次评审的价值放大到整个社区。
小结
技术方案评审 不是形式主义，而是把风险前移的最便宜手段。记住三件事：先有设计文档再评审（别空口说方案）、评审会只解决分歧（异步先行）、用六维清单和 ADR 把决策固化。把它和代码评审、复盘串成“三道闸”，团队的返工率会肉眼可见地降下来。
