本文是补能雷达 Skill 的第 08 篇，围绕语音识别和播报体验展开，说明一个高德开放平台参赛 Demo 如何从功能展示走向真实可用。

首页最容易被当成 UI 页面，但它本质是主流程调度器。路由参数、点击区域、状态动画和页面注册都属于技术稳定性问题。首页入口稳定，后续功能才有被验证的机会。重点包括：首页入口如何组织、为什么按钮点击事件不能挂在父容器上、如何通过路由参数触发阅读页自动朗读，以及动效状态如何避免影响业务流程。原则是：动画只改变视觉状态，不参与业务判断。技术点是：每个交互节点只负责自己的行为。Text('朗读文章')

本文是补能雷达 Skill 的第 05 篇，围绕充电站多因子评分展开，说明一个高德开放平台参赛 Demo 如何从功能展示走向真实可用。

本文是补能雷达 Skill 的第 04 篇，围绕补能判断模型展开，说明一个高德开放平台参赛 Demo 如何从功能展示走向真实可用。

本文是补能雷达 Skill 的第 03 篇，围绕UI 信息架构和交互设计展开，说明一个高德开放平台参赛 Demo 如何从功能展示走向真实可用。

本文是补能雷达 Skill 的第 02 篇，围绕高德 API 链路设计展开，说明一个高德开放平台参赛 Demo 如何从功能展示走向真实可用。

以晨迹相机为例，完整拆解 HarmonyOS 沙盒 JSON 数据库：PhotoRecord 数据模型、PhotoRecordStore 读写实现、页面调用、首次启动/新增/重启/文件损坏四类验证，并说明如何避免本机绝对路径和不可复现代码。

本文是补能雷达 Skill 的第 01 篇，围绕项目定位、用户痛点、参赛表达展开，说明一个高德开放平台参赛 Demo 如何从功能展示走向真实可用。

健康菜谱助手的元服务场景是快速查看今日推荐，服务卡片场景是桌面轻触达，它们都不应该承载完整 App 的复杂操作。发布摘要可以写成：本文记录健康菜谱助手从主应用扩展到 HarmonyOS 元服务与服务卡片的过程，重点讲 atomicservice 免安装配置、FormExtensionAbility、2x2 卡片信息设计和上架前验证清单。这种边界如果不清楚，元服务会越来越重，最后既不像卡片，也不像完

健康菜谱助手第一版没有强制登录，也没有把用户数据上传到服务器。这个选择不是偷懒，而是因为菜谱搜索、收藏、阅读记录这类功能完全可以先本地完成。对轻量应用来说，本地优先能降低使用门槛，也能减少隐私和审核压力。这一篇专门讲数据。重点不是 Preferences API 怎么调用，而是哪些数据该存、由谁存、什么时候刷新、以后如何迁移。关键词：Preferences、本地优先、收藏、阅读记录、隐私一致性图