晚上十一点桌板上那块 PSoC E84 评估板还亮着电源灯。我对着麦克风说了一声“刘工”板子上方的 LED 闪了一下接着继电器“咔哒”一声旁边的门锁模型开了。这个 demo 看起来像句口令触发但真正值得拆的不是“开门”这个动作而是这条语音链路本地 NPU 负责唤醒云端大模型负责理解最后执行权还是留在本地设备手里。我做这个语音终端之前一直觉得边缘 AI 至少要把一个模型塞进单片机才算数。做完之后发现更有参考价值的不是模型跑在哪而是语音任务应该怎么在本地和云端之间切分。这篇文章从硬件选型、完整数据链路、门锁安全边界、实跑坑点四个角度把整个方案重新梳理一遍。你不用真的复刻这个项目也可以把这套拆法用在其他语音终端、工业语音交互或者智能家居控制上。1. 这个语音终端真正解决的不是“喊一声就能开门”很多人看到门锁被语音打开第一反应是“这有什么难的手机上早就有了”。但如果把场景从手机换成一个低功耗单片机设备难点马上就变了它不能联网再等云端判断“你是不是在叫它”因为那样既慢又费电还把隐私全部送出去。1.1 唤醒词必须留在本地不是技术偏好是体验前提一个语音终端如果要真正做到“随时可唤醒”麦克风就必须 24 小时在线。如果每 50 毫秒都把音频片段传去云端判断一次会出现三个问题功耗撑不住。无线模组常发数据带来的耗电远高于本地跑一个很小的音频模型。时延不可控。哪怕云端响应只需要 300 毫秒加上网络抖动和排队用户会觉得这个设备“反应迟钝”。隐私成本高。环境里的所有声音都被传出去即使设计上只传片段用户心理上也不接受。唤醒词本质上是一个二分类问题听到“刘工”和没听到“刘工”。这个任务复杂度有限完全可以在端侧用一个针对性的小模型完成。NPU 在这里的价值就是让这个小模型在 MCU 上也能稳定跑起来不用依赖云端。1.2 大模型只负责“唤醒之后”的那一段一旦本地确认用户说了“刘工”设备才进入命令采集阶段。此时再录一段几秒钟的音频把它送到云端大模型做语音识别、意图理解、多轮澄清这才是大模型真正擅长的事。这个划分带来的主判断是语音终端的难点不是把一个模型塞进 MCU而是知道什么任务该放本地、什么任务该放云端。本地负责“低延迟、常驻、隐私敏感”的部分云端负责“高语义、需要泛化、非实时”的部分。两者的分界线比单纯比较“谁能跑更大的模型”重要得多。1.3 本地与云端的边界本质上是一条任务成本曲线可以把语音任务按三个维度打分是否常驻执行是否对延迟敏感是否需要开放语义理解常驻、低延迟、小语义量的任务比如唤醒词、命令词、打断检测放在本地。低频、大语义量、需要上下文理解的任务比如“帮我把客厅灯调暗一点但卧室先别关”交给云端大模型。门锁 demo 之所以是一个好例子是因为它同时覆盖了这两个极端唤醒词必须本地自然语言指令可以云端。这个边界一定下来硬件选型和软件架构才不会被拖着走。2. PSoC E84 在这套方案里到底扮演什么角色选 PSoC E84 不是因为它能跑大模型恰恰相反是因为它很清楚自己跑不了大模型但在“音频采集 小模型推理 设备控制”这条链路上它能把每个环节都安排好。2.1 先从异构架构理解这颗芯片PSoC E84 可以理解成一个“带 NPU 的低功耗 MCU”。它不是把一颗手机 SoC 改小而是专门为做边缘 AI 场景设计的CPU 负责跑协议栈、音频处理和业务逻辑NPU 负责跑唤醒模型这类固定结构的神经网络通信模块负责和云端或局域网交互。这种拆分的好处是CPU 不需要被 AI 推理占满还能处理状态机、外设和网络。NPU 跑音频模型时功耗低适合长时间等待唤醒。实时性可控不依赖外部 Linux 系统或 Android 环境。在实际项目里我把它定位成“设备端语音助手的最小底座”而不是通用开发板。2.2 一套最小硬件链路长什么样以我的验证板为例数据链路大致是MEMS 麦克风 - PDM/I2S 音频采集 - CPU 做重采样与音频预处理 - NPU 跑唤醒词模型 - CPU 收到唤醒信号 - Wi-Fi 模块连接云端大模型接口 - 云端返回结构化意图 - CPU 执行本地动作控制门锁/继电器/灯光这里最关键的是NPU 完成唤醒后CPU 要能立刻接管后续流程。NPU 不是主角CPU 和通信协作才是。2.3 为什么不用树莓派或手机从功能上讲树莓派确实能做同样的事。但它有几个不适合这种终端的点功耗高。树莓派不可能靠电池常驻 24 小时等待唤醒。启动慢。断电重启后要加载系统而 MCU 可以毫秒级恢复。可靠性过重。Linux 系统崩溃、SD 卡损坏、软件依赖混乱都会变成新问题。如果你做的是开发原型树莓派非常方便如果你做的是一个能长期放在门边或者墙上的语音终端MCU 加 NPU 的形态更接近量产方向。需要说明的是PSoC E84 的具体型号、NPU 算力和内存配置不同批次和评估板可能有差异。落地前一定要先查你手上那颗芯片的 datasheet 和 SDK 支持情况尤其是音频接口、NPU 算子支持和唤醒模型是否被官方工具链转换过。3. 从麦克风到“刘工”再到云端指令一条完整数据链路很多人以为只要把录音发给云端就行但实际上这条链路的坑都在细节里唤醒阶段怎么处理音频命令阶段怎么防止误录云端返回后怎么执行都需要一步一步设计。3.1 本地唤醒阶段小模型、低延迟、常驻唤醒阶段我会把设备设计成一个状态机enum { STATE_IDLE, STATE_WAKE_CONFIRMED, STATE_RECORD_COMMAND, STATE_PROCESSING, STATE_EXECUTE }; while (1) { switch (state) { case STATE_IDLE: frame read_audio_frame(16, 16); // 16kHz / 16bit if (energy threshold_energy) sleep_low_power(); features extract_fbank(frame); score npu_wake_word_run(features); if (score wake_threshold confirm_frames 3) { state STATE_WAKE_CONFIRMED; } break; case STATE_WAKE_CONFIRMED: play_tone(在呢); start_vad_record(5s); state STATE_RECORD_COMMAND; break; case STATE_RECORD_COMMAND: // 采集用户指令直到静音或者超过最大时长 break; } }唤醒模型一般不需要把整句语音都理解掉它只需要判断最近的几百毫秒音频里“刘工”这个音素模式是否出现。为了减少误唤醒我通常不会只看一帧分数而是连续几帧都超过阈值才进入唤醒状态再配合能量门限过滤静音。3.2 云端理解阶段把几秒录音变成结构化动作唤醒之后设备把命令音频上传到云端服务服务端依次做三件事语音识别把音频转成文字。用大模型解析文字转成结构化意图。校验意图是否在白名单里再返回给设备。服务端返回的格式尽量简单避免把大模型原始输出直接当成命令。比如可以统一返回{ intent: unlock_door, target: front_door, confidence: 0.92, need_confirm: true }设备拿到这个 JSON 后只执行自己认识的白名单意图。如果 intent 是play_music哪怕大模型说得再通顺门锁也不会动作。这样即使将来云端被注入恶意 prompt或者模型理解漂移设备侧还有一道硬边界。3.3 交互反馈让用户知道设备是不是听懂了语音终端最怕用户说完之后没有反应。无论是唤醒成功、正在录音、正在请求云端还是执行成功每个状态都要有明确反馈。我的做法是唤醒成功短提示音 LED 变化。正在录音指示灯保持常亮。等待云端播放“正在处理”的提示音。执行成功播放确认音。这些看起来不起眼但直接影响使用体验。网络再快人还是会等待等待时要有反馈否则用户会反复喊第二遍。4. 门锁不是玩具语音开门的安全边界怎么划“门锁开了”这种话一出来安全就必须优先于功能。语音开门最大的风险不是模型识别错而是整套系统把“听到一个声音”直接当成了“允许开门”。4.1 语音终端只应该负责“请求”执行权必须经过本地确认云端大模型可以帮你判断用户意图但它不能直接打开门锁。设备拿到unlock_door这个结果后还应该检查几个条件这条指令是不是来自当前这台设备生成的请求设备当前是否处于“可开门”的时间段有没有超过每分钟请求次数限制是否需要用户在设备上按一个实体键确认尤其是门锁场景我会建议在云端返回need_confirm: true时设备播放“请按确认键”等用户按下物理按键再执行。这个动作虽然多一步却能把“云被黑、模型乱说、网络被劫持”的大部分风险挡住。4.2 防重放、断网兜底和紧急旁路语音开门还要面临一个实际问题录音重放。如果有人录下“刘工开门”再找一个时间播放给设备听设备可能就被骗了。在做安全设计时至少要覆盖声纹校验可选。在本地或服务端做一个 speaker embedding只有匹配登记人的声纹才执行。请求时间戳与防重放。云端响应里带上时间和随机数设备侧校验时效性。断网兜底。网络不可用、云端超时时不允许靠本地语音直开门但可以提供紧急物理开锁方式。执行限流。一分钟内不能频繁执行“开门”防止脚本连续触发。这些不是噱头而是门锁类产品从 demo 走向真实环境的最低要求。4.3 什么场景适合语音开门什么场景不适合如果你只是做一个办公室门牌、工位灯控、会议室设备唤醒本地唤醒 云端大模型已经够用。如果要做入户门锁建议把语音设计成辅助确认手段而不是唯一权限来源。我会这样判断场景是否适合原因办公室门禁 实体键确认适合语音方便实体键兜底个人工作室桌面锁适合风险低体验大于安全入户门锁远程控制谨慎必须有防重放、权限、机械兜底金融/机房等高安全区域不建议语音无法作为强认证手段语音开门的核心价值是“减少动作”不是“替代所有安全机制”。安全这件事不能交给大模型也不能完全交给网络。5. 实跑一周后最常见的五个坑这套链路看着不算复杂真正跑起来后问题比想象中多得多。很多问题不是模型不行而是链路中某个环节被忽略了。5.1 唤醒率低先别调模型去查音频输入有一次我在板子旁边正常说话唤醒率只有 60%。排查了很久最后发现是麦克风增益太低语音信号还没到 NPU 就已经被压到很小的幅度。音频模型对输入范围很敏感模型参数再好输入信号烂也白搭。排查顺序建议看原始波形 - 看 RMS 能量 - 看是否削顶 - 调麦克风增益 - 再看唤醒分数 - 再调阈值我一般会先把麦克风采集到的原始数据打印出来确认正常说话时能量大概在什么范围然后才去动模型阈值。不要一上来就调模型那是最后的步骤。5.2 误唤醒电视机里的“刘工”也能触发误唤醒是语音终端的老大难。解决思路不是把阈值无限调高而是做多个维度的组合判断能量上要明显高于环境底噪。连续 N 帧都超过阈值而不是单独一帧。唤醒后有一段静音袋如果紧接着又来一个唤醒词不重复触发。我还建议在测试时播放电视节目、播客、关门声观察设备会不会误触发。不要只在安静环境里测试真实环境比实验室吵得多。5.3 指令被截断VAD 静音阈值太敏感命令采集阶段经常出现“我刚说一半设备就以为话说完了然后把没说完的音频丢给云端”。这个问题通常出在 VAD 上用户在句子里稍微停顿VAD 就认为指令结束。一个比较实用的做法是设置最短录音时长例如至少 1 秒。静音判定要持续 600 毫秒以上才认为命令结束。最大录音时长设 8 到 10 秒超时强制截断。服务端看到长时间静音也可以做对齐和去尾但端侧先不要急着把音频切掉。5.4 云端响应慢本地要有超时和降级策略有一次本地已经上传音频用户却一直听不到反馈。原因是云端大模型服务端排队严重响应超过了 10 秒。这在 demo 里可以接受但真实使用完全不行。我的经验是本地请求云端设置 5 秒超时。超时后播放“网络开小差了”不要一直卡住。为了减少等待感可以先返回一个“正在处理”的确认音。如果服务端支持流式返回优先用流式把中间状态逐步展示出来。5.5 状态机卡死每个转换都要有超时音频、网络、云端返回都可能异常。设备状态机一旦停在STATE_RECORD_COMMAND后面就全堵住了。我建议给每个状态加超时录音状态 10 秒超时。网络请求 10 秒超时。执行动作 3 秒超时。空闲状态如果收到无效数据直接丢弃。另外日志要记录每一次状态切换、唤醒分数、上传耗时、云端返回内容和执行结果。否则出问题时你根本不知道是哪一环断了。下面是一个常见问题的排查表现象优先排查链路检查点完全不唤醒音频输入 - 模型输入 - 阈值波形、能量、增益、模型是否加载频繁误唤醒阈值 - 确认帧数 - 环境噪声灵敏度、静音袋、多帧确认唤醒后没录音状态机 - VAD - 定时器状态流转是否卡住、VAD 是否生效云端没反应网络 - API Key - 请求格式超时、日志、服务端是否收到音频云端返回了但设备没执行意图白名单 - 本地状态intent 是否被合法解析、GPIO 是否配置对6. 从一个门锁 demo沉淀成一类可复用流程项目本身已经跑通了但比“门锁开了”更有价值的是这套“本地唤醒 云端大模型 本地执行”的架构方法。它不只能做门锁还能迁移到很多语音终端的场景。6.1 先跑最小闭环再补齐工程化能力我强烈建议所有做这类项目的人先别急着追求功能完整。第一个里程碑应该是说唤醒词 - 设备亮灯 - 录音 - 云端返回 JSON - 设备执行一个假动作这个闭环一旦通了后面加灯控、门锁、播报、多轮对话都只是在这个骨架上加肉。反过来如果一开始就把意图分析、声纹、多轮对话、App 联动全塞进去出了问题都分不清是哪一层造成的。最小闭环跑通后再补三类能力日志与监控云端请求耗时、唤醒率、误唤醒率、错误类型。异常恢复超时、断网、模型异常、网络重连。安全加固白名单、请求校验、执行确认、限流。6.2 这套架构适合什么不适合什么适合的场景有这些共同点设备长期待机需要低功耗常驻唤醒。交互以命令为主不需要太复杂的人机对话。对隐私敏感不希望所有声音都在云端处理。需要本地可靠执行比如门锁、工位设备、工业控制面板。不适合的场景也有需要连续流式视觉理解比如摄像头实时分析。需要跑 10B 以上本地大模型的对话助手。需要海量上下文记忆的陪伴型设备。在这些场景里PSoC E84 这类 MCU 加 NPU 的方案会有明显边界。它做不了“全能助手”但它能做“准确的命令终端”。6.3 一个可复用的任务切分框架最后留一个我自己常用的判断方式叫“四层职责分割”唤醒层本地、常驻、低功耗、对隐私敏感。感知层语音转文字、声纹、环境理解可以本地也可以云端取决于模型大小和时延。语义层意图识别、多轮对话、知识问答适合云端大模型。执行层门锁、灯光、电机、消息推送必须留在本地并且接受安全策略管理。每一层可以独立替换也可以逐步演进。今天用云端大模型明天想改成私有化部署只需要替换语义层不动唤醒层和执行层。这个解耦才是这套方案真正值得尝试的原因。门锁只是把这种架构具象化了。你真正做的是一个可以听懂命令、在本地保持警觉、在云端获得理解能力最后仍然把安全执行权握在自己手里的边缘语音终端。接下来要做的事就是先把它跑通再慢慢把每一层的边界打磨清楚。