应用名称：安心陪诊 Agent
统一合集：安心陪诊 Agent｜HarmonyOS 高校创新赛
关键词标签：harmonyos / AI Agent / 医疗陪诊

鸿蒙高校创新赛 C4 阅读笔记：如何把赛题转成可落地项目

摘要：围绕 C4 赛题要求，说明为什么安心陪诊 Agent 同时覆盖应用、Agent 与用户体验。 本系列基于“安心陪诊 Agent”完整项目，从产品立项、UI、Agent、Web Demo、HarmonyOS 迁移和竞赛材料角度连续复盘。本文关键词：鸿蒙高校创新赛、C4、Agent、竞赛项目。

目录

• 项目背景与本文重点
• 场景拆解：为什么这个问题值得做
• 设计稿与页面结构
• Agent 或接口实现路径
• 代码片段与工程细节
• 安全边界、测试和可迁移性
• 小结与下一步

项目背景与本文重点

安心陪诊 Agent 的定位很明确：它不是诊断系统，也不是线上问诊平台，而是一个围绕真实就医流程做信息整理、任务拆解和家属协同的智能体原型。项目当前实现了可运行 Web Demo：前端使用原生 HTML、CSS、JavaScript，后端使用 Node.js 原生 HTTP 服务，核心 Agent 采用本地规则与结构化输出，提供 /api/plan 和 /api/chat 两个接口。视觉资产包括 image2 生成的项目总览、五页 UI 原型、Agent 流程图、桌面端和移动端演示截图，以及一套 image2 风格演示 PPT。

在安心陪诊 Agent 中，安全边界一直放在功能之前。它可以帮用户整理症状、提示材料、生成医生问题、提醒复查，但不能替医生诊断，也不能给药物剂量。这个边界看似保守，却是项目能被认真评审的关键，因为健康信息场景最怕“看起来很智能，实际上越界”。

场景拆解：为什么这个问题值得做

如果把这个项目迁移到 HarmonyOS，本文提到的模块仍然成立：页面层负责展示和交互，服务层负责计划生成和对话组织，数据层负责保存必要记录，系统能力层再接入日历、提醒、语音和小艺智能体。也就是说，当前 Web Demo 不是临时玩具，而是为后续 HAP 真机演示预留了清晰骨架。

从 赛题拆解 的角度看，鸿蒙高校创新赛 C4 阅读笔记：如何把赛题转成可落地项目 不是一个单点功能，而是一条围绕真实就医行为展开的任务链。很多项目在介绍 AI 时会把重点放在“能回答问题”，但安心陪诊 Agent 更关注“回答之后用户能不能行动”。这也是它适合写成技术文章的原因：背后既有产品判断，也有界面、接口、规则、测试和提交材料的工程约束。

在真实就医前，家属常常需要同时处理挂号、路线、证件、医保、药盒、检查单和老人情绪。到了诊室里，医生真正需要的是清楚的事实：哪里不舒服、持续多久、什么情况下加重、既往病史是什么、现在吃什么药。就医结束后，又要把医嘱、复查时间、观察指标同步给家里其他人。安心陪诊 Agent 的价值就在于把这些散落的信息整理成可执行任务，而不是让用户面对一大段泛泛的医疗说明。

设计稿与页面结构

这一篇最重要的观察是：医疗陪诊场景不能把复杂性全部推给用户。老人和家属在医院里的压力来自时间、窗口、材料、检查单、医生沟通和复查安排。产品如果只给一个聊天框，用户仍然不知道下一步做什么；所以本文会把 设计稿 拆成输入、处理、输出、验证四个层次。

项目采用五页统一结构：首页、准备台、流程、家属同步、我的。首页负责建立信任和展示完整能力；准备台负责采集患者信息并生成计划；流程页把就医前 24 小时、就医前 12 小时、到院就诊、就医后当天拆成步骤；家属同步页把复杂信息压缩成可转发摘要；我的页面集中展示安全边界和 C4 赛题匹配。这个结构的好处是评委或读者不需要猜项目能做什么，打开后能顺着任务路径看完闭环。

Agent 或接口实现路径

为了让文章在 CSDN 上更有参考价值，我不会只写“项目很好看”。更有价值的部分是说明为什么这么设计、怎么实现、哪里容易踩坑、如何验证。比如同样是生成清单，直接给一段长文字和拆成卡片是完全不同的体验；同样是 AI 回复，冷冰冰的百科回答和陪诊式确认也会带来完全不同的信任感。

本项目没有把 Agent 写成不可解释的黑盒。它先通过症状关键词、就诊时间、既往病史、当前用药和家属担心生成结构化 profile，再根据 profile 生成科室方向、医生问题、提醒事项、家属摘要和对话回复。这样做的优点是演示稳定、结果可解释、迁移成本低；缺点是规则覆盖需要持续扩充。对于比赛原型来说，这个取舍是合理的，因为评审最先关心的是项目是否能完整演示、是否有清楚边界、是否能落地到鸿蒙能力。

代码片段与工程细节

下面这个片段展示了本文相关的一个关键工程点。代码不是为了炫技，而是让读者能看到项目不是只有效果图，背后有真实的输入、处理和输出链路。

// 安心陪诊 Agent 的接口边界可以保持很薄：
// /api/plan 负责把表单信息整理成陪诊计划
// /api/chat 负责把用户追问转换成陪诊式回答
const routes = {
  "POST /api/plan": buildCarePlan,
  "POST /api/chat": buildChatReply
};

function ok(res, data) {
  res.writeHead(200, { "Content-Type": "application/json; charset=utf-8" });
  res.end(JSON.stringify(data));
}

工程实现时，我更建议先把接口返回结构固定下来，再去调 UI。比如计划接口可以稳定返回 department、timeline、questions、reminders、familyBrief、cards；对话接口可以稳定返回 headline、actions、doctorInfo、hospitalInfo、followUps 和 safety。前端只要按照结构渲染，就能避免页面逻辑越来越散。

安全边界、测试和可迁移性

安全边界需要同时出现在三个地方：第一，产品文案中要明确“只做就医流程整理，不做诊断”；第二，Agent 输出中遇到胸痛、呼吸困难、意识不清等急症信号时必须提示线下急救或急诊；第三，代码和测试中要覆盖这些路径，防止后续功能扩展时把边界稀释。迁移到 HarmonyOS 后，这些边界还应该体现在权限申请、隐私说明、数据存储和上架材料中。

实现复盘

如果把“赛题拆解”作为这一篇的核心关键词，文章就不能只停留在结论，而要把判断依据写出来。高质量项目文章通常有三个共同点：一是有真实问题，二是有可复现路径，三是有失败或边界意识。安心陪诊 Agent 正好具备这些素材：它有生活痛点，有页面和接口，有安全约束，也有后续 HarmonyOS 真机化计划。写作时把这些内容展开，读者才会觉得这不是一篇宣传稿，而是一篇可以借鉴的工程复盘。

评审视角

可维护性

这一篇最重要的观察是：医疗陪诊场景不能把复杂性全部推给用户。老人和家属在医院里的压力来自时间、窗口、材料、检查单、医生沟通和复查安排。产品如果只给一个聊天框，用户仍然不知道下一步做什么；所以本文会把 可维护性 拆成输入、处理、输出、验证四个层次。

CSDN 写作提示

后续扩展

实现复盘

评审视角

可维护性

CSDN 写作提示

高质量补充：从可演示到可信赖

这一篇围绕鸿蒙高校创新赛 C4 阅读笔记：如何把赛题转成可落地项目展开，但安心陪诊 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 高质量审核和比赛材料复盘来说，这比重复铺字数更稳。

小结与下一步

本文围绕“鸿蒙高校创新赛 C4 阅读笔记：如何把赛题转成可落地项目”复盘了安心陪诊 Agent 的一个关键侧面。这个项目当前已经具备创意描述、设计稿、作品介绍文档、可运行 Demo 和演示 PPT。后续如果继续冲击更高质量的竞赛提交，建议补充三类材料：真机 HAP 运行证明、用户访谈或可用性测试报告、5 分钟以内演示视频。对 CSDN 读者来说，最值得借鉴的不是某一个页面，而是从痛点、设计、代码、边界、测试到提交材料的完整闭环。