4.6 决策框架与决策记录

一句话

决策框架解决 “谁来拍、拍多快、拍之前要什么”，决策记录解决 “三个月后还能不能还原当时为什么这么拍”；两者合起来才有用——只讲框架不留记录，同一场争论半年后会原样重开。

先分类型：单向门 vs 双向门

类型	判据	谁拍	拍之前需要	典型例子
双向门（可逆）	撤回成本 < 2 周，且不影响下游契约	执行的人自己拍	一个能说清的理由	换日志库、改内部接口、试用某个 SDK
单向门（不可逆）	撤回要数据迁移 / 跨团队协调 / 改合规口径	指定 owner + 评审	备选、代价、失效条件	选主数据库、定分片键、换云厂商、定计费模型

🔑 用单向门的流程去做双向门决策，是组织里最贵的一种税。 每个小决定都排评审会，团队一个月只能前进两步，而真正的单向门决策反而因为 “会议太多” 被草率通过。

判据只有一条问句：“撤回要多久、要谁配合？” 超过两周或跨三个团队，就是单向门；答案说不清，说明还没想清，按单向门处理（保守方向永远是 “多审一次”）。

这个判据与 4.3 技术选型的评估维度的 “退出成本” 是同一把尺子：换回来要多久、要谁配合、数据能不能导出——三条答不出，就按单向门走。

决策权：D 只能有一个

Bain 的 RAPID 与另一套常见的 DACI，名字不同、结构一样：每类决策必须有且只有一个最终拍板人。

角色（RAPID）	含义	人数上限	常见误用
Recommend	提方案、给备选与数据	1（或 1 个小组）	提方案的人顺手把决定也做了
Agree	有否决权，必须签字	≤ 2	拉 5 个人进来 “一起同意”，等于谁都不负责
Perform	执行落地	按范围定	执行者没参与决策，落地时消极抵抗
Input	提供输入，不参与决定	不限	把 input 当 agree，会开成听证会
Decide	唯一拍板人	恰好 1	写成 “技术委员会”，实际无人拍板

对照（DACI）	Driver	Approver	Contributor	Informed
对应 RAPID	R + P	D + A	Input	Informed

两条纪律比框架名重要：

Agree 有人数上限。 超过 2 个 “必须同意” 的人，决策的期望时长按人数指数上升，且没人真正负责。
“一致同意” 不是决策，是拖延的礼貌说法。 需要一致时，正确写法是 “D 拍板 + A 的否决条件写清”，而不是无限轮会议。

决策速度：拿决策成本换决策错误的成本

类型	目标时长	超时的真实原因	处理
双向门	≤ 1 个工作日	没定谁拍	当场指定 D，散会
单向门	≤ 5 个工作日	备选没做、数据没准备	补一轮材料，按期再议
超过 2 周	—	不是信息不足，是权责不清	升级到有 D 权的人，先定权再定事

“再研究研究” 通常意味着两件事之一：没人有权力拍，或者 拍错没有后果。前者补授权，后者补记录——把决定与结果绑定到人，才会有人认真算。

决策记录：记的是 “当时的信息”，不是 “正确的结论”

字段	为什么必须有	反例（写了等于没写）
决策内容	一句话说清选了什么	“采用微服务架构” —— 哪一层拆？拆几个？
当时的信息	三个月后信息会变，记录必须能还原当时的判断基础	“调研过” —— 调研了什么、数据多少
备选与排除理由	没有备选 = 没有决策，只有接受	“也考虑过 B” —— 为什么没选 B？
代价	决策必有代价，不写就会在半年后变成 “当初没想清楚”	“成本可控”
失效条件	什么情况下这个决策要推翻	空着——这条最常被删，也最该留
owner 与复核日	决定有人认领、有到期日	“团队共同决定”

ADR 的模板、写法与状态机在 58.1 ADR 实践；这里只定三件组织层面的事：记录什么、谁来记、怎么复核。

“代价” 一栏要能算成钱或人月，算法见 4.2 成本-收益分析；写成 “成本可控” 的记录，在半年后等于没有记录。

# decisions/2026-041.yaml —— 决策台账条目，可直接抄
id: D-2026-041
title: 订单库从单库主从迁移到分库分表
type: one-way                     # one-way（单向门）/ two-way（双向门）
status: accepted                  # proposed / accepted / superseded / deprecated
decided_at: 2026-10-20
decider: 交易域 TL                 # D：恰好一个
agree: [数据库 DBA 负责人]          # A：≤ 2，有否决权
recommend: 订单组架构师
info:
  volume: 3 年后 50 亿行，日增 800 万        # 当时的信息：数据化，不写“调研过”
  pain: 单表 > 8 亿行后 DDL 超过 4 小时，发布窗口不够
options:
  - name: 分库分表（16 库 × 64 表）
    rejected_reason: "-"                    # 选中的方案
  - name: 分布式数据库（TiDB）
    rejected_reason: 运维人力不足，P99 未达 200ms 目标
cost: 6 人月 + 3 个月双跑                    # 代价：必须量化
invalid_when:                                # 失效条件：什么情况下推翻
  - 单库在 10 亿行内 P99 仍 ≤ 100ms（说明分片是过早优化）
  - 业务退化为单一租户，分片键失去意义
review_at: 2027-Q1
supersedes: D-2025-017                       # 它推翻了哪一条

台账要能回答一个问题：这条决策还在生效吗

proposed ──► accepted ──► superseded（被新决策取代，链接到新 ID）
                    └───► deprecated（前提消失，不再适用）

superseded 与 deprecated 必须写明理由，否则半年后没人知道 “为什么废了”，历史决策会被反复重新提出。
超过 100 条时按 “失效条件” 分组归档，别按时间堆——检索时人找的是 “这类决定”，不是 “上个月的决定”。

每季度花 30 分钟过一遍台账，只查三件事：失效条件是否已触发、复核日是否已过、有没有该作废的条目。

失效条件一旦触发，就转入止损流程（4.7 技术风险与止损的止损单）；决策记录不负责执行，负责让触发可被发现。

需要多人评审的单向门决策，走 58.3 架构评审，评审结论直接落成一条台账记录；路线图上的每一波迁移也要各有一条决策，见 58.4 演进路线图。

复盘：把 “好决策” 和 “好结果” 分开

一个决策做得好不好，和它结果好不好，是两件事。把两者混同（Annie Duke 称之为 resulting）会得到错误的经验：

情形	结果	正确结论
好决策 + 坏结果	方案合理，只是小概率事件发生	保留决策方法，复盘风险覆盖是否够
坏决策 + 好结果	赌对了	仍然要复盘，否则下次照样赌
好决策 + 好结果	—	别过度总结，可能只是运气好
坏决策 + 坏结果	—	改流程，不是改人

季度复盘的三个数：决策数、被推翻数、推翻时失效条件是否提前写过。第三个数是质量指标——如果被推翻的决策里 80% 没写失效条件，问题不在决策本身，在记录规范。

反模式

反模式	后果
双向门也走评审会	团队一个月只能前进两步，真正的大事反而草率通过
决策没有唯一 D	会议开成听证会，最后 “再议”
Agree 拉进 6 个人	期望时长按人数指数上升，谁都不负责
记录只写结论，不写备选	半年后无法判断是否该推翻，只能重开一轮争论
失效条件空着	决策在前提消失后继续生效，且没人知道该废
“团队共同决定”	出问题无人负责，复盘无人到场
用结果倒推决策质量	赌对了的坏决策被当成经验复制
台账只增不归档	100+ 条按时间堆，检索不到 “这类决定”

三条铁律

🔑 先判可逆性，再定流程：双向门谁做谁拍，单向门才值得排评审。

🔑 每个决策恰好一个 D；Agree 超过 2 人，等于把决策变成协商。

🔑 决策记录必须写失效条件；不写，它就永远 “有效”，直到某天突然不成立。

自检

Q1 团队为了 “日志库换哪个” 连开三次会，还没定。问题出在哪一层？

▸ 答案：出在决策分类与授权，不在信息。换日志库撤回成本约 1–2 天、不影响下游契约，是典型双向门——该由执行者本人 1 个工作日内拍板。连开三次会说明：① 没人被授权拍；② 或者拍了没后果，所以大家宁愿拖。处理动作是先定 D，再定 “拍错怎么办”（写进记录，季度复盘），会立刻结束。

Q2 一份决策记录写着 “经团队充分讨论，决定采用方案 A”。缺了哪三样东西？

▸ 答案：备选与排除理由、代价、失效条件。“充分讨论” 不可复现，等于没写；没有备选，读者无法判断当时是不是只想到一个方案；没有代价，半年后成本超支会被归因为 “当初没想清楚”；没有失效条件，这条决策永远不会被推翻，也就永远不会被复核。

Q3 为什么 “需要所有人同意” 的决策，通常比 “一个 D + 两个 A” 更慢也更差？

▸ 答案：因为同意权分散后，每个人的最优策略是 “不表态” 或 “加条件”，而没有人对结果负责。人数每 +1，需要协调的边按平方增长（3 人 3 条，6 人 15 条）。RAPID 的结构把 “否决权” 限制在 ≤ 2 人，其余人只做 Input——少数人有权，多数人有话说，这个组合才既能拍板又不失信息。

Q4 一个决策当时是对的，半年后被推翻了。这算决策失败吗？

▸ 答案：不算，前提是失效条件当时写过。决策质量取决于 “当时的信息 + 推理”，不取决于后来的结果；如果失效条件写清了、并且被监控到，那么 “按条件推翻” 正是好决策的一部分。真正该复盘的是：失效条件有没有提前写、触发时是第几周发现的——这是记录规范与监控覆盖的问题。

Q5 决策台账和 ADR 是什么关系？两个都要维护吗？

▸ 答案：一份内容，两个视图。ADR 是单条决策的完整正文（背景、备选、后果），主场在 58.1 ADR 实践；台账是全体决策的索引（ID、类型、状态、owner、复核日）。正文写一次，台账抽字段索引即可。两份都写全文，必然出现 “正文改了台账没改” 的不一致。