在智能门锁上做语音交互真正的难点是“持续监听”四个字。用户站在门口喊一声“刘工”门锁要立刻醒过来随后判断用户是不是真的想开门、想让谁开门、还是只想问一句“今天有快递吗”。如果所有音频都推到云端待机功耗和网络延迟都很难接受如果所有语义都在本地跑普通 MCU 的资源和算力又不够。PSoC E84 这类集成 NPU 的 MCU 提供了第三条路本地 NPU 常年监听唤醒词云端大模型负责开放语义理解。下面是我在这条思路上完成的一个语音门锁终端案例完整覆盖唤醒词训练、NPU 部署、低功耗唤醒、云端 API 对接和门锁执行环节。这个方案里PSoC E84 承担的是端侧语音终端的角色。它需要解决三件事平时用极低功耗守着麦克风一旦捕捉到“刘工”马上进入唤醒流程唤醒之后记录一小段用户语音通过无线模块发给云端大模型收到云端的结构化指令后校验指令合法性并驱动门锁。整条链路听起来不复杂真正落地时模型量化、NPU 推理、低功耗状态切换、云端超时处理每一个环节都可能让系统卡住。这篇文章会把整条链路拆开来讲适合正在做端侧 AI、语音交互或智能门锁的嵌入式开发者。1. 为什么门锁语音终端要把唤醒放在本地、把理解放在云端1.1 门锁场景的三个硬约束功耗、延迟、可靠性门锁不是手机不能一天一充门锁也不是智能音箱不要求 7x24 小时在线回答百科问题。门锁场景有三个非常明确的约束。第一是功耗。设备在绝大多数时间处于无人状态但麦克风必须开着否则“刘工”这句唤醒词来了没人响应。这就要求硬件支持“只跑一个极低功耗的音频采集和唤醒检测任务”的模式。如果设计成持续把音频上传云端Wi-Fi 或蜂窝模组一直在线待机电流会非常难看。第二是延迟。用户站在门口从说出唤醒词到门锁动作体验上最好在 1 秒到 2 秒内完成。把音频上传、云端识别、返回结果、驱动电机跑完如果网络不好可能超过 3 秒甚至更久。把唤醒词检测放在本地可以保证唤醒到开始录音之间的时间几乎是确定的。第三是可靠性。门锁涉及人身和财产安全误唤醒、误识别、误开锁都不允许。本地唤醒词检测至少要做到“只有听到指定唤醒词才进入录音流程”并且置信度阈值可调。云端大模型返回的指令也不能直接执行必须在设备端做二次仲裁比如只允许执行白名单里的动作。1.2 NPU 解决的是“本地推理”问题不是“大模型部署”问题这里要先澄清一个常见误区PSoC E84 这类 MCU 上的 NPU主要解决的是一路或几路小规模神经网络推理不是用来在本地跑一个大语言模型的。唤醒词识别Keyword SpottingKWS正是 NPU 最典型的落地场景。唤醒词模型通常很小输入是一段几十毫秒到一秒钟的音频特征输出是“是唤醒词”和“不是唤醒词”的概率。它在 MCU 上如果能用 NPU 加速每次推理的耗时可以从几十毫秒降低到几毫秒而且运行期间 CPU 不用