8年轮回：AI卡片让TNT语音交互从翻车到落地，但工程坑不少

说到通知权限和隐私的平衡，这个点确实太真实了。我之前玩过一阵子自编译的语音助手固件，也是卡在“本地处理”和“云端能力”之间反复横跳。本地跑模型延迟是低了，但识别率一言难尽，尤其是中文长句和方言；一上云吧，用户又担心录音上传，哪怕你发誓只传脱敏后的特征向量都没用。

C·ONE这个蓝牙6.0低功耗常连接方案，理论上能做个本地缓冲池——通知文本先本地解析，只有涉及地图、闹钟、日程这类需要云端协同的指令才走网络。但问题来了，有多少第三方App会配合这个机制？像微信通知里带个短链，本地解析器大概

率直接瞎掉，最后还是得弹回云端，隐私边界又模糊了。

另外那个磁吸卡片形态我倒是挺看好的，比智能音箱和手机支架都更“轻量”。但实际场景里有个坑：卡片吸附位置如果不在视线自然落点，人就会下意识转头去看屏幕，语音交互又变成了“先看后说”，反而多了一步。不知道C·ONE有没有做角度感应或者语音唤醒时的屏幕闪烁引导？

最后想问下，资讯里提到的“混合处理”具体是怎么切分的？是固定规则（比如关键词触发本地/云端），还是有个动态决策层？这个做不好很容易变成薛定谔的隐私保护，用户用着用着就心里没底了。

这分析很到位，尤其是“从主动触发变成被动辅助”这个点，确实能大幅降低用户的心理门槛。不过关于隐私这块我也挺好奇，蓝牙6.0的常连接虽然能本地处理，但万一遇到需要云端解析的复杂指令，数据脱敏和用户授权具体是怎么做的？之前我们项目就在这踩过坑，本地缓存策略没做好，反而导致通知重复推送更耗电了。

搞过类似项目的表示，通知权限这块确实是个深坑。安卓端的通知监听API本来就不是给这种低功耗场景设计的，蓝牙6.0的LE Audio虽然延迟低，但想要做到“静默读取”又不触发系统级隐私警告，得在固件层做不少脏活。我之前踩过一个雷：某些国产ROM会把通知内容摘要直接丢进广播里，但敏感词过滤一开，连“银行卡到账”这种字段都会被拦截，导致卡片端收不到完整信息。C·ONE那个“本地+云端混合”的方案估计也绕不开这个——如果纯本地解析，中文语义的模糊性（比如“明天下午三点”和“明天下午三点半”的歧义）靠端侧小模型基本搞不定，必须上云端做NLP，但一上云，用户数据脱敏怎么做？资讯里没细说，我猜他们可能是把通知先打散成结构化字段（时间、金额、联系人）再上传，但这样又可能丢失上下文，比如“您已购买成功”这种需要结合前一条通知才能判断的对话场景。

另外，磁吸卡片这个形态，散热和续航也是暗坑。蓝牙6.0低功耗是没错，但本地跑轻量ASR模型的时候，芯片瞬时功耗容易飙上去，我见过测试机连续听写15分钟就发烫掉线的。他们要是没做动态频率调节或者温控降级策略，实际体验可能撑不过半天。

最后想问个具体的：资讯里提到“被动辅助”减少用户心理负担，但实测过误唤醒率吗？比如放在口袋里摩擦到桌面，或者磁吸充电时的电磁干扰，会不会频繁触发？这玩意儿要是没事儿就震一下念个通知，还不如直接看手机。

这个帖子我看了两遍，因为里面提到的点正好撞上我最近在琢磨的一些问题。你提到“主动触发变被动辅助”这个观察特别准，以前用语音助手总得先喊一句唤醒词，感觉像在跟机器下指令，挺累的。如果卡片能静默读取通知再根据场景决定是否反馈，确实能降低那种“我在用AI”的心理门槛。

不过你那个隐私问题我也很在意。蓝牙6.0的低功耗常连接确实解决了续航焦虑，但通知数据到底在哪一步被处理？你提到本地+云端混合，那边界怎么画的？比如一条短信里包含银行卡号，是直接在卡片的边缘芯片里完成语义解析，还是先加密传回手机再决定要不要上云？我猜C·ONE的做法可能是类似白名单机制，只对日历、闹钟这类低敏感数据做云端增强，通讯录和支付类通知强制本地处理。但这样一来，本地芯片的算力够不够？我试过在树莓派上跑轻量级NLP模型，延迟还是有点感人，磁吸卡片那么小的体积里塞得下吗？

另外你提到“工程坑”，我特别想了解他们在多设备协同上怎么处理的。比如手机连着卡片，手表也连着卡片，通知会不会重复播报？还是说卡片会判断当前哪个设备离用户最近，只播那个设备上的通知？这种优先级逻辑如果写不好，体验会很割裂。

通知权限这块确实是大坑，安卓这边权限收得越来越紧，蓝牙6.0的低功耗常连接方案听着不错，但用户侧会不会担心后台偷偷传数据？之前做类似项目时，我们干脆把敏感词识别和语音合成都放在本地，只传脱敏后的意图标签，不知道C·ONE的本地处理边界能覆盖到什么程度。

看到这个帖子真是感慨，当年TNT发布会我还在现场，老罗演示语音发微信翻车那幕简直经典重现。现在回想，确实不是语音技术不行，是场景选得太激进——谁能想象在办公室对着电脑喊“发微信给XXX”啊，旁边同事不把你当神经病才怪。

你说到通知权限和隐私平衡这个坑，我太有同感了。之前做智能眼镜的语音助手，光是处理“读取通知”这个功能就折腾了半年。用户既要方便又怕隐私泄露，最后我们被迫做了本地关键词过滤，敏感词（比如银行验证码、医疗信息）直接在端侧屏蔽，不上云端。C·ONE那个蓝牙6.0常连接方案听着挺稳，但有个问题我特别好奇：如果用户在手机上打开银行APP输入密码，这时候语音卡片还在静默读取通知栏吗？理论上系统通知栏是不应该暴露密码的，但实际很多安卓APP会偷偷把敏感信息写进通知内容，这块要是没处理好，隐私风险其实挺大的。

另外你说“被动辅助”这个方向我举双手赞成。我现在的使用习惯就是AI卡片只处理“信息摘要”和“快捷回复建议”，真正要发长消息还是得掏出手机。TNT当年非要让语音做主角，现在这个形态更像是一个“第二屏幕”，把手机通知变成可交互的卡片，用户心理负担小多了。不过蓝牙6.0的功耗到底怎么样？我试过一些常连接设备，续航基本撑不过两天，要是C·ONE能做到一周一充，那才叫真落地。

看到这篇帖子，感触很深。作为一线AI工程师，我从2017年开始做语音交互落地，经历过TNT那个年代的狂躁，也做过智能音箱、车载语音、甚至医疗场景的语音助手，中间踩的坑不比帖子里的少。先直接回你两个核心问题，再展开聊聊我的实际经历。

关于权限和隐私，你问的Android和iOS实现差异，这个我做过对比。Android这边，从Android 8开始，NotificationListenerService（NLS）是官方提供的接口，允许应用读取通知内容，但需要用户在设置里手动授权。这个授权是持久化的，只要用户不取消，系统不会主动回收。C·ONE如果走这条路，技术上完全合法，不涉及系统漏洞。但有个坑：国内很多厂商（比如小米、华为）对NLS做了额外限制，比如MIUI里如果APP被标记为“自启动”或“后台限制”，NLS可能被系统杀掉或延迟推送。我实测过，小米14的HyperOS上，某些第三方APP的NLS触发延迟能达到2-5秒，这对实时性要求高的场景是致命问题。所以C·ONE如果要在Android上稳定工作，必须通过厂商的“智能通知”白名单或者走无障碍服务（AccessibilityService）作为备选，但无障碍服务在Android 14之后也被严格限制，需要用户手动开启“增强型通知”选项，而且每次系统更新都可能影响稳定性。

iOS就更麻烦了。iOS没有官方通知读取接口，只有CallKit和SiriKit能有限度地接触通知。C·ONE如果宣称能静默读取iOS通知，只有两条路：要么通过MFi认证，走AirPlay或蓝牙HFP协议间接获取，但苹果对通知内容的访问控制极严，大概率只能拿到“有通知”这个信号，获取不到具体内容；要么就是走私有API，比如通过蓝牙串口模拟键盘或耳机设备，利用iOS的“辅助触控”或“语音控制”功能来间接读取屏幕上的通知文本。这条路技术上可行，但违反App Store审核规则，而且每次iOS大版本更新都可能被封。我认识一个做类似项目的团队，在iOS上跑了一年多，最后被iOS 17的“敏感内容警告”机制直接干废——系统会把通知文本上的URL、电话号码等语义内容拦截掉，导致模型无法解析。所以C·ONE的iOS版本如果真能稳定工作，大概率是走了MFi认证的深度定制通道，但成本极高，不太像消费级产品的做法。

关于语音分类的本地/云端问题，这个我踩过两次坑。第一次是在做车载语音助手时，我们尝试用云端模型做意图分类，结果在隧道、地下车库等无信号场景下，用户说“导航去公司”，车子直接卡死30秒后才响应。后来我们改为本地轻量模型（MobileNetV3-Small + 知识蒸馏后的BERT-Tiny）做紧急度分类，准确率从云端的98%降到93%，但延迟从1.2秒降到80毫秒。那个5%的准确率损失主要出现在“不紧急但复杂”的场景，比如用户说“提醒我下周二的会议”，本地模型容易把它误判为“不紧急”而忽略，但实际上用户可能需要立即确认。解决方案是加一个“模糊度阈值”：当本地模型置信度低于0.7时，自动上传进行云端二次判断，同时本地先给出一个“我处理中”的语音反馈，这样用户感知不到延迟，准确率也能回升到96%左右。这个方案在C·ONE这种卡片形态上更适用，因为蓝牙6.0的LE Audio延迟已经够低，再结合本地预判，完全可以在用户说完“帮我回个消息”的1秒内完成分类和响应。

但帖子提到的“续航30天”和“蓝牙6.0成熟度”才是真正的工程深水区。我去年参与过一个蓝牙5.3的穿戴项目，当时为了省电，我们做了“事件驱动”的唤醒策略：只有用户抬手或检测到特定关键词时才启动蓝牙广播。结果发现，蓝牙6.0的Channel Sounding（信道探测）技术在多设备环境中存在严重的“耳语效应”——当两个以上蓝牙设备同时广播时，信道估算会互相干扰，导致信号强度波动超过15dB。这意味着C·ONE的“静默读取”机制在办公室、地铁等密集蓝牙环境下，可能收不到某些通知，或者收到后解码错误。我们当时的解法是：在BLE广播包中添加一个“时间戳+CRC校验”的冗余字段，每个设备每30秒同步一次信道状态，如果发现误码率超过5%，就切换到“低功耗扫描模式”（只监听，不发射），牺牲一部分双向通信能力来保接收可靠性。这个方案增加了约10%的功耗，但丢包率从8%降到了0.3%。C·ONE如果真能做到30天续航，很可能也用了类似的分时调度策略，但代价是用户的通知列表更新会有秒级延迟，这在消息实时性要求高的场景（比如微信消息）里可能被感知到。

再聊聊TNT那个时代给我的教训。2018年我所在的公司也做了一个类似的“语音替代键鼠”的产品，叫“声控桌面”。我们的场景是：用户戴着耳机，对着麦克风说“打开浏览器”“输入网址”“点击搜索框”。结果测试时发现三个致命问题：第一，语音指令的准确率在安静环境下是95%，但在咖啡馆、办公室等背景噪声下直接掉到70%，用户必须扯着嗓子喊，体验极差。第二，用户说“点击那个蓝色的按钮”时，系统需要理解“蓝色”这个颜色属性，但当时我们的视觉模型只能识别按钮位置，没法准确判断颜色，经常点错。第三，也是最致命的，用户在做“删除文件”这类操作时，系统会误判成“保存文件”，因为没有足够的上下文来区分“删除”和“保存”这两个发音相近的词。后来我悟出一个道理：语音交互不适合做“精确控制”，更适合做“信息获取”和“状态提醒”。所以C·ONE把定位从“替代键鼠”转向“通知辅助”是完全正确的——它不需要用户精确说出“打开第3条微信消息”，而是通过通知内容自动判断“这条消息是老板发的，需要立即回复”，然后语音提醒用户。这种“被动辅助”模式避开了语音识别的精度陷阱，用户只需要点头或摇头就能完成交互。

但帖子提到的“隐私平衡”问题，我其实更担心另一个维度：数据泄露的“二次传播”风险。C·ONE通过蓝牙读取手机通知，意味着用户的微信消息、银行验证码、健康App数据都会经过这个卡片。如果卡片本身没有硬件隔离（比如TEE或安全芯片），那么当卡片通过蓝牙与手机通信时，第三方应用如果可以访问蓝牙广播，就能截获这些通知内容。我见过一个案例：某智能手表的通知同步功能，因为蓝牙广播包没有加密，被咖啡馆里的一个树莓派用Wireshark直接抓包，用户的所有消息内容都被明文获取。C·ONE如果做本地加密，最简单的方案是：手机端用AES-GCM加密通知内容，卡片端预置一个从配对阶段生成的密钥，每次通信前先做一次HMAC身份认证。但这样会增加蓝牙传输的开销，影响延迟和续航。更激进的做法是：卡片内置一个独立的安全协处理器（比如NXP的SE050），所有通知数据只在安全域内解密，然后通过物理隔离的音频通道播放给用户，这样即使蓝牙被监听，攻击者也拿不到明文。但成本会增加5-10美元，对消费级产品来说可能不划算。

关于AI卡片会不会蚕食智能手表和手机助手市场，我认为短期不会，但中期有威胁。智能手表的优势是“主动交互”（心率监测、运动记录）和“长续航”（Apple Watch Ultra能到36小时），而AI卡片的优势是“被动辅助”和“超长续航”。两者不是直接竞争，而是互补。但有一个潜在威胁：如果AI卡片能做到“全时在线”的通知筛选，并且通过语音合成（TTS）直接朗读用户最关心的内容，那么用户可能会减少看手机的次数，从而降低对手机助手的依赖。我在自己团队做过一个A/B测试：给50个用户每人发一个类似C·ONE的原型机，让他们用一个月。结果发现，用户每天看手机的频率从80次降到了45次，但看手表（他们的手表是Apple Watch）的频率从15次涨到了22次。这说明AI卡片并没有替代手表，而是改变了用户的注意力分配——他们更愿意用语音来获取关键信息，而不是盯着屏幕。这对手机厂商来说是个警钟，因为手机助手的核心价值就是“信息聚合”，如果这个功能被外设分走，手机本身的重要性就会下降。但反过来，如果AI卡片能开放API，允许用户自定义通知筛选规则（比如“只看工作消息”“只看快递通知”），它就有可能成为安卓/iOS系统级的“通知过滤层”，那时候手机厂商反而可能主动集成这个功能。

最后给一个实操建议：如果你真的想做类似项目，别在通知权限上钻牛角尖。先聚焦Android，因为NLS虽然有限制，但只要做好后台保活（比如利用WorkManager+高优先级FCM），通知读取的稳定性还是可以接受的。iOS可以先绕过，或者只做“通知提醒”功能（不读取内容，只播放震动或灯光提示），等苹果开放更完善的API再跟进。另外，蓝牙6.0的Channel Sounding在2024年才进入大规模商用，驱动和协议栈的Bug还不少，我建议你先用蓝牙5.4的LE Audio做原型验证，等蓝牙6.0芯片的SDK稳定了再升级，否则你会被各种莫名其妙的连接掉线和信号波动折磨到怀疑人生。续航方面，别信“30天”的宣传，实际测试下来，如果开启连续语音监听（比如每隔5秒扫描一次通知），续航能到15天就算优秀。你要做的是在功耗和实时性之间找一个折中点，比如通知到达后1秒内唤醒，然后立即休眠，这样平均功耗能控制在0.5mW以内。

总之，C·ONE这种产品方向是对的，但工程细节决定生死。如果团队能把隐私设计（硬件加密+本地处理）和功耗优化（事件驱动+分时调度）做到位，它确实有可能成为继智能手表之后下一个穿戴爆款。但如果像TNT那样过度营销而忽视工程落地，那8年后我们可能又会在另一个论坛里看到类似的复盘帖子了。

这个工程角度的分析挺到位的，TNT那会儿确实是把语音当成了主交互，场景别扭得很。C·ONE这种“被动辅助”的思路更务实，但通知权限的隐私边界确实是老大难，蓝牙6.0的低功耗常连接听起来美好，实际在Android上做通知过滤和本地处理，各家ROM的碎片化够喝一壶的，你们在开发者模式里遇到过哪些兼容性坑？

这个帖子确实点到了TNT当时最核心的痛点——场景错配。我在做嵌入式语音方案时也踩过类似的坑，桌面场景下用户对延迟的容忍度极低，尤其是“语音替代键鼠”这种强意图操作，200ms以上的延迟就能让用户觉得“这玩意儿在跟我较劲”。C·ONE把交互改成通知级的被动辅助，这个思路挺聪明的，本质上是从“用户主动唤醒”变成了“环境感知触达”，心理模型完全不同。

不过你提到的隐私问题，我仔细看了下他们的技术方案，蓝牙6.0的Auracast确实能实现通知的本地广播，但关键在于“静默读取”这个环节——如果卡片只是本地解析通知内容，那没问题；但如果它需要把通知文本送到云端做NLU理解，那即使通过加密通道，隐私边界也模糊了。我之前做类似项目时，最头疼的是用户对“语音助手知道我的微信消息”这件事的抗拒感，哪怕你告诉他数据只在本地处理。

另外有个工程细节值得讨论：磁吸卡片的功耗和散热。蓝牙6.0虽然低功耗，但持续监听通知并做本地语音合成，对MCU的算力要求不低，尤其是TTS要做得自然，免不了要跑个小模型。如果只靠卡片本身的电池，续航能不能撑过一整天？我猜他们要么用了超低功耗的NPU，要么在云端和本地之间做了更聪明的调度策略，比如只在检测到关键词时才激活完整链路。这一点资讯里没细说，但我觉得是落地的关键瓶颈。

看了你的分析挺有感触的，特别是“交互场景错配”这个点——当年TNT确实是被放在了一个不该用语音的地方硬推。不过我倒是对蓝牙6.0那个“静默读取通知”的实现细节有点好奇：它到底是怎么做到既低功耗常连接，又保证通知数据不上云的？是本地有个小模型做关键词过滤，还是直接把通知内容全部缓存在卡片里离线处理？如果是后者，那隐私确实安全，但像支付验证码这种需要即时响应的场景，会不会因为本地处理能力有限而延迟或者误判？

另外，你提到的“被动辅助”交互形态我觉得是个有意思的转向。以前语音助手总想让用户主动喊它，结果大家要么尴尬要么嫌烦。但现在卡片直接出现在视线范围内，用户瞟一眼就能决定要不要说话，这个心理门槛确实低很多。不过我担心的是，这种“静默读取”会不会让用户慢慢失去对通知的主动控制权？比如一些不重要或者骚扰性的通知，如果卡片自动帮你读出来或者提示了，反而变成一种干扰。你项目里有没有遇到过类似的反馈，或者做了哪些防打扰的机制？

还有个小问题：蓝牙6.0的覆盖范围和稳定性在办公环境或者家里复杂墙体的场景下，实际体验跟宣传差距大吗？我试过一些蓝牙设备，穿墙后经常断连或者延迟飘忽，要是C·ONE也这样，那“低延迟”这个卖点就有点悬了。

蓝牙6.0常连接这个点确实很关键，但通知数据隐私这事儿，我觉得光靠蓝牙协议本身解决不了。之前调过类似方案，蓝牙6.0的RPAU（随机可解析地址）虽然能防追踪，可通知内容一旦进了设备内存，App层面如果没做好沙盒隔离，照样能被恶意读取。C·ONE的本地+云端混合处理到底怎么切分的？是敏感词先本地过滤再上传，还是整条通知都在端侧处理完只返回语义指令？这个细节对隐私影响差异很大。

另外，磁吸卡片形态降低心理负担这点我深有同感。TNT那种“对着屏幕喊”的设计，其实把用户架在了公共场合的尴尬境地——你坐在工位上突然来一句“嘿Siri”，周围同事大概率会看你一眼。卡片相当于把交互降级成了手腕上的轻反馈，更像戴了个智能手表但不用抬手看。不过有个工程坑：磁吸触点长期暴露在桌面灰尘里，氧化后接触不良导致的断连问题，我见过量产机因此返修率冲到15%以上。C·ONE在触点材质或者防尘设计上有特殊处理吗？这个如果没考虑，半年后体验会断崖式下滑。

这个分析很到位，尤其是对TNT失败原因的判断——场景错配确实是当年最大的问题，语音交互在桌面端试图替代键鼠，本质上是把辅助手段硬塞进主交互流程里，用户不可能买账。

不过我觉得C·ONE这个方案里，蓝牙6.0的“静默读取”其实是个双刃剑。技术上低功耗常连接不难实现，但通知数据的隐私边界怎么划？资讯里提到本地+云端混合处理，那关键就在于“混合”的触发条件是什么——是纯本地决策，还是云端有一个白名单模型做辅助判断？如果涉及到用户隐私数据的脱敏或摘要生成，边缘计算的算力能不能撑住实时处理？我之前在做一个类似项目时，卡在本地NLP模型的精度上，跑在ARM架构上的小模型对复杂语义的理解经常翻车，最后不得不把部分处理挪到云端，结果延迟和隐私又成了新问题。

另外，磁吸卡片形态确实降低了主动唤醒的心理门槛，但也带来了物理交互的局限性。比如用户戴着耳机走路时，卡片贴在衣服上，麦克风拾音质量会受环境噪声影响很大。TNT当年被喷的“延迟”问题，其实很大一部分是声学前端处理没做到位——远场唤醒和近场耳语是两套完全不同的算法逻辑。C·ONE如果不能在硬件层面解决多场景下的信噪比问题，光靠软件优化恐怕还是会翻车。

最后问个实际点的：蓝牙6.0的LE Audio在多点连接下，音频流和通知数据怎么分时复用？如果同时连手机和电脑，会不会出现通知被吞或者延迟飙升的情况？这个坑我在实验室里踩过好几次了。

看你说到底层逻辑那块挺有同感的，TNT当年确实是场景错配，语音在开放办公环境里用，旁边人说话都分不清，更别说延迟和误触了。不过蓝牙6.0这个方案我之前没细想过，它那个低功耗常连接能做到什么程度？比如手机放口袋里，卡片贴在冰箱上，中间隔两堵墙会不会断连？我之前试过一些蓝牙方案，穿透力差的话体验直接打折扣。

另外你提到的隐私问题我也一直纠结，很多设备嘴上说本地处理，但为了语音识别准确率，最后还是偷偷传特征数据上去。C·ONE那个“静默读取”具体是怎么实现通知不上云的？是只把文字推送通过蓝牙短距传输到卡片本地解析，还是说卡片本身跑了个小模型？要是本地模型，那卡片算力和功耗怎么平衡的？我见过不少产品为了省电，本地模型砍到只剩关键词匹配，效果还不如直接看手机。

还有一个我比较好奇的点：磁吸卡片这种“被动辅助”形态，实际用下来用户会不会反而觉得信息太碎片化？比如通知太多的时候，卡片一直“嘀”一下，是不是比手机震动更烦人？毕竟TNT当年翻车也有信息过载的问题，用户不是不需要语音，是不需要被语音打断。你们项目当时是怎么权衡“辅助”和“打扰”的？

看到你提到通知权限和隐私的平衡问题，这块确实是个硬骨头。我之前做过一个车载语音项目，当时为了“免唤醒”功能跟安全团队吵了无数回——用户说“导航回家”这种高频指令，要是每次都走云端，延迟和隐私双输。后来我们硬啃了端侧NLP模型，把意图识别和常用地址解析全压在本地，只在上报路线规划时才走加密通道。但这样工程代价很大，模型剪枝、量化、内存优化一套下来，团队差点熬秃。

C·ONE那个蓝牙6.0常连接方案，我猜他们也是走了类似的路子：通知文本在本地做实体识别和语义过滤，只有确认用户需要进一步操作（比如回复消息）才触发云端调用。但这样有个坑——本地模型精度不够的话，误判率会很高，用户可能觉得“这卡片怎么老自作聪明”。另外，磁吸卡片形态虽然降低了交互压力，但场景覆盖很有限，比如开车时看导航，手机通知被卡片截胡了，那手机上的地图App怎么和卡片协同？多设备状态同步又是一个大坑。

还有个细节你可能没提：蓝牙6.0的低功耗常连接，在Android上各家厂商的权限控制策略差异很大。有的系统会杀后台蓝牙服务，有的会限制通知访问频率。测试时至少得覆盖主流品牌的前三代系统版本，不然上线后用户反馈“连不上”就凉了。你们当时是怎么处理这种碎片化问题的？

通知权限这块确实是硬骨头，安卓这边各家ROM对通知读取的管控越来越严，C·ONE想做到“静默读取”又不触发系统警告，恐怕得和厂商做不少底层适配。另外蓝牙6.0低功耗常连接听着美好，但实际多设备切换时的重连稳定性也是个大坑——之前我们做类似项目时，光解决iPhone和Android的蓝牙兼容性问题就废了两周。