上个月有个做电动三轮车仪表的朋友找我说他们新项目要在仪表板上加语音播报采购那边拿到一份推荐清单头一行写的就是 WT588F02-8S-C让他确认能不能用。他给我打电话的第一句话是这芯片是不是只能放三句话第二句话是三语播报是不是要中英粤各来一遍。这两个问题其实代表了很多人的第一反应把三语理解成三种语言把语音芯片理解成一个只能按顺序播放的录音盒。真实情况是这里的三语指的是速度、电量、故障这三类信息的语音播报而 WT588F02-8S-C 这类离线语音芯片能做的事比放三句话要多得多。这篇就把这套方案从选型、硬件、播报逻辑、语料制作到量产测试整条链路捋一遍给正在做电动车仪表、共享出行终端、电动滑板车这类产品的同行一个可落地的参考。1. 仪表盘加了语音播报到底解决了骑行者哪几个真实麻烦1.1 强光下的仪表基本等于装饰件做过两轮车的人都知道一个尴尬事实正午太阳直射的时候LCD 屏的对比度会被环境光完全压过去骑行者低头看仪表的那零点几秒几乎读不到有效信息。而低头看屏这个动作本身在时速 25km/h 以上的时候就很危险按 25km/h 算低头 1 秒车就往前跑了将近 7 米。所以仪表信息从视觉通道分流一部分到听觉通道不是因为酷炫而是因为视觉通道在人车混行的场景里本来就已经被路面、后视镜、行人占满了。语音播报的价值在三个时刻最明显一是骑行中需要知道当前速度是否超限二是快到目的地时想确认还能不能跑回去三是车辆抖动、异响、突然降速的时候需要立刻知道是控制器报了故障还是单纯没电。这三件事对应下来正好就是速度、电量、故障这三类播报内容也是这套方案被反复提出来的根本原因。1.2 三类播报对应的是三种完全不同的触发逻辑很多人一开始会把这三类播报当成同一件事觉得都是读一个数然后播出来。实际做下来会发现它们的触发模型差别很大。速度播报是周期性 阈值型的。它不是每秒都播那样会把骑行者烦死通常是跨越某个速度阈值比如进入 20km/h、25km/h、30km/h 三个档时播一次或者在高速档位下每 30 秒提醒一次。阈值型播报的关键是迟滞也就是升档和降档要用不同的阈值否则速度在 24~26km/h 之间波动时会疯狂重复播报。电量播报是低频 事件型的。开机时播一次当前电量百分比骑行过程中只在跨过几个关键节点时播比如从 50% 掉到 30%、从 30% 掉到 15%。这两条线要分开设因为铅酸电池和锂电池的放电曲线完全不一样同样是电压 46V在铅酸上可能是 60% 电量在锂电上可能已经接近 20%。故障播报是即时 优先级最高的。控制器一旦通过串口或单线报出故障码语音必须在几百毫秒内响应而且要能打断正在播放的内容。这里最容易踩的坑是故障播报如果被速度播报挤在后面排队等播完速度再播故障黄花菜都凉了。1.3 为什么选离线语音芯片而不是蓝牙音箱那套方案有一派做法是在仪表里塞一个蓝牙模块语音靠手机 App 走 TTS 合成再通过蓝牙推过来。这个方案在演示阶段很漂亮落到量产就全是问题用户得装 App、得配对、得保持手机连着电池本身没电或者手机没电的时候语音功能直接归零更关键的是骑行场景对响应延迟极其敏感蓝牙链路加上手机 TTS 的合成延迟从控制器报故障到喇叭出声经常要一秒以上。离线语音芯片的思路是把音频数据直接存在芯片内部的 Flash 里MCU 通过一根线或者两根线给个地址芯片立刻从内部 Flash 取数据送到 PWM 输出。整条链路没有任何无线环节也没有操作系统调度响应时间稳定在毫秒级掉电也不会丢语料。代价是语料必须提前录制和烧录进去改词就得重新烧灵活性不如 TTS。但对于速度、电量、故障这三类高度固定的播报内容来说这个代价完全可以接受——毕竟电量百分之三十这种话一年也不会改一次。2. WT588F02-8S-C 这颗 SOP-8 封装的小芯片能扛多少活2.1 先把三语这个词的歧义说清楚前面提到的那个误会值得单独讲一段因为选型阶段如果理解偏了Flash 容量会算错后面全盘皆输。如果三语真的指普通话、英语、粤语三种语言那所有语料要乘以三包括数字 0 到 9、十、百、千、百分之、剩余、故障、超速、请充电这些词元一套下来是相当可观的容量。而这里说的三语是三类播报内容语料只需要一套普通话就够。我建议在项目立项文档里就把这个定义写死别用三语这种容易歧义的简称直接写成速度播报 / 电量播报 / 故障播报三路。真要做多语言版本的时候正确的做法也是在同系列里选 Flash 更大的型号或者把语料按普通话版和英文版分成两个烧录版本按订单分别出货而不是硬塞进同一颗芯片再想办法压缩采样率。2.2 封装小、外围少这是它被仪表板接受的主要原因仪表板的空间是被成本压到极限的。一块常规两轮车仪表的 PCB 面积本来就不大上面已经挤了数码管或 LCD 驱动、MCU、DC-DC、按键、蜂鸣器、接插件。语音芯片如果用 SOP-8 这种封装加上必要的去耦电容和一路 PWM 输出占的面积非常小而且不需要额外的 Flash、不需要晶振这类芯片通常内置振荡外围元件可以精简到一颗电容一颗电阻的量级。这点对结构件的影响很直接不需要为语音功能改模具直接在现有主板上加一块区域就能塞进去。我在一个共享滑板车项目上见过相反的例子团队一开始选了带独立音频 DAC 的方案结果因为要加功放、加滤波、加屏蔽罩PCB 大了将近三分之一最后结构件重新开模工期拖了一个多月。所以选型阶段不要只看芯片单价要把外围面积和结构件改动量一起算进去。2.3 控制方式的选择按键触发、一线串口、两线串口这类芯片通常提供几种控制方式各有各的适用面控制方式接线适用场景注意点按键直接触发每个按键对应一段语音固定提示音、开机音、倒车提示按键数量受引脚数限制只适合少量固定语料一线串口1 根数据线 地仪表主控控制引脚紧张时首选时序对延时敏感中断里发容易出错两线串口TX/RX 地语料多、需要频繁切换地址波特率和帧格式必须与手册一致电动车仪表的典型做法是按键 串口混用开机音和几个固定提示走按键触发速度、电量、故障的播报走串口地址。这样即使主控 MCU 死机了开机提示音这类基础功能还能靠按键兜底用户体验不会彻底崩掉。在线路上我强烈建议给数据线串一颗小阻值电阻常见 100Ω 到 1kΩ 之间并且把走线尽量走内层。电机和控制器的线束在仪表附近走的时候耦合过来的尖峰很容易在数据线上打出误码串一颗电阻加对地小电容能挡掉相当一部分。2.4 3.3V 这件事为什么它总被单独提出来讨论最近搜到的一个热词是语音芯片 3.3V 输出这个词背后其实是两个不同的问题很多人混在一起了。第一个问题是供电电压。这类芯片通常支持一个比较宽的工作电压范围3.3V 或者 5V 供电都能跑所以仪表主控如果是 3.3V 系统可以直接用同一路 3.3V 给语音芯片供电不需要额外的 LDO。但要注意芯片工作电压范围宽不代表音质在任何电压下都一样PWM 输出的驱动能力和音量跟供电电压是正相关的3.3V 供电时能推出来的响度比 5V 时要低一截。如果喇叭是 8Ω/0.5W 这种3.3V 供电下音量可能偏小尤其是装在车头风噪大的位置用户会听不清。第二个问题是IO 电平。仪表的 MCU 很多是 3.3V 的语音芯片如果也在 3.3V 下工作两边的逻辑电平天然匹配数据线直连就行不需要电平转换。但如果语音芯片用 5V 供电MCU 是 3.3V就会出现 MCU 输出高电平低于语音芯片识别门限的情况通信会变得很不稳定间歇性丢指令。这时候要么把语音芯片也改成 3.3V 供电要么加电平转换不要指望一般都能识别这种玄学。还有第三个容易被忽略的点如果芯片有可用的输出引脚用来驱动外设或者给 MCU 一个状态指示那个输出的驱动能力通常很弱只能当信号用不能直接驱动 LED 或者继电器。我见过有人拿它去驱动一个蜂鸣器结果声音小得几乎听不见还怀疑是芯片坏了。3. 硬件设计把芯片塞进一块已经被成本和空间挤满的仪表板3.1 从整车电压到芯片供电的那条链路两轮车、三轮车的电池组电压通常是 48V、60V 或者 72V仪表板内部一般先有一级 DC-DC 把电压降到 12V 或者 5V再往下分。语音芯片的供电可以直接从这一级取也可以在仪表内部再做一次 3.3V LDO。这里有个很实际的取舍如果直接从 12V 用 LDO 降到 3.3V压差 8.7V芯片工作电流按几十毫安算LDO 上的功耗就是几百毫瓦封装小一点的 LDO 会明显发烫夏天暴晒下仪表内部温度本来就高很容易触发热保护。所以我的建议是分级降压DC-DC 先降到 5V再从 5V 用 LDO 降到 3.3V。多一颗 LDO 的成本很低但整机的热设计会舒服很多。另外要注意供电的上电次序。如果语音芯片和 MCU 共用一路 3.3V上电时两者同时启动问题不大但如果 MCU 先启动、语音芯片因为内部 Flash 初始化需要更长时间才准备好MCU 一开始就发地址指令芯片是收不到的。稳妥的做法是在 MCU 初始化完成后延时一两百毫秒再发第一条指令或者在硬件上给语音芯片的供电加一个小的 RC 延时。3.2 PWM 输出接喇叭的两个致命细节这类芯片驱动喇叭一般是 PWM 差分输出也就是有两个输出脚。这里有两个坑几乎每个新手都会踩一次。第一个坑喇叭不能有一端接地。PWM 差分输出是桥接式的两个脚都要接到喇叭两端如果把其中一端接到 GND轻则声音极小、重则完全没有声音甚至可能因为输出短路而损坏芯片。有些工程师习惯了单端输出的接法看到两个输出脚就本能地把负极接地这个错误查起来很费时间因为芯片不会冒烟只是声音不对。第二个坑输出是方波不是模拟波形。有些便宜的方案为了省滤波电容直接让 PWM 差分输出推喇叭靠喇叭自身的电感和人耳的听觉积分来还原声音。这个做法在播放语音时勉强能听但会有明显的电子音感和高频毛刺长时间听会很不舒服。加一个简单的 LC 或者 RC 低通滤波成本增加很少听感提升很明显。我在一个项目上做过对比同一套语料加滤波前后用同一只 8Ω/1W 喇叭播放加滤波之后人声的清晰度提升非常直观尤其是百分之三十这种数字连读之前是糊在一起的。3.3 喇叭的选型和安装位置比芯片本身更影响最终效果先给一个参考量级这类芯片在 3.3V 供电下直接推 8Ω/0.5W 的小喇叭比较合适想要更响就得加功放。喇叭参数上我实测下来 8Ω 比 4Ω 更稳因为 4Ω 负载下输出电流接近翻倍芯片发热明显长时播报时稳定性下降。安装位置是个纯经验问题。喇叭装在仪表外壳里如果外壳是封闭的塑料壳声音会被闷住正确做法是在喇叭背面开一个小的泄压孔或者让喇叭和外壳之间留一点空腔。另外喇叭不能贴在 PCB 上要靠结构件固定并留出减振垫否则车子过减速带的时候喇叭跟着板子一起振会产生很明显的杂音用户会以为是喇叭质量差其实是固定方式的问题。3.4 电机和控制器才是这套方案最大的干扰源仪表板上的语音芯片最坏的邻居就是旁边的电机线束和控制器。电机相线里流的是 PWM 方波大电流换相瞬间的 dv/dt 很高辐射和传导骚扰都会耦合到仪表板上。我在项目上采用的组合拳是语音芯片的供电脚就近放一颗 0.1μF 加一颗 10μF 的电容数据线串电阻加对地小电容如果空间允许在喇叭线上并一颗小的磁珠。另外布局上语音芯片和喇叭走线要尽量远离 DC-DC 的电感DC-DC 的开关频率通常在几百 kHz虽然听不见但它会在音频链路上形成底噪。还有个成本更低的办法把喇叭线做成双绞线。这个动作不花一分钱但对抑制共模干扰很有效。4. 三路播报的逻辑实现速度、电量、故障怎么触发才不难听4.1 速度播报的核心是迟滞和最小间隔速度播报的技术难点不在语音而在触发策略。我见过的最糟糕实现是每检测到一次速度变化就发一条指令结果骑行者在加速过程中喇叭里您的车速、您的车速、您的车速叠在一起完全听不清。正确的做法是两级门限加最小间隔。举个例子假设分三个档低于 20km/h 不播20 到 25km/h 之间播请注意车速25km/h 以上播已超速请减速。那么进入请注意车速档的门限是速度上升到 20km/h退出这个档的门限要设成 18km/h进入超速档的门限是 25km/h退出设成 23km/h。这样在门限附近来回波动时不会反复触发。最小间隔则是硬性的时间保护比如同一档位的播报两次之间至少间隔 30 秒。这个值不能设太小否则语音会变成噪音也不能设太大否则用户已经超速一分钟了才听到提醒失去了意义。我一般会把它做成可配置的不同车型、不同市场要求不一样。4.2 电量播报从 ADC 采样到百分之多少之间的那几道坎电量播报看起来简单实际上是三路里最容易翻车的一路。从电压到百分比中间要过好几道坎。第一道坎是采样精度。常见的做法是用两颗电阻分压把电池电压降到 ADC 量程内。这里要注意分压电阻的精度和温漂如果用的是普通的 1% 电阻在 -10℃ 到 50℃ 的温度区间内分压比的变化足以让电量读数漂移好几个百分点。要求高的项目会用 0.5% 甚至 0.1% 的精密电阻成本增加很小。第二道坎是放电曲线的非线性。铅酸电池和锂电池的曲线差别巨大铅酸的电压在放电中后段下降得很平缓锂电在 3.7V 附近有一个很长平台期然后迅速掉下去。如果用线性映射锂电池在平台期会长时间显示 40% 左右然后突然从 40% 掉到 0%用户会觉得电量显示是假的。解决办法是查表法把电压分区间段每段对应一个百分比按电池的实际放电曲线标定。这个标定工作最好拿真实电池在测功机上跑一遍不要照抄网上的曲线。第三道坎是静置电压和负载电压的区别。骑行中的端电压因为内阻压降会比静置时低。如果直接用骑行时的电压查表电量会偏低。我通常的做法是做一个简单的负载补偿按当前放电电流乘以内阻估算的压降把电压补回去再查表。内阻值不用很准粗略补偿就能让电量显示平滑很多。4.3 故障播报控制器故障码到语音地址的映射表故障播报是这三路里唯一需要和控制器打交道的需要先在 MCU 侧把控制器上报的故障码解析出来再翻译成语音地址。下面这张表是我在一个项目上用的映射关系实际项目里要根据自己的控制器协议调整控制器故障码故障含义语音内容语音地址优先级0x01转把故障转把异常请检查0x21高0x02刹把故障刹车信号异常0x22高0x03电机霍尔故障电机霍尔异常请检修0x23高0x04控制器过流控制器过流保护0x24高0x05电池欠压电量不足请及时充电0x25中0x06电机缺相电机缺相请停止行驶0x26最高0x07超温保护控制器温度过高请稍后使用0x27中表里的优先级这一列很关键它是后面打断机制的依据。电机缺相这种情况必须打断所有正在播放的内容立刻播出来而电量不足可以在当前语音播完之后再播。映射表在代码里建议用数组或者 switch 实现不要写成一大串 if-else方便后续增删故障项。typedef struct { uint8_t code; /* 控制器上报的故障码 */ uint8_t voice_addr; /* 对应的语音地址 */ uint8_t priority; /* 优先级数值越大越急 */ } fault_map_t; static const fault_map_t fault_table[] { {0x01, 0x21, 2}, {0x02, 0x22, 2}, {0x03, 0x23, 2}, {0x04, 0x24, 2}, {0x05, 0x25, 1}, {0x06, 0x26, 3}, {0x07, 0x27, 1}, }; uint8_t find_voice_addr(uint8_t code) { for (uint8_t i 0; i sizeof(fault_table)/sizeof(fault_table[0]); i) { if (fault_table[i].code code) { return fault_table[i].voice_addr; } } return 0; /* 0 表示无匹配不播报 */ }4.4 三路同时来的时候谁先播一个简单的播报仲裁器三路播报如果不做仲裁就会出现故障来了但在播电量这种尴尬。我的做法是让 MCU 维护一个小的播报队列队列长度为 2 到 3 就够同时维护一个当前播放状态的标志。状态标志的判断方式有两种一是查询语音芯片的忙状态输出脚二是用软件计时播报开始时记录时间戳按语料长度估算结束时间。硬件忙脚更可靠但会多占一个 MCU 引脚软件计时省引脚但语料长度一变就得改参数。我一般优先用忙脚实在没引脚了再用软件计时。仲裁规则很简单高优先级的新事件直接打断低优先级的正在播放内容同优先级的排队低优先级的如果队列已满就丢弃。丢弃是必须的因为速度提醒这类信息时效性很强过期的提醒没有播的必要反而会占用喇叭资源。这一点很多项目没做结果队列越堆越长用户听到的永远是几十秒前的旧信息。5. 语音文件制作和烧录语料切分是最容易被低估的一块活5.1 按词元切分而不是整句录音这是整个语音方案里最影响体验的一环。如果按照整句录比如当前电量百分之三十整句录一段那么从 0% 到 100% 至少要录 101 段再加上当前电量百分之这种前缀容量浪费得离谱。正确做法是按词元切分数字 0 到 9 各一段十、百各一段百分之一段当前电量一段。这样当前电量百分之三十就变成 前缀 三 十 四段拼接。看起来要多发几次地址但容量节省是数量级的。切割上有个技巧每个词元的前后要各留一点点静音但不能留太多。留太少拼接的时候两个音节会粘在一起留太多播报听起来一顿一顿的。我一般让每个词元的头尾各留 20 到 50 毫秒的静音具体数值按语速调整。还有一个细节数字的录音要注意声调。单独录的三和连读时的三在语调上会有差异如果全部用单字录音拼接整句话听起来会有点像机器人在念数字。要缓解这个问题可以让配音员在录数字的时候带上统一的语调起势或者在后期稍微做一点淡入淡出。5.2 采样率和容量的平衡采样率直接决定音质和容量。常见的档位是 6kHz、8kHz、16kHz 这几种语音只要求听得清而不追求好听的时候6kHz 到 8kHz 就够用容量小、烧录快如果要做得有质感一点比如开机音是一段带背景音乐的欢迎语那 16kHz 甚至更高会更合适。算容量的时候别只看单段时长要按总秒数 × 采样率 × 位宽 ÷ 8估算再留 20% 到 30% 的余量。留余量是因为后续一定会加语料——请佩戴头盔、请勿载人、已进入限速区域这类提示产品迭代过程中只会越来越多。我见过一个项目第一版正好把 Flash 塞满第二版要加两句提示音结果只能换更大容量的型号PCB 和软件都得改。5.3 烧录流程和那些写不进去的原因烧录一般是通过专用的下载器和上位机软件完成把音频文件按顺序导入、生成地址表、然后写入芯片内部 Flash。这个过程里有几个常见的失败原因地址不连续。有些上位机软件对地址分配比较敏感如果中间有空的地址可能出现某些段播不出来。建议语料按顺序编号中间不要留空。音频格式不匹配。软件通常要求特定的采样率、单声道、特定的位宽如果导入的是双声道或者 44.1kHz 的文件要么被拒绝要么被自动重采样重采样后的音质可能不理想。最好在导入前用工具统一转换好。写入中途断电或接触不良。这类失败往往表现为部分地址能播、部分不能排查起来很烦。建议烧录工位上配稳压电源别用劣质 USB 口供电并且每批抽检几个地址做播放验证。另外如果产品后期可能要换语料选型阶段最好确认一下芯片是否支持通过 MCU 在线更新语音内容。能在线更新的话产线或者售后可以通过仪表接口刷新语料不用拆机这在多语言版本、多地区版本出货的时候价值很大。6. 从打样到小批量我们踩过的那些坑6.1 播报开头总是吃掉半个字这是最典型的一个现象喇叭里出来的第一句话开头零点几秒是不完整的听起来像电量百分之三十变成了量百分之三十。原因有两类。一类是发送指令和芯片真正开始播放之间有启动时间功放或者喇叭在这段时间还没进入状态等真正出声的时候音频已经播了一段。解决办法是在每段语料的开头多留一点静音一般 50 到 100 毫秒就能解决。另一类是供电问题。芯片从内部 Flash 读数据、PWM 开始输出的瞬间会有电流冲击如果供电的 LDO 响应慢或者去耦电容不够电压会瞬间跌一下导致开头部分失真或者被截断。这种情况下加大去耦电容或者换响应更快的 LDO 就能明显改善。排查的时候可以用一个简单办法分辨把同一段语料连续播两遍。如果第一遍吃字、第二遍正常那基本是供电或者启动的问题如果两遍都吃字那就是语料本身的静音留得不够。6.2 电机一启动就误播报这个问题的现象很迷惑人车静止的时候一切正常电机一启动喇叭就自己开始播报内容还是随机的。根因是电磁干扰在数据线上打出了误码芯片把噪声当成了指令。定位方法是把数据线从 MCU 上断开看现象是否消失。如果消失说明确实是数据线上的干扰如果还在那就要怀疑供电被干扰了。解决的组合拳前面提过数据线串电阻加对地小电容、走线远离电机线束、必要时把数据线改成带屏蔽的双绞线。有一个更彻底但成本更高的办法是把语音芯片和 MCU 之间的通信加一层校验比如每条指令发两遍芯片侧用软件过滤或者干脆把语音芯片挪到离 MCU 最近的位置缩短受干扰的走线长度。这里要提醒一句不要为了图省事把数据线的上拉电阻省掉。很多这类芯片的数据线是开漏或者需要上拉的没有上拉的时候空闲状态电平不确定抗干扰能力会差很多。6.3 冷启动第一次不发声第二次就好了冬天做低温测试的时候遇到过一次-10℃ 环境下静置一夜第二天上电第一次不发声关机再开就正常了。这类现象一般指向两个方向。一是芯片内部 Flash 在低温下的读取时序需要更长的准备时间MCU 发第一条指令太早芯片还没准备好。解决办法是在初始化后加一个上电延时并且在低温环境下实测这个延时要留多少余量。二是电解电容在低温下容量衰减、等效串联电阻变大导致供电纹波变大芯片工作不正常。如果仪表板上用了电解电容做储能不妨在语音芯片的供电脚旁边再并联一颗容量合适的陶瓷电容陶瓷电容的低温特性比电解好得多。这个问题在北方市场销售的车型上必须做验证不能只在常温实验室里测。6.4 语料听久了很烦音量、语速、频次三个旋钮功能都通了之后还有一个纯体验层面的问题用户会不会嫌它烦。我总结下来有三个可调的旋钮。音量上语音播报的音量应该比蜂鸣器提示音略低一点。蜂鸣器是短促的提醒音量大一点没问题语音是连续的人声音量太大的时候在安静小区里会显得很吵用户会主动想关掉。语速上数字播报要慢一点提示语可以快一点。电量百分之三十这种信息密度高的语速快了就听不清请注意车速这种熟语快一点反而更自然。频次上这是最需要克制的。我的经验是速度提醒的间隔不要短于 30 秒电量提醒一天不要超过几次故障提醒该出的必须出。宁可少说也不要让用户觉得这车一直在念叨。7. 成本、产线和你以后一定会遇到的两件事7.1 BOM 上的增减清单加一个语音播报功能BOM 上的变化其实很小但也不是只有一颗芯片。列出来大概是这样的项目变化说明语音芯片新增核心器件喇叭新增8Ω/0.5W 到 1W带引线和接插件去耦电容新增0.1μF 10μF 各一颗数据线串阻新增100Ω 到 1kΩLDO可能新增从 5V 降到 3.3V 时增加结构件可能改动喇叭固定位、泄压孔MCU 引脚占用至少 1 个输出若用忙脚则 2 个真正容易被低估的是后两项。结构件一旦要改模成本和周期都会上去所以我在项目早期就会把喇叭的位置和固定方式先定下来哪怕电路还没最终确定。另外 MCU 的引脚规划要提前做别等到软件写完才发现没有空闲引脚。7.2 产线上的烧录和测试治具语音芯片的语料是在烧录环节写进去的所以产线上要么用专门的烧录工位先烧后贴要么在整机测试环节通过仪表接口烧。两种方式各有取舍先烧后贴的话芯片一旦烧错版本就得拆下来重烧但产线节拍快整机烧录则灵活可以按订单烧不同版本但对测试工装的通信可靠性要求高。不管用哪种方式我都建议在产线终检里加一个三路播报功能自检让测试工装发三条指令分别触发速度、电量、故障播报用麦克风采样或者人工听一下。这一步不花什么时间但能把喇叭没接好、芯片没烧进去、地址错位这类问题拦在出厂之前。我见过因为没做这一步一批货出去之后客户反馈喇叭不响最后全部召回返工损失远超测试工装的成本。7.3 语料版本管理是后面一定会疼的地方最后说一件跟技术关系不大、但一定会踩的事语料版本管理。当产品线扩展出不同车型、不同地区、不同语言版本的时候语料会分裂成好几个版本如果只靠文件名区分很快就会乱。我的做法是给每一版语料编一个版本号版本号同时写进软件代码和烧录记录产线烧录的时候必须核对版本号。地址表也建议统一维护在一份文档里任何新增语料都先分配地址再录音避免出现录了音但没地址或者地址冲突的情况。这个习惯一开始会显得有点繁琐等到第三个车型要复用第一版的语料时你会庆幸当初做了这件事。我个人在实际操作中的体会是这类离线语音方案的技术门槛并不高真正决定项目成败的是那些琐碎的地方喇叭装在哪、数据线怎么走、语料怎么切、版本怎么管。芯片选对了只是入门把这四件事处理好才是让用户觉得这车的语音挺好用的关键。