速成课 · No. 35
语音改变了 AI 产品的一切。它必须听、理解、思考、再回答——还要快到像一场对话，而不是对讲机。里面是一条由三段组成的流水线，加上一个真正棘手的难题：实时地把这一切做完。
18 个概念 · 每个配一幅图 · 结尾有速查表
语音 AI 不是单一的一样东西——它是三项工作串成的一条链。先看清这条流水线，本课其余的一切就都各归其位了。
地图：七组共 18 个概念
一张地铁图：先看整条线路，再一站一站地乘过去。
本课的概念分成七组。先是流水线本身。然后是它的两端：耳朵（语音转文字）和嘴巴（文字转语音）。接着是核心难题——延迟。再是对话的编排——谁在什么时候说话。然后是较新的路线——实时模型。最后是如何明智地使用语音。
如何阅读每个概念
一本护照：每个人的栏目都一样，所以很容易比较。
下面每个概念都有同样的几部分：它的英文名称（记住它——你在文档里就靠它去查）、一幅日常的画面、一幅图，以及一张卡片，卡片里有这些栏目：是什么、怎么运作、例子、陷阱，以及关联的概念。整门课贯穿着一个想法：延迟就是一切。
Voice Pipeline——耳朵、大脑、嘴巴
一个人在交谈：他听见你说的话，思考一番，再开口回答。三个截然不同的动作，感觉却像一件事。
语音 AI 依次做三件事。它听——把语音变成文字。它想——模型读这段文字并写出回复。它说——把回复再变回音频。这几个阶段都有名字：Speech-to-Text（STT）、模型（LLM）和 Text-to-Speech（TTS）。这条链也叫 cascade（级联）。大多数语音 AI 正是这样搭起来的。
- 是什么
- 三个阶段组成的一条链：语音转文字、模型、文字转语音。
- 怎么运作
- 语音进 → 转写 → 推理 → 合成 → 语音出。
- 例子
- 用户说“两个人的位子”，STT 把它记下来，模型作出回复，TTS 把回复读出来。
- 陷阱
- 三个阶段首尾相接——三处延迟的来源。
- 关联
由 Speech-to-Text、LLM Core 和 Text-to-Speech 组成；替代方案是 Speech-to-Speech。
LLM Core——还是那个模型，只是边缘是新的
你早就会用文字思考和回答了。学会用语音交谈，只是在同一个核心的周围加上听和说。
推理的核心，就是其他所有课程里的那个语言模型（LLM）。上下文、提示、工具、结构化输出——这一切对中间的文字依然适用。新东西只是两端的音频：把声音变成文字，再把文字变成声音，要可靠，还要快。你不用重学大脑。你只是加上耳朵和嘴巴——并学会让语音变难的那件事：在对话所要求的紧凑节奏内把这一切做完。
- 是什么
- 语音流水线中间的一个普通文字模型。
- 怎么运作
- 接收 STT 的文字，为 TTS 写出文字回复。
- 例子
- 同样的提示、同样的工具、同样的输出结构，和文字聊天机器人一模一样。
- 陷阱
- 模型只看得到文字——它不知道某句话_是怎么_说出来的。
- 关联
- Voice Pipeline 的中间一段；Speech-to-Speech 把它去掉了。
语音 AI 就是一条流水线：耳朵（STT）、大脑（模型）和嘴巴（TTS）。大脑你已经熟悉；新的是两端的音频，以及各阶段之间的时间。
第一个阶段把声音变成文字。它如今已经相当出色，但它的错误会影响后面的一切，所以值得弄清它能做什么、不能做什么。
Speech-to-Text——声音变成文字
法庭上的速记员，每说一个字就敲下一个字——把语音的洪流变成系统其余部分能读的记录。
Speech-to-Text（STT）——也叫转写或 ASR（自动语音识别）——把说出的音频转换成书面文字。它是系统的耳朵：用户说话，STT 产出模型将要据以推理的文字。现代 STT 准确得令人印象深刻，处理自然、杂乱的口语，比过去笨拙的语音识别强得多。正是这一步，让人可以直接说话而不必打字。
- 是什么
- 系统的耳朵：把语音变成文字。
- 怎么运作
- 听音频，输出模型要读的文字。
- 例子
- 用户说话——出来的是字符串“两个人的位子”。
- 陷阱
- 并不完美：口音、噪音、人名和行话都会造成错误。
- 关联
- Voice Pipeline 的第一个阶段；它的错误就是 Error Propagation。
Error Propagation——耳朵的错误会顺流而下
速记员要是听错了一个字，之后的每个读者都会继承这个错误。它从一开始就被固定下来了。
STT 并不完美：口音、背景噪音、串音、专业术语和人名都可能导致转写错误。而且由于 STT 是第一个阶段，它的错误会一路传播——模型只会对拿到的文字进行推理。一个听错的字，就能悄悄带偏整个回复。语音系统的好坏，取决于它的转写。所以要为不完美的输入做设计：模型应当从容应对略有错乱的文字，而你要留意耳朵最吃力的那些场合。
- 是什么
- 一个转写错误，成了后面每个阶段的输入。
- 怎么运作
- 模型听不到音频——它只信任拿到的文字。
- 例子
- STT 听错了一个人名——模型信心十足地去查了另一个人。
- 怎么办
- 为不完美的输入做设计；留意真实用户的噪音和口音。
- 关联
- Speech-to-Text 的弱点；LLM Core 看不到它。
Streaming STT——用户说话时就开始转写
一位在你说话时不停敲字的速记员，而不是等整场讲话结束才动笔的那位——文字和话语同步出现。
STT 可以是流式的（streaming）——在用户说话的同时持续转写，而不是等他们说完再处理整段录音。这关系到速度：系统更早开始工作，用户一停下就能作出反应，而不是平白多出一段长长的停顿。是等到最后再转写，还是边说边转写，是语音系统最先要做的延迟决策之一，而流式通常正是让它显得“活”的原因。
- 是什么
- 用户还在说话时就持续转写。
- 怎么运作
- 文字在说话期间不断累积——句子结束时已经差不多备好了。
- 例子
- 用户一说完，系统立刻回复，而不是先停顿一下去转写。
- 陷阱
- 没有它，每个回复前面都会有一段明显的停顿。
- 关联
- Streaming TTS 的孪生兄弟；属于 Stream & Overlap 的一部分。
STT 是耳朵：它把语音变成文字交给模型。它的错误会顺流而下，所以要为不完美的输入做设计——并且在用户说话时就开始转写。
最后一个阶段把模型的文字回复变回声音。这是用户真正听到的部分，所以它的质量决定了整个产品给人的感觉。
Text-to-Speech——文字变成声音
一位朗读剧本的播音员——把书面文字变成自然、有表现力的语音，而不是背书。
Text-to-Speech（TTS），也叫语音合成，把模型的文字回复转换成音频。它是系统的嘴巴。现代 TTS 能产出相当自然的声音，语调和节奏都很真实，远非过去那种平板的机器人腔可比。一条出色的流水线配上机器人嗓音，依然显得廉价。自然的声音让整个交互有了人味——这也是语音产品终于可行的重要原因。
- 是什么
- 系统的嘴巴：把回复文字变成声音。
- 怎么运作
- 接过模型的文字，合成带有语调和节奏的语音。
- 例子
- 字符串“已订好位子”变成一句温暖自然的话。
- 陷阱
- 机器人嗓音会让再出色的流水线也显得廉价。
- 关联
Voice Pipeline 的最后一个阶段；Voice Persona 定下它的语气，Streaming TTS 决定它的速度。
Voice Persona——声音承载着体验
同样的话，说得温暖或说得冷淡，听上去截然不同。听者回应的是说话的方式，而不只是内容。
在语音产品里，话怎么说和说什么同样重要。选哪种声音、什么语气、什么节奏——这些都是产品决策，会左右信任感和舒适度，就像视觉设计之于屏幕产品。声音太快、太平、语调古怪，都会糟蹋一个本来不错的回答。所以 TTS 不是最后随手加上去的附件。声音（voice persona）要像其他界面元素一样，有意识地挑选和调校。
- 是什么
- 选定的声音、语气和语速——语音产品的“脸”。
- 怎么运作
- 表达方式改变同一个回答被接收的方式。
- 例子
- 用平静温暖的声音说“您的订单延迟了”——对比同样的话，又快又平。
- 陷阱
- 没调校过的默认声音，会削弱人们对好回答的信任。
- 关联
- Text-to-Speech 的一项设置；属于 Conversation Flow 的一部分。
Streaming TTS——边写边说
有人想到答案就开口说，而不是先默默把整段话组织好，再一口气讲出来。
正如 STT 可以流式地“进”，TTS 也可以流式地“出”——回复的后半部分还在生成时，就先把开头说出来。不必等完整的文字和完整的音频都备好才发出声音。用户几乎立刻就听到回复开始，而不是坐在沉默里等。再加上模型本身也是流式输出文字，语音 agent 才能没有尴尬的空档地作答：一有话可说，语音就开始了。
- 是什么
- 回复的后半部分还在生成时，就先把开头念出来。
- 怎么运作
- 模型一块一块地输出文字；TTS 立刻把每一块变成音频。
- 例子
- 回复的头几个字几乎立刻响起，而不是沉默之后。
- 陷阱
- 没有流式，整段回复生成期间，用户都得坐在沉默里。
- 关联
- Streaming STT 的孪生兄弟；属于 Stream & Overlap 的一部分。
TTS 是嘴巴：它把模型的回复念出来，而现代的声音自然到足以承载整个体验。把语音做成流式，让回复立刻开始，而不是沉默之后。
这正是语音真正困难的地方。对话有它的节奏，整条三段式流水线必须塞进这个节奏里——否则魔法就破了。
Latency Budget——对话的时间窗口很窄
真实的交谈里，慢半拍的回应显得别扭；过了好几秒才回应，就像坏掉了。“自然”的窗口很小。
人们期待在几分之一秒内得到对话式的回应。在聊天应用里根本察觉不到的延迟，在语音里就格外刺眼——你说完之后沉默了几秒，就像系统卡死了。这个狭窄的窗口——latency budget（延迟预算）——是语音 AI 的决定性约束。整个往返——听、转写、思考、合成、说出——都必须塞进去。错过了，哪怕回答再完美，也像是坏的。
- 是什么
- 一场实时对话所能容忍的响应时间窗口——几分之一秒。
- 怎么运作
- 从“听”到“说”的一切，都必须塞进这个窗口里。
- 例子
- 在聊天里没人察觉的两秒停顿，在语音里听起来就是“系统卡死了”。
- 陷阱
- 错过它，哪怕答案正确，也像是坏的。
- 关联
被 Latency Stacking 吃掉；靠 Stream & Overlap 和 Speech-to-Speech 挽救。
Latency Stacking——延迟会叠加
一场接力赛，总用时是每一棒加起来的和——任何一处交接慢了，整个队伍都会晚。
残酷的是，延迟会沿着流水线累积。转写的时间 + 模型思考的时间 + 合成的时间——全都叠成用户感受到的那段停顿。每个阶段单独看“够快”并不够，要是它们的总和超出了预算。这就是语音比文字难的原因：文字聊天只等模型，而语音要依次等三个阶段——而且对话的窗口窄得多。
- 是什么
- 三个阶段的延迟加起来，变成一段总的停顿。
- 怎么运作
- 严格按顺序运行时，总延迟 = STT + 模型 + TTS。
- 例子
- 每个阶段都“很快”，合在一起却在每句话之后留下一段尴尬的沉默。
- 陷阱
- 只优化一个阶段不够——用户感受到的是总和。
- 关联
打破 Latency Budget；靠 Stream & Overlap 或 Speech-to-Speech 修复。
Stream & Overlap——让各阶段并行运行
一位同声传译，你一边说他一边翻，话说到一半就开始说出回应——让各阶段重叠，而不是严格地一个接一个。
关键技术是对各阶段做流式处理并让它们重叠，而不是严格按顺序运行。用户说话时就转写。不等问题处理完，就让模型开始生成。回复还没写完，就开始说。让三个阶段重叠，而不是等每个都做完，是语音系统把总延迟压缩到对话水平的办法。低延迟语音的全部技艺，就是让流水线持续流动，不在每个阶段停下又重新启动。
- 是什么
- 三个阶段全部流式处理，同时运行，而不是轮流。
- 怎么运作
- STT 边说边转写，模型提早开工，TTS 在模型写的同时就开口。
- 例子
- 语音 agent 的回复没有空档，尽管它内部仍然是同样的三个阶段。
- 陷阱
- 流式系统比“做完一个阶段、交给下一个”难搭得多。
- 关联
结合了 Streaming STT 和 Streaming TTS；满足 Latency Budget 的主要办法。
对话的延迟预算很紧，而三个阶段的延迟会叠加。对它们做流式处理并重叠——转写、思考、说话并行，而不是按顺序。
除了速度，自然的对话还有一套谁在什么时候说话的编排。这正是让语音 agent 显得真实还是笨拙的分水岭。
Turn-taking——知道用户何时说完
好的倾听者分得清换气的停顿和一句话的结束——不会你每停一下就插嘴。
语音系统必须判断用户是真的说完了，还是只是话说到一半停了一下。这就是 turn-taking：知道什么时候轮到系统。插得太早，会打断用户；等得太久，对话就拖沓。这个判断出奇地难，也是显得自然的关键。人类靠细微的线索毫不费力地做到；语音 agent 得把它近似得足够好，这样一来一往才会流畅，而不是磕磕绊绊。
- 是什么
- 这个判断：这次停顿是换气，还是这一轮结束了？
- 怎么运作
- 系统听着这些停顿，决定什么时候轮到自己。
- 例子
- “我想订……[停顿]……周五的”——第一次停顿之后，现在回复还太早。
- 陷阱
- 太早会打断用户；太晚会让对话拖沓。
- 关联
- 与 Barge-in 一起，构成 Conversation Flow。
Barge-in——被打断时让出话头
当你开口盖过别人的话，对方会停下来听你说——而不是继续硬着头皮说完自己的句子，好像你什么都没说。
真实的对话包含打断。如果用户在 AI 说话时开口——这就是 barge-in——自然的系统会停下、倾听，并回应新的输入，而不是在他们的话头上把预先写好的回复说完。支持打断是好语音 agent 的标志；差的则浑然不觉地盖过你的话。处理 barge-in，意味着系统始终在听，即使它自己正在说话，随时准备在用户接过话头的瞬间让出来。
- 是什么
- 用户打断时能够停下来的能力。
- 怎么运作
- 系统即使在说话时也在听；一听到人声，就停下来听。
- 例子
- agent 在列选项，用户说“第二个！”——agent 立刻切换。
- 陷阱
- 没有 barge-in，agent 会盖过别人的话，显得像聋子。
- 关联
- 与 Turn-taking 一起，构成 Conversation Flow。
Conversation Flow——流畅度就是产品
好的对话者和笨拙的对话者说的话相近——区别在于时机、倾听和让步。流畅度就是体验。
语音 agent 让人觉得自然还是机械，很大程度上取决于这套编排：感知轮次、面对打断时让步、不留冷场、不盖过用户。这些 conversation flow 的细节和回答的准确度一样重要，因为一个正确的回答若时机笨拙，依然像是坏的。设计语音产品，就是设计对话，而不只是设计答案。谁在什么时候说话的节奏，是体验的一等公民，而不是打磨阶段的收尾工作。
- 是什么
- 交谈的节奏：谁在什么时候说话、停顿、让步。
- 怎么运作
- 由 turn-taking、barge-in 和不冷场构成。
- 例子
- 两个 agent 的答案一模一样：一个像真人，另一个像答录机。
- 陷阱
- 正确的答案配上笨拙的时机，依然像是坏的。
- 关联
- 由 Turn-taking 和 Barge-in 构成；取决于 Latency Budget。
自然的语音需要 turn-taking——知道用户何时说完——和 barge-in——被打断时停下。谁在什么时候说话的节奏，和答案本身一样是产品的一部分。
经典的级联正迎来一种较新的做法：直接处理语音、端到端的模型，把各阶段合并以降低延迟。值得了解这个领域正往哪里走。
Speech-to-Speech——一个模型代替三个
不再是“一个译员记下来、一个思考者回答、一个朗读者念出来”的链条，而是一个人，同时听、想、答。一趟直飞，而不是两次转机。
一类较新的实时（realtime）模型，也叫 speech-to-speech 模型，直接处理音频。语音进，语音出，没有单独的转写 → 推理 → 合成这几步。一个模型取代链条上的三个——这就是端到端（end-to-end）的做法。最大的好处是延迟：阶段之间没有边界，也就没有在它们之间传递数据的延迟。第二个好处是转换中不丢东西：模型听到的是话是怎么说的，而不只是文字，保留了语气和情绪，也能用相称的表达来回应。
- 是什么
- 一个模型，语音进，直接用语音作答。
- 怎么运作
没有单独的 STT 和 TTS——所以没有阶段之间的交接，也没有交接带来的延迟。
- 例子
- 模型听出用户声音里的不耐烦，回答得更平和——文字级联看不到这一点。
- 陷阱
- 中间是个黑箱：可见性和可控性更低。
- 关联
- Voice Pipeline 的替代方案；通向 Latency Budget 最直接的路。
Pipeline vs End-to-End——一个真实的选择
你可以换乘一连串列车，每一段都由自己掌控；也可以坐一趟直达，更快，但对路线说了不算。不同的取舍，都成立。
经典的**流水线（pipeline）和端到端（end-to-end）**模型都是真实的选项，各有代价。流水线让你在每个阶段都有控制权和灵活性——换 STT、查看转写文本、用任何模型——代价是延迟和复杂度。端到端带来速度和自然度，但对中间环节的可见性和控制力较弱。知道两者都存在，你才能有意识地选择：透明灵活的流水线，还是快速流畅的端到端，取决于你的产品最需要什么。
- 是什么
- 语音产品的架构选择。
- Pipeline
- 换 STT/TTS、读转写文本、用任何模型。代价：延迟，以及更多活动部件。
- End-to-end
- 延迟最低，语气和情绪得以保留。代价：可见性和控制力更低。
- 何时用哪个
- 需要控制和可检查性——选 pipeline；需要速度和流畅——选 end-to-end。
- 关联
- 对比 Voice Pipeline 与 Speech-to-Speech。
实时模型直接语音进、语音出：阶段更少、延迟更低，语气也得以保留。流水线还是端到端，是一个真实的取舍：控制与灵活，或速度与自然。
用好语音，意味着把它用在合适的场合，并认清延迟比任何东西都更能决定它显得神奇还是显得坏掉。
Modality Fit——让语音用在该用的地方
开车时你更愿意口述路线，坐在桌前则更愿意敲一份长表单——合适的输入方式完全取决于场景。
语音在适合的地方威力十足：双手被占用、无障碍、自然的对话，以及说话比打字更快或更安全的场合。在文字更好的地方，它就不合适：精确输入、公共场合的隐私、仔细核对。关键是让**模态（modality）**匹配当下的场景，而不是因为酷炫就加上语音。该用文字的地方用语音是降级；说话本就是自然动作的地方用语音则是变革。依场景而选，而不是图新鲜。
- 是什么
- 针对具体场景，选择语音还是文字。
- 适合语音
- 双手被占用、开车、无障碍、自然的对话。
- 适合文字
- 精确输入、公共场合的隐私、仔细核对。
- 陷阱
- 在文字更好的地方“因为酷”而用语音，是降级。
- 关联
- 一切之前的第一个问题；没有它，Latency-First 就无从谈起。
Latency-First Design——从第一天起就为延迟做预算
一位厨师围绕最费时的那道菜来安排整顿饭——围绕起决定作用的约束来设计，而不是到最后才发现它。
既然延迟决定一切，就要从一开始就围绕它设计（latency-first）：每个阶段都做流式处理，速度要紧的地方用端到端模型，并为某个阶段变慢的情况准备预案。把延迟拖到后期才管的语音功能，不管答案多好，往往都显得迟钝、像坏了。把响应时间当作语音产品的核心设计约束——一旦错过，就毁掉其余的一切。
- 是什么
- 响应时间是一切都要围绕的主要约束。
- 怎么运作
- 定下预算 → 处处流式 → 关键处用端到端 → 为变慢的阶段做预案。
- 例子
- 在第一个原型里就计时整个往返，并否决会破坏它的决定。
- 陷阱
- 到最后才发现的延迟很难修。
- 关联
守护 Latency Budget；依靠 Stream & Overlap 和 Speech-to-Speech。
一切如何相连
整张地铁图一览无余：现在你能看到线路在哪里交汇。
级联造成 latency stacking，它冲击预算。流式处理与重叠，或 speech-to-speech，把它救回来。守住预算，再用 turn-taking 和 barge-in 搭起 conversation flow，对话就有了生气。而 modality fit 决定你到底需不需要语音。
- 语音是否真的适合这个场景——还是文字更能服务用户？
- 每个阶段都在流式处理吗——转写、思考、说话相互重叠，而不是严格按顺序？
- 总延迟是否有对话的感觉，还是有尴尬的空档？
- 它是否处理了 turn-taking——知道用户何时说完——以及 barge-in？
- 声音是否自然到足以承载体验？
- Pipeline 还是 end-to-end——我是否按自己对延迟和控制力的需求选了架构？
- 你把语音用在说话确实合适的场景，而不是图新鲜。
- 每个阶段都流式处理并重叠，回复几乎立刻开始。
- 总延迟有对话的感觉，没有尴尬的沉默。
- agent 处理了 turn-taking 和 barge-in，所以流程显得自然。
- 你有意识地选择了 pipeline 或 end-to-end，并围绕 latency budget 来设计。
速查表：全部 18 个概念
流水线
- Voice Pipelinecascade，级联
STT → 模型 → TTS：耳朵、大脑、嘴巴依次工作。
- LLM Core推理核心
中间还是同一个文字模型；只有两端是新的。
听
- Speech-to-TextSTT、ASR
耳朵：把语音变成文字。
- Error Propagation错误顺流而下
一个转写错误，成了模型的输入。
- Streaming STT边说边转写
句子结束时文字已经备好——作出反应前没有停顿。
说
- Text-to-SpeechTTS、合成
嘴巴：把回复文字变成声音。
- Voice Persona声音与表达
语气和语速是产品的一部分，不是细枝末节。
- Streaming TTS流式合成
回复还在写的时候就开始说。
延迟
- Latency Budget响应时间窗口
几分之一秒内回复——否则就像卡死了。
- Latency Stacking累积延迟
三个阶段的延迟叠加成一个。
- Stream & Overlap阶段并行
所有阶段同时流式处理——赶上时间的主要办法。
轮次
- Turn-taking轮次检测
分清换气的停顿和句子的结束。
- Barge-in打断处理
被打断——停下、倾听、回应。
- Conversation Flow交谈的节奏
谁在什么时候说话，和答案一样是产品的一部分。
实时
- Speech-to-Speech实时、end-to-end
一个模型：语音进，语音出。延迟更低，语气得以保留。
- Pipeline vs End-to-End架构选择
控制与灵活，对比速度与自然。
用好它
- Modality Fit语音何时适用
说话自然的地方用语音；要精确的地方用文字。
- Latency-First Design从第一天起管延迟
一切都围绕响应时间预算来搭建。
语音意味着听、想、说，而且要快到像一场对话。对流水线做流式处理并重叠，处理好 turn-taking 和打断，有意识地选择 pipeline 还是 end-to-end——并把延迟当作其他一切都要向它让步的约束。