【安心陪诊 Agent】HarmonyOS ArkTS 实战：Preferences 与 RDB 数据存储设计

贾伟康

482人浏览 · 2026-07-13 00:30:56

贾伟康 · 2026-07-13 00:30:56 发布

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

HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选

摘要：围绕陪诊记录、提醒、家属摘要和设置项设计本地数据方案。本系列基于“安心陪诊 Agent”完整项目，从产品立项、UI、Agent、Web Demo、HarmonyOS 迁移和竞赛材料角度连续复盘。本文关键词：HarmonyOS、Preferences、RDB、本地存储。

HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选封面编辑编辑编辑编辑编辑编辑编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑编辑

编辑

项目背景与本文重点

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

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

HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选配图 1 编辑编辑编辑编辑编辑编辑编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑编辑

编辑

HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选配图 2 编辑编辑编辑编辑编辑编辑编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑编辑

编辑

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

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

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

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

设计稿与页面结构

从数据存储的角度看，HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选不是一个单点功能，而是一条围绕真实就医行为展开的任务链。很多项目在介绍 AI 时会把重点放在“能回答问题”，但安心陪诊 Agent 更关注“回答之后用户能不能行动”。这也是它适合写成技术文章的原因：背后既有产品判断，也有界面、接口、规则、测试和提交材料的工程约束。

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

Agent 或接口实现路径

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

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

代码片段与工程细节

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

// HarmonyOS 迁移时可把规则 Agent 放到 service/repository 层，
// ArkUI 页面只负责展示和触发，不直接处理持久化细节。
interface CareRecord {
  patient: string;
  symptoms: string;
  appointment: string;
  reminders: string[];
}

编辑

编辑编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

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

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

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

实现复盘

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

评审视角

可维护性

CSDN 写作提示

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

后续扩展

实现复盘

评审视角

可维护性

CSDN 写作提示

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

这一篇围绕HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选展开，但安心陪诊 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】HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选，所属项目是 安心陪诊 Agent。一篇扎实的技术文章不能只写功能完成，还要说明真实场景、关键代码、边界处理、验证步骤和失败兜底。

检查项	补强标准
场景清晰	开头能看出用户是谁、遇到什么问题、为什么这个功能有价值
工程证据	正文包含接口样例、代码片段、页面截图或结构图
验证闭环	能列出输入、操作、预期结果和失败兜底
项目归属	标题、摘要、标签和正文都能识别具体应用名称

quality_check:
  app: 安心陪诊 Agent
  topic: 【安心陪诊 Agent】HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选
  evidence: screenshot + code + validation table
  fallback: empty state + error state + manual review note

编辑

编辑编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

复查时重点看三点：第一，读者是否能按文章复现核心流程；第二，文章是否避免泛泛而谈，能落到具体模块；第三，失败场景是否有明确提示，而不是只展示成功路径。满足这些条件后，文章更像一篇可落地、可复查、可继续迭代的工程记录。

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

这一部分把 安心陪诊 Agent 的文章主题 【安心陪诊 Agent】HarmonyOS 数据存储设计：Preferences 与 RDB 怎么选 继续落到工程证据上。读者不只看到结论，还能看到输入、处理、输出、异常兜底和验收方式。

复查维度	本文补充后的判断标准	落地证据
场景	开头能说明谁在什么情况下使用这个能力	用项目名称、目标用户和失败场景建立上下文
实现	能看见关键数据结构、服务边界或算法判断	给出可迁移的代码片段和字段解释
验证	能按清单复测主流程和异常路径	保留验收步骤、边界条件和排错入口

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

编辑

编辑编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

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

测试路径	输入样例	预期结果
正常路径	字段完整、状态正常	页面展示可执行建议，并保留下一步操作
空数据	缺少关键输入	显示明确提示，不进入错误结果页
边界值	数值接近阈值或文本触发限制	给出保守结果，并说明原因

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

小结与下一步

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

Preferences 与 RDB 的边界：带迁移的可验证实现

本文示例基于 HarmonyOS SDK API 12、ArkTS 与 DevEco Studio NEXT 5.0.3。轻量配置如字号、提醒开关放入 Preferences；一次陪诊任务、陪同人、状态和时间线需要查询/统计，放入 RDB。两者不要混用成一个无结构 JSON，否则后续按日期统计和删除单条任务都会变得脆弱。

const SQL_CREATE = `CREATE TABLE IF NOT EXISTS escort_task (
  id TEXT PRIMARY KEY, hospital TEXT NOT NULL, visit_at INTEGER NOT NULL,
  status TEXT NOT NULL, created_at INTEGER NOT NULL
)`;

async function saveTask(store: relationalStore.RdbStore, task: EscortTask): Promise<void> {
  const bucket: relationalStore.ValuesBucket = {
    id: task.id, hospital: task.hospital, visit_at: task.visitAt,
    status: task.status, created_at: Date.now()
  };
  await store.insert('escort_task', bucket);
}

编辑

编辑编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

编辑编辑编辑

编辑

验证步骤：首次安装建表；创建两条不同日期任务；按日期查询；删除其中一条；再重启应用确认另一条仍存在。Preferences 则单独验证提醒开关在重启后保留，RDB 删除任务不影响提醒设置。升级时通过 schemaVersion 执行一次迁移，不在页面组件里拼 SQL。

数据类型	存储位置	回归检查
提醒开关	Preferences	重启后值不变
陪诊任务	RDB escort_task	可按日期查询
单条删除	RDB	只移除目标 id
升级迁移	schemaVersion	旧记录仍可读

延伸阅读

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

RDB 字段变更：版本迁移与兼容策略

Preferences 适合开关和轻量偏好；当陪诊任务需要按日期、状态和联系人查询时，迁移到 RDB。迁移不能只执行一次 ALTER TABLE，而要让旧数据、重复启动和失败回滚都可控。

场景	处理方式	兼容结果
新增 reminderAt 字段	设置默认值 0	旧任务仍可读取，未设置提醒按 0 处理
字段含义变化	保留旧列，双写一版后再清理	升级中断不丢原始数据
迁移执行失败	事务回滚并保留旧版本号	下次启动可安全重试

用版本号控制迁移顺序

const TARGET_SCHEMA_VERSION = 2;

async function migrateVisitTask(store: relationalStore.RdbStore, currentVersion: number): Promise<void> {
  if (currentVersion >= TARGET_SCHEMA_VERSION) return;

  await store.executeSql("BEGIN TRANSACTION");
  try {
    await store.executeSql(
      "ALTER TABLE visit_task ADD COLUMN reminderAt INTEGER NOT NULL DEFAULT 0"
    );
    await store.executeSql(`PRAGMA user_version = ${TARGET_SCHEMA_VERSION}`);
    await store.executeSql("COMMIT");
  } catch (error) {
    await store.executeSql("ROLLBACK");
    throw error;
  }
}

编辑

编辑编辑

启动时先读取 user_version，再按版本递增执行迁移。不要用“数据库存在就重新建表”的做法覆盖历史任务。迁移后至少校验旧记录条数、默认字段值和一次写入读取闭环；任一校验失败时保留旧库并提示用户稍后重试。

迁移脚本的执行权限与安全上下文

RDB 迁移只能在应用自己的数据目录与受控初始化流程中执行。这里的 SQL 来自随应用发布的固定版本代码，不从网络、文件导入或用户输入拼接 SQL；迁移前后都不把数据库文件路径、连接对象或原始健康信息暴露给页面层。

class VisitTaskRepository {
  constructor(private readonly store: relationalStore.RdbStore) {}

  async migrateOwnedSchema(currentVersion: number): Promise<void> {
    if (currentVersion >= 2) return;
    // SQL 是应用内置常量，不接受外部字符串或页面参数。
    await this.store.executeSql(
      "ALTER TABLE visit_task ADD COLUMN reminderAt INTEGER NOT NULL DEFAULT 0"
    );
    await this.store.executeSql("PRAGMA user_version = 2");
  }
}

编辑

安全约束	处理方式
数据库归属	仅打开应用创建的本地库，不接受任意文件路径
SQL 来源	只执行代码内固定常量，不接收外部 SQL
调用时机	在 Repository 初始化阶段完成，页面层不直接触发
失败处理	记录版本与错误，停止后续写入并保留旧数据

若后续引入导入、同步或账号功能，应在独立服务层做数据校验和授权，不把外部内容直接作为迁移指令。

API 26 示例：Preferences v2 与 RDB Schema v3 的事务迁移

本文示例环境为 HarmonyOS API 26。字号、是否朗读等轻量设置采用 Preferences Schema v2；陪诊任务、步骤状态和更新时间采用 RDB Schema v3。迁移只在应用自己的数据目录与 Repository 初始化阶段执行。

const TARGET_RDB_VERSION = 3

async function migrateToV3(store: relationalStore.RdbStore, oldVersion: number): Promise<void> {
  if (oldVersion >= TARGET_RDB_VERSION) return
  await store.beginTransaction()
  try {
    if (oldVersion < 2) {
      await store.executeSql('ALTER TABLE visit_task ADD COLUMN updated_at INTEGER NOT NULL DEFAULT 0')
    }
    if (oldVersion < 3) {
      await store.executeSql('CREATE INDEX IF NOT EXISTS idx_visit_task_status ON visit_task(status)')
    }
    await store.executeSql('PRAGMA user_version = 3')
    await store.commit()
  } catch (error) {
    await store.rollBack()
    throw error
  }
}

Repository 负责数据库句柄和迁移事务，页面只读取迁移完成后的模型。任何 SQL 失败都会回滚，防止出现“字段已增加但版本号未更新”的半迁移状态。

SELECT COUNT(*) AS invalid_count
FROM visit_task
WHERE status NOT IN ('todo', 'done') OR updated_at < 0;

PRAGMA user_version;
PRAGMA integrity_check;

验证矩阵：分别准备 v1、v2、v3 三份本地测试库；启动后确认 user_version=3、integrity_check=ok、无非法状态记录。再故意注入一条错误 SQL，确认事务回滚后旧库仍可打开、记录总数不变。Preferences v2 还需验证缺失字段使用默认值，旧字号和开关可以继续读取。

该迁移不接收外部 SQL，不扫描其他应用目录，也不把本地陪诊数据上传到第三方服务。数据库权限与生命周期由应用自身受控初始化流程管理。

HarmonyOS开发者社区

讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐

24-发布包被临时内容拖累-用资源日志隐私清单做提交前自查

摘要：本文针对HarmonyOS应用发布前的关键检查点，提出一套系统化的交付验证流程。主要内容包括：构建与配置验证（release包编译、版本号与签名）、资源与路由检查（启动图、深色模式、空态）、敏感内容处理（mock数据、日志过滤）、隐私合规（协议入口可达性、权限说明）以及真机主路径验证。强调通过可追溯的检查清单（含构建日志、资源路径记录、隐私入口截图等）替代口头承诺，并建议将验证结果转化为包含

HarmonyOS开发者社区

25-项目越写越散-用三层工程和模块边界守住长期维护

摘要：本文针对HarmonyOS项目中常见的工程结构散乱问题，提出三层架构解决方案。通过products（入口装配层）、features（业务闭环层）和common（公共能力层）明确划分职责边界，严格限制依赖方向（仅允许上层依赖下层）。重点强调：1）产品层仅做设备适配和入口组合，不吞业务逻辑；2）各feature需实现完整业务闭环；3）common层只存放真正稳定的跨领域能力。文章还提供了迁移验证