前言 #
需求文档写得全不全面，其实跟经验没太大关系。写得多的人照样漏，写得少的人反而因为小心所以想得周全。区别往往在于有没有一套检查机制，把该想的点落到纸面上，而不是靠脑子硬记。
这份清单来自一次又一次的教训。评审时当场答不上来、上线后发现少考虑了兼容性、甚至漏掉过数据埋点。每踩一次坑就补一个检查项，慢慢地清单就变长了。现在写之前会过一遍，写完还会再过一遍，算是给自己的一道防线。
如果你也在经历类似的困扰，希望这份清单对你有用。
基本要素 #
开篇先把文档的基础信息补全。
文档形式：用 Word、Markdown、还是直接在高保真原型上标注，提前确定好，团队统一。
版本命名：大版本改第一位（如 1.0 → 2.0），小迭代改中间位（如 1.1 → 1.2），Bug 修复改最后位（如 1.1 → 1.1.1）。这个规范通常团队统一，但写进文档里让相关方心里有数。
需求目录：本期要做什么，分模块列出来。这就像一本书的目录，读者扫一眼就知道整体结构，后续也能快速定位。
更新记录：谁在什么时间改了什么是，每次更新都要同步。开发在用哪个版本，全靠这个记录来对齐。
全局位置：这个功能在产品全局里处于什么位置，跟其他模块是什么关系。有时候单独看一个需求没问题，放进全局就发现跟现有逻辑冲突了。
业务说明 #
这块容易被跳过。很多产品新人直接跳到功能细节，结果开发做完发现这不是自己想要的。
用一段简洁的文字说清楚：这个功能是什么、为谁解决什么问题、为什么现在要做、未来会怎么演进。
如果功能涉及跨角色协作（比如运营要在后台配置什么），把各方的职责边界也写明白。开发理解了业务目的，自己就能做很多判断，不用事事来问产品。
业务流程图是标配。一图胜千言，流程图能大幅降低需求理解偏差。宁可多画一张图，也不要用一大段文字描述一个流程。
规范与全局说明 #
新项目启动前，通常会制定一套设计规范。后续迭代直接引用，不用每次重复定义。
这份规范里通常包括：
- 状态名称与状态流转：有哪些状态，各自之间怎么转换，异常状态怎么处理
- 数据字典：字段含义、枚举值、业务规则
- 全局通用组件：弹窗样式、按钮状态、提示文案、加载样式、错误提示、动画效果，这些全局统一的交互规则提前定好
有了规范，需求文档可以更简洁，直接写「按规范执行」就行，不用每个页面重复描述同样的交互细节。
需求正文 #
这是文档的核心部分。常见格式是图文穿插：截图旁边配文字说明。如果截图要素较多，先用线框图标注序号，再逐条说明。
页面描述 #
开篇先说清楚这个页面是什么、属于哪个业务、处于哪个步骤的节点上。上下文清晰了，读者才能正确理解后续的细节。
前置条件 #
这是最容易遗漏的部分。展示这个页面需要什么前提？
- 权限：是否需要登录？是否有功能权限或数据权限的限制？
- 数据来源：数据是后台配置的还是接口返回的？如果是后台配置，后台是否已具备这个模块？
- 数据加载：是后端推送还是前端拉取？加载方式是什么（预加载、懒加载、实时加载）？加载的条数和触发时机是什么？加载中、加载成功、加载失败的展示分别是什么？
这些细节不写清楚，开发只能靠猜。猜错了，返工的是整个团队。
展示问题 #
页面上的数据从哪里来、怎么展示，需要说明白的点包括：
- 数据范围：是否有时间范围、权限范围的限定？展示的是哪个数据表的哪些字段？
- 空状态：数据为空时展示什么？是完全空白还是给引导文案？
- 字段展示：字段长度超限怎么处理？特殊字符是否需要过滤或转义？计量单位怎么标注？
- 元素标注：页面上的每一个元素都需要说明，尤其是信息密度高的列表页，可以用指示线或角标来标注序号，逐一解释。
排序与缓存 #
排序的默认规则是什么？哪些操作会触发排序变更？
缓存的策略呢？哪些数据需要缓存？缓存什么时候删除、什么时候更新？
交互设计 #
前置交互：用户在哪里触发、触发的方式是什么（点击、滑动、长按）、热区多大、是否容易误触。获取焦点时的样式是什么？禁用状态下又是什么样子？
校验规则：是实时校验还是提交时校验？校验失败的提示是什么？有没有引导性的提示帮助用户修正？
联动逻辑：选项之间是否有联动关系？选 A 会带出 B，选 C 则不会，这些条件需要一一列举。
后置交互：操作成功或失败后的提示是什么？是否有加载状态或倒计时？点击后的跳转逻辑是什么，是返回上一页、返回首页、还是生成一条记录但留在当前页？比如支付未完成通常会生成一条「未支付订单」而不是简单返回购物车。
后置条件 #
操作完成后，数据怎么流转？
- 数据落库：新增、修改、删除分别涉及哪些表、哪些字段？是软删除还是硬删除？是否需要生成操作日志？
- 数据处理：是实时处理还是异步处理？有没有时效性要求？涉及什么算法？结果如果有异常怎么报错？
- 后置页面：操作完成后用户看到的是什么页面？这个页面如果要继续操作，需要重新走一遍前置条件。
常见功能 #
搜索、筛选、排序是高频出现的功能，也最容易遗漏细节。
搜索：数据来源是本地还是云端？支持精确搜索还是模糊搜索？搜索范围是否需要限定？
筛选：复合筛选还是单项筛选？筛选的默认值和可选项有哪些？
排序：默认排序规则是什么？是否支持千人千面？
其他注意事项 #
以下这些点容易被忽略，但一旦漏掉，上线后会很麻烦：
版本限制：是否有最低版本要求？是否需要强制更新？新版本和旧数据是否兼容？
新手引导：是否需要启动页或功能引导？
数据埋点：需要记录哪些事件？这个在 PRD 阶段就要想清楚，不能等上线了再补。
消息推送：推送内容、推送时间、推送渠道（厂商通道还是自建通道）。
手机本地能力：相机、陀螺仪、通讯录、备忘录等原生能力的调用。
外部跳转：跳转到其他 App 还是 H5 页面？有没有缓存清理机制？
夜间模式：是否需要适配深色模式？
衍生产品：如果未来要做桌面小组件、浏览器插件等衍生能力，当前版本的技术方案是否留有余地？