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次唤醒词测试。

从数据可以看出，专用唤醒芯片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 唤醒检测相关的典型故障速查

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个百分点。原因很简单，用户选了自己觉得顺口的词，喊起来自然更清晰、更一致。这个细节看似不起眼，但对最终体验的影响很大。