1. 离线语音控制照明的核心挑战拆解1.1 为什么“离线”两个字让方案难度翻倍离线语音控制照明说白了就是把语音识别和指令执行全部塞进本地设备不依赖云端服务器。听起来只是把服务器搬到本地但实际做过的人都知道这一步跨过去难度不是线性增长而是指数级上升。云端方案里麦克风阵列采集到的音频直接打包上传识别、语义理解、指令下发全在服务器完成本地只需要一个能联网的MCU就够了。但离线方案要求本地设备在有限的算力和内存下完成同样的工作同时还要保证响应速度和识别准确率。照明控制这个场景又特别特殊。灯是家里最基础、最高频使用的设备之一用户对它的期待是“随叫随到”。你喊一声“开灯”如果等两秒才亮体验直接崩掉。云端方案受网络波动影响延迟不可控离线方案虽然响应快但算力受限识别模型必须精简到极致。更麻烦的是照明设备通常安装在墙壁开关、天花板吸顶灯、床头台灯这些位置供电条件千差万别有些位置根本没有零线只能靠电池供电。这就引出了第二个核心矛盾低功耗唤醒。1.2 低功耗唤醒为什么成了“卡脖子”环节低功耗唤醒的本质是一个“守夜人”问题。设备大部分时间在睡觉但必须有一个机制能在用户说出唤醒词时立刻醒来。这个机制不能太耗电否则电池撑不住也不能太迟钝否则用户喊了半天没反应更不能太敏感否则电视里说句话、窗外汽车鸣笛都能把它叫醒误唤醒率飙升。我实测过几款市面上的离线语音照明方案待机功耗从几十微安到几毫安不等。别小看这个差距用CR2032纽扣电池供电的话几十微安能撑几个月几毫安可能一周就趴窝了。但功耗压得越低唤醒检测的灵敏度往往越差或者误唤醒率越高。这中间的平衡点就是整个方案最难啃的骨头。1.3 照明场景对离线语音的特殊要求照明控制和音箱、电视的语音控制不一样。音箱可以接受“先唤醒、再等指令”的两段式交互用户说“小爱同学”之后停顿一下再说“开灯”这个延迟用户能忍。但灯不行用户走到黑暗的房间里喊“开灯”的时候希望灯立刻亮最好连唤醒词都省了。这就对唤醒检测提出了更高要求要么唤醒词极短要么支持免唤醒直接识别指令。另外照明设备的麦克风位置通常比较尴尬。吸顶灯的麦克风在天花板上离用户远混响严重墙壁开关的麦克风在墙面容易被手遮挡床头灯的麦克风在侧面拾音方向性差。这些物理限制导致离线语音照明方案不能照搬音箱的麦克风阵列设计必须针对安装位置做专门的声学优化。2. 唤醒检测的技术路线与选型逻辑2.1 从硬件层面理解唤醒检测的三种实现方式目前离线语音唤醒检测主要有三条技术路线每条路线的功耗、成本、识别率差异很大选型时得根据具体照明产品的供电条件和成本预算来定。第一种是专用语音唤醒芯片方案。这类芯片内部集成了专用的DSP核和唤醒词检测算法主控MCU可以完全断电只有唤醒芯片在运行。典型功耗在几十微安级别检测到唤醒词后通过中断引脚把主控唤醒。优点是功耗极低、开发简单缺点是唤醒词固定通常只能选芯片厂商预置的几个词灵活性差而且不同芯片对中文唤醒词的识别率差异很大。第二种是主控MCU带低功耗语音活动检测。主控MCU在低功耗模式下保持一个极简的VAD语音活动检测模块运行检测到有人声时快速唤醒进行完整识别。这种方案功耗比专用芯片高通常在几百微安到1毫安之间但灵活性好唤醒词可以自定义识别模型也能OTA更新。难点在于VAD的阈值调校太灵敏了误唤醒多太迟钝了喊半天没反应。第三种是模拟前端加比较器方案。用模拟麦克风加一个比较器电路当环境音量超过阈值时触发中断唤醒主控。这是最省成本的方案功耗可以做到几微安但误唤醒率极高基本只能用在噪声极低的卧室场景客厅、厨房根本没法用。2.2 唤醒词检测算法的核心指标评估一个唤醒检测方案好不好不能只看“能不能唤醒”得看四个核心指标唤醒率、误唤醒率、响应延迟、功耗。这四个指标互相制约调优的过程就是找平衡点的过程。唤醒率通常用百分比表示比如95%唤醒率意味着100次唤醒词有95次能成功触发。但这里有个坑很多厂商标称的唤醒率是在安静环境下、标准发音、固定距离测出来的实际家庭环境里用户可能带着口音、语速快慢不一、距离忽远忽近唤醒率会打折扣。我建议在选型时要求厂商提供不同信噪比条件下的唤醒率曲线而不是只看一个标称值。误唤醒率通常用“次/24小时”来表示比如0.5次/24小时意味着平均两天误唤醒一次。这个指标比唤醒率更难测因为需要长时间的老化测试。我踩过的坑是实验室里测一周没问题用户家里电视一开误唤醒率直接爆表。后来发现是电视节目里的人声频谱和唤醒词太接近算法区分不了。响应延迟包括唤醒检测延迟和指令识别延迟两部分。唤醒检测延迟通常在100-300毫秒指令识别延迟在200-500毫秒。加起来如果超过800毫秒用户就会觉得“灯反应慢”。照明场景下我建议把总延迟控制在500毫秒以内。功耗指标要分状态看待机功耗、唤醒检测功耗、识别功耗。待机功耗是设备在“只听不看”状态下的电流唤醒检测功耗是检测到声音后到确认唤醒词之间的功耗识别功耗是确认唤醒后跑完整识别模型的功耗。电池供电的设备待机功耗必须控制在100微安以内否则续航撑不过三个月。2.3 为什么照明场景更适合“唤醒词指令词”两级架构有些方案宣传“免唤醒直接说指令”听起来很美好但实际用起来问题很多。照明场景的环境噪声复杂厨房有抽油烟机、客厅有电视、卧室有空调免唤醒方案为了不漏识别只能把检测阈值调得很低结果就是误触发频繁。我见过一个方案用户打个喷嚏灯就亮了半夜翻个身灯也亮最后用户直接把语音功能关了。两级架构虽然多了一步“喊唤醒词”但换来的是更低的误唤醒率和更高的指令识别准确率。唤醒词的作用是“告诉设备我要说话了”设备确认唤醒后才启动完整的识别流程这样可以把大部分环境噪声挡在门外。而且唤醒词通常设计成多音节、频谱特征明显的词比如“小灯小灯”“开灯精灵”和日常对话的区分度更高。当然两级架构的体验优化空间在于唤醒词的短化和自然化。我试过把唤醒词从四个字压缩到两个字唤醒率会下降大约5-8个百分点但用户喊起来更顺口。这个取舍要看目标用户群体年轻人可能更接受短唤醒词老年人则更适合发音清晰的多音节词。3. 低功耗唤醒的实操设计与参数调校3.1 硬件选型麦克风、Codec与主控的搭配离线语音照明的硬件链路通常是麦克风→模拟前端可选→Codec→主控MCU/语音芯片。每一级的选型都会影响最终的唤醒性能和功耗。麦克风选型上模拟驻极体麦克风ECM和MEMS麦克风各有优劣。ECM成本低、灵敏度高但一致性差批量生产时不同麦克风的灵敏度差异可能导致唤醒率波动。MEMS麦克风一致性好、抗干扰能力强但成本略高。我建议照明产品用MEMS麦克风因为照明设备的安装位置固定麦克风一致性对批量生产的一致性影响很大。Codec的选择要看主控是否自带ADC。如果主控自带高性能ADC可以直接把麦克风信号接入省掉独立Codec。但主控自带的ADC在低功耗模式下的性能往往打折这时候就需要外挂一个低功耗Codec在待机时只让Codec的VAD模块工作主控保持深度睡眠。主控选型是最大的分水岭。如果选专用语音芯片比如某些国产的离线语音模组开发周期短但灵活性和可扩展性差。如果选通用MCU跑轻量级神经网络比如Cortex-M4/M7带DSP指令集的芯片灵活性好但需要自己优化模型和功耗。我个人的经验是照明产品如果只是控制开关和调光专用语音芯片足够如果要支持多房间组网、场景联动通用MCU方案更有扩展空间。3.2 唤醒检测的功耗预算分配假设我们用CR2032纽扣电池供电容量约220mAh目标续航6个月。那么平均电流必须控制在220mAh/(6×30×24h)≈51微安。这个预算非常紧张必须精打细算。待机状态下主控深度睡眠电流约2微安语音唤醒芯片约30微安麦克风偏置电路约10微安LDO静态电流约5微安加起来约47微安刚好卡在预算内。这意味着唤醒检测的功耗必须控制在30微安以内而且不能有额外的LED指示灯常亮否则几毫安的LED电流直接让续航崩掉。如果换成市电供电的吸顶灯功耗预算宽松很多可以用几百微安的方案唤醒率和误唤醒率都能做得更好。所以照明产品在定义阶段就要明确供电方式电池供电和市电供电的语音方案完全是两个设计思路。3.3 唤醒词模型训练与阈值调校唤醒词模型的训练通常有两种方式一种是直接用芯片厂商提供的工具链录制唤醒词样本训练一个小型神经网络另一种是用开源框架如TensorFlow Lite Micro自己训练。前者上手快后者灵活度高。训练数据的关键是覆盖真实使用场景。我建议至少录制2000条正样本不同人、不同距离、不同语速的唤醒词和5000条负样本日常对话、电视声音、厨房噪声等。负样本的重要性往往被低估实际上误唤醒率主要靠负样本的质量来控制。阈值调校是门手艺活。唤醒检测模型输出的是一个0到1的置信度分数高于阈值就触发唤醒。阈值设高了唤醒率下降设低了误唤醒率上升。我的经验是先在安静环境下把阈值调到唤醒率99%然后逐步降低阈值直到误唤醒率达到可接受的上限比如0.5次/24小时取这个临界点作为最终阈值。但要注意不同批次的麦克风灵敏度有差异量产时可能需要逐台校准或者留一个用户可调的灵敏度档位。3.4 低功耗唤醒的电路设计细节电路设计上有几个容易踩坑的地方。首先是麦克风的偏置电压MEMS麦克风通常需要1.8V到3.3V的偏置这个电压的噪声直接影响信噪比。我建议用LDO单独给麦克风供电不要和主控的数字电源共用否则数字噪声会串进来。其次是唤醒芯片和主控之间的中断信号。中断引脚必须配置为边沿触发而且要有硬件去抖否则电源波动可能产生虚假中断。我遇到过因为电源纹波导致主控频繁被误唤醒最后在中断引脚加了一个RC滤波才解决。最后是PCB布局。麦克风信号是毫伏级别的微弱信号走线必须远离高频数字信号和电源开关节点。我见过一个设计把麦克风走线和PWM调光走线平行走了5厘米结果调光时麦克风拾取到严重的PWM噪声唤醒率直接掉了一半。后来把麦克风走线改到板子另一层中间加地平面隔离问题才解决。4. 误唤醒率与唤醒率的平衡实战4.1 误唤醒的主要来源与抑制手段误唤醒是离线语音照明方案最容易被用户投诉的问题。我统计过我们方案在实际家庭环境中的误唤醒来源排名前三的分别是电视节目人声约40%、家庭成员日常对话约30%、厨房噪声约15%剩下的包括宠物叫声、窗外交通噪声等。电视节目人声之所以是最大来源是因为电视里的人声经过压缩和均衡处理频谱特征和唤醒词有相似之处。抑制手段主要有两个一是增加负样本训练把各种电视节目的音频片段加入训练集二是引入声源定位如果声音来自电视方向而不是用户常站的位置就降低唤醒置信度。但声源定位需要麦克风阵列成本和功耗都会增加照明产品不一定划算。日常对话误唤醒的抑制更依赖模型本身。我试过在唤醒词检测前加一个VAD模块只有检测到人声活动才启动唤醒词检测这样可以把空调噪声、键盘敲击声等非人声噪声挡掉。但VAD本身也有误判比如音乐里的人声可能被VAD判定为人声然后触发唤醒词检测。所以VAD的阈值也要仔细调。4.2 唤醒率下降的常见原因排查用户反馈“喊了没反应”的时候排查思路要系统化。我一般按以下顺序检查先看麦克风是否被遮挡。照明设备的麦克风开孔如果太小或者被灯罩、装饰件挡住拾音灵敏度会大幅下降。我见过一个吸顶灯设计麦克风开孔在灯罩内侧装到天花板上之后灯罩和天花板之间只有2毫米缝隙声音根本传不进去。再看电源噪声。如果设备在调光状态下唤醒率下降很可能是PWM调光噪声串入了麦克风链路。用示波器看麦克风输出如果看到和PWM频率同步的周期性噪声基本可以确认。解决办法是调整PWM频率到人声频段之外比如20kHz以上或者在麦克风链路加陷波滤波器。最后看模型是否匹配。如果设备在安静环境下唤醒率正常但在特定噪声环境下下降说明模型的抗噪能力不足。这时候需要补充对应噪声场景的训练数据重新训练模型。4.3 实测数据不同方案的唤醒性能对比我在实验室里对比过三种典型方案在相同测试集上的表现测试集包含安静、电视噪声、厨房噪声三种场景每种场景100次唤醒词测试。方案类型安静环境唤醒率电视噪声唤醒率厨房噪声唤醒率误唤醒率次/24h待机功耗专用唤醒芯片A98%85%78%0.835微安专用唤醒芯片B96%90%82%0.455微安通用MCUVAD97%88%80%1.2120微安模拟比较器方案92%60%45%5.08微安从数据可以看出专用唤醒芯片B在唤醒率和误唤醒率之间取得了较好的平衡但功耗比芯片A高。模拟比较器方案虽然功耗极低但抗噪能力太差只适合极安静的卧室场景。通用MCU方案灵活性最好但功耗和误唤醒率都需要更多调校。4.4 用户可感知的体验优化技巧除了硬指标还有一些软性的体验优化能显著提升用户满意度。比如唤醒反馈用户喊了唤醒词之后如果灯没有任何反应用户会以为设备坏了。我建议在唤醒成功后让灯闪一下或者发出极短的提示音告诉用户“我听到了”。这个反馈的功耗很低但对体验提升很大。再比如唤醒词的容错。用户可能把“开灯”说成“开登”或者语速太快把两个字连成一个音。唤醒词模型如果能支持一定的发音变体唤醒率会明显提升。我在训练模型时会把常见方言发音和连读变体加入正样本实测唤醒率能提升3-5个百分点。还有一个技巧是动态阈值。白天环境噪声大阈值可以适当提高减少误唤醒深夜环境安静阈值可以降低提高唤醒率。这个动态调整可以基于麦克风采集到的环境噪声水平自动完成不需要用户干预。5. 离线语音包与固件更新的工程实践5.1 离线语音包的构成与烧录方式离线语音包通常包含三部分唤醒词模型、指令词模型、声学前端参数。唤醒词模型负责检测唤醒词指令词模型负责识别具体指令声学前端参数包括降噪、回声消除、自动增益控制等配置。烧录方式取决于主控的存储方案。如果主控有内置Flash语音包可以直接烧录到Flash的指定分区。如果主控Flash空间不足需要外挂SPI Flash语音包放在外挂Flash里主控通过SPI读取。我建议照明产品至少留1MB的Flash空间给语音包否则后续想增加指令词或者优化模型都没有空间。烧录工具方面专用语音芯片通常有配套的烧录器和上位机软件操作比较简单。通用MCU方案则需要自己写烧录脚本把语音包和固件打包成一个镜像文件通过串口或者SWD接口烧录。我踩过的坑是语音包和固件的版本不匹配导致唤醒词模型加载失败设备直接变砖。后来我们在固件里加了版本校验不匹配就拒绝启动至少不会变砖。5.2 固件OTA与语音包热更新照明设备一旦装到天花板上拆下来更新固件就很麻烦。所以OTA能力是必须的。但离线语音设备的OTA有个特殊难点语音包通常比较大几百KB到几MB而照明设备的网络连接可能不稳定比如Wi-Fi信号弱OTA过程中断可能导致设备无法启动。我的做法是双分区备份。Flash里留两个固件分区新固件下载到备用分区校验通过后再切换启动分区。语音包也做类似处理新旧语音包共存切换时只改一个指针。这样即使OTA失败设备还能回滚到旧版本正常工作。热更新语音包的需求主要来自指令词的调整。比如用户想增加“调暗一点”这个指令如果每次都要重新烧录固件就太麻烦了。我们的方案是把指令词模型做成独立的二进制文件通过手机App推送到设备设备收到后写入外挂Flash的指定区域然后重新加载模型。这个过程不需要重启主控唤醒检测不受影响。5.3 udev热插拔与systemd看门狗在语音模组中的应用有些离线语音照明方案采用模块化设计语音模组通过USB或者UART接口和主控通信。这种设计的好处是语音模组可以独立升级主控不需要关心语音算法的细节。但模块化也带来了新的问题模组热插拔时主控需要正确识别并重新初始化。在Linux系统上udev规则可以用来处理模组的热插拔事件。比如当语音模组插入时udev规则自动加载对应的驱动并启动语音服务。当模组拔出时udev规则停止服务并释放资源。这个机制在调试阶段特别有用插上模组就能用拔下来就停不需要手动重启系统。systemd看门狗则是保证语音服务稳定运行的手段。语音服务定期向systemd发送心跳如果服务卡死或者崩溃systemd会在超时后自动重启服务。我建议看门狗超时时间设为10-15秒太短了容易误重启太长了故障恢复慢。另外看门狗重启服务时要保留日志方便事后排查崩溃原因。5.4 插入手机自动启动的联动场景“插入手机自动启动”这个场景听起来和照明无关但在实际项目中很有用。比如在酒店或者样板间场景用户把手机插到床头灯的USB充电口上灯自动进入语音控制模式同时手机开始充电。这个联动可以通过USB插入检测来实现主控检测到USB口有设备插入通过D/D-电平变化判断是手机还是U盘然后触发相应的场景。实现上USB插入检测可以用专用的USB检测芯片也可以用主控的GPIO配合分压电阻。我建议用专用芯片因为手机插入时的电平变化比较复杂GPIO直接检测容易误判。检测到手机插入后主控通过UART或者I2C通知语音模组进入活跃模式同时打开充电电路。这个场景的功耗管理也很重要手机充电时电流可能达到1A以上电源设计要留足余量。6. 常见问题排查与避坑指南6.1 唤醒检测相关的典型故障速查故障现象可能原因排查方法解决方案完全无法唤醒麦克风损坏或偏置电压缺失示波器测麦克风输出是否有信号检查偏置电路更换麦克风唤醒率突然下降电源噪声增大或麦克风被遮挡对比不同供电条件下的唤醒率优化电源滤波清理麦克风开孔误唤醒频繁阈值过低或负样本不足记录误唤醒时的环境声音提高阈值补充负样本训练唤醒后无响应主控未正确退出低功耗模式测量主控中断引脚波形检查中断配置和唤醒源设置电池续航短待机功耗超标用电流表测各状态电流逐项排查LDO、麦克风、唤醒芯片功耗6.2 低功耗设计中的隐蔽陷阱低功耗设计最怕的是“看不见的电流”。我遇到过好几个案例待机电流比预期高了十几倍最后查出来是GPIO配置不当。比如某个GPIO配置为输入但内部上拉电阻使能外部又接了地就形成了一个持续的电流通路。这种问题在原理图上看不出来必须用电流表逐项测量。另一个陷阱是LDO的静态电流。很多LDO标称静态电流几微安但那是空载条件下的值。实际带载时LDO的静态电流可能上升到几十微安。选型时要看带载条件下的静态电流曲线而不是只看数据手册的标称值。还有唤醒芯片的IO口漏电流。有些唤醒芯片在深度睡眠时IO口不是高阻态而是有微弱的漏电流。如果这个IO口连接到主控的某个引脚而主控引脚又配置为低电平就会形成漏电流通路。解决办法是在唤醒芯片和主控之间加一个隔离MOS管或者选择IO口在睡眠时为高阻态的唤醒芯片。6.3 声学结构设计的经验教训照明设备的声学结构设计往往被忽视但它对唤醒性能的影响可能比算法还大。我总结了几条经验麦克风开孔不能太小。开孔直径至少3毫米否则高频衰减严重而唤醒词的高频成分对识别很重要。开孔位置要避开灯罩的遮挡最好直接朝向用户常站的方向。麦克风不能直接贴在PCB上。PCB的振动会通过固体传导进入麦克风形成噪声。我建议用软胶套或者硅胶垫把麦克风悬浮固定减少固体传导。腔体不能完全密封。完全密封的腔体内部气压随温度变化会导致麦克风振膜变形灵敏度漂移。留一个微小的泄压孔用防水透气膜覆盖既能平衡气压又能防尘。6.4 量产一致性问题的应对策略实验室里调好的方案量产时可能因为元器件批次差异导致性能波动。我建议在产线上增加两个测试工位一个是唤醒率抽检用标准声源在固定距离播放唤醒词记录唤醒成功率另一个是待机功耗全检确保每台设备的待机电流在规格范围内。对于唤醒率不达标的设备可以通过调整软件阈值来补偿。但阈值调整范围有限如果硬件差异太大还是得从元器件筛选入手。麦克风的一致性尤其重要我建议要求供应商提供灵敏度分档同一批产品只用同一档的麦克风。7. 方案扩展与未来优化方向7.1 多房间组网与语音指令路由单灯语音控制只是起点实际家庭场景里用户希望“说一句话整个房间的灯都响应”。这就涉及多房间组网和指令路由。实现方式有两种一种是每个灯都有语音模组通过无线组网比如Zigbee或者蓝牙Mesh同步指令另一种是只有一个主语音节点其他灯作为执行节点。第一种方案成本高、功耗大但响应快、可靠性好。第二种方案成本低但主节点故障会导致整个系统瘫痪。我倾向于混合方案客厅和主卧用带语音的灯作为主节点次卧和走廊用普通灯作为从节点主节点通过组网控制从节点。这样兼顾了成本和可靠性。7.2 自适应唤醒阈值与场景学习固定阈值的方案在不同家庭环境下的表现差异很大。自适应阈值可以根据环境噪声水平动态调整但实现起来需要持续监测环境噪声功耗会增加。折中方案是定期校准设备在安装后的第一周每天凌晨环境最安静的时候自动校准一次阈值之后每周校准一次。这样既能适应环境变化又不会显著增加功耗。场景学习是更高级的优化方向。设备可以记录用户的唤醒习惯比如用户通常在晚上7点到10点在客厅活动这个时间段可以适当降低唤醒阈值提高唤醒率凌晨2点到5点则提高阈值减少误唤醒。这个学习过程可以在本地完成不需要上传数据保护用户隐私。7.3 离线语音与传感器融合单纯依赖语音唤醒在照明场景下有时不够可靠。比如用户走进黑暗的房间可能还没来得及说话灯就应该亮了。这时候可以融合人体传感器PIR或者毫米波雷达的数据传感器检测到有人进入先亮灯到低亮度同时启动语音唤醒检测用户说“调亮一点”就能快速响应。传感器融合的难点在于功耗和误触发。PIR传感器功耗低但检测范围有限毫米波雷达检测范围大但功耗高。我建议在电池供电的设备上用PIR市电供电的设备上可以用毫米波雷达。融合逻辑上传感器触发后给语音模组一个“预唤醒”信号让语音模组从深度睡眠进入浅睡眠这样唤醒延迟可以缩短一半以上。7.4 离线语音包的分发与版本管理离线语音包的版本管理是个容易被忽视的工程问题。不同批次的设备可能烧录了不同版本的语音包如果后续要统一升级需要一套版本管理机制。我建议在设备固件里记录语音包的版本号OTA服务器根据版本号决定推送哪个升级包。语音包的升级包要尽量小只包含差异部分减少下载时间和存储空间。另外语音包的兼容性也要考虑。新版本的语音包可能依赖新版本的固件如果设备固件太旧升级语音包可能导致不兼容。所以OTA时要先检查固件版本必要时先升级固件再升级语音包。8. 个人实操体会与建议我在这个方向前前后后折腾了两年多从最早的模拟比较器方案到专用唤醒芯片再到通用MCU跑神经网络每个方案都踩过坑。最大的体会是离线语音照明的核心难点不在算法本身而在系统工程。算法可以买现成的但功耗、声学结构、量产一致性这些工程问题必须自己一点点啃。如果让我给新入行的朋友一个建议我会说先明确供电方式和成本预算再选技术路线。电池供电的设备老老实实用专用唤醒芯片别想着用通用MCU省成本最后功耗调不下来反而更麻烦。市电供电的设备可以尝试通用MCU方案灵活性和可扩展性更好但要做好声学结构设计和电源滤波。还有一个建议是尽早做真实环境测试。实验室里调好的方案放到真实家庭环境里可能完全不是那么回事。我建议在开发阶段就找几个不同户型的家庭做实测收集真实的噪声数据和用户反馈这比在实验室里闭门造车有效得多。最后分享一个小技巧唤醒词的选型可以交给用户。我们做过一个实验让用户从十个候选唤醒词里投票选最喜欢的结果得票最高的那个词在实际使用中的唤醒率也比其他词高了5个百分点。原因很简单用户选了自己觉得顺口的词喊起来自然更清晰、更一致。这个细节看似不起眼但对最终体验的影响很大。