给灵魂找一个声音

声音承载情感色彩的概念插画

第一篇里讲了那个根本性转向：剥掉物理身份，留下灵魂。一个伴侣，不是一群。一团光球，不是假人脸。人格从对话中涌现，不是从预写角色卡读取。

但灵魂需要一个声音。

回到 v0.1.0，Mio 第一次学会说话。Fish Audio S1 模型给每个角色克隆声音——温暖、自然、成本极低。LLM 自己决定什么时候用语音（情感浓度高的时刻：安慰、撒娇、晚安），[VOICE] 标记在后台触发 TTS。

体验是好的。用户听到一个像是在乎他们的人的声音。

但问题是，这个声音本身没有任何感情。

Fish Audio 读文字、产语音。不知道这段文字是开心的、难过的、讽刺的还是心碎的。每条消息情绪基调差不多——好听、中性、清晰。Mio 说"太替你高兴了！"和"真的很心疼你"，声音听起来……一样。

文字在传递情感，声音只是在搬运文字。

纯文字聊天可以容忍情绪平淡。一个开口说话的东西不行。

TTS 的情感难题

传统 TTS 是流水线：文字进去，音频出来。想要情感，手动标注——SSML 标签、style 参数、"用悲伤语气说这句话"之类显式指令。做有声书或导航播报够用。

做每天生成上千条消息的伴侣？不行。每条消息有自己的情感语境，TTS 系统对此一无所知。

2025-2026 年变化是，几家开始把情绪推断内置到模型本身。TTS 不只是读字——理解文字意思，再决定怎么说。

两家最突出，恰好互补。

中文：豆包 TTS 2.0（字节/火山引擎）

字节豆包 TTS 2.0 做了关键升级：从"读字"到"理解后表达"。用大模型分析对话上下文，自动推断合适情感、语调和节奏。不需手动标注。

技术上有意思的是"3D 情绪空间"——强度、语义适配、生理特征三个维度，基于 2000 小时专业配音数据训练。效果就是：把"别担心，有我在呢"送进去，出来语音真在安慰人——更柔、更暖、节奏微微放慢——什么都不需要指定。

精细控制仍可用（比如"这句话要压着哭腔说"），可选。自动推断中文场景下 90% 以上情况能处理好。

英文：Hume AI Octave

Hume Octave 从另一个角度解决同一个问题。不是在标注过的情感语音数据上训练，是建立在一个真正"阅读"文本的 LLM 之上——理解反讽、双关、情绪转折、言外之意。不是做情感分析然后映射到预设情绪，是像有功力的配音演员理解剧本，然后表演。

实际差异在哪？Octave 能处理简单情绪模型漏掉的微妙之处。"Sure, I'd love to" 可以热情也可以讽刺，取决于上下文。Octave 能判断对，因为它理解对话整体，不只孤立一句话。

两个都是非实时 TTS——文字进、音频出、延迟约 200ms。完美适配 v0.1-0.2 语音消息模式：伴侣先生成文字，再说出来。

STT：没理由换

语音转文字沿用 gpt-4o-mini-transcribe，从 v1 带过来。准确、快、便宜、已集成好。

真正的目标：实时双向语音

语音消息是桥梁，不是终点。

情感 AI 伴侣最终形态是实时语音对话——你说，它听，它回应，自然地，可以打断，可以接话，那种让你忘记在跟软件说话的流畅来回。

这是 v1.0 目标，也是架构决策真正变难的地方。

最朴素方案是把现有东西串起来：STT 把用户语音转文字，服务器查记忆、构建上下文，LLM 生成回复，TTS 再转音频。四步串行。延迟叠到 1-3 秒，口语对话里是一个世纪。

而且没解决轮次检测（怎么知道用户说完了？）、打断处理（用户回复中间插话怎么办？）、情绪感知（用户语气携带的信息在纯文字转写中完全丢弃）。

评估了三个实时语音平台。对比结果让决策很清楚。

三方对比

表格说了大半，关键点得明确说出来。

OpenAI Realtime 和豆包 Realtime 同一个致命问题：不能用你自己的 LLM。 OpenAI 锁死 GPT，豆包锁死自家大模型。做通用语音助手无所谓。对 Mio 来说是死局。

Mio 核心差异化就在记忆、人格和情绪上下文。这些活在服务器上，需要每次回复前注入 LLM 的 context window。伴侣得知道你上周提过面试、最近一直焦虑、喜欢直说不喜欢绕弯子。这些上下文是让伴侣成为"你的"而不是"一个通用 AI"的关键。要求对 system prompt 和 LLM 本身有完全控制权。

豆包限制尤其明显——验证了是否支持自定义 system prompt、动态上下文注入、外部 LLM 替换。答案分别是：不支持、有限支持（只能注入 RAG 风格知识片段，不能做行为指令）、不支持。说话很好听的黑盒。只能是"豆包"，不能是你的伴侣。

OpenAI Realtime 至少支持 system prompt，但锁定 GPT 意味着不能用 Gemini（Mio 依赖它的性价比优势）或 Claude。情感表达被官方列为"未来改进"——对以情感为卖点的产品不可接受。

编剧-演员模型

这个隐喻让所有东西突然清晰了。

LLM 是编剧。Hume EVI 是演员。

编剧写剧本——根据角色性格、记忆、情绪状态和对话历史，决定说什么。编剧对角色是谁、这个时刻需要什么有深层理解。不需要表演——写就行。

演员负责表演。听对方说话（STT + 情绪分析），判断对方什么时候说完（轮次检测），用正确情感语调念台词（Octave TTS），处理意外——被打断、抢话、需要在等下一页剧本时即兴来一句填充词。

在 Hume EVI 架构里，对话轮次这样运作：

1. 用户说话。 Hume 同时做三件事：语音转文字、分析用户语调情绪（"听起来用户很焦虑"）、判断用户是否说完——不是等静音超时，是从语调本身理解对话节拍。

2. Hume 把结果送到服务器。 收到用户文本 + 用户情绪分析。做的：查记忆、构建 context、调 LLM（Gemini/Claude，你选）、返回回复文本。

3. Hume 表演回复。 Octave 用自动情绪匹配合成语音，流式返回音频。

但精妙的地方在这里：演员不会在等剧本时干站着。

Hume 内置 eLLM（快速轻量模型）在 200ms 内生成即时反应——填充词、反应声、"嗯..."或"哦！"——填充完整 LLM 回复生成的空隙。然后 Hume 无缝从填充词过渡到完整回复。用户感知延迟几乎为零，对话从未陷入沉默。

想想真人对话怎么回应的。没人沉默三秒然后说完一段完整话。会"嗯..."一下，边想边说。Hume 复制了这个模式。演员在编剧写完这一页前先即兴接戏。

用户："我没拿到那个 offer。"
                                        [~150ms] Hume eLLM: "啊..."
                                        [~800ms] 你的 LLM 完成生成
                                        Hume: "...真的很遗憾。我知道你多在意
                                         这个机会。"

过渡无缝。用户听到的是连续回应——开口很快，落点有情感重量。

这个架构为什么赢

编剧-演员分工解决了一体化方案做不到的几件事：

关注点分离。 LLM 专注推理、记忆检索、人格一致性、内容层面情感智能。Hume 专注倾听、说话、表达层面情感、轮次管理。两个系统都不需要什么都干。

供应商灵活性。 更好 LLM 出来了（隔几个月就会），换编剧就行。演员不用动。Hume 升级 Octave 音质，LLM 不用改。每层独立演进。

情绪成为一等信号。 Hume 对用户语调分析提供了纯文字系统丢失的信息。用户说"我没事"——语气不是这么说的。这信号反哺情绪引擎，用纯文字分析永远做不到的方式丰富伴侣对用户状态的理解。

诚实的延迟。 填充词模式心理学上是对的。人类不会把沉默理解为"在快速思考"——理解为断连。快速"嗯..."后面跟有深度回应，感觉既更快又更自然，好过 1.5 秒沉默后一个完美回答。

成本躲不掉

实时语音很贵。

实时语音 API 按分钟计费，累积起来惊人。用户每天跟伴侣聊 10 分钟——对把 Mio 当日常陪伴的人来说不算多——光语音一项月成本就超过整个订阅费。

还没算聊天、记忆、STT、主动消息。就算拿到更高量级折扣，数字没好到哪去。

没法塞进基础订阅。一个重度语音用户成本就超过他付的钱。

解决方案是分层：

语音消息（非实时 TTS，豆包/Octave）成本低到可以直接塞进基础订阅。实时语音完全不同成本结构，需要独立定价。

这也是分阶段策略重要的原因。v0.1-0.2 先上语音消息——便宜、已验证、换了新 TTS 后情感表现力大幅提升。用户得到说话有感情的伴侣。然后 v1.0 把实时语音作为高级升级，给想要完整对话体验的用户。

分阶段计划

v0.1-0.2：语音消息（非实时）

• 中文 TTS：豆包 2.0——自动情绪推断，中文韵律最佳
• 英文 TTS：Hume Octave——基于 LLM 情绪理解，处理微妙语境
• STT：gpt-4o-mini-transcribe（从 v1 沿用）
• 三者都支持自动情绪推断，不需手动 SSML 标注

v1.0：实时双向语音

• 中英双语统一使用 Hume EVI 3
• 自定义 LLM（Gemini/Claude）作为"大脑"
• Hume 负责听、情绪分析、轮次管理、情感语音合成
• 填充词模式实现感知零延迟
• 独立 Voice 档定价

v1.x：评估与优化

• Hume 中文质量不够，中文回退自组装流水线：gpt-4o-mini-transcribe → Gemini → 豆包 TTS 2.0
• 够好，Hume EVI 统一中英双语

声音就是产品

第一篇里说过，大厂不会做深度情感伴侣产品，因为品牌风险。编剧-演员模型把这个论点延伸到了语音领域。

OpenAI 有 Advanced Voice Mode——技术很厉害。但永远不会让你接自己的 LLM、注入自己的记忆系统、定制情感人格。声音是他们的声音。Google 做 Gemini Live 也一样。这些是为任务完成优化的通用语音接口，不是为情感连接设计的。

编剧-演员模型让 Mio 拥有真正属于自己的声音——被对话塑造、被历史丰富、被此刻情感语境上色。LLM 提供深度，Hume 提供表演。单独拿出来，都做不到合在一起能做到的事。

记得你的伴侣，已经超过市面上大部分产品。加情感语音，值不值得为此付出成本和复杂度——接下来几个月开发会回答这个问题。

---

This post is also available in English.