# 和 AI 对话，而不是打字

关于语音与实时 AI 的速成课。18 个概念——Voice Pipeline、Speech-to-Text、Text-to-Speech、Latency Budget、Streaming、Turn-taking、Barge-in、Speech-to-Speech 等——每个都有英文名称、一幅图和一张卡片：是什么 → 怎么运作 → 例子 → 陷阱。核心一句话：语音意味着听、想、说，而且要快到像一场对话。结尾附一页速查表。

- **Author:** Fedor Chishchin
- **Level:** intermediate
- **Reading time:** ~30 分钟阅读
- **Published:** 2026-06-13
- **Source:** https://fedorthinks.com/zh/learn/voice-ai-express

---

## 1. 语音流水线

语音 AI 不是单一的一样东西——它是三项工作串成的一条链。先看清这条流水线，本课其余的一切就都各归其位了。

### 地图：七组共 18 个概念

> 一张地铁图：先看整条线路，再一站一站地乘过去。

本课的概念分成七组。先是流水线本身。然后是它的两端：**耳朵**（语音转文字）和**嘴巴**（文字转语音）。接着是核心难题——**延迟**。再是对话的编排——**谁在什么时候说话**。然后是较新的路线——**实时模型**。最后是如何明智地使用语音。

_Diagram: 七组概念——各章依次讲解。_

### 如何阅读每个概念

> 一本护照：每个人的栏目都一样，所以很容易比较。

下面每个概念都有同样的几部分：它的**英文名称**（记住它——你在文档里就靠它去查）、一幅日常的画面、一幅**图**，以及一张**卡片**，卡片里有这些栏目：_是什么_、_怎么运作_、_例子_、_陷阱_，以及*关联*的概念。整门课贯穿着一个想法：**延迟就是一切**。

### Voice Pipeline——耳朵、大脑、嘴巴

> 一个人在交谈：他听见你说的话，思考一番，再开口回答。三个截然不同的动作，感觉却像一件事。

语音 AI 依次做三件事。它**听**——把语音变成文字。它**想**——模型读这段文字并写出回复。它**说**——把回复再变回音频。这几个阶段都有名字：**Speech-to-Text（STT）**、模型（**LLM**）和 **Text-to-Speech（TTS）**。这条链也叫 **cascade**（级联）。大多数语音 AI 正是这样搭起来的。

_Diagram: 经典的级联：语音 → STT → LLM → TTS → 语音回到用户耳中。_

#### Voice Pipeline (cascade，级联)

- **是什么:** 三个阶段组成的一条链：语音转文字、模型、文字转语音。
- **怎么运作:** 语音进 → 转写 → 推理 → 合成 → 语音出。
- **例子:** 用户说“两个人的位子”，STT 把它记下来，模型作出回复，TTS 把回复读出来。
- **陷阱:** 三个阶段首尾相接——三处延迟的来源。
- **关联:** 由 **Speech-to-Text**、**LLM Core** 和 **Text-to-Speech** 组成；替代方案是 **Speech-to-Speech**。

### LLM Core——还是那个模型，只是边缘是新的

> 你早就会用文字思考和回答了。学会用语音交谈，只是在同一个核心的周围加上听和说。

推理的核心，就是其他所有课程里的那个**语言模型（LLM）**。上下文、提示、工具、结构化输出——这一切对中间的文字依然适用。新东西只是两端的音频：把声音变成文字，再把文字变成声音，要可靠，还要快。你不用重学大脑。你只是加上耳朵和嘴巴——并学会让语音变难的那件事：在对话所要求的紧凑节奏内把这一切做完。

_Diagram: 中间是熟悉的文字进、文字出的模型；只有耳朵和嘴巴是新的。_

#### LLM Core (推理核心)

- **是什么:** 语音流水线中间的一个普通文字模型。
- **怎么运作:** 接收 STT 的文字，为 TTS 写出文字回复。
- **例子:** 同样的提示、同样的工具、同样的输出结构，和文字聊天机器人一模一样。
- **陷阱:** 模型只看得到文字——它不知道某句话_是怎么_说出来的。
- **关联:** **Voice Pipeline** 的中间一段；**Speech-to-Speech** 把它去掉了。

> **框定问题:** “我是否把自己的语音功能看成三个阶段——听、想、说——从而知道每个问题属于哪个阶段？”

> 语音 AI 就是一条流水线：耳朵（STT）、大脑（模型）和嘴巴（TTS）。大脑你已经熟悉；新的是两端的音频，以及各阶段之间的时间。

## 2. 语音转文字

第一个阶段把声音变成文字。它如今已经相当出色，但它的错误会影响后面的一切，所以值得弄清它能做什么、不能做什么。

### Speech-to-Text——声音变成文字

> 法庭上的速记员，每说一个字就敲下一个字——把语音的洪流变成系统其余部分能读的记录。

**Speech-to-Text（STT）**——也叫**转写**或 **ASR（自动语音识别）**——把说出的音频转换成书面文字。它是系统的耳朵：用户说话，STT 产出模型将要据以推理的文字。现代 STT 准确得令人印象深刻，处理自然、杂乱的口语，比过去笨拙的语音识别强得多。正是这一步，让人可以直接说话而不必打字。

_Diagram: STT（ASR）：进去的是声波，出来的是给模型的文字。_

#### Speech-to-Text (STT、ASR、转写)

- **是什么:** 系统的耳朵：把语音变成文字。
- **怎么运作:** 听音频，输出模型要读的文字。
- **例子:** 用户说话——出来的是字符串“两个人的位子”。
- **陷阱:** 并不完美：口音、噪音、人名和行话都会造成错误。
- **关联:** **Voice Pipeline** 的第一个阶段；它的错误就是 **Error Propagation**。

### Error Propagation——耳朵的错误会顺流而下

> 速记员要是听错了一个字，之后的每个读者都会继承这个错误。它从一开始就被固定下来了。

STT 并不完美：**口音、背景噪音、串音、专业术语和人名**都可能导致转写错误。而且由于 STT 是第一个阶段，**它的错误会一路传播**——模型只会对拿到的文字进行推理。一个听错的字，就能悄悄带偏整个回复。语音系统的好坏，取决于它的转写。所以要为不完美的输入做设计：模型应当从容应对略有错乱的文字，而你要留意耳朵最吃力的那些场合。

_Diagram: 第一个阶段的错误会传遍整条链——模型信心十足地回答了错的东西。_

#### Error Propagation (错误顺流而下)

- **是什么:** 一个转写错误，成了后面每个阶段的输入。
- **怎么运作:** 模型听不到音频——它只信任拿到的文字。
- **例子:** STT 听错了一个人名——模型信心十足地去查了另一个人。
- **怎么办:** 为不完美的输入做设计；留意真实用户的噪音和口音。
- **关联:** **Speech-to-Text** 的弱点；**LLM Core** 看不到它。

### Streaming STT——用户说话时就开始转写

> 一位在你说话时不停敲字的速记员，而不是等整场讲话结束才动笔的那位——文字和话语同步出现。

STT 可以是**流式的（streaming）**——在用户说话的同时持续转写，而不是等他们说完再处理整段录音。这关系到速度：系统更早开始工作，用户一停下就能作出反应，而不是平白多出一段长长的停顿。是等到最后再转写，还是边说边转写，是语音系统最先要做的延迟决策之一，而流式通常正是让它显得“活”的原因。

_Diagram: 批处理要等到句子结束，多出一段停顿；流式边说边转写，立刻作出反应。_

#### Streaming STT (流式转写)

- **是什么:** 用户还在说话时就持续转写。
- **怎么运作:** 文字在说话期间不断累积——句子结束时已经差不多备好了。
- **例子:** 用户一说完，系统立刻回复，而不是先停顿一下去转写。
- **陷阱:** 没有它，每个回复前面都会有一段明显的停顿。
- **关联:** **Streaming TTS** 的孪生兄弟；属于 **Stream & Overlap** 的一部分。

> **聆听问题:** “我的转写在真实用户身上有多准——他们的口音、他们的噪音——我是否用了流式转写，让系统在他们一停下就作出反应？”

> STT 是耳朵：它把语音变成文字交给模型。它的错误会顺流而下，所以要为不完美的输入做设计——并且在用户说话时就开始转写。

## 3. 文字转语音

最后一个阶段把模型的文字回复变回声音。这是用户真正听到的部分，所以它的质量决定了整个产品给人的感觉。

### Text-to-Speech——文字变成声音

> 一位朗读剧本的播音员——把书面文字变成自然、有表现力的语音，而不是背书。

**Text-to-Speech（TTS）**，也叫**语音合成**，把模型的文字回复转换成音频。它是系统的嘴巴。现代 TTS 能产出相当自然的声音，语调和节奏都很真实，远非过去那种平板的机器人腔可比。一条出色的流水线配上机器人嗓音，依然显得廉价。自然的声音让整个交互有了人味——这也是语音产品终于可行的重要原因。

_Diagram: TTS：进去的是回复文字，出来的是自然的声音——语调、节奏、语速。_

#### Text-to-Speech (TTS、语音合成)

- **是什么:** 系统的嘴巴：把回复文字变成声音。
- **怎么运作:** 接过模型的文字，合成带有语调和节奏的语音。
- **例子:** 字符串“已订好位子”变成一句温暖自然的话。
- **陷阱:** 机器人嗓音会让再出色的流水线也显得廉价。
- **关联:** **Voice Pipeline** 的最后一个阶段；**Voice Persona** 定下它的语气，**Streaming TTS** 决定它的速度。

### Voice Persona——声音承载着体验

> 同样的话，说得温暖或说得冷淡，听上去截然不同。听者回应的是说话的方式，而不只是内容。

在语音产品里，话*怎么说*和*说什么*同样重要。选哪种声音、什么语气、什么节奏——这些都是产品决策，会左右信任感和舒适度，就像视觉设计之于屏幕产品。声音太快、太平、语调古怪，都会糟蹋一个本来不错的回答。所以 TTS 不是最后随手加上去的附件。声音（**voice persona**）要像其他界面元素一样，有意识地挑选和调校。

_Diagram: 同样的话：温暖的表达建立信任，又平又快的表达会糟蹋一个好回答。_

#### Voice Persona (产品的声音与表达)

- **是什么:** 选定的声音、语气和语速——语音产品的“脸”。
- **怎么运作:** 表达方式改变同一个回答被接收的方式。
- **例子:** 用平静温暖的声音说“您的订单延迟了”——对比同样的话，又快又平。
- **陷阱:** 没调校过的默认声音，会削弱人们对好回答的信任。
- **关联:** **Text-to-Speech** 的一项设置；属于 **Conversation Flow** 的一部分。

### Streaming TTS——边写边说

> 有人想到答案就开口说，而不是先默默把整段话组织好，再一口气讲出来。

正如 STT 可以流式地“进”，TTS 也可以流式地“出”——回复的后半部分还在生成时，就先把开头说出来。不必等完整的文字和完整的音频都备好才发出声音。用户几乎立刻就听到回复开始，而不是坐在沉默里等。再加上模型本身也是流式输出文字，语音 agent 才能没有尴尬的空档地作答：一有话可说，语音就开始了。

_Diagram: 批处理在整段回复备好之前一声不吭；流式在模型还在写的时候就开始说话。_

#### Streaming TTS (流式合成)

- **是什么:** 回复的后半部分还在生成时，就先把开头念出来。
- **怎么运作:** 模型一块一块地输出文字；TTS 立刻把每一块变成音频。
- **例子:** 回复的头几个字几乎立刻响起，而不是沉默之后。
- **陷阱:** 没有流式，整段回复生成期间，用户都得坐在沉默里。
- **关联:** **Streaming STT** 的孪生兄弟；属于 **Stream & Overlap** 的一部分。

> **说话问题:** “我的声音是否自然到足以承载整个体验——回复是否几乎立刻开始，而不是沉默之后才开始？”

> TTS 是嘴巴：它把模型的回复念出来，而现代的声音自然到足以承载整个体验。把语音做成流式，让回复立刻开始，而不是沉默之后。

## 4. 延迟的挑战

这正是语音真正困难的地方。对话有它的节奏，整条三段式流水线必须塞进这个节奏里——否则魔法就破了。

### Latency Budget——对话的时间窗口很窄

> 真实的交谈里，慢半拍的回应显得别扭；过了好几秒才回应，就像坏掉了。“自然”的窗口很小。

人们期待在**几分之一秒**内得到对话式的回应。在聊天应用里根本察觉不到的延迟，在语音里就格外刺眼——你说完之后沉默了几秒，就像系统卡死了。这个狭窄的窗口——**latency budget（延迟预算）**——是语音 AI 的决定性约束。整个往返——听、转写、思考、合成、说出——都必须塞进去。错过了，哪怕回答再完美，也像是坏的。

_Diagram: 几分之一秒感觉自然，慢半拍显得别扭，好几秒像是卡死。整个往返必须塞进第一个窗口。_

#### Latency Budget (响应时间窗口)

- **是什么:** 一场实时对话所能容忍的响应时间窗口——几分之一秒。
- **怎么运作:** 从“听”到“说”的一切，都必须塞进这个窗口里。
- **例子:** 在聊天里没人察觉的两秒停顿，在语音里听起来就是“系统卡死了”。
- **陷阱:** 错过它，哪怕答案正确，也像是坏的。
- **关联:** 被 **Latency Stacking** 吃掉；靠 **Stream & Overlap** 和 **Speech-to-Speech** 挽救。

### Latency Stacking——延迟会叠加

> 一场接力赛，总用时是每一棒加起来的和——任何一处交接慢了，整个队伍都会晚。

残酷的是，延迟会沿着流水线**累积**。转写的时间 + 模型思考的时间 + 合成的时间——全都叠成用户感受到的那段停顿。每个阶段单独看“够快”并不够，要是它们的总和超出了预算。这就是语音比文字难的原因：文字聊天只等模型，而语音要依次等三个阶段——而且对话的窗口窄得多。

_Diagram: 聊天只等一个阶段；语音要依次等三个，它们的总和超出了预算。_

#### Latency Stacking (累积延迟)

- **是什么:** 三个阶段的延迟加起来，变成一段总的停顿。
- **怎么运作:** 严格按顺序运行时，总延迟 = STT + 模型 + TTS。
- **例子:** 每个阶段都“很快”，合在一起却在每句话之后留下一段尴尬的沉默。
- **陷阱:** 只优化一个阶段不够——用户感受到的是总和。
- **关联:** 打破 **Latency Budget**；靠 **Stream & Overlap** 或 **Speech-to-Speech** 修复。

### Stream & Overlap——让各阶段并行运行

> 一位同声传译，你一边说他一边翻，话说到一半就开始说出回应——让各阶段重叠，而不是严格地一个接一个。

关键技术是对各阶段做**流式处理并让它们重叠**，而不是严格按顺序运行。用户说话时就转写。不等问题处理完，就让模型开始生成。回复还没写完，就开始说。让三个阶段重叠，而不是等每个都做完，是语音系统把总延迟压缩到对话水平的办法。低延迟语音的全部技艺，就是让流水线持续流动，不在每个阶段停下又重新启动。

_Diagram: 同样的工作：一个接一个就晚了，重叠起来回复开始得早得多。_

#### Stream & Overlap (流式处理、阶段重叠)

- **是什么:** 三个阶段全部流式处理，同时运行，而不是轮流。
- **怎么运作:** STT 边说边转写，模型提早开工，TTS 在模型写的同时就开口。
- **例子:** 语音 agent 的回复没有空档，尽管它内部仍然是同样的三个阶段。
- **陷阱:** 流式系统比“做完一个阶段、交给下一个”难搭得多。
- **关联:** 结合了 **Streaming STT** 和 **Streaming TTS**；满足 **Latency Budget** 的主要办法。

> **延迟问题:** “我的整条流水线——转写、思考、说话——是否装得进对话的窗口，各阶段是否在流式处理并重叠？”

> 对话的延迟预算很紧，而三个阶段的延迟会叠加。对它们做流式处理并重叠——转写、思考、说话并行，而不是按顺序。

## 5. 轮流发言与打断

除了速度，自然的对话还有一套谁在什么时候说话的编排。这正是让语音 agent 显得真实还是笨拙的分水岭。

### Turn-taking——知道用户何时说完

> 好的倾听者分得清换气的停顿和一句话的结束——不会你每停一下就插嘴。

语音系统必须判断用户是**真的说完了**，还是只是话说到一半停了一下。这就是 **turn-taking**：知道什么时候轮到系统。插得太早，会打断用户；等得太久，对话就拖沓。这个判断出奇地难，也是显得自然的关键。人类靠细微的线索毫不费力地做到；语音 agent 得把它近似得足够好，这样一来一往才会流畅，而不是磕磕绊绊。

_Diagram: 换气的停顿——继续听；句子的结尾——轮到我们。无论判错哪边，对话都会被破坏。_

#### Turn-taking (轮次检测)

- **是什么:** 这个判断：这次停顿是换气，还是这一轮结束了？
- **怎么运作:** 系统听着这些停顿，决定什么时候轮到自己。
- **例子:** “我想订……[停顿]……周五的”——第一次停顿之后，现在回复还太早。
- **陷阱:** 太早会打断用户；太晚会让对话拖沓。
- **关联:** 与 **Barge-in** 一起，构成 **Conversation Flow**。

### Barge-in——被打断时让出话头

> 当你开口盖过别人的话，对方会停下来听你说——而不是继续硬着头皮说完自己的句子，好像你什么都没说。

真实的对话包含打断。如果用户在 AI 说话时开口——这就是 **barge-in**——自然的系统会停下、倾听，并回应新的输入，而不是在他们的话头上把预先写好的回复说完。支持打断是好语音 agent 的标志；差的则浑然不觉地盖过你的话。处理 barge-in，意味着系统**始终在听，即使它自己正在说话**，随时准备在用户接过话头的瞬间让出来。

_Diagram: 用户插话——agent 停下、倾听并回应，而不是盖过他们。_

#### Barge-in (打断处理)

- **是什么:** 用户打断时能够停下来的能力。
- **怎么运作:** 系统即使在说话时也在听；一听到人声，就停下来听。
- **例子:** agent 在列选项，用户说“第二个！”——agent 立刻切换。
- **陷阱:** 没有 barge-in，agent 会盖过别人的话，显得像聋子。
- **关联:** 与 **Turn-taking** 一起，构成 **Conversation Flow**。

### Conversation Flow——流畅度就是产品

> 好的对话者和笨拙的对话者说的话相近——区别在于时机、倾听和让步。流畅度就是体验。

语音 agent 让人觉得自然还是机械，很大程度上取决于这套编排：感知轮次、面对打断时让步、不留**冷场**、不盖过用户。这些 **conversation flow** 的细节和回答的准确度一样重要，因为一个正确的回答若时机笨拙，依然像是坏的。设计语音产品，就是设计*对话*，而不只是设计答案。谁在什么时候说话的节奏，是体验的一等公民，而不是打磨阶段的收尾工作。

_Diagram: 同样的话：流畅的轮次，对比冷场和盖过用户的话。_

#### Conversation Flow (对话的节奏)

- **是什么:** 交谈的节奏：谁在什么时候说话、停顿、让步。
- **怎么运作:** 由 turn-taking、barge-in 和不冷场构成。
- **例子:** 两个 agent 的答案一模一样：一个像真人，另一个像答录机。
- **陷阱:** 正确的答案配上笨拙的时机，依然像是坏的。
- **关联:** 由 **Turn-taking** 和 **Barge-in** 构成；取决于 **Latency Budget**。

> **流畅度问题:** “我的语音 agent 是否知道用户何时说完、被打断时是否会停下，并保持自然的节奏——还是会打断别人、盖过别人的话？”

> 自然的语音需要 turn-taking——知道用户何时说完——和 barge-in——被打断时停下。谁在什么时候说话的节奏，和答案本身一样是产品的一部分。

## 6. 实时模型

经典的级联正迎来一种较新的做法：直接处理语音、端到端的模型，把各阶段合并以降低延迟。值得了解这个领域正往哪里走。

### Speech-to-Speech——一个模型代替三个

> 不再是“一个译员记下来、一个思考者回答、一个朗读者念出来”的链条，而是一个人，同时听、想、答。一趟直飞，而不是两次转机。

一类较新的**实时（realtime）**模型，也叫 **speech-to-speech** 模型，直接处理音频。语音进，语音出，没有单独的转写 → 推理 → 合成这几步。一个模型取代链条上的三个——这就是**端到端（end-to-end）**的做法。最大的好处是**延迟**：阶段之间没有边界，也就没有在它们之间传递数据的延迟。第二个好处是转换中不丢东西：模型听到的是话*是怎么*说的，而不只是文字，保留了语气和情绪，也能用相称的表达来回应。

_Diagram: 级联在文字交接处丢掉了语气；speech-to-speech 是一个模型，语音进、语音出。_

#### Speech-to-Speech (实时模型、end-to-end)

- **是什么:** 一个模型，语音进，直接用语音作答。
- **怎么运作:** 没有单独的 STT 和 TTS——所以没有阶段之间的交接，也没有交接带来的延迟。
- **例子:** 模型听出用户声音里的不耐烦，回答得更平和——文字级联看不到这一点。
- **陷阱:** 中间是个黑箱：可见性和可控性更低。
- **关联:** **Voice Pipeline** 的替代方案；通向 **Latency Budget** 最直接的路。

### Pipeline vs End-to-End——一个真实的选择

> 你可以换乘一连串列车，每一段都由自己掌控；也可以坐一趟直达，更快，但对路线说了不算。不同的取舍，都成立。

经典的**流水线（pipeline）**和**端到端（end-to-end）**模型都是真实的选项，各有代价。流水线让你在每个阶段都有控制权和灵活性——换 STT、查看转写文本、用任何模型——代价是延迟和复杂度。端到端带来速度和自然度，但对中间环节的可见性和控制力较弱。知道两者都存在，你才能有意识地选择：透明灵活的流水线，还是快速流畅的端到端，取决于你的产品最需要什么。

_Diagram: 流水线：可控、灵活，但有延迟。端到端：快速、自然，但控制力较弱。_

#### Pipeline vs End-to-End (级联还是实时)

- **是什么:** 语音产品的架构选择。
- **Pipeline:** 换 STT/TTS、读转写文本、用任何模型。代价：延迟，以及更多活动部件。
- **End-to-end:** 延迟最低，语气和情绪得以保留。代价：可见性和控制力更低。
- **何时用哪个:** 需要控制和可检查性——选 pipeline；需要速度和流畅——选 end-to-end。
- **关联:** 对比 **Voice Pipeline** 与 **Speech-to-Speech**。

> **架构问题:** “我的产品需要三段式流水线的控制力和灵活性，还是端到端实时模型更低的延迟和自然度？”

> 实时模型直接语音进、语音出：阶段更少、延迟更低，语气也得以保留。流水线还是端到端，是一个真实的取舍：控制与灵活，或速度与自然。

## 7. 用好它

用好语音，意味着把它用在合适的场合，并认清延迟比任何东西都更能决定它显得神奇还是显得坏掉。

### Modality Fit——让语音用在该用的地方

> 开车时你更愿意口述路线，坐在桌前则更愿意敲一份长表单——合适的输入方式完全取决于场景。

语音在适合的地方威力十足：**双手被占用**、**无障碍**、自然的对话，以及说话比打字更快或更安全的场合。在文字更好的地方，它就不合适：**精确输入**、**公共场合的隐私**、**仔细核对**。关键是让**模态（modality）**匹配当下的场景，而不是因为酷炫就加上语音。该用文字的地方用语音是降级；说话本就是自然动作的地方用语音则是变革。依场景而选，而不是图新鲜。

_Diagram: 双手被占用、对话有帮助时用语音；需要精确、隐私和核对时用文字。_

#### Modality Fit (语音何时适用)

- **是什么:** 针对具体场景，选择语音还是文字。
- **适合语音:** 双手被占用、开车、无障碍、自然的对话。
- **适合文字:** 精确输入、公共场合的隐私、仔细核对。
- **陷阱:** 在文字更好的地方“因为酷”而用语音，是降级。
- **关联:** 一切之前的第一个问题；没有它，**Latency-First** 就无从谈起。

### Latency-First Design——从第一天起就为延迟做预算

> 一位厨师围绕最费时的那道菜来安排整顿饭——围绕起决定作用的约束来设计，而不是到最后才发现它。

既然延迟决定一切，就要**从一开始就围绕它设计（latency-first）**：每个阶段都做流式处理，速度要紧的地方用端到端模型，并为某个阶段变慢的情况准备预案。把延迟拖到后期才管的语音功能，不管答案多好，往往都显得迟钝、像坏了。把响应时间当作语音产品的核心设计约束——一旦错过，就毁掉其余的一切。

_Diagram: 先定预算，再做流式处理，关键处用端到端，并为变慢的阶段留好预案。_

#### Latency-First Design (围绕延迟来设计)

- **是什么:** 响应时间是一切都要围绕的主要约束。
- **怎么运作:** 定下预算 → 处处流式 → 关键处用端到端 → 为变慢的阶段做预案。
- **例子:** 在第一个原型里就计时整个往返，并否决会破坏它的决定。
- **陷阱:** 到最后才发现的延迟很难修。
- **关联:** 守护 **Latency Budget**；依靠 **Stream & Overlap** 和 **Speech-to-Speech**。

### 一切如何相连

> 整张地铁图一览无余：现在你能看到线路在哪里交汇。

级联造成 **latency stacking**，它冲击**预算**。**流式处理与重叠**，或 **speech-to-speech**，把它救回来。守住预算，再用 turn-taking 和 barge-in 搭起 **conversation flow**，对话就有了生气。而 **modality fit** 决定你到底需不需要语音。

_Diagram: 延迟居中：级联把它堆高，流式和 speech-to-speech 把它削低；再加上 conversation flow，就显得自然了。_

#### 发布语音功能之前

- **语音是否真的适合**这个场景——还是文字更能服务用户？
- **每个阶段都在流式处理吗**——转写、思考、说话相互重叠，而不是严格按顺序？
- **总延迟**是否有对话的感觉，还是有尴尬的空档？
- **它是否处理了 turn-taking**——知道用户何时说完——以及 **barge-in**？
- **声音是否自然**到足以承载体验？
- **Pipeline 还是 end-to-end**——我是否按自己对延迟和控制力的需求选了架构？

#### 你把语音做好了的迹象

- 你把语音用在**说话确实合适**的场景，而不是图新鲜。
- 每个阶段都**流式处理并重叠**，回复几乎立刻开始。
- 总**延迟有对话的感觉**，没有尴尬的沉默。
- agent 处理了 **turn-taking 和 barge-in**，所以流程显得自然。
- 你**有意识地选择了 pipeline 或 end-to-end**，并围绕 **latency budget** 来设计。

## 速查表：全部 18 个概念

### 流水线

- **Voice Pipeline** (cascade，级联): STT → 模型 → TTS：耳朵、大脑、嘴巴依次工作。
- **LLM Core** (推理核心): 中间还是同一个文字模型；只有两端是新的。

### 听

- **Speech-to-Text** (STT、ASR): 耳朵：把语音变成文字。
- **Error Propagation** (错误顺流而下): 一个转写错误，成了模型的输入。
- **Streaming STT** (边说边转写): 句子结束时文字已经备好——作出反应前没有停顿。

### 说

- **Text-to-Speech** (TTS、合成): 嘴巴：把回复文字变成声音。
- **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——并把延迟当作其他一切都要向它让步的约束。

速成课结束 · 7 章 · 18 个概念

接下来是练习：搭一个最简单的语音循环——语音转文字、模型回复、文字转语音——并给整个往返计时。然后让每个阶段都做流式处理，看着体感的延迟骤然缩短。最后，试着在它回复到一半时打断它，看看它会不会停下来倾听。当你亲身感受到一秒钟的空档如何打破对话的幻觉，这个挑战就变得真切了。但有一个想法要置于其余之上：语音就是同一个会思考的模型，外面加了一只耳朵和一张嘴，全部的难点在于把这三件事做得快到像是活的。让一切都流式，留意轮次，守住延迟预算——这才是让和 AI 说话像是在说话，而不是在等待。