速成课 · No. 35
语音改变了 AI 产品的一切。它不再是读和写，而必须听、理解、思考、再开口说——还要快到像一场对话，而不是对讲机。这里有一条由三段组成的流水线，外加真正棘手的部分：实时地把这一切做完。学会这些阶段，弄清为什么 latency 是核心挑战，以及是什么让一个语音 agent 听起来自然而不是机械。
只讲精髓 · 每个想法一个画面 · 延迟就是一切
语音 AI 不是单一的一样东西——它是三项工作协同运转组成的一条链。先看清这条流水线，本课其余的一切就都各归其位了。
耳朵、大脑、嘴巴
一个人在交谈：他听见你说的话，思考一番，再开口回答——三个截然不同的动作，感觉却像浑然一体的一件事。
语音 AI 依次做三件事：它听（把你的话变成文字），它想（一个模型基于那段文字推理并生成回复），它说（把回复重新变回音频）。耳朵、大脑、嘴巴。中间那一步就是你早已熟悉的语言模型；新东西是两侧的耳朵和嘴巴。理解语音 AI，要从把它看成这条三段式的链开始，而不是一个单一的魔法黑盒。
speech-to-text、模型、text-to-speech
一条有三个工位的流水线：一个负责转写，一个负责决策，一个负责发声——活儿从一个工位流向下一个。
这三段都有名字。Speech-to-text（STT）把用户说出的话转写成文字。模型接过那段文字并生成回应，正是你一路学来的那种文字进、文字出。Text-to-speech（TTS）把模型给出的文字回复转换成有声音频。声音进，转写，推理，合成，声音出。大多数语音 AI 就是这条经典流水线，而说清这三段的名字，就已经掌握了它运作方式的大半。
模型是老样子，变化在两端
你早就会用文字思考和回答——学会用语音交谈，只是在同一个内核外面加上听和说。
推理内核还是其他每门课里那个语言模型——上下文、提示、工具、结构化输出，这一切对中间的文字依然成立。新的是两端的音频：把声音变成文字，再把文字变成声音，又可靠又快。所以你不必重学大脑；你只是加上耳朵和嘴巴，再学那唯一让语音真正变难的事——在一场对话所要求的紧凑节奏里把这三件事都做完。
语音 AI 是一条流水线：speech-to-text（耳朵）、模型（大脑）和 text-to-speech（嘴巴）。推理内核是你熟悉的那个模型；新东西是两端的音频，以及它们之间的节奏。
第一段把声音变成词语。它现在已经相当出色，但它的不完美会左右下游的一切，所以值得弄清它能做什么、不能做什么。
transcription：声音变成文字
一位法庭速记员把说出口的每个词当场敲下来——把流动的话语变成系统其余部分能读取的书面记录。
Speech-to-text（也叫 transcription 或自动语音识别）把有声音频转换成书面文字。它是系统的耳朵：用户开口说，STT 产出模型将要据以推理的那些词。现代 STT 准得令人印象深刻，对自然、凌乱的口语的处理也远胜当年那种笨拙的语音识别。正是这一步让人可以直接说而不是打字——它是整个语音体验的入口。
口音、噪声和错误会流向下游
速记员一旦听错一个词，后面每个读者都继承了这个错误——错误在最开头就被定了下来。
STT 并不完美：口音、背景噪声、串话、专业术语和人名都可能导致转写出错。又因为它是第一段，它的错误会传播——模型只对它拿到的那段文字推理，所以一个听错的词可能悄悄让整条回应跑偏。一套语音系统的上限,就是它转写的上限。所以你要为不完美的输入做设计：模型应当从容应对略有错乱的文字，你也要盯紧那些耳朵最吃力的情形（噪声、口音）。
在用户说话时进行 streaming 转写
一位速记员在你说话的同时持续敲字，而不是等你把整段话讲完才开始——文字与词语同步浮现。
为了让人觉得反应灵敏，STT 可以是 streaming 的——在用户说话的过程中持续转写，而不是等他说完再去处理整段录音。这对速度很关键：streaming 让系统更早开始干活，并在用户一停下就立刻反应，而不是平添一段长长的停顿。在「说完再转写」和「边说边转写」之间的取舍，是语音系统里最早遇到的 latency 决策之一，而 streaming 通常正是让它感觉鲜活的那一招。
Speech-to-text 是耳朵：它把语音转写成文字供模型使用。它的错误会流向下游，所以要为不完美的输入做设计——并对转写做 streaming，让系统在用户说话的同时就反应。
最后一段把模型的文字回复重新变回声音。这是用户真正听到的部分，所以它的质量塑造了整个产品给人的感觉。
synthesis：文字变成声音
一位旁白朗读着脚本——把书面词语变成自然、有表现力的话语，听者体验到的是一个声音，而不是照本宣科。
Text-to-speech（TTS）把模型的文字回应转换成有声音频——系统的嘴巴。现代 TTS 能产出极其自然的嗓音，语调和节奏都很逼真，远超过去那种平板机械的发声。这是用户听到的东西，所以它承载了产品大量的个性与质感。一条出色的流水线配上机械的嗓音，依然显得廉价；而一个自然的嗓音让整场交互显得有人味——这也正是语音产品得以成立的很大一部分原因。
嗓音承载着体验
同样的话语，温暖地说和冷淡地说，落地的感觉天差地别——听者回应的是表达方式，而不只是内容。
在一个语音产品里，一句话怎么说，和说了什么同样重要。所选的嗓音、它的语气、它的节奏——这些都是塑造信任与舒适感的产品决策，就像视觉设计在屏幕产品里所起的作用一样。一个太快、太平、或腔调古怪的嗓音，会拖垮一个本来不错的回答。所以 TTS 不是最后随手拧上去的零件；嗓音是体验的核心组成部分，值得像对待其他任何界面元素一样,刻意地去挑选和调校。
边生成边把语音 stream 出去
一个人一边想到答案一边就开口说，而不是先默默把整段都酝酿好,再一口气讲出来。
正如 STT 可以 stream 进来，TTS 也可以把语音 stream 出去——在其余部分还在生成时,就开始把回复的开头念出来，而不是等到全部文字和全部音频都齐了才发出声响。这对反应灵敏至关重要：把语音 stream 出去意味着用户几乎立刻就听到回复开了头，而不是干坐在沉默里。再配上模型对文字的 streaming，这就是一个语音 agent 不带尴尬空档作答的方式——一旦有话可说，语音就开始了。
Text-to-speech 是嘴巴：它为模型的回复发声，而现代嗓音已自然到足以承载整场体验。边生成边把语音 stream 出去，让回复立刻开始，而不是在一段沉默之后。
这里就是让语音真正变难的地方。一场对话有它的节奏，而整条三段式流水线必须在这节奏之内跑完——否则魔法就破了。
一场对话有一笔很紧的时间预算
真实交谈里，慢半拍的回答让人觉得别扭；隔了好几秒才来的回答让人觉得坏掉了。「自然」的窗口很小。
人们期待一句对话式的回答在不到一秒内到来。在聊天应用里察觉不到的延迟，到了语音里却格外刺眼——你说完后那一两秒的沉默,感觉就像系统卡死了。这笔很紧的 latency 预算是语音 AI 的决定性约束：整个往返——听、转写、想、合成、说——必须装进一场人类对话所允许的那个小窗口里。错过它，哪怕答案完美无缺，也会显得坏掉了。
三段的延迟会累加
一场接力赛，总时间是每位选手那一棒之和——任何一处交接慢了，整支队伍就晚了。
残酷之处在于，latency 会在流水线上累加：转写花的时间，加上模型思考的时间，加上合成语音的时间，全都叠进用户感受到的总延迟里。每一段单独「够快」并不够，只要它们之和撑爆了预算就不行。这就是为什么语音比文字难：文字聊天只等模型一个,而语音要串行地等三段，而且对话的节奏窗口要紧得多。
把每一段都 streaming，是你守住预算的办法
一位口译员一边听你说一边翻，并在你话还没说完时就开始说出回复——让各段相互重叠，而不是严格地一个接一个。
关键的手法是对各段做 streaming 并让它们重叠，而不是严格地按顺序跑完：在用户说话时就转写，让模型在问题还没被完整处理时就开始生成，在回复还没写完时就开始把它说出来。让三段相互重叠，而不是等每一段彻底结束，正是语音系统把总延迟压缩成对话级别的办法。低延迟语音的全部功夫，就在于让流水线持续流动，而不是在每一段停下又起步。
一场对话有一笔很紧的 latency 预算，而三段的延迟会累加。对它们做 streaming 并让它们重叠——并行地转写、想、说，而不是按顺序——好把回应装进对话的窗口里。
除了速度之外，自然的对话还有一套谁在何时开口的编排。把这套流动做对，正是把一个有真实感的语音 agent 和一个笨拙的语音 agent 区分开来的地方。
知道用户什么时候说完了
一个好的倾听者能分辨喘口气的停顿和一句话的结束——他不会每当你顿一下就插进来。
语音系统必须察觉用户究竟是真的说完了，还是只是想到一半停了一下——也就是判断什么时候轮到系统的问题。插得太早，你就把用户打断了；等得太久，对话就拖沓了。这种 turn-taking 的判断出乎意料地难，又是自然感的核心：人类靠微妙的线索毫不费力地做到这件事，而一个语音 agent 必须把它逼近到足够好，让一来一回流畅起来,而不是磕磕绊绊。
处理打断：barge-in
当你开始盖过别人说话，对方会停下来听——而不是当你什么都没说一样,径直把自己的句子讲完。
真实对话包含打断。如果用户在 AI 说话时开口——barge-in——一个自然的系统会停下、倾听、回应这条新输入，而不是把它照本宣科的回复盖在用户头上讲完。支持打断是好语音 agent 的标志，也是差语音 agent 明显缺的东西——后者会浑然不觉地盖着你说。处理 barge-in 意味着系统即便在说话时也始终在听，随时准备在用户接过话头的那一刻让出发言权。
流动本身就是产品的一部分
一个好的谈话对象和一个尴尬的谈话对象,说的话可能差不多——区别在于时机、倾听和退让。流动就是体验。
一个语音 agent 究竟显得自然还是机械，很大程度上取决于这套编排——感知轮次、处理打断、不留死寂也不盖着用户说。这些流动的细节和答案的准确度同等重要，因为一句正确的回应若以笨拙的时机递出，依然显得坏掉了。所以设计一个语音产品意味着设计这场对话，而不只是答案：谁在何时开口的节奏是体验里头等重要的一部分，而不是收尾时的打磨。
自然的语音需要 turn-taking——知道用户什么时候说完了——以及 barge-in——被打断时停下来。谁在何时开口的流动，和答案本身一样,都是产品。
经典的三段式流水线正迎来一种更新的做法：直接、端到端地处理语音的模型，把各段压缩到一起以削减延迟。值得了解这个领域正往哪里去。
直接接收并产出语音的模型
不再是一个翻译写下你的话、把纸条递给一个思考者、再把答案交给一个发声者——而是一个人同时听、想、答。
一类更新的 realtime（或 speech-to-speech）模型直接处理音频：它们接收语音、产出语音，没有单独的「先转写、再推理、再合成」步骤。不是一条链上的三个模型,而是一个模型干完整件活。通过把流水线压缩到一起，这种做法能大幅削减叠加三段所造成的 latency，还能保住那些在语音被压平成纯文字再变回来时丢失的语气和情绪。
阶段更少，延迟更低
一趟直飞,而不是转两次机——交接更少，总时间少得多，转运中也没有任何东西丢失。
End-to-end 实时模型最大的好处是 latency：去掉各段之间的边界，就去掉了在它们之间传递数据的延迟，更接近人类对话那种即时的一来一回。它还避免了每次转换都丢失信息——模型能听见一句话是怎么说的，而不只是哪些词，并以相称的表现力来回应。对于要求最高、最讲求自然感的语音交互，这条压缩到一起的流水线正越来越成为首选做法。
流水线还是端到端：一个真实的选择
你可以乘坐一连串你能掌控每一段的列车,也可以乘一趟更快但让你对路线更少话语权的直达车——不同的取舍，两者都成立。
经典的流水线和 end-to-end 模型都是带有取舍的真实选项。流水线让你在每一段都有掌控和灵活——换掉 STT、检查转写稿、用任意模型——代价是 latency 和复杂度。End-to-end 模型给你速度和自然感，但对中间的可见性和掌控更少。知道两者都存在，你才能刻意地去选：是透明、灵活的流水线，还是快速、流畅的 end-to-end 做法，取决于你的产品最看重什么。
Realtime end-to-end 模型直接接收并产出语音，把流水线压缩到一起以猛砍 latency 并保住语气。流水线对 end-to-end 是一个真实的取舍：掌控与灵活，还是速度与自然感。
用好语音意味着在对的情形里选用它，并尊重一个事实：latency 比什么都更能决定它感觉是神奇还是坏掉。
只在语音真正合适时才用它
开车时你宁愿用嘴说出方向，坐在桌前时你宁愿敲完一张长表单——对的输入方式完全取决于情形。
语音在合适的地方很强大——解放双手、无障碍、自然对话，以及说比打字更快或更安全的情形——而在文字更好的地方就不合适，比如任何需要精确输入、在公共场合保护隐私、或需要仔细审阅的情况。本事在于把方式匹配到当下的场合，而不是因为语音很唬人就加上它。在文字本该更好用的地方用语音界面是一种倒退；在说话才是自然之举的地方用它，则是脱胎换骨。为情形而选它，而不是为新奇。
从一开始就为延迟留预算
一位主厨围绕最费时的那道菜来规划整桌饭——围绕那个起约束作用的环节来设计，而不是到最后才发现它。
因为 latency 是成败攸关的约束，从一开始就为它做设计：在每一段都选用 streaming，在速度至关重要处考虑 end-to-end 模型，并为某一段变慢时备好预案。那些拖到很晚才理会 latency 的语音功能,往往无论答案多好都显得迟钝、坏掉。把响应时间预算当作语音产品的核心设计约束——那个一旦错过就毁掉其余一切的数字——并围绕命中它来构建一切。
- 语音是否真正适合这个情形——还是文字会更好地服务用户？ - 每一段是否都在 streaming ——转写、想、说相互重叠，而不是严格按顺序？ - 总的延迟是否让人觉得像对话，还是有一个 尴尬的空档？ - 它是否处理 turn-taking——知道用户什么时候说完了——以及 barge-in？ - 嗓音是否自然到足以承载体验？ - 流水线还是 end-to-end——我有没有为我的延迟和掌控 需要选好架构？
- speech-to-text（STT）/ transcription——耳朵：把语音变成文字。 - text-to-speech （TTS）/ synthesis——嘴巴：把回复变成声音。 - 语音流水线——STT、模型、TTS 按顺序排列。 - streaming——持续地处理每一段，而不是等它结束。 - latency 预算——一场对话所允许的 那个很紧的响应时间窗口。 - turn-taking / barge-in——知道用户什么时候说完了，以及被 打断时停下来。 - realtime / end-to-end（speech-to-speech）模型——直接处理语音，把流水线 压缩到一起。
- 你在说话真正合适的情形里选用语音，而不是为了新奇。 - 每一段都stream 并重叠， 让回复几乎瞬间就开始。 - 总的延迟让人觉得像对话，没有尴尬的沉默。 - agent 处理 turn-taking 与 barge-in，让流动显得自然。 - 你刻意地选了流水线还是 end-to-end， 围绕 latency 预算来设计。
语音意味着听、想、说，而且要快到像一场对话。对流水线做 streaming 并让它重叠，处理 turn-taking 与打断，刻意地选流水线还是 end-to-end——并把 latency 当作其余一切都为之让步的那个约束。