我自己的小智AI音箱之前遇到过一个挺有意思的场景家里路由器半夜自动重启那几十秒时间里设备明显是断网的但我说“小智小智”它依然会亮灯、会回应一声提示音只是接下来无论问天气还是让它放歌都只会得到一句“网络异常”之类的反馈。这个现象让不少朋友困惑过它到底算“活着”还是“死了”为什么唤醒词能响应后续功能却全废答案其实不在某一个模块里而在于理解设备与服务端的分工。一次完整的语音唤醒远没有表面看起来那么简单。沿着这条链路拆开看你就能明白断网时设备究竟还有多少“本地算力”在悄悄工作也能搞清楚为什么唤醒词这种功能被特意放在了设备端而不是全部丢给云端。这篇文章我用一次实际唤醒测试为主线把设备端和服务端各自负责的活儿捋清楚也聊聊断网场景下可以怎么继续折腾。如果你手头也有一台ESP32S3做的小智AI或者正准备用ESP32加INMP441麦克风攒一台那我这篇内容应该能帮你少踩不少坑。就算你只是好奇这类AI硬件的工作原理读完也会对“本地优先”这个词有更具体的感觉。1. 断网测试之前先搞清楚“小智”的耳朵长在哪很多人对语音设备的第一印象是“它不就是听声音然后联网查答案嘛。”这个理解不算错但忽略了很重要的一个层次——听声音这个动作本身就分了多个阶段。并且其中只有一部分依赖网络。在围绕“断网”做实验之前有必要先把手头这台设备的硬件结构和音频链路理一遍否则后面看到的“能响应”和“不能响应”都会变成一堆迷惑行为。1.1 硬件端的声音采集INMP441与I2S总线的角色我手里这台小智AI是用ESP32S3为主控芯片搭的麦克风选的是INMP441一款非常常见的I2S数字麦克风。还有的人会用板载模拟麦克风或者PDM接口的咪头但INMP441在这类DIY项目里出现频率最高原因很简单它输出的是数字信号抗干扰能力强接线上也能少处理一层模拟放大电路。INMP441通过I2S协议与ESP32通信。I2S是一条专门传音频数据的总线包含三个主要信号BCK位时钟、WS声道选择、DATA数据。ESP32S3本身集成I2S外设可以直连这颗麦克风。实际焊接的时候需要注意WS和BCK这两根线不能接反Data线也要对应到ESP32S3支持I2S输入的那个GPIO上不然采集出来的全是噪声或静音。你说这不是一篇讲断网行为的文章吗为什么我要先唠麦克风因为唤醒词识别这件事第一步就是把麦克风采集到的PCM音频流喂给算法。如果硬件端采集就有问题那断网不断网都没意义本地识别和云端识别都会一起崩。而且后面的很多故障排查最终都会回溯到音频链路质量上。1.2 音频数据流的起点16kHz采样率与本地缓存的逻辑INMP441最高支持到48kHz采样率但小智这类语音助手通常会把采样率降到16kHz甚至8kHz再来做唤醒和语音识别。为什么因为人说话的有效频段大部分集中在300Hz到3400Hz16kHz采样率已经能覆盖到8kHz带宽对语音识别来说足够用了还能显著降低数据量。我在实际测试中习惯把ESP32侧的采集配置设为16kHz、16bit、单声道。这个配置有两点好处一是ESP-SR这类本地唤醒引擎对16kHz音频处理最成熟识别率最高二是后续如果要把音频上传到服务端16kHz单声道的PCM流带宽占用只有256kbps左右打包成Opus或者Speex之后还能压得更低不会让WiFi链路成为瓶颈。麦克风采到的原始PCM数据会先在ESP32内部走一遍缓冲区。这个缓冲区大小的设置很有讲究设得太小音频流容易断断续续唤醒词检测还没跑完数据就被覆盖了设得太大端到端延迟会明显增加。我一般用DMA双缓冲每个缓冲250ms左右这样既能给本地算法留出足够的分析窗口又不会让用户说完唤醒词后感觉响应迟钝。1.3 服务端是什么小智AI的云端处理框架设备端负责“听”和“判断是否有人在叫它”服务端负责“理解这句话是什么意思”以及“生成回答”。小智AI的服务端走的是一条典型的智能语音链路语音识别ASR把音频转成文字语义理解NLU/LLM理解用户意图语音合成TTS把回复文本转成音频最后再把音频流推回给设备播放。这里有个关键点唤醒词识别在设备端完成但唤醒之后的那一长段用户语音也需要被送到服务端做ASR。换句话说触发唤醒本身是免费的但触发之后的所有“智慧”都依赖网络。这就能解释最开头那个现象断网后“小智小智”仍能触发设备端的状态切换可一旦进入“等待后续指令并上传”的阶段没网就只能中断了。理解了这层结构下面就可以沿着时间线把一次唤醒从物理声音变成设备动作的完整过程切开来看。这个过程里每一步的归属方、依赖条件和失败表现都不同只有逐段拆开才能回答“断网后还能做什么”这个问题。2. 一次唤醒从声波到响应的完整链路切割我决定用一次实际场景来串这条链路我在客厅里说“小智小智”然后紧接着说“现在几点”。这句话一共经历了多少道工序每一道工序是在设备上完成的还是云端完成的哪几道工序断网后会立刻罢工下面按时间顺序逐段拆。2.1 声学前端本地降噪与回声消除的第一道工序声音从嘴巴出发首先要经过一个常被人忽略但极其重要的模块——声学前端处理英文简称AFE。ESP32上的乐鑫语音方案自带AFE的能力包括回声消除、噪声抑制、自动增益控制等。为什么要做回声消除因为音箱自己会播放音乐或语音。如果设备一边播放TTS回复一边又开着麦克风采集麦克风会把喇叭里放出来的声音也录进去。如果没有回声消除那唤醒词引擎就会陷入“自己说话自己唤醒自己”的死循环。我最早调试时没开AFE设备一播放回复马上又被同一个“小智小智”的音频触发唤醒场面非常尴尬。之后又加入了“唤醒词引擎”和“VAD”。VAD全称Voice Activity Detection用来检测人是否在说话。在用户说完唤醒词后设备会开启一段录音窗口通过VAD判断用户是已经结束说话还是还在继续。这段判断完全在本地完成不需要联网。实际效果上VAD的灵敏度参数直接影响后续上传音频的切分质量调得太灵敏会把环境噪声一起打包上传调得太迟钝又会把用户的指令尾部截掉导致云端ASR识别出半句话。2.2 唤醒词引擎的本地判定为什么归类不依赖网络唤醒词引擎是设备端最核心的模块之一。esp32上常用的方案包括乐鑫的WakeNet、以及用onxx-runtime跑在MCU上的自定义唤醒词模型。小智项目支持自定义唤醒词我曾经刷过一个模型让设备只认“你好小智”这样就不会跟家里其他语音设备抢答。本地唤醒词识别的本质是把一小段音频频谱特征丢进一个轻量级神经网络模型里让它输出两个概率是唤醒词或者不是。这个模型经过量化后体积通常在几十KB到几百KB之间在ESP32S3上跑一次推理的耗时大约在几十毫秒。整个推理过程只消耗芯片本地算力和内存不产生任何网络请求。这一条就是“断网后还能唤醒”的根本原因。模型在设备里、数据在设备里、推理也在设备里整个过程对外部环境没有任何依赖。服务端就算完全离线这段本地推理依然能稳定输出。2.3 唤醒后的音频上传第一道真实依赖网络的门槛一旦WakeNet检测到“小智小智”这个唤醒词设备状态就会从“监听”切换为“工作”。此时ESP32会把从用户说出唤醒词之后采集到的后续音频一般是跟在唤醒词后面的那几秒语音编码成音频流通过WiFi上传到配置好的服务端地址。这一步就是第一个真正依赖网络的环节。断网时表现非常干脆TCP连接建立失败要么报错要么超时后会进入设备预设的断网处理分支。很多固件在这个阶段会播放一段提示音或者直接停止录音避免做无用功。这里有个容易踩的坑有些网络环境下WiFi信号很差但不是完全断网TCP请求超时时间会被拉得特别长。设备表现就是唤醒有反应但转圈好几秒才提示失败。我实际使用中会把MQTT连接断线重连的超时时间调短一些让设备在低质量网络下能更快进入“离线状态”而不是长时间卡死。2.4 服务端处理ASR识别、语义理解与TTS合成音频成功上传到服务端之后服务端会依次完成三个任务ASR语音识别把16kHz的音频片段转换成文字这一步一般使用专门训练的中文语音识别模型也有部分方案会先做VAD切分再逐段识别。语义理解与响应生成文字进入对话引擎比如接入大语言模型生成回答文本。这一阶段往往还会配合技能插件比如查天气、控制智能家居、播放音乐等。TTS语音合成回答文本转成音频通常编码成MP3或Opus流再通过网络下发给设备端播放。这三个任务全部需要联网。ASR和TTS有些场景可以做本地模型但小智服务端默认使用的是云端算力因为它要支撑更复杂的对话。断网状态下服务端的处理链路上传第一步就断了后面自然无从谈起。2.5 设备端播放回复本地解码但依赖远端数据服务端把TTS音频流推回设备之后ESP32需要解码音频流再通过I2S总线输出到功放芯片比如MAX98357A最后由喇叭放出来。这一步的“解码播放”本身是本地动作但音频数据来源是网络。所以严格来说播放环节也需要依赖网络只不过断网时设备端的表现往往是“静默”而不是“播放失败”。我曾经试过在播放TTS的过程中直接把路由器关掉结果设备在播完当前这一句之后下一句就卡住大概过了几秒才进入错误处理逻辑。这说明音频流是边下边播的流式传输网络中断后缓冲区的数据播完播放自然就停了。到这一次完整的唤醒链路就算切完了。你会发现实际对网络有依赖的环节主要有三个音频上传、服务端处理、音频回传。而不是许多人以为的“整个过程都需要联网”。这个认知差异正是断网测试里很多“奇怪现象”的答案。3. 拔掉网线那一刻逐模块验证断网后的真实表现说再多原理都不如直接把网断掉实测一轮。我搭了一个简单的测试环境把路由器WiFi禁用掉或者直接拔掉设备电源转USB口的网线如果你用的是有线供电模块的话。反正只要让设备处于彻底没有网络的状态就行。下面是我逐模块记录到的真实表现。3.1 唤醒词模块在断网时的响应速度与表现先测唤醒词。断电重连后在完全无网环境下说“小智小智”设备依然会快速响应——LED亮起、状态切换、播放预设的“叮”提示音。从说出唤醒词到设备给出反馈目测延迟在300毫秒左右跟有网状态几乎没有差别。这说明本地唤醒路径完全独立。我又专门打开串口监视器看了一眼日志设备本地打印了唤醒事件并记录了音量大小、唤醒分数这些调试信息。这个唤醒分数很有参考价值它表示模型对“这是唤醒词”这一判断的置信度。得分越高说明模型越确定。我调整唤醒词灵敏度的时候就会盯着这个分数来调一般情况下超过0.5就算触发想更灵敏就调到0.3左右。顺带一提断网唤醒后设备并不会主动提示“我断网了”。很多固件默认是静默等待用户下一句指令直到发现音频无法上传才会报错。这就会造成“我说了小智小智它应了然后我正常说话它又不理我”的误会。如果你打算给设备加一个断网指示灯或者离线提示音应该在这个状态切换点做。3.2 断网时连续对话与技能调用的失败分支唤醒之后紧接着测试连续对话。比如我对设备说“小智小智明天天气怎么样”在断网状态下设备可能的表现有两种一是直接进入超时然后播报“网络连接异常”二是迟迟没有反应直到最后才失败。这两种表现取决于固件版本和服务端连接策略。我在测试中发现小智项目里对网络异常其实有做检测逻辑设备会先判断MQTT连接是否正常如果断开就直接走本地错误处理不再浪费时间去尝试上传音频。这个设计比较合理至少不会让用户傻等。但不同分支固件可能会有差异建议拿到设备后先做一次断网测试搞清楚自己这套固件的失败表现是什么才不会在真正断网时误以为设备坏了。还有一种比较特殊的情况WiFi信号弱但没完全断开设备以为自己在网实际上请求一直在超时重试。这种“半死半活”的网络状态比彻底断网更难受。排查时可以用串口日志看MQTT的心跳重连间隔如果发现心跳反复失败基本就能判定是网络质量问题而不是代码问题。3.3 本地输入输出通道GPIO控制与本地提示音仍然可用断网环境下设备虽然不能理解复杂的自然语言指令但本地输入输出通道仍然全部在线。我实测过两件事第一GPIO控制。我提前在固件里加了一个逻辑当唤醒词被触发且网络不可用时直接点亮板载RGBLED的红色灯并输出一个低电平脉冲控制外围继电器。这样即使断网设备也可以作为一个本地语音开关来用。第二本地提示音。通过播放器模块播放预先烧录在Flash里的短音频比如“网络不可用”或自定义的“我在但连不上网”这个播放动作不依赖网络。ESP32的Flash里可以预留一小段资源区域专门放这种离线提示音断网时直接从Flash读取播放效果非常稳定。这两条验证了什么验证了设备端的“状态感知能力”和“本地执行能力”在断网时依然存在。问题只在于服务端那套“理解自然语言并决策”的核心智能暂时缺席。所以小智断网后并不是一台砖头而更像一个只能听懂固定触发词句的简陋语音开关。3.4 实测结论表断网对各功能模块的影响功能模块归属方断网影响实际表现麦克风音频采集设备端无影响持续工作可正常采音AFE回声消除噪声抑制设备端无影响开启状态效果不变唤醒词识别设备端无影响正常触发低延迟VAD人声检测设备端无影响正常检测语音段音频流上传设备与服务端之间完全中断连接失败或超时云端ASR/NLU/TTS服务端不可用无法识别与回复音频流回传播放设备端播放、依赖网络中断播完缓冲后卡住GPIO控制、本地提示音设备端无影响正常可用这张表基本上回答了标题里的问题设备端负责“感知与触发”服务端负责“理解与生成”。断网砍掉的只是“理解与生成”但感知与触发这条腿还稳稳站着。4. 为什么唤醒必须留在设备端延迟、功耗与隐私的三笔账既然服务端那么强云端也完全可以做唤醒词识别——设备只负责把麦克风音频全部传到云端由云端判断有没有人喊“小智小智”。从技术上说这不是不行但没有任何一个成熟方案会这么设计。原因集中在这三笔账上。4.1 延迟账本地推理几十毫秒云端往返几百毫秒先说延迟。语音交互对延迟极其敏感从用户说出唤醒词到设备给出视觉或听觉反馈这个时间如果超过500毫秒人就会明显感觉到“迟钝”。而唤醒词识别只是整个交互链路的第一步后面还有ASR、NLU、TTS每一环都在消耗时间。如果唤醒动作放在云端那音频必须先打包、上传、云端推理再把结果返回设备。就算网络状况良好一次消息往返也要消耗100到200毫秒加上云端排队和推理时间整体延迟很容易突破500毫秒。本地推理则不同ESP32S3跑一次量化后的唤醒模型延迟大约50到100毫秒几乎感觉不到。还有一个更实际的问题如果把音频全部传到云端做唤醒意味着设备必须保持一个持续的上行音频流。WiFi环境下的持续上行推流不仅功耗高还会挤占其他应用的带宽在路由器性能一般的时候会非常明显。4.2 功耗账低功耗监听才有意义市面上主打低功耗语音唤醒的设备本质上都是靠“设备端唤醒”来实现的。ESP32在正常工作时功耗不低但可以通过休眠策略把功耗压下来没有人在说话时芯片进入深度睡眠或轻睡眠状态麦克风仍然保持低功耗监听WakeNet以较低功耗模式常驻运行一旦检测到唤醒词芯片被立即唤醒并进入全速工作状态。如果唤醒依赖云端那设备就必须不停地采集音频并通过WiFi发送WiFi收发本身就是功耗大头深度睡眠策略也彻底失效。这会让“低功耗语音唤醒”变成一句空话。我自己试过在ESP32S3上开轻睡眠模式跑WakeNet整机电流大约可以控制在30到50mA左右配合电池可以撑比较久。如果你用18650电池或锂电池供电肯定希望触发唤醒后才进入高功耗状态而不是7x24小时全速跑网络。4.3 隐私账本地唤醒变相过滤了大部分隐私音频隐私是另一个常被忽略的硬理由。如果所有音频都持续传给云端那麦克风采集的所有环境声音都会离开设备包括家人聊天、电视声、键盘声。这样就算服务端完全不记录用户在心理上也无法接受。唤醒词留在设备端好处就体现出来了只有检测到唤醒词之后的那一小段音频才会被上传其余时间的所有声音都只停留在本地处理不会出设备。这个设计本质上是一种“隐私门闩”从物理层面限制了用户语音暴露给服务端的范围。顺带说一句很多智能音箱品牌也把“本地唤醒”作为隐私卖点来宣传小智这类DIY项目能在这方面做到更好因为固件完全可控你甚至可以自己决定唤醒后要不要保存本地音频副本。4.4 那云端在分工里到底扮演什么设备端把唤醒这种“粗活”干完之后云端承担的是“细活”复杂语义理解、大模型对话、知识问答、语音合成。这些都是设备端算力做不了的。尤其是大语言模型参数量动辄几十亿根本不可能塞进MCU。就算以后出现了能在MCU上跑的轻量语言模型能力边界依然远不如云端。所以更准确的说法是设备端负责“什么时候该把耳朵交给云端”服务端负责“接住耳朵之后怎么回应”。这也是当前主流智能语音设备的标准分工不存在谁能完全替代谁的问题。断网时你能享受到的能力取决于设备端固件的功能设计而联网时则能享受整套云端智能这也就是为什么“小智断网后还能唤醒、但不能聊天”本质上是一种合理的架构产物。5. 复现与调校一套可落地的断网实验方法与唤醒参数建议前几节把原理和实测都聊清楚了下面这部分直接上干货如果你也想复现这套断网测试应该怎么操作以及哪些参数值得反复调。5.1 实验准备硬件接线、固件烧录、网络环境先列一份基础硬件清单主控ESP32S3开发板最好带4MB以上Flash和8MB以上PSRAM跑唤醒词加音频处理会更从容麦克风INMP441 I2S数字麦克风功放与喇叭MAX98357A功放模块加一个3W小喇叭供电5V/2A电源避免电流不足导致WiFi掉线或音频失真接线方面INMP441的SD引脚接一个GPIO作为I2S数据输入SCK接BCK引脚WS接LRCLK引脚。不同固件对引脚定义有默认设置烧录前先查清楚自己固件默认的I2S引脚号或者直接改配置重编。固件烧录推荐用乐鑫官方的ESP-IDF环境或者直接用小智项目提供的预编译固件。烧录完成之后第一步不是连接网络而是先用串口工具确认设备启动日志正常麦克风数据能否被正确采集。你可以用串口监视器输出一段音频数据的幅值变化吹口气或拍手看看数值有没有明显波动这样能快速验证硬件通路。5.2 核心测试步骤从设备恢复出厂依赖到拔网线到串口日志分析完整的断网实验流程我建议按下面顺序走设备正常联网完成一次完整语音对话确认全链路工作正常。记录正常情况下唤醒到回复的体感延迟以及串口日志里各阶段的时间戳。关闭路由器WiFi或拔掉设备网线让设备彻底断网。等待大约10秒钟让设备完成TCP断线检测进入离线状态。对设备说唤醒词观察LED、提示音、串口日志有无变化。继续说一句完整指令观察设备是否报错、报什么错、多长时间后报错。用串口日志确认设备是否尝试建立TCP连接、有没有重试记录。重新打开WiFi等待设备自动重连再做一次完整对话确保恢复能力正常。这8步执行完你在脑海中对这套设备断网行为的全貌就有了一个具体模型。如果想把测试做得更细致可以用两个手机热点切来切去模拟“弱网恢复”的场景。5.3 唤醒阈值与灵敏度调整从调试日志里读关键指标不同环境对唤醒灵敏度要求不同。家里比较安静阈值可以设高一些减少误唤醒放在商场、路边等嘈杂环境阈值就应该调低但误唤醒也会增多。在乐鑫WakeNet方案的调试输出里有一个wake_score字段就代表了唤醒得分。我测试时的做法是在安静环境下连说10次“小智小智”记录每次得分再在嘈杂环境下说10次同样内容记录得分。取两组数据的中间值作为阈值基线再往低调一点留出余量。阈值设得太高会出现“喊破喉咙也不理你”的情况设得太低就会出现电视里有人喊“小智”它就抢答的场面。我实际用下来初始阈值设在0.5左右比较稳然后根据家里环境再微调。每调整一次就重新跑一遍两组测试录音确认两个方向的效果都可接受再固化配置。5.4 断网提示音与离线分支的自定义设置如果你希望在断网时设备有明显的提示而不是无声静默可以自己改固件逻辑。在小智项目的代码里设备与服务器之间通信用的是WebSocket或MQTT网络状态的判断可以依据连接状态回调。我在固件里加了一段逻辑当WebSocket连接状态变为断开时播放一个短促的提示音当唤醒触发后且网络仍然不可用时播放另一段“网络断开了我暂时无法理解你的指令”的本地音频。这个音频文件放在SPIFFS分区里通过AudioPlayer的本地文件播放接口调用。这个改动不算复杂却能极大提升断网时的用户体验。毕竟设备给了你唤醒反馈却没有任何说明会让用户以为设备坏了。现在很多商业智能音箱断网时的“鸡生蛋”问题都是因为只做了静默失败没做用户感知处理。5.5 实测调校中的几个大坑最后说几个我实际踩过的坑给后面复现的人提个醒。第一个坑是INMP441的时钟配置。如果I2S采样率配置错误比如实际录到的采样率不是16kHz而是32kHz那唤醒词引擎虽然能跑但识别率会断崖式下降。排查方法是在调试日志里加一段音频频率统计或者用示波器直接看BCK引脚的时钟频率。第二个坑是PSRAM内存不足。跑唤醒词模型加音频缓冲区时需要不少堆内存。如果编译配置里没启用PSRAM设备可能在唤醒后出现随机崩溃。建议在编译配置里明确开启PSRAM并把音频DMA缓冲区分配在PSRAM中留出更多内部SRAM给实时任务。第三个坑是WiFi天线位置。ESP32板载PCB天线对摆放位置很敏感如果设备放在金属机箱里信号可能时断时续断网测出来的数据会非常不稳定。测试时尽量让设备处于开放空间避免把天线被遮挡这样测出来的断网表现才是网络真正断开而不是信号太差导致的假断网。6. 断网场景不是死角离线扩展玩法与后续演进前面验证了断网后设备端的感知能力还在。那这个“断网但没完全断”的状态能不能拿来做一些实际有用的事情我觉得完全可以而且这里头还藏着不少扩展方向。6.1 把唤醒词变成本地指令开关GPIO联动、家电控制、状态提示既然唤醒词触发的本地事件是完全可控的我可以在断网条件下赋予它特定语义。比如设备断网后我说“小智小智”并紧接着说“开灯”或者“关灯”这个指令虽然无法被云端理解但完全可以在设备端做一层轻量级本地关键词匹配。实现思路是在WakeNet触发后开启一小段本地录音窗口对这段音频再做一次轻量级命令词识别。比如用较小的关键词模型识别“开灯”“关灯”“空调开”“空调关”等几个固定指令然后通过GPIO输出电平信号控制继电器或ESPHome设备。我在家里已经试过这个方案路由器断网时小智音响作为一个离线语音控制器出了客厅灯、卧室灯的控制。虽然它听不懂复杂句子但“开灯”“关灯”这种固定指令识别准确率很高实用性相当不错。这个玩法只用了很低的开发成本却让断网不再是一个纯负面事件。6.2 本地语音与局域网设备的联动不连外网也能玩智能家居既然对外网络会断那你完全可以退一步让设备在断外网的情况下还能连局域网。很多智能家居设备走的是MQTT局域网通信服务端就跑在树莓派或NAS上。这种情况下小智AI只要保持WiFi连接路由器就可以通过局域网MQTT协议控制设备根本不需要访问外网。实际操作时我会在断网分支里优先尝试本地MQTT服务器判断本机是否能访问局域网内的MQTT broker。如果能就直接走局域网的指令解析通道如果不能再播放断网提示。这样设备在“断外网”但“局域网可用”的环境中仍然拥有相当完整的能力。唯一的限制是自然语言理解能力。局域网端只能做固定规则的关键词匹配没法像云端大模型那样理解“把灯调暗一点顺便换个颜色”这种复杂指令。但对于开关类、固定场景类的指令已经非常够用。6.3 未来方向端侧小模型、更稳的断网检测与混合交互框架再说远一点。小智这类项目后续的方向大概率是“端侧模型越来越强”。比如在ESP32S3这种带向量指令加速的芯片上跑更复杂的本地意图分类模型甚至跑轻量级的大语言模型蒸馏版。目前一些实验性方案已经在尝试把嵌入式端侧ASR模型跑在STM32和ESP32级别的主控上识别固定指令集已经不是问题。断网检测本身也有优化空间。现在很多实现只有在TCP请求超时之后才能确认断网这个过程要花好几秒。更聪明的做法是维护一个本地网络健康状态机周期性探测服务端心跳一旦心跳连续失败设备立刻进入本地优先模式。这样做的好处是从真正断网到设备识别到断网的时间会被压缩到秒级以内用户在体验上不会感受到“带着网络身份卡死”的窗口期。混合交互框架方面我认为最终形态会是“本地处理一切可处理的云端处理一切需要智慧的”。设备能自主决策的比如固定指令、本地状态查询全部留在本地只有遇到超出本地能力范围的请求才把音频数据上行到云端处理。这种架构不但让设备在断网时更可用也会减轻云端的压力。可以说沿着这次“断网唤醒”实验看到的设备与服务端分工本身就是未来所有端侧智能设备演进的基本逻辑。回到最开始的问题小智断网后还能做什么答案已经很清楚了——它能听懂你在叫它能告诉你它在线却不在云端能执行你预先设好的本地开关指令但暂时接不住复杂的对话。这一半的“失能”不是硬件坏了而是分工体系的取舍。设备端保住了感知和触发的底牌服务端负责聪明应答网络则是这两者之间的桥梁。桥断了底牌还在。如果你也想给自己的小智设备加上离线提示音、本地指令开关或者只是想把断网测试完整跑一遍完全可以拿我这套流程做参考。这些东西改起来并不复杂改完之后你对设备内部的分工边界的理解会比只看说明书的人深得多。
