第2章 系统架构设计：车载语音助手整体架构

好，咱们直接进入正题。车载语音助手这玩意儿，说白了就是一套“听得懂、反应快、说得准”的系统。但你要真把它拆开看，里面的门道可不少。

我个人习惯，做任何系统设计之前，先画一张大图。这张图里，必须把“云端”和“车机端”分清楚。为什么？因为这两边的职责完全不同，延迟要求也天差地别。

2.1 整体架构：云端+车机端

先说说整体架构。我把它分成三层：

• 车机端（边缘侧）：负责本地唤醒、降噪、VAD（语音活动检测）、以及部分离线指令的解析。说白了，就是“第一道防线”。
• 云端（服务端）：负责大词库的语音识别、自然语言理解、对话管理、以及TTS（文本转语音）合成。这是“大脑”。
• 通信层：连接车机和云端的桥梁。通常走WebSocket或者MQTT over TLS。

嗯，这里要注意。车机端和云端的分界线，不是固定的。我见过不少项目，一开始把太多逻辑放云端，结果网络一抖，语音助手就“哑巴”了。后来大家学乖了，把唤醒词、常用指令（比如“打开空调”、“导航回家”）都放本地。

2.2 模块划分与职责

咱们把模块拆开来看。每个模块的职责必须清晰，不然调试起来你会疯掉。

模块	位置	核心职责
音频采集模块	车机端	麦克风阵列管理、AEC（回声消除）、降噪、波束成形
唤醒引擎	车机端	本地唤醒词检测，比如“你好，小X”
VAD模块	车机端	判断人是否在说话，结束说话时自动截断
ASR引擎	云端为主	将音频流转换成文字。本地可做轻量级指令识别
NLU模块	云端	理解用户意图，比如“我冷了” -> 调高温度
对话管理	云端	维护多轮对话状态，比如“导航到天安门” -> “走哪条路？”
TTS引擎	云端/车机端	将文字转成语音播报。本地TTS用于离线场景
技能执行器	车机端	调用车辆CAN信号、HMI接口，比如真的去开空调

我在项目中遇到过一个问题：NLU模块和对话管理模块的职责没分清楚。结果NLU把“打开车窗”理解成了“打开天窗”，对话管理还傻傻地追问“您要打开哪个窗？”——这就是典型的模块边界模糊导致的体验灾难。

2.3 数据流与信令流设计

这块是很多工程师容易忽略的。你想想看，语音助手跑起来，数据怎么流？信令怎么走？

数据流（音频流）：

1. 麦克风采集到16kHz/16bit的PCM数据。
2. 经过AEC和降噪处理后，送入唤醒引擎。
3. 唤醒成功后，音频流通过WebSocket实时上传到云端ASR。
4. 云端返回识别结果（文字），再送入NLU。
5. NLU解析出意图和槽位，交给对话管理。
6. 对话管理生成回复文本，传给TTS。
7. TTS合成音频，下发到车机端播放。

信令流（控制信令）：

1. 车机端发送“唤醒成功”信令到云端，开启ASR会话。
2. 云端返回“ASR就绪”信令。
3. 用户说完话，VAD触发“语音结束”信令。
4. 云端返回“识别完成”信令，附带识别结果。
5. 车机端发送“执行结果”信令，比如“空调已开启”。

2.4 高可用与低延迟设计原则

车载场景下，延迟就是生命。用户说“刹车”，你等3秒才反应？那这车谁敢开？

我总结了几条铁律：

• 端到端延迟控制在500ms以内。其中，音频采集+降噪<50ms，唤醒<200ms，ASR+NLU<200ms，TTS+播放<50ms。
• 本地优先。所有高频指令（空调、车窗、导航回家）必须本地闭环。云端只处理复杂查询（比如“附近有什么好吃的？”）。
• 断网降级。网络断了，语音助手不能死。至少能执行本地指令，并提示“网络已断开，部分功能不可用”。
• 心跳保活。车机端和云端之间每5秒发一次心跳。连续3次心跳丢失，自动切换为离线模式。
• 冗余设计。云端ASR至少部署两个节点，一个挂了，另一个自动接管。切换时间<1秒。

嗯，说到延迟，还有一个容易被忽视的点：音频编解码。车机端上传音频时，如果直接传原始PCM，带宽占用太大。我建议用Opus编码，压缩率好，延迟也低。云端解码后送入ASR，整体延迟能降低20%左右。

最后，我想说一句：架构设计没有银弹。你设计的再好，到了实车上，总会遇到各种意想不到的问题。比如某些车型的麦克风阵列布局不合理，导致降噪效果差；或者车机芯片算力不够，本地唤醒引擎跑不起来。这些都需要你在实际项目中一点点去调、去优化。

好了，这一章就到这里。下一章咱们聊聊具体的唤醒词引擎怎么选型，以及怎么在低功耗芯片上跑起来。