1. 为什么多数技术方案写完就“废”了
我接触过大量技术方案，有团队内部的、跨部门的，也有面向客户交付的。一个很残酷的现状是：大部分方案在评审会结束那一刻就完成了它的历史使命，后续开发根本不按方案走，或者走到一半发现走不下去，然后开始“边做边改”。你要是追问一句“当初方案里不是写了吗”，得到的回答通常是“方案是方案，实现是实现”。
问题不在写方案的人水平差，而在于多数方案从一开始就不是奔着“可实施”去写的。
很多技术方案的写作动机是“走流程”。架构组要求立项必须有方案，那就写一份；客户要求交付物里有设计文档，那就补一份。这种方案的核心目标是“看起来完整”，于是大量篇幅花在背景介绍、行业趋势、技术选型对比上，真正落到“这个模块到底怎么改、数据怎么流、失败怎么办”的部分反而一笔带过。评审专家想看的执行细节没有，不想看的空话倒是一大堆。
另外一个大问题是方案与技术栈、与代码现状脱节。写方案的人凭理想中的架构画图，不翻现有工程的实际代码，不看数据库里真实的表和字段，不考虑当前团队的技术水平。画出来的架构图漂漂亮亮，一落到代码层面全是“此路不通”。
还有一个很隐蔽的原因：方案的验证闭环缺失。方案写完，没有定义“怎么算成功”。没有量化指标，没有验收标准，没有上线后的回归方案，于是开发做到哪算哪，测试凭感觉验，上线后有没有达到预期没人知道。方案自然就成了一纸空文。
所以我想给的不是一个“看起来专业”的模板，而是一个能把“方案”变成“施工图”的框架。它不追求辞藻华丽，只追求一件事：任何一个拿到这份方案的人——不管是三个月后的新同事，还是没参加过评审的运维——都能按图索骥，知道每一步该干什么，每一处风险在哪兜底。
下面这套结构，是我在多次方案评审和落地复盘之后沉淀出来的，踩过不少坑，也为此重写过好几版方案。直接拿去用，按自己的业务场景增减即可。
2. 可实施技术方案的核心骨架：六段式结构拆解
一份能落地的技术方案，骨架必须清晰。我把它拆成六个部分，顺序基本固定，但每个部分的篇幅可以按项目性质调整。内部工具改造可能“背景与目标”几百字就够，核心在“详细设计”；面向客户的交付方案则要在“背景”和“约束”上多花笔墨。
2.1 背景、目标与边界：先把“为什么做”钉死
第一个部分不是写行业趋势，而是写清楚：当前系统遇到了什么具体问题，这个问题影响多大，这次改造要解决到什么程度。我见过太多方案在这里写成“为了提升系统稳定性，增强用户体验”这类正确的废话。正确的写法是给出可验证的事实，比如：
“当前订单表数据量已超过8000万行，按月增长的速率约为每月300万行。订单查询接口P95响应时间从年初的120ms劣化到现在的480ms，经排查主要瓶颈集中在订单表全表扫描和索引命中率下降。本次改造的目标是将订单类慢查询的P95响应时间降到200ms以内。”
目标也要拆成两层：业务目标和IT目标。业务目标面向业务方，讲价值和收益；IT目标面向研发，讲指标和指标值。两层都要写，缺一不可。只有业务目标没有IT目标，开发不知道做到什么程度算完；只有IT目标没有业务目标，业务方不知道你为什么要动这个系统，评审自然通不过。
边界同样要在开头就划清楚。这次改造动哪些服务、不动哪些服务；哪些接口在范围内，哪些明确不在范围内。边界模糊是范围蔓延的温床，写着写着就把“顺手优化”的东西也塞进来，最后交付周期失控，质量也没法保障。
2.2 现状分析与约束盘点：动手设计前的必修课
可实施的方案必须基于现状，而不是基于想象。现状分析不是简单贴一张系统架构图，而是要跑到代码里、数据库里、监控系统里把事实捞出来。
我一般在写方案前会强制自己回答下面这些问题：
- 当前的核心调用链路是什么？画出来，标注每个环节的耗时占比。
- 现有数据库的表结构长什么样？数据量多大？增长趋势如何？索引情况如何？
- 核心接口的调用方有哪些？有没有外部系统依赖？依赖的协议和鉴权方式是什么？
- 现有的缓存、消息队列、定时任务等基础设施的使用情况和容量余量如何？
- 团队对这套代码的熟悉程度如何？有没有历史包袱和已知的技术债？
这些内容不需要全部写进方案正文，但方案里的设计决策必须建立在这些事实之上。方案里要呈现的“现状分析”部分，聚焦在影响本次改造决策的关键事实上即可，但要注明这些事实的数据来源和采集时间，让评审者可以复核。
约束条件也要在这一节列全。时间约束、人力约束、预算约束、合规约束、兼容性约束，越早摆上桌面越好。方案最大的风险不是技术风险，而是在错误的前提下发散设计。把约束写清楚，评审时才能聚焦在约束下找最优解，而不是吵方案本身。
2.3 总体架构设计：用一张图和一段话讲清楚方案骨架
架构设计不是越多图越好，而是要让评审者在30秒内听明白你的思路。我习惯用“一张核心架构图 + 一段不超过300字的设计概述”来支撑这个部分。
架构图只画本次改造涉及的关键组件、调用关系和部署形态。重点标注数据流方向，以及涉及改造的部分用明显颜色标出来，涉及新引入的组件也要标注用途。避免把整个系统全部画进去，外围系统用统一的、淡淡的方式表示即可。图画完自己检查一遍：如果跳出三界外不在五行中的评审者也能看懂图和数据流，这张图才算合格。
设计概述要讲清楚核心思路。举个例子：“本次改造采用‘读写分离 + 本地缓存’的组合策略。订单查询流量先命中应用本地缓存，未命中再查只读副本，主库只承接写入和强一致性查询。数据同步采用DTS实时同步到只读副本，延迟控制在秒级以内。”这就是一个清晰的设计概述，有思路、有手段、有参数，评审者一听就知道你要干什么。
2.4 详细设计与核心流程：把每个步骤落到可执行
这是方案能否“可实施”的分水岭。详细设计不是把架构图再贴一遍，而是把每个模块、每条链路、每个关键场景的加工逻辑写清楚。
我自己的经验是，详细设计至少要覆盖以下内容：
- 模块级设计：每个涉及的模块或服务，改造前做了什么、改造后做什么、接口签名是否有变化。
- 数据模型设计：新增表或字段的DDL，索引设计，数据迁移方案和回退方案。
- 接口设计：新增/变更接口的入参、出参、错误码、超时设置、幂等策略、限流策略。
- 核心流程时序：用文字或伪代码描述关键业务场景的完整处理流程，包含异常分支和兜底逻辑。
- 配置项清单：涉及哪些配置项，新老配置的切换逻辑，配置变更是否走配置中心。
这块内容写不写得具体，直接决定开发拿到方案后能不能动手。我见过太多方案的“详细设计”只是把架构图放大了一点，然后加了几行描述——那等于什么都没写。真正可实施的详细设计，开发照着写代码时不需要再问产品经理和架构师“这个地方怎么处理”。
用伪代码描述核心流程是一个容易被忽视但非常有效的做法。比如要写清楚一个订单超时关单流程，与其用大段文字描述，不如直接写一段伪代码，把状态流转、时间条件、异常处理表达清楚。伪代码不需要能运行，但逻辑要完整，所有分支要覆盖到。写不出来的地方，就是设计还没想清楚的地方，趁早暴露。
2.5 风险清单与预案：把“如果…怎么办”从口头变成书面
评审会上最常被问到的问题就是“假如XXX失败了怎么办”。方案里提前把这些场景列清楚，既能体现思考深度，也能减少评审中的反复拉扯。
风险清单不要写“存在一定风险”这种空话，要具体到场景。比如：
- 数据迁移过程中源表有写入怎么办？（迁移工具是否支持增量同步，是否有校验和补偿机制）
- 缓存服务不可用，流量全部打到数据库，数据库能扛多久？（是否有熔断降级）
- 新老接口切换后，发现有少量调用方没适配新协议怎么办？（是否保留老接口兼容期，兼容期多长）
- 上线后发现核心接口性能指标没有达到目标怎么办？（是否有快速回滚方案，回滚窗口多久）
每个风险要写清楚四个方面：触发条件、影响范围、检测方式、应对预案。预案不能是“紧急修复”，要有具体的操作步骤和责任人。预案只有写清楚到“谁在什么时间执行什么命令”的颗粒度，才是可执行的预案。
2.6 实施排期与验证计划：让方案从“设计”走向“落地”
没有排期的方案永远是空中楼阁。实施排期要把整个改造拆成里程碑，每个里程碑有明确交付物和验证方式。拆分颗粒度以“天”为单位比较合适，太粗了没法跟踪，太细了管理成本高。
排期至少包含以下阶段：环境准备、数据迁移、代码开发、联调测试、性能压测、灰度发布、全量切换、观察期。每个阶段要有明确入口条件和出口条件，出口条件最好能量化。
验证计划跟目标定义区隔开：定义目标时是“定方向”，验证计划是“定标准”。验证计划要写清楚每个验证项用什么工具压、压到什么量级、看哪些指标、阈值是多少。比如“对订单查询接口执行3000并发、持续30分钟的压测，P95响应时间不超过200ms，错误率不超过0.1%”。这种标准写清楚后，测试团队不需要再猜。
3. 目标定义与验收标准：把“我觉得行”变成“数据说行”
很多方案写得热闹，但一到“怎么验收”就含糊其辞。没有验收标准的方案，在开发眼里就是“需求还早，先写着”。这一章节专门讲怎么把目标定义落到可量化。
3.1 用北极星指标定靶子，用反指标防副作用
我在前面提到目标要有两层：业务目标和IT目标。这里再进一层：每个目标都要对应一个可量化的指标，且这个指标必须同时考虑正向指标和反向指标。正向指标是“我们要达成的效果”，反向指标是“我们不想因为改造而变差的东西”。
举个例子。假设我们要做一次缓存改造，目标是降低数据库压力。正向指标是“数据库QPS下降30%以上”，反向指标是“缓存命中率不低于95%”和“订单查询的P95响应时间不劣于改造前”。只盯正向指标，很容易做出一个缓存了错误数据、查询走了错误路径、性能比原来更差的“成功改造”。
指标不能拍脑袋定，要基于现状数据。改造前先把关键指标的值记录清楚，作为基线。基线的采集方法和口径都要写进方案，否则上线后对比时口径不一致，容易扯皮。
3.2 验收标准要拆到功能和非功能两层
验收标准直接落到功能验收和非功能验收两个清单。功能验收清单描述“每个功能点做什么、输入什么、期望输出什么”，颗粒度要细到一个QA能直接照着写测试用例。非功能验收清单覆盖性能、稳定性、安全性、兼容性。这里给个参考表：
| 验收项类型 | 验收项示例 | 验收标准 |
|---|---|---|
| 功能验收 | 订单查询接口在缓存命中时的返回体 | 与改造前接口返回体完全一致，字段顺序可不同但内容一致 |
| 功能验收 | 缓存未命中时触发DB查询并回填缓存 | 回填成功后在TTL内再次查询命中缓存 |
| 非功能验收 | 接口性能 | 3000并发30分钟压测下P95 ≤ 200ms，错误率 ≤ 0.1% |
| 非功能验收 | 数据一致性 | 缓存与DB数据差异不超过5秒，最终一致 |
| 非功能验收 | 可回滚性 | 保留老代码发布包，可在30分钟内完成回滚操作 |
| 非功能验收 | 兼容性 | 不强制要求调用方升级，兼容期内新旧协议并存 |
这个表是辅助，关键是每一条都要能被验证。“内容一致”怎么判定，“可回滚性”怎么验证，都要有具体方法。建议每个验收项后面加一列“验证方法”，写清楚用什么工具、看什么日志、跑什么脚本。
3.3 灰度与回滚判定，不能靠“感觉差不多”
可实施的技术方案除了要写“上线后什么时候算成功”，还要写“灰度放量的节奏和暂停/回滚条件”。灰度不是把流量切过去就完事，而是要分阶段、控制风险、有明确判定点。
我常用的灰度节奏是：第一批放5%的流量，观察30分钟，核心指标正常再放到30%，再观察、再放到100%。每个阶段入口处都要有判定标准，比如：错误率低于0.1%、P95响应时间达标、业务方确认无异常、无客户投诉。任何一个条件不满足，暂停放量并进入回滚流程。
回滚方案要具体到操作步骤。很多人写回滚就是一句“出现问题则回滚到上一版本”，这等于没写。回滚方案至少要有：回滚的操作入口在哪里、谁来执行、回滚后数据怎么处理（已写入新表的数据要不要同步回老表）、回滚后如何验证系统恢复、当初的问题会不会在回滚后仍然存在。想清楚这些，回滚方案才算完整。
4. 边界、回滚与兼容：决定方案生死的三个暗坑
这三个问题几乎每个技术方案都会碰到，但也是最容易被“写在文档角落”的部分。我专门拿出来讲，是因为它们在落地时出的问题最多。
4.1 边界不清：范围蔓延的第一大来源
前面提到开头要划边界，这里再深入说一下。边界的定义不能只在“方案开头”出现一次，而是要在每个模块设计里都体现。具体来说：
- 功能边界：哪些功能本次做，哪些不做。不做的原因要写清楚，是资源不足还是依赖前置项目。
- 数据边界：本次涉及哪些库表，哪些字段，数据流向从哪里开始到哪里结束。新增的数据落地在哪个环境、哪个集群。
- 调用边界：哪些接口允许被外部调用，哪些是内部私有接口。外部调用的鉴权方式是什么。
- 组织边界：不同团队各负责哪块，接口联调由谁主导，线上问题由谁响应。
边界写清楚还有一个好处：后期做变更评估时，能快速判断一个需求是不是已经超出原方案范围。评审时我经常问一个问题：“这个改动影响的系统边界在哪儿，边界外是否需要联调？”能答清楚这个问题的方案，通常都经过了认真思考。
4.2 回滚设计：永远假设上线会失败
我在评审时有个习惯：看到方案里没有回滚设计，就直接打回。上线失败是常态，区别只在于失败后你能不能快速恢复。回滚设计不是让大家往坏了想，而是给团队留一条保命的路。
回滚设计要分三个层面：
- 代码回滚：保留上一个稳定版本的发布包，发布系统支持一键回滚。需要确认回滚时数据库的兼容性，比如新代码用了新字段，回滚后老代码不认这个字段，会不会出问题。
- 数据回滚：涉及数据迁移、表结构变更的改造，原始数据必须有备份。迁移脚本要可逆向执行。这里尤其提醒：数据库的变更脚本，永远不要只写前向的“加字段”，有条件就写逆向的“删字段”或“兼容策略”。
- 配置回滚：开关类配置要支持动态切换，能在不停机的情况下把流量切回老链路。
回滚方案的定义粒度要到“操作步骤”，而不是只有一句话。我通常会在方案里加一张“回滚执行清单”的表格，列清楚步骤顺序、操作指令、执行人和预计耗时。没有人喜欢写这个，但出事的时候你会发现它是全团队最值钱的一张纸。比如：
| 步骤 | 操作内容 | 执行人 | 预计耗时 |
|---|---|---|---|
| 1 | 暂停灰度放量，将流量全部切回老集群 | 运维A | 5分钟内 |
| 2 | 执行数据库逆向脚本：删除新字段、恢复旧索引 | DBA B | 15分钟内 |
| 3 | 回滚应用至上一稳定版本 | 运维A | 10分钟内 |
| 4 | 验证订单主链路：创建订单、查询订单 | 测试C | 10分钟内 |
4.3 兼容性设计：改造不是“你迁就我，而是大家都不难受”
兼容性分两层：接口兼容和数据兼容。
接口兼容主要指对外提供的API，特别是面向第三方、面向客户的接口。任何破坏性变更都必须有兼容期。常见做法是接口版本化，旧版本保留一段时间，新版本并行上线。兼容期的长度取决于调用方的改造周期，这个时间要跟业务方、客户成功团队确认，不能一人拍板。
字段级别的兼容也要注意，新增字段没问题，但修改字段含义、修改枚举值、改变响应里的类型，都可能导致调用方解析失败。兼容性不好的接口上线后，线上告警会告诉你什么叫“牵一发动全身”。
数据兼容主要指新老数据能否共存、能否互转。比如你改造了订单状态的枚举值，老数据里存的“1”代表“待支付”，新代码里“1”可能变成了“已取消”。这类改造如果不在方案里专门设计数据映射和清洗迁移策略，上线当夜就会遇到线上数据错乱的问题。
一个好的做法是：在设计阶段就用一张“兼容性检查表”过一遍改造点，逐项记录是否影响现有调用方、是否有兼容方案、兼容期多长。这张表跟着方案一起评审，比评审后再补漏要高效得多。
5. 可直接套用的完整模板：把前面所有方法论装进一张图
前面讲了很多原则和方法，这一章给一个可以直接拿去填空的模板。模板的主体就是一份可以在项目里直接复制使用的技术方案骨架，配合一个真实的示例片段来说明每个环节应该写什么、写到什么程度。
5.1 模板正文
我将这份模板设计成Markdown格式，方便在各大团队协作平台直接使用。关键原则是：每个部分要回答明确的问题，而不是泛泛而谈。
# 技术方案：<项目名称> | 字段 | 内容 | | --- | --- | | 方案作者 | <姓名> | | 创建日期 | <YYYY-MM-DD> | | 评审参与人 | <列出需要评审的角色> | | 方案状态 | 草稿 / 待评审 / 已评审 / 已实施 | | 关联需求 | <需求单号或Jira链接> | ## 1. 背景与目标 ### 1.1 现状与问题 - 当前系统的关键事实描述（数据量、耗时、故障记录等，附数据来源和采集时间） - 问题影响面：影响哪些用户/业务，影响程度如何 ### 1.2 目标定义 | 目标类型 | 量化指标 | 当前基线 | 目标值 | 数据来源 | | --- | --- | --- | --- | --- | | 业务目标 | <可量化的业务效果> | <基线> | <目标> | <从哪来> | | IT目标 | <可量化的技术指标> | <基线> | <目标> | <从哪来> | | 反指标 | <不可变差的指标> | <基线> | <阈值> | <从哪来> | ### 1.3 边界范围 - 范围内：<本次改造涉及的模块、接口、数据、团队> - 范围外：<明确不做的内容，附原因> ## 2. 总体方案 ### 2.1 设计概述 <不超过300字，说清楚核心设计思路、关键选型、数据流转方式> ### 2.2 架构图 <核心架构图，标注改造点和数据流方向> ### 2.3 技术选型 | 组件/方案 | 选型 | 选型理由 | 备选方案 | 未选原因 | | --- | --- | --- | --- | --- | | <eg. 消息队列> | <eg. RocketMQ> | <eg. 团队已有运维经验> | <eg. Kafka> | <eg. 运维成本高> | ## 3. 详细设计 ### 3.1 模块改动清单 | 模块/服务 | 改动类型 | 改动内容 | 涉及接口 | 兼容性方案 | | --- | --- | --- | --- | --- | | <服务A> | 新增 / 修改 / 删除 | <具体的改动描述> | <接口和版本> | <兼容说明和周期> | ### 3.2 数据模型设计 - 新增表/字段 DDL - 索引设计 - 数据迁移方案（迁移工具、增量处理、校验方式、回退方案） - 数据生命周期（保留周期、归档策略） ### 3.3 核心流程 <对关键业务场景用文字描述整体时序，必要时用伪代码表达，必须覆盖异常分支> ### 3.4 配置项清单 | 配置项 | 环境 | 原值 | 新值 | 切换方式 | 变更时机 | | --- | --- | --- | --- | --- | --- | | <配置名> | <dev/test/prod> | <原值> | <新值> | <动态发布/重启生效> | <上线阶段> | ## 4. 风险与预案 | 风险场景 | 触发条件 | 影响范围 | 检测方式 | 应对预案 | 责任人 | | --- | --- | --- | --- | --- | --- | | <风险描述> | <何时发生> | <影响哪些链路> | <监控/告警项> | <具体操作步骤> | <角色> | > 注意：应对预案要具体到“谁在什么时间执行什么操作”的颗粒度，而不是“紧急处理”。 ## 5. 实施排期与验证 ### 5.1 里程碑排期 | 里程碑 | 交付物 | 开始时间 | 结束时间 | 出口条件 | | --- | --- | --- | --- | --- | | <eg. 环境准备> | <环境清单> | <日期> | <日期> | <可量化的完成标准> | ### 5.2 功能验收清单 | 编号 | 功能点 | 操作步骤 | 期望结果 | | --- | --- | --- | --- | | F1 | <功能点> | <步骤1/步骤2/...> | <可验证的结果> | ### 5.3 非功能验收清单 | 编号 | 验收项 | 验收方法 | 验收标准 | | --- | --- | --- | --- | | P1 | <性能/稳定性等> | <压测工具、压测模型> | <量化阈值> | | R1 | 回滚验证 | <执行回滚清单> | <在指定时间内恢复服务> | ### 5.4 灰度计划 | 批次 | 放量比例 | 观察时长 | 放量条件 | 暂停/回滚条件 | | --- | --- | --- | --- | --- | | 第一批 | 5% | 30分钟 | 错误率<0.1%，核心指标达标 | <明确条件> | ## 6. 附录 - 相关代码地址/PR链接 - 监控大盘链接 - 操作手册/运维手册 - 上线checklist5.2 模板使用示例：以订单超时关单改造为例
为了让模板更直观，我用一个简化的例子说明“核心流程”和“灰度计划”怎么写。
场景：现有订单超时关单依赖定时任务每分钟扫描一次超大订单表，耗时长且容易漏单。改造方案：引入延迟消息，在下单时发送一条延迟30分钟的关单消息，消息到期触发关单。
核心流程用伪代码这样写：
1. 用户提交订单成功，事务提交后： - 发送延迟消息到MQ，topic=order_close，延迟级别=30分钟 - 消息内容包含 orderId、userId、closeTime 2. 关单消费者收到到期消息： - 查询订单状态 - 若状态=待支付，则执行关单；否则丢弃消息（说明已支付或已关闭） - 若查询订单失败，则记录重试日志，重试3次（间隔1分钟/5分钟/15分钟） - 若重试仍失败，进入死信队列，触发告警，由人工介入 3. 兜底定时任务保留，改为每5分钟扫描一次“待支付且超时未关”的订单，只处理最近10分钟内未关单的订单，避免与延迟消息重复处理（重复处理通过状态判断保证幂等）灰度计划写清楚放量节奏：
| 批次 | 放量范围 | 观察时长 | 放量条件 | 暂停/回滚条件 |
|---|---|---|---|---|
| 第一批 | 10%订单开启延迟关单 | 2小时 | 死信队列无异常，关单成功率=100% | 死信数量>10则暂停并人工排查 |
| 第二批 | 50%订单开启延迟关单 | 4小时 | 关单成功率≥99.9%，定时任务扫描量下降 | 关单成功率<99.9%则全量回切定时任务 |
| 第三批 | 100%订单开启延迟关单 | 24小时 | 核心指标平稳 | 启动回滚：关闭延迟消息入口，恢复定时任务 |
这个颗粒度的方案，开发、测试、运维、业务方拿到手都能对齐预期，评审会上基本不会再出现“这里没写清楚”的质疑。
6. 评审会上没说的那些事：让方案真正过会落地的经验之谈
方案写得再完美，如果过不了评审、落不了地，一切都是白费。最后分享几个我在多年评审与落地中总结出来的实战经验。
6.1 评审前先找关键人“对答案”
不要等到评审会上才让所有人第一次看到方案。正确做法是：评审前把方案发给每个关键角色，私下先沟通一轮。架构师关心技术选型是否有坑，DBA关心数据量和索引设计，运维关心发布和回滚方案，业务方关心改造期间是否停服。每个角色的顾虑提前解答，评审会就变成了确认会，而不是辩论会。
我在评审前通常会给每个关键角色发三个问题：这份方案有没有动你的核心地盘？有没有需要你额外投入资源？有没有你不同意的地方？三个问题对齐了，评审会基本就能顺利通过。
6.2 方案里的每个“决策”都要能说出理由
评审专家最爱问的就是“为什么用A不用B”。可实施的方案里，每个关键选型都应该有一段“理由”支撑。不一定要写很多字，但必须能自圆其说。比如选型RocketMQ而非Kafka，理由是“团队已有运维经验和监控大盘”，这就够了。最怕的是“大家都用这个所以我们也用”，这种理由在评审会上一击即碎。
如果是“需求紧急，先短期方案顶上”，也要写清楚这个短期方案的技术债是什么，后续在什么条件下替换，谁来负责。诚实面对技术债，比假装没有技术债更能让评审者放心。
6.3 上线不是终点：方案的生命周期管理
最后说一个容易被忽略的点：方案通过评审、上线完成之后，这份文档还有用。新同事接手代码时靠它理解设计意图，出线上问题时靠它回溯决策过程，做技术复盘时靠它对照目标验证结果。
我的习惯是：方案上线后一个月内做一次复盘，把实际数据跟当初的目标基线做对照，写进方案附录。这个“事后回填”的动作，对方案作者的成长价值极大。你会发现很多当初以为想清楚了的地方，实际运行后根本不是那回事。把这些真实数据回填进文档，这份方案才真正完成了自己的闭环。
我现在写方案时，已经不太在意文档格式是否精美，更在意的是：评审者是否能在30分钟内理解我的设计思路，开发是否能不加思考地按图施工，误入歧途时是否有一条明确的路可以退回来。这份模板的所有设计都围绕着这三个问题展开，希望能帮你少踩一些我踩过的坑。
