你文档里如果只有一个方案，那不是评审材料，是汇报材料。这句话听起来像抬杠，但对照公开模板的标准，这是字面意思。

这里主要指软件团队的方案/架构 design review，不含纯 compliance gate。

差别不在会议室大小，不在 PPT 精不精美，甚至不在来的是不是架构师。差别在文档里有没有至少两个被你认真否决过的备选方案。有，才谈得上「评审」；没有，只是把已定结论念给听众听。常见默认流程里，汇报会很容易被误当成决策会，问题出在形态。

浪费时间的是汇报形态

先划一条边界，免得把机制和开法混为一谈。

好的架构评审能拦住系统性风险，比如服务耦合、扩展性天花板、运维盲区。这些东西代码 review 抓不到。Boehm 在 1981 年的大型项目数据里已经说明：缺陷发现得越晚，修复成本越高，成本随发现阶段显著上升（区间见 §五）。

关键在弄清你们开的那场在干什么。

还有一个隐蔽信号：会后有没有 ADR 或 decision log 入库？

汇报会结束后，产物是会议纪要里的一句「同意方案 A」。决策会结束后，常见产物之一是带 Options Considered 段的 ADR 或 decision log——merge 进 repo 后，六个月后新人还能读到「为什么没选 B」。决策记录（ADR/decision log）与同步评审会是两种载体：前者可以 async，后者只在分歧收敛不掉时才占日历。

多数公开 playbook 建议把 design review artifacts 放进 development repo，走 PR review。异步通道同样要求多方案 trade study，只是不用占同步日历。

常见形态的「方案评审」往往长这样：主讲人打开三十页 Slide，从背景讲到架构图，讲到一半有人提问，主讲人解释「我们评估过了，这个方案最合适」。会议结束，纪要写「与会各方无异议，同意按方案 A 推进」。

把 Slide 换成 Markdown、会议室换成腾讯会议，本质不变：全程只有一个选项在被展示。参会者处于听众角色，缺少 trade-off 抓手——没有 B、C 可比，trade-off 和风险对冲都无从谈起，因为主讲人已在会前替所有人完成了「选择」。

Stoa 的架构评审模板里有一句很直白的话：“We’re doing Z” is an assumption. “We considered X and Y but chose Z” is a decision.（「我们要做 Z」是假设；「我们考虑过 X 和 Y，最后选了 Z」才是决策。）国内团队很少把这句话贴在会议室门口，但道理通用：单方案文档在语义上就是汇报，不具备决策请求的资格。

汇报会浪费时间，是因为它很少产生会前没有的新决策信息。信息在会前已被主讲人消化完毕，会议只是广播。

决策会也可能浪费时间，人太多、预读不足、议题过大，但至少设计目标是对的：在多个可行路径里选一条，并记录为什么。

还有第三种形态值得单独点名：架构审批 gate。评审委员会只问「符不符合规范」「有没有安全风险」，不问「为什么选 Z 而不是 Y」。标准合规评审仍可有价值，但别把它叫 design decision review。它是 compliance check，不是 design decision。把 compliance 会和 design 决策混在一个 hour 里，两种目的都达不成，前者需要 checklist，后者需要 alternatives。

有效架构对话的常见起点是先列出 alternatives，再去找会 disagree 的人征求意见。注意顺序：先有 alternatives，再 seek advice。先排期开会、会上才第一次听说「原来还有方案 B」，并不少见。

判别器：三个要素

要把汇报会和决策会分开，不需要搞一套复杂流程。一个判别器就够：文档里有没有备选方案。

但「有」字容易糊弄。有人会在附录里加两行「方案 B：不用，原因：性能差」，稻草人替代方案，不算。有效判别要看三个要素，缺任何一个，会议都会滑向汇报。问题空间尚未收敛时，应先做 time-boxed spike 或 RFC 0，产物是 spike 结论，不是假 Options——那不算 decision review，也不该占同步日历。

要素 1：至少两个认真考虑的备选

「认真考虑」的意思是：每个备选都有足够的细节，让评审者能独立判断它的优劣，须能独立评估而非充当陪衬。

英文公开工程指南里，至少两个备选是默认门槛：Stoa 与 Ankul 等均要求会前 circulated 且 at least 2 alternatives / options considered（Stoa 示例为 48h）。各团队模板用词略有差异，门槛一致。

你拿自己的评审文档对照一下：除了主推方案，能不能找到第二个「如果主推方案不存在，团队可能真的会选它」的选项？找不到，就是汇报材料。

怎么识别稻草人备选？看三个信号：备选只有两行而主推有二十页；备选的「否决理由」是「性能差/太复杂」但没有数据；备选从未在团队内被任何人认真 champion 过。Stoa 模板原话：Alternatives don’t need to be fully fleshed out, but they need to be seriously considered — not strawmen set up to fail. 稻草人备选的典型写法是「方案 B：微服务重构（不采用，工作量大）」，工作量多大、跟谁比，不知道，因为 B 从来不是为了被选中而写的。

单方案文档里，评审者没有 disagree 的抓手，只能问细节问题，细节问完，还是只能点头。

要素 2：显式的 tradeoff 和优化目标

「方案 A 更简单，方案 B 更快」，这种话没有信息量，除非你先声明你在优化什么。

Stoa 要求文档顶部写 optimization target：性能、交付速度、运维复杂度、成本，四选一或排优先级；多方案并存时，公开 playbook 通常要求 trade study 作为标准产出。没有优化目标，tradeoff 讨论会变成各说各话：有人谈扩展性，有人谈招人难度，有人谈「上次那个项目也是这么干的」，讨论很热闹，决策没发生。

Stoa 模板里的 tradeoff 表是一个好范例：行是 Option A/B/C，列是 implementation time、operational complexity、scale ceiling、local dev/test。每一格填具体判断，不是形容词堆砌。填完这张表，Recommendation 段写「我提议 A，因为当前优化目标是 developer velocity at current scale」，读者能追溯逻辑链。跳过这张表直接写「推荐 A」，和写「我们要做 A」一样，都是 assumption。没有 criteria，review 容易退化成 subjective vibes check。

要素 3：会议必须产出明确决策

决策会结尾是三态之一：批准、带条件批准、打回修订（英文模板常见 Approved / Approved with conditions / Needs revision，语义等价）。Ankul 流程写得很硬：No design review ends with “let’s discuss more” without a concrete next step. 打回修订必须写清 gap 和 next review 日期；带条件批准时，条件必须书面化、有 deadline，否则等于没批。

把三个要素合成一张自检表：

三要素齐全 = 决策会；缺任何一个 = 汇报会。这是全文的核心判别器，后面不再换框架。

对照实验：公开模板怎么说

上面是逻辑推演。下面是我做的一个可复现小实验，不编造任何「上周三我们开会」的故事，只查公开模板。

方法

2026-08-27，我逐份阅读 6 份可公开访问的英文工程实践指南/模板，核查是否明确要求：文档中列出多个方案（alternatives / options / trade studies），以及是否要求 tradeoff 和 明确决策 outcome。完整对照表含来源链接与逐条判定，见 附录。

本实验验证的是公开 ADR 指南的模板语义，不是国内团队实际落地率。

结果

在本文抽样的 6 份 ADR/设计评审指南中，6/6 在有多方案/决策场景时要求 alternatives 或 trade study（Microsoft 为条件性表述：when multiple solutions exist）；5/6 要求显式 tradeoff 和明确退出决策（Fowler 偏 async advice，要求比较备选，未强制显式 tradeoff 表）。没有任何一份模板写「单方案可以直接上会」。

*Microsoft：多方案存在时要求 trade study。

公开指南的共同要求

这些模板指向同一件事：评审的输入物须是一份决策请求，带着 Options 与 tradeoff 等待裁决。

国内很多团队的评审模板还在检查「有没有架构图、有没有容量评估、有没有排期」，清单很长，但很少写「Alternatives Considered：必填」。清单缺这一栏，会议就天然滑向汇报：主讲人只要把清单上的框填满，就能过会。

你可以用自检表对照最近一次评审：打开你们团队的方案评审模板，搜「备选」「alternative」「方案对比」，如果搜不到，你的流程在系统性地生产汇报会。

与国内「评审 checklist」的错位

很多国内模板长这样：架构图 ✅、容量评估 ✅、监控方案 ✅、回滚方案 ✅、排期 ✅，每一项都有，唯独没有「Alternatives Considered」。主讲人把 checklist 填满就能过会，因为 checklist 量的是文档完整度，决策就绪看有没有 Options。完整度和就绪度是两回事：三十页单方案文档可以非常完整，但仍然不具备被评审的条件。

对照实验的局限也要说清楚：样本是 6 份英文公开指南，不代表国内团队实际执行的模板。但公开指南反映的是「被认为正确的默认形态」——当默认形态 6/6 要求 alternatives，而你的模板连字段都没有，在英文指南层已可见结构性缺口；国内落地形态仍待验证。

对照记录见 附录，读者可按同样标准扫描自己的模板库。国内样本待验证；若你有反例模板，欢迎对照后留言。在那之前，6/6 是我能拿出来的可复现的对照结果。

顺带一提：Fowler 的 conversational architecture 并不要求每次决策都开同步会。很多 effective team 把「列 alternatives + seek advice」放在 async ADR comment 里，同步会只处理 async 无法收敛的分歧。alternatives 是决策的前置条件，与是否开会无关；有没有会，文档里都应该有备选；有会但没备选，会白开。

把汇报会改成决策会

以下针对已决定开 sync review 的一扇门场景。诊断和判别器讲完了，处方部分刻意写短，本文不是 another best practice 清单。只给三个可立即执行的改动，每条都是我裁过、只留最小可执行单元的。

改动 1：无 ADR 草稿，拒绝排期

Ankul 团队的 guardrail 第一条：No meeting without ADR draft. 没有书面文档，就不占会议室。文档最低结构四块：Context、Options（≥2）、Tradeoffs、Recommendation——Recommendation 写「我建议选 Z」，决策 outcome 另段记录。我保留这条，因为会前 digest options、会上只处理 async 没收敛的分歧，比模板名字重要。

最小 ADR 骨架可以直接抄：

## Context
我们在解决什么问题？约束是什么？

## Options
- Option A：…（足够细节，能独立评估）
- Option B：…
- Option C（可选）：…

## Tradeoffs
优化目标：{velocity / cost / reliability / …}
|  | A | B |
|--|---|---|
| 实现周期 | … | … |
| 运维负担 | … | … |

## Recommendation
我提议 A，因为 …

会前 48h 发出去，Reviewer 用 async comment 提问题。会上只处理 async 没收敛的分歧。

改动 2：预读 48 小时，会上不念 Slide

Stoa 和 CodeIntelligently 共识：The meeting is NOT a presentation. 所有人会前读完文档，会上只讨论分歧和 tradeoff。会上念 Slide 的人，默认在开汇报会，facilitator 有权打断：「这段我们读过了，直接说你对 Option B 的顾虑。」我裁掉了「预读清单逐条」，只留「不念 Slide」这一条 habit，因为预读失败时 cancel meeting 比清单长度更关键。

改动 3：30–45 分钟，必须带出 outcome

Tech Architect Insights 的 30 分钟决策 ritual 把时间盒死在决策上：0–5 分钟对齐问题，5–15 分钟过选项（viable options 通常 ≤3，TAI），15–35 分钟辩论，最后 10 分钟必须 call 决策。超时没结论？文档信息不足，回去补备选，两周后再审。我保留时间盒，因为「call 决策」是三要素 3 的同步版落地。

三改动落地成本不高：改模板、改 habit、指定 facilitator。facilitator 的职责是守流程的人，有人念 Slide 就打断，会议超时没 outcome 就判定 Needs revision，Reviewer 没预读就 cancel meeting（Ankul 的 guardrail #3 对此写得很硬）。现实阻力在于：第一次 cancel meeting 容易被骂，建议从 pilot team 起步，需 Tech Lead 背书。

成本高的是承认过去很多会白开了，那恰恰说明值得改。

谁该参与：不是人越多越好

CodeIntelligently 把 Architecture by committee 列为 anti-pattern，通常不超过少数预读过的 reviewer（CodeIntelligently 警示 committee 反模式）。Fowler 的建议是找会 disagree 的人，不是找能点头的人。单方案汇报会的变体是「拉所有 stakeholder 来听」，听众越多，主讲人越像在做汇报；决策会应该小范围、预读过、带着具体顾虑来。

边界：评审什么时候仍然值得

把话说死容易，把边界说清更难。

两扇门：可逆 vs 不可逆

Ivaaya 的 governance 文章区分 two-way door 和 one-way door：可逆决策走 advice process，找受影响的人和专家征求意见即可；不可逆、跨团队边界的决策，才值得同步 review meeting。

Bezos 的两扇门隐喻在工程里翻译成人话：换缓存组件、调线程池大小，两扇门，错了能改；选 data residency、定 public API 契约，一扇门，错了要迁移。一扇门才值得同步 review；两扇门用 advice process + ADR 异步记录就够了。判别器仍然有效：不管一门还是两扇门，只要开同步 review，文档里就要有备选。门的大小决定「要不要开会」，不决定「开会时是不是汇报会」。

InfoQ 介绍的 Architecture Advice Process 进一步说：在职责边界内，任何人可以做决策，但必须 seek advice from affected parties and experts，注意是 advice，不是 permission。这降低了「等架构师拍板」的 bottleneck，但前提是决策请求里得写清 options，否则 advice 无从谈起。

合规场景例外

金融、医疗、安全合规域的 formal gate 不在本文射程内。那些场景要的是 audit trail，模板可以更重，但 alternatives 记录 在合规审计里同样有价值：「为什么没选 B」是审计员常问的问题。合规 gate 仍可在 audit trail 里要求 alternatives considered；本文批评的是 design decision 伪装成 review，与 SOC2 签字不是一回事。

备选可以写在 ADR Options 里引用 spike 结论，但不能省略 Options 段。

若目标是同步认知而非选方案，诚实叫 design walkthrough。

对「评审防技术债」的回应

辩护评审价值的人常引用「设计阶段修复更便宜」。方向对，但便宜的前提是你在设计阶段真的做了决策，比较了路径、记录了 tradeoff、留下了 ADR。即便评审有价值，汇报式单方案会既不捕获事故也不留下 decision record。单方案汇报会不产生这些产物，它省下的只是主讲人的准备时间，不是团队的长期成本。

IBM 培训讲义里流传的 1:10:100 倍数常被口播简化，Bossavit 等研究者指出原始数据不可复现，正文不宜引用精确倍数。Boehm 1981 的区间更稳妥：设计阶段发现缺陷 vs 运维阶段，大致是 3x–8x 到 50x–200x 的量级差，因项目类型而异。拿这个为评审价值辩护时，限定语必须是：只有决策会才能在设计阶段产出可执行的 trade-off 记录；汇报会只是在设计阶段开了一次会，不等于在设计阶段做了决策。

结尾：你的评审是哪种

拿最近一次方案评审对照：

三行全 ✅：决策会，值得开。
任意一行 ❌：汇报会，你可以继续开，但别叫它评审，也别怪别人走神。

常见借口与回应

「我们时间紧，来不及写备选。」时间紧更不该开同步会。写两个备选的 ADR 通常远少于一场多人同步会的人时总和，且后者常不留 decision record。时间紧时应该缩 scope 或走 advice process，不是缩 alternatives。

方案 obvious、只有一个正确答案？Fowler 的流程要求 explicitly ask “what’s bad about this alternative?"，单方案思维跳过了这一步。真 obvious 的话，写两行 Option B 否决理由成本很低，远少于会前准备 Slide 的时间，却能证明你想过。

有人把评审理解成走流程拿签字。那就诚实地叫它 sign-off meeting，别占用「评审」这个词。词义误导会吸引错的人、用错的期待：有人带着 critique 来，发现只能点头，下次就不来了。

没有备选方案的评审，就是汇报会。公开工程模板对照后的结论，也是你可以用自检表验证的判断。

原文发布于 止语Lab