应用名称安心陪诊 Agent统一合集安心陪诊 AgentHarmonyOS 高校创新赛关键词标签harmonyos / AI Agent / 医疗陪诊老年陪诊需求分析家属、老人、医生三方到底缺什么摘要从三类角色的任务和焦虑出发梳理陪诊类产品的核心需求模型。 本系列基于“安心陪诊 Agent”完整项目从产品立项、UI、Agent、Web Demo、HarmonyOS 迁移和竞赛材料角度连续复盘。本文关键词需求分析、用户画像、陪诊系统、医疗流程。​编辑目录项目背景与本文重点场景拆解为什么这个问题值得做设计稿与页面结构Agent 或接口实现路径代码片段与工程细节安全边界、测试和可迁移性小结与下一步项目背景与本文重点安心陪诊 Agent 的定位很明确它不是诊断系统也不是线上问诊平台而是一个围绕真实就医流程做信息整理、任务拆解和家属协同的智能体原型。项目当前实现了可运行 Web Demo前端使用原生 HTML、CSS、JavaScript后端使用 Node.js 原生 HTTP 服务核心 Agent 采用本地规则与结构化输出提供 /api/plan 和 /api/chat 两个接口。视觉资产包括 image2 生成的项目总览、五页 UI 原型、Agent 流程图、桌面端和移动端演示截图以及一套 image2 风格演示 PPT。如果把这个项目迁移到 HarmonyOS本文提到的模块仍然成立页面层负责展示和交互服务层负责计划生成和对话组织数据层负责保存必要记录系统能力层再接入日历、提醒、语音和小艺智能体。也就是说当前 Web Demo 不是临时玩具而是为后续 HAP 真机演示预留了清晰骨架。​编辑​编辑场景拆解为什么这个问题值得做从 需求分析 的角度看老年陪诊需求分析家属、老人、医生三方到底缺什么 不是一个单点功能而是一条围绕真实就医行为展开的任务链。很多项目在介绍 AI 时会把重点放在“能回答问题”但安心陪诊 Agent 更关注“回答之后用户能不能行动”。这也是它适合写成技术文章的原因背后既有产品判断也有界面、接口、规则、测试和提交材料的工程约束。这一篇最重要的观察是医疗陪诊场景不能把复杂性全部推给用户。老人和家属在医院里的压力来自时间、窗口、材料、检查单、医生沟通和复查安排。产品如果只给一个聊天框用户仍然不知道下一步做什么所以本文会把 用户路径 拆成输入、处理、输出、验证四个层次。在真实就医前家属常常需要同时处理挂号、路线、证件、医保、药盒、检查单和老人情绪。到了诊室里医生真正需要的是清楚的事实哪里不舒服、持续多久、什么情况下加重、既往病史是什么、现在吃什么药。就医结束后又要把医嘱、复查时间、观察指标同步给家里其他人。安心陪诊 Agent 的价值就在于把这些散落的信息整理成可执行任务而不是让用户面对一大段泛泛的医疗说明。设计稿与页面结构为了让文章在 CSDN 上更有参考价值我不会只写“项目很好看”。更有价值的部分是说明为什么这么设计、怎么实现、哪里容易踩坑、如何验证。比如同样是生成清单直接给一段长文字和拆成卡片是完全不同的体验同样是 AI 回复冷冰冰的百科回答和陪诊式确认也会带来完全不同的信任感。项目采用五页统一结构首页、准备台、流程、家属同步、我的。首页负责建立信任和展示完整能力准备台负责采集患者信息并生成计划流程页把就医前 24 小时、就医前 12 小时、到院就诊、就医后当天拆成步骤家属同步页把复杂信息压缩成可转发摘要我的页面集中展示安全边界和 C4 赛题匹配。这个结构的好处是评委或读者不需要猜项目能做什么打开后能顺着任务路径看完闭环。Agent 或接口实现路径在安心陪诊 Agent 中安全边界一直放在功能之前。它可以帮用户整理症状、提示材料、生成医生问题、提醒复查但不能替医生诊断也不能给药物剂量。这个边界看似保守却是项目能被认真评审的关键因为健康信息场景最怕“看起来很智能实际上越界”。本项目没有把 Agent 写成不可解释的黑盒。它先通过症状关键词、就诊时间、既往病史、当前用药和家属担心生成结构化 profile再根据 profile 生成科室方向、医生问题、提醒事项、家属摘要和对话回复。这样做的优点是演示稳定、结果可解释、迁移成本低缺点是规则覆盖需要持续扩充。对于比赛原型来说这个取舍是合理的因为评审最先关心的是项目是否能完整演示、是否有清楚边界、是否能落地到鸿蒙能力。代码片段与工程细节下面这个片段展示了本文相关的一个关键工程点。代码不是为了炫技而是让读者能看到项目不是只有效果图背后有真实的输入、处理和输出链路。一句话创意 把一次看病前后的症状资料、挂号分诊、医生问题、医院流程、用药核对、 复查提醒和家属同步整理成一条可执行、可对话的安全陪诊流程。工程实现时我更建议先把接口返回结构固定下来再去调 UI。比如计划接口可以稳定返回 department、timeline、questions、reminders、familyBrief、cards对话接口可以稳定返回 headline、actions、doctorInfo、hospitalInfo、followUps 和 safety。前端只要按照结构渲染就能避免页面逻辑越来越散。安全边界、测试和可迁移性安全边界需要同时出现在三个地方第一产品文案中要明确“只做就医流程整理不做诊断”第二Agent 输出中遇到胸痛、呼吸困难、意识不清等急症信号时必须提示线下急救或急诊第三代码和测试中要覆盖这些路径防止后续功能扩展时把边界稀释。迁移到 HarmonyOS 后这些边界还应该体现在权限申请、隐私说明、数据存储和上架材料中。实现复盘如果把“需求分析”作为这一篇的核心关键词文章就不能只停留在结论而要把判断依据写出来。高质量项目文章通常有三个共同点一是有真实问题二是有可复现路径三是有失败或边界意识。安心陪诊 Agent 正好具备这些素材它有生活痛点有页面和接口有安全约束也有后续 HarmonyOS 真机化计划。写作时把这些内容展开读者才会觉得这不是一篇宣传稿而是一篇可以借鉴的工程复盘。评审视角这一篇最重要的观察是医疗陪诊场景不能把复杂性全部推给用户。老人和家属在医院里的压力来自时间、窗口、材料、检查单、医生沟通和复查安排。产品如果只给一个聊天框用户仍然不知道下一步做什么所以本文会把 评审视角 拆成输入、处理、输出、验证四个层次。可维护性CSDN 写作提示后续扩展实现复盘评审视角可维护性CSDN 写作提示后续扩展高质量补充从可演示到可信赖这一篇围绕老年陪诊需求分析家属、老人、医生三方到底缺什么展开但安心陪诊 Agent 的核心不只是做一个页面而是把老年就医前、中、后的任务拆清楚。高质量项目文章需要回答三个问题用户为什么需要它、系统怎样把需求变成可执行计划、哪些边界必须明确告诉用户。1. 场景证据不是泛聊天而是陪诊任务链安心陪诊 Agent 的对话范围应当收敛在陪诊流程内整理症状描述、提醒携带材料、生成医生沟通清单、记录复查安排、给家属同步重点。它不做诊断、不推荐处方、不替代医生判断。把这个边界写在文章里能让评审看到项目不是随意套一个 AI 聊天框而是在医疗辅助场景里做了风险控制。2. 工程证据前端、接口和规则 Agent 如何协作当前 Demo 可以按三层理解前端负责收集患者信息和展示任务卡片Node 服务负责把页面请求拆到/api/plan与/api/chat规则 Agent 负责输出结构化计划和安全提示。后续迁移到 HarmonyOS 时可以把计划生成、提醒、家属同步和隐私说明拆成独立模块降低页面和业务规则互相耦合的风险。patient input - /api/plan 生成陪诊任务 - /api/chat 回答流程问题 - safety guard 限制医疗风险表达 - family summary 输出家属可读清单3. 安全边界医疗类项目必须主动说明不能做什么医疗陪诊类作品最容易被质疑的不是页面是否好看而是是否越界。文章需要明确系统只做信息整理和流程提醒不判断病情严重程度不给药物剂量不承诺挂号或检查结果不把个人健康信息上传到未说明的第三方服务。这个边界越清晰作品越像一个可以继续打磨的真实产品。4. 验收清单发布前应该能被复查检查项合格标准应用名称标题、正文开头和合集名称都能看到安心陪诊 Agent结构完整至少包含场景、实现、边界、测试和复盘图片证据保留封面、流程图或页面截图不只堆文字风险提示说明不诊断、不开药、不替代医生HarmonyOS 方向能说明后续如何迁移到 ArkUI、元服务或智能体入口5. 测试样例让评委能复现核心价值为了让文章更像真实项目复盘每篇都应该给出一组可复现样例。比如输入“老人明天去三甲医院复查子女不能陪同担心材料漏带和医生问题记不住”系统应该输出就医前准备、到院流程、医生沟通问题、检查后记录和家属同步摘要。这个样例能同时覆盖用户痛点、Agent 规划能力和页面交互闭环比单纯描述“支持智能对话”更容易让评委理解。如果页面或接口失败也要有明确兜底。前端应提示用户重新填写关键字段Node 服务应返回结构化错误Agent 回复应避免编造医疗判断。文章里写出这些失败处理不会显得项目弱反而能证明开发者知道医疗类应用的边界和风险。case: 老人复查陪诊 input: 就诊时间、医院科室、症状摘要、家属关注点 output: 材料清单、沟通问题、院内任务、复查提醒 fallback: 信息不足时先追问不输出诊断和处方建议6. 后续升级从 Web Demo 到 HarmonyOS 场景后续如果继续打磨可以把安心陪诊 Agent 拆成 HarmonyOS 端的几个稳定入口首页展示当日陪诊计划服务卡片提醒复查和材料小艺智能体负责自然语言唤起Preferences 或 RDB 保存本地记录。这样既能保持隐私优先又能让作品从 Web Demo 走向更贴近鸿蒙生态的参赛形态。这也是 CSDN 系列文章需要统一标签和合集的原因读者看到的不是一篇孤立文章而是一条从需求分析、UI 原型、Agent 规则、接口实现、HarmonyOS 迁移到参赛材料的完整路径。完整路径越清楚项目越容易被认为是认真做过的作品。最终交付时还可以把 Demo 地址、核心截图、接口样例和隐私边界放到同一份 README 中让老师或评委不用翻很多文件就能快速复查。这样的资料组织方式会比只强调“用了 AI”更能体现项目完成度。这样处理后文章就不只是“我做了一个 Demo”而是把项目目标、实现证据、医疗安全边界和竞赛表达放在同一条线上。对 CSDN 高质量审核和比赛材料复盘来说这比重复铺字数更稳。工程复查补强让文章具备可验证证据这一段用于补齐文章的工程证据链。主题是【安心陪诊 Agent】老年陪诊需求分析家属、老人、医生三方到底缺什么所属项目是安心陪诊 Agent。一篇扎实的技术文章不能只写功能完成还要说明真实场景、关键代码、边界处理、验证步骤和失败兜底。检查项补强标准场景清晰开头能看出用户是谁、遇到什么问题、为什么这个功能有价值工程证据正文包含接口样例、代码片段、页面截图或结构图验证闭环能列出输入、操作、预期结果和失败兜底项目归属标题、摘要、标签和正文都能识别具体应用名称quality_check: app: 安心陪诊 Agent topic: 【安心陪诊 Agent】老年陪诊需求分析家属、老人、医生三方到底缺什么 evidence: screenshot code validation table fallback: empty state error state manual review note复查时重点看三点第一读者是否能按文章复现核心流程第二文章是否避免泛泛而谈能落到具体模块第三失败场景是否有明确提示而不是只展示成功路径。满足这些条件后文章更像一篇可落地、可复查、可继续迭代的工程记录。工程深度补充从页面表现走到可复查实现这一部分把安心陪诊 Agent的文章主题【安心陪诊 Agent】老年陪诊需求分析家属、老人、医生三方到底缺什么继续落到工程证据上。读者不只看到结论还能看到输入、处理、输出、异常兜底和验收方式。复查维度本文补充后的判断标准落地证据场景开头能说明谁在什么情况下使用这个能力用项目名称、目标用户和失败场景建立上下文实现能看见关键数据结构、服务边界或算法判断给出可迁移的代码片段和字段解释验证能按清单复测主流程和异常路径保留验收步骤、边界条件和排错入口type AgentIntent plan | chat | summary; interface AgentRequest { intent: AgentIntent; userText: string; safeMode: boolean; } function routeAgent(req: AgentRequest) { if (!req.userText.trim()) return { type: empty, message: 请先补充就医需求 }; if (req.safeMode /诊断|剂量|处方/.test(req.userText)) { return { type: guard, message: 仅提供就医准备建议不替代医生判断 }; } return { type: req.intent, message: 进入陪诊任务编排 }; }这段代码的重点不是堆功能而是把文章里的核心判断拆成稳定输入、明确输出和可解释的失败分支。读者复用时可以先保留接口形状再替换成自己的业务字段。测试路径输入样例预期结果正常路径字段完整、状态正常页面展示可执行建议并保留下一步操作空数据缺少关键输入显示明确提示不进入错误结果页边界值数值接近阈值或文本触发限制给出保守结果并说明原因实际提交前还需要做一次人工复查标题是否和正文一致封面是否能在列表页看清代码是否和项目主题相关图片是否能解释流程结尾是否有可执行的验证清单。小结与下一步本文围绕“老年陪诊需求分析家属、老人、医生三方到底缺什么”复盘了安心陪诊 Agent 的一个关键侧面。这个项目当前已经具备创意描述、设计稿、作品介绍文档、可运行 Demo 和演示 PPT。后续如果继续冲击更高质量的竞赛提交建议补充三类材料真机 HAP 运行证明、用户访谈或可用性测试报告、5 分钟以内演示视频。对 CSDN 读者来说最值得借鉴的不是某一个页面而是从痛点、设计、代码、边界、测试到提交材料的完整闭环。需求分析到任务模型的版本与验证需求研究的结论必须能落到可运行的任务模型。示例环境为 Node.js 20.11.1、Express 4.18.3、Chrome 126 和 HarmonyOS ArkTS老人、家属和医生三方的需求不直接保存为自由文本而是转换为可确认的陪诊任务。type Role elder | family | doctor; interface NeedInput { role: Role; text: string; } interface TaskDraft { title: string; owner: Role; requiresConfirm: boolean; } function toTaskDraft(input: NeedInput): TaskDraft[] { if (input.role elder) return [{ title: 出发与挂号提醒, owner: elder, requiresConfirm: true }]; if (input.role family) return [{ title: 材料与家属同步, owner: family, requiresConfirm: true }]; return [{ title: 就诊流程协同, owner: doctor, requiresConfirm: false }]; }这个模型不记录病情判断只记录谁需要完成什么准备。实际页面先展示草稿任务用户确认后才写入本地计划避免系统把访谈结论误当成医疗建议。访谈验证与验收角色高频问题转化后的功能验证方式老人流程陌生、容易遗漏大字号任务卡片与提醒移动窗口逐项完成家属无法实时知晓准备情况材料清单与同步摘要确认后展示摘要医生沟通信息分散问诊问题清单不包含诊断和处方curl -X POST http://localhost:5188/api/needs ^ -H Content-Type: application/json ^ -d {\role\:\family\,\text\:\整理复查材料\} { code: OK, tasks: [{ title: 材料与家属同步, requiresConfirm: true }] }发布前核对 Node、Express 版本完成老人、家属、医生三类输入以及空输入和风险词两条异常路径。需求分析只有连接到代码、返回值和验证记录才具备可复查的工程价值。