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

准备台页面实现：把患者信息变成可执行陪诊计划

摘要：讲解表单输入、即时生成、陪诊卡片、问题清单和提醒事项的实现思路。 本系列基于“安心陪诊 Agent”完整项目，从产品立项、UI、Agent、Web Demo、HarmonyOS 迁移和竞赛材料角度连续复盘。本文关键词：JavaScript、表单、陪诊计划、前端状态。

目录

• 项目背景与本文重点
• 场景拆解：为什么这个问题值得做
• 设计稿与页面结构
• 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 真机演示预留了清晰骨架。

从 表单与状态 的角度看，准备台页面实现：把患者信息变成可执行陪诊计划 不是一个单点功能，而是一条围绕真实就医行为展开的任务链。很多项目在介绍 AI 时会把重点放在“能回答问题”，但安心陪诊 Agent 更关注“回答之后用户能不能行动”。这也是它适合写成技术文章的原因：背后既有产品判断，也有界面、接口、规则、测试和提交材料的工程约束。

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

设计稿与页面结构

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

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

Agent 或接口实现路径

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

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

代码片段与工程细节

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

// 前端没有把业务规则写死在页面里，而是把输入整理后交给服务层。
form.addEventListener("input", debounce(refreshPlan, 420));

async function refreshPlan() {
  const plan = await postJson("/api/plan", readForm());
  render(plan);
}

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

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

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

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

这一部分把 安心陪诊 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: "进入陪诊任务编排" };
}

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

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

源码复核与实测记录（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 版本。

主题对应证据：计划对象由 profile、department、timeline、questions、reminders 和 familyBrief 组成；Smoke test 已覆盖慢病模式、家属摘要和急症分支。访谈与市场文章只陈述验证方法，不把演示样例冒充真实用户数据。

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

export function buildCarePlan(input = {}) {
  const profile = normalizeProfile(input);
  const department = inferDepartment(profile.symptoms);
  const timeline = buildTimeline(profile);
  const questions = buildDoctorQuestions(profile, department.dept);
  const reminders = buildReminders(profile, buildAudienceMode(profile.audienceMode));
  return { profile, department, timeline, questions, reminders };
}

复现步骤：进入 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 版本写成兼容结论。

主题输入：患者称呼、年龄、症状、过敏史、既往史与就医目标。

可复查调用链：normalizeProfile -> inferDepartment -> buildTimeline -> buildDoctorQuestions。

预期结果：就医前、中、后任务和医生沟通问题来自同一份 profile。

失败与边界：空字段会被归一化，急症词命中时跳过普通流程并优先提示线下求助。

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 和演示 PPT。后续如果继续冲击更高质量的竞赛提交，建议补充三类材料：真机 HAP 运行证明、用户访谈或可用性测试报告、5 分钟以内演示视频。对 CSDN 读者来说，最值得借鉴的不是某一个页面，而是从痛点、设计、代码、边界、测试到提交材料的完整闭环。

实现补充：准备台如何把输入变成可执行计划

本稿对应的页面逻辑版本为 care-agent-plan v1.0。它只整理用户手工确认的就诊日期、地点、同行人和待办事项，不推断病情，不生成用药或检查结论。

type PlanDraft = {
  date: string
  location: string
  companion: string
  tasks: string[]
}

type PlanIssue = 'missing_date' | 'missing_location' | 'empty_tasks'

export function validatePlan(input: PlanDraft): PlanIssue[] {
  const issues: PlanIssue[] = []
  if (!input.date.trim()) issues.push('missing_date')
  if (!input.location.trim()) issues.push('missing_location')
  if (input.tasks.filter(Boolean).length === 0) issues.push('empty_tasks')
  return issues
}

export function buildPlan(input: PlanDraft) {
  const issues = validatePlan(input)
  if (issues.length) return { ok: false as const, issues }
  return { ok: true as const, items: input.tasks.map((title, index) => ({ id: `task-${index}`, title, done: false })) }
}

输入输出样例：输入“日期 2026-07-20、地点市一医院、事项：带身份证、带检查单”，输出两条未完成任务；缺少地点时返回 missing_location，页面在地点字段下提示补全，不能进入下一步。

const result = buildPlan({ date: '2026-07-20', location: '市一医院', companion: '家属', tasks: ['带身份证', '带检查单'] })
console.assert(result.ok && result.items.length === 2)
console.assert(validatePlan({ date: '', location: '', companion: '', tasks: [] }).length === 3)

验收时验证：长地点名称换行不遮挡按钮、空字段不可提交、计划保存后重新进入仍显示同一任务数；涉及健康资料时仅展示用户主动填写的摘要，不默认上传到第三方。

care-agent-plan v1.1：准备台状态流与回归用例

准备台不是普通表单。它必须区分、校验失败、保存中、已保存四种状态，避免用户重复点击或误以为计划已经落库。下面的状态机只管理页面流程，医疗判断仍不进入该模块。

type PlanState = 'editing' | 'invalid' | 'saving' | 'saved'
interface PlanInput { visitDate: string; hospital: string; tasks: string[] }

export function submitPlan(input: PlanInput): { state: PlanState; issues: string[] } {
  const issues: string[] = []
  if (!input.visitDate.trim()) issues.push('visitDate')
  if (!input.hospital.trim()) issues.push('hospital')
  if (input.tasks.filter((item) => item.trim()).length === 0) issues.push('tasks')
  return issues.length ? { state: 'invalid', issues } : { state: 'saving', issues: [] }
}

export function saveFinished(ok: boolean): PlanState {
  return ok ? 'saved' : 'editing'
}

submitPlan 只信任经过修剪的字符串；空日期、空医院或没有任务时返回字段级错误。Repository 保存成功后才进入 saved，失败则回到可状态并保留输入。

const valid = submitPlan({ visitDate: '2026-07-20', hospital: '市一医院', tasks: ['带检查单'] })
console.assert(valid.state === 'saving')
console.assert(submitPlan({ visitDate: '', hospital: '', tasks: [] }).issues.length === 3)
console.assert(saveFinished(true) === 'saved')
console.assert(saveFinished(false) === 'editing')

回归矩阵：空输入应显示 3 个字段错误；合法输入首次点击进入保存中并禁用按钮；模拟保存失败后输入仍在；保存成功后重新进入页面，日期、医院和任务数一致。长医院名称在 390px 宽度下换行，不遮挡错误提示与提交按钮。

本模块只保存用户主动填写的陪诊任务。它不判断病情严重程度、不提供药物剂量、不承诺挂号或检查结果，也不把健康信息上传到未说明的第三方服务。

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