2.架构演进决策能力
# 2.架构演进决策能力
# 目录介绍
- 1. 案例引入
- 2. 演进决策全景图
- 3. 渐进演进四原则
- 4. 可逆与不可逆
- 5. Trade-off 量化
- 6. 敢不做也是决策
- 7. 演进节奏拆分
- 7.4 演进决策反模式
- 9. 决策沟通策略
- 10. 综合案例串讲
# 1. 案例引入
# 1.1 老板顺便重构
糖果充的支付方案通过了，团队 3 人 3 个月，正式启动。第二周周会上，老板 A 总突然发话：
A 总: "小杨, 我看你这次支付重构做得不错。既然都要动订单系统了，咱们顺便把订单、库存、履约也一起微服务化吧？"
糖果充: (心里咯噔) "呃, 这个......"
A 总: "反正都要改, 一次改到位, 别一年后又来一遍。你想想，Netflix、蚂蚁不都是这么干的？"
糖果充: "但我们方案里只承诺了支付重构 3 个月......"
A 总: "方案可以调嘛。你回去评估一下, 一次性做到位需要多久？ 顺便把技术债都还了。"
糖果充: (被架起来) "好, 我评估一下。"
回到工位，糖果充越想越不对劲：
支付重构 3 个月 (方案已过, 团队已备)
订单拆分 保守估计 4 个月 (200 张表要拆)
库存拆分 3 个月 (要处理分布式事务)
履约拆分 2 个月 (跟外部物流对接)
如果串行: 12 个月, 团队规模需要翻倍
如果并行: 6 个月, 但依赖交织, 上线风险爆炸
一周后糖果充硬着头皮做出评估："顺便"意味着 6-12 个月，风险不可控。他把评估发给 A 总，A 总回一句："别怕难，去做"。
糖果充慌了：做，明知道会翻车；不做，会不会显得没担当？
# 1.2 顺藤摸到根因
带着这条线往下挖：
- 假设 1：A 总的想法有没有道理？有一定道理，技术债确实存在
- 假设 2：那就该"顺便"做吗？不是，因为风险 × 成本 ≠ 收益
- 假设 3：为什么老板会有这种诉求？因为架构决策的成本不由老板扛
- 假设 4：那糖果充应该怎么办？不是"扛住老板"，而是帮老板算清楚账
- 假设 5：算账的语言是什么？决策的量化框架
- 假设 6：如果算完 A 总还是要做呢？那也不是糖果充单挑，而是让 A 总承担明确风险
- 假设 7：这些语言、框架、姿势是什么？本篇的主线
仔细分析这次危机的根因：
表象 真实问题
────────────────────────────────────────────────────
"既然要改, 顺便……" → 顺便主义, 不区分决策独立性
"一次改到位" → 大爆炸, 不区分可逆/不可逆
"别一年后又来一遍" → 恐惧驱动, 不算成本折现
"我评估一下" → 糖果充没有决策语言
"别怕难, 去做" → 没有让上级承担明确风险
根因：糖果充没有"架构演进的决策语言"，他只会说"能做/不能做"，不会说"这么做代价是什么、比另一种代价高多少、谁来承担、可不可回滚"。
这一段里至少藏着 8 个原理点：
① 什么是"演进"？为什么不是"重构"？ → 第 2 章
② 渐进和一次到位, 到底哪个更好？怎么选？ → 第 3 章
③ 决策的可逆性怎么判断？为什么可逆比不可逆便宜 10 倍？ → 第 4 章
④ "顺便一起做"到底伤在哪？ → 第 4 章
⑤ Trade-off 怎么量化才能跟老板对话？ → 第 5 章
⑥ 什么情况下"不做"才是最优决策？ → 第 6 章
⑦ 演进的节奏怎么拆才不翻车？ → 第 7 章
⑧ 面对老板压力怎么"体面地说不"？ → 第 9 章
# 1.3 我们要回答什么
这个事故就是本篇的主线案例。带着上面 8 个问号往下走。本篇路线：
决策全景图 (第 2 章)
↓
渐进演进四原则 (第 3 章) ─→ 解开"为什么小步好过大爆炸"
↓
可逆与不可逆 (第 4 章) ─→ 解开"哪些决策慎之又慎"
↓
Trade-off 量化 (第 5 章) ─→ 解开"跟老板怎么算账"
↓
敢不做也是决策 (第 6 章) ─→ 解开"什么时候拒绝"
↓
演进节奏拆分 (第 7 章) ─→ 解开"必须做怎么做"
↓
反模式 (第 8 章) + 沟通策略 (第 9 章)
↓
综合案例 (第 10 章) ─→ 糖果充顶住 A 总
📌 本篇定位：这是继"方案设计力"之后的决策力升级。方案回答"做什么"，决策回答"要不要做/什么时候做/一次做多少"。能顶住"顺便一起做"的诱惑，是资深工程师的第一个分水岭。
# 2. 演进决策全景图
# 2.1 决策五要素
一次架构演进决策，包含五个要素。缺一个都会出问题：
┌───────────────────────────────────────────────────────────┐
│ 架构演进决策五要素 │
├───────────────────────────────────────────────────────────┤
│ ① 时机 (When) 现在做 / 半年后做 / 不做 │
│ ② 幅度 (How much) 全做 / 一部分做 / 试点做 │
│ ③ 可逆性 (Reversibility) Type1 不可逆 vs Type2 可逆 │
│ ④ 成本收益 (Trade-off) 人力/时间/风险 vs 收益 │
│ ⑤ 责任归属 (Accountability) 谁拍板, 谁承担, 谁复盘 │
└───────────────────────────────────────────────────────────┘
五要素属性速查：
| 要素 | 关键问题 | 输出 | 糖果充 V1 |
|---|---|---|---|
| 时机 | 现在最迫切吗？ | 优先级排序 | 全都现在 ❌ |
| 幅度 | 一次做多大？ | 里程碑拆分 | 全都做 ❌ |
| 可逆性 | 做错能回吗？ | Type 分类 | 没分类 ❌ |
| Trade-off | 值不值？ | 量化对比 | 没算 ❌ |
| 责任 | 谁拍谁扛？ | 决策记录 | 糖果充一人扛 ❌ |
# 2.2 为什么这么切
架构演进不就是"要做就好好做"吗？为什么要拆成五要素？
1.没时机决策就没优先级，所有需求都紧迫 = 没需求紧迫。糖果充的 4 个改造都"应该做"，但按优先级只有支付真正 P0。不排优先级 = 每个都做不完。
2.没幅度决策就是赌，"全做"和"做 20%"的风险不是线性的，是指数的。大爆炸重构翻车概率 = 单个改造翻车概率 ^ 项目数。糖果充 4 个改造，单个翻车 20%，全做翻车 (1-0.8^4)=59%。
3.没可逆性区分就要命，微服务拆分是 Type1 不可逆，一旦拆了几乎回不去。跟"换 Redis 客户端库" (Type2 可逆) 完全不是一个决策级别。Type1 决策要 10 倍谨慎。
4.没量化 Trade-off 就跟老板对不上话，老板说"顺便"是感性，你说"6-12 个月风险不可控"是感性。量化 = 语言 = 决策力。
5.没责任归属就没人认真，糖果充一人扛 = 出问题只有他挨骂 = 老板下次继续"顺便"。责任归属清晰 = 决策成本对上决策收益。
反向验证：没这五要素会怎样？答案就是第 1 章，糖果充被架起来做 4 个改造，一场大爆炸的种子被埋下。
结论：五要素的本质是把"架构演进"从热血冲锋变成冷静工程，时机排优先、幅度控风险、可逆定谨慎度、Trade-off 建共识、责任对齐奖惩。少一环都是赌。
# 3. 渐进演进四原则
# 3.1 小步快跑
为什么小步比大步好？我一次做完不是省事？算一笔账：
方案 A: 一次拆 4 个服务
周期: 6 个月并行
上线: 一次性大发布
发现问题: 6 个月后
回滚代价: 数据已迁, 代码已删, 几乎不可回
单点风险: 一处翻车全盘皆输
方案 B: 半年拆 1 个 (支付先做, 剩下 3 个逐个跟)
周期: 支付 3 个月 + 单个 3 个月 × 3 = 12 个月串行, 但重叠可缩到 9 个月
上线: 每个独立灰度
发现问题: 3 个月内
回滚代价: 单个可控
单点风险: 隔离
表面周期: A 短 3 个月
真实周期: A 有 60% 概率翻车拖到 12 个月, 期望 = 6 × 0.4 + 12 × 0.6 = 9.6 月
B 稳定 9 个月
结论：期望周期 A ≈ B，但 A 有 60% 概率翻车、B 稳定 9 个月。选 B。
小步快跑的量化定义：一步的"合适大小" = 可以在一个 sprint (2 周) 内完成、可以独立上线、出问题可以在 1 天内回滚。
# 3.2 一次改一件
改支付时不能顺手改一下订单接口吗？不能。原因是变量隔离：
一次只改 A: 出问题 → 一定是 A → 排查 10 分钟
一次改 A+B: 出问题 → 可能是 A、B、或 A/B 交互 → 排查 3 小时+
一次改 A+B+C: 出问题 → 排查回天乏术, 只能整体回滚
结论：一次改一件 = 排障成本恒定。多改一件 = 排障成本翻倍。
例外：如果两件事逻辑绑定（如接口签名变了必须同步升级调用方），才是一次改一件"逻辑上的一件"。
# 3.3 保留退路
什么叫保留退路？每一步演进都要有对应的"撤退键"：
演进动作 退路
────────────────────────────────────────────
新增支付通道 (加代码) Feature Flag 关闭
存量数据迁移新表 双写, 保留老表读
接口拆到新服务 网关灰度回切老服务
数据库拆库 保留同步链路 30 天
删除老服务 留 30 天备份 + 部署包
结论：没有退路的决策叫赌博，有退路的决策叫工程。
极端案例：删除老代码，很多人以为"完成收尾"，其实这是最不可逆的动作。老代码删了，40 天后发现新代码有边界 bug，回天乏术。规矩：老代码在新代码全量后再等 30 天再删。
# 3.4 承担明确风险
老板说"你干"，我就干呗，风险是老板扛的吧？不是。风险的默认归属：
默认归属: 技术方案的翻车, 由技术负责人扛
特殊归属: 被上级明确要求"必须做"的翻车, 上级扛
关键动作: 你必须"明确"这个"必须做"
不明确的后果:
糖果充: "我评估一下" (未明确风险)
A 总: "别怕难, 去做"
上线翻车: 糖果充被追责
明确后的后果:
糖果充: "评估如下, 期望翻车概率 60%, 建议不做。如果要做, 请书面确认由技术委员会背书。"
A 总: (要么放弃, 要么书面背书)
上线翻车: A 总或技术委员会扛
结论：承担明确风险 ≠ 甩锅，而是让决策成本对上决策权力。老板要做，就让他明知代价。
# 4. 可逆与不可逆
# 4.1 决策的可逆度
什么叫可逆？我做完了都能改吧？能改 ≠ 能低成本改。看几个例子：
决策 可逆度 改动代价
─────────────────────────────────────────────
换缓存 Key 前缀 极高 5 分钟
换 HTTP 客户端库 高 1 天
换 ORM 框架 中 2 周
拆分微服务 低 3-6 月
换数据库 (MySQL→Postgres) 极低 6-12 月
上市 零 几乎不可
结论：可逆度是梯度，不是二元。决策的谨慎程度应该与可逆度成反比。
# 4.2 Type1 与 Type2
贝索斯的分类（简化版）：
Type1 决策 (不可逆):
- 影响面大、代价高、几乎回不去
- 例: 微服务拆分、更换数据库、组织架构调整
- 处理: 慢决策, 收集尽可能多信息
Type2 决策 (可逆):
- 局部、可撤、回滚便宜
- 例: 接口重命名、加一个字段、改个配置
- 处理: 快决策, 试错成本低
关键洞察：大多数人把 Type2 当 Type1 决策（开一大堆会），把 Type1 当 Type2 决策（拍脑袋就干）。两个错误一样严重。
对照 A 总的诉求：
A 总: "顺便微服务化吧"
性质: 4 个 Type1 决策同时启动
处理: 应该收集 6-12 个月信息, 而不是"顺便"
# 4.3 决策优先级矩阵
四象限图：
可逆度
▲
高 │ 低
┌──────────────┼──────────────┐
│ │ │
高 │ Type2 高频 │ Type1 关键 │
收益│ 快速试错 │ 慎重决策 │
│ (加缓存) │ (拆微服务) │
│ │ │
├──────────────┼──────────────┤
│ │ │
低 │ Type2 低频 │ Type1 无意义 │
收益│ 可做可不做 │ 别碰 │
│ │ │
└──────────────┴──────────────┘
(换 DB 但没痛点)
决策口诀：Type1 高收益慢决策、Type2 高收益快决策、Type1 低收益不做。
回头看 A 总的诉求：4 个改造中，只有支付是"Type1 高收益"，其他 3 个都是"Type1 中收益"，应该慢决策，不该"顺便"。
# 5. Trade-off 量化
# 5.1 三轴决策图
怎么把"值不值"讲给老板听？用三轴决策图，时间、风险、收益：
收益
▲
│
│ ┌─────┐ ★理想区
│ │ 支付 │
│ └─────┘
│
│ ┌──────┐
│ │ 订单 │ 中等区
│ └──────┘
│
│ ┌──────┐
│ │ 履约 │ 不划算区
│ └──────┘
│
└──────────────────────────→
低 时间×风险 高
坐标定义：
X 轴 (时间×风险): 完成所需人月 × 翻车概率
Y 轴 (收益): 3 年内累积业务/技术价值
决策规则：Y/X 比值最高的做，其他等下一个决策窗口。
举例（数字为示意）：
| 项目 | 人月 | 翻车概率 | X = 时间×风险 | 3 年收益 | Y/X |
|---|---|---|---|---|---|
| 支付重构 | 9 | 15% | 10.4 | 500 万 | 48 |
| 订单拆分 | 20 | 40% | 28 | 400 万 | 14 |
| 库存拆分 | 15 | 45% | 21.8 | 300 万 | 14 |
| 履约拆分 | 10 | 50% | 15 | 200 万 | 13 |
结论：支付 Y/X = 48，是订单的 3 倍。四个项目全做 = 稀释支付这个高 ROI 项目。
# 5.2 成本估算法
怎么估人月？PERT 三点估算法：
期望人月 = (O + 4M + P) / 6，标准差 = (P - O)／6
举例（承接上表订单拆分, M=20 人月）: O=12, M=20, P=40 → (12 + 4×20 + 40) / 6 = 22 人月
结论：估算不是精确，是把"我觉得"变成量化直觉。
# 5.3 收益折现法
3 年 500 万收益怎么算？未来的钱不如现在的钱值钱，要折现：
折现率 (r) 一般取 15%-25% (软件行业风险高)
现值 (NPV) = 收益₁/(1+r)^1 + 收益₂/(1+r)^2 + 收益₃/(1+r)^3
举例 (r=20%):
年 1 收益 200 万 → 现值 167 万
年 2 收益 200 万 → 现值 139 万
年 3 收益 100 万 → 现值 58 万
NPV 合计 = 364 万 (而不是 500 万)
结论：长远收益要打折，这就是为什么老板"3 年 500 万"要按 NPV 算 = 别被大数字忽悠。
# 6. 敢不做也是决策
# 6.1 不做的三种情形
什么时候"不做"是最优？三种典型情形：
① 边际收益递减: 已经做了 80%, 剩下 20% 成本占 60%, 收益占 10% → 停
② 决策窗口未到: 信息不足, 现在决策错误概率高 → 等 (但明确"等到什么信号")
③ 机会成本更高: 同样资源投别处收益 3 倍 → 转向
对照 A 总诉求：
订单/库存/履约 拆分:
边际收益递减？ 否
决策窗口未到？ 是, 支付都还没验证
机会成本更高？ 是, 支付 ROI 是它们 3 倍
→ 结论: 不做 (现在)
# 6.2 拒绝的表达法
直接跟老板说"不做"？会不会被认为没担当？拒绝有姿势。错误姿势：
❌ 硬顶: "这不可能, 太难了"
❌ 甩锅: "这是 A 总您的意思, 我做不了主"
❌ 拖延: "我评估一下" (然后无限期评估)
❌ 妥协: "好吧我试试" (然后翻车)
正确姿势 (三段式)：
① 承认价值 "顺便一起做的目标我完全认同"
② 摆出数据 "但按 NPV 折现算, 支付 Y/X 是订单的 3 倍, 全做 = 稀释支付, 期望翻车 60%"
③ 给出选项 "所以有三种路径:
A. 只做支付 (推荐), 支付完再评估
B. 支付 + 订单 (次推荐), 但周期延长 3 月
C. 全做, 需要团队翻倍 + 明确风险背书
请您选择"
关键：给出选项而不是给出拒绝。老板要的是决策权，你要的是决策依据。
# 6.3 让子弹飞一会
如果老板还是要"顺便"呢？技术决策不是最后一刻拍板，争取一个决策窗口：
拖字诀 (正当版):
"A 总, 支付重构 3 个月后完成, 我们能拿到一个关键数据:
微服务的运维成本、开发效率、故障率。
带着这些数据再决策订单要不要拆, 决策质量会高 10 倍。
现在决策, 我们缺关键信息。"
心理原理: 老板要的是"事情往前走"，你给的是"事情往前走 + 决策会更准"
→ 双赢
结论：让子弹飞 = 用"决策质量"换"决策时机"。这不是拖延，是决策成熟度。
# 7. 演进节奏拆分
# 7.1 里程碑拆法
假设支付重构必须做，怎么拆里程碑才不翻车？拆分原则：每个里程碑独立上线、独立回滚、独立验收。
支付重构 3 个月拆法，每个里程碑均可独立上线/回滚（Feature Flag 控制），验收标准如下：
| 里程碑 | 内容 | 验收 |
|---|---|---|
| M1 (W1-3) | 网关框架 + Stripe 接入 | 5% 灰度成功率 > 99% |
| M2 (W4-6) | Alipay/WeChatPay 迁入 | 30% 灰度, 老渠道不劣化 |
| M3 (W7-9) | PayPal/Union 接入 | 全渠道 60% 灰度 |
| M4 (W10-12) | 全量 + 老代码下线 | 100% 运行 30 天无异常 |
结论：4 个里程碑，每 3 周一个节奏，每一个都是"完整的胜利"，翻车最多回退到上一个里程碑。
# 7.2 依赖排序
怎么决定里程碑的顺序？按"技术依赖 + 业务价值 + 风险验证"三重排序：
① 技术依赖: A 依赖 B, B 必须先做
② 业务价值: 高价值先做 (提前验证 ROI)
③ 风险验证: 高风险先做 (提前暴露问题)
支付重构里的应用：
M1 先做 Stripe:
技术依赖: Stripe 是新渠道, 可独立
业务价值: 海外业务 Q3 上线, 最急
风险验证: Stripe 网络最不确定, 早验早稳
M2 才做老渠道迁移:
技术依赖: 网关框架已经过 Stripe 验证
业务价值: 老渠道流量大, 但已有稳态
风险验证: 迁老渠道风险是"切换风险", M1 已扫清框架风险
结论："新且不重要"的最先做，用最低成本验证框架。这是 Netflix、亚马逊的默认做法。
# 7.3 每步都能上线
里程碑必须都能上线吗？做一半的成果不能留着？做一半的代码 = 技术债 = 后续必然翻车：
❌ 反例 — M1→M3 全未上线, M4 大爆炸: 12000 行代码 3 个月没在生产跑过, 一次接管流量, 必翻车
正确做法：Feature Flag + 灰度，即使功能没做完，代码也在生产运行（关着）。上线不等于放量。
结论："每一步都能上线"是渐进演进的底线。做了不上 = 大爆炸的前奏。
# 7.4 演进决策反模式
| 反模式 | 症状 | 危害 | 修复 |
|---|---|---|---|
| 大爆炸重构 | 一次性推翻旧架构重写 | 多变量同时变，无法回滚 | 绞杀者模式，新旧共存逐步替 |
| 顺便主义 | "既然都改了，顺便把 X 也改了吧" | 未评估的 Type1 决策，风险叠加 | 一次改一件，先算 Y/X |
| 技术洁癖 | "老代码太丑，重写" | 丑但稳 > 美但险 | 修一处 = 一处收益，别追整体 |
| 过度设计 | 为一年后"可能"的需求做架构 | 为不确定未来付确定现在 | YAGNI，留扩展点别提前实现 |
| 只做不停 | 从不复盘"要不要继续" | 沉没成本谬误 | 每里程碑 GO/NO-GO 复盘 |
# 9. 决策沟通策略
# 9.1 向上说不的姿势
向老板说"不"是不是很危险？说不的核心是"帮他做出更好的决策"，他的诉求你没否，你只是给了更好的路径。三个姿势：
姿势 1 - 数据说话: "按 NPV 折现算, 全做的期望 ROI 是 X, 只做支付的期望 ROI 是 3X。建议先做支付。"
姿势 2 - 风险摊开: "全做的翻车概率是 60%, 翻车后损失预计 500 万。您愿意承担这个风险吗？"
姿势 3 - 选项摊开: "有三种路径, 我推荐 A, 但决策权在您。请您选择, 我会全力执行。"
结论："说不"不是对抗，是共谋更好的决策。
# 9.2 用数据代替嘴硬
老板不相信我的数据怎么办？准备三层数据支撑：
① 内部经验数据:"我们上次拆用户中心, 计划 3 月, 实际 6 月, 翻车概率 33%"
② 行业标杆数据:"Netflix 微服务拆分平均 18 月, Uber 微服务改造 24 月"
③ 反例警示数据:"Segment 从微服务回退到单体, Amazon Prime Video 从微服务回退到单体"
结论：内部数据 + 外部标杆 + 反例 = 无法被"你太保守"反驳的组合拳。
# 9.3 让对方选择
为什么要让老板选，不能直接告诉他答案吗？选择权 = 尊严 = 支持。
❌ 独裁式: "我们只做支付, 其他都不做"。老板感受: 你在挑战我的决策权
✅ 引导式: "有 A/B/C 三个选项, 我建议 A, 但请您拍板"。老板感受: 我在决策, 你在辅助 → 他会更认真看数据 → 更可能选 A
结论：让老板选择 = 你赢。你的目标不是"我说了算"，是"最终决策是正确的"。
# 10. 综合案例串讲
# 10.1 糖果充顶住老板
回到糖果充。他花了 2 天做完量化分析，然后约 A 总 1v1：
糖果充约 A 总 1v1:
四个项目 NPV: 支付 Y/X=48, 订单 14, 库存 14, 履约 13——支付 ROI 是其他的 3 倍。
如果全做, 周期 9→18-24 月, 翻车概率 15%→60%, 成本 300-500 万。
三个方案:
方案 A (推荐): 只做支付 — 3 个月/3 人, Q3 如期上线
方案 B (次选): 支付+订单 — 6 个月/5 人, 多 200 万, 延期 2 周
方案 C (激进): 全做 — 18-24 月/10 人, 翻车 60%, 延期 6 月+
请您拍板。"
A 总 (看 30 秒): "行, 就 A。支付跑稳了 Q4 再启动订单。"
关键动作复盘：
① 糖果充没有"硬顶", 用数据说话
② 三个方案给了 A 总"决策权"
③ 明确"如果要激进方案, 需要技术委员会背书"，把责任摊开
④ 每个方案都有 GO 后果和 NO-GO 后果
⑤ 结果: A 总选了糖果充推荐的方案, 并且是他自己选的
# 10.2 一次成功演进
方案 A 落地后，糖果充严格按照本篇原则执行：
M1 (W1-3): 网关 + Stripe ✅ 5% 灰度 99.2%, 老代码 0 改动
M2 (W4-6): 老渠道迁移 ⚠️ WeChat 签名问题, FF 关闭 5 分钟回滚, 修后恢复
M3 (W7-9): PayPal/Union ✅ 经验复用, 顺利
M4 (W10-12): 全量 + 保留 30 天 ✅ 0 事故, Day 42 老代码下线
汇总: 计划 12 周 / 实际 13 周, 1 次可控回滚, 生产 0 事故, Q3 如期上线
M2 那次回滚成为团队的经典案例，因为有 Feature Flag，一次可能酿成 P0 事故的兼容问题被 5 分钟化解。团队从此把"Feature Flag + 灰度"写进研发规范。
# 10.3 决策哲学回扣
回望糖果充这次决策过程，架构演进决策能力的本质是：
初级: 被诉求驱动 (老板要啥做啥)
中级: 会评估成本 (敢说"这个太贵")
高级: 会算 Trade-off (用数据讲清楚 ROI)
资深: 会保留可逆性 (即使做, 也留退路)
大师: 敢让子弹飞 (敢说"现在信息不足, 3 月后再决定")
演进决策的四个心法：
① "现在做" 不等于 "现在做完" → 拆里程碑
② "都要做" 不等于 "一起做" → 排优先级
③ "老板要" 不等于 "你扛" → 明确风险
④ "做" 有时不如 "先不做" → 让子弹飞
架构演进决策能力 = 帮组织在不确定性中做出最好的一步，不是最激进、不是最保守，是当前信息下最合理。
# 10.4 演进决策速查
演进决策速查表：
| 场景 | 动作 |
|---|---|
| 老板说"顺便做" | 先算 Y/X，用三方案回应 |
| 拆微服务 | Type1 决策，慢决策，收集尽可能多信息 |
| 加缓存/换库 | Type2 决策，快决策，试错成本低 |
| 一次改多件 | 拆开，一次改一件 |
| 大爆炸重构 | 拒绝，改用绞杀者模式 |
| 老代码丑但稳 | 别碰，改增量重构 |
| 已投入很多想收手 | GO/NO-GO 复盘，别陷入沉没成本 |
| 未来可能用到 | YAGNI，只留扩展点不实现 |
| 上级坚持做 | 让子弹飞 or 要求书面背书 |
| 说服上级 | 数据 + 选项 + 决策权在他 |
三轴决策图：
决策时思考:
X 轴: 时间 × 风险 (成本)
Y 轴: NPV 折现后收益
Z 轴: 可逆度 (Type1/Type2)
Y/X 高 + Type2 → 立刻做
Y/X 高 + Type1 → 慢决策做
Y/X 低 + Type2 → 有空做
Y/X 低 + Type1 → 别碰
下一集预告：糖果充支付项目大获成功。M3 阶段部门要拉一场技术方案讨论，是自研 API 网关还是买商业方案？会议室里同事 B 声音大、逻辑却混乱，把讨论带偏了两小时。糖果充想插话却被打断三次。**第 03 篇《技术讨论表达能力》**告诉他"结构化压过嗓门大"。
