1. 三份文档到底在解决什么问题很多刚接触软件工程文档体系的朋友一看到“需求分析说明书、概要设计说明书、详细设计说明书”这三个词第一反应就是头大——名字长得差不多内容好像也互相重叠到底谁该写什么、写到什么颗粒度、给谁看完全是一笔糊涂账。我见过不少项目组要么把三份文档写成同一份东西换个封面要么干脆只写一份“设计文档”糊弄过去最后开发阶段返工、测试阶段扯皮、验收阶段被卡根子往往就出在这里。先把这三份文档的定位用一句话说清楚需求分析说明书回答“做什么”概要设计说明书回答“怎么做分几块做”详细设计说明书回答“每一块具体怎么实现”。这三者是一条从抽象到具体、从业务到代码的逐级收敛链路每一级都在给下一级划定边界同时也在给上一级做可验证的落地承诺。我习惯用一个盖房子的类比来解释。需求分析说明书就是业主跟设计师说“我要一栋三层小楼要有四个卧室、两个卫生间、一个能停两辆车的车库预算控制在某个范围内”——这里描述的是目标和约束不涉及用什么砖、什么梁。概要设计说明书就是设计师给出的方案主体采用框架结构一层是客厅加车库二层是卧室区三层是书房加露台水电怎么走主干线承重墙分布在哪里——这是结构和模块划分。详细设计说明书则是施工图每根梁的截面尺寸、每根钢筋的型号和绑扎方式、每个插座的精确位置和线径——这是可直接施工的细节。为什么很多团队写不好这三份文档核心原因有两个。第一是没有建立“读者意识”。需求分析说明书的主要读者是业务方、产品经理和测试人员他们关心的是功能是否覆盖、流程是否闭环、边界是否清晰概要设计说明书的主要读者是架构师、技术负责人和高级开发他们关心的是模块划分是否合理、接口是否稳定、技术选型是否匹配详细设计说明书的主要读者是一线开发和单元测试人员他们关心的是类怎么设计、方法怎么签名、异常怎么处理、数据库字段怎么定义。读者不同写作的颗粒度和语言风格就必须不同。第二个原因是没有建立“追溯意识”。三份文档不是孤立的需求分析说明书里的每一条需求都应该能在概要设计里找到对应的模块承接在详细设计里找到对应的实现方案。反过来详细设计里的每一个类、每一张表都应该能追溯到某条需求。这条追溯链断了就会出现“需求漏做”“功能多做”“设计跟需求对不上”的经典问题。我在实际项目里推过一个很土但很有效的办法给每条需求编一个唯一编号比如 REQ-001然后在概要设计和详细设计里都标注“本模块对应 REQ-001、REQ-003”评审的时候顺着编号查一查一个准。下面这张表可以先帮你快速建立三份文档的全局认知维度需求分析说明书概要设计说明书详细设计说明书核心问题做什么分几块做、怎么衔接每块具体怎么实现主要读者业务方、产品、测试架构师、技术负责人一线开发、单测人员抽象层级业务级系统级代码级典型内容功能列表、流程、边界架构图、模块划分、接口类图、方法签名、表结构变更成本极高高中评审重点完整性、一致性合理性、可扩展性可实现性、可测试性理解了这三份文档各自的定位和相互关系后面的样例拆解才有意义。接下来我会按“需求分析—概要设计—详细设计”的顺序逐份拆解每份文档的核心章节该怎么写、常见坑在哪里、有没有可以直接抄的模板结构。2. 需求分析说明书的样例骨架与写法拆解2.1 一份合格的需求分析说明书长什么样需求分析说明书最容易犯的毛病是写成“功能清单”——把用户提的需求一条条列出来就完事。这种文档看着挺全实际上没法用因为它缺少了需求分析最核心的动作把模糊的业务诉求翻译成清晰、可验证、无歧义的软件需求。我手里有一份用了很多年的需求分析说明书骨架章节结构大致是这样的引言目的、范围、术语定义、参考资料、总体描述产品定位、用户特征、运行环境、约束假设、具体需求功能需求、非功能需求、接口需求、数据需求、验收标准、附录需求追溯矩阵。这个结构不是拍脑袋定的它对应的是 IEEE 830 软件需求规格说明的标准框架经过大量项目验证覆盖度是够的。其中**“具体需求”这一章是整份文档的重心**也是最能体现写作水平的地方。功能需求不能只写“系统应支持用户登录”而要写清楚谁登录角色、用什么登录账号密码/手机验证码/第三方、登录成功后发生什么跳转/发令牌/记日志、登录失败怎么处理错误提示/锁定策略/重试次数。这就是所谓的**“需求三要素”触发条件、处理逻辑、预期结果**。我见过写得最好的功能需求是用“用户故事 验收标准”的格式来组织的。比如REQ-012 用户登录作为已注册用户我希望通过账号密码登录系统以便访问我的个人数据。 验收标准输入正确的账号密码点击登录3 秒内跳转到个人主页输入错误密码页面提示“账号或密码错误”不清空已输入的账号连续 5 次输入错误密码账号锁定 15 分钟提示“账号已锁定请稍后再试”登录成功后服务端生成有效期 2 小时的会话令牌客户端存储并在后续请求中携带。这种写法好在哪好在每一条验收标准都可以直接转成测试用例。测试人员拿着这份文档就能写测试开发拿着就能估工时产品拿着就能跟业务方确认三方不用来回扯皮。2.2 非功能需求为什么最容易被漏掉功能需求大家都会写非功能需求才是真正拉开文档质量差距的地方。所谓非功能需求指的是性能、安全、可用性、可维护性、兼容性这些“不是功能但决定系统好不好用”的需求。很多项目上线后出问题不是功能没做而是非功能需求没定义清楚。举个真实的教训。之前有个项目需求文档里只写了“系统应支持用户上传头像”没写文件大小限制、没写支持的格式、没写并发上传的处理策略。上线后有人传了个 50MB 的 RAW 格式图片直接把服务拖垮了。后来补需求才把这几条加上头像文件大小不超过 5MB支持 JPG、PNG、WebP 三种格式单用户上传频率限制为每分钟 3 次上传接口 P95 响应时间不超过 800ms。非功能需求有个特点不写不会立刻出问题但一旦出问题就是大问题。所以我的经验是在需求评审阶段专门留一个环节过非功能需求清单逐项确认“这条要不要”“指标定多少”“怎么验证”。下面这张清单可以直接拿去用非功能维度需要确认的问题示例指标性能响应时间、吞吐量、并发数接口 P95 500ms支持 1000 并发安全认证、授权、加密、审计敏感字段加密存储操作留痕可用性可用率、故障恢复时间99.9% 可用故障 5 分钟内恢复兼容性浏览器、设备、系统版本支持主流浏览器最近两个大版本可维护性日志、监控、配置化关键路径打点配置不硬编码2.3 需求追溯矩阵一张表解决“需求漏做”的老大难需求追溯矩阵Requirement Traceability MatrixRTM是我强烈建议每份需求分析说明书都附上的一张表。它的逻辑很简单把每条需求从“提出”到“设计”到“实现”到“测试”串成一条线任何一环断了都能立刻发现。表格的列一般包括需求编号、需求描述、来源谁提的、优先级、对应设计模块、对应测试用例、当前状态。行就是一条条需求。评审的时候产品、开发、测试三方对着这张表过一遍谁也别想蒙混过关。我印象最深的一次是一个项目在验收前用 RTM 做自查发现有一条“用户可导出操作日志”的需求设计文档里没有对应模块测试用例里也没有覆盖。追查下去才发现这条需求在需求评审后被漏掉了开发根本不知道要做。如果没有这张表这个问题要到验收时才暴露返工成本至少翻三倍。RTM 不需要多复杂一个 Excel 或者在线表格就能维护。关键是从需求评审通过的那一刻就开始建后续每次变更都同步更新而不是等到项目结束再补——补出来的表基本没有追溯价值。3. 概要设计说明书的样例骨架与写法拆解3.1 概要设计要回答的核心问题分几块、怎么连需求分析说明书交付之后下一步就是概要设计。概要设计的核心任务可以概括成两件事把系统拆成模块把模块之间的连接关系定义清楚。拆得好后面开发顺风顺水拆得不好模块之间耦合严重改一处动全身。一份标准的概要设计说明书章节结构通常包括引言、总体设计架构风格、分层设计、部署视图、模块设计模块划分、职责定义、模块间关系、接口设计外部接口、内部接口、数据设计数据模型概览、数据流、非功能设计性能、安全、容错的架构级方案、附录。其中**“总体设计”和“模块设计”是重中之重**。总体设计要给出系统的架构图——注意这里说的架构图不是那种花里胡哨的装饰图而是能说清楚“系统分几层、每层干什么、层与层之间怎么调用”的实用图。比如一个典型的 Web 应用可以分成接入层、应用层、领域层、数据层每层的职责和依赖方向都要明确。模块设计则要把每个模块的职责边界写清楚。什么叫职责边界清楚就是这个模块该做什么、不该做什么一眼能看明白。我常用的判断标准是如果一个模块的职责描述里出现了“并且”“同时”“还负责”这类词大概率是职责没拆干净。比如“用户模块负责用户注册、登录、权限校验、消息推送”这里消息推送明显不该放在用户模块里应该独立成消息模块。3.2 模块划分的粒度怎么把握模块划分的粒度是个老大难问题。拆得太粗一个模块几百个功能维护起来像一团乱麻拆得太细模块之间调用关系复杂光理清依赖就要半天。我的经验是遵循**“高内聚、低耦合”**原则具体落地时可以问自己三个问题第一这个模块能不能用一句话说清楚它是干什么的如果一句话说不清说明职责太杂该拆。第二修改这个模块的功能时会不会经常需要同时改另一个模块如果会说明这两个模块耦合太紧要么合并要么重新划边界。第三这个模块能不能独立测试如果一个模块必须依赖其他五个模块才能跑起来说明依赖太重该考虑引入接口隔离或事件解耦。举个具体的例子。一个电商系统的订单模块如果把它设计成“负责订单创建、订单支付、订单发货、订单退款、订单评价”那这个模块就太重了。更合理的拆法是订单模块只负责订单的生命周期管理创建、状态流转、查询支付逻辑放到支付模块发货逻辑放到履约模块退款逻辑放到售后模块评价逻辑放到评价模块。订单模块通过接口或事件跟这些模块交互各司其职。这样拆的好处是支付逻辑要改比如接入新的支付渠道只动支付模块订单模块不受影响履约逻辑要改只动履约模块。每个模块的变更影响面都被控制在最小范围内。3.3 接口设计概要设计里最容易被低估的部分接口设计是概要设计里技术含量最高、也最容易被敷衍的部分。很多概要设计文档里接口部分就写一句“模块 A 通过接口调用模块 B”具体接口长什么样、参数是什么、返回什么、异常怎么处理一概没有。这种文档交到开发手里开发只能自己猜猜出来的结果十有八九跟设计意图对不上。好的接口设计应该包含这些信息接口名称、功能描述、请求参数名称、类型、是否必填、说明、响应参数、错误码、调用示例。如果是内部模块间的接口还要说明调用方式同步/异步、超时设置、重试策略。我习惯用表格来呈现接口定义清晰直观。比如一个查询用户信息的接口项目内容接口名称getUserInfo功能描述根据用户 ID 查询用户基本信息请求方式同步调用请求参数userIdString必填用户唯一标识响应参数userNameString、emailString、statusInteger错误码USER_NOT_FOUND用户不存在、PARAM_INVALID参数非法超时设置3 秒重试策略不重试查询类接口失败由调用方决定是否重试接口设计还有一个容易被忽略的点版本管理。接口一旦发布就可能被多个调用方依赖后续要改就得考虑兼容性。我的做法是接口路径里带版本号比如/api/v1/user/info新增字段保持向后兼容删除或修改字段必须升版本。这样老调用方不受影响新调用方用新版本平滑过渡。3.4 数据设计概要阶段要定到什么程度概要设计阶段的数据设计不需要细到每个字段的类型和长度但核心数据实体和它们之间的关系必须定下来。具体来说要回答这几个问题系统有哪些核心数据实体每个实体的关键属性是什么实体之间是一对一、一对多还是多对多数据的主要流向是怎样的比如一个内容管理系统核心实体可能有用户、文章、分类、标签、评论。用户和文章是一对多一个用户写多篇文章文章和分类是多对一一篇文章属于一个分类文章和标签是多对多一篇文章可以有多个标签一个标签可以属于多篇文章文章和评论是一对多。这些关系定下来后面详细设计阶段建表就有了依据。概要设计阶段还要考虑数据量和增长趋势。如果预估某个表一年内会到千万级那分库分表或者引入缓存就要在概要设计里提出来不能等到详细设计甚至开发阶段才想。我见过一个项目用户表设计的时候没考虑增长上线半年到了几百万行查询开始变慢才回头做分表代价比一开始就设计好大得多。4. 详细设计说明书的样例骨架与写法拆解4.1 详细设计的颗粒度写到开发能直接照着编码详细设计说明书的目标读者是一线开发所以它的颗粒度标准只有一个开发拿着这份文档不需要再问设计者任何问题就能直接开始编码。这个标准听起来简单做起来很难因为它要求设计者把每一个类、每一个方法、每一张表、每一个异常分支都想清楚。一份完整的详细设计说明书通常包含这些章节引言、模块概述本模块在系统中的位置和职责、类设计类图、类职责、关键属性、方法设计方法签名、参数说明、处理逻辑、异常处理、数据库设计表结构、索引、SQL 示例、界面设计如涉及、单元测试要点。其中类设计和方法设计是核心。类设计要给出类图说明每个类的职责、关键属性、与其他类的关系继承、组合、依赖。方法设计要逐个说明每个方法的签名、入参、返回值、处理逻辑和异常情况。我举个具体的例子。假设要设计一个“订单创建”功能详细设计里应该有这样的内容类设计OrderController接收 HTTP 请求参数校验调用 ServiceOrderService订单创建的核心业务逻辑事务控制OrderRepository订单数据的持久化操作InventoryService库存扣减外部依赖Order订单实体类。方法设计以OrderService.createOrder为例项目内容方法签名Order createOrder(CreateOrderRequest request)入参request包含 userId、items商品列表、addressId返回值创建成功的 Order 对象含订单号处理逻辑1. 校验参数2. 查询商品信息3. 计算总价4. 扣减库存5. 生成订单号6. 保存订单7. 返回订单异常处理库存不足抛InventoryShortageException参数非法抛InvalidParamException保存失败抛OrderCreateFailedException事务边界扣减库存和保存订单在同一事务内任一失败整体回滚这种颗粒度的详细设计开发拿到手基本就是“翻译”工作了——把设计文档里的逻辑翻译成代码。当然实际项目中不一定每行逻辑都写这么细但关键路径、复杂逻辑、异常分支必须写清楚这些地方最容易出问题。4.2 数据库表结构设计字段、类型、索引一个都不能少详细设计阶段的数据库设计要细到每个字段的名称、类型、长度、是否为空、默认值、注释以及索引的设计。这些信息直接决定了建表语句怎么写也直接影响后续的查询性能。我见过太多项目表结构设计就写个表名和几个字段名类型全靠开发自己定。结果同一个字段有的地方用varchar(50)有的地方用varchar(255)有的地方允许为空有的地方不允许索引更是想起来才加。这种随意性带来的问题在数据量小的时候看不出来数据量一大就集中爆发。一份规范的表结构设计应该长这样字段名类型允许空默认值说明idbigint否自增主键order_novarchar(32)否无订单号唯一索引user_idbigint否无用户 ID普通索引total_amountdecimal(10,2)否0.00订单总金额statustinyint否0订单状态0 待支付1 已支付2 已取消created_atdatetime否CURRENT_TIMESTAMP创建时间updated_atdatetime否CURRENT_TIMESTAMP ON UPDATE更新时间索引设计也要写清楚哪些字段建唯一索引哪些建普通索引哪些建联合索引联合索引的字段顺序是什么。索引不是越多越好每个索引都会增加写入成本所以要根据实际查询场景来定。比如订单表经常按user_id查也经常按order_no查那就给这两个字段分别建索引如果经常按user_id status联合查询那就建联合索引(user_id, status)注意字段顺序要把区分度高的放前面。4.3 异常处理与边界条件详细设计里最见功力的地方异常处理和边界条件是详细设计里最能体现设计者经验的地方。新手设计者往往只考虑“正常流程怎么走”老手会把“异常情况怎么处理”也想清楚。因为实际运行中异常情况的出现频率远比想象中高。以“订单创建”为例需要提前想清楚的异常和边界包括用户不存在或已被禁用怎么处理商品已下架或库存不足怎么处理收货地址不属于该用户怎么处理订单金额计算出现精度问题怎么处理扣减库存成功但保存订单失败怎么回滚同一用户短时间内重复提交怎么防重每一个问题详细设计里都要给出明确的处理方案。比如防重提交可以用“用户 ID 商品 ID 时间窗口”做幂等键在 Redis 里设置短过期时间重复请求直接返回上次结果。这些方案写进详细设计开发就不用自己拍脑袋决定了。我的经验是详细设计评审的时候专门花时间过一遍异常和边界清单让测试人员也参加。测试人员对异常场景的敏感度往往比开发高他们提出的问题经常能补上设计者的盲区。这个环节花的时间会在开发和测试阶段成倍省回来。4.4 详细设计要不要写伪代码关于详细设计要不要写伪代码业内一直有争议。我的观点是看逻辑复杂度。简单的 CRUD 逻辑用文字描述就够了写伪代码反而啰嗦复杂的算法、状态机、并发控制逻辑伪代码能极大降低理解成本该写就写。比如一个订单状态流转的逻辑用文字描述可能是“订单从待支付状态在支付成功后变为已支付在超时未支付后变为已取消在用户主动取消后变为已取消”读起来就有点绕。用状态机图或者伪代码表示一目了然状态待支付 事件支付成功 - 状态变为已支付 事件超时30分钟 - 状态变为已取消 事件用户取消 - 状态变为已取消 状态已支付 事件发货 - 状态变为已发货 事件退款 - 状态变为已退款 状态已发货 事件确认收货 - 状态变为已完成这种表达方式开发一看就懂测试也能直接照着设计用例。伪代码不是必须的但当逻辑复杂到文字说不清楚的时候它就是最好的沟通工具。5. 三份文档的衔接与常见踩坑复盘5.1 从需求到概要到详细追溯链怎么建三份文档写完之后最关键的一步是建立它们之间的追溯关系。这个关系建不起来三份文档就是三座孤岛评审的时候各看各的出了问题互相甩锅。追溯链的建立方法不复杂核心就是编号 引用。需求分析说明书里每条需求有唯一编号REQ-XXX概要设计说明书里每个模块标注它承接了哪些需求编号详细设计说明书里每个类或方法标注它实现了哪个模块的哪个部分。这样从需求出发能一路查到代码从代码反查也能一路追溯到需求。我通常会在概要设计和详细设计的文档开头放一张追溯表把“需求编号—设计模块—详细设计章节”的对应关系列出来。评审的时候评审人拿着这张表抽查几条就能判断追溯链是否完整。需求编号需求描述概要设计模块详细设计章节REQ-001用户注册用户模块3.1 用户注册类设计REQ-002用户登录用户模块3.2 用户登录类设计REQ-012订单创建订单模块4.1 订单创建类设计REQ-013订单支付支付模块5.1 支付流程设计这张表还有一个好处需求变更时能快速评估影响面。比如 REQ-012 要改一看表就知道要动订单模块的详细设计再顺着模块看依赖就能评估出改动范围。5.2 文档评审最容易吵起来的几个点文档评审是团队协作里最容易产生分歧的环节。根据我的观察吵架最集中的地方有这么几个第一颗粒度之争。开发觉得详细设计写得太粗“这跟没写一样”设计者觉得写得太细“我都能写代码了还要你干嘛”。这个矛盾的根源是没有提前对齐颗粒度标准。我的做法是在项目启动时就明确详细设计写到方法签名和关键逻辑具体代码实现由开发负责。标准定在前面评审时就按标准来少很多扯皮。第二技术选型之争。概要设计里提到用某个技术方案有人觉得另一个方案更好争论不下。这种争论往往是因为没有把选型依据写清楚。如果设计文档里写明了“选 A 方案是因为它在 X 场景下性能比 B 高 30%且团队已有相关经验”争论就会聚焦在依据是否成立上而不是各说各话。第三需求理解之争。需求分析说明书里某条需求写得模糊开发和测试理解不一致。这种问题的解法是在需求评审时就把模糊点澄清澄清结果写回文档。我习惯在需求文档里维护一个“待澄清问题”清单评审时逐条过澄清一条划掉一条确保没有遗留。5.3 文档写完就过时版本管理得跟上“文档写完就过时”是很多团队的常态。需求变了文档没更新设计改了文档还是老版本。时间一长文档就没人看了因为大家都知道它不准。解决这个问题靠的不是自觉而是机制。我的做法有这么几条文档和代码同仓库管理。文档用 Markdown 写跟代码放在同一个 Git 仓库里改代码的时候顺手改文档提交记录里能看到文档变更。变更必须同步文档。需求变更流程里加一步变更评审通过后责任人必须在规定时间内更新对应文档更新完才能进入开发。定期文档巡检。每个迭代结束前花半小时对照代码检查文档是否一致发现不一致立即修正。这些机制听起来有点繁琐但比起文档失准带来的沟通成本和返工成本这点投入完全值得。我待过的一个团队坚持文档和代码同步更新两年后来新成员入职看文档就能快速上手老成员查历史设计翻文档就能找到依据整体效率提升非常明显。5.4 小团队要不要写这么细经常有人问我们团队就三五个人也要写这么细的三份文档吗我的回答是形式可以简化但核心内容不能省。小团队可以不写完整的正式文档但至少要有一份“需求清单 设计要点”的合并文档把“做什么、分几块、关键实现”说清楚。需求清单可以简单到用在线表格维护设计要点可以写在代码仓库的 README 或者 Wiki 里。关键是信息要沉淀下来不能只存在于某个人脑子里。我见过一个小团队三个人开发一个内部工具没写正式文档但他们在代码仓库里维护了一份DESIGN.md里面用简短的条目记录了每个模块的职责、关键接口、数据库表结构。这份文档不到两千字但新成员来了看一遍就能上手需求变更时也有据可查。这就是“轻量但有效”的文档实践。反过来我也见过大团队写了几百页文档但没人看、没人维护最后变成摆设。文档的价值不在于厚度而在于是否被使用、是否准确、是否及时更新。三份文档的样例骨架和写法核心是帮你建立“分层思考、逐级收敛、全程追溯”的工作习惯具体写多细、用什么形式完全可以根据团队规模和项目特点灵活调整。6. 可直接复用的文档模板结构6.1 需求分析说明书模板目录下面这份目录结构可以直接拿去用按项目实际情况增删章节即可1. 引言 1.1 编写目的 1.2 项目背景 1.3 术语定义 1.4 参考资料 2. 总体描述 2.1 产品定位 2.2 用户特征 2.3 运行环境 2.4 约束与假设 3. 功能需求 3.1 功能模块一REQ-001 ~ REQ-00X 3.2 功能模块二 ... 4. 非功能需求 4.1 性能需求 4.2 安全需求 4.3 可用性需求 4.4 兼容性需求 5. 接口需求 5.1 外部接口 5.2 内部接口 6. 数据需求 6.1 数据实体 6.2 数据流 7. 验收标准 8. 附录 8.1 需求追溯矩阵 8.2 待澄清问题清单6.2 概要设计说明书模板目录1. 引言 1.1 编写目的 1.2 参考文档 1.3 术语定义 2. 总体设计 2.1 架构风格 2.2 分层设计 2.3 部署视图 2.4 技术选型与依据 3. 模块设计 3.1 模块划分总览 3.2 模块一设计职责、依赖、承接需求 3.3 模块二设计 ... 4. 接口设计 4.1 外部接口 4.2 内部接口 5. 数据设计 5.1 核心数据实体 5.2 实体关系 5.3 数据流 6. 非功能设计 6.1 性能方案 6.2 安全方案 6.3 容错方案 7. 附录 7.1 需求追溯表6.3 详细设计说明书模板目录1. 引言 1.1 编写目的 1.2 参考文档 2. 模块概述 2.1 模块职责 2.2 模块在系统中的位置 3. 类设计 3.1 类图 3.2 类职责说明 3.3 关键属性 4. 方法设计 4.1 方法一签名、参数、逻辑、异常 4.2 方法二 ... 5. 数据库设计 5.1 表结构 5.2 索引设计 5.3 SQL 示例 6. 界面设计如涉及 7. 单元测试要点 8. 附录 8.1 异常与边界清单 8.2 设计决策记录这三份模板不是让你照搬而是给你一个起点。实际使用时根据项目类型Web 应用、移动端、后台服务、数据处理等和团队习惯做调整。比如移动端项目要增加“界面设计”章节数据处理项目要增加“算法设计”章节后台服务要增加“并发与线程模型”章节。模板的价值在于帮你建立结构化的思考框架而不是限制你的表达。当你对三份文档的定位和写法都烂熟于心之后完全可以打破模板用最适合当前项目的方式组织内容。但在那之前先照着模板写几遍把基本功练扎实比什么都重要。