简介：这是一份传智健康管理系统的产品需求文档，面向产品经理、需求分析师及系统设计人员。文档围绕数据结构管理展开，详细定义健康评估指标的关键字段——序号、指标名称、参考值、单位、针对性别，并明确用户（病人）、医护人员、管理员三类角色的权限与操作场景，这些字段可直接映射到数据库字段设计。功能部分涵盖会员管理、预约管理、健康评估、健康干预等模块，每个模块均配有流程图与功能操作说明，有助于理解健康平台从需求到落地的完整思路。文档还包含修订记录、用户角色描述、产品概述、功能详情等部分，结构完整、便于需求评审和二次开发参考。资源共1个docx文件，压缩包约890KB；已有599人学习，适合需要梳理健康类系统数据字典、撰写PRD或开展需求评审的从业者，也可作为实际项目中的模板范本。

1. 健康类PRD不是功能清单：一份能扛住开发的文档长什么样

写健康管理平台的PRD文档，翻车起点往往是同一个：把几十页需求写成菜单和按钮的清单，开发看完觉得这跟普通CRUD没区别，做完才发现取消预约后号源何时释放、医生超时未回复怎么办、报告延迟该找谁，这些全是评审会上反复重吵的遗留问题。传智健康这类产品的PRD文档，真正的分界线不在原型画得多精致，而在规则有没有写死——状态机、字段字典、接口契约，这些才是文档的硬骨架。下面按一份PRD从拆业务到过评审的推进顺序来拆，状态机、字段字典、接口契约、合规边界、验收清单都会给出可以直接复制的写法。适合正在写健康类产品需求文档的产品与需求人员，也适合被不靠谱PRD坑过的开发用来反向提要求。

2. 锁死三条业务主线：预约建档与报告解读的状态机设计

2.1 健康产品的主线为什么不能按菜单写

常见做法是照着页面菜单写需求——预约管理、报告管理、个人信息，每个模块拆几个增删改查。这样写出来开发确实能照着做，但做出来你会发现“取消预约”这个操作在预约管理有、在订单管理又有，谁负责释放号源、谁负责退款、谁负责通知用户，完全没有归属。这个问题的根子在于：PRD按页面组织，而业务规则是按单据和状态流转组织的，两者错位，交付后必然互相甩锅。

健康产品通常有三条业务主线要优先定状态机：预约（覆盖体检和问诊）、健康报告、问诊会话。预约是钱、号源和履约的交汇点，状态最多也最容易写乱；报告是数据与用户的连接点，涉及上传、解析、异常标记、解读完成等环节；问诊会话是医患交互，涉及时效、关闭、转派。这三条线用文字叙述很容易漏状态，用状态机配合角色权限才能兜住边界。

2.2 预约状态机的完整定义：PRD里必须锁死的流转规则

以体检预约为例，我一般会把状态拆成基础态和中间态，用枚举定义写死在PRD里，而不是用流程图一带而过。流程图能让人看懂主路径，枚举才能让开发落代码时不自由发挥。

# 预约状态枚举，直接写入PRD的“状态机”章节 class AppointmentStatus(Enum): PENDING_PAYMENT = "待支付" # 用户已提交预约单，未完成支付 PAID = "已支付" # 支付成功，等待服务日期 CONFIRMED = "已确认" # 到达预约日期，确认已到检 REPORT_PENDING = "报告生成中" # 已到检，报告未出 REPORTED = "报告已生成" # 报告已上传/已推送用户 COMPLETED = "已完成" # 用户已查看报告 / 解读已完成 CANCELED = "已取消" # 用户主动取消或系统超时取消 EXPIRED = "已失效" # 预约日期已过且未到检，订单不可再改期

每个状态的进入条件和退出动作必须在文档里写死。比如PENDING_PAYMENT只有两个退出路径：用户支付成功后进入PAID；超过15分钟未支付，系统自动取消并释放号源，记录CANCELED。PAID状态的退出路径有用户主动取消、到检确认进入CONFIRMED、预约日期过期进入EXPIRED三个分支。这些流转动作中，用户主动取消会触发退款和号源释放两个跨模块动作，文档里必须在状态定义旁边标注“联动动作”，否则开发只改预约单状态，不通知库存和支付模块。

状态流转之外，角色权限也要一起定义。用户能触发的是提交、取消、确认到检；客服能操作的是改期、退款、关闭会话；后台脚本自动触发的是超时取消、报告推送。把“哪个角色能做什么动作”单独列成一张权限矩阵，避免后续开发实现越权操作。实际评审中，开发问“取消后的退款走微信原路退回还是手动打款”这类问题，都应当在状态机这一节提前给到默认答案：支付后取消走原路退回，未支付取消不触发退款。这笔账必须先算，否则技术评审会变成财务评审。

2.3 报告的异常分支要在需求阶段写进状态图

报告线是健康产品里最容易被低估的部分。常见的做法是只写“用户上传体检报告→系统解析→展示指标”，但真实情况是：PDF扫描件解析失败、同一用户上传两份报告、指标值超出正常范围好几倍。解析失败应该进入人工处理队列还是告知用户重新上传？异常指标应该由系统自动推送还是人工确认后推送？这两个边界规则不在PRD里锁死，测试阶段就天天干瞪眼。

我推荐的写法是：在报告状态定义之后，加一个“异常处理矩阵”，列出异常场景、探测方式、处理角色、兜底动作。解析失败的处理角色是数据后台，兜底动作是72小时内工作人员手工录入；异常指标的处理角色是客服，兜底动作是确认后24小时内推送。这些内容看着是运营流程，但开发需要知道字段落库和消息通道在哪里触发，所以必须写进PRD而不是另起一份运营手册。

3. 页面与字段的写法：从原型图到开发能直接抄的规格

3.1 页面交互需求的最小规范写法

原型图只能解决“长什么样”，解决不了“什么情况下出现、不出现、点了会怎样”。一份页面级需求，我一般要求写清楚七个问题的答案：入口在哪、前置条件、默认值、空态、异常态、角色差异、操作反馈。以体检预约页为例，前置条件是用户已完成实名认证且当天未提交过同类型预约；默认值是本周三上午九点的第一个可约时段；空态是当前城市没有可预约的体检机构时展示提示文案；异常态是号源被抢光时可选时段置灰；角色差异是普通用户看不到团检套餐；操作反馈是提交成功后要同时出现弹窗提示和短信模板预览。

这七个问题不一定要写成七个标题，每页一段话也够，但必须存在。最容易偷懒的是空态和异常态，很多PRD只画了正常态，导致前端开发上线前才补空态UI，UI走查又让改一遍。空态文案属于文档必填项，不要在验收阶段才讨论“没有报告时应该显示什么”。

3.2 字段字典实例：PRD里如何写一份让后端不再二次猜谜的 JSON

页面文字写明白了，字段还不一定对得上。后端建表时如果拿不到统一的字段名、类型、长度、枚举值，同一个“预约日期”就可能出现三种命名。为了不让字段命名变成各写各的，我会在PRD里给一份字段字典，直接用 YAML 结构描述，后端可以照着建表，前端可以照着联调接口。

# PRD 字段字典示例：预约单（appointment） appointmentNo: type: string length: 32 required: true source: system_generated display: true desc: 预约单号，全局唯一，格式 APPT+yyyyMMdd+4位流水 status: type: enum values: [PENDING_PAYMENT, PAID, CONFIRMED, REPORT_PENDING, REPORTED, COMPLETED, CANCELED, EXPIRED] required: true source: system display: true desc: 当前状态，见“状态机”章节 userId: type: string length: 16 required: true source: user_session display: false desc: 下单用户ID，取自登录态，前端不可传 packageId: type: string length: 16 required: true source: user_input display: true desc: 套餐ID，联动体检套餐列表，礼品卡不可用 appointmentDate: type: datetime format: yyyy-MM-dd required: true source: user_input display: true desc: 用户选择的到检日期，必须晚于当前日期且在有效期内 appointmentTimeSlot: type: string values: [08:00-09:00, 09:00-10:00, ..., 14:00-15:00] required: false source: user_input display: true desc: 可选时段，依据机构排班动态返回，为空代表机构不排班 amount: type: decimal precision: "10,2" required: true source: system display: true desc: 实付金额，由套餐价格减去优惠计算，不能由前端传入 paymentChannel: type: enum values: [WECHAT, ALIPAY] required: false source: user_input display: false desc: 用户使用的支付渠道，支付成功回调后回填

字段字典里最重要的约定有三个。第一个是source，它决定了字段由谁填——用户输入、系统生成还是登录态，后端看到source: system_generated就知道该字段不接受前端传值。第二个是display，它决定字段要不要返回给前端，用户ID这种字段就不应该出现在响应体里。第三个是required，它和校验规则要一致，常出现 PRD 里写“选填”、代码里却按必填校验的情况。字段字典写完，前后端联调期“字段类型对不上”的争议会大幅减少。

3.3 枚举值统一在PRD里定死，接口代码才不会出现魔法值

还有一个细节：枚举值不要用中文描述代替，比如状态字段不要写“已取消”三个字就完事，要把英文枚举名一起写出来。前端拿到的永远是CANCELED而不是“已取消”，后端接口文档、数据库注释、PRD 字段字典三处保持一致。同一字段在不同新页面或弹窗里也要复用同一套枚举，不要既叫REFUNDED又叫REFUND_SUCCESS。枚举冲突是联调期最耗时的隐形坑，提前统一能省下一整周的扯皮时间。

4. 数据与接口契约：让后端不见面就能开工的文档细节

4.1 预约下单接口的请求与响应：PRD里提前定死的三条契约

很多团队的习惯是PRD只写页面，接口让后端自己出。这也能开发，但结果就是后端按自己对业务的理解定义接口，前端联调时发现字段名不一致、错误码对不上，再回头跟产品确认。我一般会在PRD里把核心写接口定义出请求响应骨架，不用精确到每个边界，但请求参数、响应码、幂等键这些必须有。预约下单接口涉及支付、涉及并发抢号，所以幂等键和状态码约定必须在文档里出现。

# 预约下单接口契约（摘自PRD接口章节） # POST /api/v1/appointments # 请求头: Content-Type: application/json; Authorization: Bearer <token> # 幂等策略：客户端生成幂等键，重复提交同一键只返回首次结果，防止用户双击下单 { "userId": "U218903", # 取自登录态，后端校验与 token 一致 "packageId": "PKG-HEALTH-BASE", # 体检套餐ID "appointmentDate": "2025-06-15", # 到检日期，格式 yyyy-MM-dd "appointmentTimeSlot": "09:00-10:00", "idempotencyKey": "6f8b2e9a-1c4d-4f7e-9a3b-2c8d5e1f0a4b" } # 成功响应 { "code": 0, # 业务码：0 为成功 "message": "success", "data": { "appointmentNo": "APPT202506150001", "status": "PENDING_PAYMENT", "expireAt": 1749888000, # 支付截止时间，超过15分钟未支付自动取消 "amount": 399.00, "paymentParams": { "wechat": { "prepayId": "wx291834234fe", "nonceStr": "..." }, "alipay": { "tradeNo": "20250615..." } } } } # 失败响应（统一错误码） { "code": 40031, # 40031: 号源已被预约，请重新选择时段 "message": "所选时段已被约满", "data": { "availableTimeSlots": ["08:00-09:00", "10:00-11:00"] } }

这里有三条约定值得固定下来。第一，业务码与HTTP状态码分离，业务失败统一返回200 + 业务错误码，这样网关层不会丢弃业务异常信息。第二，失败响应必须带上可用的替代数据，比如号源约满时返回剩余可约时段，前端可以直接更新界面，不用再发一次查询请求。第三，幂等键放在请求体而不是请求头，便于日志排查和问题复现。业务码统一按模块划分，预约模块是40开头，支付是41开头，每个码在PRD里都要有具体含义，不要等后端自己编。

这样写接口文档对后端不是约束，是省事，因为每个字段的格式和数据来源已经在字段字典里定了。没有文档，他要去翻前端代码看有没有同名字段，那才叫真折腾。

4.2 埋点字典跟着PRD走，别等上线前再补

健康类产品的数据埋点比普通电商更依赖业务阶段，比如预约页到支付成功的转化、报告上传用什么端、异常指标通知点击率是多少。这些事件在PRD阶段不定义，上线后运营发现拿不到完整行为数据，再补埋点可能还要等发版审核，来回折腾一个月。我一般会在PRD里加一节“关键行为事件”，直接按事件字典写，开发做埋点时有明确参照，不必自己起名。

# 关键行为事件字典（节选） appointment_create: trigger: 用户点击提交预约 properties: package_id: 套餐ID source_page: 发起页面，取值 home/category/detail result: success/duplicate/failed fail_reason: 失败码，如号源不足/未实名/余额不足 appointment_pay_result: trigger: 支付回调返回后 properties: payment_channel: WECHAT/ALIPAY amount: 实付金额 pay_result: success/failed/canceled elapsed_seconds: 从提交到回调的耗时 report_upload_result: trigger: 用户上传报告文件 properties: upload_channel: mini_program/web_app file_count: 文件数量 parse_result: success/failed parse_failed_reason: 解析失败码

事件字典要注意三个问题：属性值统一用枚举不用中文；事件名按“对象_动作”命名，不要一次拉长五六个词；关键事件必须和状态机联动，比如appointment_create.result=duplicate对应幂等键命中。这些细节看着繁琐，但它是运营后续做数据分析的底子，PRD里缺了，后面靠猜事件名会让人头大。

4.3 为什么接口契约先定的性价比最高

做产品的人都懂需求变更代价随阶段指数级增长，但落到接口上往往觉得后端能搞定就让他们定。实际上，提前在PRD里把接口骨架定死，消耗的是写作时的一点时间，换来的是整个开发周期的稳定。后端不用追着产品问“这个字段哪来的”“取消时要不要返回退款状态”，前端不用自己在 mock 数据里编字段名然后再改一遍。这笔账算下来，接口契约是 PRD 里性价比最高的部分，也最值得在一开始多花两小时。

5. 健康产品PRD避坑：合规、边界场景与评审的常见翻车点

5.1 合规红线：健康数据的授权、最小化与可删除

现象：PRD里只写了“用户可以上传体检报告”，没有写授权同意、数据范围、删除入口。开发照文档做了，到了安全测试阶段被驳回：体检报告属于健康数据，收集环节没有用户授权记录，拿不到合规依据。

原因：需求阶段只考虑了功能，把合规当成了上线的后置校验项。健康数据的收集、存储、使用必须伴随明确的授权动作，只有功能没有授权，是不完整的。

解决：在PRD里把授权与数据管理写成一节功能需求而不是一句合规说明。具体包括三个出口：用户首次上传报告时必须经过同意页，文档里定义同意页出现的条件与话术；用户可以随时查看授权范围；用户申请删除报告后，文档要求后端在一个工作日内完成逻辑删除，并在界面上提供撤回授权的入口。我一般在需求清单里直接放这几个需求项，跟“上传报告”同级，这样测试才不会漏测。

5.2 边界场景：医生不在线、报告延迟、用户误操作怎么定义

现象：问诊模块评审时，开发问“用户发的问题，医生一直没回复怎么办”。产品经理说“医生会来的”，于是系统没有任何超时机制。上线第一周，用户等回复等了四小时没有收到任何提示，客诉翻倍。

原因：PRD只覆盖了主流程，把“医生不回复”当成低频事件省略了。健康产品的特殊性在于服务方不是系统而是真实的人，人的不确定性必须转化为系统机制。

解决：把超时机制写进状态机。用户提交问题后进入等待分配的状态，5分钟无医生接单就自动重新分配；医生接单后超过30分钟未回复，系统推送提醒医生，提醒后10分钟内仍未回复的，自动转派给同科室下一位在岗医生，同时原路退回部分费用。这些规则不是为了处罚医生，而是给用户确定感。PRD里要把这几个时间参数标清楚，标注为可配置项，运营后台能改，不至于因排班变化而重新发版。同样值得补充的还有：用户取消问诊、医生主动关闭会话、报告延迟超过24小时时如何给用户推通知。

5.3 评审陷阱：技术说“做不到”时，产品经理怎么接

现象：技术评审会，后端指着某个需求说“这个做不了”。现场最容易演变成需求拉锯战，最后以砍功能收场。但事后复盘常常发现，“做不了”其实有三种不同的意思：真的做不了、现有方案不对、接口不支持所以他不想动老代码。

原因：PRD给的是“要什么”，没给“为什么这样设计、有没有备选”。技术的一句话否定，没有可用来拆解的上下文。

解决：在PRD的每个核心需求旁边，我建议加一行“设计考量”，写清这个需求的业务目标、备选方案、降级路径。比如健康报告异常指标要“24小时内自动推送”，设计考量可以写：备选方案是人工客服电话通知，成本高时效低，自动推送不可行时可降级为App内通知加短信。这样评审会上后端再说“做不了”，可以直接指着降级方案问“自动推送做不了，那能不能做短信通知？短信也不行，那App内通知的触发点能不能加？”——每一级都有明确的回退选项，讨论就能收敛。另外，把字段字典和接口契约带到会上，很多“做不了”其实是“你要求返回的字段我在后端没有”，字段字典能快速定位该字段的已有来源，谁有数据谁负责提供，责任就明确了。

5.4 评审前别忘的三处一致性检查

现象：文档各部分自己写了，但状态机里的CANCELED在字段字典里叫已取消，接口响应里出现中间态REFUNDING而状态机没有这个状态。开发按状态机开发、测试按响应码写用例，两边对不上，验收阶段才爆出来。

原因：PRD各章节由不同时间完成，没有统一核对。状态名、字段名、接口返回码这三处是全文一致性的重灾区。

解决：在定稿前把文档里的英文枚举全局检索一遍，确保出现的枚举名都能在状态机章节找到定义；字段字典里的source、required与接口契约里的请求参数一一对应；响应中的业务码在错误码表里都有条目。这个检查用文本搜索就能完成，花半小时换来后期数天对账时间，我对每个要上线的PRD都做这一步。

6. 评审和验收：用一份检查清单让文档真的落地

评审会前，我建议把文档里的核心章节浓缩成一张两页的检查清单，会议直接逐项过，不扯空泛问题。这张清单不是给文档打分的，是给开发、测试、产品三方确认“按这份文档做出来的东西，和预期一致”的证据。

清单里每一行都可以直接追问“这一项在文档的第几页”，答不上来就是文档没写完整，当场补。我一般会要求评审会先过清单再过页面，页面细节可以会后在群里继续对，但状态机、字段、接口这三项必须在会上达成一致，否则开发中途改返工成本极高。

这里有一个我踩过的坑：有份PRD状态机画得完整，但没写支付回调的触发点，后端认为支付结果自动带出状态，前端认为支付成功页和后端各管一段，结果上线当天支付成功的订单状态没有及时变更，用户看订单一直停留在“待支付”。后来把“支付回调→状态变更→前端轮询更新”这条链路写进接口契约才解决。所以我的习惯是：文档里凡是跨模块的状态变更，都额外标一句“由哪个系统在哪个时机触发”，不把触发机制留给实现者猜。

做健康类产品的PRD，最难的不是写功能，是把所有规则的触发机制和责任人定清楚。功能清单人人都能列，边界规则才是真正拉开文档质量差距的地方。如果这篇里的检查清单能帮你在评审会上少吵一场架，或者帮你提前发现一个没定义的状态，那这个文档就没白写。希望帮到你。

本文还有配套的精品资源，点击获取