语音交互这件事我从早期用专用语音芯片做离线词条识别到后来跑云端ASR做自然语言对话再到最近折腾端侧小模型做本地唤醒前后踩过的坑能写满一个笔记本。很多人觉得语音智能硬件是个高门槛的活要么得懂声学要么得会训练模型其实真上手之后你会发现核心难点根本不在算法本身而在于怎么把一条完整的语音链路塞进一颗算力有限、内存有限、还要求低功耗的MCU里同时保证用户体验不崩。这篇内容就是把我这些年做语音智能硬件的完整思路拆开从需求定义、方案选型、链路搭建、代码落地到调试避坑一步步讲清楚。不管你是刚接触嵌入式语音的新手还是已经做过几款产品想优化体验的老手都能从中找到可以直接抄作业的部分。1. 先想清楚你的硬件到底要听什么1.1 语音交互的三种典型形态与适用边界做语音硬件第一步不是选芯片而是定义交互形态。我见过太多项目一上来就说我要做个语音助手结果做到一半发现需求根本不需要那么复杂。语音交互大致分三类第一类是命令词识别也就是常说的离线词条。用户说打开灯光调高温度这种固定指令设备只需要识别几十到几百条预设词条。这类方案用专用语音识别芯片就能搞定成本低、功耗低、响应快不需要联网。典型场景是智能开关、小家电、玩具。第二类是语音转文本加语义理解设备把用户说的话转成文字再送到云端或本地做NLU自然语言理解然后执行对应动作。这类方案灵活度高用户可以用自然语言表达但需要联网、需要算力、延迟也更高。典型场景是智能音箱、语音助手。第三类是实时语音对话设备不仅要听懂还要用语音回复形成双向对话。这对ASR、NLU、TTS语音合成和对话管理都有要求链路最长调试最复杂。典型场景是陪伴机器人、智能客服终端。选哪种形态取决于你的产品定位、成本预算和用户场景。我的经验是能用命令词解决的绝不上云端ASR。因为每增加一个环节就多一个出错的可能多一份功耗和成本。1.2 从用户场景反推技术指标定义完形态之后你需要把用户场景翻译成技术指标。这一步很多人会跳过直接看芯片参数结果选出来的方案跟实际需求对不上。我一般会问自己几个问题用户在多远的距离说话这决定了麦克风的灵敏度和是否需要阵列。环境噪声有多大这决定了是否需要降噪算法和回声消除。响应时间要求多快命令词识别一般要求300ms以内云端ASR可以放宽到1秒。设备是电池供电还是市电这直接决定功耗预算。是否需要离线工作如果需要就必须把模型跑在本地。举个例子做一个电池供电的语音遥控器用户距离1米以内环境相对安静要求按键唤醒后1秒内响应。那么技术指标就是单麦克风、近场识别、唤醒词加命令词两级结构、功耗控制在毫安级。这些指标确定之后选型范围就缩小了很多。1.3 常见误区把识别率当成唯一指标很多新手一上来就盯着识别率看觉得识别率越高越好。实际上在真实产品里误唤醒率和响应延迟往往比识别率更影响体验。我做过一个项目识别率做到了95%但误唤醒率太高用户看电视的时候设备经常自己触发最后不得不把唤醒阈值调高结果正常唤醒又变得不灵敏。所以定义需求的时候一定要把这三个指标放在一起看识别率、误唤醒率、响应延迟。它们之间是互相制约的调高灵敏度会提高识别率但也会提高误唤醒率降低延迟可能需要牺牲一些精度。找到平衡点才是产品化的关键。2. 语音链路的核心模块拆解2.1 从声音到动作一条完整链路的六个环节一条完整的语音交互链路从用户开口到设备执行动作中间要经过六个环节拾音麦克风把声波转换成模拟电信号。预处理包括放大、滤波、ADC采样把模拟信号变成数字信号。唤醒检测特定唤醒词把设备从低功耗状态激活。识别把语音信号转成文字或命令。理解解析文字的含义映射到具体动作。执行驱动硬件执行动作并可能给出语音或灯光反馈。每个环节都有对应的技术方案和选型考量。下面我逐个拆解。2.2 拾音与预处理最容易被忽视的地基很多人把精力全放在识别算法上结果麦克风选型一塌糊涂后面怎么调都调不好。拾音环节的核心是信噪比也就是用户声音和环境噪声的比例。信噪比不够再好的算法也救不回来。麦克风选型主要看几个参数灵敏度、信噪比、指向性、尺寸。驻极体麦克风便宜但一致性差MEMS麦克风贵一些但一致性好、适合量产。如果产品要求远场识别就需要麦克风阵列常见的是双麦或四麦环形阵列配合波束成形算法来增强目标方向的声音。预处理环节我一般会加一个AGC自动增益控制因为用户说话的音量差异很大有人轻声细语有人中气十足。AGC可以自动调整增益让后续算法拿到的信号幅度在一个合理范围内。另外高通滤波也很重要可以滤掉低频的环境噪声比如空调声、风扇声。注意麦克风的布局对拾音效果影响极大。麦克风开孔位置要远离扬声器、电机、风扇等噪声源否则再好的算法也白搭。我踩过的一个坑是麦克风开孔太靠近喇叭结果播放语音的时候自己把自己唤醒后来加了回声消除才解决。2.3 唤醒环节低功耗与高灵敏的博弈唤醒是整个链路里最讲究功耗的环节因为设备大部分时间都处于待机状态只有唤醒词检测模块一直在运行。唤醒方案主要有两种一种是基于专用语音芯片的硬件唤醒比如某些低功耗语音识别芯片内置唤醒词检测功能功耗可以做到毫安级甚至微安级。这类方案适合电池供电的产品。另一种是基于软件算法的唤醒在MCU或AP上跑一个轻量级的唤醒词检测模型。这类方案灵活度高可以自己定义唤醒词但功耗相对较高。唤醒环节的核心指标是唤醒率和误唤醒率。唤醒率是指用户说了唤醒词设备能正确响应的比例误唤醒率是指设备在没有唤醒词的情况下自己触发的频率。这两个指标是矛盾的调高灵敏度会提高唤醒率但也会提高误唤醒率。我的经验是误唤醒率比唤醒率更重要。因为用户说唤醒词没反应最多再喊一遍但设备半夜自己触发用户会直接退货。一般消费类产品误唤醒率控制在24小时不超过1次比较合理。2.4 识别与理解离线与云端的取舍识别环节是把语音转成文字或命令。离线识别一般用命令词匹配把用户的语音特征和预设词条的特征做比对匹配上了就执行对应动作。云端识别则是把音频上传到服务器用大模型做识别精度更高但需要联网。离线识别的优势是响应快、不依赖网络、隐私好劣势是词条数量有限、无法处理自然语言。云端识别的优势是灵活、精度高劣势是延迟高、需要网络、有隐私顾虑。我的建议是如果产品只需要固定指令优先用离线识别。如果产品需要自然语言交互再考虑云端。也可以做混合方案常用指令离线识别复杂指令走云端。理解环节是把识别结果映射到具体动作。如果是命令词识别这一步很简单直接查表就行。如果是自然语言就需要NLU模块把用户的话解析成意图和槽位。比如把客厅的灯调暗一点意图是调灯光槽位是位置客厅和动作调暗。2.5 反馈与执行别让用户觉得设备死了执行环节是驱动硬件动作这个不用多说。我想重点说的是反馈。很多产品识别完了直接执行没有任何反馈用户不知道设备有没有听到、有没有听懂。这种体验很糟糕。反馈可以是声音比如好的已打开也可以是灯光比如LED闪烁还可以是震动。我的经验是至少要有一种即时反馈让用户知道设备收到了指令。如果识别失败也要有反馈比如没听清请再说一遍而不是默默无闻。3. 硬件选型从芯片到外围的完整清单3.1 主控芯片怎么选算力、内存、功耗的三角平衡主控芯片是语音硬件的核心选型主要看三个维度算力、内存、功耗。这三个维度往往是互相制约的算力越强功耗越高内存越大成本越高。如果只做命令词识别一颗带DSP的MCU就够了比如某些Cortex-M4或M5内核的芯片主频100MHz以上带浮点运算单元内存128KB以上。这类芯片成本低、功耗低适合量产。如果要做云端ASR主控只需要负责音频采集和网络传输算力要求不高但需要WiFi或4G模块。这类方案可以用Cortex-M7或低端AP。如果要做本地自然语言理解或实时对话就需要更强的算力可能要上Cortex-A系列的应用处理器甚至带NPU的芯片。我一般会列一个表把候选芯片的算力、内存、功耗、成本、开发难度都列出来然后根据产品需求打分。下面是一个简化的对比芯片类型典型算力内存功耗适用场景开发难度Cortex-M4/M5 MCU100-200MHz128-512KB低命令词识别中Cortex-M7 MCU300-600MHz512KB-1MB中离线识别网络中高Cortex-A AP1GHz以上256MB以上高云端ASRNLU高带NPU的AP1GHz以上NPU512MB以上高本地AI对话很高3.2 麦克风与音频前端信噪比决定上限麦克风选型我前面提过这里补充一些细节。MEMS麦克风的一致性比驻极体好很多量产的时候不需要逐个校准强烈建议用MEMS。灵敏度一般选-26dBFS到-38dBFS之间信噪比选60dB以上。如果做远场识别需要麦克风阵列。双麦阵列可以做简单的波束成形四麦环形阵列可以做360度拾音。阵列的间距和布局要根据产品形态来定一般间距在3-5厘米比较合适。音频前端芯片Codec也很重要负责ADC/DAC转换和音频处理。选型的时候要看采样率、信噪比、是否内置AGC和降噪。有些Codec内置了硬件降噪可以减轻主控的负担。3.3 存储与网络别让flash和WiFi拖后腿存储方面离线识别需要存模型和词条一般几MB的flash就够了。云端识别需要缓存音频可能需要几十MB。如果要做本地TTS还需要存语音包可能几十到几百MB。网络方面WiFi模块选型要看功耗和稳定性。有些WiFi模块在低功耗模式下会断连唤醒后重新连接需要几秒这个延迟用户能明显感觉到。建议选支持快速重连的模块或者在待机时保持长连接。提示WiFi和语音模块共用天线的时候要注意干扰问题。我遇到过一次WiFi传输的时候语音识别率骤降后来发现是天线布局不合理WiFi信号串到了音频链路上。解决办法是把两个天线拉开距离或者加屏蔽。3.4 电源管理电池供电产品的生死线电池供电的产品电源管理是重中之重。语音链路的功耗主要来自三部分麦克风偏置、Codec、主控。待机的时候只有唤醒模块在跑功耗要控制在微安级。唤醒之后主控全速运行功耗可能到几十毫安。我的做法是分三级电源管理深度睡眠只保留唤醒模块浅睡眠保留音频前端全速运行所有模块开启。根据用户交互的状态动态切换。另外DCDC转换效率要高LDO的静态电流要小这些细节都会影响续航。4. 软件实现从驱动到算法的落地路径4.1 音频采集驱动的关键配置音频采集驱动是软件链路的第一环配置不对后面全白费。关键参数有三个采样率、位深、缓冲区大小。采样率一般用16kHz这是语音识别的标准采样率。如果要做音乐播放或者高保真录音可以用44.1kHz或48kHz但语音识别用16kHz就够了还能省算力和存储。位深一般用16bit够用了。32bit精度更高但没必要反而增加传输和存储负担。缓冲区大小很关键。太小会丢帧太大会增加延迟。我一般用双缓冲或者环形缓冲每个缓冲区20-30ms的音频数据。这样既能保证实时性又不会频繁中断。代码层面以I2S接口的MEMS麦克风为例初始化流程大概是// I2S初始化配置示例 void audio_init(void) { // 配置I2S时钟16kHz采样率 i2s_config.sample_rate 16000; i2s_config.bits_per_sample 16; i2s_config.channels 1; i2s_config.dma_buf_size 320; // 20ms 16kHz // 初始化I2S外设 i2s_init(i2s_config); // 配置DMA双缓冲模式 dma_config.buf0 buf_a; dma_config.buf1 buf_b; dma_config.callback audio_callback; dma_init(dma_config); // 启动采集 i2s_start(); }这个配置的意思是每20毫秒采集320个采样点DMA自动搬运到缓冲区搬满一个缓冲区触发一次回调。回调里把数据送到后续的预处理和识别模块。4.2 预处理算法的工程实现预处理主要包括AGC、滤波和降噪。AGC的实现比较简单就是计算当前帧的RMS能量和目标能量比较动态调整增益。注意增益调整要平滑不能突变否则会产生可听见的呼吸效应。滤波一般用高通滤波截止频率80-100Hz滤掉低频噪声。可以用简单的IIR滤波器实现计算量小。降噪就复杂一些常见的有谱减法、维纳滤波、深度学习降噪。谱减法计算量小但效果一般深度学习降噪效果好但需要算力。如果主控算力有限建议用谱减法或者不做降噪靠麦克风阵列的波束成形来提升信噪比。// 简单的AGC实现示例 float agc_process(float *buf, int len) { float rms 0; for (int i 0; i len; i) { rms buf[i] * buf[i]; } rms sqrtf(rms / len); float target_rms 0.1f; // 目标能量 float gain target_rms / (rms 1e-6f); // 限制增益范围避免过度放大 if (gain 10.0f) gain 10.0f; if (gain 0.1f) gain 0.1f; // 平滑增益变化 static float smooth_gain 1.0f; smooth_gain smooth_gain * 0.9f gain * 0.1f; for (int i 0; i len; i) { buf[i] * smooth_gain; } return smooth_gain; }这段代码的核心是计算当前帧的能量然后算出一个增益值再平滑地应用到音频数据上。平滑系数0.9和0.1是经验值可以根据实际效果调整。4.3 唤醒词检测的两种实现路径唤醒词检测有两种实现路径基于模板匹配和基于神经网络。模板匹配的思路是预先录几遍唤醒词提取特征比如MFCC存成模板。运行时提取当前音频的特征和模板做比对相似度超过阈值就触发。这种方案实现简单但鲁棒性差不同人说同一个唤醒词或者同一个人不同语速特征差异都很大。神经网络方案是训练一个小型的唤醒词检测模型输入是音频特征输出是唤醒词的概率。这种方案鲁棒性好但需要训练数据和算力。现在有很多开源的唤醒词检测框架可以自己训练自定义唤醒词。如果主控算力有限可以用专用语音芯片做唤醒主控只负责后续处理。如果主控算力够可以跑轻量级神经网络比如DS-CNN或者TC-ResNet模型大小可以压到几十KB。4.4 命令词识别与云端ASR的对接命令词识别的实现和唤醒词类似只是词条更多。可以用同样的模板匹配或神经网络方案。词条数量少的时候几十条模板匹配够用词条多的时候几百条以上建议用神经网络。云端ASR的对接就简单很多主要是网络通信和音频编码。音频一般用PCM或者Opus编码Opus压缩率高适合网络传输。上传音频之后等待服务器返回识别结果然后解析JSON拿到文字。// 云端ASR请求示例伪代码 void asr_request(char *audio_data, int len) { // 编码音频 char *encoded opus_encode(audio_data, len); // 构造HTTP请求 http_request_t req; req.url https://asr.example.com/recognize; req.method POST; req.body encoded; req.headers[Content-Type] audio/opus; // 发送请求 http_response_t resp http_send(req); // 解析结果 if (resp.status 200) { char *text json_get_string(resp.body, text); handle_asr_result(text); } }实际项目中网络请求要考虑超时、重试、断网等情况。我一般会设置3秒超时超时后给用户一个网络不好的反馈而不是一直等。4.5 TTS语音合成的选型与集成如果产品需要语音回复就要用到TTS。TTS有两种方案离线TTS和云端TTS。离线TTS把语音合成模型跑在本地不需要联网延迟低但语音自然度差一些而且需要存语音包占用存储。云端TTS语音自然度高但需要联网有延迟。离线TTS的语音包大小从几MB到几百MB不等取决于音质和音色数量。如果存储有限可以用参数合成的方法语音包可以压到几MB但音质会差一些。如果存储充足可以用波形拼接或神经网络合成音质好但语音包大。集成TTS的时候要注意播放和拾音的冲突。设备播放语音的时候麦克风会拾到自己的声音可能导致误唤醒或识别错误。解决办法是加回声消除AEC或者在播放的时候暂停拾音。5. 调试与优化那些文档里不会写的事5.1 识别率上不去的排查思路识别率上不去不要一上来就换算法先按这个顺序排查第一步看音频质量。把采集到的音频存成wav文件用Audacity之类的工具听一下。如果音频本身就有噪声、失真、截幅那算法再好也没用。重点看信噪比、有没有直流偏置、有没有削顶。第二步看预处理。AGC是不是过度放大了噪声滤波器是不是把语音的关键频段也滤掉了降噪是不是把语音也消掉了这些问题都会导致识别率下降。第三步看唤醒和识别的阈值。阈值太高会漏识别太低会误识别。可以统计一段时间内的识别结果画一个ROC曲线找到最佳阈值。第四步看模型和词条。如果是命令词识别词条之间是不是太相似比如打开和关掉声学特征很接近容易混淆。可以调整词条或者增加区分度。第五步看环境。是不是噪声太大是不是有混响是不是说话距离太远这些环境因素对识别率影响很大有时候换个位置就能明显改善。5.2 误唤醒的根因分析与抑制手段误唤醒是语音硬件最头疼的问题之一。用户看电视、聊天、甚至打呼噜都可能触发设备。误唤醒的根因主要有几个一是唤醒词太常见。比如你好这种词日常对话里经常出现误唤醒率必然高。解决办法是选一个不常见的唤醒词比如你好小飞这种组合词。二是唤醒阈值太低。调高阈值可以降低误唤醒但也会降低唤醒率。需要找到平衡点。三是环境噪声和唤醒词相似。比如某些电视节目的背景音乐可能和唤醒词的声学特征相似。这种情况可以用更鲁棒的模型或者增加二次确认。四是音频链路有干扰。比如电源噪声、WiFi干扰可能导致音频信号异常触发误唤醒。这种情况要排查硬件。我的经验是误唤醒率控制在24小时1次以内用户基本能接受。如果超过这个频率就要认真排查了。5.3 响应延迟的优化路径响应延迟是用户体验的关键指标。命令词识别的延迟一般要求300ms以内云端ASR可以放宽到1秒。延迟主要来自几个环节音频采集缓冲缓冲区越大延迟越高。20ms的缓冲区延迟可以接受50ms以上用户就能感觉到。算法处理时间唤醒和识别算法的计算时间。如果主控算力不够算法跑得慢延迟就高。可以优化算法或者换更强的芯片。网络传输时间云端ASR的网络往返时间。这个取决于网络质量一般100-300ms。可以选就近的服务器或者用UDP代替TCP减少握手时间。执行和反馈时间驱动硬件动作和播放反馈的时间。这个一般很快可以忽略。优化延迟的思路是能本地做的本地做能并行的并行做。比如唤醒和预处理可以并行识别和网络请求可以流水线化。5.4 功耗优化的实战技巧电池供电的产品功耗优化是必修课。我总结的几个技巧一是分级睡眠。待机的时候只保留唤醒模块其他全部关掉。唤醒之后逐步开启其他模块。二是动态调频。主控在待机的时候降频唤醒之后升频。很多MCU支持动态调频可以省不少电。三是外设管理。不用的时候关掉WiFi、关掉Codec、关掉LED。这些外设的静态功耗加起来可能比主控还高。四是优化算法。减少不必要的计算比如降噪算法如果效果不明显可以关掉。模型量化也可以减少计算量。五是电池选型。如果功耗实在降不下来就换更大容量的电池。但这是最后的手段优先还是优化功耗。我做过一个项目待机功耗从5mA优化到200uA续航从3天提升到3个月。关键就是分级睡眠和外设管理。6. 从Demo到量产那些容易翻车的环节6.1 一致性问题是量产最大的敌人Demo阶段用一两台设备调试效果很好。量产的时候几百台设备问题就来了有的识别率高有的识别率低有的唤醒灵敏有的唤醒迟钝。这就是一致性问题。一致性问题的根源主要在硬件麦克风的一致性、Codec的一致性、天线的一致性、结构的一致性。MEMS麦克风的一致性比驻极体好很多但还是有差异。结构方面麦克风开孔的位置、大小、密封性都会影响拾音效果。解决办法是来料检验加产线校准。来料检验筛选掉一致性差的物料产线校准对每台设备做单独的增益和阈值调整。校准的方法可以是播放标准音源测量麦克风的响应然后写入校准参数。6.2 结构设计对语音性能的影响结构设计对语音性能的影响比很多人想象的大。麦克风开孔的位置、大小、深度都会影响频响和信噪比。扬声器的位置和功率会影响回声和误唤醒。我踩过的一个坑是麦克风开孔太小导致高频衰减严重识别率上不去。后来把开孔加大识别率明显改善。还有一个坑是扬声器和麦克风太近播放的时候自己把自己唤醒后来加了AEC才解决。结构设计阶段建议做声学仿真模拟麦克风的频响和指向性。如果没有仿真条件就做手板验证多试几种方案。6.3 电磁兼容与音频干扰的排查电磁兼容EMC问题在语音硬件里很常见。WiFi、蓝牙、DCDC、电机都可能对音频链路产生干扰。干扰的表现是音频里有噪声、识别率下降、误唤醒增加。排查EMC问题我一般用排除法先关掉WiFi看问题是否消失再关掉DCDC看问题是否消失逐个排除找到干扰源。找到之后可以通过加屏蔽、加滤波、调整布局来解决。音频链路的PCB布局也很重要。模拟音频走线要远离数字信号和电源最好用地线包围。麦克风的偏置电压要干净否则会有噪声。6.4 用户反馈驱动的迭代优化产品上市之后用户反馈是宝贵的优化依据。我一般会关注几个指标唤醒成功率、识别成功率、误唤醒率、响应延迟、用户投诉。如果唤醒成功率低可能是唤醒词不好记或者阈值太高。如果识别成功率低可能是词条设计不合理或者环境噪声太大。如果误唤醒率高可能是唤醒词太常见或者阈值太低。根据反馈迭代优化是产品走向成熟的必经之路。我做过的一个产品上市后根据用户反馈调整了三次唤醒阈值和两次词条最终体验才稳定下来。7. 几个真实项目的经验复盘7.1 智能开关项目离线命令词的极简方案这个项目的需求很简单用户说打开关闭调亮调暗设备执行对应动作。成本要求极低电池供电续航一年以上。方案选型专用语音识别芯片内置命令词识别功能功耗微安级。麦克风用单颗MEMSCodec用芯片内置的。主控用低功耗MCU只负责驱动继电器和LED。实现要点命令词只有四条用芯片自带的工具训练。唤醒词用小灯小灯不常见误唤醒率低。电源管理用分级睡眠待机功耗控制在100uA以内。踩坑记录最初麦克风开孔在开关面板的侧面用户手握住的时候会遮挡麦克风导致识别率下降。后来把开孔改到面板正面问题解决。7.2 智能音箱项目云端ASR加本地唤醒的混合架构这个项目的需求是用户可以用自然语言提问设备回答。需要联网需要TTS。方案选型本地唤醒用专用芯片云端ASR用第三方服务TTS用云端合成。主控用Cortex-A7跑Linux系统。麦克风用四麦环形阵列支持远场拾音。实现要点唤醒词用你好小智本地检测。唤醒后录音上传云端返回文字后做NLU然后执行动作或调用TTS。回声消除用WebRTC的AEC模块。踩坑记录最初没有做回声消除设备播放音乐的时候经常自己唤醒。后来加了AEC问题解决。另外WiFi和音频链路的干扰也折腾了很久最后通过调整天线布局和加屏蔽解决。7.3 语音遥控器项目低功耗与响应速度的平衡这个项目的需求是按键唤醒用户说命令词设备通过蓝牙发送指令。电池供电要求续航三个月以上。方案选型MCU用Cortex-M4跑离线命令词识别。蓝牙用低功耗蓝牙模块。麦克风用单颗MEMS。实现要点按键唤醒后MCU从睡眠模式唤醒开始采集音频跑识别算法识别到命令词后通过蓝牙发送。识别完成后立即回到睡眠模式。踩坑记录最初唤醒后MCU启动时间太长用户说完命令词了MCU还没准备好。后来优化了启动流程把不必要的初始化放到睡眠前完成唤醒后直接开始采集响应时间从800ms降到200ms。8. 语音硬件开发的几个关键决策点8.1 离线还是云端没有标准答案离线还是云端是语音硬件开发最重要的决策之一。我的判断逻辑是如果命令词固定、数量少、对延迟敏感、对隐私要求高选离线。如果需要自然语言、词条经常更新、对识别精度要求高选云端。如果两者都有需求做混合方案常用指令离线复杂指令云端。混合方案的关键是无缝切换。用户不需要知道哪些指令是离线处理的哪些是云端处理的。设备自动判断自动路由。8.2 自研还是用现成方案成本与可控性的权衡自研语音算法可控性高但投入大、周期长。用现成方案上手快但定制性差、可能有授权费。我的建议是核心算法用现成的应用层自研。比如唤醒和识别可以用芯片厂商提供的方案NLU和业务逻辑自己写。这样既能快速上线又能保证产品差异化。如果产品对语音性能有极高要求或者有特殊场景需求再考虑自研算法。自研的话建议从开源框架入手比如Kaldi、ESPnet先跑通再优化。8.3 成本控制哪些地方可以省哪些不能省语音硬件的成本主要在芯片、麦克风、存储、网络模块。我的经验是不能省的麦克风、Codec、电源管理。这些直接影响语音性能省了后面全是坑。可以省的主控算力、存储容量、外壳材质。如果算法优化得好低算力主控也能跑如果语音包压缩得好小存储也够用。看情况的网络模块。如果产品不需要联网WiFi和4G都可以省掉成本能降不少。成本控制的核心是按需选型不要盲目追求高性能也不要为了省钱牺牲核心体验。8.4 开发周期与团队配置的现实考量语音硬件开发的周期取决于方案的复杂度和团队的熟悉程度。一个简单的命令词识别产品从选型到量产大概3-6个月。一个云端ASR加TTS的智能音箱可能需要6-12个月。团队配置方面至少需要嵌入式软件工程师、硬件工程师、算法工程师可以兼职、测试工程师。如果做云端服务还需要后端工程师。我的经验是先做Demo验证核心链路再做产品化。Demo阶段用开发板快速验证语音链路能不能跑通。产品化阶段再考虑成本、功耗、一致性。9. 写在最后一些个人体会做语音智能硬件这些年最大的感受是语音交互不是万能药不是所有产品都适合加语音。有些场景按键比语音更直接、更可靠。加语音之前先想清楚用户是不是真的需要语音语音是不是真的能提升体验。另一个感受是语音硬件的门槛在工程不在算法。算法有现成的方案可以用但把算法塞进硬件、保证一致性、控制功耗、优化体验这些工程问题才是真正的挑战。我见过太多团队算法很强但产品做不出来就是卡在工程上。最后语音硬件的调试需要耐心。识别率上不去、误唤醒降不下来、延迟优化不了这些问题都很磨人。但只要按部就班排查找到根因总能解决。我踩过的坑希望你不要再踩一遍。
