产品经理文档清单

产品经理每天忙东忙西，但真正能留下的东西，是一堆文档。开发照着文档写、测试照着文档验、客户照着文档确认。文档写不清，开发和测试就只能靠猜，猜错了就是返工。

这一页把产品经理在每个阶段要写的文档列成一张清单，每份都说清三件事：用途、包含什么、示例。不追求文采，只求能直接照着用。

文档总览表

下面这张表覆盖了本页要讲的全部文档。可以先扫一眼整体，再看后面的逐份说明。

文档名称	所属阶段	什么时候写	主要给谁看	一句话说明
原始需求清单	需求	收到需求的第一时间	自己、技术团队	把用户原话原封不动记下来，先不评判
需求池登记表	需求	需求收集后统一登记	自己、决策人	所有需求的统一台账，看状态和优先级
需求分析结论	需求	分析完、立项前	决策人、技术团队	拆出的功能点、边界、优先级、待确认项
PRD（产品需求文档）	设计	立项后、开发前	技术、测试、UI、客户	讲清楚做什么、为什么做、做到什么程度
功能规格说明书	设计	PRD 之后、开发前	前后端开发、测试	讲字段、规则、流程、异常，能照着开发
字段与规则表	设计	设计阶段随功能一起	前后端开发	每个字段的类型、必填、校验、默认值
流程图与状态图	设计	设计阶段	技术、测试	主流程怎么走、状态怎么迁移
原型与交互说明	设计	设计阶段、开发前	UI、前端、客户	页面长什么样、点了会发生什么
数据字典	设计	有多表关联或字段口径不统一时	后端、前端、测试	统一全项目的数据字段口径
排期表 / 迭代计划	项目	评审通过后	技术、客户、老板	谁在什么时候做什么，分几轮交付
评审会议纪要	项目	每次评审会后	全体参会人	会上定了什么、还留了哪些疑问
变更登记表	项目	每次需求变更时	技术、客户	改了什么、为什么改、要不要重新排期
风险与依赖清单	项目	排期时建立、贯穿全程	技术主管、老板	可能出问题的事、要等别人的事
上线清单	项目 / 交付	上线前	运维、测试、技术	上线前逐条核对，勾完才能发
验收标准	验收	写 PRD 时同步写	测试、客户	做到什么程度算合格，可判定
测试用例	验收	开发完成、测试前	测试工程师	每个功能点怎么测、期望什么结果
验收报告	验收	测试通过后	客户、老板	逐条核对的结果，能不能交付
问题清单	验收	测试过程中持续更新	开发、测试	发现了哪些问题，谁跟、修没修
交付物清单	交付	交付前	客户、运维	这次交付了什么，清单化点交
用户操作手册	交付	交付前	最终用户、客户	用户怎么用，配截图一步步说
发布说明	交付	每次上线后	用户、运营、客服	这次更新了什么、有什么要注意
复盘报告	交付	上线后一两周内	全体参与人	做对了什么、踩了什么坑、下轮改什么

需求阶段

需求阶段的核心是“先记全，再判断”。别急着说行不行，先把话记下来。

原始需求清单

用途：把用户、老板、数据、竞品提出的话原封不动记下来，作为后续分析的原始素材。
关键字段：编号、来源、提出人、原始描述、提出时间、期望时间。
要点：只记录、不改写。用户说“加个大红按钮”，就写“加个大红按钮”，别自作主张改成“优化下单入口”。

编号	来源	提出人	原始描述	提出时间	期望时间
R-001	用户反馈	张老板	老客户下单能不能给个折扣	2026-03-01	尽快
R-002	客服工单	客服小李	一周收到 20 个问“优惠券怎么用”的电话	2026-03-02	不着急
R-003	老板	王总	竞品都有优惠券，我们也得有	2026-03-02	本季度内

需求池登记表

用途：所有需求的统一台账。谁提的、什么状态、什么优先级，一眼能查。
要点：状态只用一套词，别今天“待处理”明天“待定”，最后没人知道做没做。
状态流转链：待评估 → 已评估 → 排期中 → 开发中 → 已上线 / 已拒绝。

编号	来源	提出人	原始描述	优先级	状态
R-001	用户反馈	张老板	老客户下单给折扣	高	排期中
R-002	客服工单	客服小李	优惠券使用说明不清	中	已评估
R-003	老板	王总	增加优惠券功能	高	开发中
R-004	竞品	产品经理	竞品的分享领券活动	低	已拒绝

需求分析结论

用途：把零散的原始需求，加工成“要做哪些功能点”的结论，是立项和写 PRD 的直接依据。
包含什么：
- 拆出的功能点（一条功能点 = 一份能独立开发、独立验收的活）
- 需求边界（in scope 做什么 / out of scope 不做什么）
- 优先级（必须做 / 应该做 / 可以做）
- 待确认项（还没问清楚、需要再对齐的）
示例（针对“优惠券”这个需求）：

功能点	边界	优先级	待确认
用户领取优惠券	范围内	必须做	无
下单时使用优惠券	范围内	必须做	一张订单能不能叠加多张券？待客户确认
优惠券使用记录	范围内	应该做	无
优惠券分享给好友	范围外，下个版本做	可以做	无

只写“做什么”不够，一定要写“不做什么”。否则上线后客户一句“我以为是包含的”，就要扯皮。

设计阶段

设计阶段是产品经理产出最重的一段，尤其是 PRD 和功能规格。下面逐份展开。

PRD（产品需求文档）

PRD 是产品需求文档（Product Requirements Document）的缩写，是整个项目的“总纲”。开发照着它做，测试照着它验，客户照着它确认。它回答的是做什么、为什么做、做到什么程度算好。

一份完整的 PRD 包含下面这些章节：

章节	写什么
背景与目标	为什么要做这个功能，希望解决什么问题，上线后想看到什么变化
用户与场景	谁会用它、在什么情况下用
范围（做什么 / 不做什么）	这一版做什么、明确不做什么，都逐条列出来
功能清单	把功能拆成一条条，每条一句话说清
字段与规则	涉及哪些字段、每个字段有什么规则
流程与状态	用户操作按什么顺序走，状态怎么变
异常与边界	断网、超时、重复提交、权限不足怎么办
验收标准	做到什么程度算合格，可判定
排期与依赖	大概什么时候做，要先等谁完成

填好的小示例：优惠券领取与使用

一、背景与目标老客户复购率低，老板要求做一个优惠券功能，刺激复购。目标：上线一个月内，使用优惠券的订单占比达到 20%。

二、用户与场景普通用户。场景：用户在活动页看到“满 100 减 20”的券，点击领取，下单结算时抵扣。

三、范围

范围内：领取优惠券、我的优惠券列表、下单时选择优惠券抵扣。
范围外：优惠券分享给好友、优惠券转赠（本版不做）。

四、字段与规则表

字段名	类型	是否必填	默认值	校验规则	说明
券名称	文本	是	空	不超过 20 个字	展示给用户的券名字
面额	数字	是	空	大于 0，最多两位小数	能抵扣多少钱
使用门槛	数字	是	0	大于等于 0	订单满多少才能用，0 表示无门槛
有效期	日期区间	是	空	结束日期不早于开始日期	过期后不可用
每人限领	数字	是	1	大于等于 1	同一个用户最多领几张
券状态	枚举	是	未使用	未使用 / 已使用 / 已过期	券的当前状态

五、主流程（文字箭头链）活动页看到券 → 点击“立即领取” → 校验是否已领满 → 领取成功，进入“我的优惠券” → 下单结算 → 选择可用优惠券 → 提交订单，抵扣生效 → 券状态变为“已使用”

六、验收标准

用户点击“立即领取”后，券立刻出现在“我的优惠券”列表，状态为“未使用”。
一单金额为 80 元时，“满 100 减 20”的券不可选，并提示“未满使用门槛”。
券一旦使用，同一张券在“我的优惠券”里状态变为“已使用”，不能再次选择。

PRD 是给所有人看的，所以先讲清楚“为什么”，再讲“怎么做”。别一上来就是字段表，别人看不懂背景就会问个不停。

功能规格说明书

用途：把 PRD 里的功能，细化成开发能直接照着写代码的说明书。
和 PRD 的区别：

对比项	PRD	功能规格说明书
回答的问题	做什么、为什么做	字段是什么、规则怎么定、流程怎么走
主要读者	客户、老板、全体	前后端开发、测试
详细程度	讲清目标和范围	细到每个字段、每个异常
变更频率	相对稳定	随设计推进不断细化

要点：PRD 是“总纲”，功能规格是“操作手册”。一份 PRD 可以配多份功能规格。

字段与规则表

用途：每个功能都配一张，写清涉及哪些字段、每个字段有什么限制。
模板：

字段名	类型	是否必填	默认值	校验规则	说明
字段名	文本 / 数字 / 日期 / 枚举	是 / 否	空或具体值	具体判断条件	业务含义

填好的示例（手机号注册）：

字段名	类型	是否必填	默认值	校验规则	说明
手机号	文本	是	空	11 位数字，以 1 开头	用户登录账号
验证码	文本	是	空	6 位数字，5 分钟内有效	短信验证码
密码	文本	是	空	8~20 位，含字母和数字	登录密码
是否同意协议	布尔	是	否	必须为“是”才能提交	用户协议勾选

规则要写成“能判定对错”的话。别写“手机号要合法”，要写“11 位数字且以 1 开头”。

流程图与状态图

用途：把主流程和状态变化画清楚，开发和测试照着走。
主流程用文字箭头链，以“订单”为例：用户下单 → 生成待支付订单 → 用户支付 → 收到支付回调 → 变为已支付 → 商家发货 → 用户确认收货 → 订单完成
状态迁移表，同样以“订单”为例：

当前状态	触发动作	下一个状态	说明
待支付	用户完成支付	已支付	收到支付回调后变更
待支付	超时未支付（30 分钟）	已取消	系统自动关闭订单
已支付	商家发货	已发货	记录物流单号
已发货	用户确认收货	已完成	交易结束
已支付	用户申请退款	退款中	需商家审核
退款中	商家同意退款	已退款	原路退回

要点：每个状态说清“谁能触发”“能不能撤回、超时会怎样”，状态名全项目统一，页面、数据库、接口都用同一套。

原型与交互说明

用途：让 UI 和前端知道页面长什么样、点了会发生什么。
原型要标注：
- 每个元素的位置和名称，名称要和字段表一致。
- 按钮点击后去哪儿、弹什么框。
- 有几种状态（默认、加载中、成功、失败、空）各长什么样。
交互要写清：
- 点击、滑动、返回分别发生什么。
- 必填项没填、格式不对时提示什么文案。
- 操作是否可撤销、是否需要二次确认。

数据字典

用途：当项目里有多张表互相关联、或者同一个字段在不同页面叫法不一致时，需要一份数据字典统一口径。
包含什么：字段名、中文含义、数据类型、取值范围、来源、关联关系。
示例：

字段名	中文含义	类型	取值范围	说明
user_id	用户编号	数字	正整数	全系统唯一，用户表主键
order_status	订单状态	枚举	待支付 / 已支付 / 已取消	与状态图保持一致
coupon_status	券状态	枚举	未使用 / 已使用 / 已过期	与订单状态同一套命名风格

什么时候需要？同一个概念出现了两种叫法（比如“订单号”和“order_no”混用）时，就该建数据字典了，越早越好。

项目阶段

进入开发后，文档的重点从“做什么”转向“怎么推进、怎么控变更”。

排期表 / 迭代计划

用途：告诉所有人，谁在什么时候做什么，分几轮交付。
要点：时间由技术主管定，产品经理不自己拍脑袋承诺；核心流程先做；标注依赖关系。
示例：

迭代	内容	负责岗位	计划完成	依赖
第 1 轮	优惠券领取 + 我的优惠券	前后端开发	3 月 20 日	无
第 2 轮	下单使用优惠券抵扣	后端开发	3 月 28 日	第 1 轮完成
第 3 轮	优惠券使用记录	前后端开发	4 月 5 日	第 2 轮完成

评审会议纪要

用途：记录会上定了什么、留了哪些疑问，会后作为唯一依据。
示例：

项目	内容
会议时间	2026-03-10 14:00
参会人	产品、技术主管、前后端、测试、UI
结论	优惠券功能本版做“领取 + 使用”，分享功能下版做
待确认	一张订单能否叠加多张券，待客户 3 月 12 日前答复
风险	优惠券与订单系统联动较多，需要额外联调时间

钉钉、微信里聊的结论不算数，写进纪要才算数。会后把纪要发给所有参会人。

变更登记表

用途：需求变更免不了，但不能随便变。每条变更登记原因、影响，评估后再决定。
示例：

变更内容	变更原因	影响范围	是否重新排期	提出人	结论
增加“券可叠加使用”	客户临时要求	订单结算逻辑、前端选择交互	是，推迟 3 天	客户	同意，排进第 3 轮
券面额改成支持小数	运营核对账目需要	券表字段、结算计算	否	运营	同意

口头变更不算数，写进登记表才算数。

风险与依赖清单

用途：提前列出可能出问题的事、要等别人的事，别等出事才想。
示例：

类型	内容	可能影响	应对措施	负责人
风险	优惠券与订单系统联动多	联调时间不足，延误上线	提前预留 2 天联调时间	技术主管
风险	需求频繁变更	反复返工	设需求冻结窗口	产品经理
依赖	短信服务商审核	领取通知短信发不出	提前 5 天提交申请	后端开发

上线清单

用途：上线前逐条核对，勾完才能发布。
示例：
功能：领取、使用、状态变更逐条走通
文案：门槛不足、已领满的提示语是否正确
数据：测试券已清理，正式券配置无误
权限：普通用户只能看到自己的券
回滚：出问题能退回上一版本
通知：相关人已知晓上线时间

验收阶段

验收就是按当初写下的标准，一条一条对着核。验收的功夫，全在“当初写得清不清楚”。

验收标准

用途：定义“做到什么程度算合格”，要求可验证、可判定，不靠感觉。
好的写法 vs 差的写法：

差的写法	好的写法
优惠券要领得顺畅	点击“立即领取”后 2 秒内，券出现在“我的优惠券”列表
券要用得合理	订单金额未满门槛时，券置灰不可选并提示“未满使用门槛”
状态要准确	券使用后，列表状态立即变为“已使用”，且不可再次选择

要点：一条验收标准只写一件事，能回答“是 / 否”。

测试用例

用途：给测试工程师用，每个功能点怎么测、期望什么结果。
示例：

用例编号	测试步骤	预期结果
TC-001	在活动页点击“立即领取”	券出现在“我的优惠券”，状态“未使用”
TC-002	领满限领张数后再点领取	提示“已达领取上限”，不再发放
TC-003	订单金额 80 元时选择“满 100 减 20”的券	券不可选，提示“未满使用门槛”
TC-004	使用券下单成功后查看券列表	该券状态变为“已使用”

验收报告

用途：逐条核对的结果汇总，是“能不能交付”的依据。
示例：

验收项	验收标准	结果	备注
领取优惠券	2 秒内出现在列表	通过	无
使用门槛校验	未满门槛不可选并提示	通过	提示文案已核对
券状态变更	使用后立即变为已使用	通过	无
券叠加	一单可用多张	不通过	客户已确认放到下个版本

问题清单

用途：测试过程中发现的问题都记在这里，跟踪到修复完成，别记了就忘。
示例：

编号	问题描述	严重程度	发现人	负责人	状态
B-001	券列表页刷新后偶发空白	高	测试	前端开发	修复中
B-002	领取上限提示文案有错别字	低	测试	前端开发	已修复
B-003	过期券未自动更新为“已过期”	中	测试	后端开发	待修复

交付阶段

交付不是把代码扔给客户就完事，把东西交清楚、说明白，才算真的交付。

交付物清单

用途：这次交付了什么，清单化点交，缺什么一目了然。
要点：代码、数据库、部署文档、账号、说明书分开列，逐项签字确认。
示例：

交付物	形式	交接对象
源码与部署包	代码仓库	运维
数据库脚本	SQL 文件	运维
部署文档	文档	运维
用户操作手册	文档	客户、最终用户
后台账号	账号密码	客户

用户操作手册

用途：最终用户怎么用，配截图一步步说，减少客服电话。
要点：按“用户想做什么”来组织，不按功能模块罗列；多用截图和编号步骤；常见问题单列一节。

发布说明

用途：每次上线后告诉用户、运营、客服，这次更新了什么、有什么要注意。
示例：

分类	内容
新增	支持领取优惠券，下单时抵扣
优化	“我的优惠券”列表加载更快
注意	旧版已持有的券，需重新领取一次

复盘报告

用途：上线后回顾，做对了什么、踩了什么坑、下轮先改什么。
要点：别只夸成绩，重点找问题；每条问题配一个具体改法，写清负责人和落地时间。
示例：

分类	内容	改进项
做对了	优惠券与订单提前联调，联调期没耽误	保持
踩坑了	中途临时加“券叠加”，导致结算逻辑返工	下次变更先评估排期影响
数据	使用优惠券的订单占比 12%，未达 20% 目标	下版调整券门槛和面额

文档写作规范

文档写得好不好，直接影响别人看不看得懂。下面几条是通用底线。

统一术语：全项目用同一套词，同一个东西只用一个名字。不确定时先查需求与产品术语字典，别自己造词。
可验收：每条要求都写成能判定“是 / 否”的话，不写“要快”“要好看”这种没法验证的描述。
版本与变更记录：文档开头或结尾留一块变更记录，写清版本号、日期、改了什么、谁改的。
命名规范：文件名统一，比如 PRD_优惠券_v1.2、字段表_订单_v1.0，别用“新建文档111”。
一图胜千言，但别只给图：流程图、原型要配文字说明，方便搜索和引用。
写完自检：发出去之前自己先读一遍，检查有没有前后矛盾、链接是不是有效、示例是不是真能照着用。