去年我在帮一个做智能陪护机器人的团队调主板产品形态是带屏幕的桌面机器人主要功能包括AI语音对话、视频通话和远程看护。一开始大家觉得无线方案没啥好纠结的——主控SoC自带Wi-Fi家里路由器遍地都是视频语音全走Wi-Fi不就完了结果联调阶段就翻车设备待机时要保持语音唤醒Wi-Fi长连接把功耗顶上去了电池撑不了一天语音通话时又时不时来一下200ms以上的抖动对面的人声断断续续视频画面也跟着卡。后来我们把BLE通道加进来做常听唤醒和保活Wi-Fi只在真正需要传视频流和音频大包的场景下才被拉起靠着这套“Wi-FiBLE”融合架构才把问题彻底解决。也是从那次之后我意识到AI语音和AI视频这类重媒体业务铺开之后智能设备的连接层已经不可能靠单条无线链路通吃了多无线融合方案正在成为设备体验的核心底座。这篇文章我就从几个维度把这个底座拆开讲AI语音和AI视频到底给无线连接出了什么难题Wi-Fi、BLE、UWB、Thread这些技术各自擅长什么单模方案会在哪些真实场景里翻车多模融合的协同架构怎么设计以及落地量产时绕不开的射频共存、功耗、认证这些硬骨头。1. AI语音与AI视频给无线连接出了哪些“新难题”1.1 从“状态上报”到“媒体管道”连接形态的根本变化传统智能设备传感器、插座、门锁的无线连接模型很简单设备定时把状态数据上报到网关或云平台一天下来也就是几十KB的流量。这种模型下Wi-Fi也好、BLE也好本质上只是个“数据邮差”链路偶尔断一下、延迟抖动几百毫秒都不会造成什么体感问题。但AI语音和AI视频业务一上来连接形态就彻底变了。设备不再只是数据采集端同时还是媒体渲染端麦克风阵列采集的音频要实时上行到云端做ASR语音识别云端合成的TTS语音流要实时下行到喇叭播放摄像头采集的画面要持续上行推流手机端的控制命令又要下行控制设备转动、变焦、开关补光灯。连接层从“偶尔传个数据”变成了“持续输送媒体流的高速管道”而且这条管道对延迟、抖动、丢包、带宽都有硬性要求。1.2 AI语音和AI视频各自的链路需求差异很多人以为“无线方案只要带宽够大就行”这是个误区。AI语音和AI视频对链路的需求其实完全不同放在一起看特别有意思AI语音流带宽需求真的不高。以16kHz采样、单声道、Opus编码为例高质量通话码率也就在20~64kbps之间哪怕用BLE的LE AudioLC3编码都能跑得动。但语音流对端到端延迟和抖动极其敏感业内普遍要求端到端延迟低于200ms否则就会感受到明显的“对讲机效应”。而且语音是双向交互的上行采集和下行播放必须保持连续任何一次调度延迟或者丢包重传都会直接表现为破音、卡顿、吞字。AI视频流刚好相反带宽是大头。720p30fps用H.264压缩大约需要1~2Mbps1080p30fps需要3~8Mbps到了4K30fps就需要15Mbps以上。视频编码还特别“不听话”I帧出现的时候瞬时码率可能是平均码率的5到10倍链路需要有足够的突发吸收能力。与此同时实时视频对延迟的要求比语音宽松一些一般300~500ms内都能接受但对连续性和吞吐稳定性要求极高不能突然掉到一个很低的吞吐区间。1.3 智能设备的多业务并发链路资源变成实时编排问题真正让问题复杂化的是同一台智能设备上往往会同时跑多个业务。我自己调试过一台带屏AI音箱它的典型工作状态是本地VAD检测到唤醒词→云端ASR识别→TTS播报→同时屏幕上有视频流正在播放。如果这台设备还兼做安防摄像头那还要再加一路视频上行推流。在这种多业务并发场景下无线链路资源本质上变成了一个实时编排问题什么优先级用什么无线制式承载占多大占空比在什么时机切换这套调度逻辑如果没做对就会出现视频流把TTS语音挤爆、上行推流占满Wi-Fi导致控制命令延迟、又或者待机状态音频唤醒链路和Wi-Fi Beacon周期打架等一堆问题。2. 主流无线技术逐个过秤它们分别擅长什么2.1 Wi-Fi大带宽主力AI视频的“主干道”Wi-Fi在AI视频场景里是不可替代的。从802.11n到Wi-Fi 6再到Wi-Fi 7吞吐能力一路从几十Mbps涨到几个Gbps1080p甚至4K视频流对于Wi-Fi来说都不算压力。更重要的是Wi-Fi 6引入的OFDMA技术可以在一个信道内同时服务多个终端设备在设备密集场景下大幅降低了时延抖动TWT目标唤醒时间则让设备可以和AP约定唤醒窗口对功耗控制帮助很大。到了Wi-Fi 7MLO多链路操作让设备可以同时连接2.4GHz、5GHz甚至6GHz链路两条链路可以动态承载不同业务或者一条链路为主另一条做快速冗余切换。这对于双频并发、视频语音分流的设备来说是非常实用的演进方向。不过Wi-Fi有个天生的短板维持连接的代价太高。保持Wi-Fi连接时接收Beacon和周期性唤醒的功耗在毫安级别对电池供电设备来说很难接受。如果为了省电让Wi-Fi深度休眠重新关联AP又需要几百毫秒到数秒时间语音唤醒场景等不起。2.2 BLE低功耗常开链路AI语音唤醒与控制的“哨兵”BLE是我在多无线融合方案里最常用来做“保活链路”的技术。原因有三点第一是功耗极低。BLE的广播和扫描机制允许设备以极低的占空比工作一颗纽扣电池都能跑几个月到一年。对需要7x24小时待机听唤醒词的设备来说只有BLE能做到让麦克风阵列和语音唤醒模型常开而不至于让设备一天充三次电。第二是有足够带宽承载音频。BLE 5.x引入了2M PHY实际吞吐可以到1~2Mbps再配合LE Audio的LC3编码跑低延迟高质量的双向语音通话已经够用。这就意味着在Wi-Fi休眠或者断连的窗口期设备仍然能用BLE维持基础的语音交互能力。第三是生态和触发机制完善。BLE广播、扫描、连接事件这套机制非常适合做触发和保活比如手机靠近设备时通过BLE触发Wi-Fi快连或者设备通过BLE连接接收低频率的控制命令。2.3 UWB/Thread等辅助链路空间感知和mesh控制面除了Wi-Fi和BLE多无线融合方案里还有两个重要的配角。UWB超宽带的核心价值是精准测距和空间感知厘米级的定位精度让它非常适合做“人来亮屏”“指向交互”“数字钥匙”这类场景。比如带屏幕的AI设备利用UWB感知到用户靠近到两米以内再触发屏幕点亮、麦克风阵列波束成形指向用户体验会非常自然。UWB的带宽和覆盖范围虽然不如Wi-Fi但它的时间戳精度极高这是其他无线技术替代不了的。Thread和Zigbee这类802.15.4 mesh协议数据速率只有250kbps左右在AI音视频场景里几乎承载不了任何媒体流但它们在智能家居控制面有独特价值低功耗、低延迟、mesh组网可靠设备之间没有单点故障。Matter标准则把Wi-Fi、Thread、BLE统一到了应用层让设备可以用Thread做控制面、Wi-Fi做媒体面各干各的活。2.4 一张表看明白各无线技术的分工边界无线技术频段峰值速率典型连接功耗延迟特征在AI音视频设备中的角色Wi-Fi 6/6E/72.4/5/6GHz600Mbps~2.4Gbps保持连接约10~50mA低延迟但受AP负载和信道干扰影响大AI视频主通道、大文件传输、云服务连接BLE 5.x LE Audio2.4GHz1~2Mbps广播/扫描约5~15uA连接态约10~50uA连接事件周期可控延迟较稳定AI语音唤醒常听、音频通话备用链路、控制信令保活UWB6~9GHz6.8~27Mbps测距会话约几十mA纳秒级时间戳测距延迟极低空间感知、人员靠近触发、指向交互Thread/Zigbee2.4GHz250kbps约5~10mA收发瞬时低吞吐但mesh可靠智能家居控制面、传感器网络不承载媒体流3. 单打独斗的无线方案在哪几个典型场景里翻车3.1 Wi-Fi-only的设备功耗和延迟抖动的双重尴尬现在市面上很多AI音箱、AI中控屏硬件上只有一颗Wi-Fi模块设计思路是“反正Wi-Fi啥都能传”。实际用下来主要翻两个车功耗这关就很难过。Wi-Fi保持连接即使没有业务流量也要周期性地醒来收Beacon、做功率校准待机功耗通常在10~50mA这个量级。对于插电设备还好但凡是带电池的移动AI设备比如手持翻译机、AI宠物相机、陪护机器人这个底噪功耗就是灾难。我见过一个AI宠物相机项目Wi-Fi常连状态下电池续航只有不到半天后来把主控切到BLE保活、Wi-Fi按需拉起续航直接翻了四倍。延迟抖动同样不好控制。Wi-Fi是共享信道家里一堆终端设备、隔壁邻居AP、微波炉蓝牙都在抢信道一旦信道拥塞视频流或者语音流的延迟就会剧烈抖动。做视频通话时如果Wi-Fi出现一次几十毫秒的抖动人耳能明显听出语音断续更麻烦的是Wi-Fi协议栈的重传机制在弱信号下可能触发指数退避导致链路吞吐雪崩式下降。3.2 BLE-only的设备语音勉强能跑视频直接没戏BLE-only设备的优点是功耗、成本和体积都有优势很多轻量级AI语音设备会选BLE云端ASR的方案。用LE Audio跑双向语音对话实测下来体验确实可以LC3编码在128kbps码率下就能提供相当清晰的语音质量。但视频业务一来就完全顶不住了。BLE的PHY速率上限就是2Mbps实际单向有效吞吐受限于连接间隔和包间隔稳定跑1Mbps已经很吃力连720p的视频都推不动。而且BLE连接是主从模式从设备的所有通讯都要经过主设备调度一旦同时挂多个连接吞吐更是直线下滑。所以BLE-only方案只适合“纯语音、无视频”或者“视频只是本地预览不传云端”的场景。3.3 多业务并发时的“链路打架”一个真实调试案例我之前调过一台AI安防摄像头功能是“视频监控双向语音对讲语音助手”硬件上只有一个Wi-Fi模块。问题现象很稳定只要视频流一推流语音对讲马上破音语音一通话视频帧率掉到个位数。排查下来根子在于单条Wi-Fi链路上视频和语音在抢资源。视频I帧突发时瞬时带宽需求飙高直接把语音RTP包的发送队列给挤了Wi-Fi协议栈默认对TCP视频流和UDP语音流的优先级是一视同仁的没有做QoS分流。后来我做了三件事在Wi-Fi模块上使能WMM把语音队列Voice Queue优先级提到最高给视频流设置一个突发上限I帧进来时先降帧率再堆积码流把语音对讲的信令和控制命令挪到一条独立低带宽链路上。第三个改动其实就是把控制面拆出去避免和媒体面抢资源——这也是我后来在方案里坚持引入多无线融合的直接原因。3.4 结论AI语音和AI视频需要的是“组合拳”单模方案的问题不是技术本身不行而是人类对智能设备的期待已经是“同时、持续、高质量地跑多个重媒体业务”。在这种需求面前任何单一无线技术都有自己的天花板Wi-Fi强在带宽但输在功耗和抖动BLE强在功耗但带宽不够UWB强在空间感知但覆盖太小。所以多无线融合的本质不是“多装几个无线芯片”而是让每个无线技术去干自己最擅长的那件事再用一套协同调度机制把它们组织起来。4. 多无线融合方案的协同架构链路分工与动态调度4.1 融合的核心原则按数据特征分链路按场景切策略我设计多无线融合方案时第一原则概括起来就是媒体走宽道控制走窄道唤醒走小道。高带宽、持续的媒体流视频上行、大码率音频走Wi-Fi因为只有Wi-Fi能提供足够的吞吐和低延迟能力。低带宽、低频次的控制信令和保活消息走BLE因为BLE能在低功耗下保持长连接而且不占用宝贵的Wi-Fi带宽。唤醒和空间感知由BLE广播扫描或UWB测距来承担因为这两个场景需要在设备深度休眠的状态下依然能低功耗地感知外部事件。但这只是静态分工真正关键的是动态调度。设备的工作状态会在“待机-唤醒-通话-视频推流-降级”这些状态之间切换连接管理器需要根据当前业务场景、电池电量、链路质量实时决定各条链路的工作状态。比如电量低于20%时自动降低视频分辨率和帧率让Wi-Fi进入省电模式同时把语音通话切到BLE通道维持基础功能。4.2 典型架构一Wi-Fi主通道BLE保活通道AI语音中控设备这是我在语音中控、AI带屏音箱这类产品上最常用的架构。整体分工是待机态Wi-Fi关闭或进入深度休眠BLE保持广播扫描和低功耗连接。设备通过BLE通道接收手机App的控制命令麦克风阵列和语音唤醒模型常开音频采集由本地VAD检测到唤醒词后触发。唤醒唤醒态本地唤醒词命中后BLE先把唤醒事件发送给主控同时主控开始拉起Wi-Fi关联。利用BLE这条“带外通道”可以把Wi-Fi重新关联AP的工作提前放到音频数据真正需要传输之前从而把唤醒到开始响应的时间压缩到几百毫秒以内。通话态Wi-Fi已建立连接双向语音流通过Wi-Fi的VoIP通道传输。BLE保持连接负责心跳保活和紧急控制命令。如果Wi-Fi质量突然恶化语音流可以自动降级切换到BLE的LE Audio通道虽然音质有所下降但至少保证通话不中断。断线降级态Wi-Fi断线后BLE通道维持设备与手机之间的控制连接设备可以通过BLE告知App“视频不可用但语音可用”并且每秒或每两秒尝试一次Wi-Fi重连。这个设计能大幅减少用户对设备“离线”的感知。4.3 典型架构二Wi-Fi视频流Thread/Matter控制面智能家居场景如果智能设备要接入全屋智能生态而不是只跟手机点对点通信那Thread和Matter的价值就会体现出来。这个架构里设备仍然用Wi-Fi承载音视频媒体流和云服务连接但设备之间的控制命令、状态同步、场景联动走Thread mesh。比如一个智能门铃门铃的视频流通过Wi-Fi推给云端用户手机远程查看同时门铃作为Thread节点能把“有人按门铃”这个事件毫秒级地同时广播给屋里的智能音箱、灯光和中控屏触发联动场景。Thread mesh在这里解决的是传统Wi-Fi方案做不到的可靠性问题单个AP掉线或者Wi-Fi拥塞时Thread mesh网络内设备之间的联动不受影响仍然可以正常工作。Matter在应用层统一了设备模型让不同厂商的设备不用为私有协议去适配这对多无线融合方案的落地帮助很大。4.4 典型架构三Wi-FiBLEUWB三模融合空间感知音视频交互一些高端AI交互设备比如带屏幕的陪伴机器人、智能健身镜、会议白板会把UWB也加进融合方案里。这时的协同逻辑就更立体了UWB负责空间感知层设备通过UWB测距判断用户是否靠近、从哪个方向靠近甚至可以区分多个用户中谁在锁定交互。当检测到用户走进1.5米范围BLE先被唤醒设备亮屏、麦克风阵列波束成形指向用户方向UWB持续跟踪用户位置如果用户走远屏幕自动熄灭进入省电模式。Wi-Fi负责媒体传输层视频通话、内容投屏、云端ASR/TTS全部走Wi-Fi。由于UWB已经把用户位置和交互意图提前告诉系统Wi-Fi链路可以提前预建立连接用户真正开口说话时媒体通道已经是ready状态。BLE负责设备配网和日常保活新设备配网时通过BLE完成Wi-Fi凭证的安全传递日常运行中BLE保持低功耗心跳连接。这套三模架构在体验上的提升非常明显用户靠近即亮屏、指哪打哪的语音交互、无感配网这些都是单模方案做不到的。4.5 协同调度里的关键机制唤醒设计、无缝切换和共存仲裁多无线融合的软件架构我最看重的三个关键机制唤醒设计。设备深度休眠时唯一保持工作的就是BLE的广播扫描窗口或者UWB的低功耗测距。这个窗口的占空比决定了两个互相矛盾的指标唤醒响应时间和静态功耗。我一般用“双重唤醒”思路BLE先做粗粒度检测比如检测到手机进入蓝牙范围然后采样间隔切到更密的扫描模式做细粒度确认最后才拉起主控和Wi-Fi。这样待机功耗能控制在微安级别又能保证用户接近时响应足够灵敏。无缝切换。多无线融合过程中切换失败是最常见的体验杀手。我的做法是所有无线链路都受同一个连接管理器Connectivity Manager调度任何一次链路切换都必须走“先建后断”的流程——新链路确认可用之前旧链路不允许断开。比如Wi-Fi断线降级到BLE语音时必须先通过BLE建立音频承载通道确认编码器和收发双方状态都OK再关闭Wi-Fi语音流这样用户就不会感受到通话中断。共存仲裁。多无线芯片在同一设备里同时工作射频信号之间会有共存干扰这需要在硬件和软件两个层面做仲裁。软件层面的重点是让各协议栈共享一个“射频占用日历”在时隙上错开Wi-Fi信标和BLE连接事件的收发窗口避免同时收发。5. 物理层硬仗多无线共存、天线设计和调优经验5.1 2.4GHz频段拥堵与多模自干扰的现实很多方案选型时只看协议栈层面觉得Wi-Fi和BLE在两条不同“技术”上不会冲突实际上Wi-Fi 2.4GHz、BLE、Thread全挤在同一段频谱里。信道规划稍有不慎多模设备内部首先就会自干扰。最常见的现象是Wi-Fi发送大流量时BLE接收灵敏度骤降连接出现大量重传反过来BLE正在广播时Wi-Fi的上行吞吐掉一半。这是因为2.4GHz频段内Wi-Fi的发射信号功率远高于BLE和Thread的接收信号射频前端很容易被压饱和产生邻道干扰。解决思路分三层频谱规划上把Wi-Fi固定在1、6、11信道之一让BLE的跳频信道避开Wi-Fi主信道带宽时间调度上通过PTAPacket Traffic Arbitration信号或软件调度器让Wi-Fi发送和BLE接收分时进行功率控制上尽量压低Wi-Fi发射功率刚好满足覆盖需求即可不要盲目开满功率。5.2 天线布局、隔离度要求和工程化经验多无线融合设备最容易被低估的是天线设计。我在几个项目里踩过的坑包括Wi-Fi天线和BLE天线距离太近隔离度不够导致Wi-Fi一发数据BLE直接掉线UWB天线被金属后盖遮挡测距精度从厘米级掉到半米级蓝牙天线和麦克风阵列的距离太近射频耦合进音频通路产生底噪。工程上我建议几个指标作为底线同频段双天线比如2.4G Wi-Fi和BLE隔离度至少做到20dB以上通常需要在PCB布局上拉开四分之一波长以上的距离且朝向尽量正交异频段天线2.4G和UWB隔离度要求可以放宽到15dB但因为UWB对时域精度敏感天线周围不要有金属反射体。调试时必须做整机状态下的天线辐射效率测试不要只测裸板天线外壳、屏幕、电池都会改变天线谐振。5.3 实测中容易翻车的细节时隙冲突、功率互斥和协议栈优先级我总结了三类在多无线融合实测中最常遇到的问题以及对应的排查思路。时隙冲突。现象是BLE连接事件每30ms丢一次包很有规律。用频谱仪抓包后会看到Wi-Fi的Beacon周期和BLE的连接事件周期刚好错开得不彻底两者在某些时隙重叠导致BLE收不到主设备的poll包。解法是把BLE连接间隔设置成与Wi-Fi Beacon周期的非整数倍关系或者通过共存仲裁器把BLE的连接事件固定安排在Wi-Fi非活跃窗口。功率互斥。Wi-Fi拉高发射功率后BLE链路的RSSI在没移动的情况下突然掉了20dB。这是典型的射频前端饱和问题先查两颗芯片的发射功率配置和天线隔离度再看能不能把Wi-Fi功率用手动档限制在14dBm左右实测往往能在保证覆盖的同时保住BLE灵敏度。协议栈优先级。默认配置下Wi-Fi协议栈对视频、语音和背景流量的处理是公平的这在多业务并发时会造成体验灾难。排查方式是给Wi-Fi模块的QoS映射表配上WMM优先级把语音队列标记为Voice优先级最高视频流队列标为Video次之控制信令可以走BE队列但频率低影响不大BLE侧则把控制信令的connection interval设短一点保证低延迟响应。5.4 调优工具和方法从频域到实网的排障流程多无线融合的排查跟单模设备完全是两个量级。我自己的调优流程分四步第一步频谱分析仪看环境在设备实际安装位置扫一遍2.4GHz和5GHz频段确认哪些信道是干净的、哪些已经被邻居设备占用这是信道规划的依据。第二步打流工具测单链路基线分别单独测Wi-Fi上行/下行吞吐、BLE吞吐和时延记录每条链路在无干扰时的性能基线。第三步多链路并发压测同时跑Wi-Fi视频流和BLE保活数据观察两条链路的吞吐和时延变化定位是否存在互扰。第四步实网场景回放用录制好的语音对话和视频流完整回放真实业务场景重点观察唤醒响应时间、通话连续性、视频卡顿次数这几个体验指标。整个过程靠的不仅是工具还有一套可复现的测试用例。我一直建议团队把每次调优的射频参数、信道规划、协议栈配置都记录下来形成设备的“射频指纹档案”这样量产时遇到一致性波动能很快定位是天线批次问题还是配置漂移问题。6. 从选型到量产多无线方案落地时的平衡艺术6.1 芯片平台选型单SoC多模一体与分立方案怎么选多无线融合方案的芯片选型我见过三种路径第一种是单SoC集成多模比如一颗SoC同时集成Wi-Fi 6、BLE 5.3和802.15.4。最大的优势是共存调度在芯片内部完成射频前端也可以共享功耗和成本都更低缺点是天线布局更集中散热和射频隔离难度大而且一旦某代无线标准升级整颗SoC都得换。第二种是Wi-Fi/BLE Combo模块加独立UWB芯片这是目前AI中控和陪护机器人产品里比较主流的组合。Combo模块解决了Wi-Fi和BLE这一对最常用链路的共存问题UWB芯片单独部署可以放在天线空间更合理的位置比如屏幕上方方便做空间感知。第三种是多颗分立无线芯片灵活性最高但共存调度要自己写天线数量多成本高一般只适合对性能有极致要求的旗舰设备。我的建议是除非产品有特殊的射频架构需求否则优先选成熟的Combo方案把共存调度的复杂度交给原厂把精力花在应用层业务逻辑上。UWB这种辅助链路再独立选型。6.2 功耗、成本与认证三个绕不开的验收门槛多无线融合方案在项目验收阶段几乎绕不开下面这张功耗表。以一台带屏AI中控为例工作场景链路状态实测功耗说明深度待机BLE常听Wi-Fi/UWB休眠0.2~0.5mA麦克风VAD常开BLE广播扫描窗口约5%语音唤醒待命BLE常听Wi-Fi休眠UWB低功耗测距1~3mAUWB占空比降到1HzVAD常开Wi-Fi重连语音通话Wi-Fi连接BLE保活150~300mAWi-Fi VoIP为主BLE只走心跳视频通话本地渲染Wi-Fi视频流语音流BLE保活400~800mA屏幕、编解码、Wi-Fi同时工作视频上行语音下行Wi-Fi全双工BLE保活300~600mA安防摄像头模式成本控制上多模融合必然增加BOM成本但它同时减少了因连接体验差导致的退货和售后成本。这个平衡要想清楚单纯看BOM会增加10~20元但换来的是用户感知层面的稳定性和续航长期是划算的。认证是多无线融合最容易踩的坑。除了常规的SRRC/FCC/CE认证多模设备还经常要做额外的射频互扰测试和SAR测试。UWB在国内的频段合规和功率限制要特别注意不同国家的UWB频段政策差别很大如果产品要出海必须在设计阶段就确认目标市场的UWB合规要求。6.3 典型的多无线设备量产配置参考最后给一套我实际用过的量产配置参考产品是带屏AI语音中控主控SoC集成Wi-Fi 6 2x2 MIMO BLE 5.3天线采用1根Wi-Fi双频1根BLE/2.4G复用加1颗独立UWB芯片和专用UWB天线Wi-Fi侧使能WMM QoS信标间隔默认100msTWT间隔按业务场景动态调整待机500ms/通话100msBLE侧广播间隔200ms连接间隔30ms从设备延迟slave latency4保证待机功耗不超标UWB侧测距模式设为AOA测距频率5Hz检测到用户靠近后自动切换到20Hz高精度模式连接管理器统一调度支持“Wi-Fi主BLE保活”“BLE语音降级”“UWB触发唤醒”三种策略这套配置在量产项目中跑了大半年待机功耗、唤醒响应、视频通话流畅度都达到了预期指标算是我个人比较满意的一套融合方案落地模板。最后聊点我自己的体会。多无线融合方案做久了你会发现它真正的难点从来不在某一颗芯片或某一个协议上而在于怎么用一套清晰的系统思维把不同无线技术的能力边界、功耗代价、干扰关系都摆到桌面上一一权衡。每次调试到射频互扰、链路切换这类问题的时候我都会想起那句话连接层不是堆料而是做编排。AI语音和AI视频时代谁能把这张无线资源编排好谁就能让智能设备的体验真正站上新的台阶。