适合谁看

• 正在评估 TTS 是否值得接入的人

• 做内容型、知识型、AI 型应用的人

• 想让鸿蒙系统能力真正服务产品的人

问题背景

TTS 常被误判为"可有可无"的原因在于，很多 Demo 只展示：点一下，读一段。

但这还不是内容型应用真正关心的价值。真正的问题是：

• TTS 能不能延长用户的使用场景？

• TTS 能不能降低 AI 的交互门槛？

• TTS 能不能让推荐结果更自然？

• TTS 能不能形成完整的语音闭环？

项目中的真实场景

食界探味当前在两个地方使用了 TTS：

页面	播报内容	触发方式	价值
AI 助手页	AI 推荐文案	用户点击"语音播报"	让 AI 回复可听
菜品详情页	AI 导览词（灵魂+风味+描述）	用户点击"语音播报"	让内容讲解可听

底层都通过 TextToSpeechChannel 调用鸿蒙 CoreSpeechKit。

核心实现

一、四类真实价值

在内容型应用里，TTS 至少有四类真实价值：

价值 1：把阅读场景延展成听读场景

没有 TTS：
  用户只能看文字 → 场景受限（做饭时不方便看手机）

有 TTS：
  用户可以边做边听 → 场景扩展（做饭、开车、散步都能用）

对食界探味来说，用户在厨房里想探索美食时，语音播报让 AI 推荐真正"触手可及"。

价值 2：让 AI 回复更像交互，而不只是文本回执

没有 TTS：
  AI 助手 → 输出文字 → 用户看 → 结束（像搜索结果）

有 TTS：
  AI 助手 → 输出文字 → 用户点击播报 → "听到"推荐 → 更像对话

AI 助手的产品语义是"有个助手在和你推荐美食"。TTS 让这个语义从"看文字"变成了"听声音"，陪伴感更强。

价值 3：降低输入输出门槛

当项目已经接了语音识别（ASR），再接 TTS，用户就能得到一条更完整的链路：

语音输入 + TTS 输出：
  嘴说 → ASR 识别 → AI 理解 → 工具调用 → 推荐文案 → TTS 播报 → 耳朵听

只有 ASR：
  嘴说 → ASR 识别 → AI 理解 → 推荐文案 → 用户还得看屏幕

第二条链路更完整——用户全程不需要打字和看屏幕。在鸿蒙设备上，ASR 和 TTS 都来自 CoreSpeechKit，接入成本低，形成闭环的价值高。

价值 4：让系统能力和内容本身发生关系

没有 TTS 时：
  鸿蒙 CoreSpeechKit → 接了但只是 Demo → 和业务无关

有 TTS 时：
  鸿蒙 CoreSpeechKit → 播报 AI 推荐文案 → 直接服务内容消费

在食界探味里，TTS 不是独立功能页，而是服务于菜品推荐解释和 AI 助手回答。这就是"能力服务内容"，而不是"内容配合能力演示"。

二、AI 助手页的 TTS 价值分析

AI 助手页的 TTS 不是"给回复加个朗读按钮"，而是改变了 AI 推荐的消费方式：

用户问："今晚想吃点热乎的"
AI 回复："为你找到了3道适合下雨天的热乎吃法：日式拉面、
         泰式冬阴功汤、意大利番茄浓汤。拉面最暖胃，冬阴功更开胃。"

没有 TTS：
  用户看文字 → 点击卡片 → 看详情（需要一直盯屏幕）

有 TTS：
  用户看文字 → 点击"语音播报" → 边做饭边听推荐
  → 听到感兴趣的 → 点击卡片看详情

TTS 在这里的价值是：让用户在不方便看屏幕时也能消费 AI 推荐。

三、菜品详情页的 TTS 价值分析

菜品详情页的 TTS 是通过 speakDishNarration() 实现的：

Future<void> speakDishNarration(Dish dish) async {
  final parts = <String>[];
  if (dish.soul.isNotEmpty) {
    parts.add('这道${dish.name}的灵魂在于${dish.soul}');
  }
  if (dish.flavorTags.isNotEmpty) {
    parts.add('它的风味特点是${dish.flavorTags.join("、")}');
  }
  if (dish.description.isNotEmpty) {
    parts.add(dish.description);
  }
  parts.add('如果你喜欢这种口味，可以继续探索更多${dish.ingredientName}的全球吃法');
  final narration = parts.join('。');
  await speakText(narration);
}

这段导览词把菜品的多个维度拼接成自然语言：

"这道日式茶碗蒸的灵魂在于细腻的蛋液和鲜美的高汤完美融合。
 它的风味特点是鲜、嫩、滑。
 如果你喜欢这种口味，可以继续探索更多鸡蛋的全球吃法。"

这比"这是一道日本菜，主要食材是鸡蛋"更有温度。TTS 让这段内容从"屏幕上的文字"变成了"助手在给你讲故事"。

四、TTS 和 ASR 的闭环效应

食界探味同时接了 ASR（语音识别）和 TTS（文本转语音），形成了完整的语音闭环：

┌─────────────────────────────────────────┐
│              语音闭环                     │
│                                          │
│  用户说话                                │
│    ↓                                     │
│  鸿蒙 ASR（CoreSpeechKit）              │
│    ↓                                     │
│  Flutter 接收文本                        │
│    ↓                                     │
│  AI 理解意图 + 工具调用                   │
│    ↓                                     │
│  推荐文案生成                             │
│    ↓                                     │
│  用户点击"语音播报"                       │
│    ↓                                     │
│  鸿蒙 TTS（CoreSpeechKit）              │
│    ↓                                     │
│  用户听推荐                               │
│                                          │
└─────────────────────────────────────────┘

单独接 ASR 或单独接 TTS 都有价值，但两者同时接形成闭环后，价值会倍增。用户可以"全程用嘴和耳朵"完成美食探索，不需要打字和看屏幕。

五、什么时候 TTS 不值得接

TTS 不是万能的。如果一个场景满足以下特征，TTS 价值可能不高：

特征	为什么 TTS 不适合
内容特别短（一句话）	听一遍不如看一遍快
用户主要是快速点击结果	播报拖慢交互节奏
页面交互节奏很快	声音跟不上文字更新
内容不适合朗读	代码、数据表格读出来很奇怪
用户群体主要是视觉型	听觉需求不强

TTS 更适合的场景：

场景	为什么 TTS 适合
内容型（美食推荐、文章朗读）	内容本身值得被听
推荐型（AI 助手推荐）	像朋友在给你推荐
陪伴型（对话式 AI）	增强"有人在和你说话"的感受
不方便看屏幕的场景	做饭、开车、散步

六、鸿蒙端 TTS 的特殊价值

在鸿蒙设备上，TTS 还有一层特殊价值：让 CoreSpeechKit 能力真正参与产品体验链路。

没有产品场景时：
  鸿蒙 CoreSpeechKit → 接了但只是 Demo → 比赛展示用

有产品场景时：
  鸿蒙 CoreSpeechKit → 播报 AI 推荐 → 直接服务内容消费

这意味着 TTS 在鸿蒙项目里不只是"接了一个 Kit"，而是让鸿蒙能力真正改变了用户消费内容的方式。

关键代码位置

文件	作用
app/lib/core/platform/text_to_speech_channel.dart	Flutter TTS 通道
app/lib/core/ai/ai_explore_coordinator.dart	speakText + speakDishNarration
app/lib/features/ai_assistant/screens/ai_assistant_screen.dart	AI 助手页 TTS 触发
app/lib/features/dish_detail/screens/dish_detail_screen.dart	菜品详情页 TTS 触发
app/ohos/entry/src/main/ets/plugins/TextToSpeechPlugin.ets	鸿蒙 TTS 插件

TTS 价值矩阵

价值维度	没有 TTS	有 TTS	差异
使用场景	只能看屏幕	边做边听	场景扩展
AI 交互感	像搜索结果	像对话推荐	陪伴感增强
输入输出	需要打字+看屏	说话+听	门槛降低
系统能力	Demo 展示	服务内容	能力落地
鸿蒙体验	Kit 拼装	产品链路	体验完整

常见坑

• 只因为系统支持就接 TTS，却没有明确业务场景 → TTS 很快变成摆设

• 所有长文本都默认自动播报，打扰用户 → 应该让用户主动触发

• 没有 stop 机制，体验失控 → 鸿蒙端会出现后台播放

• TTS 播报没有清理 Markdown 格式 → 鸿蒙引擎会把符号读出来

• 只接了 TTS 没接 ASR → 语音闭环不完整

• TTS 做成了独立功能页 → 和业务脱节，没有产品价值

可复用模板

TTS 价值判断清单

接入 TTS 前，先回答：
  □ TTS 能不能延长用户的使用场景？
  □ TTS 能不能降低 AI 的交互门槛？
  □ TTS 能不能让推荐结果更自然？
  □ TTS 能不能形成完整的语音闭环？
  □ 用户是否可能在"不盯屏"场景使用？

TTS 价值描述模板

[TTS 功能名]
  原来：用户只能 [原有方式]
  现在：用户可以 [新方式]
  价值：[具体的产品价值]

示例：
  AI 推荐播报
  原来：用户只能看文字推荐
  现在：用户可以边做饭边听推荐
  价值：在不方便看手机时也能消费 AI 内容

鸿蒙 TTS 能力落地模板

鸿蒙 CoreSpeechKit TTS
  ↓ 接入
Flutter TextToSpeechChannel
  ↓ 调用
协调器 speakText() / speakDishNarration()
  ↓ 触发
AI 助手页 / 菜品详情页
  ↓ 用户点击
语音播报 → 鸿蒙引擎朗读

本篇总结

TTS 在内容型应用里的核心价值，不是"给应用加一个会朗读的功能"，而是把文本交付升级成多模态交付。具体来说：

1. 延长场景 — 从"看屏幕"到"边做边听"

2. 增强交互 — 从"文本回执"到"语音对话"

3. 降低门槛 — 从"打字+看屏"到"说话+听"

4. 落地能力 — 从"Demo 展示"到"服务内容"

食界探味把 TTS 放进 AI 助手和菜品详情页，是因为这两个场景天然适合"可听化"。在鸿蒙设备上，CoreSpeechKit 的 TTS 能力通过 Flutter Channel 接入，直接服务于 AI 推荐和菜品讲解——这才是系统能力真正服务产品的样子。

只有技术接入，没有产品场景，TTS 很快就会变成摆设。