门诊排队 — 项目原型设计+概要设计

2026秋软工实践 门诊排队——项目原型设计+概要设计

团队「门诊排队」第二次团队作业：完成了用户端问诊小程序的可交互原型、UML 概要设计、数据库设计，以及配套的可运行 Web 版实现（FastAPI 后端 + 前端页面，44 项自动化测试通过）。

一、作业格式描述

项目 内容
作业所属课程 H202601软件工程与软件工程实践
作业要求 2026秋软工实践团队作业-第二次（原型设计+概要设计）
作业的目标 在第一次需求分析与选题的基础上，完成可交互的原型设计（用户端+后台管理）与概要设计：用 UML 表达系统结构、说明领域 Agent 与软件的集成方式，完成数据库设计（ER 图、关系模型、ORM 映射），制定后续开发计划与成员分工，并建立 GitHub 团队仓库沉淀全部设计文档。
团队名称 门诊排队
团队成员学号-名字 102401431-丘南星、102401422-陈嘉俊、102401426-薛强龙、102402128-李韩远、102402129-梁洪睿、102402137-翁齐文、102402131-马天鸿、102402130-林晓捷、102401425-薛昌建、102401415-林豪、102401433-肖志渊、102401428-魏怡健

二、团队与项目简介

队名「门诊排队」
项目：智能导诊与挂号导航助手，定位为「诊前分诊导航的行动指引」：

症状输入 → 急症拦截 → 多轮追问 → 结构化报告

系统面向"不知道该挂哪个科、面对挂号平台无从选择"的患者，输出
「主推科室 + 备选科室 + 判断依据 + 挂号指引 + 院内导航 + 沟通话术 + 就医提醒」的结构化报告。
不做诊断、不开处方、不替代医生，全程标注"仅供参考，不替代医生诊断"。项目需求依据见第一次作业《软件需求规格说明书》，本文聚焦原型设计与概要设计。

三、原型设计

3.1 墨刀原型（在线链接）

用户端「问诊小程序」：https://modao.cc/proto/djKmUlT6to17c228Y8MJ7d/sharing?view_mode=read_only&screen=rbpVa6d0lkNEKZqxS

共 5 个页面：启动页 → 对话页 → 多轮追问 → 急症拦截页 → 导诊报告页。原型已导出 PNG，见 3.5 节。

说明：本项目无后台管理端——知识库（科室规则/红旗词）以 JSON 为唯一编辑源、由后端脚本维护，不面向运营人员提供可视化后台；如需后台管理界面，可在后续版本补充。

3.2 原型亮点

  1. 结论前置的结构化报告卡片：主推科室 + 备选科室 + 判断依据 + 挂号、导航、话术、提醒一次给全，用户拿到的是"可执行的行动指引"。
  2. 急症拦截红色告警：命中"胸痛伴出冷汗""大出血"等高危词立即跳转红色告警页，提供「拨打 120」「返回修改」两个动作，终止常规分诊流程。
  3. 一键复制就诊话术：话术根据用户提供的症状信息自动生成，是挂号后向医生描述症状的陈述（起病时间、部位、性质、伴随症状、人群特征），解决"不知道怎么跟医生描述症状"的痛点。
  4. 多轮追问状态可视化：追问按「部位→性质→时长→人群」逐步补齐，不重复询问，用户能感知进度。
  5. 隐私优先：不要求微信授权或手机号，会话以随机 UUID 标识，结束即销毁。
  6. 与真实后端联动：除墨刀设计稿外，团队已实现可运行的 Web 前端 + FastAPI 后端（Agentic RAG 四步流程、44 项自动化测试通过），演示时"界面是设计、逻辑是真实系统"。

3.3 可运行与演示

  • Web 演示页：启动后端后访问 http://127.0.0.1:8000（真实调用 /api/v1/chat，支持追问/报告/急症三种交互，前端为按墨刀设计 1:1 复刻的页面）
  • 离线交互原型：不依赖网络，双击 HTML 即可演示完整流程（本地模拟后端逻辑）
  • 微信开发者模式：v1 小程序工程可在微信开发者工具中本地运行

3.4 上架说明与演示方式

微信小程序的上架存在两个现实门槛：

  1. 审核周期较长：小程序提交审核通常需要数周乃至更久，且需反复整改；
  2. 大模型类目资质要求：涉及大模型能力的类目一般需提供相关合作协议或资质证明。

对于课程项目，这两点在有限周期内难以满足。因此项目的最终呈现方式调整为：

  1. 网页版（主要形式）：后端 FastAPI + Web 前端页面，本地或服务器部署即可访问，不受小程序审核限制；网页版交互与原型一致（症状输入 → 追问 → 报告卡片 → 一键复制话术）。
  2. 微信开发者模式演示（辅助形式）：小程序工程（v1 初版代码已归档）可在微信开发者工具中以开发者模式本地运行演示，不经过上架审核流程。

开发者模式演示仅用于课程展示，不对外发布；若后续需要正式上线小程序，需完成类目资质与合作协议后再提交审核。

3.5 原型界面

注：墨刀导出的清晰度不高，高清效果可在分享链接中查看
（ https://modao.cc/proto/djKmUlT6to17c228Y8MJ7d/sharing?view_mode=read_only&screen=rbpVa6d0lkNEKZqxS ）

墨刀原型：启动页

墨刀_page1

墨刀原型：对话页

墨刀_page2

墨刀原型：多轮追问

墨刀_page3

墨刀原型：急症拦截页

墨刀_page4

墨刀原型：导诊报告页

墨刀_page5

四、概要设计

4.1 系统架构与领域 Agent 集成方式

系统采用前后端分离的四层架构：

展示层   墨刀原型（问诊小程序） / Web 演示前端（墨刀复刻版）
        对话气泡 · 结果卡片 · 急症告警 · 一键复制话术
接口层   FastAPI：POST /api/v1/chat · GET /session · GET /health
编排层   Orchestrator（Agent 流程调度 + 会话状态机）
能力层   NLU 信息抽取 · 急症拦截 · 多轮追问 · RAG 检索 · LLM 结构化生成
知识层   SQLite（科室白名单/症状规则/红旗信号/医院/知识文档）+ 会话缓存

领域 Agent 的定制思路（Agentic RAG）：

环节 做法 防幻觉/安全设计
信息抽取 规则词典 + 正则把口语抽成结构化字段（部位/性质/时长/伴随/人群） 可审计、零成本；LLM 兜底可选
急症拦截 417 条红旗词纯代码匹配（Ⅰ级 201/Ⅱ级 216，WS/T 591—2018） 不经过大模型，宁可多拦不可漏拦
多轮追问 状态机按优先级追问缺失字段，去重、上限 3 轮、支持改口重置 追问有上限，不会无限循环
知识检索 规则库（434 条规则 / 1849 个关键词）匹配 + 向量证据 top5 判断依据只来自检索资料
结构化生成 提示词硬性约束 + Pydantic Schema + 科室白名单枚举校验 LLM 返回枚举外科室直接拒绝

定制前后对比（以"我肚子疼了两天，偶尔反酸"为例）：通用大模型可能猜测甚至编造科室、不追问；本系统只能从 1849 个症状关键词命中的科室中选，按优先级追问，输出 8 字段结构化报告——这就是领域定制带来的可预测性与安全性。

4.2 UML 设计

用例图（患者用户 + 大模型服务作为次参与者；9 个用例及 include/extend）：

01-用例图

活动图（用户/前端与后端双泳道：输入校验 → 急症短路 → 追问循环 → 白名单校验与降级）：

02-活动图

类图（Orchestrator 等 9 个系统类 + 6 个 Pydantic 数据类及关联）：

03-类图

时序图（Agentic RAG 完整时序：抽取→追问→检索→生成→校验；alt 片段为急症拦截）：

04-时序图

协作图（"改口修正"场景下七个对象的协作与编号消息流）：

05-协作图

4.3 数据库设计

详见《门诊排队_数据库设计说明书》。要点：

  • 5 张表：departments（科室白名单，LLM 输出枚举基准）、symptom_rules（症状-科室规则，核心分诊知识）、high_risk_signals（急症红旗信号）、hospitals（福州三甲挂号渠道）、knowledge_docs（检索证据语料）
  • 联系：科室 1—N 症状规则（recommended_dept 外键）；备选科室 alt_depts 用 JSON 存（有意反范式，逻辑 N:M 虚线标注）
  • ORM 映射：后端采用 Pydantic + sqlite3，实体类（SymptomInfo/SessionState/TriageResult 等）与库表/缓存存储的映射关系已在说明书 2.4 节完整给出
  • 存储策略：知识表落库（SQLite，启动自动建表灌种子）；会话状态与任务结果不落库（内存/Redis，TTL 1h），会话结束即销毁，符合隐私设计
  • 真实数据量：departments 32、symptom_rules 1849 行（434 条规则）、high_risk_signals 417 行（Ⅰ级 201/Ⅱ级 216）、hospitals 3、knowledge_docs 20

ER图-导诊助手

【图11：数据库 E-R 图】

五、团队协作记录

5.1 预期开发计划（周表 + 里程碑）

周次 时间 开发安排 里程碑与产出
第9周 11.10–11.16 前后端联调：前端完整接入 /api/v1/chat，覆盖追问/结果/急症三种响应；统一错误处理与加载态 M1 核心链路贯通：可演示完整 Agent 流程；接口联调测试用例全绿
第10周 11.17–11.23 知识库扩充：补科室规则与红旗词（标注来源）；接入真实大模型（Kimi）并回归结构化输出与枚举校验 M2 真实模型可用：LLM 输出回归测试通过
第11周 11.24–11.30 前端体验打磨：结果卡片、复制话术、急症页动画；会话存储切换 Redis 预研；部署方案选型 前端完成度 90%；部署方案文档
第12周 12.01–12.07 上线部署：服务器部署 + 域名/HTTPS；邀请同学真实试用收集反馈 M3 上线运行：公网可访问地址 + 测试方式
第13周 12.08–12.14 按反馈修复缺陷；异常场景兜底完善；性能与安全复查 缺陷修复清单；异常处理说明
第14周 12.15–12.21 项目收尾：缺陷清理、文档与博客定稿、GitHub 仓库整理 M4 项目收尾：文档与代码定稿

5.2 成员分工表

成员 学号 角色 负责的详细开发部分
丘南星 102401431 项目经理 / 统筹答辩 需求与进度管理、里程碑跟踪、答辩 PPT、原型与设计评审、项目整合
陈嘉俊 102401422 测试 / 前期调研 用户需求问卷调研、测试用例设计与执行、急症高危词全量回归
薛强龙 102401426 博客撰写 / 仓库 团队博客撰写与发布、GitHub 仓库管理与提交规范
李韩远 102402128 后端 数据库设计与文档（ER 图、关系模型、ORM 映射）、LLM 网关与就诊话术
梁洪睿 102402129 后端 / 测试 任务四前后端联调、API 边界测试、联调记录
翁齐文 102402137 后端 编排器 Orchestrator、多轮追问状态机、改口修正
马天鸿 102402131 后端 知识库扩充（症状规则/红旗词）、数据导入与来源标注
林晓捷 102402130 后端 / 测试 NLU 信息抽取、RAG 规则检索、单元测试
薛昌建 102401425 前端 / UML UML 活动图/时序图/协作图；前端联调
林豪 102401415 前端 前端页面实现（墨刀复刻版）与联调记录、v1 小程序归档与演进说明
肖志渊 102401433 原型 / 调研 墨刀原型设计、现场调研照片素材
魏怡健 102401428 前端 / UML UML 用例图/类图；前端交互细节

5.3 协作过程记录

后端组协作记录（任务分工与代码提交）：

协作_后端组

前端组协作记录（原型设计与 UML 图稿分工）：

协作_前端组

  • 需求与设计：使用腾讯文档协同撰写需求规格说明书；原型用墨刀多人协作设计；设计评审通过在线会议完成。
  • 代码管理：GitHub 团队仓库按功能分支开发，每位成员使用自己的账号提交到个人分支，由项目经理统一合并 PR，保证每人都留下贡献记录。
  • 测试：测试组维护《联调测试用例表》，安全相关（急症红旗词）做全量回归，任何人改动必须运行 pytest；当前 44 项自动化测试全部通过。
  • 文档同步：系统设计说明书、数据库设计说明书、博客与代码保持同步更新。

5.4 近期迭代与变更记录（11-07 ~ 11-09）

知识库扩充：在原有规则基础上补充常见口语部位与俗语表达（覆盖泌尿、妇科、骨科、口腔等），并补充眼科、精神心理科、内分泌科、疼痛科等科室的症状-科室规则与口语变体。规则库 425 → 434 条，关键词行 1775 → 1849 行。

缺陷修复：① 问"腹痛/胸痛"被追问部位（部位词典缺单字兜底）→ 补齐并重排"长词优先"顺序；② 含"眼"字的部位俗语被误判为"眼部"（单字兜底词顺序问题）→ 词典顺序修复，同类隐患（手指、额头、脚趾、手腕）一并修复；③ 部位命名自然化（按规范部位名输出）。

就诊话术重构：话术从"挂号用"改为挂号后向医生描述症状的陈述，包含起病时间、部位、性质、伴随症状与人群特征。

前端：按墨刀导出稿 1:1 复刻 Web 演示页（启动页、对话页、急症页、报告弹窗、复制话术弹窗），并接入真实后端。

六、GitHub 仓库与设计文档

项目 链接
GitHub 团队仓库 LinkWalker/Hospital-Guide
系统设计说明书 系统设计说明书.pdf
数据库设计说明书 数据库设计说明书.pdf

成员贡献概览：

1

posted @ 2026-11-09 19:14  天使十二  阅读(17)  评论(0)    收藏  举报