一次关于"是否引入消息队列"的讨论持续了三周。支持方给出了三种收益，反对方给出了两种风险，双方都有数据、都有案例。第四周有人拍板"先不做"，于是争论结束——但没人说清为什么不做，三个月后同样的讨论又开始了。
技术分歧很少因为"证据不足"而僵持，更多是因为没有约定谁有决定权、依据什么判。没有这两条，讨论就会变成"谁更坚持"，而结论无法被记住，因为它没有形成依据。
1. 分歧的三种类型
| 类型 | 本质 | 解法 |
|---|---|---|
| 事实分歧 | 对现状的认知不同 | 查证（数据、实验） |
| 预测分歧 | 对未来演化的判断不同 | 明确假设，约定复查点 |
| 价值分歧 | 对不同代价的权重不同 | 由有权者拍板 |
第一种最容易被误当成第三种：双方在争论"现在到底有多少量"，而这本可以查。分清类型的第一步永远是问"这个分歧能被数据解决吗"。
三种类型的解法还可以写成一张判定表，避免每次讨论都重新摸索：
// 分歧判定表：一次问句决定走哪条路
1. 我们能查到答案吗？ 能 → 事实分歧，查证
2. 我们对"多快会变"的判断一致吗？ 不一致 → 预测分歧，写假设 + 复查点
3. 我们愿意承担同一种代价吗？ 不愿意 → 价值分歧，交有权者拍板
分类型还有个时间价值：先花十分钟判类型，能省掉三周的争执。判类型的问句只有一个："如果我们对现状的认知完全一致，还会不会吵"——会，是价值分歧；不会，是事实或预测分歧，可以查证。
第三种无法用数据解决，因为它涉及优先级（成本 vs 稳定 vs 速度）。这类分歧只能由承担后果的人决定，而不该追求"达成共识"。
2. 事实分歧的查证成本
| 查证方式 | 成本 | 可信度 |
|---|---|---|
| 看现有监控 | 最低 | 中（可能没覆盖） |
| 查日志与库 | 低 | 高 |
| 做一次最小实验 | 中 | 高 |
| 压测或 POC | 高 | 最高 |
查证还有一个纪律：查之前先说清"查到什么就改变结论"。否则查完数据，双方仍各自引用对自己有利的部分——这在事实分歧里比"没查"更糟，因为它消耗了信任。
第二项常被跳过：很多"我们觉得"其实查一下日志就有答案。养成"先查再说"的习惯，能消掉大半分歧。
// 一个典型的"事实分歧"查证：这个接口到底有多少 QPS
awk '{print $4}' access.log | cut -d: -f1 | uniq -c | tail -24
// 一分钟级分布比日均值更能说明"峰值到底多高"
3. 预测分歧的处理：假设显式化
| 步骤 | 做法 |
|---|---|
| 1 写出预测 | "半年后写入量会到 X" |
| 2 写出依据 | 依据是什么（增长曲线、业务计划） |
| 3 写出失效信号 | 什么现象说明预测错了 |
| 4 约定复查点 | 什么时候回来看 |
还有一个成本更低的收敛手段：把分歧压缩成一个可判定的问题。比如"要不要引入消息队列"太宽，压成"当前写入峰值能否在单库上撑过下一个季度"，就变成了可以查、可以复查的问题。
第三项是分歧能被收敛的关键：双方都写出失效信号后，往往发现彼此的分歧没有想象中大——只是对"多快"的判断不同，而复查点会给出答案。
// 分歧记录：把预测变成可复查的假设
topic: 是否引入消息队列
prediction_A: 半年内写入峰值会超过单库承受能力（当前 3k/s，预计 8k/s）
basis_A: 近三个月周环比 12%
prediction_B: 峰值会稳定在 4k/s 以内
basis_B: 主要客户已签约完毕，增长主要来自存量
invalidate_A: 若连续四周峰值 < 4k/s，则 A 的预测偏悲观
invalidate_B: 若单周峰值 > 5k/s，则 B 的预测偏乐观
review_at: 2027-02
4. 价值分歧：谁拍板
| 角色 | 应回答的问题 |
|---|---|
| 技术负责人 | 这个方案的长期维护代价是什么 |
| 业务负责人 | 这个代价换来的是什么、值不值 |
| 运维/值班 | 故障时我们能不能兜住 |
第二项的判断不能由技术代劳："值不值"是权衡业务收益与工程代价，技术只能提供代价的估计。所以价值分歧的仲裁者应当是承担业务后果的人。
// 拍板的三要素：谁、依据什么、什么时候可以改
决定：暂不引入消息队列
拍板人：业务负责人 A（承担峰值风险的后果）
依据：预测分歧未收敛（见分歧记录），且当前余量可支撑一个季度
复查：2027-02，按 A/B 的失效信号判
5. 让结论能被记住
| 做法 | 效果 |
|---|---|
| 写决策记录（ADR） | 后来人能读到"为什么" |
| 记录被否决的方案与理由 | 避免重复讨论 |
| 记录复查时间 | 结论有到期 |
| 记录适用前提 | 前提变了要重议 |
决策记录还有一个常被漏掉的字段："什么时候该重议"。没有这一栏，记录会变成"永久结论"，而技术前提是会变的——结论过期之后仍被引用，比没有记录更危险。
ADR 的格式不必复杂，五栏就够：
// 决策记录：五栏，写完就能被后来人读懂
标题：暂不引入消息队列（2026-11）
背景：写入峰值 3k/s，周环比 12%
决定：不使用消息队列，改为同步写 + 异步补偿
被否决：消息队列（理由：预测分歧未收敛，且当前余量可支撑一个季度）
重议条件：峰值连续两周 > 5k/s，或出现写入导致的超时事故
第二种最有价值：三个月后重开的讨论，90% 是因为没人记得上次为什么否决。把否决理由写清楚，重复讨论的概率会大幅下降。
6. 排错：五种"讨论了三周没结论"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 反复回到同一点 | 事实分歧没查证 | 先查数据 |
| 各说各的案例 | 场景差异未对齐 | 追问量级与前提 |
| 越讨论人越多 | 无决策边界 | 明确谁是决策人 |
| 结论无人执行 | 无责任人 | 指定执行人与时间 |
| 三个月后重提 | 未记录否决理由 | 写 ADR |
排错时可以先做一件很简单的事：问"如果现在必须决定，谁签字"。如果没人能答，讨论再久也不会有结论——先解决"谁"，再解决"什么"。
还有一种隐性僵持值得识别：双方其实都同意"现在不做"，只是在争"谁的观点对"。这类僵持只要把"谁对"和"做什么"分开，就能立刻结束——决定可以一致，归因可以留待复查。
第三项很实际：会议人数增长往往意味着没有决策者，因为如果有，讨论早就收敛了。
7. 边界：什么情况不必正式仲裁
| 场景 | 为什么 | 做法 |
|---|---|---|
| 可逆且影响小的决定 | 错了改回来即可 | 直接做 |
| 已有明确规范 | 无需判断 | 照规范 |
| 时间极紧的故障处置 | 先处置 | 事后补记录 |
| 纯个人范围 | 无跨方影响 | 自己定 |
最后一条与开会方式有关：分歧超过两轮就应当换形式。继续在会上争，成本是所有人的时间；改成"各自写一页纸 + 一个人判"，成本是两小时。写下来的过程本身就会暴露"其实没有依据"。
最后一条与人的因素有关：分歧里最贵的不是时间，是关系。把"我觉得你错了"换成"我们的前提不同"，能让讨论从立场之争回到事实与假设——而这两者是可以被查证和复查的。
判断口径一句话：这个决定错了，要多久能改回来。改回来便宜，就不必仲裁；改回来昂贵，就必须有明确的决策人与依据。
8. 自测
- 分歧的三种类型分别对应什么解法？为什么"事实分歧被误当成价值分歧"很常见？
- 预测分歧能被收敛的关键步骤是什么？为什么双方写出失效信号后分歧常常变小？
- 价值分歧为什么不能由技术团队拍板？三个角色各自应回答什么？
- 决策记录里最有价值的是哪一项？它避免了什么重复成本？
- 为什么"会议人数增长"往往意味着没有决策者？
- 判断"是否必须正式仲裁"的那个问题是什么？