企业官网建设流程全解析

简介：面向健康管理系统产品设计与开发学习者的《传智健康PRD文档》是一份完整的产品需求说明书，适用于产品经理、Java 后端开发者及毕业设计选题者了解互联网医疗类项目的需求梳理思路。文档按标准 PRD 规范组织，从目的、范围与用户角色描述切入，依次给出产品总体流程、功能摘要，再展开会员管理、预约管理、健康评估、健康干预四大模块的产品结构图、特性描述与功能操作路径。其中健康评估部分对数据结构类型管理作了细化，涵盖序号、指标名称、参考值、单位、针对性别等字段的含义与取值约束，可直接作为建表与接口设计的参考依据。资源包内共 1 个 docx 文件，约 890KB，为单文档结构，目录层级清晰，便于按章节快速定位流程图与页面交互说明。目前已有 600 人学习下载，适合需要对照真实需求文档练习用例拆分、流程建模与模块开发的学习者参考。

1. 需求先立住：一套健康管理系统 PRD 到底在替谁做决定

接手一份健康管理系统 PRD，多数人的第一反应是先排页面：登录、列表、表单、图表。真正让这份需求说明书站得住的是另一件事——先想清楚健康管理师每点一次鼠标，系统要替他记住什么。某健康管理机构原来的流程是纸质量表加表格文件，患者做完体检，评估靠人对着参考值一行行比，干预方案靠复制上一份再改几处，管理者想知道这个月到检多少人还得挨个问。这套系统要接的就是这段活：会员建档、预约排期、评估出报告、干预出计划、知识库兜底、统计给管理者看数。它适合两类读者：要交健康管理系统毕设或课程设计的学生，需要一份能拆成模块、能落到数据表的完整需求；要给机构交付方案的从业者，需要一份能对着评审讲清边界的产品说明。七个功能模块、三类角色、两条端（PC 管理端与微信端），就是这份文档的全部战场。

2. 角色与主流程：三类用户、一条主线和七个模块的边界

一份 PRD 最先被评审追问的从来不是界面好不好看，而是「谁能看到谁的数据」。角色定义含糊，后面所有模块的权限判断都会变成补丁摞补丁。这套系统只有三类角色，但每一类的数据边界差别很大，必须在需求阶段就划死。

2.1 三类角色的权限切面

管理员的权限是全量增删改查，但要加一条限制：知识库里的运动项目、膳食、疾病、评估建议，管理员可写，健康管理师只读。这条规则看起来是小事，实际是防止健康管理师各自维护一套膳食库，最后统计口径全乱。健康管理师的边界不是「全部患者」，而是「分配给自己的患者」，评估、干预、回访都只能在自己名下患者的范围内操作。患者侧在微信端，只能看到自己的预约、报告、评估结果和健康日记。

权限实现上通常分两层：菜单级控制「看不看得到这个页面」，数据级控制「看得到哪些行」。很多课设只做了第一层，答辩时被问一句「健康管理师 A 能不能改健康管理师 B 的患者档案」就卡住了。正确的做法是在所有患者相关的查询里强制带上健康管理师 ID 条件，而不是靠前端传参。

2.2 从建档到回访的主线，和挂在旁边的四条旁路

这套系统的业务主线是一条单向链：建档 → 预约 → 到检 → 评估 → 预分类 → 制定干预方案 → 执行与回访 → 结束或调整。主线上的每一步都依赖上一步的产出，建档产出档案号，预约产出到检记录，到检产出体检报告，评估消费报告和问卷，分类消费评估结果，干预消费分类和知识库。

挂在主线旁边有四条旁路。第一条是知识库维护，它不参与主线流转，但干预方案必须从里面取运动、膳食、疾病条目，所以它是「先有数据才能跑通」的前置条件。第二条是系统管理，菜单、权限、用户、题库、问卷，属于上线前配置。第三条是统计分析，只读，从主线的过程数据里聚合。第四条是套餐与检查项维护，服务于预约。

把旁路和主线分开画，好处是评审时能一句话说清优先级：主线不通，系统等于没做；旁路不全，系统等于不好用。

2.3 功能摘要写成可验收的模块清单

原始需求里的功能摘要是一张扁平的任务表，四十多行，读起来像流水账。落到方案里我会重排成「模块 — 子模块 — 验收点」三层，每一行都要能回答「怎么算做完了」。这样既方便排期，也方便最后对账。

这张表最大的价值不是好看，是让「健康评估」这种听起来一个模块的东西暴露出它内部其实是三套问卷加一个指标配置，工作量差三倍。

3. 数据结构设计：档案号做主键，指标表管住评估的命门

这份需求里最容易埋雷的不是流程，是字段。原始文档给了七八张数据结构表，字段类型一律写「文本」「字符型」，可修改、可为空两列填得也很随意。真按这个建表，跑两个月数据就会脏。

3.1 会员档案：一张宽表扛不住三十多个字段

会员档案在需求里列了三十多个字段，前半段是身份信息（档案号、姓名、性别、身份证号、手机号、民族、出生日期、邮箱、婚姻、职业、文化程度、健康管理师、档案状态），后半段是体征（身高、体重、舒张压、收缩压、呼吸频次、体温、腰围、臀围、BMI、血氧饱和度）加五类病史。硬塞进一张表有两个问题：体征每次体检都会变，宽表只能覆盖不能留历史；病史字段长文本，和身份信息混在一起查询会拖慢列表页。

我一般会拆成主表加体征子表，体征表按测量时间追加记录，主表只保留最新一次的快照字段供列表展示。

-- 会员主表：身份信息 + 最新体征快照 CREATE TABLE member ( archive_no VARCHAR(32) PRIMARY KEY COMMENT '档案号，全局唯一，生成后不可改', name VARCHAR(32) NOT NULL COMMENT '姓名', gender TINYINT NOT NULL COMMENT '性别 1男 2女', id_card VARCHAR(18) NOT NULL COMMENT '身份证号，唯一索引', phone VARCHAR(11) NOT NULL COMMENT '手机号，登录账号', password VARCHAR(64) NOT NULL COMMENT '登录密码，加盐哈希存储', birthday DATE NULL COMMENT '出生日期，由身份证号解析', manager_id BIGINT NOT NULL COMMENT '所属健康管理师，数据权限依据', status TINYINT DEFAULT 1 COMMENT '档案状态 1启用 0停用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_id_card (id_card), UNIQUE KEY uk_phone (phone), KEY idx_manager (manager_id) ) COMMENT='会员档案主表'; -- 体征记录表：一次体检/一次到诊一条，保留历史 CREATE TABLE member_physical ( id BIGINT PRIMARY KEY AUTO_INCREMENT, archive_no VARCHAR(32) NOT NULL COMMENT '关联会员档案号', height DECIMAL(5,1) NULL COMMENT '身高 cm', weight DECIMAL(5,1) NULL COMMENT '体重 kg', sbp SMALLINT NULL COMMENT '收缩压 mmHg', dbp SMALLINT NULL COMMENT '舒张压 mmHg', bmi DECIMAL(4,1) NULL COMMENT 'BMI，由身高体重计算后落库', measure_time DATETIME NOT NULL COMMENT '测量时间，报告排序依据', KEY idx_archive_time (archive_no, measure_time) ) COMMENT='会员体征历史表';

档案号做主键这件事要写进需求约束里：生成规则可以是「年月日 + 4 位流水」，一旦生成不允许修改。原始文档在会员档案表里把档案号标成「不可修改」，但在报告上传表里又把它当外键引用，如果允许改，历史报告就全断链。身份证号解析出生日期、BMI 由身高体重算，这两个是典型的「能算出来就不要让人填」，减少录入错误。

3.2 评估指标表：正常参考值和左右临界值必须分两列

需求里有一段业务规则写得非常关键：左右临界值为实际评估对照值，正常值参考为显示值；同一指标针对性别不同，正常参考值会有不同。这句话翻译成设计就是——指标表里必须同时存「给患者看的文字范围」和「给程序判断用的数值边界」，而且按性别分版本。

CREATE TABLE indicator ( id BIGINT PRIMARY KEY AUTO_INCREMENT, code VARCHAR(32) NOT NULL COMMENT '指标编码，如 SBP/GLU', name VARCHAR(64) NOT NULL COMMENT '指标名称，如收缩压', unit VARCHAR(16) NULL COMMENT '单位，如 mmHg', gender TINYINT NOT NULL COMMENT '针对性别 0通用 1男 2女', ref_display VARCHAR(32) NULL COMMENT '展示用正常参考值，如 90-140', left_critical DECIMAL(8,2) NULL COMMENT '左临界值，低于此值判偏低', right_critical DECIMAL(8,2) NULL COMMENT '右临界值，高于此值判偏高', status TINYINT DEFAULT 1 COMMENT '启用状态', UNIQUE KEY uk_code_gender (code, gender) ) COMMENT='评估指标定义表';

判定逻辑放在服务层而不是前端，原因很实在：同一份问卷在 PC 端和微信端都能提交，前端判定等于判定规则写两遍，改一次漏一次。

def judge_indicator(indicator, value): """按指标临界值给出评估结论 indicator: 指标行，含 left_critical / right_critical value: 本次测量值 返回 normal / low / high / unknown """ if value is None: return "unknown" # 未填写不判定，避免空值被误判为正常 if indicator["left_critical"] is not None and value < indicator["left_critical"]: return "low" if indicator["right_critical"] is not None and value > indicator["right_critical"]: return "high" return "normal"

参数说明写清楚：left_critical和right_critical存的是判定边界，ref_display只用于报告展示。两者允许不一致——比如血糖的正常参考值展示成 3.9-6.1，但判定临界值可能按机构标准取 3.6-6.5，这是业务上真实存在的差异，混成一列就再也调不回来了。

3.3 知识库五张表：字段不同，抽象要一致

评估建议、健康方案、运动项目、膳食、疾病、宣教，这五类内容字段差异很大：运动项目有强度、千步当量、运动时间、年龄区间、运动方法、注意事项；膳食有能量、蛋白质、脂肪、建议人群；疾病库基本上是名称加描述。但它们的操作模式完全一样——管理员增删改查，健康管理师只读，被干预方案引用。

两种做法。一种是五张表各写各的 CRUD，代码量大但字段清晰。另一种是统一成knowledge_item主表加knowledge_attr扩展属性表，代码一套，字段靠配置。我倾向于折中：运动、膳食、疾病、评估建议各自建表，但共用一个code + name + type + status的基础字段规范，控制器层做统一的分页查询和状态开关，扩展字段各自处理。

关键在于所有知识库条目都要有一个逻辑删除标记。干预模板和干预方案会引用这些条目，物理删除会让历史方案的「运动方案」字段变成空白，打开就是黑匣子，查不到当初推荐了什么。

4. 三条主链路的落地：预约、评估、干预怎么从流程图变成接口

流程图在 PRD 里是最容易画得漂亮但落不了地的部分。这几张图的判断节点如果不对应到具体的状态字段，开发阶段就会出现「这个 if 到底写在哪」的扯皮。

4.1 预约链路：排班日历、套餐与到检确认

预约这条链上有三个主体：患者选号、健康管理师确认、管理员维护检查项与套餐。排班用日历形式按周维护开诊时间，每个时段有容量上限，取消预约要把号源释放回去。预约单的状态机建议只留五个状态，多了没人记得住。

// 预约状态流转：0待确认 1已确认 2已到检 3已取消 4已过期 const TRANSITIONS = { 0: ['1', '3', '4'], // 待确认可确认、可取消、可过期 1: ['2', '3', '4'], // 已确认可到检、可取消、可过期 2: [], // 已到检是终态，只能补报告 3: [], // 已取消终态 4: [] // 已过期终态 }; function canTransit(from, to) { return (TRANSITIONS[from] || []).includes(to); }

取消预约时必须同步把对应时段的已约数量减一，这个动作我建议放在同一个事务里，并且加行锁。血泪经验是：并发取消和预约撞在一起，号源数会漂，最后显示「已约 -1」，查起来极其费劲。到检确认是健康管理师的动作，确认之后才能在会员管理里给这个患者上传体检报告，两条链路在这里咬合。

4.2 评估链路：问卷作答到报告生成

评估有三套问卷：风险测评、体质测评、心理测评。流程分两条入口——患者到诊由健康管理师现场新建评估，或者患者在微信端自己填。两条入口写同一个接口，区别只在source字段。

提交后的处理顺序是固定的：先按问卷版本取题目和指标映射，再逐项判定，然后按「指标 + 结论」去评估建议库里匹配建议，最后生成报告并落库。报告必须存快照，包括问卷版本号、每个指标当时的临界值、匹配到的建议文本。不存快照的话，管理员哪天调了临界值，半年前的报告重新打开结论就变了，这在评审现场是致命问题。

def build_report(answers, indicator_map, advice_repo): """生成评估报告快照 answers: {指标code: 测量值} indicator_map: {指标code: indicator行}，按性别已过滤 """ items, matched = [], [] for code, value in answers.items(): ind = indicator_map.get(code) if not ind: continue result = judge_indicator(ind, value) items.append({ "code": code, "name": ind["name"], "value": value, "unit": ind["unit"], "ref_display": ind["ref_display"], "result": result, "left_critical": ind["left_critical"], # 快照，防止后续调参影响历史 "right_critical": ind["right_critical"] }) matched.extend(advice_repo.match(code, result)) return {"items": items, "advices": dedup(matched), "created_at": now()}

注意gender过滤要在取指标映射时就做掉，不要留到判定阶段。同一指标男女参考值不同，如果映射表里两行都在，判定时取到哪一行完全取决于字典顺序，这种 bug 测不出来，上线才炸。

4.3 干预链路：预分类、模板实例化与回访

干预的起点是评估结果的预分类。系统按规则给患者打上人群标签，健康管理师逐条确认或调整。预分类规则通常按指标结论组合：血压偏高 + BMI 偏高归入某类，血糖异常归入另一类。规则本身建议做成可配置的表达式，不要硬编码在代码里，否则每加一类人群就得发一次版。

分类确认后是选模板。干预模板包含方案目标、适用人群、运动方案、膳食方案、健康方案，其中后三项来自知识库。模板实例化成患者方案时要复制一份内容，而不是存知识库条目 ID 就完事——模板改了，历史方案不能跟着变。

回访是干预工作台的核心动作，每次回访记录回访时间、方式、患者反馈、方案是否有效。有效的继续执行到结束，无效的回到方案调整。这条回路决定了统计分析里「干预方案总量、回访量、完成量」三个指标能不能算出来，所以回访记录必须是独立的表，不能只更新方案状态。

4.4 报告上传与统计口径

体检报告上传是会员管理里的一个子功能，需求写得很轻，实际上是文件加状态两件事。文件存对象存储或本地目录，数据库只存路径和元信息；状态按体检时间排序，最早的排最前，这样健康管理师能一眼看到哪份报告还没上传。

统计分析的三个指标要提前把口径写进需求，否则开发完对不上账：

-- 工作量统计：按健康管理师和时间区间聚合 SELECT m.name AS manager_name, COUNT(DISTINCT p.id) AS plan_total, -- 干预方案总量 COUNT(DISTINCT v.id) AS visit_total, -- 回访量 COUNT(DISTINCT CASE WHEN p.status = 3 THEN p.id END) AS finish_total -- 已完成 FROM sys_user m LEFT JOIN intervention_plan p ON p.manager_id = m.id AND p.created_at BETWEEN :start AND :end LEFT JOIN follow_visit v ON v.plan_id = p.id AND v.visit_time BETWEEN :start AND :end WHERE m.role = 'HEALTH_MANAGER' GROUP BY m.id, m.name;

参数:start和:end由前端时间选择器传入，注意时间区间要按自然日补齐到 23:59:59，否则当天的数据永远统计不到。另外这个查询必须叠加权限过滤：健康管理师本人只能看自己那行，管理员才能看全部。

5. 避坑与常见问题：五处最容易翻车的地方

5.1 数据一致性上的三个坑

档案号被改，历史报告全断链。现象是会员列表里改了个档案号，报告上传记录、评估记录全部查不到。原因很直接：档案号被当成业务主键到处引用，但需求只写了「不可修改」没有在数据库层约束。解决办法是档案号做主键并禁写，需要更正时走「作废重建 + 档案合并」流程，历史记录跟着迁移，绝不允许原地改。

指标临界值缓存了单份。现象是男性患者的血糖被判成偏高，女性患者同样的值被判正常。原因是把指标定义在启动时加载成单例缓存，gender维度被吞掉了。解决办法是缓存 key 带上性别，或者在加载时就按性别拆成两份映射表，用的时候直接取。

知识库条目被删，历史方案开天窗。现象是打开半年前的干预方案，运动方案一栏是空的。原因是模板和方案都存了知识库条目 ID，管理员把条目物理删了。解决办法是知识库统一逻辑删除，同时方案实例化时复制一份文本快照，双保险。

5.2 流程与权限上的两个坑

同一患者多次体检，报告排序错乱。现象是最新报告排到了最下面。原因是按「报告状态」排序而不是按体检时间排序，状态值恰好和上传顺序反着来。解决办法是明确排序键为体检时间倒序，状态只做筛选不做排序。

权限只做了菜单级。现象是健康管理师 A 通过改 URL 参数能打开健康管理师 B 的患者档案。原因是接口层只校验了「有没有这个菜单权限」，没校验「这条数据是不是你的」。解决办法是在数据访问层统一注入manager_id条件，管理员角色才放行全量，这条规则要在需求文档里写成不可协商的约束。

5.3 需求文档本身的坑

还有一个容易被忽略的点：原始需求里大量字段的「可修改」「可为空」标注前后矛盾，比如档案号在会员表里标不可改，在报告表里又被当作可传入参数。落到方案里我会加一节「字段约束总表」，把所有主键、唯一键、必填、只读字段集中定义一遍，开发照着建表，测试照着写用例，评审照着提问，三方对同一份东西。

6. 验收与答辩：拿一份 PRD 撑住评审的四个动作

验收这件事，很多人以为是把功能点过一遍，实际上评审看的是「这份需求有没有能力约束后面的设计和开发」。我一般会准备四个动作，按顺序走一遍，基本能覆盖八成提问。

第一个动作是走主线。从新建一个会员开始，到预约、到检、上传报告、发起评估、确认分类、制定方案、记录一次回访，把这条链完整跑一遍。跑不通的地方就是需求没写清楚的地方，比如评估结果怎么触发预分类、预分类的规则是谁配的。这条链跑顺了，方案的主体就立住了。

第二个动作是对字段。拿会员档案和指标管理这两张表，逐列问三个问题：这个字段能不能为空、能不能改、改了影响谁。答不上来的，说明约束没定义。特别是档案号、身份证号、手机号这三个唯一性字段，以及指标的性别维度，必须能当场说清楚。

第三个动作是查权限。至少验证三种越权：健康管理师访问他人患者、患者访问他人报告、健康管理师修改知识库。这三条过了，权限设计才算闭环。

第四个动作是对数字。把统计分析里的三个指标手工算一遍，和系统跑出来的比。对不上就查回访记录是不是独立表、时间区间是不是补齐了、权限过滤是不是生效了。这一步最能暴露模型设计的问题。

答辩现场最常被问的一句是「如果患者重复建档怎么办」。这个问题的标准答法不是「加个校验」，而是说清楚唯一性建在身份证号上、档案号只是业务编号、重复时走合并流程并保留原档案的作废标记。能把这句话讲明白，说明数据模型是真想过的。

从那以后我每次做这类业务系统的需求文档，都会先把字段约束总表和权限矩阵写出来，再动笔画界面。界面可以后补，约束一旦漏了，后面全是补丁。希望这套拆法能帮到你。

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