企业官网建设流程全解析

简介：面向健康管理系统产品设计与需求梳理场景的PRD参考资料，核心围绕传智健康项目的数据结构管理、角色权限与功能流程展开，适合产品经理、需求分析人员及医疗健康类项目学习者对照理解业务建模方法。压缩包内仅含1个docx文档，约890KB，正文以需求说明书形式组织，涵盖会员管理、预约管理、健康评估与健康干预等模块的结构图、特性描述和操作流程。已有600人学习下载。文档对指标序号、指标名称、参考值、单位及适用性别等字段定义较细，并区分用户、医护人员和管理员角色，可用于梳理健康管理平台的信息架构、编写需求文档或开展课程案例复盘，帮助读者快速把握预约与评估业务的整体链路。

1. 需求立住：一套健康管理系统先要跑通哪条主线

健康管理机构的日常运营里，最容易断的从来不是设备，而是流程：预约靠电话本记、评估靠纸质问卷、干预方案靠健康管理师个人经验口口相传，患者做完体检之后报告压在抽屉里，下次复诊又得从头问一遍。这套健康管理系统的产品需求文档（PRD）就是为接上这些断点而写的——PC 管理端给管理员和健康管理师用，微信端给患者用，把会员建档、体检预约、健康评估、健康干预、知识库与运营统计装进同一条业务主线。

它适合两类人：正在做毕设或课程设计、需要一份结构完整的需求文档作参照的学生；以及要给中小型健康管理机构出一版可交付需求蓝图的从业者。整套方案真正值钱的地方不是页面画了多少张，而是数据字典和业务规则定得够不够细——档案号怎么生成、指标临界值怎么判定、预分类由谁拍板，这些才是后面开发和验收时反复被翻出来看的部分。

2. 总体设计：三类角色、双端入口与七个模块的职责划分

在动手画任何一个页面之前，先要把「谁在哪个端、对哪片数据做什么」定死。这份需求文档把系统切成七个模块，但模块不是并列摆着的，而是围绕一条「预约—到诊—评估—干预—回访」的主线咬合在一起。下面按角色、模块、端三个维度拆。

2.1 角色分层：管理员、健康管理师、患者各自的操作面

需求文档里只给了三类角色，看似简单，实际权限边界很容易做糊。我的处理原则是按数据域分，不按页面分：

这张表里最容易被忽略的是最后一行和倒数第二行的交叉点：患者在微信端提交的自评问卷，健康管理师在 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. 验收与答辩：用一条业务主线把所有功能串起来演示

这类系统的验收最怕按菜单点一遍：会员管理点一下、预约管理点一下、评估点一下，评委看完记不住任何一个功能。我习惯的做法是准备一条完整的测试数据，从预约走到回访，全程用同一个患者，让评委看到数据是怎么在模块之间流动的。验收前先把这张检查表过一遍：

答辩时的讲述顺序也有讲究：先花一分钟讲角色和主线，让评委建立地图；然后用那条测试数据演示一遍完整流程，中间在评估和干预两处停下来讲设计取舍，比如为什么指标要拆性别两行、为什么方案要存快照、为什么取消预约要回滚号源。这三处取舍讲清楚，比展示二十个页面更能说明你真的想过问题。评委追问「如果系统分错类怎么办」，答案就在预分类要人工确认这个设计里，顺着答即可。

从那以后我每次带人做这类系统，都要求先把一条主数据从预约走到回访跑通，再回头补界面和报表，顺序反了就要返工。希望帮到你。

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