1.技术方案设计能力
# 1.技术方案设计能力
# 目录介绍
# 1. 案例引入
# 1.1 方案会上的悲剧
先看一段真实故事。杨充，Java 三年经验，刚从大厂跳到一家 100 人规模的公司，Leader 交给他第一个独立任务：把老订单系统的支付模块从 Alipay SDK 迁到聚合支付。
杨充很兴奋，两天就交出一份 8 页方案，标题写着「支付重构技术方案 V1」，去评审会上被 5 连问：
14:00 杨充开讲, 直接切到"我要引入 XX 聚合支付平台"
14:05 Leader: 为什么必须是 XX?你评估过 YY、ZZ 吗?
杨充: YY 我看过, 觉得 XX 更好
Leader: "觉得"?你有对比表吗?
杨充: ......
14:10 QA: 切完老订单还能不能查? 老数据要不要迁?
杨充: 应该可以吧,回头再看
QA: "回头再看"?那你这方案的影响面是什么?
14:20 运维: 上线怎么灰度?挂了怎么回滚?
杨充: 全量切一次
运维: 全量?你测试环境跑通了几笔交易?
14:30 产品: 接入完之后, 用户体验有没有变化? 客服培训要不要跟?
杨充: ......这我没考虑
14:40 CTO: 这是个方案还是个想法?回去重写
全场沉默
结论：方案被打回。杨充晚上写日记："我明明搞懂了技术，为什么大家不认？"
之后 3 个月，杨充的方案又被打回了 4 次。每次都是同样的场景，只是问题换了一批。他开始怀疑：是我技术不行，还是方案本身有问题？
# 1.2 顺藤摸到根因
带着这条线往下挖：
- 假设 1：杨充技术不好？——不是，他 SDK 集成能力比同组多数人强
- 假设 2：方案篇幅不够？——不是，V2 有 20 页，还是被打回
- 假设 3：口才不好？——不是，他 1v1 能说清楚，一开评审就翻车
- 假设 4：那到底是什么？——方案根本不是"讲技术"，而是"讲决策"
- 假设 5："讲决策"意味着什么？——评审者要能凭这份方案作出 GO/NO-GO，而不是听你汇报你想干什么
- 假设 6：为什么大厂新人也能写出合格方案？——他们被强制走方案八要素模板
- 假设 7：模板到底是什么、怎么写？——本篇的主线
仔细分析杨充这次翻车的根因：
表象 真实问题
────────────────────────────────────────────────
"我要引入 XX 平台" → 没有可选方案,只有一个答案
"觉得 XX 更好" → 没有 Trade-off 对比,凭偏好
"回头再看" → 没有影响面盘点,漏掉存量数据
"全量切一次" → 没有风险回滚,没有灰度
"这我没考虑" → 没有跨端影响,忽略客服/产品
根因：把方案当成"技术选型说明书"——只讲我要做什么、用什么，不讲为什么必须是这个、代价是什么、出问题怎么办。
这一段里至少藏着 8 个原理点：
① 方案到底要包含哪几大块? 缺一块会怎样? → 第 2 章
② 背景怎么写才不是"废话开头"? → 第 3 章
③ 目标怎么写才能被拿来验收? → 第 3 章
④ 为什么必须至少 3 个可选方案? → 第 4 章
⑤ Trade-off 怎么表达才有说服力? → 第 4 章
⑥ 影响面盘点漏什么会翻车? → 第 5 章
⑦ 风险和回滚怎么写才不是走过场? → 第 6 章
⑧ 评审现场怎么陈述才不被打断? → 第 7 章
# 1.3 我们要回答什么
这个事故就是本篇的主线案例。带着上面 8 个问号往下走，每讲完一段方法就解开一两个；最后在第 10 章把杨充的方案彻底重写，并给出可复用模板。
本篇路线：
方案八要素 (第 2 章)
↓
背景与目标 (第 3 章) ─→ 解开"为什么写、写完像什么"
↓
可选方案对比 (第 4 章) ─→ 解开"为什么是这个,不是那个"
↓
详细设计与影响面 (第 5 章) ─→ 解开"改了哪、影响了谁"
↓
风险与回滚 (第 6 章) ─→ 解开"翻车了怎么办"
↓
方案陈述三段式 (第 7 章) ─→ 解开"评审会上怎么讲"
↓
反模式 (第 8 章) + 自检清单 (第 9 章)
↓
综合案例 (第 10 章) ─→ 杨充的方案彻底重写
📌 本篇定位：这是"程序员精进"系列的开篇。方案是所有后续讨论、评审、执行的载体。没有一份合格方案，后面所有的软技能都没有着力点。读完本篇后再写方案，你会自然回答："这份方案敢不敢发给 CTO 直接看"。
# 2. 方案全景图
# 2.1 八要素总图
一份合格的技术方案，本质包含八个要素。缺一个都会在评审现场被戳穿：
┌────────────────────────────────────────────────────────────┐
│ 技术方案八要素 │
├────────────────────────────────────────────────────────────┤
│ │
│ ① 背景 (Why now) │
│ 为什么现在做,不做会怎样 │
│ │ │
│ ▼ │
│ ② 目标 (Goals) + 非目标 (Non-Goals) │
│ 可验收的成功标准 + 明确不做的边界 │
│ │ │
│ ▼ │
│ ③ 可选方案 (Alternatives) │
│ 至少 3 个,含推荐+备选+否决 │
│ │ │
│ ▼ │
│ ④ Trade-off 对比表 │
│ 多维度打分,量化对比 │
│ │ │
│ ▼ │
│ ⑤ 详细设计 (Design) │
│ 数据模型、接口、时序、代码骨架 │
│ │ │
│ ▼ │
│ ⑥ 影响面 (Impact) │
│ 上下游、存量数据、跨端、组织 │
│ │ │
│ ▼ │
│ ⑦ 风险与回滚 (Risks & Rollback) │
│ Top 5 风险 + 每个都配缓解与回滚 │
│ │ │
│ ▼ │
│ ⑧ 排期与里程碑 (Milestones) │
│ 人天估算、依赖、灰度节奏 │
│ │
└────────────────────────────────────────────────────────────┘
八要素的核心属性速查：
| 要素 | 输入 | 输出 | 常见翻车 |
|---|---|---|---|
| 背景 | 业务/技术痛点 | Why now 三句话 | 写成"最近老板要求" |
| 目标 | 业务要求 + 技术诉求 | 可量化验收指标 | 写成"提高性能" |
| 可选方案 | 领域调研 | ≥3 方案 + 决策矩阵 | 只有一个方案 |
| Trade-off | 方案对比 | 加权打分表 | 全凭"觉得" |
| 详细设计 | 推荐方案 | 数据/接口/时序 | 只写"用 Redis" |
| 影响面 | 全链路盘点 | 影响清单 + 联系人 | 漏掉存量数据 |
| 风险回滚 | 上线预演 | Top 5 + 缓解 + 回滚 | 写"暂无风险" |
| 排期 | 拆分 + 依赖 | 里程碑 + 灰度节奏 | 一句"两周搞定" |
# 2.2 为什么这么切
为什么把方案切成"八要素"，而不是想到哪写到哪？
疑惑：第 1 章的方案不就是"写清楚我要做什么"吗？为什么不够？
论证：
1.没背景就没必要——"为什么现在做"没交代 → 评审者第一反应是"这事儿能不能不做"。杨充 V1 直接讲选型，跳过了背景，评审者的心是冷的。
2.没目标就没验收——"提升性能"是诉求不是目标，必须变成"P99 从 800ms 降到 300ms 以内"。没目标的方案 = 上线后扯不清成功还是失败。
3.没可选方案就没决策——只有一个答案时，评审只能选"接受你的答案"或"拒绝你"。给出三个，评审的心态从"审你"变成"跟你一起挑"。方案的政治学。
4.没 Trade-off 就是拍脑袋——"觉得 XX 好"是感受，"XX 在延迟维度胜出，但成本高 30%"是论证。决策必须能被复现。
5.没影响面就有黑天鹅——杨充漏掉了存量订单迁移、客服培训。你没盘的坑，一定会踩到。
6.没风险回滚就是裸奔——"应该没问题"是希望，"如果 X 发生就回滚到 Y"是工程。评审的本质是评风险，不是评设计。
7.没排期就没承诺——"两周搞定"没依赖没里程碑 → 拖到六周，人人愤怒。排期是对齐预期的合同。
8.反向验证：没有这八要素会怎样？答案就是第 1 章杨充的场景——5 连问全打脸，评审通过率 0%。
结论：八要素的本质是把"技术方案"从汇报稿升级为决策书——背景说明必要性、目标定义验收、可选方案给出选项、Trade-off 支撑决策、设计落地方案、影响面盘全链路、风险回滚兜底、排期约定预期。少一环都漏风。
下面从最基础的"背景与目标"开始，看它如何决定后续的一切。
# 3. 背景与目标
# 3.1 背景不是废话
疑惑：写背景我经常写"随着业务发展，我们决定引入 XX"——这算不算背景？
论证：这种写法有三宗罪：
❌ 空话开头: "随着业务发展、用户规模不断扩大, 我们决定引入聚合支付"
评审者的心声: 谁的业务?哪部分发展?规模到多少?为什么现在?不引入会怎样?
结果: 评审第一分钟就走神
一份能抓住评审注意力的背景，回答三个问题：
① 现状是什么? (量化)
② 问题是什么? (业务影响)
③ 不做会怎样? (代价)
结论：背景的本质是建立紧迫感——让评审者读完 30 秒就理解「这个事必须做」。
对比示例：
❌ 空话背景 (杨充 V1): "随着业务发展, 我们需要引入聚合支付以支撑更多支付渠道"
✅ 有效背景 (杨充 V4):
"现状:
- 老订单系统仅接入 Alipay + WeChatPay 两个渠道
- 2026 上半年海外业务上线, 需要接入 Stripe/PayPal
- 每次新增渠道平均耗时 2 人月
问题:
- Q3 有 3 个新渠道需求排队, 老架构一个都接不进来
- 支付渠道故障时无法自动切换, 上季度 3 次故障共损失订单 8000+ 单
代价 (不做):
- Q3 海外业务上线延期 1 个月, 预计损失 GMV 300 万
- 现有单渠道模式再遭遇故障, 单次损失预计 100 万+
"
关键差异：有效背景在制造决策焦虑——评审者读完会主动问"那什么时候能上"，而不是"这事儿要不要做"。
# 3.2 目标必须可验收
疑惑：目标写"提升系统性能与可扩展性"，可以吗？
论证：不可以，因为你没法验收。
❌ 不可评审 ✅ 可评审
"提升性能" → "订单创建接口 P99 < 300ms"
"提高可扩展性" → "新增支付渠道从 2 人月降到 3 人天"
"改善用户体验" → "支付失败率从 0.8% 降到 0.2% 以内"
"降低运维成本" → "月度故障平均恢复时间从 45min 降到 10min"
结论：目标必须遵循 SMART：具体、可测量、可达成、相关、有时限。
一份合格目标的模板：
项目目标 (T+3 月验收):
业务目标:
□ 支付渠道扩展到 5 个 (Alipay/WeChatPay/Stripe/PayPal/Union)
□ 新渠道接入耗时 ≤ 3 人天
□ Q3 海外业务上线不受支付阻塞
技术指标:
□ 支付接口 P99 ≤ 300ms
□ 单渠道故障 30s 内自动切换
□ 支付失败率 ≤ 0.2%
质量指标:
□ 单元测试覆盖率 ≥ 80%
□ 关键接口有链路追踪
□ 灰度上线, 30% -> 60% -> 100% 三阶段
验收原则：每一条都能拿工具跑出来验证——不能靠"感觉更好了"。
# 3.3 非目标同样重要
疑惑：为什么方案里还要写"不做什么"？我只写做什么不就够了？
论证：非目标（Non-Goals）是边界防御：
杨充不写非目标的后果:
评审 A: 顺便把退款逻辑也重构了吧?
评审 B: 加上分账功能?
评审 C: 顺便支持虚拟货币?
杨充: ... (答应了都完不成, 不答应就"不配合")
结果: 项目范围膨胀 3 倍, 3 个月做不完, 全员骂
结论：非目标是给方案画一圈红线，让评审知道"哪些扩展诉求本项目不接"。
非目标示例：
本次不做 (Non-Goals):
□ 退款流程重构 (走独立项目, 计划 Q4)
□ 分账/清算功能 (依赖财务改造, Q1 再启动)
□ 老订单历史数据迁移 (走离线任务, 单独排期)
□ 虚拟货币/加密支付 (合规未通过, 暂缓)
□ 支付 SDK 前端重构 (客户端团队负责, 本项目仅后端)
说明: 以上诉求不在本项目范围, 如需推进请另立项。
非目标的政治意义：主动说"不"，胜过被动扛不下。
# 4. 可选方案对比
# 4.1 至少给三个
疑惑：我明明知道该选 A，为什么还要写 B 和 C？
论证：这是方案的政治学：
只给 1 个方案:
评审心态: "审你" → 只能通过或否决
评审动作: 挑刺、找问题、要证据
你的处境: 防御
给 3 个方案 (推荐 + 备选 + 否决):
评审心态: "跟你一起挑" → 从审判者变成合作者
评审动作: 权衡、讨论、微调
你的处境: 引导
结论：三方案让评审者感受到"你已经全面思考过"，同时把你从被审者变成主导者。
三方案的组合原则：
方案 A (推荐): 综合最优, 你想让评审选的这个
方案 B (备选): 某维度更优 (如更省钱、更快上线), 保留作 Plan B
方案 C (否决): 表面合理但你已排除的, 用来"消灭想当然"
举例（支付重构）：
方案 A (推荐): 自研聚合支付网关
- 灵活可控、长期成本低
- 建设期 3 个月
方案 B (备选): 接入 Ping++ 等第三方聚合平台
- 快速上线 (2 周)
- 长期抽佣, 3 年成本高 200 万
方案 C (否决): 直连各渠道 SDK, 应用层封装
- 短期最快 (2 周)
- 每加一个渠道仍需 2 人月, 没解决根本问题
# 4.2 Trade-off 表
疑惑：三个方案怎么比才有说服力？
论证：用加权打分矩阵，让评审看到"分数怎么算出来的"：
维度权重:
- 建设周期 (0.20)
- 长期成本 (0.25)
- 灵活性 (0.20)
- 团队能力 (0.15)
- 风险 (0.20)
对比表（10 分制）：
| 维度 | 权重 | A 自研 | B 三方 | C 直连 |
|---|---|---|---|---|
| 建设周期 | 0.20 | 5 | 9 | 8 |
| 长期成本 | 0.25 | 9 | 4 | 5 |
| 灵活性 | 0.20 | 9 | 5 | 3 |
| 团队能力 | 0.15 | 7 | 9 | 8 |
| 风险 | 0.20 | 6 | 8 | 5 |
| 加权总分 | 1.00 | 7.30 | 6.50 | 5.65 |
关键动作：权重先定、分数后打——先跟评审对齐"我们最看重什么"，再展示分数。
反面教材：如果先打分再定权重，评审会怀疑"你是不是为了让 A 赢反推的分数"。
# 4.3 推荐的理由
疑惑：把分数摆出来就够了吗？
论证：不够，还要回答一个反问题：
反问: "为什么不选 B?B 上线更快啊"
标准回答结构 (三句话):
① B 在 XX 维度确实更优 (给面子)
② 但 YY 维度我们更看重, 因为 ZZ (讲价值观)
③ 长远看 A 更值得 (给决策的锚)
示范:
① "B 的建设周期 2 周确实吸引人"
② "但我们更看重长期成本, 因为公司 Q4 预算已锁定, 3 年多花 200 万会
压死续做的钱"
③ "所以短期慢 2.5 个月换 3 年可控, 我们建议 A"
结论：推荐理由 = 分数 + 价值观 + 长远视角。评审即使不同意，也会觉得"你已经想清楚了"。
# 5. 详细设计与影响面
# 5.1 设计颗粒度
疑惑：详细设计要写多细？画个大架构图够不够？
论证：颗粒度取决于评审要作出的决策：
方案评审阶段:
- 系统架构图 (模块划分)
- 关键流程时序图 (2-3 个核心场景)
- 数据模型草图 (核心 3-5 张表)
- 关键接口签名 (对外接口)
技术设计阶段 (方案通过后):
- 完整类图
- 所有接口 OpenAPI
- 完整数据字典
- 详细时序图 (10+ 个场景)
结论：方案 ≠ 技术设计文档。方案只需要"能让评审拍板"的最少设计，不需要写到能直接编码。
颗粒度的判断标准：
✅ 应该有:
- 支付网关内部核心模块 (路由/风控/记账/回调)
- 一笔支付的完整时序图
- 核心表 payment_order/payment_channel 的字段
- 对外接口 /pay/create /pay/query /pay/notify
❌ 不必有:
- 每个类的方法签名
- 数据库索引明细
- 每个字段的长度/默认值
- 每个接口的每个错误码
# 5.2 上下游影响
疑惑：影响面写什么？我改的是自己的服务，跟别人有什么关系？
论证：99% 的项目翻车都是因为没盘完影响面。
影响面盘点清单（六层）：
┌─────────────────────────────────────┐
│ 影响面盘点六层 │
├─────────────────────────────────────┤
│ ① 上游调用方 谁在调我的接口 │
│ ② 下游依赖 我调了谁 │
│ ③ 存量数据 历史数据要不要迁 │
│ ④ 跨端影响 App/Web/H5 前端 │
│ ⑤ 运营影响 客服/风控/财务 │
│ ⑥ 组织影响 需要哪些团队配合 │
└─────────────────────────────────────┘
杨充 V1 漏掉的：
① 上游: 订单服务、退款服务、对账服务 → V1 漏
② 下游: Alipay/WeChatPay/Stripe SDK → V1 部分覆盖
③ 存量: 200 万笔历史订单如何处理 → V1 漏
④ 跨端: App 支付页 SDK 版本兼容 → V1 漏
⑤ 运营: 客服看板字段、财务对账格式 → V1 漏
⑥ 组织: 需要客户端、财务、客服三方配合 → V1 漏
结论：影响面每一层都要具体到人：
影响清单示例:
| 层级 | 具体影响 | 联系人 | 沟通状态 |
|------|---------|-------|--------|
| 上游 | 订单服务需改支付调用 | 老王 | ✅ 已对齐 |
| 上游 | 退款服务改回调地址 | 老李 | ⚠️ 待确认 |
| 存量 | 200万订单迁移 | 数据团队 | ✅ 独立排期 |
| 跨端 | App 需升级 SDK | 客户端小张 | ✅ 已对齐 |
| 运营 | 客服看板加渠道字段 | 客服主管 | ❌ 未沟通 |
红色项 = 评审现场的雷。方案里主动列出未沟通的项，等于承认"我知道这里有坑，需要评审帮我协调"。
# 5.3 数据与接口
疑惑：数据设计写什么？接口列表就够了吗？
论证：数据设计的三个关键：
① 主表结构 (核心字段+类型+索引)
② 数据流转图 (谁写谁读)
③ 数据一致性策略 (最终一致?强一致?)
接口设计的三个关键：
① 对外接口的 5W 表 (谁调、干啥、入参、出参、错误码大类)
② 内部关键接口 (跨模块的)
③ 幂等性/超时/重试策略
结论：数据与接口部分能被拿去 QA 编写测试用例，就是合格颗粒度。
# 6. 风险与回滚
# 6.1 风险不是走过场
疑惑：写风险栏就是"依赖不稳定、需求变更"这几句套话，够吗？
论证：套话 = 走过场 = 评审知道你没认真想。
真正的风险 = 能画出场景 + 有量化影响 + 有具体缓解：
❌ 走过场:
"风险: 依赖第三方不稳定, 需求可能变更"
✅ 真风险:
"风险 1: Stripe 海外网络延迟
- 场景: 中国大陆 → Stripe 美西, RTT 250-400ms
- 影响: 单笔支付延迟增加 300ms+, P99 超时率可能上升 5%
- 缓解: 部署在香港节点作为中转, 同步开启异步重试队列
- 检测: 上线后 24h 内每 5min 检查延迟分布, 触发阈值告警"
Top 5 风险模板：
风险清单 (按影响 × 概率排序):
| # | 风险 | 概率 | 影响 | 缓解 | 兜底 |
|---|-----|-----|-----|-----|-----|
| 1 | Stripe 网络延迟 | 高 | P99+ | 香港中转 | 降级到 Ping++ |
| 2 | 老订单迁移丢单 | 中 | 极高 | 双写 3 天 | 回滚脚本 |
| 3 | 新渠道回调伪造 | 中 | 高 | 签名+白名单 | 人工审核 |
| 4 | 灰度期性能未达 | 中 | 中 | 压测预演 | 缩灰度比例 |
| 5 | 客服培训不到位 | 高 | 低 | 3 场培训 | 双班值守 |
结论：写风险的心态不是"应付评审"，是帮自己提前上线一次。
# 6.2 回滚预案必备
疑惑：回滚不就是"发现有问题回滚代码"？
论证：回滚有五个层次，代码只是最外层：
┌────────────────────────────────────┐
│ 回滚五层 │
├────────────────────────────────────┤
│ L1 配置回滚 改配置项即可 │
│ L2 开关回滚 Feature Flag 关掉 │
│ L3 代码回滚 发版回滚 │
│ L4 数据回滚 数据订正/双写切读 │
│ L5 业务回滚 走人工兜底流程 │
└────────────────────────────────────┘
回滚优先级: L1 > L2 > L3 > L4 > L5
关键动作：每个风险都要指定至少一个可执行的回滚层：
风险 2 "老订单迁移丢单" 的回滚:
L2: 关闭"读新库"开关, 立刻切回读老库
L4: 双写 3 天期间, 老库始终有最新数据
L5: 万一双库都有问题, 人工客服工单流程
RTO 目标: L2 切换 ≤ 5 分钟, L4 切换 ≤ 30 分钟
结论：回滚预案 = 可执行动作 + 时间承诺。没有 RTO 的回滚 = 假回滚。
# 6.3 灰度与开关
疑惑：为什么灰度要写在方案里？灰度是上线时的事吧？
论证：灰度是方案的一部分，因为它决定架构：
需要灰度的方案 vs 不需要灰度的方案:
需要灰度 → 必须内置 Feature Flag → 影响代码结构
需要按流量分桶 → 必须引入分桶键 (uid/orderId) → 影响接口设计
需要多版本并存 → 必须做兼容层 → 影响数据 schema
灰度模板：
灰度计划:
Day 1-3 : 5% 流量 (内部员工白名单)
- 观察指标: 支付成功率、P99、异常告警
- 通过标准: 三项指标不劣化 5% 以上
Day 4-7 : 30% 流量 (随机 uid 尾号)
- 观察指标: 同上 + 客服工单量
- 通过标准: 工单量增长 < 20%
Day 8-14 : 60% 流量
- 保持每日复盘
Day 15+ : 100% 全量
- 双写观察 7 天
- 老代码保留 30 天再删
任一阶段异常 → 立刻回滚到上一个百分比 → 复盘再推进
结论：灰度写在方案里 = 提前跟评审对齐"上线不会一步到位"。评审最怕的是"我不知道你什么时候大炮打过来"。
# 7. 方案陈述三段式
# 7.1 结论先行
疑惑：评审现场怎么讲，才能不被打断？
论证：讲方案有三种讲法，效果天差地别：
❌ 铺垫式 (最常见):
"大家好, 我今天讲一下我们组的支付重构方案。
先讲一下背景, 我们的老系统是 5 年前搭建的......"
(评审在心里: 又是废话开场, 我先刷会手机)
❌ 技术式:
"我们要引入聚合支付, 用 Spring Cloud + 各种 SDK,
数据层用 Sharding-JDBC......"
(评审在心里: 你到底要解决什么问题?)
✅ 结论式:
"本次评审我请大家决策一件事:
支付模块选自研聚合网关方案 (方案 A),
投入 3 人 × 3 个月,
带来 3 年抽佣成本节省 200 万、渠道扩展效率 20 倍提升。
核心风险是海外网络, 已有中转+降级预案。
请大家聚焦在:
(1) 3 个月周期能不能压到 2 个月?
(2) 香港中转的合规性如何确认?
下面详细展开。"
结论：结论先行 = 让评审 30 秒内进入决策状态。他们越早知道要拍什么板，评审效率越高。
# 7.2 论证展开
疑惑：结论抛完之后怎么展开？
论证：展开的顺序不是方案文档的顺序，而是评审关心度的顺序：
展开顺序 (推荐):
1. 目标 (让评审确认"要解决的问题对不对")
2. 方案对比 (让评审看"为什么是这个")
3. 风险回滚 (让评审心里稳)
4. 详细设计 (只讲关键点, 细节让他们看文档)
5. 排期 (最后说)
反常识: 详细设计放最后
原因: 评审不需要在会上把代码看懂, 他们要看的是决策依据
时间分配（1 小时评审会）：
0-5min 结论 (先行)
5-15min 目标 + 非目标
15-30min 方案对比 + Trade-off
30-45min 风险回滚
45-55min 关键设计 + 排期
55-60min 收口
结论：论证展开的本质是按评审的决策路径讲，不是按文档目录讲。
# 7.3 收口与提问
疑惑：讲完之后怎么收口？
论证：收口的核心是把评审拉回决策：
❌ 空洞收口:
"我讲完了, 大家有什么问题?"
✅ 有效收口 (四步):
① 复述结论 "所以我请大家拍板: 选 A 方案"
② 列未决项 "有 3 个待评审确认的问题: ..."
③ 邀请异议 "反对意见请特别提出, 我会一一回应"
④ 定下时间 "如果今天拍板, 下周一启动"
结论：没被拍板的方案 = 白讲。收口要主动索取决策，不是等评审"想到再说"。
# 8. 方案反模式
# 8.1 只有一种方案
症状：全篇只讲一个方案，其他一笔带过。
危害：评审只能通过或否决，你从主导者变成被审者。
修复：至少三个方案，含"故意送分方案"用来对比。
# 8.2 目标不可验收
症状：目标里全是"提升"、"优化"、"改善"。
危害：上线后没法证明"做到了"，绩效评估时被质疑。
修复：每条目标都能被 SQL 查、Grafana 看、脚本跑。
# 8.3 风险栏写"无"
症状：风险一栏写"暂无重大风险"。
危害：评审立刻怀疑你"没上过线"，全场信任崩塌。
修复：宁可写小风险，也别写"无"。能写出风险 = 想清楚了。
# 8.4 通篇技术自嗨
症状：从头到尾讲 Spring Cloud、Kafka、Netty 有多牛。
危害：非技术评审（产品、运营、CTO）跟不上，无法投票。
修复：技术名词后面必须紧跟业务价值。「用 Kafka」不够，「用 Kafka 保证支付回调不丢失，历史丢单率从 0.3% 降到 0」才够。
# 8.5 影响面写不全
症状：只讲自己服务的改造，不讲上下游。
危害：上线前一天发现要拉别的团队配合，全组加班。
修复：影响面六层每层都盘一遍，具体到人。
# 8.6 排期拍脑袋
症状：写"预计 6 周完成"，没有拆分、没有依赖。
危害：实际做 12 周，团队 credibility 毁掉。
修复：排期公式 = 累加子任务人天 × 1.5 缓冲 + 依赖等待时间。
# 9. 写完自检清单
# 9.1 十五条自检
方案写完后，逐条打勾。任意一条打不了勾 = 别拿去评审：
背景与目标 (4 条):
□ 1. 背景能让人 30 秒理解"为什么现在做"
□ 2. 目标每条都可验收 (SQL/Grafana/脚本能证明)
□ 3. 非目标明确列出至少 3 条
□ 4. 目标对齐过业务方一次
可选方案 (3 条):
□ 5. 至少 3 个方案 (推荐 + 备选 + 否决)
□ 6. Trade-off 表有加权权重, 权重先于分数确定
□ 7. 推荐理由能回答"为什么不选备选"
详细设计与影响面 (3 条):
□ 8. 详细设计颗粒度让 QA 能编测试用例
□ 9. 影响面六层每层都列出, 每项指定联系人
□ 10. 未沟通/待确认项主动列出
风险与回滚 (3 条):
□ 11. Top 5 风险每条有量化影响 + 缓解 + 兜底
□ 12. 回滚预案指定 L1-L5 中的可执行层
□ 13. 灰度计划有阶段划分和通过标准
评审准备 (2 条):
□ 14. 结论先行三句话准备好
□ 15. 至少一位同事预审过, 提出的问题都在方案里回应了
# 9.2 找同事预审
疑惑：预审找谁?
论证：找三种人分别问一遍：
① 同 Level 的技术同学
问: "如果你来做, 会怎么做?"
收获: 检查是否忽视了明显方案
② 上下游的对接同学
问: "如果我这么改, 你要配合什么?"
收获: 检查影响面盘点
③ 上一级 Leader / 架构师
问: "如果你是评审, 会问什么?"
收获: 预演评审现场
结论：预审不是走流程，是把评审现场的雷提前引爆。
# 9.3 版本与追溯
疑惑：方案改了多次怎么管理？
论证：给方案标版本、留 Change Log：
方案版本管理:
V1.0 初稿 提出方案 A
V1.1 修改 Trade-off 表增加"团队能力"维度 (@Leader 反馈)
V1.2 修改 影响面加入客服团队 (@客服主管反馈)
V2.0 重写 拆分为方案 A/B/C 三选 (@CTO 反馈)
V2.1 终版 评审通过版本 (含所有讨论纪要)
结论：方案的版本 = 决策的历史证据。三年后有人问"为什么当初选 A"，你能直接翻出来。
# 10. 综合案例串讲
# 10.1 杨充第二次改稿
回到杨充。方案被打回后，他找了一位大厂来的架构师老陈请教。老陈没直接看方案，先问：
老陈: "你写方案时, 心里的读者是谁?"
杨充: "评审组吧, Leader、CTO、运维、QA。"
老陈: "那你有没有针对每个人的关注点写一段?"
杨充: "......没有, 我就按技术流程写的。"
老陈: "评审的本质不是审技术, 是审风险和决策。你的方案里,
CTO 在意的 ROI 在哪? 运维在意的回滚在哪?
QA 在意的验收标准在哪?"
杨充: (被点醒)
第二天杨充按八要素重写。三个关键改动：
改动 1: 背景重写
V1: "随着业务发展..."
V4: "Q3 海外业务上线, 3 个新渠道排队, 不做 GMV 损失 300 万"
改动 2: 加入方案对比
V1: 只有"引入聚合支付"
V4: 自研 vs Ping++ vs 直连, 加权打分 7.30 vs 6.50 vs 5.65
改动 3: 影响面到人
V1: "上下游需要调整"
V4: 列出 12 个联系人, 8 个已对齐、4 个待确认
改完后他找了同 Level 的老王和上级架构师老陈各预审一次，收获又是 15 个问题。每一个问题都被写进方案的对应章节。
三天后第二次评审，全程 55 分钟，评审组问了 8 个问题，7 个方案里都有回答，1 个当场记录跟进。方案通过。
# 10.2 一份合格方案全貌
杨充的 V4 版本目录长这样（供参考）：
支付重构技术方案 V4.0
1. 背景 (Why now)
1.1 现状 (量化)
1.2 问题 (业务影响)
1.3 代价 (不做的损失)
2. 目标与非目标
2.1 业务目标 (3 条)
2.2 技术指标 (3 条)
2.3 质量指标 (3 条)
2.4 非目标 (5 条)
3. 可选方案对比
3.1 方案 A: 自研聚合网关 (推荐)
3.2 方案 B: Ping++ 三方聚合
3.3 方案 C: 直连各 SDK (否决)
3.4 Trade-off 加权打分表
3.5 推荐理由与反问回答
4. 详细设计
4.1 系统架构图
4.2 核心模块 (路由/风控/记账/回调)
4.3 核心时序图 (下单支付/回调对账)
4.4 数据模型 (payment_order/payment_channel)
4.5 关键接口 (对外 4 个 / 对内 6 个)
5. 影响面盘点
5.1 上游影响 (订单/退款/对账)
5.2 下游依赖 (SDK 版本)
5.3 存量数据 (200 万订单迁移策略)
5.4 跨端影响 (App/H5)
5.5 运营影响 (客服/风控/财务)
5.6 组织影响 (联系人表)
6. 风险与回滚
6.1 Top 5 风险清单
6.2 回滚五层预案
6.3 灰度计划 (5%→30%→60%→100%)
7. 排期与里程碑
7.1 WBS 拆分 (子任务人天)
7.2 关键里程碑 (M1-M5)
7.3 依赖与关键路径
8. 附录
8.1 术语表
8.2 参考资料
8.3 版本 Change Log
# 10.3 设计哲学回扣
回望杨充这次改稿的全过程，八要素并不是模板僵化，而是决策成熟度的外显：
初级方案: "我要做 X" (只讲做什么)
中级方案: "我要做 X, 因为 A/B/C 权衡" (讲选择)
高级方案: "我要做 X, 因为 A/B/C,
风险是 D, 回滚是 E,
影响 F/G/H, 排期 I" (讲决策 + 兜底 + 承诺)
方案的能力 = 你的思维成熟度。写方案不是文书工作，是逼你把脑子里的直觉论证成决策。
# 10.4 方案模板速查
开箱即用的方案骨架（复制粘贴到你的下一个方案）：
# [项目名] 技术方案 V1.0
## 1. 背景
- 现状: <量化描述>
- 问题: <业务影响>
- 代价: <不做的损失>
## 2. 目标与非目标
### 2.1 目标 (T+X 月验收)
- 业务目标: <可验收指标 3 条>
- 技术指标: <可验收指标 3 条>
- 质量指标: <可验收指标 3 条>
### 2.2 非目标
- 明确不做的 3-5 条
## 3. 可选方案
### 3.1 方案 A: <名称> (推荐)
- 核心思路
- 优势/劣势
### 3.2 方案 B: <名称> (备选)
### 3.3 方案 C: <名称> (否决)
### 3.4 Trade-off 对比
| 维度 | 权重 | A | B | C |
|------|-----|---|---|---|
| ... | ... |...|...|...|
### 3.5 推荐理由
## 4. 详细设计
- 系统架构图
- 核心模块
- 关键时序图
- 数据模型
- 接口清单
## 5. 影响面
| 层级 | 具体影响 | 联系人 | 状态 |
|------|---------|-------|-----|
| 上游 | ... | @x | ✅ |
| 下游 | ... | @y | ⚠️ |
| 存量 | ... | @z | ❌ |
| 跨端 | ... | @a | ✅ |
| 运营 | ... | @b | ⚠️ |
| 组织 | ... | @c | ✅ |
## 6. 风险与回滚
### 6.1 Top 5 风险
| # | 风险 | 概率 | 影响 | 缓解 | 兜底 |
### 6.2 回滚预案
- L1-L5 层次
### 6.3 灰度计划
- 5% → 30% → 60% → 100%
## 7. 排期
- WBS 拆分
- 里程碑
- 依赖
## 8. 附录
- 术语表
- 参考资料
- Change Log
下一集预告：杨充方案通过后启动开发，第二周老板抛出一句话："既然要重构支付，顺便把订单、库存、履约都一起微服务化吧？" —— 又一场大爆炸的种子被埋下。**第 02 篇《架构演进决策能力》**告诉他"敢不做也是水平"。
本篇速查表：
| 场景 | 动作 |
|---|---|
| 写背景 | 现状（量化）+ 问题 + 代价 |
| 写目标 | SMART，能被 SQL/Grafana 验收 |
| 写方案 | 至少 3 个，含推荐/备选/否决 |
| 写对比 | 加权打分，权重先定 |
| 写设计 | 颗粒度让 QA 能写用例 |
| 写影响 | 六层盘点，具体到人 |
| 写风险 | Top 5，每个配缓解与回滚 |
| 讲方案 | 结论先行，按评审关心度展开 |
| 收口 | 复述结论 → 未决项 → 邀请异议 → 定时间 |
| 上会前 | 15 条自检 + 3 位预审 |
