健康管理系统PRD设计：业务主线、权限边界与评估干预闭环

简介面向健康管理系统产品设计与需求梳理场景的PRD参考资料核心围绕传智健康项目的数据结构管理、角色权限与功能流程展开适合产品经理、需求分析人员及医疗健康类项目学习者对照理解业务建模方法。压缩包内仅含1个docx文档约890KB正文以需求说明书形式组织涵盖会员管理、预约管理、健康评估与健康干预等模块的结构图、特性描述和操作流程。已有600人学习下载。文档对指标序号、指标名称、参考值、单位及适用性别等字段定义较细并区分用户、医护人员和管理员角色可用于梳理健康管理平台的信息架构、编写需求文档或开展课程案例复盘帮助读者快速把握预约与评估业务的整体链路。1. 需求立住一套健康管理系统先要跑通哪条主线健康管理机构的日常运营里最容易断的从来不是设备而是流程预约靠电话本记、评估靠纸质问卷、干预方案靠健康管理师个人经验口口相传患者做完体检之后报告压在抽屉里下次复诊又得从头问一遍。这套健康管理系统的产品需求文档PRD就是为接上这些断点而写的——PC 管理端给管理员和健康管理师用微信端给患者用把会员建档、体检预约、健康评估、健康干预、知识库与运营统计装进同一条业务主线。它适合两类人正在做毕设或课程设计、需要一份结构完整的需求文档作参照的学生以及要给中小型健康管理机构出一版可交付需求蓝图的从业者。整套方案真正值钱的地方不是页面画了多少张而是数据字典和业务规则定得够不够细——档案号怎么生成、指标临界值怎么判定、预分类由谁拍板这些才是后面开发和验收时反复被翻出来看的部分。2. 总体设计三类角色、双端入口与七个模块的职责划分在动手画任何一个页面之前先要把「谁在哪个端、对哪片数据做什么」定死。这份需求文档把系统切成七个模块但模块不是并列摆着的而是围绕一条「预约—到诊—评估—干预—回访」的主线咬合在一起。下面按角色、模块、端三个维度拆。2.1 角色分层管理员、健康管理师、患者各自的操作面需求文档里只给了三类角色看似简单实际权限边界很容易做糊。我的处理原则是按数据域分不按页面分角色入口核心动作数据边界管理员PC 管理端菜单、权限、用户、题库问卷、知识库、检测项与套餐维护全平台字典、配置与知识库内容健康管理师PC 管理端建档、报告上传、评估、预分类确认、制定干预、回访自己名下患者的过程数据知识库只读患者微信端预约、查报告、自评问卷、健康日记仅本人档案与本人记录这张表里最容易被忽略的是最后一行和倒数第二行的交叉点患者在微信端提交的自评问卷健康管理师在 PC 端能看到结果但不能替患者改答案健康管理师能看知识库但不能改知识库因为知识库是全院共用的内容资产改了会影响别人的干预方案。需求文档里对知识库写得很明确——系统管理员可以增删改查健康管理师只可以查看。这条规则如果开发阶段放松成「有编辑按钮就给了权限」后面做权限验收时会很难看。另一个细节是患者账号的来源。患者不是自己注册的账号来自会员档案里的手机号和登录密码两个字段档案由健康管理师在到诊时建立或由预约信息完善而来。这意味着「账号体系」和「会员体系」是同一套数据不需要单独做一张用户表给患者只在角色表里挂一个患者标识即可。很多同学在这里会多建一张患者登录表结果手机号改一次要同步两处纯属给自己找麻烦。2.2 模块串联七个模块如何围成一条业务主线七个模块分别是会员管理、预约管理、健康评估、健康干预、知识库、统计分析和系统管理。它们不是七个独立的小系统主线是这样的患者微信端预约体检 → 到诊后健康管理师建档或完善档案 → 上传体检报告 → 现场评估或读取患者自评结果 → 系统按评估结果给出人群预分类 → 健康管理师确认分类 → 从干预模板生成个性化方案 → 定期回访并判断方案是否有效 → 无效则调整方案 → 运营数据进统计看板。把这条线画出来之后模块的上下游关系就清楚了模块主要角色关键产出下游消费方会员管理健康管理师会员档案、体检报告评估、干预、统计预约管理患者、健康管理师、管理员预约单、开诊排班、检测套餐会员建档、报告上传健康评估健康管理师、患者评估记录、评估报告人群预分类、干预健康干预健康管理师干预方案、回访记录统计分析知识库管理员评估建议、运动项目、膳食、疾病、宣教内容评估报告、干预模板统计分析管理者工作量与运营指标管理决策系统管理管理员菜单、权限、用户、题库问卷全平台知识库和系统管理是两个「底座」模块一个供内容一个供权限和问卷结构它们不直接产生业务单据但被上面五个模块反复引用。做概要设计时把这两块放最后做是很常见的翻车起点——评估报告要引用评估建议库干预模板要引用运动库和膳食库底座没搭好上面的功能只能先写死假数据回头再拆一遍。2.3 端与主数据PC 端和微信端必须共用一套档案PC 管理端和微信端是两套界面但绝不能是两套数据。需求文档里患者的微信端只做四件事预约、查报告、做评估、记健康日记。这四件事的数据源全部指向同一张会员档案主表和同一张评估记录表。患者改不了自己的身高体重血压这些体征数据只能由健康管理师在到诊时录入患者能改的只有健康日记这类主观记录。这条约束在开发时体现为接口分层微信端只有查询本人档案、提交自评问卷、创建预约、写健康日记这几类写接口其余全部只读。好处是数据口径唯一统计报表拉出来的会员总量和微信端能看到的患者数永远对得上。如果两端各存一份档案运营统计里的「会员总量」和患者端的实际用户数就会出现差值这种问题排查起来非常费劲属于典型的黑匣子。2.4 非功能性约束文件、留痕与性能底线需求文档一般不写性能指标但健康管理这个场景有几条底线值得提前写进设计说明。第一是体检报告的文件存储报告是 PDF 或图片体积不小表里只存文件标识和元信息文件本身走对象存储上传失败要能重试删除报告只做逻辑删除并保留操作人。第二是留痕评估记录、干预方案、回访记录都带创建人和时间健康管理师的每一次方案调整都要能追溯到人这在后续做工作量统计和责任界定时会用到。第三是并发不高的场景下不要过度设计预约日历的号源扣减用数据库行锁加唯一约束就够别一上来就上分布式锁把一个课程设计做成运维灾难。3. 会员档案与预约管理主表字段与预约状态机的设计取舍会员和预约是整个系统的入口也是数据量最大的两张表。这一章把字段设计和状态流转讲透因为这两块一旦返工评估和干预模块全部要跟着改。3.1 会员档案主表身份、体征和病史放一张表的取舍需求文档给出的会员档案字段相当完整大致分三组身份与账号信息档案号、姓名、性别、身份证号、手机号、登录密码、民族、出生日期、邮箱、婚姻状态、职业、文化程度、健康管理师、档案状态、备注、体征数据身高、体重、舒张压、收缩压、呼吸频次、体温、腰围、臀围、BMI、血氧饱和度、病史信息既往史、家族史、过敏史、病史、慢性病。字段全放在一张表是最直接也最合理的做法因为这些数据总是被一起读取健康管理师打开档案就要看到全部评估报告也要引用体征和病史。拆成三张表再做关联查询在这个数据量级下没有收益。落成 DDL 大致是这样CREATE TABLE member_archive ( archive_no VARCHAR(32) NOT NULL COMMENT 档案号业务主键, name VARCHAR(32) NOT NULL COMMENT 姓名, gender CHAR(1) NOT NULL COMMENT 性别 M/F, id_card VARCHAR(18) NOT NULL COMMENT 身份证号唯一, mobile VARCHAR(11) NOT NULL COMMENT 手机号兼作微信端登录账号, login_pwd VARCHAR(64) NOT NULL COMMENT 登录密码加盐哈希后存储, nation VARCHAR(16) DEFAULT NULL COMMENT 民族, birthday DATE DEFAULT NULL COMMENT 出生日期建档时由身份证解析写入, email VARCHAR(64) DEFAULT NULL COMMENT 邮箱, marital_status VARCHAR(8) DEFAULT NULL COMMENT 婚姻状态, occupation VARCHAR(32) DEFAULT NULL COMMENT 职业, education VARCHAR(16) DEFAULT NULL COMMENT 文化程度, manager_id BIGINT NOT NULL COMMENT 分配的健康管理师用户ID, archive_status TINYINT NOT NULL DEFAULT 1 COMMENT 档案状态 1启用 0停用, remark VARCHAR(255) DEFAULT NULL COMMENT 备注, height DECIMAL(5,1) DEFAULT NULL COMMENT 身高 cm, weight DECIMAL(5,1) DEFAULT NULL COMMENT 体重 kg, dbp SMALLINT DEFAULT NULL COMMENT 舒张压 mmHg, sbp SMALLINT DEFAULT NULL COMMENT 收缩压 mmHg, breathe_freq SMALLINT DEFAULT NULL COMMENT 呼吸频次 次/分, temperature DECIMAL(4,1) DEFAULT NULL COMMENT 体温 ℃, waist DECIMAL(5,1) DEFAULT NULL COMMENT 腰围 cm, hip DECIMAL(5,1) DEFAULT NULL COMMENT 臀围 cm, bmi DECIMAL(4,1) DEFAULT NULL COMMENT BMI按身高体重计算后落库, spo2 SMALLINT DEFAULT NULL COMMENT 血氧饱和度 %, past_history TEXT DEFAULT NULL COMMENT 既往史, family_history TEXT DEFAULT NULL COMMENT 家族史, allergy_history TEXT DEFAULT NULL COMMENT 过敏史, disease_history TEXT DEFAULT NULL COMMENT 病史, chronic_disease TEXT DEFAULT NULL COMMENT 慢性病, PRIMARY KEY (archive_no), UNIQUE KEY uk_id_card (id_card), UNIQUE KEY uk_mobile (mobile) ) COMMENT会员档案主表;几个字段的处理值得说明。档案号是业务主键不是自增 ID因为体检报告、预约单、评估记录都靠档案号关联自增 ID 一旦迁移环境就会乱。身份证号加唯一索引防止同一个人被建两次档手机号也加唯一索引因为它是微信端登录账号重复会导致登录歧义。出生日期按身份证号自动计算后落库而不是每次查询时现算——需求文档里明确写了「根据患者身份号自动计算」落库是为了让报表按年龄段分组时不用做函数运算索引也能用上。BMI 同理按身高体重计算后存一份快照因为体征会变历史报告里应该保留当时的 BMI而不是永远显示最新值。3.2 体检报告上传文件状态与按体检时间排序的规则体检上传模块的字段不多档案号、体检时间、姓名、手机号、检测套餐、报告状态、报告文件。规则有两条报告是手动上传选择患者和体检信息后上传报告列表按体检时间排序最先检查的排在前面。这里的设计要点是「报告状态」和「排序字段」分离。报告状态是业务状态通常就是未上传和已上传两态如果后续要加审核可以扩成待审核、已归档而排序用的是体检时间是业务时间不能用创建时间代替。很多同学图省事直接按create_time倒序结果补录一份三天前的报告它会跳到列表最前面健康管理师看到的时间顺序就乱了。正确做法是查询里显式写ORDER BY exam_time ASC, create_time ASC体检时间相同时用创建时间兜底保证顺序稳定。文件本身的处理表里存文件标识、原始文件名、大小和上传人文件实体放对象存储删除报告做逻辑删除记录删除人和删除时间。需求文档里没有写删除留痕但这是我在实际项目里养成的习惯——健康档案属于敏感数据任何删除动作都应该有后悔药。3.3 预约状态机从待确认到已到诊的流转与日历排班预约管理覆盖三方的动作患者在微信端选项目和时间下单健康管理师在 PC 端查看预约列表并确认患者是否到诊管理员在后台维护检测项、检测组合和套餐。预约列表的字段包括档案号、预约日期、姓名、手机号、预约类型电话预约或微信预约、预约状态、婚姻状态、出生日期、性别、年龄其中预约类型这个字段很有价值它能支撑后面统计线上线下预约占比。状态机的设计直接决定后续所有查询的口径我一般会落成下面这张表当前状态触发动作目标状态说明待确认健康管理师确认已确认电话回访确认到诊时间待确认患者或健管师取消已取消释放号源已确认到诊登记已到诊进入建档或报告上传环节已确认约定时间未到爽约计入统计可重新预约已确认取消已取消需填写取消原因对应的表结构CREATE TABLE appointment ( id BIGINT NOT NULL AUTO_INCREMENT, archive_no VARCHAR(32) NOT NULL COMMENT 档案号未建档患者可先存临时号, appoint_date DATE NOT NULL COMMENT 预约体检日期, slot_id BIGINT DEFAULT NULL COMMENT 开诊时段ID关联排班表, appoint_type TINYINT NOT NULL COMMENT 1电话预约 2微信预约, appoint_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待确认 1已确认 2已到诊 3爽约 4已取消, package_id BIGINT DEFAULT NULL COMMENT 预约的体检套餐, cancel_reason VARCHAR(128) DEFAULT NULL COMMENT 取消原因, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_date_status (appoint_date, appoint_status), KEY idx_archive (archive_no) ) COMMENT体检预约表;排班这块需求文档写的是「日历预约根据日历排开诊时间支持批量导入开诊时间」。实现上是一张排班表按日期和时段记录可预约名额预约创建时扣减、取消时回滚。这里有个必须提前想清楚的点取消和爽约都要回滚号源否则日历上显示已满、实际却空着运营会一直来问为什么约不上。批量导入开诊时间则要处理日期格式和重复导入的幂等同一日期同一时段导入两次不能生成两条排班。4. 健康评估与干预闭环指标字典、人群预分类与模板复用这一章是整个方案里业务规则最密的部分也是答辩时最容易被追问的地方。评估不是一个问卷页面而是一套「指标字典 → 问卷作答 → 结果判定 → 预分类 → 干预方案 → 回访验证」的规则链。4.1 指标管理正常参考值、左右临界值和性别维度的分工需求文档对指标管理的描述很短但信息量很大指标有名称、单位、正常参考值、针对性别、左右临界值左右临界值是实际评估对照值正常参考值仅用于显示同一指标针对性别不同参考值也不同。这三条规则决定了指标表怎么设计。我的做法是把「展示」和「判定」彻底分开ref_text存给人看的文字比如「90-120」可以带单位和描述lower_limit和upper_limit存参与程序判定的数值边界。判定时只读数值字段展示时才拼接文字。如果偷懒拿ref_text去解析数字做比较遇到「小于 5.6」或者「阴性」这种文案就直接崩了。CREATE TABLE eval_indicator ( id BIGINT NOT NULL AUTO_INCREMENT, seq_no VARCHAR(16) NOT NULL COMMENT 指标序号界面排序用, name VARCHAR(64) NOT NULL COMMENT 指标名称如收缩压, unit VARCHAR(16) DEFAULT NULL COMMENT 计量单位如 mmHg, gender_scope CHAR(1) NOT NULL DEFAULT A COMMENT 适用范围 A通用 M男 F女, ref_text VARCHAR(64) DEFAULT NULL COMMENT 正常参考值文案仅展示, lower_limit DECIMAL(8,2) DEFAULT NULL COMMENT 左临界值参与判定, upper_limit DECIMAL(8,2) DEFAULT NULL COMMENT 右临界值参与判定, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用, PRIMARY KEY (id), KEY idx_name_gender (name, gender_scope) ) COMMENT健康评估指标字典;性别维度用gender_scope表达同一条指标如果男女参考值不同就存两行一行 M 一行 F查询时按患者性别匹配匹配不到再回落到 A 通用行。这样做的好处是规则全部数据化运营改参考值不用改代码代价是指标名称会重复出现界面展示时要按名称聚合。左右临界值允许为空对应需求文档里「某些指标可能没有预设参考值」的情况判定时遇到空值就跳过该项不要当成异常。4.2 评估问卷风险、体质、心理三类测评共用一套引擎健康评估模块在需求文档里拆成三块风险测评、体质测评、心理测评每块都有新增评估、查看结果、按条件查询三个动作另外还有一个评估建议的增删改查。三块的流程完全一致——选问卷、填答案、生成报告——所以完全没必要写三套代码而是一套问卷引擎加一个eval_type字段区分。问卷和题库放在系统管理里维护题库管理管题目问卷管理管题目组合和评分规则。评估记录表只存结果不存过程CREATE TABLE eval_record ( id BIGINT NOT NULL AUTO_INCREMENT, archive_no VARCHAR(32) NOT NULL COMMENT 档案号, eval_type TINYINT NOT NULL COMMENT 1风险测评 2体质测评 3心理测评, paper_id BIGINT NOT NULL COMMENT 问卷ID, total_score DECIMAL(6,2) DEFAULT NULL COMMENT 问卷总分, conclusion VARCHAR(255) DEFAULT NULL COMMENT 评估结论摘要, eval_source TINYINT NOT NULL COMMENT 1健管师现场评估 2患者微信端自评, evaluator_id BIGINT DEFAULT NULL COMMENT 评估人微信端自评时为空, eval_time DATETIME NOT NULL COMMENT 评估时间, PRIMARY KEY (id), KEY idx_archive_type (archive_no, eval_type) ) COMMENT健康评估记录;评估报告由两部分拼成问卷得分算出的结论加上评估建议库里按指标和结果命中的健康建议。需求文档里评估建议库的规则写得很清楚——评估建议与评估结果关联根据指标关联内容推荐建议。所以报告生成不是把建议文案硬编码在页面里而是查建议库匹配。4.3 预分类与确认系统给建议健康管理师拍板健康干预的起点是人群分类。需求文档的流程是患者评估后系统做预分类健康管理师查看患者信息后确认分类。这个「预分类 人工确认」的设计是整套方案里我最认可的一处因为它承认了规则引擎的能力边界。落地时人群分类表至少要有这些字段档案号、姓名、性别、年龄、状态、系统预分类、健康管理师。状态区分待确认和已确认系统预分类是规则算出来的健康管理师确认时可以改判。改判要留痕——谁改的、从什么改成什么、什么时候改的。这条留痕在答辩时是加分项因为它回答了「如果系统分错了怎么办」这个问题不是让系统重新学而是让有资质的人来定系统只做初筛。预分类规则本身不用做得太玄学通常就是按评估结论和关键指标阈值组合命中比如血压和 BMI 同时超阈值归入某一类命中多条规则时按优先级取第一条并把命中依据存下来方便后续解释「为什么给我分到这一类」。4.4 干预模板与知识库三个库被方案引用的方式干预模块的核心是模板复用。需求文档写得很明白健康管理师提前维护干预模板模板包含标题、关键词、适用人群、方案目标、启用状态、运动方案、膳食方案、健康方案制定干预方案时通过知识库内维护的内容组成模板。也就是说模板不是自由文本而是对知识库条目的引用组合。知识库里跟干预直接相关的有三个库评估建议库、运动项目库、膳食库。运动项目库的字段包括项目名称、运动强度、千步当量、运动时间、年龄区间、运动方法、注意事项膳食库包括食品名称、所属类型、每 100 克能量、蛋白质含量、脂肪含量、建议人群。这些字段设计得挺专业千步当量这种指标不是随便写的做膳食和运动推荐时能直接换算。模板表的一种简化实现是把引用存成 ID 集合CREATE TABLE intervene_template ( id BIGINT NOT NULL AUTO_INCREMENT, title VARCHAR(64) NOT NULL COMMENT 模板标题, keywords VARCHAR(128) DEFAULT NULL COMMENT 模板关键词便于检索, crowd_type VARCHAR(32) NOT NULL COMMENT 适用人群分类, goal VARCHAR(255) DEFAULT NULL COMMENT 方案预计目标, enabled TINYINT NOT NULL DEFAULT 1 COMMENT 是否启用, sport_ids VARCHAR(255) DEFAULT NULL COMMENT 运动项目ID集合逗号分隔, diet_ids VARCHAR(255) DEFAULT NULL COMMENT 膳食ID集合逗号分隔, advice_ids VARCHAR(255) DEFAULT NULL COMMENT 评估建议ID集合逗号分隔, remark VARCHAR(255) DEFAULT NULL COMMENT 备注, PRIMARY KEY (id) ) COMMENT健康干预模板;用逗号分隔存 ID 是小项目的务实做法查询时一次取出再批量查详情比建三张关联表省事。代价是无法用外键约束保证引用有效性所以删除知识库条目时要先检查有没有模板在引用。规范做法当然是关联表但如果这是课程设计把取舍讲清楚比硬上关联表更有说服力。制定具体方案时从模板复制一份方案明细到患者名下允许健康管理师增删条目但模板本身不动。这里涉及一个后面会重点讲的坑方案到底存引用还是存快照。4.5 回访与方案调整干预闭环的最后一公里需求文档的干预流程图最后一段是「定期回访 → 判断是否有效 → 无效则调整方案 → 干预结束」。这一段如果只做方案制定不做回访整个干预模块就是个半成品。回访记录表至少要有档案号、方案 ID、回访日期、回访方式、回访内容、有效性判断、下次回访时间、回访人。有效性判断只有有效和无效两个值选无效时强制要求填写调整说明并生成一条新的方案版本旧版本保留。这样健康管理师的干预方案总量、回访量、完成量三个统计口径才有数据来源——统计分析模块的工作量统计正是按这三个数字加时间区间做的并且受权限限制健康管理师只能看自己的管理者能看全院的。5. 常见问题排查五处最容易翻车的设计点这一章列的五个问题都是我在类似项目里真实见过或者自己踩过的。共同点是需求文档里看不出来开发到联调阶段才爆发而且每一个都会连带影响评估和干预模块。5.1 指标性别分叉没生效评估结果男女一个标准现象同一份问卷男性患者和女性患者的评估结论一模一样但指标字典里明明配了男女不同的参考值。原因指标表里同一指标存了两行查询时只按指标名称匹配取到了第一行就返回gender_scope根本没进查询条件。更隐蔽的一种情况是回落到通用行的逻辑写反了先查 A 再查 M/F导致专用行永远命中不了。解决查询条件写成WHERE name ? AND gender_scope IN (?, A) ORDER BY FIELD(gender_scope, ?, A) LIMIT 1保证专用行优先、通用行兜底同时在指标管理界面加一条校验同一指标同一性别不允许重复配置从源头堵住脏数据。上线前用两组性别不同的测试档案各跑一遍评估对比报告结论这是最省事的验证方式。5.2 报告列表顺序乱补录一份旧报告就跳到最前现象健康管理师补录了三天前的一份体检报告结果它在列表里排到了第一条当天新上传的报告反而排在后面。原因排序字段用了创建时间而不是体检时间或者用了体检时间但没加第二排序键同一天多份报告的顺序不稳定。解决查询显式按exam_time ASC, create_time ASC排序体检时间为主、创建时间为辅。如果产品要求最新的在最前就整体倒序但一定要在需求文档里写死方向别让开发和测试各自理解。这类问题改起来只要一行 SQL但不改的话每天都会被问一次。5.3 取消预约后号源没回滚日历显示约满实际空着现象患者取消预约后当天日历上那个时段仍然显示已满新患者约不进去。原因取消逻辑只改了预约单状态忘了同步扣减排班表的名额或者回滚写在了事务外面异常时状态改了、名额没回。爽约状态同样容易漏。解决把「创建预约扣名额、取消或爽约回滚名额」封装成一个服务方法状态变更和名额变更放在同一个事务里排班表加乐观锁版本号防止并发覆盖。再补一条对账逻辑每天定时用预约单实际数量校准排班名额发现不一致就告警。这条对账是血泪经验人工发现永远比程序慢。5.4 干预模板引用的知识库内容被改历史方案跟着变现象管理员调整了某个运动项目的建议时长三个月前已经结束的干预方案里那条运动建议也跟着变了患者翻历史记录发现内容对不上。原因方案明细存的是知识库条目的外键引用展示时实时联查。知识库一改所有引用处全变。解决制定方案时把被引用条目的关键内容复制成快照存进方案明细字段包括条目名称、内容摘要、引用时的版本号。模板本身继续存引用没问题因为模板是「待用配置」患者名下的方案必须是「已发生事实」只能快照。这个原则可以推广到所有涉及审核和历史追溯的单据。5.5 知识库权限放太松健康管理师能改全院共用的内容现象验收时发现健康管理师账号能进知识库编辑评估建议改完之后其他人的评估报告推荐内容全变了。原因权限按菜单配的知识库菜单给了健康管理师查看权限但页面里的编辑按钮没做按钮级控制后端接口也没校验角色前端藏没藏都一样能调。解决后端接口统一加角色注解或拦截器写操作只放行管理员前端按钮按权限码控制显隐但只作为体验优化不作为安全边界。验收时专门用健康管理师账号直接调一次知识库的写接口确认返回无权限而不是只看页面上按钮有没有消失。6. 验收与答辩用一条业务主线把所有功能串起来演示这类系统的验收最怕按菜单点一遍会员管理点一下、预约管理点一下、评估点一下评委看完记不住任何一个功能。我习惯的做法是准备一条完整的测试数据从预约走到回访全程用同一个患者让评委看到数据是怎么在模块之间流动的。验收前先把这张检查表过一遍检查项判定标准留档证据预约到建档链路微信端下单后 PC 端能看到预约到诊后能建档并上传报告操作录屏指标性别分叉男女两组档案跑同一问卷结论按各自参考值判定两份报告截图预分类确认评估后生成待确认记录健管师改判后留痕流程截图与日志干预方案与回访方案可从模板生成回访判定无效后能生成新版本版本对比截图权限边界健管师账号调知识库写接口返回无权限接口返回截图答辩时的讲述顺序也有讲究先花一分钟讲角色和主线让评委建立地图然后用那条测试数据演示一遍完整流程中间在评估和干预两处停下来讲设计取舍比如为什么指标要拆性别两行、为什么方案要存快照、为什么取消预约要回滚号源。这三处取舍讲清楚比展示二十个页面更能说明你真的想过问题。评委追问「如果系统分错类怎么办」答案就在预分类要人工确认这个设计里顺着答即可。从那以后我每次带人做这类系统都要求先把一条主数据从预约走到回访跑通再回头补界面和报表顺序反了就要返工。希望帮到你。本文还有配套的精品资源点击获取