车载语音模块选型这件事，我一开始也以为就是对着参数表看看识别率、挑个贵点的完事。直到真把 SU-32T 和 CI-03T 同时塞进测试台架，跑到停车场和城市快速路上实测了一轮，才发现这中间的门道比想象中多得多：不光要对比识别率，还要搞清楚 CAN 控制器缺席怎么补、TTL 串口在车载 12V 环境下到底能撑多远。这篇文章把我这一轮踩坑和实测的结果整理出来，给正在选型或者准备做车载语音方案的你一个参考。
1. 别急着比识别率，车载环境先吃掉你三成性能
很多人在选型的时候第一句话就问“识别率多少”，这个思路放在安静的办公室没问题，但放在车里就是个陷阱。车载环境的声学条件跟室内完全两码事，同样的模块、同样的词表，在室内测试能达到 95% 以上，装到车上可能直接跌到 70% 都不到。先搞清楚噪音到底是怎么影响语音识别的，再看两个模块的参数才有意义。
1.1 信噪比才是关键指标，不是响度
车上最典型的声音干扰是什么？风噪、胎噪、发动机声、空调鼓风机声、转向灯滴答声，还有副驾和后排说话的人声。这里面最坑的不是响，而是“频段重叠”。比如高速上 100km/h 的时候，风噪主要集中在 500Hz 到 2kHz 这一大片区域，而人说话的关键频段（尤其是辅音部分，像“是”“次”“四”这种齿音）也集中在这一带。噪音一上来，模块收到的语音信号信噪比直线下降，识别器就会把辅音听丢，结果就是“开空调”识别成“开窗”这种离谱操作。
所以评估车载语音模块，我个人习惯先看两个东西：麦克风信噪比（SNR）和 DSP 降噪算法。麦克风 SNR 低于 60dB 的直接不用看，在车里根本扛不住。然后把测试音频里混入不同 SNR 的噪音，实测模块还能不能正确识别，这比看官方宣传页上的“识别率 98%”靠谱得多。
1.2 车载场景还有几重隐藏挑战
除了噪音，还有几个容易被忽略的问题：
- 回声和混响：车窗关紧的时候，声音在封闭车厢里反复反射，尤其是有天窗的车型，混响时间会比普通房间更长，识别器会把多个重复的语音帧叠在一起，导致误识别。
- 多唤醒源：车里经常放着音乐或者广播，语音模块的唤醒词被播报声音误触发，或者反过来一直不触发。好的模块应该能判断“音频是来自本地播放还是人声”，但这个功能很多模块只是做了个单声道回声消除，效果非常看芯片算力。
- 振动和电源噪声：车载 12V 电源经过 DCDC 之后纹波可能还有上百毫伏，而很多语音模块对供电纹波很敏感，电源一脏，ADC 采出来的信号底噪就高，识别率也跟着掉。
这些因素叠加起来，就会出现典型的“静态测试满分、上车就废”的情况。所以这一轮对比，我把重点放在了三类真实场景的模拟上，而不是标准实验室环境。
2. SU-32T 与 CI-03T 在同一条测试路径下的真实差距
这次测试的两块板子分别是 SU-32T 和 CI-03T，都是从模块厂直接拿的带麦克风的成品板。SU-32T 走的是单麦 + 本地 DSP 降噪路线，CI-03T 则是双麦阵列 + 波束成形的方案。听起来双麦应该碾压单麦，但实际测下来，结果并没有那么一边倒。
2.1 硬件底子对比
先看硬件层面的区别。我把两块模块的规格列了个表，方便直接对照：
| 项目 | SU-32T | CI-03T |
|---|---|---|
| 麦克风配置 | 单麦克风 | 双麦克风阵列 |
| 降噪方式 | 本地 DSP 降噪 | 波束成形 + 回声消除 |
| 离线指令条数 | 最多 100 条 | 最多 200 条 |
| 唤醒词自定义 | 支持，需重新训练模型 | 支持，可现场录入 |
| 串口输出 | UART TTL 3.3V | UART TTL 3.3V |
| CAN 接口 | 无 | 无 |
| 工作电压 | 5V | 5V |
| 标称识别率 | 98%（安静环境） | 97%（安静环境） |
看表格会发现一个有意思的点：两块模块都没有 CAN 控制器，这意味着直接对接车载总线是没戏的，后面我会专门说这个问题。而麦克风配置上的差异，理论上 CI-03T 应该明显更强，但实测下来恰恰在最高噪音场景下翻车了。
2.2 三场景实测数据
我设计了三个测试场景，分别对应车辆静止、城市道路、高速行驶：
- 场景 A：车辆熄火静止，仅有环境底噪（约 40dB）
- 场景 B：空调二档 + 城市道路 60km/h，关闭车窗（约 65dB）
- 场景 C：高速 100km/h，车窗关闭，空调二档（约 72dB），这个条件下人正常说话已经要提高音量了
每个场景测试 100 次指令识别，指令集包含 20 条常用车载指令，如“打开空调”“温度调到 24 度”“播放音乐”“下一首”“关闭车窗”等，男女声各 50 次。
结果如下：
| 场景 | SU-32T 识别率 | CI-03T 识别率 |
|---|---|---|
| A：静止 40dB | 96% | 97% |
| B：城市 65dB | 88% | 91% |
| C：高速 72dB | 79% | 74% |
在静止场景下两者几乎打平，城市路况下 CI-03T 小幅领先，但到了高速场景反而被 SU-32T 反超。为什么双麦阵列会在高噪音下翻车？我分析原因是 CI-03T 的波束成形算法在远场（大约 0.5m-3m）效果好，但车载场景里驾驶员嘴离麦克风往往只有 20-40cm，属于近场。近场情况下，波束成形的空间滤波优势发挥不出来，反而因为双麦间距固定，在强风噪下两个麦克风收到的噪声不完全相关，算法处理完后残留的噪声反而比单麦 DSP 降噪后的更多。
这个结果直接让我改变了选型策略：如果语音模块安装在离驾驶员嘴边很近的位置（比如方向盘或仪表台上方），单麦 DSP 方案的 SU-32T 反而更稳；如果要覆盖全车多位置（比如后排乘客也要用），那 CI-03T 的双麦优势才能体现出来。
2.3 指令条数与自定义词表的实际体验
指令条数这个东西，参数表上写着 100 条、200 条，看起来很够用，但真正部署的时候你会发现完全不是那么回事。
SU-32T 的自定义词表需要把指令文本发给模块厂训练模型，然后下载固件刷进去。这一来一回，改一次词表至少要等半天时间，而且指令不能随便加，加得多了识别速度会下降。CI-03T 支持现场录入指令，操作上方便很多，但现场录入对发音环境要求高，在嘈杂的车间里录入的词条，识别率会明显低于在安静环境录的。
我的建议是：无论用哪块模块，词表一定要提前定死，不要想着上线之后频繁改。每一条指令都要考虑同音词和易混词，比如“关闭”和“关毕”、“下一首”和“下一手”，这些词在车载噪音环境下非常容易混淆，词表里尽量不要同时出现相近发音的指令。
3. CAN 控制器缺席：对接车载总线时的三种绕行方案
接下来要说的这个问题，在选型的时候特别容易被忽略，却是装车时候最头疼的：这两块语音识别模块都只有 TTL 串口，没有 CAN 控制器。如果你只是做一个独立语音控制的小盒子，那串口够了；但如果要跟原车总线联动——比如获取车速、读取车门状态、跟方向盘按键做互斥——没有 CAN 就非常被动。
3.1 为什么语音模块没有 CAN 会让你抓狂
车载环境里，很多信息只有总线上才有。举个例子：你要做“车速超过 80km/h 时禁止语音开启天窗”这个安全逻辑，语音模块本身不知道车速，它只能识别到“开启天窗”这条指令。如果语音模块有 CAN 口，它可以直接挂到总线上读车速节点；但 SU-32T 和 CI-03T 都没有，你只能把“车速判断”这个逻辑放到外部的 MCU 上，语音模块只负责把识别结果发出去，然后 MCU 再根据车速决定要不要执行。
这就多了一层数据中转，带来两个问题：
- 实时性受损：语音模块识别完指令，通过串口发给 MCU，MCU 再通过 CAN 发到执行器，整条链路多了串口这一跳。串口波特率不高的时候，几十毫秒的延迟是常事，而很多车载控制指令要求 100ms 内响应，一旦慢了，用户体验就很差。
- 布线复杂度上升：本来语音模块可以直接挂在 CAN 总线上的，现在必须拉一根串口线到 MCU，然后 MCU 再接 CAN 收发器，整个走线路径变长，抗干扰能力下降，还给装车增加了故障点。
3.2 没有 CAN 的三种替代接法及利弊
我实际试了三种方案，各有取舍：
方案一：外部 MCU + CAN 控制器桥接语音模块 TTL 串口 -> STM32/ESP32 -> 外挂 MCP2515 + TJA1050 -> CAN 总线。这是最通用的做法，也是我用得最多的。优点是灵活，除了转 CAN，还可以顺便处理一些逻辑，比如超速禁指令、多指令排队。缺点是链路长，你需要多写一套协议转换代码，还要处理两端的流控和缓冲，调试工作量大。
方案二：直接用带 CAN 的单片机替代语音模块方案把语音识别模块整个放弃，用 ESP32 的 TWAI 控制器（也就是 CAN 控制器）直接接 TJA1050 收发器，再跑一个离线语音识别库。这样的话，CAN 和语音识别在一块芯片上搞定，省了一个模块的钱和一块 PCB 的面积。但代价是语音识别效果完全取决于你用的库和调优水平，大概率比不过专门优化过的 SU-32T、CI-03T 这类模块。我拿 ESP32 跑过一些开源离线识别库，安静环境下还行，一上车就原形毕露。
方案三：语音识别结果只做本地执行，不总线上报如果只是控制一些后装设备（比如氛围灯、电动尾门、座椅通风），不涉及原车总线数据，那根本不需要 CAN。语音模块识别后直接通过串口控制一个继电器/电机驱动板就够了。这个方案最简单，但要特别注意别把语音模块当成总线节点来用——很多拿了语音模块就想往原车线上挂的人，在这上面踩了坑，最后要么烧了模块，要么把原车总线干扰得报故障码。
3.3 我踩过的坑：总线上电时序和优先级
方案一里有个细节特别容易翻车：上电时序。CAN 总线上各个节点的上电顺序如果不对，先上电的节点可能因为总线一直处于显性电平而报错，严重的时候会把整个总线拉死。语音模块通过 MCU 桥接后，MCU 如果比车上其他 CAN 节点上电快，在初始化 CAN 控制器的时候可能会往总线上发错误的帧，导致其他节点报一堆故障码。
解决方法是给 MCU 加一个上电延时，等整车总线稳定（一般等 200-500ms）之后再初始化 CAN。这个延时在上电自检里很重要，但很多从做消费电子产品转来做车载的工程师，习惯了上电就跑，完全没想过这个，结果装车测试的时候被底盘和 BCM 的故障码折腾了好几天。
另外一个坑是发送帧 ID 的优先级。车载 CAN 总线里帧 ID 越小优先级越高。如果你的桥接 MCU 发的帧 ID 设得很小（比如 0x010），它可能会抢在整车关键报文之前发出去，轻则延迟其他节点通信，重则被网关当成非法帧踢掉。我建议语音控制相关的帧 ID 从 0x100 之后开始排，并且尽量避开车厂已经占用的区间，具体要看你这辆车实际的 CAN 数据库文件。
4. TTL 串口的工程边界：电平、线长与地环路
前面说了语音模块没有 CAN 只能走 TTL 串口，但 TTL 串口在车载环境里并不是一个“插上就能用”的东西。它的电平标准、传输距离、抗干扰能力都有明确的物理边界，很多项目就是栽在这条看起来最简单的串口线上。
4.1 车载 12V 环境下 TTL 为什么容易翻车
SU-32T 和 CI-03T 的串口都是 3.3V TTL 电平，而车里常见的 MCU 和车机系统一块 5V 的、一块 3.3V 的，电平不匹配就直接通信失败。如果语音模块和 MCU 都标称 3.3V，你觉得没问题，直接拿杜邦线一连，结果死活收不到数据——大概率是因为两边虽然都是 3.3V，但参考地电平不一致导致的。
低电压差分信号（LVDS）和 TTL 的差别在于，TTL 是单端信号，发送端和接收端必须共地。车载环境里，语音模块的供电来自 DCDC，MCU 的供电来自另一个 DCDC，两块 DCDC 的输出地和输入地之间可能存在零点几伏的电位差，这个压差在 TTL 看来就已经是可见的信号干扰了。轻则偶发乱码，重则直接把串口芯片打死。
正规做法是加一个隔离，比如用 ISO7721 这类数字隔离芯片把语音模块和 MCU 的地彻底隔开，两边各用各的电源，通信只靠信号线穿过隔离芯片。这样做以后，再没遇到过“偶尔不通”这种玄学问题。
4.2 线长与波特率：你踩过的那些偶发乱码可能都跟这有关
TTL 串口的传输距离和波特率是强相关的。很多语音模块默认波特率是 9600 或者 115200，在桌面上测试用什么线都行，但装到车上就不一样了——从仪表台到扶手箱的走线动辄两三米，如果还是普通杜邦线，115200 波特率下很容易出现码间串扰。
我实测过一组数据：用普通 22AWG 杜邦线，在 115200 波特率下，线长超过 50cm 就开始偶尔丢字节，超过 1 米基本没法用；换用双绞线后，1.5 米内可以稳定跑 115200。如果你必须把语音模块和 MCU 分开布置，尽量用双绞线，并且把波特率降到 9600——虽然慢一点，但可靠很多。语音识别本身的时间一般也就几百毫秒，串口传个几十字节的指令，9600 和 115200 的差别用户根本感知不到。
另外，车载串口线最好远离点火线圈、电动窗电机、大灯继电器这些强干扰源。这些器件工作时会在线束上感应出很高的尖峰电压，TTL 电平根本扛不住，轻则乱码，重则烧毁芯片。如果走线实在避不开，串口线上加共模电感或者用屏蔽双绞线会好很多。
4.3 串口玩出花：用 TTL 串口做在线升级和调试
虽然 TTL 串口在车载环境里有一堆毛病，但它有个好处是兼容性好、调试方便。两块语音模块都支持通过串口升级固件、导出识别日志，这个功能在量产前的调试阶段特别有用。
实际开发中，我习惯在语音模块的串口线上预留一个三针调试座，分别是 GND、TX、RX。上车出现识别率异常时，直接用一个 USB 转 TTL 小板怼上去，能看到识别器实时返回的置信度分数和命中的指令 ID。比如用户说“打开空调”识别成了“打开车窗”，通过日志能看到“打开”两个字的置信度很高，但“空调”和“车窗”的分数特别接近，这就说明是噪音环境下这两个词的声学特征被混淆了。对症下药去调词表或者调整麦克风位置，比瞎猜高效得多。
5. 补一条云端链路：ESP32 IDF 接入讯飞的实测感受
既然离线模块在高速场景下识别率掉得比较多，很多人会想：干脆上车联网，把语音扔到云端做识别，识别率不是直接起飞吗？我也用 ESP32 IDF 跑通了接入讯飞语音识别的全流程，这里把真实体验分享一下，帮大家判断这条路线适不适合自己。
5.1 什么时候适合把音频扔到云端
云端的识别率确实高，尤其是对长句、口语化表达、还有各种方言，但代价也很明显：
- 必须有网：车载环境网络信号不稳定，进隧道、下地库、跑偏远路段，信号一断，语音功能就彻底瘫了。这不是识别率的问题，是有没有的问题。
- 延迟不可控：离线识别从说完到出结果一般 300-500ms，云端走一圈至少 800ms 起步（采集->上传->识别->返回），网络差一点就奔着 2 秒去了。开车的时候等 2 秒才执行指令，体验非常糟糕。
- 流量成本：每次识别要传几十 KB 的音频上去，如果做成持续监听模式，一个月下来流量不是小数，而且很多车机方案商对流量资费有硬性要求。
所以我的判断是：云端方案适合做主驾之外的第二交互通道，比如副驾/后排乘客用自然语言跟车机闲聊查询，而主驾的常用控制指令（空调、车窗、音乐）必须留在本地。别把关键指令压在云上，这是我这次测试体会最深的一点。
5.2 ESP32 IDF 接入讯飞的链路拆解
接入流程拆开来说并不复杂，但每一步都有不少细节。我用的 ESP32-S3，带 16MB Flash 和 PSRAM，音频采集用的是板载模拟麦克风（或者走 I2S 外接数字麦克风）。
核心链路是四个节点：
| 步骤 | 动作 | 关键参数/注意点 |
|---|---|---|
| 1 | 配置 WiFi 连接 | 用 IDF 的 event handler 做断线重连，避免小车在移动中频繁掉线后无法恢复 |
| 2 | 录音并编码 | 采集 16kHz/16bit 单声道 PCM，写入环形缓冲区，把片段转成 OPUS 编码，数据量能压到原始 PCM 的 1/5 左右 |
| 3 | 鉴权与 WebSocket 上传 | 讯飞语音识别用的是 WebSocket 接口，需要拿到 AppID、APIKey、SecretKey，在 ESP32 端拼鉴权 URL，注意服务器时间戳要和本地对时一致，否则签名会挂 |
| 4 | 解析识别结果 | 服务端返回 JSON，解析出 text 字段，再走本地关键词匹配来触发指令 |
这里面最容易踩的坑是音频格式。讯飞接口要求采样率、位深、声道数必须匹配，ESP32 IDF 的 I2S 驱动配置如果差了哪怕是采样率的一点（比如实际是 16000 但配成了 15980），识别结果会间歇性出错，而且很难排查。
另一个坑跟内存有关，同样的效果，ESP32 IDF 在内存管理上比 Arduino 灵活，但如果把 WebSocket 收发缓冲区和音频缓冲区加起来设置不当，会频繁 OOM 重启，在车里跑段时间就自己重启了，特别揪心。我最后把音频环形缓冲区做成了动态调整，因为 ESP32 的 PSRAM 比内置 SRAM 大很多，把大缓冲都放到外部 PSRAM 里，问题就解决了。
5.3 混合架构才是车载语音的实用解
把 SU-32T/CI-03T 这种离线模块和 ESP32 云端识别组合起来用，才是兼顾体验和稳定性的做法。我目前采用的方案是：离线模块负责本地唤醒词和控制类指令，ESP32 负责网络请求、CAN 总线桥接和其他逻辑。当离线模块识别到“我想听点别的”这种比较模糊的指令时，就把音频流转发给 ESP32，由 ESP32 上传讯飞做更复杂的语义理解，然后返回结果给离线模块执行。
这个混合架构的好处是，即使云端断了，基础控制功能不会瘫痪，在线时又能获得更智能的交互体验。不过要注意，两块处理器之间通信也要走串口，所以前面说的 TTL 串口边界问题依旧存在，设计时必须统一考虑。
最后再分享一个实测小技巧：无论用哪块离线模块，供电都别直接从 ACC 线上拉，ACC 在启动瞬间掉压严重，会导致语音模块复位，正在导航的时候突然打断可太难受了。我习惯在语音模块前面加一个带使能脚的 DCDC，由 MCU 控制上电时序，启动完成之后再给语音模块上电，这样既稳定又好排查问题。选型不是看参数表挑最贵的，而是要把装车环境里那些“没说出口的需求”（抗噪、总线对接、串口边界）都列出来，再拿来套模块，这样才不会到了装车那天才发现这也不合适那也不合适。
