"评审会开完没人改"是评审机制最典型的失败形态。它通常被归因为"大家不重视"，但真实原因几乎总是机制缺口：没有触发条件，于是什么都评、每周都在开会；没有必答项，于是讨论滑向个人偏好；没有收尾规则，于是"基本同意"变成谁也不用动的结论。
评审的价值不在当场说服谁，而在于把不可逆的决定在还便宜的时候定下来，并留下能被半年后的自己读懂的判断依据。
1. 该拦的三类风险，不该拦的所有东西
评审会失控的第一步是范围失控。判断某议题是否值得进评审，只看它是否命中三类风险之一。
| 类别 | 具体形态 | 为什么必须拦 |
|---|---|---|
| 不可逆决策 | 数据模型、存储选型、对外契约、部署形态 | 事后改造代价按季度计 |
| 跨团队边界 | 服务拆分、职责归属、共享库、同步调用方向 | 影响别人的排期与故障面 |
| 容量与成本 | 峰值容量假设、扩容路径、第三方按量计费 | 上线后才发现的账单无法回收 |
不该拦的同样要明确：实现细节（类怎么拆、用什么设计模式）、个人偏好（命名风格、日志格式细节）、可随时回退的局部改动（加个索引、调个超时）。把这些放进评审，评审就会变慢，然后被绕过——被绕过的评审比没有评审更糟，因为它制造了"已评审"的错觉。
2. 触发条件：把"要不要评"变成查表
| 触发项 | 判据 | 例外 |
|---|---|---|
| 新系统 / 新服务 | 引入新的运行时、存储或对外入口 | 一次性脚本、内部工具不算 |
| 跨服务改动 | 改动后调用方需同步变更 | 纯增量且调用方无感 |
| 数据模型变更 | 表结构、字段语义、留存周期变化 | 加可选字段且无回填 |
| 第三方引入 | 新增外部依赖、数据出境、SLA 依赖 | 仅开发期依赖 |
| 容量级变化 | 预期 QPS 或存储量跨数量级 | 线性增长内的常规扩容 |
触发条件写死成表，好处是可被审计：任何一次线上事故，事后能回答"当时该不该评、评了没有"。"什么都评"是形式化的起点——当评审变成每周固定议程，参与者会用最低成本通过它，评审就退化成签字。
3. 材料的四个必答项
材料不合格，评审必然发散。四项必答缺一项就不排会。
| 必答项 | 写清什么 | 缺失后果 |
|---|---|---|
| 问题 | 现状的哪个具体约束不满足（带量级） | 讨论变成"要不要做"而不是"怎么做" |
| 选项 | 至少两个真实可选方案，含"不做" | 变成单向汇报，评审无从判断 |
| 取舍 | 每个选项放弃了什么，用 A 换 B | 只剩优点罗列，隐性代价后置爆发 |
| 验证方式 | 上线后用什么指标判断决策是否成立 | 无法事后回看，同类决策重复犯错 |
## 决策请求
问题: 订单查询 P99 在促销期从 300ms 涨到 1.8s，索引已无优化空间
选项: A 分库(改造成本高) / B 读副本+缓存(一致性让步) / C 不做(接受 1.8s)
取舍: B 用"读到滞后数据"换延迟，滞后窗口按秒级估计
验证: 上线后 P99 < 400ms 且不一致投诉 < 阈值；否则回滚到 A 方案评估
"含不做选项"这一条最常被省，但它是评审质量的支点：没有"不做"，就没有真正的比较。
4. 角色分工：谁提供什么，谁拍板
| 角色 | 职责 | 不该做的事 |
|---|---|---|
| 提出者 | 写材料、列选项、给出推荐与理由 | 把评审当审批流程走 |
| 领域专家 | 指出材料中与事实不符的假设 | 用偏好替代判据 |
| 运维/安全视角 | 补齐容量、故障面、依赖与合规约束 | 只在最后提"要注意安全" |
| 决策人 | 定结论、定条件项与责任人 | 让会议以"再讨论"收场 |
只有一个决策人是关键设计。多人共同决策的结果通常是"谁都不用负责"，而评审最需要的产出恰恰是明确的、可追责的取舍。
review:
id: AR-2026-11-09-orders
decision_owner: ROLE_A # 单一拍板人
required: [proposer, domain_expert, ops, security]
quorum: 3 # 缺席不影响结论有效性
async_window_hours: 48 # 异步意见期
5. 异步评审往往比开会更有效
会议的价值是分歧收敛，不是信息传递。把材料阅读放到会前异步完成，会议只处理仍有分歧的点，能同时降低成本与提高质量。
| 环节 | 异步 | 会议 |
|---|---|---|
| 材料阅读 | 48 小时窗口，逐条留意见 | 现场念 PPT，多数人首次看到 |
| 事实澄清 | 文字记录，可回查 | 口头问答，事后无人记得 |
| 分歧识别 | 按意见条数自动汇总 | 取决于谁嗓门大 |
| 结论形成 | 决策人书面定稿 | 现场"基本同意" |
判断标准很实用：如果会议的前 30 分钟在讲背景，这场会就该改成异步。
6. ADR：写什么、放哪里
ADR 不是会议纪要，而是决策的不可变记录。四段结构够用：背景、决策、后果、替代方案。
# ADR-017 订单查询采用读副本 + 缓存
## 背景
促销期 P99 1.8s，分库改造成本按季度计，索引已无空间。
## 决策
读请求走副本，热点键加缓存，接受秒级不一致。
## 后果
- 正面: 延迟目标可达，改造周期两周
- 负面: 用户可能看到滞后状态；需新增不一致投诉监控
- 回滚: 关闭缓存开关即回到旧路径（保留一个发布周期）
## 替代方案
A 分库：彻底但与本次排期冲突，留作下一阶段的候选。
| 存放位置 | 优点 | 风险 |
|---|---|---|
| 代码仓库（与实现同目录） | 与代码同版本，改动可追溯 | 跨仓库决策分散 |
| Wiki / 文档系统 | 集中易检索 | 与代码脱节，容易过期 |
| 工单系统 | 与排期绑定 | 检索差，难以形成序列 |
务实做法：ADR 放代码仓库，索引放 Wiki。ADR 一旦定稿不改正文，后续变更用新 ADR 覆盖并互相链接——这才是"决策有历史"。
7. 结论的三种形态与条件项跟踪
| 结论 | 含义 | 后续动作 | 退出条件 |
|---|---|---|---|
| 通过 | 方案可执行，无条件 | 进入排期 | 无 |
| 有条件通过 | 方向可行，但需补齐若干项 | 条件项进待办，指定责任人与期限 | 条件项全部关闭才允许上线 |
| 打回 | 材料或方案不成立 | 明确缺什么、下次评审前补什么 | 补齐后重新提交 |
"有条件通过"是最容易烂尾的一类：条件项写进了纪要，却没进任何人的待办。对策是把条件项做成带责任人与截止日期的条目，并与上线门禁挂钩。
[AR-2026-11-09-orders] 条件项
C1 补容量测算(峰值按 3 倍) owner=ROLE_B due=2026-11-20 status=open
C2 不一致投诉监控 + 告警阈值 owner=ROLE_C due=2026-11-25 status=open
规则: C1..Cn 未全部 closed 前，发布流水线拒绝该服务的生产部署
8. 意见质量的判定与事后验证
评审意见分三等，只有前两等值得回应。
| 等级 | 形态 | 处理 |
|---|---|---|
| 可执行 | "若读副本延迟超过 X，会与主库语义冲突，需给出兜底" | 必须回应并落到材料或条件项 |
| 需澄清 | "这里的容量假设从哪来" | 补充数据后回到评审 |
| 泛泛而谈 | "建议考虑扩展性""要关注稳定性" | 记录但不阻塞，避免稀释注意力 |
事后验证是评审闭环里最常缺的一环。决策落地后的固定回看（例如上线后一个月）只回答一个问题：当初的验证指标达到了吗？没达到，说明判据错了或假设错了，两者都该写进下一次评审的输入。
# 回看记录与 ADR 互链，一个季度扫一遍未闭合项
ADR-017 verify_at=+30d metric=P99<400ms result=met note=促销期峰值仍需观察
ADR-012 verify_at=+30d metric=不一致投诉<阈值 result=missed → 触发 ADR-017 复核
9. 流于形式的五个信号
| 信号 | 含义 | 纠偏 |
|---|---|---|
| 材料永远在会前十分钟发出 | 评审变成通报 | 设材料截止时间，否则不排会 |
| 每次结论都是"通过" | 门槛失效或议题选错 | 抽查一次被否的案例是否存在 |
| 参与者固定为同一批人 | 领域专家缺位，靠通才判断 | 按议题拉人，非常设委员会 |
| 条件项从不关闭 | 结论没有约束力 | 条件项与发布门禁绑定 |
| 讨论集中在命名与格式 | 议题越界到实现细节 | 用第 1 节的三类风险筛议题 |
10. 排错：评审机制本身的六种故障
| 现象 | 根因 | 处理 |
|---|---|---|
| 会开完没人动 | 结论无责任人、条件项无期限 | 结论必须带 owner 与 due |
| 评审成为排期瓶颈 | 触发条件过宽 | 收窄到三类风险，其余走轻量走查 |
| 意见互相矛盾无人裁决 | 缺单一决策人 | 指定 decision_owner |
| 同一问题反复评审 | 无 ADR，决策不可追溯 | 决策入 ADR，索引化 |
| 材料质量参差 | 无必答项模板 | 四项缺一不排会 |
| 参与者不读材料 | 异步窗口太短或材料太长 | 材料限一页结论 + 附录 |
11. 边界：这些情况不该走评审
| 场景 | 判断 | 做法 |
|---|---|---|
| 小改动（加索引、调超时、改文案） | 可逆且影响面局部 | 走代码评审即可 |
| 单人项目 | 流程成本超过收益 | 保留 ADR 记录，跳过会议 |
| 紧急故障修复 | 时间是第一约束 | 先修，事后 48 小时内补评审 |
| 探索性原型 | 结论未定，评了也白评 | 明确标注 experiment，禁止直接上生产 |
| 已被更高层约束锁死的决策 | 无可选项 | 只做记录与影响说明，不做评审 |
评审的成立前提是存在真实选项。当选项已被预算、合规或组织决定锁死，评审能做的只剩把约束写清楚——硬开一场会，只会生产一份没人再读的纪要。
12. 自测
- 判断一个议题该不该进评审，看哪三类风险？
- 为什么"含不做选项"是评审质量的支点？
- 决策人只有一个，解决了什么问题？
- "有条件通过"为什么最容易烂尾，怎么绑定？
- 什么信号说明评审已经形式化？
- 紧急故障修复为什么走事后评审而不是当场评审？