Web 语音技术
系统梳理 Web 语音技术的发展脉络、系统架构与技术选型，帮助读者建立整体认知，并为后续专题内容提供阅读导览。
概述
随着浏览器能力与人工智能技术不断发展，语音逐渐成为 Web 应用中重要的交互方式之一。相比键盘、鼠标和触屏操作，语音能够让用户以更加自然、便捷的方式表达需求，在移动设备、无障碍交互和智能助手等场景中具有独特优势。
一个完整的 Web 语音应用并不只是完成声音与文字之间的转换。从用户说话到系统理解需求并作出响应，通常需要经过音频采集与处理、语音传输、语音识别、语义理解、任务处理、响应生成、语音合成与音频播放等多个环节。其中，语义理解、任务处理等并不属于狭义的语音技术，而是与语音能力共同构成完整交互链路的系统能力。
除了这些基础环节，系统还需要考虑交互过程中的实时性与连续性，以及话轮切换、用户打断和异常恢复等机制。这些因素共同决定了语音交互是否自然、流畅，也直接影响最终的使用体验。
从整体上看，本文所讨论的「Web 语音技术体系」，是以浏览器作为交互入口，将语音能力与 Web 通信、交互逻辑及业务服务相结合，从而完成语音输入、处理与响应的一整套技术链路。
本文是整个系列的导览，不会深入具体的模型结构与代码实现，而是先围绕下面三个问题建立对 Web 语音技术的整体认知：
- Web 语音技术经历了怎样的发展过程；
- Web 语音系统由哪些核心能力与技术环节组成；
- 面对不同的业务需求，应当如何选择合适的技术方案与部署方式。
发展脉络
Web 语音应用建立在数字音频与语音技术长期发展的基础之上。从声音的数字化，到语音识别与语音合成技术逐渐成熟，再到与自然语言处理、大语言模型等技术结合，语音逐渐从独立的识别与合成能力，融入更加完整的人机交互系统。
从声音到数字音频
早期语音相关技术首先关注的是声音的记录、传输与还原。1876 年，亚历山大·格拉汉姆·贝尔 完成了早期电话实验，使声音能够转换为随时间变化的电信号，并通过通信线路进行远距离传输。这一时期的技术主要解决“如何传递声音”的问题，还无法理解声音中包含的语言内容。
进入 20 世纪后，声音处理逐渐从 模拟信号 向 数字信号 转变。1937 年，英国工程师 亚历克·里夫斯 提出了 脉冲编码调制（Pulse Code Modulation，PCM）的思想。通过采样、量化和编码，连续变化的模拟声音信号可以转换为由离散数值表示的数字信号，使声音能够被计算机存储、传输和处理。
声音数字化为后来的语音分析与识别奠定了基础。当声音被转换为数字信号后，计算机便可以通过信号处理方法对其进行分析，从中获得频率分布、能量变化等声学信息。随着 数字信号处理 和 模式识别 等技术的发展，计算机逐渐具备了从语音信号中识别语言内容的能力。
声音数字化改变了声音的表示与处理方式，使声音从连续变化的模拟信号转变为计算机能够存储、传输和分析的数字信号，也为后续的语音识别与语音合成等技术奠定了基础。
从数字音频到声学特征
数字化后的声音由一系列按时间顺序排列的采样值表示，每个采样值记录声音信号在对应时刻的振幅。将这些采样值依次绘制出来，就可以得到反映声音振幅随时间变化的语音波形。
语音波形保留了声音随时间变化的信息，但并不能直接反映其中的语言内容。即使说出同一个词，其波形也会受到音量、语速、说话人以及环境噪声等因素的影响，因此很难直接进行比较和建模。
语音识别通常需要从采样数据中提取更稳定、更适合分析的 声学特征。这些特征保留与语音识别相关的声学信息，使原始波形能够以更适合模型分析和建模的形式表示。
特征提取本质上是一种有目的的信息取舍：既要保留能够区分不同发音的关键声学信息，又要尽可能降低音量、语速以及部分环境因素带来的影响，使得到的声学表示更加稳定。
语音是一种随时间变化的复杂信号。根据 傅里叶分析 的基本思想，复杂信号可以表示为不同频率、幅度和相位的正弦成分的组合。因此，除了观察语音波形随时间的变化，还可以分析其中包含哪些频率成分，以及各个频率成分的强弱。傅里叶变换 正是实现这种分析的重要工具，它可以将信号从 时域 转换到 频域，从而得到信号的频谱。
但语音的频率组成并不是固定不变的，而是会随着发音过程不断变化。如果直接对较长的一段语音进行傅里叶变换，得到的是这段语音整体的频率组成，很难反映不同频率成分在什么时间出现、又如何随时间发生变化。因此，实际处理中通常会将连续语音划分为几十毫秒左右的短时片段，这一过程称为分帧。随后分别对每一帧进行 频谱分析，并让分析位置沿时间不断移动，就可以连续观察语音频率结构随时间的变化。相邻帧之间通常还会保留一定的重叠，以减少帧与帧之间的信息跳变，获得更加连续的时间变化信息。
分帧相当于从连续信号中截取一小段进行分析，但这种直接截断会在帧的两端形成突变，而傅里叶变换会把这些人为产生的突变也当作信号的一部分，从而在频谱中产生额外的频率成分，也就是常说的 频谱泄漏。因此，在进行频谱分析之前，通常还会对每一帧进行 加窗，让帧两端的信号逐渐减弱，从而降低截断边界对频谱分析的影响。
完成分帧与加窗后，就可以对每一帧进行傅里叶变换。工程中通常使用 快速傅里叶变换（Fast Fourier Transform，FFT）高效地完成计算，得到各个短时片段对应的 频谱。将频谱中的频率强度映射为颜色，并按照时间顺序排列连续多帧的结果，就形成了 语谱图（Spectrogram）。
语谱图同时保留了时间、频率和强度信息：横轴表示时间，纵轴表示频率，颜色表示对应时刻、对应频率成分的强弱，因此能够直观呈现语音的频率结构如何随时间变化。
傅里叶变换可以将语音从时域转换到频域，得到信号的频率组成，但这并不等同于完成了特征提取。实际系统通常还会根据语音特性、听觉感知或模型需求，对频谱或波形做进一步处理，从而得到更适合分析和识别的声学表示。
在语音识别发展的早期阶段，声学特征主要依赖人工设计。研究者通过对语音波形和频谱进行处理，提取能够反映声音变化与声学结构的信息。例如，短时能量可以描述声音强弱，过零率可以粗略反映波形变化的快慢，而 线性预测编码（Linear Predictive Coding，LPC）则利用线性预测模型描述语音的频谱特性。这一阶段的特点是：由人工决定从语音中提取哪些信息，以及如何将这些信息表示为可供后续处理的声学特征。
随着统计语音识别的发展，更适合识别任务的特征表示逐渐成为主流。其中，梅尔频率倒谱系数（Mel-Frequency Cepstral Coefficients，MFCC）通过梅尔滤波器组、对数处理和离散余弦变换等步骤，将频谱信息转换为较为紧凑的倒谱特征；感知线性预测（Perceptual Linear Prediction，PLP）则将人类听觉感知相关的处理融入 线性预测，得到适合语音识别的低维声学表示。MFCC、PLP 等人工设计特征也成为传统统计语音识别系统中的经典方案。
随着 深度学习 的发展，声学特征的获取方式开始发生变化。相比传统方法依赖人工设计并压缩声学信息，神经网络能够从保留更多信息的输入中自行学习与识别任务相关的模式。因此，系统开始更多使用滤波器组特征（Filter Bank，FBank）、对数梅尔频谱（Log-Mel Spectrogram）等保留较多时频信息的表示，将更多特征学习工作交给模型。需要注意的是，这些表示并非在深度学习时代才出现，而是在深度学习语音识别系统中得到了更加广泛的应用。
更进一步的方法开始使用可训练的网络前端直接处理原始波形，由数据和任务目标决定应当保留哪些信息。以 Wav2vec 2.0 为代表的自监督学习方法，还可以利用大量未标注语音预先学习通用的语音表示，再使用带有文字标注的语音数据适配具体的语音识别任务。特征的获取也由此进一步从人工设计，走向由模型从数据中自动学习。
声学特征的演进，本质上是特征获取方式的变化：从依赖人工设计和筛选声学信息，逐渐转向保留更多基础声学信息，并由模型从数据中学习与识别任务相关的表示。随着深度学习与自监督学习的发展，模型在特征学习中的作用也越来越重要。
从模板匹配到端到端识别
有了能够描述语音的声学特征，下一个问题就是如何通过这些特征判断说话内容。从早期的参考模板，到统计模型和深度神经网络，语音识别的主要变化在于系统如何建立声学特征与语言单位之间的关系。
早期自动语音识别主要面向数字、孤立词和简单命令等有限场景，其中一种具有代表性的方案是模板匹配。构建这类系统时，通常先确定能够识别的有限词表，再采集一个或多个说话人朗读各个词语的录音。录音经过端点检测后被划分为短帧，系统再从每一帧提取声学特征。按时间排列的帧级特征共同组成一条特征序列，并作为对应词语的参考模板保存。
识别新的语音时，系统会执行相同的预处理和特征提取，再将得到的特征序列与已有参考模板进行比较，从而寻找最相似的结果。
不过，每次发音的时长往往不同，二者的特征帧很难按照时间位置逐一对应。动态时间规整（Dynamic Time Warping，DTW）通过在时间轴上对两条特征序列进行非线性对齐，寻找累计距离较小的匹配路径，使不同语速下的发音仍然能够进行比较。
模板匹配的核心是“寻找最相似的参考样本”。DTW 解决了不同发音之间的时间对齐问题，但系统的识别能力仍然依赖预先采集的模板。随着词汇、说话人和应用场景不断增加，仅靠扩充模板已经很难覆盖复杂的语音变化。
随着识别词汇和应用场景不断扩大，逐条保存并比较参考模板的方式越来越难以满足需求。语音识别开始从“寻找最相似的模板”，转向从大量语音样本中学习发音的统计规律，并逐渐形成以概率模型为基础的统计语音识别方法，其中具有代表性的就是 GMM-HMM 系统。
一段语音并不是静止不变的，而是由一系列随时间连续变化的发音过程组成。为了描述这种变化，隐马尔可夫模型（Hidden Markov Model，HMM）会将一个发音过程表示为若干依次变化的状态（State）。可以简单理解为：每个状态对应发音过程中的一个短时阶段，而状态之间的转移则描述这些阶段随时间如何变化。
但 HMM 只描述了“发音状态如何随时间变化”，还需要判断每一帧声学特征更可能属于哪个状态。高斯混合模型（Gaussian Mixture Model，GMM）正是用来描述各个状态下声学特征的概率分布。系统通常以 MFCC、PLP 等帧级声学特征作为输入，由 GMM 计算当前特征在不同状态下出现的可能性，再由 HMM 结合状态之间的转移关系，寻找最可能的状态序列。
因此，GMM-HMM 的核心可以简单理解为：GMM 判断“这一帧像哪个发音状态”，HMM 判断“这些发音状态按照什么顺序出现最合理”。相比模板匹配直接将整条特征序列与参考样本进行比较，这种方法能够从大量训练语音中学习不同发音的统计规律，从而更好地适应说话人、语速和发音方式等差异。
随着识别任务进一步扩展到大词汇量连续语音，仅依靠 声学模型 仍然无法直接确定最终的文字序列。传统系统通常还会使用 发音词典 建立词语与 音素 等发音单位之间的对应关系，并通过 语言模型 描述不同词语及词语序列出现的可能性。最终，解码器综合声学模型、发音词典和语言模型提供的信息，在大量候选路径中搜索概率更高的文字序列，并输出识别结果。
这种架构逐渐成为传统大词汇量连续语音识别的重要基础，但也形成了明显的模块化特征：特征提取、声学模型、发音词典、语言模型和解码器承担不同职责，需要分别设计并最终组合成完整系统。
统计语音识别的核心变化，是从“比较具体样本”转向“学习大量样本背后的概率规律”。GMM-HMM 不再依赖完整的参考模板，而是对语音状态及其声学特征分布进行建模。
随着训练数据和计算能力不断增长，深度神经网络开始被用于改善传统系统中的声学建模。具有代表性的 DNN-HMM 混合系统使用深度神经网络（Deep Neural Network，DNN）取代 GMM 在声学建模中的主要作用，根据连续多帧的声学特征学习更加复杂的非线性关系，并估计对应 HMM 状态的概率。
相比 GMM 使用预先选定的概率分布形式描述声学特征，神经网络能够从数据中学习更加复杂的特征组合与决策边界，因此显著增强了声学模型的建模能力。不过，DNN-HMM 并没有改变传统语音识别系统的整体结构：HMM、发音词典、语言模型和解码器等组件仍然保留，变化主要发生在声学模型内部。
DNN-HMM 的主要变化发生在声学模型内部。神经网络取代 GMM 学习更加复杂的声学关系，但 HMM、发音词典、语言模型和解码器等传统模块仍然保留。
随着神经网络的序列建模能力进一步增强，研究开始尝试减少对多个独立模型、人工对齐过程和中间训练目标的依赖，并直接围绕最终的文字结果优化整个识别系统，端到端语音识别由此逐渐发展起来。
端到端语音识别尝试在统一的训练目标下学习输入语音与输出文字之间的关系。连接时序分类（Connectionist Temporal Classification，CTC）、注意力编码器—解码器（Attention-based Encoder-Decoder）以及 Transducer 等方法，为长度不同且对应关系未知的语音序列和文字序列提供了不同的建模方式，使模型能够基于“语音—文字”配对数据进行整体训练。
此后，Transformer、Conformer 等结构进一步增强了模型对长距离上下文和局部声学模式的建模能力。传统系统中原本相对独立的声学建模、序列建模和文字预测，也开始被整合到更加统一的训练框架中。
端到端描述的是训练目标和系统边界，并不限定模型必须采用哪一种输入。模型可以接收上一节介绍的 Filter Bank 或对数梅尔频谱，也可以使用可训练前端处理原始波形；关键在于声学表示、序列建模和文字预测能够围绕最终识别目标共同优化。
端到端并不是“不再需要特征”，而是减少独立设计和训练的中间模块，让更多处理环节参与同一个识别目标的优化。
端到端模型虽然简化了传统系统的模块划分，但训练通常仍然需要大量“语音—文字”配对数据，而现实中未标注的语音数据远比人工转写数据容易获得。为了利用这些数据，自监督学习开始被广泛用于语音模型的预训练。
以 wav2vec 2.0 为代表的方法，可以先利用大量未标注语音学习通用表示，再使用标注数据针对语音识别任务进行微调。这种“预训练—微调”的方式使模型能够先学习语音本身的结构，再适配文字识别等具体任务，从而减少对大规模人工转写数据的依赖。
自监督学习改变了模型获得通用语音能力的方式。它不能完全替代标注数据，但可以更充分地利用容易获得的未标注语音。
回顾这一节，语音识别从模板匹配中寻找最相似的参考样本，发展到 GMM-HMM 对语音状态和概率分布进行统计建模，再由 DNN-HMM 增强声学模型，最终走向围绕“语音到文字”进行整体优化的端到端模型。自监督预训练则进一步改变了模型利用数据的方式。这条模型演进路线与上一节的声学表示演进相互配合，共同推动了识别能力的发展。
从传统 Web 到语音系统
早期 Web 应用主要通过键盘和鼠标接收用户输入。虽然浏览器很早就能够播放音频，但在麦克风访问、实时音频处理和语音识别等方面的能力仍然有限。要在网页中实现语音交互，往往需要依赖浏览器插件、本地程序或其他外部组件，难以像普通 Web 功能一样直接集成。
随着 HTML5 及相关 Web 标准的发展，浏览器开始获得更加完善的音频与媒体处理能力。2011 年，Web Audio API 首个公开工作草案发布，为浏览器中的音频处理与控制提供了一套标准化接口；随后，Web Speech API 也开始探索通过浏览器接口提供语音识别与语音合成能力。与此同时，媒体采集、音频录制和实时通信等相关技术不断发展，浏览器逐渐具备了从获取声音、处理声音到传输和播放声音的一系列基础能力。
这些能力并不是由某一个 API 独立完成的，而是由不同的 Web API 共同提供：
- Media Capture and Streams API 允许网页在获得用户授权后访问麦克风等媒体输入设备；
- Web Audio API 提供音频处理、分析与播放能力；
- MediaRecorder 用于录制 MediaStream 中的音频或视频数据；
- WebSocket 与 WebRTC 为实时数据和音视频通信提供了不同的传输机制；
- Web Speech API 则在部分浏览器中提供更高层的语音识别与语音合成接口。
这些能力的逐步完善，使浏览器在语音应用中的角色发生了变化。它不再只是展示语音处理结果的页面，还可以直接参与麦克风授权、音频采集与处理、实时通信、交互状态管理以及语音播放等环节，为今天的 Web 语音应用提供了基础运行环境。
Web Speech API 的支持范围、具体实现和服务来源存在浏览器差异。它适合快速验证或轻量功能，但对稳定性、隐私和跨浏览器一致性要求较高时，通常需要接入云服务或自建语音链路。
从语音命令到智能对话
传统语音助手通常采用固定的级联流程：
语音识别 → 意图识别 → 业务执行 → 语音合成这种方式适合任务边界清晰的场景，例如：查询天气、控制设备或执行固定命令。系统通常需要预先定义意图、实体和业务规则，再根据识别结果匹配相应的处理逻辑，因此能够理解和处理的表达方式往往受到既定规则的限制。
随着 大语言模型（Large Language Model，LLM）的发展，语音交互中的语言理解和响应生成方式开始发生变化。系统不再完全依赖预先定义的意图和规则，而是可以结合对话历史理解更加灵活的自然语言表达，并通过检索、数据库、接口和工具调用等方式获取信息或完成具体任务。现代智能语音应用因此逐渐形成了新的级联链路：
ASR → LLM → 工具 / 业务系统 → TTS与此同时，能够直接处理和生成音频的 多模态模型 也在不断发展。相比先将语音完整转换为文本再进行处理，这类模型能够进一步利用语气、停顿、节奏等文本难以完整保留的信息，为更加自然的语音交互提供了新的实现方式。
从固定的语音命令到基于大语言模型的智能对话，再到直接处理语音的多模态模型，语音交互正在从“识别并执行预设指令”，逐渐发展为能够理解上下文、完成任务并生成响应的自然交互方式。
整体架构
一个典型的 Web 语音系统，可以从职责上划分为交互层、通信层、智能处理层和业务服务层。
- 交互层：获取用户语音、播放合成音频，并呈现监听、识别、思考和播放等状态；
- 通信层：在浏览器与服务端之间传输音频、文本、事件和控制信息；
- 智能处理层：负责语音识别、上下文理解、响应生成和语音合成；
- 业务服务层：连接数据库、检索系统、业务接口和外部工具，完成具体任务。
这些层并不是按顺序执行一次就结束。实时语音系统通常会持续交换音频片段、中间识别结果、话轮状态和控制事件，让多个模块并行协作。
例如，用户尚未说完时，浏览器就可以持续发送音频；ASR 同时返回中间文本；端点检测判断当前话轮是否结束；后续模型开始准备响应。合理的流式设计可以缩短等待时间，也能让界面更及时地反馈系统状态。
音频采集与处理
Web 应用通常通过 navigator.mediaDevices.getUserMedia() 获取麦克风的 MediaStream。接下来采用哪种处理方式，取决于业务目标：
- 录音完成后上传：可以使用
MediaRecorder； - 实时获取采样数据：可以使用
Web Audio API与AudioWorklet； - 直接建立实时媒体连接：可以考虑 WebRTC。
采集后的音频可能还需要重采样、声道转换、格式转换和分片。复杂环境下，还应关注噪声抑制、回声消除和自动增益控制。
设计采集链路前，应先确认下游服务需要的采样率、声道、位深和编码格式。先采集再临时适配，往往会增加延迟和排查成本。
语音识别
自动语音识别（Automatic Speech Recognition，ASR）负责把音频转换为文字。结果可以在整段录音结束后一次性返回，也可以在用户说话时持续输出中间结果。
实时应用通常更关注流式识别：浏览器不断发送音频片段，服务端返回临时文本，并在话轮结束后给出相对稳定的最终结果。除了准确率，还需要考虑首字延迟、最终结果延迟、语言支持、热词能力和中间结果稳定性。
在 Web 场景中，识别效果不仅由模型准确率决定。音频格式是否匹配、网络传输是否稳定、中间结果是否及时，同样会直接影响用户体验。
语义理解与任务处理
识别文本只是用户表达的载体，系统还要结合上下文判断用户希望完成什么，并把结果转化为业务动作。
任务边界明确时，可以使用意图识别、实体提取和规则系统；面对开放式问答、多轮对话或复杂指令时，可以使用大语言模型，并让模型连接检索系统、数据库和业务工具。
这一环节需要明确区分“生成回复”和“执行操作”。涉及账户、支付、设备控制或数据修改时，业务系统仍应进行权限校验、参数验证和结果确认，不能只依赖模型输出。
语言模型可以理解和规划任务，但真正的业务操作仍应由受约束的接口执行，并由业务系统负责权限、参数和结果校验。
语音合成
语音合成（Text-to-Speech，TTS）负责把响应文本转换为声音。Web 应用可以等待完整音频生成后播放，也可以采用流式合成，让浏览器尽早收到并播放首段音频。
选型时除了自然度，还应关注首包延迟、音色一致性、流式能力、格式支持、可控参数以及浏览器端的缓冲与播放策略。
对实时语音应用而言，“多久开始说话”通常比“多久生成完整音频”更容易被用户感知，因此流式合成和首包延迟尤其重要。
语音交互机制
只有 ASR 和 TTS，还不足以形成自然的语音对话。系统还需要协调用户与应用之间的交流节奏，常见能力包括：
- 语音活动检测（VAD）与端点检测；
- 语音唤醒与录音授权；
- 话轮管理和上下文维护；
- 用户打断系统播报（Barge-in）；
- 音频缓冲、心跳、断线重连与异常恢复。
用户感受到的“自然”不只来自模型音质和识别准确率，还来自系统能否及时开始监听、正确判断说话结束、允许用户打断，并在网络异常后恢复状态。
技术选型与部署
Web 语音系统没有适用于所有项目的固定方案。通常可以从浏览器原生能力、云语音服务和开源模型三类路径中选择。
| 方案 | 适合场景 | 主要优势 | 需要关注 |
|---|---|---|---|
| 浏览器原生能力 | 原型、轻量辅助功能 | 接入快，服务端工作少 | 兼容性、可控性和实现差异 |
| 云语音服务 | 需要快速上线的生产应用 | 能力完整，稳定性与语言支持较好 | 调用成本、网络依赖与数据合规 |
| 开源模型 / 自建服务 | 强调隐私、定制或长期可控性 | 模型与数据链路可控 | 推理资源、工程复杂度和运维成本 |
从运行位置看，还可以分为云端、本地和混合部署：
- 云端部署拥有更充足的计算资源，便于扩展和集中维护，但依赖网络，并涉及音频数据传输与合规问题；
- 本地部署在隐私、离线和可控性方面更有优势，但受设备性能、模型体积和能耗限制；
- 混合部署把采集、预处理或轻量检测放在终端，将高计算量任务交给服务端，在体验与成本之间取得平衡。
评估方案时，可以重点比较以下因素：
- 准确率、自然度与语言覆盖；
- 首字、首包和完整响应延迟；
- 实时流式能力与浏览器兼容性；
- 音频数据的隐私、安全和合规要求；
- 开发、推理、带宽和长期运维成本；
- 团队对模型、音频与实时系统的维护能力。
原型阶段可以优先验证完整交互链路，而不是一开始就追求最强模型。只有在真实场景中测量准确率、延迟、成本和失败率，选型才有可靠依据。
系列导览
本文建立的是 Web 语音技术的整体地图。后续文章将沿着一次语音交互的完整链路，分别介绍以下主题：
- 音频采集与处理：声音数字化、浏览器采集、音频处理、音频增强与实时传输；
- 语音识别：识别基本原理、声学表示，以及从传统方案到端到端模型的演进；
- 语义理解与任务处理：意图、实体、上下文、工具调用与业务执行；
- 语音合成：合成流程、技术演进、流式生成与浏览器播放；
- 语音交互机制：VAD、端点检测、话轮管理、打断和实时会话状态；
- 技术选型与部署：浏览器原生能力、云服务、开源模型与部署方案。
系列文章按照一次语音交互的处理顺序组织。可以从音频采集开始依次阅读，也可以根据当前关注的系统环节直接进入对应专题。
小结
Web 语音应用的核心，不是把某个语音模型放进网页，而是让浏览器、网络、模型和业务系统围绕一次对话稳定协作。
从浏览器采集音频，到 ASR 生成文字，再到语言模型或业务系统理解并执行任务，最后由 TTS 返回语音，每个环节都会影响最终体验。与此同时，授权、流式传输、状态反馈、打断和异常恢复等工程机制，决定了这条链路能否真正用于生产环境。
接下来的系列文章将从音频采集与处理开始，沿着这条链路逐步展开。
相关阅读
