26软工实践 门诊排队 团队展示与选题报告
26软工实践 门诊排队 团队展示与选题报告
| 项目 | 内容 |
|---|---|
| 作业所属课程 | H202601软件工程与软件工程实践 |
| 作业要求 | 2026秋软工实践团队作业第一次：团队展示、选题报告与需求分析 |
| 作业的目标 | 围绕真实就医需求，选择医疗导诊领域，设计能够结合专业知识和规则提供分诊导航指引的智能体与软件方案。 |
| 团队名称 | 门诊排队 |
| 团队成员学号-名字 | 102401431-丘南星、102401422-陈嘉俊、102401426-薛强龙、102402128-李韩远、102402129-梁洪睿、102402137-翁齐文、102402131-马天鸿、102402130-林晓捷、102401425-薛昌建、102401415-林豪、102401433-肖志渊、102401428-魏怡健 |
一、团队展示
1.1 队名与项目
我们的队名是“门诊排队”，项目名称为智能导诊与挂号导航助手。队名来自去医院时常见的排队与挂号体验。我们希望帮助不知道该挂哪个科、面对挂号平台无从选择的患者，减少挂错号、退号和重新排队的困扰。
项目选择医疗服务中的诊前导诊与挂号导航领域，定位为分诊导航的“行动指引”。系统围绕症状输入、急症拦截、多轮追问和结构化报告四个步骤，为用户提供科室推荐、挂号与院内导航指引、沟通话术和就医提醒。
1.2 队员风采与成员分工
团队共有12名成员，分为统筹与答辩、前期调研、博客撰写、后端与核心逻辑、前端与交互五个小组。成员按期望角色和项目任务分工，并在调研与开发阶段协作。
| 成员 | 学号 | 擅长技术 | 兴趣爱好 | 期望角色 | 项目分工 |
|---|---|---|---|---|---|
| 丘南星 | 102401431 | Vibe Coding | “不务正业” | 项目经理 | 统筹与答辩 |
| 陈嘉俊 | 102401422 | 基础算法、常见数据结构、代码调试与问题排查 | 玩游戏 | 测试 | 前期调研 |
| 薛强龙 | 102401426 | Java、Linux、Git | 游戏、健身 | 后端 | 博客撰写 |
| 李韩远 | 102402128 | 后端代码处理 | 后端技术处理 | 后端 | 后端与核心逻辑 |
| 梁洪睿 | 102402129 | Vibe Coding | 无 | 都行 | 后端与核心逻辑 |
| 翁齐文 | 102402137 | 使用 AI 编程 | 听歌、游戏 | 后端 | 后端与核心逻辑 |
| 马天鸿 | 102402131 | Python | 音乐、游戏 | 后端 | 后端与核心逻辑 |
| 林晓捷 | 102402130 | 数据结构与算法、数据可视化 | 羽毛球 | 测试 | 后端与核心逻辑 |
| 薛昌建 | 102401425 | C/C++、Python、Linux、Git 协作 | 游戏、开发环境与工具链 | 前端，测试 | 前端与交互 |
| 林豪 | 102401415 | 软件开发 | 阅读 | 前端 | 前端与交互 |
| 肖志渊 | 102401433 | 前端设计 | 电子游戏 | 前端 | 前端与交互 |
| 魏怡健 | 102401428 | C++ | 听歌 | 前端 | 前端与交互 |
1.3 团队首次合照
图1：团队首次线上项目会议合照。
1.4 团队愿景
我们希望用技术缩小患者与医疗服务之间的信息差，让在挂号大厅不知所措的人少走弯路、少一份焦虑。通过清晰、受控的分诊导航指引，帮助患者找对科室、准备好沟通，让就医第一步更加从容。
二、选题报告与项目规划
2.1 选题背景与真实需求
身体不适时，患者需要先在挂号平台或医院大厅作出科室选择。密集的科室选项、复杂的指示牌和对症状归属的不了解，可能让患者在就医第一步就陷入迷茫。挂错号之后，还需要退号、重新挂号和排队，增加时间成本与情绪负担。
我们通过线上问卷与线下实地走访，了解用户在选科、挂号和院内导航中的实际困难。
2.2 线上问卷结果
数据来自团队开展的用户需求调查，共有28份有效答卷，受访者均为在校学生，其中27人年龄在18—25岁，1人为60岁及以上。结果反映的是本次学生样本的反馈。
| 调研指标 | 调查结果 | 对应需求 |
|---|---|---|
| 不知道该挂哪个科 | 18人，占64.29% | 输入症状后给出科室建议。 |
| 挂号平台科室名称太多、看不懂 | 18人，占64.29% | 结论前置，降低选择负担。 |
| 不清楚手机挂号方式或渠道 | 10人，占35.71% | 提供挂号方式说明或入口。 |
| 到院后发现挂错科，需要重挂 | 6人，占21.43% | 提供清晰的行动指引。 |
| 判断科室的困难程度 | 平均2.54分（5分制） | 通过追问补齐信息，帮助用户准备分诊。 |
2.3 线下实地观察
团队成员前往协和医院挂号大厅实地走访，观察院内导视、收费窗口以及患者持挂号单询问方向等情况。现场观察与线上反馈共同说明：患者需要的不只是一个科室名称，还包括能够理解和执行的挂号、导航及沟通指引。
图2：团队调研实拍，多方向地面导视。
图3：团队调研实拍，院内登记区域。
图4：团队调研实拍，收费窗口。
2.4 目标用户与使用场景
目标用户为在就医前不清楚应挂哪个科、难以理解挂号平台科室选项，或不善于向分诊台、医生描述症状的患者。前期问卷直接覆盖的是在校学生群体。
| 使用场景 | 用户遇到的问题 | 项目提供的帮助 |
|---|---|---|
| 在家准备就医 | 有不适症状，但不知道从哪个科室开始 | 输入症状并补充关键信息，查看推荐科室与备选科室。 |
| 前往医院途中 | 担心挂错号，不知道怎样描述症状 | 查看推荐依据、导航指引和就医提醒，复制沟通话术。 |
| 面对挂号页面或院内导视 | 科室选项多、方向复杂 | 查看挂号入口和院内导航信息。 |
2.5 用户对导诊结果的期待
受访者希望导诊建议同时回答“该挂什么科”和“接下来怎么做”。对结果内容及后续操作的选择如下：
| 期待内容或操作 | 人数与比例 |
|---|---|
| 建议科室和备选科室 | 20人，占71.43% |
| 判断依据 | 16人，占57.14% |
| 附近医院推荐及距离 | 16人，占57.14% |
| 医院挂号方式说明 | 21人，占75% |
| 可复制的就诊话术 | 13人，占46.43% |
| 就医提醒 | 21人，占75% |
| 获得导诊建议后，希望得到挂号入口或步骤 | 20人，占71.43% |
最常见的使用场景是自己身体不适、不确定挂什么科（24人，占85.71%）；帮助家中老人或孩子就诊的有14人，占50%。这些反馈支持项目提供科室建议、依据、挂号指引、沟通话术和就医提醒。
2.6 项目价值与业务边界
项目围绕“找对科室”这一具体任务，帮助用户减少选科困扰与沟通成本。针对医疗场景中的大模型幻觉问题，团队确定以医学知识库、科室规则与代码约束模型输出的设计方向。
系统不做在线问诊，不进行疾病诊断，不开处方，不承诺疗效，不替代医生。系统全程标注“仅供参考，不替代医生诊断”。识别到预设高危信号时，系统终止常规分诊推荐，引导用户线下就医或提示立即拨打120。
2.7 领域智能体的定制思路
团队采用Agentic RAG思路，将自然语言信息抽取、规则引擎、知识检索、多轮状态管理与结构化生成组织到同一任务流程中。
- 从用户口语化描述中提取部位、性质、时长及伴随症状。
- 使用预设高危词汇库和关键词匹配引擎进行急症强阻断。
- 维护会话状态，针对缺失信息继续追问，避免重复询问已经记录的内容。
- 优化查询词，检索权威医学知识库与科室规则。
- 约束模型参考检索资料组织回答，按照规定字段生成科室、导航、沟通话术与就医提醒。
2.8 项目实施规划
团队围绕“症状输入—急症拦截—多轮追问—结构化报告”推进项目。前端与交互小组负责用户输入、对话和结果操作；后端与核心逻辑小组负责信息抽取、规则判断、会话状态、知识检索及结构化输出。统筹答辩、前期调研和博客撰写由对应成员负责，团队根据阶段需要跨组协作。
项目开发将优先完成核心流程，再推进前后端与智能体集成。软件完成后上线运行，并提供访问地址和必要的检查方式。
三、需求分析文档
需求分析文档：智能导诊与挂号导航助手-软件需求规格说明书
浙公网安备 33010602011771号