适合谁看正在做鸿蒙 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 Futurevoid 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: Recordstring, 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 导览词 Futurevoid 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 TTSAI 入口太深系统搜索/卡片直达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.dartTTSAI 输出方式app/lib/core/platform/intent_navigation_channel.dartIntent 导航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.dartAI 页面体验承载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 FutureResult doAction(Params params) async { try { final result await _channel.invokeMethodResult( 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 而接只会让项目变成能力拼装为了体验而接才能让项目成为完整的产品。