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

测试策略：一个陪诊 Agent Demo 至少要验证哪些路径

摘要：介绍 smoke test、接口测试、页面截图检查和人工验收清单。 本系列基于“安心陪诊 Agent”完整项目，从产品立项、UI、Agent、Web Demo、HarmonyOS 迁移和竞赛材料角度连续复盘。本文关键词：测试、smoke test、QA、项目验收。

​编辑

目录

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

项目背景与本文重点

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

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

​编辑

​编辑

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

从 测试质量 的角度看，测试策略：一个陪诊 Agent Demo 至少要验证哪些路径 不是一个单点功能，而是一条围绕真实就医行为展开的任务链。很多项目在介绍 AI 时会把重点放在“能回答问题”，但安心陪诊 Agent 更关注“回答之后用户能不能行动”。这也是它适合写成技术文章的原因：背后既有产品判断，也有界面、接口、规则、测试和提交材料的工程约束。

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

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

设计稿与页面结构

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

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

Agent 或接口实现路径

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

本项目没有把 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 写作提示

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

这一篇围绕测试策略：一个陪诊 Agent Demo 至少要验证哪些路径展开，但安心陪诊 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. 验收清单：发布前应该能被复查

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】测试策略：一个陪诊 Agent Demo 至少要验证哪些路径。要让它接近 CSDN 后台“高质量”标识，不能只靠增加字数，而要补足三个证据：真实场景、工程边界、验证记录。安心陪诊 Agent 是医疗辅助场景，文章必须主动说明它做什么、不做什么，以及用户如何复现核心流程。

测试策略篇要把成功路径和失败路径都列出来：信息完整、信息缺失、用户取消、接口失败、重复点击、隐私提示都要能复查。

1. 真实使用场景

可以用一个固定样例贯穿全文：老人明天去三甲医院复查，子女不能陪同，担心材料遗漏、医生问题记不住、检查后不知道怎么同步给家属。系统接收病情摘要、就诊科室、时间、家属关注点后，输出材料清单、就诊流程、医生沟通问题、检查后记录和复查提醒。

2. 工程边界

文章里需要把页面、接口和 Agent 规则拆清楚。页面层负责输入和卡片展示；服务层负责把请求拆到 /api/plan 与 /api/chat；规则层负责生成结构化任务，不输出医疗诊断。这样写可以避免读者把项目误解成普通聊天工具。

{
  "scene": "elder_follow_up",
  "input": ["hospital", "department", "symptoms", "familyConcern"],
  "output": ["materialChecklist", "doctorQuestions", "familySummary"],
  "guardrails": ["noDiagnosis", "noPrescription", "noDosageAdvice"]
}

这段结构化样例的作用是说明数据如何流动：用户输入不会直接变成自由发挥的回复，而是先进入可控字段，再由规则 Agent 生成任务卡片。医疗辅助项目必须做到边界清楚，否则内容越像 AI 聊天，风险反而越高。

3. 安全边界和隐私说明

4. 验证记录

高质量项目文章需要可复查，而不是只写“功能完成”。建议在正文中保留以下验收记录：输入空内容时能提示补全；输入完整就诊信息时能生成计划；点击家属同步时能看到摘要；切换移动端宽度时卡片不重叠；接口异常时页面给出可读提示。

5. 可以直接放进答辩的表达

如果把这篇文章压缩成比赛表达，可以这样说：安心陪诊 Agent 面向老年就医和异地家属协同，使用规则化 AI Agent 把就诊信息整理成材料清单、沟通问题、陪诊计划和家属摘要。它不是替代医生，而是降低陪诊前后的信息遗漏和沟通成本。

工程深度补充：从页面表现走到可复查实现

这一部分把 安心陪诊 Agent 的文章主题 【安心陪诊 Agent】Node.js 20 + Node.js 内置 http 模块 实战：测试策略与核心路径验证 继续落到工程证据上。读者不只看到结论，还能看到输入、处理、输出、异常兜底和验收方式。

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: "进入陪诊任务编排" };
}

这段代码的重点不是堆功能，而是把文章里的核心判断拆成稳定输入、明确输出和可解释的失败分支。读者复用时可以先保留接口形状，再替换成自己的业务字段。

实际提交前还需要做一次人工复查：标题是否和正文一致，封面是否能在列表页看清，代码是否和项目主题相关，图片是否能解释流程，结尾是否有可执行的验证清单。

源码复核与实测记录（2026-07-28）

复核范围：安心陪诊 Agent v1.0.0；运行要求来自 project/package.json 的 node >=20。服务端实际使用 Node.js 内置 node:http，不是 Express；前端使用原生 HTML、CSS 与 JavaScript ES Modules。本文不再使用源码无法证明的精确浏览器、TypeScript、Express 或 DevEco 版本。

主题对应证据：源码使用 Node.js 内置 http.createServer 提供静态资源、/api/context、/api/plan 与 /api/chat；package.json 没有 Express 依赖。

真实文件：project/server/index.js + project/tests/smoke-test.js

const plan = await post("/api/plan", {
  patient: "妈妈",
  age: 66,
  symptoms: "头晕、血压波动、晚上睡不好",
  audienceMode: "chronic"
});
assert.equal(plan.department.dept, "心内科");
assert.ok(plan.reminders.some((item) => item.title === "华为手表提醒"));

const emergency = await post("/api/chat", {
  ...plan.profile,
  message: "老人突然胸痛还有呼吸困难怎么办？"
});
assert.equal(emergency.intent, "emergency");

复现步骤：进入 project 目录执行 npm test。测试会随机监听本机端口，依次请求三个接口，并断言心内科方向、慢病模式、华为手表提醒、家属摘要、安全提示和急症意图；全部断言通过后只输出 Smoke test passed.。这是一条已经执行的本地证据，不代表医院服务或医疗结果。

当前版本兼容性与主题验证（2026-07-28）

时效性基线：截至 2026 年 7 月 28 日，当前可运行交付物仍是安心陪诊 Agent v1.0.0 Web Demo，package.json 要求 Node.js >=20，服务端使用标准库 node:http，前端使用原生 HTML、CSS 与 JavaScript ES Modules。现代 Chromium 浏览器可用于本地复现，但仓库没有固定某一个浏览器小版本，所以本文不把单一 Chrome 版本写成兼容结论。

主题输入：GET /api/context、POST /api/plan、POST /api/chat 与错误方法。

可复查调用链：http.createServer -> URL 路由 -> readBody -> agent 纯函数 -> sendJson。

预期结果：三个接口返回结构化 JSON，静态首页可访问，Smoke test 全部断言通过。

失败与边界：未知接口返回 404，方法不匹配不进入业务分支，异常请求不伪造成功结果。

1. 本地复现顺序

复现时先进入 project 目录执行 npm test。脚本创建本机随机端口，依次请求上下文、计划与聊天接口，并检查科室方向、慢病模式、提醒、家属摘要、安全提示和急症意图。只有控制台输出 Smoke test passed. 才能记录为自动化回归通过；某个断言失败时，应保留首个失败项，不能只截取最后一行日志。

cd project
npm test
# 通过标准：Smoke test passed.

# 需要人工查看页面时再启动本地服务
npm start
# 浏览器打开终端输出的本机地址，不使用真实患者资料

页面验证使用演示资料，重点检查表单能否提交、计划是否渲染、对话能否返回、错误是否可读和手机宽度下是否仍可操作。当前测试不等于临床验证，也不证明真实医院流程、诊断准确率或商业需求已经成立。

2. 兼容性矩阵

3. 从 Web 数据契约迁移到 HarmonyOS 5.0+

迁移时先冻结 profile、department、timeline、questions、reminders 与 familyBrief 的字段，再定义严格 ArkTS 接口。页面只持有输入草稿、加载、错误和内容状态；规则判断放在 Service，Preferences 或 RDB 由 Repository 管理。这样能避免把 JavaScript 动态对象直接搬进 ArkUI 页面后产生大量可空字段和隐式类型错误。

interface CarePlan {
  profile: PatientProfile
  department: DepartmentSuggestion
  timeline: CareStep[]
  questions: DoctorQuestion[]
  reminders: CareReminder[]
  familyBrief: string
}

type PageState = 'loading' | 'empty' | 'error' | 'content'

轻量开关、引导状态和用户偏好可以评估 Preferences；结构化计划、查询、统计和需要迁移的历史记录更适合 RDB。医疗相关字段遵循最小化原则，默认本地处理；如果未来增加账号、云同步、语音、小艺或跨设备流转，必须重新设计授权、删除、隐私说明、服务端边界和审核材料，不能从当前 Web Demo 自动推导。

4. 主题专项检查表

性能记录至少观察接口响应时间、连续提交后的事件处理、长文本渲染和手机宽度布局。当前规则函数是本地同步计算，若以后接入模型或远端服务，还要增加超时、取消、重试、限流、离线提示与服务降级；这些都属于新增能力，不能在当前结论中提前写成完成。

5. 故障注入与证据回读

只验证成功输入无法证明流程稳定。第一组故障注入针对 HTTP 边界：向 /api/plan 发送空对象、缺少字段、额外字段和无效 JSON，向 /api/chat 发送空消息与超长消息，再访问未知路径。服务应返回可解释状态，不因一次请求导致进程退出；未知路径必须保持 404 语义，不能被静态首页兜底成看似成功的页面。

第二组故障注入针对规则边界：把普通慢病描述与“胸痛、呼吸困难、意识不清”等急症信号分别输入，确认急症判断先于普通科室建议。再使用相近但不属于急症的描述，观察是否出现过度匹配。测试记录要保留输入类别、命中的规则、响应中的 intent 或 urgency 和安全提示，不保存真实患者姓名、联系方式与病历。

第三组故障注入针对前端状态：在请求进行中重复点击、关闭本地服务后提交、返回非 JSON 响应、缩小到手机宽度、放大系统字体并刷新页面。通过标准是加载状态不会永久卡住，错误消息可见，旧结果不会冒充本次成功，按钮和输入仍可到达。若未来迁移 ArkUI，应显式维护 loading、empty、error 与 content，不要只用一个布尔值覆盖所有页面状态。

证据回读发生在修改之后。服务端文章重新读取 server/index.js 与 server/agent.js，确认方法名、接口路径和字段仍存在；前端文章重新读取 public/app.js 与 public/styles.css；测试文章重新执行 npm test。如果源码已经变化，文章应更新为新的快照，而不是为了保留旧结论去修改代码或虚构兼容层。

HarmonyOS 迁移阶段还要增加构建与设备证据：DevEco 工程的 build-profile.json5、module.json5、目标 SDK、设备类型和权限用途必须一致；执行仓库实际提供的 Hvigor 任务，记录第一条编译错误；有签名候选包后再做安装、启动、核心流程、返回和卸载。没有执行这些步骤时，只能写“设计方案”或“待验证”，不能写“已适配”或“已上架”。

对医疗陪诊主题而言，功能正确之外还有可逆性要求。用户应能修改或清除本地资料，提醒可以关闭，家属摘要应由用户主动生成或分享，急症提示必须引导线下求助。未来增加云端能力时，要补充传输、存储位置、删除、账号退出和隐私授权；当前本地 Demo 没有这些能力，所以文章不会提前承诺云同步、跨设备数据或医疗机构接入。

维护阶段建议为每个接口保存一份最小请求与响应样例，但样例只使用虚构人物和非敏感症状。字段新增时先更新纯函数、Smoke test 和前端渲染，再同步文章中的数据结构；字段删除时检查旧页面是否仍访问它。通过这种契约式回归，可以把“页面看起来没变”转换为可执行断言，也能在迁移 ArkTS 严格类型时尽早发现可空字段、枚举值和默认值不一致。

每次修改完成后还要重新从 CSDN 编辑端回读正文唯一标记、三张托管图片、摘要、标签和封面，避免接口保存成功但编辑器展示仍是旧版本。平台内容状态可能异步更新，因此修改记录与后台结果要分开保存：正文已升级只能写“已回读”，不能把尚未返回的结果写成已经达成。

发布前最后回读标题、摘要、五个相关标签、正文三张托管图片、AI 辅助声明和封面 URL。正文中的代码路径必须能在仓库定位，测试结果必须来自实际执行；未验证的设备、HarmonyOS 原生能力和临床效果统一写成待办或迁移边界。

小结与下一步

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

可执行测试矩阵：接口、页面与安全边界

测试基线为 Node.js 20 及以上、Node.js 内置 http 模块、现代 Chromium 浏览器。测试覆盖“输入是否合法、任务是否生成、页面是否可操作、医疗边界是否守住”四类结果，而不是仅检查页面截图。

import assert from 'node:assert/strict';
import { buildEscortTasks } from '../src/escort-plan.js';

const plan = buildEscortTasks({ hospital: '门诊楼', visitAt: '09:00', need: '取号' });
assert.equal(plan.code, 'OK');
assert.equal(plan.tasks.length, 3);
assert.equal(buildEscortTasks({ hospital: '', visitAt: '09:00', need: '取号' }).code, 'INVALID_ARGUMENT');
assert.equal(buildEscortTasks({ hospital: '门诊楼', visitAt: '09:00', need: '药怎么吃' }).code, 'OUT_OF_SCOPE');

运行 node --test test/escort-plan.test.js 后，应看到三条断言通过。最后一条专门验证边界：出现用药或诊断类文本时不创建医疗建议任务，而是返回明确的范围外提示。前端据此保留输入并展示“请咨询医生或药师”。

延伸阅读

这篇文章和同项目的实现、测试或排错文章可以组合阅读，下面两篇给出相邻的工程上下文。

• 查看本系列的相关实践 1
• 查看本系列的相关实践 2

AI 辅助声明：本文在人工复核真实源码、配置字段与验证记录的基础上，使用 AI 辅助整理结构和语言；功能边界、代码路径、版本信息与测试结论均以当前工程为准，未执行的真机、云测或平台操作不会写成已经通过。