1. 一次唤醒背后的链路拆解小智这类语音交互设备很多人第一次接触都会有一个直觉判断断网了它就是个塑料壳子。我一开始也这么想直到有次家里路由器重启我随口喊了一声唤醒词设备灯效照样亮起、照样哎了一声回应我我才意识到事情没那么简单。这次经历让我认真去梳理了一遍从喊出唤醒词到设备给出反馈这条链路上到底哪些环节跑在设备本地哪些环节必须依赖服务端。先把结论摆出来唤醒这个动作本身绝大多数情况下是纯本地完成的。设备里跑着一个轻量的唤醒词检测模型它只干一件事——持续听环境音判断当前这段音频里有没有出现预设的唤醒词。这个判断不联网、不上传、不依赖任何远程接口。所以你断网之后喊它它依然会亮灯、会应答因为这部分逻辑压根没出过设备。真正断网就废掉的是唤醒之后的那一整套流程。你问它天气、让它放歌、跟它闲聊这些都需要把音频送到服务端做语音识别、语义理解、内容生成再把结果送回来做语音合成。这条链路里任何一环断了设备就只能听见你叫它但听不懂你要干嘛。所以断网后还能做什么这个问题本质上是在问哪些能力被设计在了设备侧哪些被设计在了服务端侧。把这个分工搞清楚你就能预判设备在各种网络状况下的表现也能在选型、调试、排障的时候少走很多弯路。这篇文章我打算沿着一次完整的唤醒过程从麦克风拾音开始一路走到服务端返回结果把每个环节的归属、原理、以及实操中容易踩的坑都讲清楚。不管你是刚拿到设备想搞明白它脾气的新手还是正在做类似产品、需要划分端侧云侧职责的开发者应该都能从里面找到对自己有用的东西。2. 唤醒链路的分工全景2.1 从拾音到唤醒的本地闭环一次唤醒的完整本地链路大致是这样的麦克风持续采集环境音频音频经过降噪和增益处理后送入唤醒词检测模块。这个模块通常是一个很小的神经网络参数量被压得很低为的是能在资源受限的芯片上实时运行。它输出的不是文字而是一个概率值——当前音频片段是唤醒词的概率有多高。超过阈值就触发唤醒事件。这条链路有几个关键特征值得注意。第一它是常驻运行的设备通电后这个检测循环就一直在跑功耗被压到很低靠的是芯片的低功耗音频采集能力和轻量模型。第二它是纯本地的音频数据在设备内部处理完就丢弃不会因为唤醒这个动作本身而产生任何网络请求。第三它的准确率和误唤醒率是一对矛盾阈值调低了容易误触发调高了又可能喊好几遍没反应。我实测过几款不同方案的小智类设备唤醒响应时间普遍在 200 到 500 毫秒之间这个延迟主要来自音频缓冲窗口的大小。窗口越大判断越准但响应越慢窗口越小响应越快但容易漏检。厂商在这个点上做的取舍直接决定了你喊它的手感。2.2 唤醒之后服务端接管了什么唤醒事件触发后设备进入对话模式这时候分工就变了。设备负责录音、编码、上传服务端负责识别、理解、生成、合成最后设备负责播放。整个流程可以拆成这么几段环节执行位置断网后是否可用说明唤醒词检测设备本地可用纯本地模型不联网唤醒反馈灯效/提示音设备本地可用本地资源触发录音与编码设备本地可用录了也传不出去语音识别ASR服务端不可用需要上传音频语义理解NLU服务端不可用依赖识别结果内容生成服务端不可用大模型或规则引擎语音合成TTS服务端为主部分可用本地合成能力有限音频播放设备本地可用播放本地缓存内容这张表基本就是断网后设备能力的边界。你能看到设备侧保留的是感知和表达的入口服务端承担的是理解和思考的核心。断网切断的是中间那段两头其实都还在。2.3 为什么这样分工是合理的有人可能会问为什么不把识别和理解也放到设备上做成完全离线的设备这个问题我在做方案选型的时候反复想过答案其实很现实算力和成本。语音识别和大模型推理对算力的要求跟唤醒词检测完全不是一个量级。唤醒模型可能只有几十 KB 到几百 KB而一个能用的语音识别模型动辄几十 MB 起步大模型更是以 GB 计。把这些塞进一个几十块钱的芯片里还要保证实时性和功耗目前不现实。所以行业里普遍的做法就是把最轻、最需要实时响应的部分放端侧把最重、最需要灵活更新的部分放云侧。这个分工还有个额外好处——服务端的能力可以随时升级。今天换个更好的识别模型明天接个更强的大模型设备端一行代码不用改用户体验就提升了。如果全塞在设备里每次升级都得推固件那才是噩梦。理解了这层逻辑你再看断网后还能做什么就不会觉得是设备残废了而是它本来就被设计成这个样子——端侧保底云侧增强。3. 端侧到底留了哪些家底3.1 唤醒模型是怎么塞进小芯片的唤醒模型能跑在设备上核心在于它足够小。这类模型通常是深度可分离卷积或者轻量循环网络的变体输入是音频的梅尔频谱特征输出是一个二分类概率。整个模型的参数量被压到几十 KB 级别量化之后还能更小。我拆过一个类似方案的固件唤醒模型文件大概 80 KB 左右加上特征提取和推理框架整个唤醒模块占用的内存不到 200 KB。这个体量放在一颗带几百 KB SRAM 的芯片上完全跑得动。推理一帧的时间在几毫秒级别功耗也压得住。这里有个实操细节唤醒模型对麦克风的一致性很敏感。同一套模型换一个灵敏度不同的麦克风唤醒率可能差出一大截。所以如果你是自己搭硬件麦克风的选型和增益配置要跟模型训练时的假设对齐否则会出现别人喊得动你喊不动的情况。3.2 本地能播放的内容从哪来断网之后设备虽然不能生成新内容但本地存储里的音频还是能播的。常见的有几类唤醒提示音、固定的应答语比如我在网络好像不太行、本地缓存的音乐或故事文件。我见过一些做得比较细的方案会在设备里预置一批离线应答断网时根据简单规则匹配。比如你问现在几点如果设备有本地时钟它可以直接用本地合成的语音报时不需要联网。这种降级可用的设计体验上比直接来一句网络异常要好得多。不过要注意本地 TTS 的音质和自然度通常远不如云端。云端合成可以用更大的模型、更丰富的韵律本地合成为了省资源往往就是拼接或者轻量模型听起来会比较机械。这是断网场景下必须接受的妥协。3.3 本地缓存与状态保持设备在联网时通常会缓存一些状态和内容到本地断网后这些缓存就成了家底。常见的包括最近播放的音乐列表、用户偏好设置、设备配网信息、以及一些常用指令的本地映射。我实测过一个场景设备联网时放过某首歌断网后再喊播放它有时候能从本地缓存里把这首歌放出来。这不是因为它记得而是因为音频文件被缓存到了本地存储。这个行为取决于具体实现不是所有设备都这么做但如果你在做产品设计主动做一层内容缓存能显著提升断网时的可用性。4. 服务端承担的重量级工作4.1 语音识别把声音变成文字服务端接到的第一件事是设备上传的音频流。语音识别模块要把这段音频转成文字这是后续所有理解的前提。这一步对算力和模型的要求很高尤其是要处理各种口音、环境噪声、语速变化。从设备到服务端音频通常会被压缩编码后再传常见的是 Opus 或者类似的低码率编码为的是省带宽、降延迟。服务端收到后先解码再做识别。整个往返的延迟好的方案能压到几百毫秒差的可能一两秒用户体感差别很大。这里有个容易被忽略的点音频上传的时机。有些方案是唤醒后立刻开始上传有些是等检测到语音结束再上传。前者延迟低但可能传了废话后者省流量但响应慢。这个策略的选择直接影响断网瞬间的行为——如果设备正在上传网络断了这次对话就废了。4.2 语义理解与内容生成识别出文字之后服务端要做的是理解用户意图然后生成回复。这一步现在越来越多地交给大模型来做因为大模型能处理更开放、更灵活的对话。但大模型推理的成本和延迟都不低所以很多产品会在前面加一层意图识别简单指令走规则复杂对话才走大模型。这个分层设计对断网场景其实有启发如果设备端能承担一部分简单意图的本地匹配断网时就能多撑一会儿。比如开灯关灯这种固定指令完全可以在本地做关键词匹配不需要联网。我见过一些方案就是这么做的断网后基础控制还能用体验上是个加分项。4.3 语音合成与回传生成好的回复文本要再经过语音合成变成音频传回设备播放。这一步同样在服务端完成因为高质量的 TTS 模型体积大、算力需求高。合成好的音频流回传到设备设备解码播放一次对话才算闭环。整个链路的延迟分布大致是录音编码几十毫秒上传几十到几百毫秒识别几百毫秒理解生成几百毫秒到几秒合成几百毫秒回传几十到几百毫秒。加起来一次完整对话的响应时间在一秒到几秒之间。断网的话这条链路在上传这一步就断了后面的全都无从谈起。5. 断网场景的实测与排查5.1 断网后设备行为的实测记录我专门做过一组断网测试把设备所在网络断开然后观察它的各种反应。结果整理成下面这张表操作断网后表现原因喊唤醒词正常亮灯应答唤醒在本地问天气提示网络异常或长时间无响应需要联网查询让它放本地缓存的歌部分设备可播放依赖本地缓存问时间部分设备可本地报时依赖本地时钟和TTS连续对话第一次后无响应后续全依赖服务端设备配网无法进行需要联网配置这张表里最值得说的是连续对话。很多设备唤醒后进入一个短暂的对话窗口这个窗口内你可以连续提问。但断网后第一次提问就会卡住因为设备在等服务端返回等不到就一直等窗口超时后回到待唤醒状态。所以断网时你会感觉喊得应但问不动。5.2 常见问题速查在实际调试和用户反馈里我整理了几个高频问题附上排查思路问题一断网后喊唤醒词没反应。先确认是不是真的断网导致的。唤醒是本地行为理论上断网不影响。如果没反应可能是设备进入了某种低功耗休眠或者唤醒模型因为固件问题没加载。排查方法是看设备指示灯正常待机应该有特定灯效如果灯都不亮那是供电或固件问题跟网络无关。问题二断网后唤醒有反应但一直思考中。这是最典型的表现。设备唤醒了开始录音上传但网络不通上传超时设备在等服务端响应。排查方法是看设备是否有超时机制好的实现应该在几秒后主动放弃并提示网络异常差的实现会一直卡着。这个取决于固件质量用户侧能做的就是等它超时或者重启设备。问题三网络恢复后设备不自动重连。有些设备断网后不会主动重试需要重启或者重新配网。这是固件的重连策略问题。排查方法是看设备是否支持自动重连以及重连的间隔策略。如果频繁断网建议检查路由器稳定性而不是怪设备。问题四断网时本地缓存内容放不出来。确认设备是否真的有本地缓存。很多设备宣传支持离线播放但实际缓存的内容很有限或者缓存策略是播放过才缓存。这种情况只能靠提前联网播放来养缓存。5.3 实操避坑心得做了这么多测试有几个心得是文档里不会写的分享出来提示判断一个设备断网后能干什么最快的办法是拔掉网线或者关掉路由器然后把它所有能想到的指令都试一遍记录哪些有反应、哪些没反应。这比看任何参数表都直观。第一个心得是别把唤醒有反应当成设备正常。唤醒是本地行为它只能证明设备通电、麦克风工作、唤醒模型加载了证明不了网络和服务端链路是通的。很多用户看到设备应答了就以为网络没问题结果一问就卡住白白浪费时间排查。第二个心得是断网测试要分阶段做。先测纯断网完全没网再测弱网有网但很慢这两种情况设备的表现可能完全不同。弱网下设备可能能连上但超时表现是偶尔能用偶尔不能用比纯断网更难排查。第三个心得是关注设备的超时和降级策略。好的设备在断网时会快速失败并给出明确提示差的设备会一直卡着让你以为死机了。这个差异在选购和自研时都是重要考量。6. 从分工看设备选型与自研6.1 选型时该看哪些指标如果你要选一款小智类设备又比较在意断网场景的可用性我建议重点看这几个指标本地唤醒的响应速度和误唤醒率这决定了基础体验跟网络无关但很重要。本地缓存策略支持缓存多少内容、缓存什么类型决定了断网后能放什么。断网提示的明确程度是明确告诉你网络异常还是默默卡住体验差别很大。自动重连能力网络恢复后能否自动恢复不需要人工干预。本地指令支持范围有没有把一些高频简单指令做成本地匹配。这几个指标里前两个是硬件和固件决定的后三个更多是软件策略。选型时如果能拿到样机一定要做断网实测别只看宣传。6.2 自研时的端云职责划分建议如果你正在做类似产品需要划分端侧和云侧的职责我的建议是遵循能本地就本地该云端就云端的原则具体可以这样分端侧负责唤醒词检测、音频采集与编码、本地缓存播放、简单指令的本地匹配、网络状态监测与降级提示、断网时的基础反馈。云侧负责语音识别、语义理解、内容生成、语音合成、内容更新与个性化、复杂对话管理。这个划分的关键在于把实时性要求高、算力要求低的放端侧把算力要求高、可以容忍一定延迟的放云侧。唤醒必须实时所以放端侧识别和理解可以容忍几百毫秒延迟所以放云侧。还有一点很重要端侧一定要有网络状态感知和降级能力。设备应该知道自己现在能不能联网联网时走完整链路断网时走降级路径而不是傻等着超时。这个设计能极大提升断网时的体验。6.3 一个容易被忽略的细节唤醒后的状态机最后说一个细节是我在调试时发现的。设备唤醒后其实进入了一个状态机待唤醒 - 唤醒 - 录音 - 上传 - 等待响应 - 播放 - 回到待唤醒。断网时这个状态机卡在上传或等待响应这一步。好的实现会给每个状态设置超时超时后回到待唤醒并给出提示。差的实现可能就卡死在那里需要重启。如果你在自研一定要给状态机的每个状态设计超时和异常处理这是保证断网体验的基础。我见过太多设备因为没处理好这个断网后直接假死用户以为坏了其实只是状态没复位。这个状态机的设计思路其实也适用于任何依赖远程服务的设备。核心就一句话永远假设网络会断并为断网准备好退路。
1. 一次唤醒背后的链路拆解小智这类语音交互设备很多人第一次接触都会有一个直觉判断断网了它就是个塑料壳子。我一开始也这么想直到有次家里路由器重启我随口喊了一声唤醒词设备灯效照样亮起、照样哎了一声回应我我才意识到事情没那么简单。这次经历让我认真去梳理了一遍从喊出唤醒词到设备给出反馈这条链路上到底哪些环节跑在设备本地哪些环节必须依赖服务端。先把结论摆出来唤醒这个动作本身绝大多数情况下是纯本地完成的。设备里跑着一个轻量的唤醒词检测模型它只干一件事——持续听环境音判断当前这段音频里有没有出现预设的唤醒词。这个判断不联网、不上传、不依赖任何远程接口。所以你断网之后喊它它依然会亮灯、会应答因为这部分逻辑压根没出过设备。真正断网就废掉的是唤醒之后的那一整套流程。你问它天气、让它放歌、跟它闲聊这些都需要把音频送到服务端做语音识别、语义理解、内容生成再把结果送回来做语音合成。这条链路里任何一环断了设备就只能听见你叫它但听不懂你要干嘛。所以断网后还能做什么这个问题本质上是在问哪些能力被设计在了设备侧哪些被设计在了服务端侧。把这个分工搞清楚你就能预判设备在各种网络状况下的表现也能在选型、调试、排障的时候少走很多弯路。这篇文章我打算沿着一次完整的唤醒过程从麦克风拾音开始一路走到服务端返回结果把每个环节的归属、原理、以及实操中容易踩的坑都讲清楚。不管你是刚拿到设备想搞明白它脾气的新手还是正在做类似产品、需要划分端侧云侧职责的开发者应该都能从里面找到对自己有用的东西。2. 唤醒链路的分工全景2.1 从拾音到唤醒的本地闭环一次唤醒的完整本地链路大致是这样的麦克风持续采集环境音频音频经过降噪和增益处理后送入唤醒词检测模块。这个模块通常是一个很小的神经网络参数量被压得很低为的是能在资源受限的芯片上实时运行。它输出的不是文字而是一个概率值——当前音频片段是唤醒词的概率有多高。超过阈值就触发唤醒事件。这条链路有几个关键特征值得注意。第一它是常驻运行的设备通电后这个检测循环就一直在跑功耗被压到很低靠的是芯片的低功耗音频采集能力和轻量模型。第二它是纯本地的音频数据在设备内部处理完就丢弃不会因为唤醒这个动作本身而产生任何网络请求。第三它的准确率和误唤醒率是一对矛盾阈值调低了容易误触发调高了又可能喊好几遍没反应。我实测过几款不同方案的小智类设备唤醒响应时间普遍在 200 到 500 毫秒之间这个延迟主要来自音频缓冲窗口的大小。窗口越大判断越准但响应越慢窗口越小响应越快但容易漏检。厂商在这个点上做的取舍直接决定了你喊它的手感。2.2 唤醒之后服务端接管了什么唤醒事件触发后设备进入对话模式这时候分工就变了。设备负责录音、编码、上传服务端负责识别、理解、生成、合成最后设备负责播放。整个流程可以拆成这么几段环节执行位置断网后是否可用说明唤醒词检测设备本地可用纯本地模型不联网唤醒反馈灯效/提示音设备本地可用本地资源触发录音与编码设备本地可用录了也传不出去语音识别ASR服务端不可用需要上传音频语义理解NLU服务端不可用依赖识别结果内容生成服务端不可用大模型或规则引擎语音合成TTS服务端为主部分可用本地合成能力有限音频播放设备本地可用播放本地缓存内容这张表基本就是断网后设备能力的边界。你能看到设备侧保留的是感知和表达的入口服务端承担的是理解和思考的核心。断网切断的是中间那段两头其实都还在。2.3 为什么这样分工是合理的有人可能会问为什么不把识别和理解也放到设备上做成完全离线的设备这个问题我在做方案选型的时候反复想过答案其实很现实算力和成本。语音识别和大模型推理对算力的要求跟唤醒词检测完全不是一个量级。唤醒模型可能只有几十 KB 到几百 KB而一个能用的语音识别模型动辄几十 MB 起步大模型更是以 GB 计。把这些塞进一个几十块钱的芯片里还要保证实时性和功耗目前不现实。所以行业里普遍的做法就是把最轻、最需要实时响应的部分放端侧把最重、最需要灵活更新的部分放云侧。这个分工还有个额外好处——服务端的能力可以随时升级。今天换个更好的识别模型明天接个更强的大模型设备端一行代码不用改用户体验就提升了。如果全塞在设备里每次升级都得推固件那才是噩梦。理解了这层逻辑你再看断网后还能做什么就不会觉得是设备残废了而是它本来就被设计成这个样子——端侧保底云侧增强。3. 端侧到底留了哪些家底3.1 唤醒模型是怎么塞进小芯片的唤醒模型能跑在设备上核心在于它足够小。这类模型通常是深度可分离卷积或者轻量循环网络的变体输入是音频的梅尔频谱特征输出是一个二分类概率。整个模型的参数量被压到几十 KB 级别量化之后还能更小。我拆过一个类似方案的固件唤醒模型文件大概 80 KB 左右加上特征提取和推理框架整个唤醒模块占用的内存不到 200 KB。这个体量放在一颗带几百 KB SRAM 的芯片上完全跑得动。推理一帧的时间在几毫秒级别功耗也压得住。这里有个实操细节唤醒模型对麦克风的一致性很敏感。同一套模型换一个灵敏度不同的麦克风唤醒率可能差出一大截。所以如果你是自己搭硬件麦克风的选型和增益配置要跟模型训练时的假设对齐否则会出现别人喊得动你喊不动的情况。3.2 本地能播放的内容从哪来断网之后设备虽然不能生成新内容但本地存储里的音频还是能播的。常见的有几类唤醒提示音、固定的应答语比如我在网络好像不太行、本地缓存的音乐或故事文件。我见过一些做得比较细的方案会在设备里预置一批离线应答断网时根据简单规则匹配。比如你问现在几点如果设备有本地时钟它可以直接用本地合成的语音报时不需要联网。这种降级可用的设计体验上比直接来一句网络异常要好得多。不过要注意本地 TTS 的音质和自然度通常远不如云端。云端合成可以用更大的模型、更丰富的韵律本地合成为了省资源往往就是拼接或者轻量模型听起来会比较机械。这是断网场景下必须接受的妥协。3.3 本地缓存与状态保持设备在联网时通常会缓存一些状态和内容到本地断网后这些缓存就成了家底。常见的包括最近播放的音乐列表、用户偏好设置、设备配网信息、以及一些常用指令的本地映射。我实测过一个场景设备联网时放过某首歌断网后再喊播放它有时候能从本地缓存里把这首歌放出来。这不是因为它记得而是因为音频文件被缓存到了本地存储。这个行为取决于具体实现不是所有设备都这么做但如果你在做产品设计主动做一层内容缓存能显著提升断网时的可用性。4. 服务端承担的重量级工作4.1 语音识别把声音变成文字服务端接到的第一件事是设备上传的音频流。语音识别模块要把这段音频转成文字这是后续所有理解的前提。这一步对算力和模型的要求很高尤其是要处理各种口音、环境噪声、语速变化。从设备到服务端音频通常会被压缩编码后再传常见的是 Opus 或者类似的低码率编码为的是省带宽、降延迟。服务端收到后先解码再做识别。整个往返的延迟好的方案能压到几百毫秒差的可能一两秒用户体感差别很大。这里有个容易被忽略的点音频上传的时机。有些方案是唤醒后立刻开始上传有些是等检测到语音结束再上传。前者延迟低但可能传了废话后者省流量但响应慢。这个策略的选择直接影响断网瞬间的行为——如果设备正在上传网络断了这次对话就废了。4.2 语义理解与内容生成识别出文字之后服务端要做的是理解用户意图然后生成回复。这一步现在越来越多地交给大模型来做因为大模型能处理更开放、更灵活的对话。但大模型推理的成本和延迟都不低所以很多产品会在前面加一层意图识别简单指令走规则复杂对话才走大模型。这个分层设计对断网场景其实有启发如果设备端能承担一部分简单意图的本地匹配断网时就能多撑一会儿。比如开灯关灯这种固定指令完全可以在本地做关键词匹配不需要联网。我见过一些方案就是这么做的断网后基础控制还能用体验上是个加分项。4.3 语音合成与回传生成好的回复文本要再经过语音合成变成音频传回设备播放。这一步同样在服务端完成因为高质量的 TTS 模型体积大、算力需求高。合成好的音频流回传到设备设备解码播放一次对话才算闭环。整个链路的延迟分布大致是录音编码几十毫秒上传几十到几百毫秒识别几百毫秒理解生成几百毫秒到几秒合成几百毫秒回传几十到几百毫秒。加起来一次完整对话的响应时间在一秒到几秒之间。断网的话这条链路在上传这一步就断了后面的全都无从谈起。5. 断网场景的实测与排查5.1 断网后设备行为的实测记录我专门做过一组断网测试把设备所在网络断开然后观察它的各种反应。结果整理成下面这张表操作断网后表现原因喊唤醒词正常亮灯应答唤醒在本地问天气提示网络异常或长时间无响应需要联网查询让它放本地缓存的歌部分设备可播放依赖本地缓存问时间部分设备可本地报时依赖本地时钟和TTS连续对话第一次后无响应后续全依赖服务端设备配网无法进行需要联网配置这张表里最值得说的是连续对话。很多设备唤醒后进入一个短暂的对话窗口这个窗口内你可以连续提问。但断网后第一次提问就会卡住因为设备在等服务端返回等不到就一直等窗口超时后回到待唤醒状态。所以断网时你会感觉喊得应但问不动。5.2 常见问题速查在实际调试和用户反馈里我整理了几个高频问题附上排查思路问题一断网后喊唤醒词没反应。先确认是不是真的断网导致的。唤醒是本地行为理论上断网不影响。如果没反应可能是设备进入了某种低功耗休眠或者唤醒模型因为固件问题没加载。排查方法是看设备指示灯正常待机应该有特定灯效如果灯都不亮那是供电或固件问题跟网络无关。问题二断网后唤醒有反应但一直思考中。这是最典型的表现。设备唤醒了开始录音上传但网络不通上传超时设备在等服务端响应。排查方法是看设备是否有超时机制好的实现应该在几秒后主动放弃并提示网络异常差的实现会一直卡着。这个取决于固件质量用户侧能做的就是等它超时或者重启设备。问题三网络恢复后设备不自动重连。有些设备断网后不会主动重试需要重启或者重新配网。这是固件的重连策略问题。排查方法是看设备是否支持自动重连以及重连的间隔策略。如果频繁断网建议检查路由器稳定性而不是怪设备。问题四断网时本地缓存内容放不出来。确认设备是否真的有本地缓存。很多设备宣传支持离线播放但实际缓存的内容很有限或者缓存策略是播放过才缓存。这种情况只能靠提前联网播放来养缓存。5.3 实操避坑心得做了这么多测试有几个心得是文档里不会写的分享出来提示判断一个设备断网后能干什么最快的办法是拔掉网线或者关掉路由器然后把它所有能想到的指令都试一遍记录哪些有反应、哪些没反应。这比看任何参数表都直观。第一个心得是别把唤醒有反应当成设备正常。唤醒是本地行为它只能证明设备通电、麦克风工作、唤醒模型加载了证明不了网络和服务端链路是通的。很多用户看到设备应答了就以为网络没问题结果一问就卡住白白浪费时间排查。第二个心得是断网测试要分阶段做。先测纯断网完全没网再测弱网有网但很慢这两种情况设备的表现可能完全不同。弱网下设备可能能连上但超时表现是偶尔能用偶尔不能用比纯断网更难排查。第三个心得是关注设备的超时和降级策略。好的设备在断网时会快速失败并给出明确提示差的设备会一直卡着让你以为死机了。这个差异在选购和自研时都是重要考量。6. 从分工看设备选型与自研6.1 选型时该看哪些指标如果你要选一款小智类设备又比较在意断网场景的可用性我建议重点看这几个指标本地唤醒的响应速度和误唤醒率这决定了基础体验跟网络无关但很重要。本地缓存策略支持缓存多少内容、缓存什么类型决定了断网后能放什么。断网提示的明确程度是明确告诉你网络异常还是默默卡住体验差别很大。自动重连能力网络恢复后能否自动恢复不需要人工干预。本地指令支持范围有没有把一些高频简单指令做成本地匹配。这几个指标里前两个是硬件和固件决定的后三个更多是软件策略。选型时如果能拿到样机一定要做断网实测别只看宣传。6.2 自研时的端云职责划分建议如果你正在做类似产品需要划分端侧和云侧的职责我的建议是遵循能本地就本地该云端就云端的原则具体可以这样分端侧负责唤醒词检测、音频采集与编码、本地缓存播放、简单指令的本地匹配、网络状态监测与降级提示、断网时的基础反馈。云侧负责语音识别、语义理解、内容生成、语音合成、内容更新与个性化、复杂对话管理。这个划分的关键在于把实时性要求高、算力要求低的放端侧把算力要求高、可以容忍一定延迟的放云侧。唤醒必须实时所以放端侧识别和理解可以容忍几百毫秒延迟所以放云侧。还有一点很重要端侧一定要有网络状态感知和降级能力。设备应该知道自己现在能不能联网联网时走完整链路断网时走降级路径而不是傻等着超时。这个设计能极大提升断网时的体验。6.3 一个容易被忽略的细节唤醒后的状态机最后说一个细节是我在调试时发现的。设备唤醒后其实进入了一个状态机待唤醒 - 唤醒 - 录音 - 上传 - 等待响应 - 播放 - 回到待唤醒。断网时这个状态机卡在上传或等待响应这一步。好的实现会给每个状态设置超时超时后回到待唤醒并给出提示。差的实现可能就卡死在那里需要重启。如果你在自研一定要给状态机的每个状态设计超时和异常处理这是保证断网体验的基础。我见过太多设备因为没处理好这个断网后直接假死用户以为坏了其实只是状态没复位。这个状态机的设计思路其实也适用于任何依赖远程服务的设备。核心就一句话永远假设网络会断并为断网准备好退路。
