简介：《传智健康PRD文档1》是一份面向健康管理系统的产品需求说明书，适合产品经理、研发与测试人员梳理业务逻辑、明确功能边界。文档围绕数据结构管理展开，对健康评估指标进行规范化定义：涵盖序号、指标名称、参考值、单位、针对性别等核心字段，明确字段类型与可空要求；同时描述用户、医护人员、管理员三类角色的权限和使用场景，为权限设计提供依据。目录覆盖会员管理、预约管理、健康评估、健康干预四大业务模块，包含产品结构图、流程图和功能操作说明，可直接用于系统开发、需求评审或同类PRD编写。资源包共1个docx文档，压缩包约890KB，文字形式便于检索和二次编辑。目前已有599人学习，适合需要快速掌握健康管理平台核心需求的产品与研发人员。

1. 一份健康管理系统 PRD：它到底在管什么

这是一份健康管理系统 PRD，面向健康管理机构业务系统，覆盖会员管理、预约管理、健康评估、健康干预、知识库、统计分析、系统管理七个模块。它不只是讲「患者能挂号、能看报告」，而是把健康管理师的日常工作拆成「评估→分类→干预→回访」的闭环，同时把会员档案、体检报告、评估指标、干预模板这些对象的数据结构定义到字段级。文档里大量篇幅是表格，几乎每个子功能后面都跟一张数据字典表，这对后端反推表结构、前端对齐功能清单非常友好。适合谁？后端开发拿它做数据库设计，前端开发拿它列页面功能，产品经理拿它评审流程缺口；你要复现一套健康管理平台，这份文档就是一个现成的需求底稿。

2. 角色、流程与状态机：先把「谁在做什么」串起来

2.1 三种角色的权限边界

PRD 的角色模型很简单但很关键：管理员、健康管理师、患者，三种角色各管一段。

管理员负责平台所有基础数据的增删改查，落到功能上就是系统管理里的菜单管理、权限设置、用户管理、题库管理、问卷管理，以及知识库里的评估建议、膳食库、运动项目库、疾病库这些公共主数据。健康管理师是业务执行者，主要负责患者评估、干预、随访，以及会员档案维护和确认人群分类；但注意，知识库对健康管理师是只读的，他们不能改膳食库和运动库内容，只能引用。患者走微信端，能操作预约、查询报告、评估、健康日记，但 PRD 里没有给患者端展开独立的字段设计，这说明移动端的细节基本由前后端在开发阶段自行补齐，文档只是把入口和流程画了出来。

这个角色划分直接决定了权限设计：知识库是「管理员维护、健管师只读」，评估结果是「健管师可写、患者可查」，系统管理是「仅管理员可见」。你如果把它翻译成菜单树，就等于大部分业务页面挂给健康管理师，基础数据维护页面挂给管理员，患者端单独是一套轻量 UI。我在看过大量 PRD 之后的一个习惯是：先画「角色 × 模块 × 操作」矩阵，再落到具体页面，不然开发到权限这一层又会回来反复确认。

2.2 预约管理流程：从套餐维护到到诊确认

预约管理是整条业务链的入口，PRD 给了一张很完整的流程图：健康管理师先维护体检项、组合、套餐，维护预约设置，然后进入预约，选择预约项目，完善预约信息，确认预约；接着健康管理师查看预约信息，确认是否预约成功，不成功就走取消分支，成功则进入预约成功状态。

整个流程可以拆成三段：

• 配置段：维护检测项、检测套餐、预约设置，包括用日历排开诊时间、批量导入开诊时间。这是整个预约系统的地基，套餐不维护好，患者端根本选不到项目。
• 下单段：预约类型分电话预约和微信预约，患者选择预约项目、完善信息、确认预约。电话预约由健康管理师代操作，微信预约由患者自己操作，两条入口最终落到同一条预约记录。
• 确认段：健康管理师在预约列表里看到全部预约，通过电话回访确认患者是否按时到诊，然后把预约状态改成对应状态。

这里有一个容易被忽略的设计点：预约列表的数据结构里同时放了婚姻状态、出生日期、性别、年龄这些会员冗余字段。为什么列表要冗余这些信息？因为健康管理师在回访前就需要判断对方是不是需要特殊对待的群体，如果每次都要去会员档案里查一遍，工作效率会低很多。所以把展示字段冗余在预约列表里，是合理的查询优化手段。检测套餐字段同理，预约记录里除了套餐 ID，还应冗余套餐名称，因为套餐可能会被管理员改造，历史预约记录不能被影响。

2.3 评估与干预流程：一份问卷如何变成干预方案

健康评估的流程在 PRD 里有两条路径。第一条是患者到诊后，健康管理师先判断他是否做过评估；如果没做过，就现场选择评估问卷、填写评估信息、生成评估报告；如果做过，就直接查看之前的评估结果。第二条是患者自己在公众号/微信端做健康评估，填写问卷后直接生成报告，健康管理师在评估列表中查看结果。

两条路径最终都汇入健康干预流程：先判断患者是否完成体检和评估，没完成就先补；完成后根据评估结果和患者信息制定干预方案，确认人群分类，然后定期回访；回访发现方案无效就调整方案，有效则干预结束。

这条链路里最核心的设计是「预分类」。PRD 明确写了：患者评估后，系统对患者进行预分类，健康管理师根据患者信息进行确认分类。也就是说，系统先根据评估结果自动判断这个人大概属于哪个人群，然后人工再确认。这是典型的「机器推荐 + 人工确认」模式，既照顾效率又保留人的判断权。

2.4 我建议补上的状态机表

PRD 里没有画状态机，但所有流程描述都在暗示状态变化。如果开发前不把状态枚举定清楚，到联调阶段一定翻车。我一般会把预约、评估、干预三条线各抽出一组状态：

这套状态机不是 PRD 原文，但它是从 PRD 的流程图里反推出来的。开发时把状态枚举直接写进数据库字典，前端的按钮显隐、后端的接口校验就都有据可依了。

3. 会员与预约管理：数据结构字段级拆解

3.1 会员档案：为什么这份 PRD 要定义三十多个字段

会员档案是这份 PRD 里数据字典最完整的地方。它把档案分成了几类信息：身份信息、生理指标、病史背景、账号与状态。我把关键字段整理成组，方便你对照表结构设计：

为什么字段这么多？因为后续的健康评估、人群预分类、干预方案都要以这份档案为基础。比如预分类时，系统要结合年龄、性别、慢性病信息；制定干预方案时，要参考运动禁忌和既往史。字段多不是缺点，但开发时一定要区分「创建时必填」和「后续补录」：身份证号、手机号、健康管理师分配必须在创建会员时完成，身高体重这些体征可以等体检报告上传后回填。

这里还有个细节值得注意：PRD 的会员来源写得很清楚，包括到诊直接注册和预约到诊两种。到诊注册是健康管理师直接为患者建档；预约到诊是患者先在微信端产生预约记录，到诊后再由健康管理师完善档案信息。所以会员管理页面要支持「从预约记录一键创建会员档案」，而不是让健康管理师从头敲一遍信息。

3.2 报告上传与预约列表：两个容易被低估的子功能

报告上传看起来简单，其实业务规则很讲究。PRD 规定体检报告是手动上传，由健康管理师选择患者体检信息后上传；上传字段包括档案号、体检时间、姓名、手机号、检测套餐、报告状态和报告文件。其中「报告状态按照体检时间按顺序排列，最先检查的在最前面」——这句话实际上定义了列表的排序规则：不是按上传时间排序，而是按体检时间倒序排列。

这个排序规则如果前端不留意，就会做成「最新上传的放最上面」，健康管理师可能会找不到最早的那份报告。我在做类似系统时吃过这个亏，后来统一口径是：报告上传时间和体检时间分开，列表展示按体检时间排序，体检时间为空时按上传时间兜底。

预约列表的数据结构里，除了预约本身的字段，还带着婚姻状态、出生日期、性别、年龄。这一段我再提醒一次：这些字段是冗余展示字段，不是预约表应该存储的核心字段。建议的落库方式是预约主表存档案号、预约日期、预约类型、预约状态，性别年龄等通过档案号关联查询，但查询接口里做冗余返回。PRD 把冗余字段直接列在预约列表的字典里，本质上是告诉你「这个列表页面要展示这些列」，而不是「预约表要存这些字段」。理解这个区别，建表时才不会把会员字段重复塞进预约表。

3.3 落地推演：从 PRD 字段到物理表的步骤

把这份 PRD 的字段翻译成物理表，我会按下面几步走：

第一步，把文档里所有「数据结构」表格抽取出来，合并同类字段，建立字段清单。一份 PRD 往往有十几张字段表，分散在各功能描述里，不提前整理，开发时容易漏字段。

第二步，按业务对象分组成表。会员档案落在 member 表，报告上传落在 report 表，预约落在 appointment 表，套餐落在 package 表，检测项落在 item 表。以档案号为主键贯穿所有业务表。

第三步，识别字典字段。婚姻状态、档案状态、预约类型、预约状态这类字段，一律抽出为字典表，或者至少用枚举值统一约束，不要在业务表里随手写字符串。

第四步，确认哪些字段系统自动生成、哪些自动计算。档案号建议系统生成，出生日期根据身份证号自动提取，BMI 根据身高体重自动计算，年龄根据出生日期动态计算。这些逻辑要写进后端接口，不能放给前端随意输入。

第五步，做一次反向走查：从患者注册到报告上传，把所有页面对应到表字段，查一遍有没有字段无来源、有来源无字段。

这套方法不只适用于这份 PRD，任何以字段表为核心的需求文档都能这样落地。关键是把「文档结构」翻译成「数据结构」时，不要照搬字段名，而是先识别每个字段属于哪个业务对象、由谁产生、在哪个环节更新。

4. 健康评估与干预：指标标准化与模板化

4.1 指标管理的「左右临界值」设计

健康评估模块是这份 PRD 的技术含量所在，而指标管理则是评估模块的核心。PRD 中指标管理的数据结构有六个关键字段：序号、指标名称、正常参考值、单位、针对性别、左/右临界值。

这里有一段业务规则值得细读：左右临界值为实际评估对照值，正常参考值为显示值；同一指标针对性别不同，正常参考值会有不同。这说明设计者把「展示」和「判定」拆开了。正常参考值给患者看，左右临界值给系统算。

举个例子，一个指标的判定逻辑是：

如果 检测值 在 左临界值 和 右临界值 之间：判定为正常 如果 检测值 超出右临界值：判定为异常偏高 如果 检测值 低于左临界值：判定为异常偏低

而正常参考值只是展示层的一个范围字符串。这套设计的好处是，不同指标的正常参考值显示方式和判定方式可以各自独立调整：显示层改了不影响判定逻辑，判定逻辑改了不用动前端展示。开发时我建议把左右临界值拆成两个数值字段left_threshold和right_threshold，而不是存一个字符串，否则每次判定都要解析字符串，既慢又容易出错。

指标还有一个「针对性别」字段，这意味着一张指标表里同一指标可能有多条记录，按性别区分。建表时唯一索引建议设计为「指标名称 + 针对性别」联合唯一，避免同性别同指标重复录入。

PRD 还写到体质测评、心理测评、风险测评三套评估方式，每一套都有新增评估、查看结果、条件查询评估信息。而且评估问卷和题库在系统管理里有独立的维护入口，说明评估内容是可配置的，不是写死在代码里。也就是说，评估系统和题库系统之间是「题库定义问卷、问卷产生结果、结果关联指标」的关系。

4.2 预分类、确认分类与干预方案模板

健康干预模块的起点是人群分类。PRD 的人群分类数据结构里，人群分类字段明确标注为「系统根据患者评估结果进行预分类」，同时还有一个健康管理师字段。整段设计是：系统先根据评估结果给患者打一个预分类标签，健康管理师查看患者信息后确认这个分类，确认后才进入制定干预方案阶段。

这个流程要落地，前端需要两个列表：一个是预分类列表，展示系统自动分类结果，状态为待确认；另一个是已确认列表，展示健康管理师确认后的分类结果。后端要提供两个操作：确认分类、重新分类。PRD 没有明说预分类的规则是什么，但既然评估结果来自指标判定，那预分类就应该是根据指标异常的数量和程度做规则映射。比如多个核心指标异常，预分类为高风险人群；全部正常，分类为一般人群。这套规则在开发阶段需要和业务方确认，PRD 只负责把流程框架定下来。

干预模板的数据结构设置了模板标题、关键词、适用人群、方案目标、启用状态、备注，以及运动方案、膳食方案、健康方案。注意「适用人群」这个字段，它和人群分类必然有关联。我在设计时会用分类编码做关联键，模板里applicable_category存的就是人群分类字典的编码，健康管理师制定方案时，系统按人群分类自动过滤可选模板。

这里还要区分「模板」和「方案」：模板是提前维护的通用内容，方案是针对具体患者定制的实例。制定方案时，健康管理师从模板里选运动、膳食、健康三套内容，再结合患者个体情况调整。很多团队在这里会犯一个错误，就是把模板字段和方案字段混在一张表里，导致同一行数据既像模板又像实例，后期根本没法统计。正确做法是模板一张表、方案一张表，方案通过字段引用模板 ID。

4.3 知识库怎么支撑模板生成

知识库是给干预模块供应的素材库，PRD 把它拆成评估建议、健康方案、运动项目库、膳食库、疾病库、宣教内容六类。实际展开的数据结构有评估建议库、膳食库、运动项目库三张表，每一张都定义到字段级。

膳食库的字段包括编码、食品名称、所属类型、100g 含能量、蛋白质含量、脂肪含量、建议人群、备注。运动项目库的字段包括编码、项目名称、运动强度、千步当量、运动时间、年龄区间、运动方法、注意事项。这些字段的价值在于让干预方案可量化：膳食方案能算能量摄入，运动方案能算运动量，而不是一句「多吃蔬菜多运动」这种空话。

在实际建表时，评估建议库要和评估指标关联，运动项目库要支持按强度筛选，膳食库要支持按营养成分检索。健康干预模板选择运动方案和膳食方案时，本质上是从这些库中筛选后组合。我建议模板与知识库内容之间用多对多关系表，因为一个模板往往包含多个运动项目和多个膳食条目，模板与项目之间是多对多，不是一对一的单行文本拼接。PRD 里把运动方案、膳食方案、健康方案直接作为文本字段放在模板表里，是一种简化写法；落地时如果希望模板真正可复用、可调整，就一定要拆关系表。

4.4 把 PRD 描述推成规则伪代码

把前面几节连起来，评估到干预的完整链路可以表达成这样一段伪代码：

# 指标判定：通过左右临界值判断单个指标是否异常 def evaluate_metric(value, left_threshold, right_threshold): if left_threshold <= value <= right_threshold: return "normal" return "abnormal" # 评估汇总：一份问卷对应多个指标，汇总异常项 def summarize_assessment(metric_results): abnormal_items = [r for r in metric_results if r["status"] == "abnormal"] if len(abnormal_items) >= 3: return "high_risk" if len(abnormal_items) > 0: return "medium_risk" return "general" # 模板匹配：根据人群分类查找可用的干预模板 def match_templates(category, template_list): return [t for t in template_list if t["applicable_category"] == category]

这段代码的作用是帮助你理解 PRD 没写明的规则部分：evaluate_metric 对应指标管理里的左右临界值判定，summarize_assessment 对应系统预分类，match_templates 对应健康管理师在制定方案时筛选模板。实际项目的判定规则一定比这个复杂，比如异常指标要分主次、要结合年龄性别、要有历史数据对比，但框架是这个框架。开发前把这段伪代码拿去和业务方过一遍，比对着 PRD 猜要高效得多。

4.5 知识库与干预模板的权限边界

这段本来应该在系统管理里说，但因为涉及知识库和干预的实际使用，放到这里更合适。PRD 的权限规则是：系统管理员可以对评估建议库、膳食库、运动项目库进行增删改查，健康管理师仅可以查看。这不是一句废话，它决定了知识库所有写操作都要做角色校验，前端要隐藏或禁用编辑按钮，后端接口要做权限注解。尤其是批量导入功能，如果知识库支持 Excel 导入，导入接口必须走管理员权限校验，而且导入后要有操作日志记录，方便追溯是谁改了哪条知识数据。

5. 避坑与排查：这份 PRD 里没写明白的地方

这份 PRD 整体质量不低，字段定义足够细，流程也有图，但它不是完美的。下面这五处是我拆解时认为最容易让开发翻车的地方，每条都按「现象 → 原因 → 解决」来讲。

5.1 表格命名残留：文章、频道、问答、活动

现象：这份 PRD 的数据结构表格里，会员档案对应的表名叫「文章管理」，报告上传对应的表名叫「频道管理」，预约列表对应的表名叫「问答管理」，评估问卷对应的表名叫「活动管理」，指标管理对应的表名叫「类型管理」。

原因：文档是从某个通用 PRD 模板复制过来的，表格里的字段内容改成了业务字段，但表名没改，或者改了模块标题却漏了表名。这是典型的模板残留问题。

解决：开发前先做一次全局搜索，把「文章管理」「频道管理」「问答管理」「活动管理」「类型管理」这些词全部捞出来，对照实际业务映射成会员档案、报告上传、预约列表、评估问卷、指标管理等真实表名。这个工作最好在需求评审阶段就做完，不然测试用例写出来都是错位的。

5.2 预约状态机不闭环：取消之后怎么办

现象：预约管理的流程图里有一条「预约取消」的分支，但整个预约管理功能列表里，只有预约查询、预约列表、新增预约、日历预约、批量导入、预约设置、取消预约、检测项管理、套餐管理这些操作，没有说明取消预约后号源怎么处理、患者怎么重新预约。

原因：PRD 把「取消预约」当成一个动作写了，但没有深入到取消后的业务规则。这属于需求文档常见的主流程完整、异常分支缺失问题。

解决：开发前主动定义取消规则。我会把状态机补成：待确认 → 已预约 → 已到诊 / 已取消，已取消后对应的预约时段释放，患者可重新预约；同时取消操作需要记录取消人和取消时间，便于运营复盘爽约率。你如果不补这一段，测试阶段就会发现取消预约后时段还占着，患者无法再次预约。

5.3 评估结果与指标关联是黑匣子

现象：健康评估模块说「生成评估报告」，指标管理也说「评估根据指标限定内容进行评估」，但整份文档没有写评估结果是由哪些指标、通过什么规则计算出来的。

原因：PRD 把评估规则当成业务逻辑留给开发去咨询业务方，但开发如果没有咨询，就会自己拍脑袋写一个规则，做完发现和业务预期不一致。

解决：拿到文档后第一时间把这个问题抛给产品和业务方，列出评估问卷对应的指标清单，逐项确认判定规则。如果业务方也说不清，先按 4.4 的伪代码框架实现一个基础版：指标判定是否异常，异常项汇总后映射人群分类，后续再补充权重、复杂规则。关键是要把判定规则做成可配置，而不是写在代码里。

5.4 三套「方案」字段高度相似，容易混

现象：干预模板里有「运动方案、膳食方案、健康方案」，制定方案的数据结构里也是「运动方案、膳食方案、健康方案」，人群分类里还有「健康管理师」字段。三层结构字段长得几乎一样，很容易在开发时合并成一张表。

原因：PRD 用同一套名词描述模板和实例，没有明确区分「预置模板」和「患者实例」两个概念。模板是给所有患者复用的，方案是针对单个患者定制的。

解决：落库时分两层。模板表存模板 ID、适用人群、启用状态，以及关联的知识库项目；方案表存患者档案号、模板 ID、健康管理师 ID、实际执行的运动项目和膳食条目。界面命名也分开：模板管理、方案制定、工作台执行。这样统计健康管理师工作量时直接按方案表分组，清晰明了。

5.5 权限规则只有一句话

现象：统计分析模块的工作量统计规则写着「根据权限限定查看人员」，系统管理里有菜单管理和权限设置，但管理员权限、健康管理师查看数据范围的边界都没有展开。结果是开发只知道要控制，不知道控制到什么粒度。

原因：PRD 把权限设计省略了，只留了一句模糊的话。这在需求文档里很常见，因为作者默认权限是后台通用功能。

解决：按 RBAC 模型落地，至少做三级权限：菜单权限控制左侧导航栏，按钮权限控制新增/编辑/删除按钮，数据权限控制健康管理师只能看到自己名下患者的数据。工作量统计页面要通过数据权限拦截，确保一个健康管理师查不到另一个健康管理师的干预量。别等到联调时再补权限，那时改动成本非常高。

6. 把 PRD 用起来：反向核对九步

6.1 用九步核对法把文档走透

这套 PRD 最实用的用法，不是从头到尾读一遍，而是把它当核对清单，走一遍反向验证。我处理这类文档时固定做九步：

第一步读用户角色定义，画角色权限矩阵；第二步读功能摘要，画功能树；第三步把全篇所有「数据结构」字段表导出成一份字段清单；第四步查模板残留，修正所有错误表名；第五步抽公共字典字段，统一枚举；第六步画三条主流程的状态机，补全异常分支；第七步逐条核对每段「业务规则」，看是否有歧义；第八步列出文档里没定义的事项，如评估计算规则、权限粒度、取消预约后的号源处理；第九步拿原型工具快速走查一遍主流程，让业务方确认没有遗漏。

做完这九步，这份 PRD 就不再是「一份文档」，而是变成了「一份需求基线」。后面的开发、测试、验收都能以这套基线为参照。这里附上我整理好的 PRD 原文件与上述核对表，资源包里已经打包好，可以直接作为你内部评审的对照材料。

6.2 一个教训成了习惯

我做过的健康类项目里，凡是跳过第五步、第六步直接进开发的，后期几乎都要返工：要么表名对不上需求描述，要么取消预约流程卡住。后来我接手新 PRD 时强制规定，必须先出权限矩阵和状态机表再排开发计划，这两张纸出了，这轮需求的地基才算打牢。希望这套拆解手法帮到你，少踩几个我看到过的坑。

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