企业官网建设流程全解析

在智能门锁上做语音交互，真正的难点是“持续监听”四个字。用户站在门口喊一声“刘工”，门锁要立刻醒过来，随后判断用户是不是真的想开门、想让谁开门、还是只想问一句“今天有快递吗”。如果所有音频都推到云端，待机功耗和网络延迟都很难接受；如果所有语义都在本地跑，普通 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 Spotting，KWS）正是 NPU 最典型的落地场景。

唤醒词模型通常很小，输入是一段几十毫秒到一秒钟的音频特征，输出是“是唤醒词”和“不是唤醒词”的概率。它在 MCU 上如果能用 NPU 加速，每次推理的耗时可以从几十毫秒降低到几毫秒，而且运行期间 CPU 不用