04-产品需求文档PRD标准化：三端项目统一撰写规范与交付模板
为什么PRD要标准化
上一篇讲了需求全生命周期管理，但需求管理流程再好，产物文档本身不规范，执行也会走样。PRD（Product Requirements Document，产品需求文档）就是需求管理的核心交付物——它是产品、研发、测试三方对"做什么"的共同契约。
无人售货柜项目有三端，如果每端各写各的PRD、各用各的格式，问题会马上暴露：
- 后端PRD写了接口字段，固件没看到，对不上
- 小程序PRD描述了交互，但没写异常态，开发自由发挥
- 测试拿到的验收标准跟开发理解的不一样，扯皮
所以PRD必须统一结构、统一模板、统一交付标准。
PRD文档标准化结构
一份合格的PRD包含以下6个核心模块，缺一不可：
1. 背景与目标
## 1. 背景与目标 ### 背景 - 业务背景：为什么现在做这个功能 - 用户痛点：当前存在什么问题 - 数据支撑：如果有数据，列出来 ### 目标 - 业务目标：可量化的业务指标（如退款到账时间从24h降至1min） - 技术目标：技术层面要达成的效果 - 非目标：明确说明这版不做什么（边界很重要）这一段的价值在于让所有人先对齐"为什么做"再讨论"怎么做"。很多项目返工是因为开发到一半才发现产品要的跟自己理解的不是一个东西。
2. 功能描述
## 2. 功能描述 ### 2.1 功能概述 一句话概括这个功能做什么。 ### 2.2 用户角色 | 角色 | 说明 | |------|------| | 消费者 | 扫码购物用户 | | 柜长 | 管理售货柜的运营人员 | | 运营 | 平台运营方 | ### 2.3 核心流程 用流程图或时序图描述主流程，标注三端交互节点。 ### 2.4 功能详述 | 编号 | 功能点 | 优先级 | 描述 | |------|--------|--------|------| | F1 | 扫码开门 | P0 | 用户扫码后授权开门 | | F2 | 实时退款 | P1 | 退款1分钟内到账 |功能详述要写到**“另一个没参与讨论的开发也能看懂”**的颗粒度，不能默认上下文。
3. 接口定义
这是三端PRD最容易出问题的地方。接口定义模块要明确：
## 3. 接口定义 ### 3.1 接口清单 | 接口ID | 接口名称 | 调用方→提供方 | 协议 | |--------|---------|---------------|------| | API-001 | 开门授权 | 小程序→后端 | HTTPS | | API-002 | 下发开门指令 | 后端→固件 | MQTT | | API-003 | 柜门状态上报 | 固件→后端 | MQTT | ### 3.2 接口详情 #### API-001 开门授权 - 请求方式：POST /api/v1/door/authorize - 请求参数： | 字段 | 类型 | 必填 | 说明 | |------|------|------|------| | deviceId | String | 是 | 柜机ID | | userId | String | 是 | 用户ID | | qrcode | String | 是 | 扫码内容 | - 响应参数： | 字段 | 类型 | 说明 | |------|------|------| | code | Int | 0成功，其他见错误码表 | | message | String | 提示信息 | | data.doorToken | String | 开门令牌，传给固件 | - 错误码： | code | 含义 | 处理建议 | |------|------|---------| | 1001 | 柜机离线 | 提示用户换一台 | | 1002 | 二维码过期 | 提示重新扫码 |接口定义的核心要求：字段名、类型、必填、含义四要素齐全。小团队不用搞正式API网关，但Swagger或YApi必须有，PRD里的接口定义跟代码里的保持同步。
4. 交互规范（UI/UX）
## 4. 交互规范 ### 4.1 页面流转 扫码页 → 授权中loading页 → 开门成功页 → 购物页 → 关门结算页 ### 4.2 状态说明 | 状态 | 展示 | 触发条件 | |------|------|---------| | 授权中 | 转圈loading+"正在开门" | 点击扫码后 | | 开门成功 | 绿色勾+"请取走商品" | 收到固件开门成功上报 | | 开门超时 | 橙色提示+"开门失败，请重试" | 5秒未收到响应 | | 柜机离线 | 灰色提示+"该柜机维护中" | 后端返回1001 |交互规范的价值在于把异常态也写清楚。90%的体验事故是因为开发只做了正常流程，异常态自由发挥。
5. 验收标准
## 5. 验收标准 ### 5.1 功能验收 | 编号 | 验收项 | 验收条件 | |------|--------|---------| | A1 | 扫码开门 | 正常扫码3秒内柜门打开 | | A2 | 离线柜机 | 扫码后展示维护提示，不白屏 | | A3 | 开门超时 | 5秒未响应展示重试入口 | ### 5.2 性能验收 | 指标 | 目标值 | |------|--------| | 开门响应P50 | <2秒 | | 开门响应P95 | <3秒 | | 退款到账时间 | <1分钟 | ### 5.3 兼容性 - 小程序：微信基础库2.10.4+ - 固件：RK3399 Android 7.0+ - 后端：JDK8 + SpringBoot 2.7验收标准要可测试。写"体验流畅"这种没法验收，写"P50<2秒"可以测。
6. 异常处理
## 6. 异常处理 | 异常场景 | 后端处理 | 固件处理 | 小程序处理 | |---------|---------|---------|-----------| | 断网 | 心跳超时标记柜机离线 | 本地缓存开门记录，恢复后上报 | 展示"网络异常"重试 | | 断电 | 未收到状态上报，标记离线 | 来电后自检，上报状态 | 无感知 | | 支付失败 | 回滚订单 | 不开门 | 展示支付失败原因 | | 固件崩溃 | 5分钟无心跳告警 | 看门狗重启 | 提示柜机维护中 |异常处理模块是三端协同的保险丝。每个异常场景三端都要写清楚自己的处理逻辑，联调时逐项验证。
三端PRD差异处理
无人售货柜三端虽然共用一份PRD，但各端关注重点不同，差异部分要单独标注：
后端PRD重点
- 接口定义：完整字段、错误码、幂等性要求
- 数据模型：核心实体ER图、关键字段
- 业务逻辑：状态机、定时任务、消息队列
- 非功能需求：并发量、响应时间、可用性
安卓工控固件PRD重点
- 硬件交互：继电器驱动、传感器读取、串口通信
- 离线策略：断网时的本地缓存与恢复逻辑
- 固件升级：OTA方案、回滚机制、版本兼容
- 性能约束：内存占用、启动时间、功耗
微信小程序PRD重点
- 交互流程：页面流转、状态切换、loading态
- 微信能力：扫码、支付、订阅消息、授权登录
- 兼容性：基础库版本、机型适配
- 异常兜底：网络异常、接口超时、白屏处理
一份PRD里，三端差异部分用章节标注区分：
### 2.4.1 后端逻辑 （后端相关描述） ### 2.4.2 固件逻辑 （固件相关描述） ### 2.4.3 小程序交互 （小程序相关描述）这样三端开发各取所需，但共享同一份文档，不会有信息断层。
PRD模板与交付规范
模板骨架
# [需求编号] 功能名称 PRD ## 文档信息 | 项目 | 内容 | |------|------| | 需求ID | REQ-2026-XXXX | | 版本 | v1.0 | | 作者 | XXX | | 评审日期 | 2026-XX-XX | | 基线版本 | Baseline-2026SXX | ## 1. 背景与目标 ## 2. 功能描述 ## 3. 接口定义 ## 4. 交互规范 ## 5. 验收标准 ## 6. 异常处理 ## 7. 附录（原型图、流程图、变更记录）交付规范
| 规范项 | 要求 |
|---|---|
| 文档格式 | Markdown，统一飞书文档或Git仓库管理 |
| 版本管理 | PRD纳入Git版本库，变更走Commit记录 |
| 交付时机 | 迭代规划前完成初稿，评审通过后纳入基线 |
| 存放位置 | 统一目录，按迭代归档 |
| 三端共享 | 一份PRD三端共用，差异用章节标注 |
PRD评审通过标准
PRD评审不是走形式，有硬性通过标准：
评审Checklist
□ 1. 背景目标：背景清晰，目标可量化，非目标边界明确 □ 2. 功能描述：功能点颗粒度合适，优先级标注清楚 □ 3. 接口定义：字段四要素齐全（名称/类型/必填/含义），错误码完整 □ 4. 交互规范：正常流程+异常流程都有描述，状态机完整 □ 5. 验收标准：每项可测试、可量化 □ 6. 异常处理：三端异常处理逻辑各有描述，覆盖断网/断电/支付失败/固件崩溃 □ 7. 三端差异：后端/固件/小程序各自关注点已分章节标注 □ 8. 附录：有流程图或时序图，有原型截图 □ 9. 变更记录：初始版本无变更记录，后续变更每条有记录评审参与方与职责
| 角色 | 评审重点 |
|---|---|
| 产品经理 | 功能完整性、业务逻辑、优先级合理性 |
| 后端负责人 | 接口可行性、数据模型、性能约束 |
| 嵌入式负责人 | 硬件可行性、离线策略、固件升级方案 |
| 前端负责人 | 交互可行性、微信能力限制、兼容性 |
| 测试负责人 | 验收标准可测性、异常场景覆盖度 |
通过判定
- 全部通过：PRD纳入基线，进入开发
- 3条以内不通过：修改后产品经理确认即可，无需重新评审
- 4条以上不通过：修改后重新组织评审
这套标准看似严格，实际执行起来一份PRD评审30分钟内能搞定。核心不是文档写多厚，而是该有的信息不能缺。
小结
PRD标准化的核心价值：
- 三端信息同源：一份文档，各取所需，消除信息断层
- 验收有据可依：开发、测试、产品对"做完了"的判断一致
- 异常提前暴露：联调前就把三端异常处理对齐，减少联调返工
- 变更可追溯：PRD入Git，改了什么、谁改的、什么时候改的一目了然
CMMI3不是要求你写多厚的文档，而是要求关键信息不缺失、关键流程不断链。PRD就是这条链上最关键的一环——它把需求管理前几步的成果固化成一份可执行、可验收、可追溯的契约。
小微企业把这四篇做到位——CMMI3核心认知、痛点识别、需求管理流程、PRD标准化——轻量CMMI3的地基就打好了。后续的配置管理、质量保证、度量分析，都是在这套地基上往上盖楼。
