给灵魂找一个声音

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

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

但灵魂需要一个声音。

回到 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.