鸿蒙 + Flutter 下如何让 HarmonyOS 能力真正服务于 AI 体验

适合谁看

正在做鸿蒙 AI 项目的人
不想把系统能力做成孤立展示点的人
想让 AI 页面更像产品而不是能力清单的人
想理解每项 HarmonyOS 能力如何改变 AI 体验的人

问题背景

做鸿蒙项目时，很容易出现一种天然冲动：既然有这么多 Kit，那就尽量多接几个。

这在比赛或演示阶段看起来很有吸引力。但如果这些能力和产品体验的连接不够紧，最后就会变成：

语音是语音，和 AI 页面没关系
TTS 是 TTS，只是个多余的按钮
Intent 是 Intent，只是个路由演示
防窥是防窥，和 AI 体验无关

这会让整个项目看起来像"能力拼装"，而不是"体验设计"。

项目中的真实场景

食界探味当前 AI 体验已经和 4 类鸿蒙能力发生了真实连接：

鸿蒙能力	对应 Channel	服务的 AI 体验
语音识别 (CoreSpeechKit)	`SpeechRecognitionChannel`	改变 AI 输入方式
TTS (CoreSpeechKit)	`TextToSpeechChannel`	改变 AI 输出方式
Intent 导航	`IntentNavigationChannel`	改变 AI 触达方式
防窥保护	`AntiPeepProtectionChannel`	保护用户隐私

每一项能力都不是孤立的按钮或展示，而是嵌进了真实的 AI 交互链路。

核心实现

先说结论：

判断一项 HarmonyOS 能力是不是在真正服务 AI 体验，关键不是"有没有接上"，而是"它有没有改变用户使用 AI 的输入、输出、触达或信任方式"。

一、判断框架：4 个维度

每项鸿蒙能力接入 AI 页面时，问自己 4 个问题：

维度	问题	如果答案是"是"
输入	它有没有改变用户怎么给 AI 提问？	这项能力在服务 AI
输出	它有没有改变 AI 结果怎么被消费？	这项能力在服务 AI
触达	它有没有改变用户怎么进入 AI？	这项能力在服务 AI
信任	它有没有让用户更敢用 AI？	这项能力在服务 AI

如果 4 个答案都是"没有"，那这项能力可能只是在展示"接了某个 Kit"。

二、语音识别------改变了 AI 的输入方式

食界探味当前 AiExploreCoordinator 已经直接接上：

复制代码

// ai_explore_coordinator.dart

Future<void> startVoiceInput() async {
  state = state.copyWith(status: AiSessionStatus.listening);
  final text = await SpeechRecognitionChannel.startListening();
  if (text.isNotEmpty) {
    await submitQuery(text);  // 语音识别结果直接作为 AI 输入
  }
}

这不是简单地"多一个按钮"，而是在改变用户提问方式：

复制代码

原来：用户打字 → "鸡蛋 清淡" → 搜索框匹配
现在：用户说话 → "想吃鸡蛋做的，清淡一点，不要太家常" → AI 理解意图

这对 AI 推荐尤其重要，因为用户本来就更适合用自然语言说想吃什么、不想吃什么、今天是什么心情。语音识别在这里不是展示输入技术，而是在真正降低 AI 使用门槛。

在鸿蒙设备上，CoreSpeechKit 的语音识别引擎支持中文在线识别，VAD（语音端点检测）自动处理"用户停止说话"的判断：

复制代码

// SpeechRecognitionPlugin.ets

const extraParam: Record<string, Object> = {
  'recognitionMode': 0,
  'vadBegin': 2000,      // 2秒静音开始检测
  'vadEnd': 3000,        // 3秒静音结束识别
  'maxAudioDuration': 20000  // 最长20秒
};

用户不需要手动点"停止识别"，说完话后鸿蒙引擎自动判断结束。这让语音输入的体验更自然。

三、TTS------改变了 AI 的输出方式

TTS 当前已经接进 AI 助手页和菜品详情页：

复制代码

// AI 助手页：播报推荐文案
void _toggleSpeak(String text) async {
  if (_isSpeaking) {
    await TextToSpeechChannel.stop();
  } else {
    await TextToSpeechChannel.speak(text);
  }
}

// 菜品详情页：播报 AI 导览词
Future<void> speakDishNarration(Dish dish) async {
  final narration = '这道${dish.name}的灵魂在于${dish.soul}...'
  await speakText(narration);
}

这说明 TTS 不是为了展示"应用会说话"，而是在给 AI 输出增加另一种消费方式：

复制代码

原来：AI 输出 → 用户看文字 → 点击卡片
现在：AI 输出 → 用户看文字 → 点击卡片
                  ↓ 用户点击"语音播报"
                  鸿蒙 TTS 引擎朗读推荐文案

这让 AI 从纯视觉交互变成了"可看 + 可听"。在做饭、开车、散步等不方便看手机的场景下，TTS 让 AI 推荐真正"触手可及"。

四、Intent 导航------改变了 AI 的触达方式

IntentNavigationChannel 让 AI 助手可以从鸿蒙系统层直接被唤起：

复制代码

// intent_navigation_channel.dart

static const _pageIdToRoute = <String, String>{
  'search': '/search',
  'ai_assistant': '/ai-assistant',  // ← AI 助手的外部入口
  'wish_box': '/wish-box',
  'ingredients': '/ingredients',
  'explore': '/explore',
};

static void _navigate(_NavigationPayload payload) {
  if (payload.pageId == 'ai_assistant' && !AppConfig.enableAi) {
    _router?.go('/explore');  // AI 功能关闭时回退到探索页
    return;
  }
  // ... 路由跳转
}

这意味着 AI 助手不只能从应用内部一级一级点进去，还可以从：

系统搜索直达
服务卡片直达
外部 Intent 调起
其他应用跳转

这些入口都能更自然地引到 AI 助手，改变了用户是怎么进入 AI 的。这对产品层的意义，比单纯"又接了一个 Kit"更大。

五、防窥保护------改变了用户对 AI 的信任方式

AntiPeepProtectionChannel 服务于收藏页的隐私保护：

复制代码

// anti_peep_protection_channel.dart

static void initialize() {
  _channel.setMethodCallHandler((call) async {
    if (call.method == 'onAntiPeepEvent') {
      final event = arguments['event'] as String?;
      switch (event) {
        case 'HIDE':
          visibilityState.value = AntiPeepVisibilityState.hidden;
          break;
        case 'PASS':
        case 'DEACTIVATE':
          visibilityState.value = AntiPeepVisibilityState.visible;
          break;
      }
    }
  });
}

虽然防窥保护当前不在 AI 助手页面直接使用，但它保护的是用户的收藏数据------这些数据可能来自 AI 推荐。当用户收藏了 AI 推荐的菜品后，防窥保护让用户更敢在公共场合使用应用。

这改变了用户对 AI 的信任方式：我不怕别人看到我收藏了什么，因为有防窥保护。

六、4 项能力如何形成完整体验链

把 4 项鸿蒙能力和 AI 体验串在一起看：

复制代码

用户发现 AI 助手
  │
  ├─ 系统搜索 → Intent 导航 → AI 助手页     ← Intent 改变触达
  │
  ├─ 服务卡片 → Intent 导航 → AI 助手页     ← Intent 改变触达
  │
  ▼
AI 助手页
  │
  ├─ 用户说话 → 鸿蒙 ASR → AI 理解意图      ← 语音识别改变输入
  │
  ├─ AI 调用工具 → 推荐菜品 → 菜品卡片      ← AI 核心能力
  │
  ├─ 用户点击"语音播报" → 鸿蒙 TTS 朗读     ← TTS 改变输出
  │
  ├─ 用户收藏菜品 → 收藏夹                   ← 业务逻辑
  │
  ▼
收藏页
  │
  └─ 鸿蒙防窥保护 → 他人无法偷看             ← 防窥改变信任

每一项鸿蒙能力都在链路中承担一个明确的角色，而不是孤立地"挂在项目说明里"。

七、最容易犯的错误：先有能力，再倒找场景

这在鸿蒙项目里特别常见。流程通常会变成：

复制代码

❌ 错误顺序：
  我先接一个 Kit → 再想想它能放哪 → 强行塞进 AI 页面

✅ 正确顺序：
  先看 AI 页面卡在哪 → 再找哪项 HarmonyOS 能力能解决这个卡点

食界探味的实际例子：

AI 页面卡点	解决方案	鸿蒙能力
用户打字太麻烦	语音输入	CoreSpeechKit ASR
推荐只能看不能听	语音播报	CoreSpeechKit TTS
AI 入口太深	系统搜索/卡片直达	Intent 导航
用户怕别人看到收藏	防窥保护	AntiPeep Protection

这才叫"能力服务体验"。每一项能力都是因为 AI 页面有对应的卡点才接入的，不是因为"鸿蒙有这个 Kit 所以要接"。

八、比赛和真实产品都更需要这种判断

很多人会以为只有产品长期迭代才需要这个判断。其实比赛项目更需要。

因为比赛里最容易被质疑的，往往就是"你是不是只是把几个能力凑到一起"。

而如果你能讲清楚：

语音识别如何降低 AI 输入门槛（从打字变成说话）
TTS 如何增强 AI 推荐消费方式（从只能看变成可听）
Intent 如何增强 AI 助手触达效率（从深藏菜单变成系统直达）
防窥如何让用户更敢用 AI 收藏（从担心偷看变成安心使用）

那这套能力组合就会显得更像一个完整体验链，而不是零散展示点。

关键代码位置

文件	鸿蒙能力	服务的 AI 体验
`app/lib/core/platform/speech_recognition_channel.dart`	语音识别	AI 输入方式
`app/lib/core/platform/text_to_speech_channel.dart`	TTS	AI 输出方式
`app/lib/core/platform/intent_navigation_channel.dart`	Intent 导航	AI 触达方式
`app/lib/core/platform/anti_peep_protection_channel.dart`	防窥保护	用户信任
`app/lib/core/ai/ai_explore_coordinator.dart`	协调器	能力接入的桥梁
`app/lib/features/ai_assistant/screens/ai_assistant_screen.dart`	AI 页面	体验承载
`app/ohos/entry/src/main/ets/plugins/SpeechRecognitionPlugin.ets`	鸿蒙 ASR	原生语音识别
`app/ohos/entry/src/main/ets/plugins/TextToSpeechPlugin.ets`	鸿蒙 TTS	原生语音播报

鸿蒙能力服务 AI 体验的完整链路图

复制代码

┌─────────────────────────────────────────────────────────┐
│                    系统层（鸿蒙）                         │
│                                                          │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌─────────┐ │
│  │ Core     │  │ Core     │  │ Intent   │  │ Anti-   │ │
│  │ SpeechKit│  │ SpeechKit│  │ Navigation│  │ Peep    │ │
│  │ (ASR)    │  │ (TTS)    │  │          │  │ Protect │ │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬────┘ │
│       │              │              │              │      │
├───────┼──────────────┼──────────────┼──────────────┼──────┤
│       │   MethodChannel             │              │      │
├───────┼──────────────┼──────────────┼──────────────┼──────┤
│                    Flutter 层                           │
│       │              │              │              │      │
│  ┌────▼─────┐  ┌────▼─────┐  ┌────▼─────┐  ┌────▼────┐ │
│  │ Speech   │  │ TextTo   │  │ Intent   │  │ Anti-   │ │
│  │ Recog.   │  │ Speech   │  │ Navig.   │  │ Peep    │ │
│  │ Channel  │  │ Channel  │  │ Channel  │  │ Channel │ │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬────┘ │
│       │              │              │              │      │
├───────┼──────────────┼──────────────┼──────────────┼──────┤
│                    体验层                                │
│       │              │              │              │      │
│  ┌────▼─────┐  ┌────▼─────┐  ┌────▼─────┐  ┌────▼────┐ │
│  │ 改变输入  │  │ 改变输出  │  │ 改变触达  │  │ 改变信任│ │
│  │          │  │          │  │          │  │         │ │
│  │ 打字→说话│  │ 看→可听  │  │ 深→直达  │  │ 担心→   │ │
│  │ 模糊→精准│  │ 文字→语音│  │ 内部→系统│  │ 安心    │ │
│  └──────────┘  └──────────┘  └──────────┘  └─────────┘ │
│                                                          │
│                    AI 助手页                              │
│                                                          │
│  用户说话 → 鸿蒙 ASR → AI 理解 → 工具调用 → 菜品卡片     │
│                                         ↓                │
│                              用户点击"语音播报"           │
│                                         ↓                │
│                              鸿蒙 TTS 朗读推荐           │
│                                         ↓                │
│                              用户收藏 → 防窥保护          │
│                                                          │
└─────────────────────────────────────────────────────────┘

常见坑

先接 Kit，再倒找 AI 场景 → 应该先找体验卡点，再找能力解决方案
把 HarmonyOS 能力做成孤立按钮 → 能力必须嵌进真实交互链路
只强调"用了什么能力"，不解释"它改变了哪段体验" → 每项能力都要回答"改变了什么"
把比赛展示逻辑和真实产品逻辑完全割裂 → 比赛也应该讲清楚体验链路
接了能力但不处理边界情况 → 如语音识别失败、TTS 引擎创建失败、Intent 路由未知
没有评估能力的真实价值 → 如果一项能力只是"有总比没有好"，可能不值得接

可复用模板

能力评估清单

复制代码

接入一项鸿蒙能力前，先回答：
  □ 它改善的是 AI 的输入、输出、触达还是信任？
  □ 没有它，AI 页面会卡在哪？
  □ 它是不是进入了真实交互链路（不是孤立按钮）？
  □ 它有没有边界情况需要处理（失败、超时、引擎不存在）？
  □ 它的产品价值能不能用一句话讲清楚？

体验链路描述模板

复制代码

语音识别
  原来：用户必须打字输入，只能用关键词
  现在：用户可以直接说话，用自然语言表达模糊需求
  价值：降低 AI 使用门槛，获取更丰富的意图信息

TTS
  原来：AI 推荐只能看文字
  现在：AI 推荐可以被语音播报
  价值：在不方便看手机时也能消费 AI 内容

Intent 导航
  原来：AI 助手只能从应用内层层点击进入
  现在：可以从系统搜索、卡片、外部调用直达
  价值：缩短用户触达 AI 的路径

防窥保护
  原来：用户担心在公共场合暴露收藏内容
  现在：防窥机制自动保护隐私
  价值：让用户更敢使用 AI 收藏功能

能力接入代码模板（Flutter Channel 层）

复制代码

// 统一的 Channel 封装
class HarmonyCapability {
  static const _channel = MethodChannel('com.foodvoyage.capability_name');

  static Future<Result> doAction(Params params) async {
    try {
      final result = await _channel.invokeMethod<Result>(
        'actionName',
        params.toJson(),
      );
      return result ?? defaultResult;
    } on MissingPluginException {
      // 鸿蒙插件不可用（非鸿蒙平台）------ 优雅降级
      return defaultResult;
    } catch (e) {
      // 处理错误
      return errorResult;
    }
  }
}

体验优先级排序模板

复制代码

优先级 1（必须接入）：
  - 直接解决 AI 核心卡点的能力
  - 例：语音识别（解决输入门槛）

优先级 2（应该接入）：
  - 显著增强 AI 体验的能力
  - 例：TTS（增强内容消费方式）

优先级 3（可以接入）：
  - 增强触达或信任的能力
  - 例：Intent 导航（缩短入口路径）

优先级 4（谨慎接入）：
  - 和 AI 体验关系不紧密的能力
  - 除非能明确讲出它改变了什么，否则不接

本篇总结

让 HarmonyOS 能力真正服务 AI 体验，关键不是"接上更多 Kit"，而是让每项能力都准确进入 AI 的输入链路、输出链路、触达链路或信任链路。

食界探味当前最有价值的地方就在于，它已经开始让语音、TTS、Intent 这些能力进入真实 AI 体验，而不是只停留在"接过某个 Kit"的层面。

判断标准很简单：

它改变了什么？ --- 输入、输出、触达、信任，至少改变一个
没有它会怎样？ --- AI 页面会卡在哪，体验会差多少
它进入了真实链路吗？ --- 不是孤立按钮，而是嵌进了交互流程

在鸿蒙设备上，CoreSpeechKit、Intent Navigation、AntiPeep Protection 这些能力本身不是目的，它们是让 AI 体验更好的手段。"为了接 Kit 而接"只会让项目变成能力拼装；"为了体验而接"才能让项目成为完整的产品。