技术方案的两种失败
我评审过大量技术方案，失败的无外乎两种：
失败一：写成代码解说。通篇「我们定义了一个接口、建了三张表」，读完不知道为什么要做这件事。评审人只能追问「所以呢？」——一次评审会开成十次。
失败二：藏着掖着。只写方案的优点，风险、代价、被放弃的方案只字不提。评审人问「为什么不用 X？」答不上来，信任当场破产。
两种失败本质是同一个问题：把方案当成了「功能说明书」，而不是「决策书」。
一句话心法
技术方案 = 在给定的业务约束下，讲清楚你要做什么决策、为什么这个决策是对的、风险是什么。
评审人要的不是细节，是判断依据。他们要能回答三个问题：该不该做？这么做行不行？出了问题怎么办？
方案的骨架（90% 场景够用）
- 摘要：一页讲完。要做什么、为什么做、怎么做、最大风险。这是给「只看一页的人」看的。
- 背景与目标：现状痛点 + 可量化目标。目标必须可衡量（P99 < 200ms、支持 5k QPS）。
- 方案对比：至少两个候选方案，用同一套维度对比（成本 / 复杂度 / 性能 / 可维护性 / 风险）。
- 推荐方案的细节：架构图 + 关键设计点。图自己画，别截图。
- 灰度与回滚：怎么发布、怎么快速回滚。
- 风险与待办：诚实列出不确定的事。
配套模板见文末链接，可以直接套。
三个常见错误与修正
错误 1：结论放在最后 评审人看到第 3 页还不知道你推荐哪个。结论先行：第一页摘要直接给答案。
错误 2：只列优点不写代价 每个方案都写「不足与代价」栏。主动暴露缺点，是专业感的来源——评审人自己发现缺点，比你先说出来杀伤力大十倍。
错误 3：拿 demo 当证据 「我本地跑通了」不是方案依据。POC 数据、压测结果、真实流量回放才是。（选型方法论见《后端架构落地教程》第 1 章）
技术汇报的本质差异
对内评审、向上汇报、对外分享，说的是同一件事，但组织方式完全不同：
- 对内评审：讲风险和取舍，同行要帮你挑毛病。
- 向上汇报：讲价值和影响，老板只关心「投入产出和风险」。
- 对外分享：讲方法和教训，听众要能带走可复用的东西。
我见过太多人拿「对内评审的讲法」去做向上汇报，讲了一堆技术细节，老板一脸茫然——不是老板不懂技术，是你没讲他要听的那一层。
落地清单
- 第一页有结论（摘要四要素齐全）
- 目标可量化，非目标写清楚
- 至少两个方案，同一维度对比
- 主动列出风险与代价
- 架构图自己画
- 给「只看摘要的人」也能做决定