企业官网建设流程全解析

最近我把工作台上那台自制的语音助手“小智”强制断网了。断网之后它照样能响应唤醒词，也能开关灯、倒计时，但一聊天气、一问百科就直接哑火——这逼着我沿着一次完整的唤醒过程，把设备端和服务端的分工重新捋了一遍。折腾几天下来，光是日志就看了几十屏，最后结论挺有意思：断网不可怕，可怕的是设计时根本没想过设备离线后该干嘛。这篇就当一次踩坑笔记，给同样在做语音助手、物联网设备或者边缘智能项目的朋友参考。

“小智”本身不复杂，硬件就是一块 ESP32-S3 加一块 INMP441 麦克风，外接继电器和扬声器，跑本地唤醒词模型，再接一个简单 HTTP 服务做云端语义处理。这类结构在现在的智能音箱、智能家居终端里非常常见，所以整个排查思路和设计取舍应该能直接迁移到你的项目里。我尽量把这几天踩过的坑、想明白的道理、实测到的数据都写清楚。

1. 一声“小智”背后，设备端与服务端的完整分工

1.1 唤醒之前：本地音频管道和低功耗设计

很多人以为“唤醒”是网络请求触发的，实际上完全不是。在“小智”这个设备上，唤醒词检测整个过程都在本地芯片上完成，和云端一毛钱关系都没有。

硬件链路是这样的：INMP441 麦克风通过 I2S 接口持续采样，采样率 16kHz、16bit、单声道，数据不断写入 DMA 环形缓冲区。这块 ESP32-S3 上跑着一个量化后的唤醒词模型，模型输入是最近 1.5 到 2 秒的音频切片，输出就是“是否有人喊了小智”。语音唤醒的模型我用过 onnx-wakeword 那一套思路，也试过自己训练一个极小的关键词分类器，本质都一样：在端侧用低精度推理做二分类，只认“小智”这两个音节。

为什么唤醒必须放在本地？三个原因非常现实。第一是时延，本地推理一次大概几十毫秒，如果先把音频传到服务器再等结果，最顺利也要一秒钟起步，用户连续喊两三遍设备还不动，体验直接崩。第二是隐私，唤醒词前后的音频片段其实都属于敏感数据，只要在本地处理完且不被上传，至少用户心里能踏实一点。第三就是断网可用性，这也是我今天要重点聊的，唤醒是设备最后的“本地能力底线”，如果连唤醒都要联网，那设备断网就真的成了砖头。

这里顺带提一句低功耗语音唤醒。我最初版本是让 ESP32 一直以全速跑音频采集和推理，实测电流能到 80 到 100 毫安，用电池供电撑不了多久。后来改成两级唤醒：空闲时主芯片进入深度睡眠，只留一个超低功耗的语音活动检测器监听环境声音，检测到疑似人声再唤醒主芯片去跑唤醒词模型。这个思路和 STM32U575 的 STOP3 模式有点像，都是保留必要外设和 RAM，其余全部断电，只在外部事件到来时快速唤醒。改完以后待机电流压到了微安级，电池续航的问题才算解决。

1.2 唤醒成功那一刻：本地命令先分流

“小智”被唤醒之后，设备会进入一个短暂的“聆听”状态，这时候麦克风继续采集音频，但处理逻辑不一样了。

我设计了一套最简单的命令词分流机制。唤醒后的 3 秒内，设备拿音频去匹配本地命令词表，命令词表里包括“开灯”“关灯”“倒计时五分钟”“现在是几点”“定个闹钟”这类固定句式。命中命令词就直接在本地执行，整个过程中不产生任何网络流量，从唤醒到执行完成大概 150 到 300 毫秒。用户体感就是“刚说完话，灯就开了”。

只有本地命令词表没有命中时，设备才会把音频打成请求发给服务端。服务端那边再接大词表语音识别、自然语言理解、知识库查询，最后把结果转成结构化 JSON 返回。这样做的好处很直接：本地先做一次“能者多劳”，把最简单、最常用、即时性要求最高的活儿都留在设备端，只有真正需要语义理解、动态数据、在线内容时才上云。

我经常用一个“小区门卫”的类比来解释这种分流逻辑。唤醒词识别就像小区门口的保安，先确认来的人是不是住户；一旦确认是住户，小区里能解决的事（比如开门、开灯、倒垃圾）就直接解决，不用每次都给物业总部打电话。只有遇到住户解决不了的问题，比如“今天会不会下雨”，才需要电话联系外部专家。这个类比放在架构里也很贴切：本地能力覆盖得越广，对服务端的依赖就越小，断网后的存活能力也越强。

1.3 服务端返回后，设备端还要做“最后一公里”

当音频真的被送上服务端之后，整条链路就变成经典的客户端-服务端协作模型。

设备端把音频 POST 到服务端接口，服务端先做 ASR 识别成文本，再做 NLU 解析用户意图，然后去天气接口、百科接口或者对话模型那边拿答案，最后返回一个内容相对固定的 JSON。这个 JSON 一般包含意图类型、回答文本、需要执行的设备动作、TTS 播报文本等。设备端拿到之后再做最后一步：解析 JSON，控制 GPIO、播放音频、点亮状态灯。

“最后一公里”特别容易被忽视，但它恰恰是断网时问题最集中的地方。比如服务端返回慢、连接超时、返回格式变了吗、JSON 字段缺失、TTS 音频还没下载完设备就进入休眠，每个环节都能让体验瞬间崩塌。就好比手机上的语音支付，唤醒和生物识别是设备本地完成的，但真正扣款、查余额必须走服务端，中间任何一条链路断了，用户感知到的就是“按下支付没反应”，根本分不清是设备问题还是网络问题。

所以我现在写代码有个习惯：所有发往服务端的请求都要求设置“连接超时”和“读取超时”，并且服务端返回的 JSON 要用 schema 校验，不能默认“服务端永远可靠”。这一课不是从教科书上学来的，是我在断网实测里被一次假死坑出来的，后面第 4 节会详细说。

2. 断网之后设备还剩什么：本地能力与服务端依赖的真实边界

2.1 断网后照样能跑的功能

做了断网实验之后，我才真正把“设备端能力”和“服务端依赖”分清楚。先列一份设备断网后依然正常的清单，这些都是实际验证过的：

• 唤醒词识别：模型跑在本地，完全不依赖网络。
• 本地命令词：“开灯”“关灯”“倒计时”“定闹钟”“播放提示音”，这些逻辑全部在设备状态机里完成。
• 局域网控制：通过本地局域网协议（比如 MQTT）控制同一网段下的其他智能设备，比如把灯、插座、空调这些接到同一个局域网，外网断掉不影响它们之间的通信。
• 本地 RTC 时间：只要设备没彻底断电，RTC 能继续走时；就算断电重启，也会在联网时同步一次并缓存上次校时结果。

关键在于一条判断标准：这个功能所需的“判断依据”和“执行资源”是否都在设备本地。开灯需要的信息是“用户说出开灯”加上“被控设备的地址”，这些都在本机或局域网内，所以断网不影响。倒计时也一样，计时器逻辑完全在本地跑，闹钟到点之后播放一段预置音频，也没有任何外网依赖。

有一个容易被忽略的小点：很多智能设备带“本地场景联动”，比如“天黑自动开灯”“有人移动就录像”，这类自动化如果完全跑在局域网网关或设备内部，断网后仍然有效。我见过不少产品把联动判断放在云端，一旦断网全家设备就像集体失忆，这就是典型的本地能力没设计好。

2.2 一断网就崩的功能

有能跑的，自然就有断网即崩的。整理一下这次“小智”断网后暴露出来的失效功能：

• 大词表语音识别和语义理解：设备本地只放了一个关键词模型，想理解“帮我找个附近开着的川菜馆”这种句子，必须靠服务端的大模型。
• 天气、新闻、百科、股票这类动态信息查询：数据在第三方服务或云端数据库里，设备本地没有持有。
• 在线 TTS：我用的云端语音合成，断网后没有新音频文件可以播报。
• 账号绑定、云同步、设备远程查看：这些天然依赖服务端，断网后全部不可用。

这些能力的共同特点是：数据量太大、计算太复杂或者信息是实时变化的，不可能全部塞进一个嵌入式设备里。就像让一个门店店员背下整个连锁集团的库存系统和客户关系系统，根本不现实，遇到这类问题还是得打电话回总部。

有意思的是，断网实验其实是一种非常高效的产品自检方法。很多产品经理在评审时喜欢在原型图里画“在线”“离线”两套界面，但真正上线后到底哪些功能在断网时会崩，往往没人说得清。我后来做了一个“设备老化测试全自动执行脚本”，把几十条常用指令在断网状态下自动跑一遍，过一遍就生成一份能力清单，谁依赖服务端、谁本地就能干活，一目了然。这个方法也推荐你们试试。

2.3 用户视角：断网后“小智”还能做什么

光说技术边界太抽象，我从用户视角重新描述一下断网后的实际体验。

第一种情况，只是外网断了，但局域网还通。“小智”能正常唤醒，能执行所有本地命令词，也能控制局域网里的灯和插座。你让它“打开客厅灯”，它会立刻照做；你问它“上海天气怎么样”，它会停顿一下，然后说“网络好像出了点问题，我暂时没法查天气，你可以试试其他本地功能”。这种克制而清楚的降级反馈，其实比假装听懂然后胡诌一通要可信得多。

第二种情况，完全离线，局域网也没有。唤醒词和本地命令词仍然正常工作，但所有需要外网的内容都会被拦截，统一回复“网络不可用”。倒计时、闹钟、本地音频播放这些照样好使。换句话说，如果家里断网了，“小智”至少还能当一个带语音控制的定时器和开关面板。

第三种情况，弱网，信号时不时断一下。这是最难受的，因为用户很难判断设备到底听没听到。我实测下来，本地命令命中时基本感觉不到延迟，毕竟不出网；但云端请求就有概率卡在超时边界上，一会儿成功一会儿失败。为了减少这种“薛定谔的响应”，我做了降级策略：连续两次云请求超时，就把设备切到“离线模式”，不再发起云端请求，等健康检查恢复后再切回来。

下面这张表可以更直观地表示三种场景的能力差异：

用户其实不怕功能缺失，怕的是设备毫无反馈地“死掉”。所以断网设计的第一原则不是强行让所有功能可用，而是把能用的留下来，把不能用的明确告诉用户。

3. 一次真实断网实测：从唤醒到响应的全程拆解

3.1 实验环境与三种断网模拟方式

先把实验环境摆出来，方便想复现的朋友对照。

设备端用的是一块 ESP32-S3 开发板，搭配 INMP441 麦克风，外接一个继电器模块模拟“开关灯”，还接了一个 I2S 功放模块做语音播报。固件用 C++ 写的，唤醒模型和命令词匹配都在本地，云请求走 HTTP POST 到一个部署在局域网服务器的简单服务端程序上。服务端程序用 Python FastAPI 写，返回意图和播报文本，模拟真实云服务的行为。

我用了三种方式模拟断网，因为“断网”这个词其实很模糊：

• 物理断网：直接把路由器外网网线拔掉，这是彻底离线。
• 路由策略断网：在路由器里禁止外网访问但保留局域网通信，用来模拟“外网断但局域网通”的典型场景。
• DNS 故障：把设备配置的 DNS 服务器改成错误地址，制造“伪断网”。这时候网络接口仍然 up，TCP 连接也能建立，但域名解析必然失败，会让客户端长时间卡住。

第三种方式特别值得提一下。很多开发者在本地联调时遇到过 WSL2 或 Ubuntu 虚拟机“老断网、重启就好”的诡异问题，本质就是网络栈状态不稳定或 DNS 配置异常，应用层看起来像断网，实际上系统又没给任何明确事件。这种“伪断网”恰恰最容易让客户端暴露出超时处理不善的 bug，所以我的实验里专门加了这一项。

3.2 四个场景的实测记录

下面是实际测试时的串口日志，我加了时间戳，方便看到每个环节的耗时。场景顺序是先断网前，再断网后。

场景一，断网前，“小智，现在几点了”：

[19:00:01.123] wake word detected: xiao_zhi [19:00:01.178] local intent matched: query_time [19:00:01.203] local rtc time: 19:00:01 [19:00:01.214] tts_play: /sdcard/audio/time_190001.wav [19:00:01.351] done

这里从检测到唤醒词到最后播报完成，只用了 228 毫秒，全程没有任何网络请求，纯粹是本地能力。

场景二，断网前，“小智，打开客厅灯”：

[19:01:05.042] wake word detected: xiao_zhi [19:01:05.097] local intent matched: turn_on_light [19:01:05.113] mqtt publish: 192.168.31.50:1883 topic=device/light/cmd payload={"state":"on"} [19:01:05.167] mqtt ack received [19:01:05.180] tts_play: /sdcard/audio/light_on_ok.wav

这个场景走的是局域网协议，主灯设备在同一个网段里，所以即便外部网络已经拔掉，整个链路也完全不受影响。

场景三，断网前，“小智，北京天气怎么样”：

[19:02:10.330] wake word detected: xiao_zhi [19:02:10.385] no local intent matched, start cloud request [19:02:10.401] POST http://192.168.31.100:8000/v1/ai [19:02:12.118] cloud response received [19:02:12.153] cloud intent: query_weather, city=北京 [19:02:12.402] tts_play: /sdcard/audio/weather_download.wav

请求发出到收到响应用了 1.7 秒左右，这个延迟主要在网络和服务端处理。如果用户没有耐心，可能已经以为设备坏了。

场景四，拔掉外网网线后，重复以上三句话：

[19:03:01.230] wake word detected: xiao_zhi [19:03:01.284] local intent matched: query_time [19:03:01.307] tts_play: /sdcard/audio/time_190301.wav [19:03:01.445] done [19:03:20.112] wake word detected: xiao_zhi [19:03:20.167] local intent matched: turn_on_light [19:03:20.181] mqtt publish: 192.168.31.50:1883 topic=device/light/cmd payload={"state":"on"} [19:03:20.236] mqtt ack received [19:03:20.249] tts_play: /sdcard/audio/light_on_ok.wav [19:04:05.502] wake word detected: xiao_zhi [19:04:05.558] no local intent matched, start cloud request [19:04:05.574] POST http://192.168.31.100:8000/v1/ai [19:04:08.582] network timeout, request aborted [19:04:08.590] fallback tts_play: /sdcard/audio/network_error.wav

可以看到，本地命令词和局域网控制在断网前后表现几乎一致，而云端请求在 3 秒后超时，设备播放了降级提示音。整个体验没有卡死，也没有半句话不说的“真空期”。

3.3 从串口日志读到的分工真相

这四段日志放在一起，“设备端和服务端的分工”比任何架构图都直观。

首先，唤醒和本地命令词处理完全不上云。从唤醒词命中到命令执行完成，耗时基本在 300 毫秒以内，这段体验在网络正常时和网络断开时没有任何区别。对用户来说，设备是“可持续响应”的，这种确定性的掌控感是云端能力无法替代的。

其次，云端请求是“尽力而为”的增强能力，不是设备的生命线。本地命令词没命中时，设备才发起云请求；云请求超时后，设备要优雅降级而不是原地等待。真实的断网场景里，用户最怕的就是设备假装沉默，实际上内部已经因为同步阻塞卡死了。

最后，日志还揭示了设计上的一条红线：每个环节都要有明确的时间预算。唤醒多久、命令匹配多久、云请求多久算超时、降级提示多久播完，这些都必须提前定好。我专门把每个环节都打了时间戳，就是为了在问题发生时能快速定位到底慢在哪个模块。

4. 断网实测中的典型问题与排查实录

4.1 断网后设备“假死”：同步阻塞谁背锅

第一次做断网测试时，我最先遇到的是“假死”。现象是断网后喊“小智，北京天气怎么样”，设备沉默大概五秒，然后直接重启，期间再喊多少次唤醒词都没反应。串口日志显示问题发生点非常明确：

[19:10:01.102] wake word detected [19:10:01.160] no local intent matched, start cloud request [19:10:01.175] http_client_send_request // 卡在这里

罪魁祸首是早期代码用了同步 HTTP 请求，而且没设置超时。ESP32 的 Wi-Fi 栈在 DNS 解析失败时并不会立刻返回，而是会一直重试，主循环被http_client_send_request卡住，唤醒检测、LED 刷新、看门狗喂狗全都停了。看门狗超时之后发现主循环没动静，就直接把设备重启了。

这个问题在嵌入式开发里太典型了：不要用同步阻塞的方式访问网络。改法是新建一个异步任务专门处理云请求，主循环保持畅通；所有网络请求都设置连接超时和读取超时，我实际用了 3 秒；再加一个应用层看门狗，如果超过 10 秒没有任何事件处理，就强制回到空闲状态。改完之后再跑断网测试，设备最多沉默 3 秒就播报降级提示，再也不会假死。

其实这类问题和“服务端接口测试”里常见的问题一模一样：客户端把网络请求当成本地函数调用来写，忽略了网络的不确定性。服务端接口再稳，也挡不住客户端自己的超时逻辑有 bug。

4.2 唤醒成功但指令没反应：状态机与音频缓冲的坑

还有个特别隐蔽的 bug，发生在断网之后第二次、第三次唤醒时。现象是“小智”能听见唤醒词，也播放了“叮”的提示音，但说完“开灯”之后设备毫无反应。

排查过程挺折腾。我先以为是命令词表没加载，后来发现不是。反复看代码才发现问题在音频缓冲：唤醒词检测用的环形缓冲区是持续写入的，唤醒成功的瞬间缓冲区内可能还残留着唤醒词之后的半秒环境音和之前的历史音频。命令词匹配器拿到的是包含杂音和唤醒词尾巴的音频段，首尾被截断了，导致“开灯”这两个字根本识别不出来。

解决办法不复杂：唤醒事件触发后，先清空环形缓冲区，再开始收集命令词音频。同时把设备状态机改得更严格一点，从“休眠态”唤醒后必须显式切换到“聆听态”，这一步完成后才允许麦克风数据进入命令词识别模块。另外我还加了一条调试输出，把每次识别到的文字结果和置信度都打出来，这样下一次遇到“听见了但没反应”的情况，能立刻从日志里看出是“没识别到”还是“识别错了”。

这个经验同样适用于其他嵌入式调试场景，比如 STM32 死活不识别 USB 设备、串口打印乱码、设备拔插后无法枚举，很多问题都不是“外设坏了”，而是初始化顺序和缓冲状态没处理好。

4.3 断网恢复后状态对不上：事件补传不能少

另一个让我印象深刻的问题是断网恢复后的状态不一致。有一次我在断网状态下用本地指令关掉了客厅灯，但 App 和服务端依然显示灯是开着的。用户视角就是：“我明明关了灯，为什么手机上一看是开的？”这已经不只是语音助手的问题了，而是所有物联网设备都会遇到的状态同步问题。

根因是我的设备只有在线时才会上报状态，离线期间的状态变化没有任何记录。解决方法是加一个本地事件队列，把设备的关键操作以“事件”的形式持久化，比如时间、操作类型、执行结果、目标设备信息。每次断网恢复后，设备先把缓存的事件按时间戳排序，再逐个 POST 到服务端的事件同步接口。服务端收到事件后更新设备状态，返回确认。为了防重复上报，我还在事件里加了唯一 ID，服务端根据 ID 去重，也就是让接口具备幂等性。

这件事做好之后，“小智”在断网期间做的每个本地操作，最终都能在服务端状态里反映出来，两端回归一致。做设备协议对接或者 EAP 系统现场实施的朋友应该深有体会：设备端主动、可靠地上报状态，是整个系统一致性的地基。如果只靠服务端轮询或者设备在线时顺手同步，断网这个小小的场景就能把系统信誉搞得一团糟。

4.4 断网检测的三种做法与选型对比

断网检测听起来简单，但真正做起来全是坑。我试过三种方案，各有取舍。

第一种是只 ping 网关。实现最简单，但坑也最大：外网断了，只要局域网还通，网关照样能 ping 通，设备根本感知不到“上不了云”。WSL2 或者 Ubuntu 虚拟机里那种“系统显示网络正常但实际访问不了外网”的现象，和这个很像，很多朋友在本地调代码时深受其扰。

第二种是定期 HTTP HEAD 探测服务端健康地址。这种做法能反映真实业务链路的可达性，因为探测目标是服务端域名或者健康检查接口，比 ping 网关准得多。代价是增加了额外的流量和延迟，而且如果探测的地址本身不稳定，容易误判。

第三种是根据业务请求的失败统计来判断。设备在正常流程中每次云请求失败，就记一次“失败计数”，连续 N 次失败就判定为离线；连续几次成功则判定恢复。这种方案最真实，毕竟业务请求能不能通，才是用户真正关心的标准，坏处是判断有滞后，至少要到第一次超时才能发现问题。

我现在实际用的是“业务请求失败统计为主，HTTP 探测为辅”的组合：平时不额外打扰网络，业务失败连续超过 2 次就切弱网模式，连续超过 5 次再切换成离线模式；同时每 30 秒做一次轻量 HTTP 探测，一旦探测成功立刻尝试恢复。给一张选型对比表：

4.5 断网恢复后设备还“懵”着：网络栈复位不能省

还有一个值得记录的坑：断网恢复之后，设备并不一定马上就能正常联网。尤其是物理拔插网线、路由器重启这种场景，Wi-Fi 模块可能已经和路由器断开了关联，但固件里没有处理“断线重连”事件。我一开始在断网测试后恢复网络，发现“小智”还是继续播报“网络不可用”，直到手动重启才恢复。

问题出在 Wi-Fi 层的状态没有及时恢复。我后来在固件里加了网络事件监听，发现 Wi-Fi 断开就触发重连并清空 DNS 缓存；同时应用层健康检查识别到“HTTP 探测成功”后，还会主动做一次完整的网络状态确认，包括重新解析服务端域名。这样网络恢复后，设备最快几秒内就能切回在线模式，不用再依赖重启。

5. 把“断网可用”写进设计：设备端与服务端的协作架构

5.1 本地优先原则：确定性功能不出网

经过这一轮断网实测，我最大的设计心得只有一句话：凡是确定性、实时性要求高的功能，都尽量放在设备本地；只有语义理解、知识问答、动态数据这类真正需要大模型或云端算力的功能，才允许上云。

怎么落地这个原则？我给自己定了两条检查规则。第一，新功能上线前先问一句：“如果没有外网，这个功能还能不能按预期工作？”如果答案是不能，那就要么把它改成本地可执行，要么明确告诉用户它依赖网络。第二，功能列表要分成本地能力和服务端能力两个清单，产品评审时同时看两份清单，而不是只看一张“演示成功”的截图。

“小智”的本地命令词表就是这么设计的。我把开关灯、调亮度、倒计时、闹钟、查询本地时间、播放本地提示音之类的功能全部塞进本地状态机，保证不出网也能闭环。至于“帮我写一段周报”“今天股市怎么样”这类必须靠服务端的任务，才交给云请求。用我上面那个门卫类比来说，就是先把手头能办的事全部办了，再决定要不要打电话求助。

5.2 在线、弱网、离线、恢复：状态机怎么切

有了本地优先原则之后，设备在断网场景下的行为就变成了一套状态机，而不是一堆 if else 的临时判断。我设计了四个基本状态：在线、弱网、离线、恢复中。

• 在线状态：本地命令和云请求都正常，云请求失败计数清零。
• 弱网状态：云请求开始出现失败或超时，但还没到离线阈值。此时仍然允许发起云请求，但本地命令词全部优先响，后台同时做健康探测。
• 离线状态：连续多次云请求失败或健康探测失败，设备进入离线模式。此时完全停止云请求，只响应本地命令词，遇到云服务内容就播放“网络不可用”的提示音。
• 恢复中状态：健康探测成功或局域网连通，设备开始尝试补传离线事件，然后逐步恢复正常云请求。

切换条件我建议用“连续计数”而不是“单次失败”，因为网络本身有抖动，一次超时并不能说明整个网络不可用。实测下来，连续 2 次失败判断弱网、连续 5 次失败判断离线，整体误判率比较低。恢复判断则要保守一点，连续 3 次业务请求成功才切回在线，防止刚恢复又立刻掉线造成来回震荡。

5.3 状态同步与幂等补传：让两端最终一致

最后说说设备端和服务端的数据一致性。很多人做物联网设备时只关心“控制指令下行”，忽略了“设备状态上行”，这导致断网恢复后各种状态漂移。我之前在设备端加了一个 SQLite 表存事件日志，主要字段是事件 ID、时间戳、操作类型、目标对象、执行状态。每次本地命令执行成功后就往表里插一条记录，服务端在线时立刻上报并删除；离线时就攒着，等恢复后按时间戳排序补传。

补传接口必须是幂等的，这个坑我踩过。最开始补传时没有事件 ID，服务端按“时间戳+设备号”去重，结果两条事件在相同一秒内发生就漏掉了。后来每台设备自己生成全局唯一事件 ID，服务端只靠这个 ID 去重，重复上报多少遍都不会产生副作用。这套机制其实和很多设备协议里“状态上报”的设计一致，比如半导体封测设备对接 EAP 系统时，设备状态必须可靠上报到主机，网络中断后也要有补传机制，否则整个产线数据就没法对账。

补传顺序也不能乱。离线期间如果有“开灯”和“关灯”两条事件，顺序反了，服务端最终状态就错了。所以补传前要按时间戳排序，而且服务端处理事件时最好也带一个“事件时间”字段，避免因为网络乱序导致状态错乱。最终两端都收敛到同一个状态，用户不管在 App 上还是设备前看到的结果才是一致的。

断网实测做下来，我个人最大的体会是：断网不是设备的末日，反而是检验设备端与服务端分工是否合理的最好方式。你不需要复杂的测试工具，把网线拔掉，把平时常用的指令挨个说一遍，哪些能秒回、哪些会卡住、哪些直接没反应，一眼就能看出本地兜底做得够不够。后来我每次改“小智”的固件，都会强制跑一轮断网回归，这比任何架构评审都直观。

我现在还在考虑把一个小型语言模型搬到设备端，把更复杂的离线语义理解也做出来。到那时候，“小智”断网后能做的事又会多出一大截。先把这次实验的日志和断网测试流程整理一下，如果有人想照着复刻，后续我再把工程配置和测试脚本单独发出来。