HarmonyOS 实战第一篇：从 0 到 1 搭建“知行生活小助手”AI 生活决策 APP

摘要

本文以“知行生活小助手”为例，拆解一个 HarmonyOS/ArkTS 生活决策类 APP 的完整实现思路。应用围绕“用户当前状态 -> 生成生活建议 -> 采纳或换一条 -> 历史沉淀与复盘”形成闭环，同时扩展了天气日历、专注提醒、快捷决策和穿戴端页面。文章重点不是堆页面，而是把产品目标、工程结构、数据模型、服务层和 UI 组件串起来，适合正在做 HarmonyOS 课程设计、比赛作品或个人项目的同学参考。

目录

1. 项目定位
2. 页面与模块划分
3. 数据模型设计
4. 服务层如何组织业务
5. 首页闭环实现
6. 工程质量与高分文章写作细节
7. 总结

一、项目定位：不是待办工具，而是生活决策助手

“知行生活小助手”的核心目标很明确：当用户不知道现在该吃什么、要不要运动、是否该休息、今天该做点什么时，APP 给出一个可以立刻执行的小建议。

它的核心链路可以概括为：

用户状态输入
  -> 本地建议池匹配
  -> 生成建议记录
  -> 用户采纳/忽略/换一条
  -> 历史记录与统计复盘

这个定位比普通备忘录更有辨识度。备忘录通常是“用户主动规划”，而知行生活小助手更像“用户状态驱动的即时建议系统”。这也是文章写作时最应该强调的亮点：它不是简单 CRUD，而是一个有决策闭环的生活型 AI 应用。

二、开发环境与项目目录

为了让读者能快速判断项目是否可复现，建议在文章开头补充环境信息。下面是本项目对应的开发上下文：

项目	说明
开发平台	HarmonyOS / ArkTS
工程模型	Stage 模型
主入口模块	entry
穿戴端模块	Has
公共能力模块	Har
数据存储	Preferences
主要语言	ArkTS

项目关键目录如下：

APP_05/
├── entry/
│   └── src/main/ets/
│       ├── pages/              # 手机端页面
│       ├── components/         # 通用 UI 组件
│       ├── services/           # 业务服务层
│       ├── repositories/       # 本地数据访问层
│       ├── models/             # 数据模型
│       ├── data/               # 本地建议池
│       └── common/             # 路由、常量、工具类
├── Has/
│   └── src/main/ets/pages/     # 穿戴端页面
├── Har/                        # 公共 HAR 模块
└── doc/                        # 设计稿、开发文档、文章资料

配图建议：这里可以插入 DevEco Studio 工程目录截图，能提高文章的图文完整度。

三、页面与模块划分

当前手机端主要页面包括：

页面	作用
HomePage	首页仪表盘，展示最新建议、快捷决策入口、今日统计
StatusInputPage	录入心情、疲劳状态、当前需求和补充描述
AnalysisResultPage	展示本次生成建议的分析结果
HistoryPage	查看历史建议、采纳状态和分组记录
SettingsPage	通知权限、早晚提醒、专注计时、隐私与数据管理
WeatherCalendarPage	展示天气和日历信息
QuickDecisionPage	快速回答“吃什么、运动吗、点外卖吗”
LegalDocPage	隐私政策、用户协议、联系我们

路由枚举统一放在 Constants.ets 中，避免页面之间硬编码字符串：

export enum RouteNames {
  HOME = 'home',
  STATUS_INPUT = 'statusInput',
  ANALYSIS_RESULT = 'analysisResult',
  HISTORY = 'history',
  SETTINGS = 'settings',
  WEATHER_CALENDAR = 'weatherCalendar',
  LEGAL_DOC = 'legalDoc',
  QUICK_DECISION = 'quickDecision'
}

这种写法的好处是：页面多了之后，不需要到处搜索字符串；如果后续要接入深度链接或多端路由，也能统一维护。

四、数据模型设计

1. 用户状态模型

状态输入页采集的信息并不复杂，但足够支撑推荐逻辑：

export interface UserStatus {
  mood: MoodType;
  isTired: boolean;
  needs: NeedType[];
  note: string;
}

其中 mood 代表情绪，isTired 代表疲劳状态，needs 表示用户当前需求，note 则是自由文本补充。自由文本非常关键，它让系统从“点按钮推荐”进化到“根据一句话理解用户意图”。

2. 建议记录模型

每条建议被保存为一条 SuggestionRecord：

export interface SuggestionRecord {
  id: string;
  content: string;
  reasoning: string;
  category: SuggestionCategory;
  iconKey?: string;
  isAdopted: boolean;
  adoptedAt: number | null;
  createdAt: number;
  updatedAt: number;
}

这里有两个设计点值得注意：

1. content 和 reasoning 分开保存，前者是建议，后者是解释。
2. isAdopted 和 adoptedAt 单独记录，方便统计采纳率和今日采纳数。

很多初学项目只存一句文本，后期想做统计时就会很痛苦。这个模型提前为历史分析、趋势复盘和首页 Bento 数据卡打好了基础。

五、服务层如何组织业务

项目中建议相关逻辑集中在 SuggestionService，本地持久化集中在 SuggestionRepository。这样页面只负责展示和响应用户操作，不直接处理存储细节。

服务层大致承担四类职责：

方法	职责
generateMockSuggestion	根据用户状态生成建议
saveSuggestion	保存建议记录
adopt / dismiss	更新采纳状态
getHomeData / getGroupedHistory	为首页和历史页提供聚合数据

其中推荐逻辑采用“三段式”：

generateMockSuggestion(status: UserStatus): MockSuggestion {
  const note = status.note ?? '';
  if (note.length > 0) {
    const matches = matchByKeywords(note, LIFE_SUGGESTIONS);
    if (matches.length > 0) {
      const top = matches.slice(0, Math.min(8, matches.length));
      return toMock(top[Math.floor(Math.random() * top.length)]);
    }
  }

  let pool: LifeSuggestion[] = LIFE_SUGGESTIONS;
  if (status.needs.length > 0 && status.needs[0] !== NeedType.OTHER) {
    const cat = NEED_CATEGORY[status.needs[0]];
    if (cat !== undefined) {
      const filtered = filterByCategory(cat, LIFE_SUGGESTIONS);
      if (filtered.length > 0) pool = filtered;
    }
  }

  return toMock(pool[Math.floor(Math.random() * pool.length)]);
}

这段逻辑很适合写进技术文章，因为它不是一句“随机推荐”带过，而是能体现推荐策略：

1. 优先匹配用户补充文本中的关键词。
2. 如果没有文本命中，再根据用户选择的需求筛选分类。
3. 如果仍然没有明确偏好，就从完整建议池中随机抽取。

六、首页闭环实现

首页是整个 APP 的“中控台”。它不是简单展示页面，而是把推荐、采纳、换一条、快捷功能和统计数据全部聚合起来。

首页加载时会初始化服务、同步提醒、刷新建议和天气：

async aboutToAppear() {
  const ctx = AppStorage.get<common.UIAbilityContext>('ctx') as common.UIAbilityContext;
  await this.service.init(ctx);
  const settings = SettingsPreferencesService.getInstance();
  await settings.init(ctx);
  try { await ReminderService.getInstance().sync(); } catch (_) {}
  await this.refresh();
  await this.loadWeather();
}

采纳建议时更新记录并刷新首页：

async handleAdopt(id: string) {
  await this.service.adopt(id);
  await this.refresh();
  promptAction.showToast({
    message: '已采纳 ✓ 已记录你的选择',
    duration: 2000
  });
}

“换一条”则保留历史，同时生成新的建议：

async handleDismiss(id: string) {
  const currentContent = this.state.data?.latestSuggestion?.content ?? '';
  const wasAdopted = this.state.data?.latestSuggestion?.isAdopted ?? false;
  this.generating = true;
  try {
    if (!wasAdopted) {
      await this.service.dismiss(id);
    }
    await this.service.generateAndSave(currentContent);
    await this.refresh();
  } finally {
    this.generating = false;
  }
}

这里有一个小细节：如果用户已经采纳过当前建议，再点“换一条”时不应该把它改成未采纳。因此代码中用 wasAdopted 做了保护。

七、效果图与读者验证路径

图片位置	建议说明
doc/APP_05_UI/stitch_ai_life_assistant/home_dashboard/screen.png	首页 Dashboard 效果图
doc/APP_05_UI/stitch_ai_life_assistant/status_input_final_polish/screen.png	状态输入页效果图
doc/APP_05_UI/stitch_ai_life_assistant/history_records_final_polish/screen.png	历史记录页效果图
doc/APP_05_UI/stitch_ai_life_assistant/smartwatch_interface_final_polish/screen.png	穿戴端效果图

读者可以按下面路径验证项目主链路：

打开 APP
  -> 首页点击生成建议
  -> 进入状态输入页填写心情和需求
  -> 生成建议
  -> 在结果页查看原因
  -> 返回首页采纳或换一条
  -> 进入历史页查看记录

八、常见问题与排查

1. 页面中文出现乱码怎么办？

如果在 PowerShell 中查看 ArkTS 文件时出现乱码，优先检查读取编码。建议使用 UTF-8：

Get-Content -Encoding UTF8 entry\src\main\ets\pages\HomePage.ets

源文件本身如果是 UTF-8，DevEco Studio 中通常不会乱码；命令行乱码多半是终端编码或读取方式导致。

2. 首页没有显示最新建议怎么办？

优先检查三点：

1. SuggestionService.init(ctx) 是否执行。
2. SuggestionRepository.save(record) 是否成功 flush。
3. 首页 refresh() 是否在页面显示或返回时重新调用。

3. 为什么要把 Repository 和 Service 分开？

Repository 只处理数据读写，Service 处理业务计算。这样当存储从 Preferences 换成 RDB 时，页面和大部分业务代码都不用改。

九、工程质量与高分文章写作细节

如果要把这类项目写成 CSDN 高质量文章，建议注意以下几点：

1. 标题要具体：不要写“我的 HarmonyOS 项目”，而要写“HarmonyOS 实战：AI 生活决策 APP 的架构设计与首页闭环实现”。
2. 开头先说明应用解决什么问题，不要一上来贴代码。
3. 每个功能都配“为什么这么设计”，让文章有思考深度。
4. 代码块不要太多，但关键模型、服务方法、页面事件一定要贴。
5. 结尾给出可扩展方向，例如接入云端大模型、跨设备同步、个性化权重等。

十、参考资料

1. HarmonyOS 官方文档：Stage 模型应用包结构。
2. HarmonyOS 官方文档：ArkTS 声明式开发范式。
3. CSDN 质量分说明页：关注标题、段落结构、正文长度、代码格式、链接和超文本内容质量。
4. 项目设计文档：doc/开发计划.md、doc/三层架构规范.md。

十一、互动问题

如果你也在做 HarmonyOS 生活类 APP，可以在评论区讨论三个问题：

1. 你更倾向于端侧推荐，还是云端大模型推荐？
2. 生活建议类 APP 是否需要接入健康数据？
3. 多端联动时，手机和手表应该如何分工？

十二、总结

“知行生活小助手”的核心价值在于把生活建议做成了一个完整闭环：用户输入状态，系统给出可执行建议，用户采纳或换一条，最终沉淀为历史和统计。项目中通过 UserStatus、SuggestionRecord、SuggestionService 和 SuggestionRepository 将数据、业务和页面解耦，既适合课程项目，也具备继续扩展为真实产品的基础。

推荐标签

HarmonyOS ArkTS 鸿蒙应用开发 AI生活助手 移动端项目实战