技术方案设计实战：从需求到可评审的方案

「方案」常常只存在于某个人脑子里：等到写代码才发现接口对不上、数据迁移没想、回滚没做。这篇给一套七段式结构、选型方法与评审纪律，让方案把风险提前暴露在纸面上，而不是线上。

一、为什么值得写：三个真实价值

技术方案文档经常被当成流程负担，但它真正的作用只有三条：对齐——把「我以为」变成「我们确认」，接口、边界、职责在写代码之前就统一；暴露——把风险提前到「改文档」的阶段，而不是「改线上数据」的阶段；留痕——半年后有人问「为什么当时这么设计」，文档就是答案。

方案的产出不是文档本身，而是一群人对同一个设计达成共识。

二、七段式结构：一份方案该有的样子

• 背景与问题：现状是什么、痛点是什么、为什么现在做——用事实而不是形容词说清动机
• 目标与非目标：要达成什么（可验证、可验收），以及明确「本次不做什么」——非目标是控制范围膨胀的关键
• 现状与约束：现有架构、数据量级、团队能力、时间与合规约束——没有约束的方案都是幻想
• 方案对比与选型：至少两个候选方案，列出评估维度并给出选择理由（不是只给结论）
• 详细设计：数据模型、接口定义、核心流程、异常处理与回滚方式
• 影响面与风险：上下游依赖、兼容性、性能、成本；每条风险配一个应对或兜底
• 排期与里程碑：拆到可验收的粒度，标注关键路径与依赖方

七段不必每段都长，但不能缺项——尤其是「非目标」和「回滚方式」，它们是最常被跳过、也最容易在事故里被追问的两段。

三、选型怎么做：维度、对比、验证

选型的质量取决于三件事：有没有比多个方案、有没有统一维度、有没有动手验证。

还有一个最有效、却最常被省略的动作：spike（原型验证）。关键不确定项——某接口的真实延迟、某库的兼容性、某方案的可行性——花一两天写个最小 demo 验证，比在文档里争论一周有价值得多。文档里应写上「已验证」还是「待验证」，别让假设混进结论。

四、评审怎么开：三个问题定生死

评审的目标不是「批准」，而是找出方案里没说清或想错了的地方。三个问题几乎能覆盖八成风险：这个方案解决了什么、没解决什么？（目标与非目标是否认）最坏情况是什么、怎么退？（回滚与兜底）有没有更简单的做法——不做会怎样？（防止过度设计）。

评审的纪律同样重要：文档提前发、会上只读不念、时间花在分歧点上。把「逐页朗读」的评审会砍掉，能省下团队一半的会议时间。

五、粒度：别用一套流程管所有变更

• 一天的小需求：口头对齐加三行要点，别写文档
• 一周的中等变更：一段式方案——问题、方案、影响面，各一段
• 跨团队或动数据的大变更：完整七段 + 评审 + 小范围试点；动数据的必须写清迁移与回滚

判断标准很简单：变更的影响面越大、越难回退，方案就该越详细。

六、五个常见坑

• 没有非目标：范围一路膨胀，评审时才发现「顺便把 XX 也改了吧」
• 只给一个方案：评审退化成「批准或否决」，没有真正比较与权衡
• 忽略数据迁移与回滚：上线当晚才发现退不回去，只能硬着头皮往前修
• 排期靠感觉：没拆到可验收的粒度，里程碑全是「开发中」
• 方案写完就锁抽屉：实施过程中偏离了设计却没人更新，文档从此失去参考价值

七、让方案成为资产，而不是一次性作业

三个小机制就能做到：模板化（把七段结构做成模板，放在代码仓库的 docs/design/ 下，和代码一起版本管理）；记 ADR（架构决策记录——一条两百字，记「选了什么、为什么、代价是什么」，比翻聊天记录高效得多）；实施后回写（哪些假设被推翻、哪些妥协留了下来），让下一份方案的起点更高。

# ADR-014 订单表拆分方案
- 状态：已采纳（2026-09-20）
- 决策：按 user_id 哈希分 8 表，而非按时间分表
- 原因：查询 95% 带 user_id；按时间分表会让单用户历史查询跨表
- 代价：跨用户统计需异步汇总，实时性从秒级降到分钟级
- 备选：按时间分表（否决：跨表查询多）；不改（否决：单表将超 20 亿行）

速查卡

写在最后

方案的本质是把风险从线上提前到纸面：多想一天，少改一周。它不需要写得漂亮，只需要把「目标、非目标、取舍、风险、怎么退」讲清楚——剩下的交给评审去挑刺。写方案的能力，本质是「把不确定讲清楚」的能力，而这个能力会随时间复利。