1. 一个让我头疼的真实场景为什么该安静时不安静大概两三个月前我在自己维护的一个效率小工具里加了一个看起来特别简单的需求工作日早晨到公司之后自动把通知声音关掉午休结束再打开。写个定时任务不就完了我当时也是这么想的。可真正跑起来之后我才发现自己严重低估了上下文这三个字的重量。第一次翻车是在一个周六。我加班到了公司手机在九点整准时不带感情地静了音十一点半又准时把声音打开——可那一刻我正开着会手机在桌上震得嗡嗡响全组人都看了我一眼。这个场景让我彻底放弃了按时间定规则的幼稚思路转而开始琢磨一套真正能感知环境、再决定表现的状态机制。我把这套机制命名为context-mode后来它从一个小定时器慢慢长成了一个三层结构的轻量框架。这篇文章想讲清楚三件事context-mode 到底在解决什么问题、我具体怎么实现它、以及上线之后踩过的那些坑。如果你在做个人效率工具、自动化联动、或者任何根据环境自动调整行为的功能这篇应该能帮你少走不少弯路。代码本身不算复杂真正的难点在于思路——很多细节是跑了一两周才想明白的。2. 先想清楚再说实现上下文模式不是一堆 if else很多人一听到根据场景自动切换就想到写判断if 是工作日 时间是九点就静音。我一开始也是这么干的而且为此付出了代价。这么写有两个致命问题一是规则之间很容易打架二是外部条件稍微变化整套逻辑就塌了。2.1 上下文不等于场景两个容易混淆的概念先说两个概念。很多文章混着用但实际设计时必须分清楚不然代码结构一定会乱。上下文context是原始信号比如当前时间、GPS 坐标、WiFi 名称、加速度计数据、日历里的日程、蓝牙设备列表。它是客观事实还没有经过任何解释。场景scene / scenario是对上下文的解读结果比如在开会通勤中在家休息。同一个上下文可能对应多个场景同一个场景也可能由完全不同的上下文组合触发。context-mode 的核心价值不在采集——采集这件事谁都会它真正难的部分在把上下文解释成场景这步。解释得准后续动作才有意义解释得不准后面所有自动化都是在错误的假设上跳舞还不如手动切换。2.2 三层结构为什么必须拆开我把整个机制拆成了三层采集层Signal Layer负责拿原始信号屏蔽不同数据源之间的差异。推断层Inference Layer根据信号算出一个当前场景概率分布也就是对置信度的评估。执行层Action Layer根据推断结果去调用具体动作比如改通知策略、切界面主题、暂停后台任务。为什么必须拆开因为我吃过不拆的亏。最早我把采集和判断写在同一个模块里结果换一个定位服务商就要改几十处调用改完还引入了一堆新 bug。拆开之后每一层只对接口负责替换数据源、调整推断逻辑、变更动作策略彼此不影响。而且每一层可以单独测试——这对调试为什么又误判了这种问题特别重要你不需要为了确认一个问题翻遍整个项目。3. 从零搭一套 context-mode采集层和推断层的具体实现下面说实现。我用的技术栈是 TypeScript 加 React Native但下面的设计不绑定任何平台Android、iOS、Web 端都能照着这个思路做。核心不是某个框架的 API而是分层方式和推断策略。3.1 采集层哪些信号要采哪些信号别碰采集层最初我列了一个特别长的信号清单GPS、WiFi、蓝牙、气压计、光线传感器、电量、充电状态、日历、通知栏……后来一测发现盲目采集既耗电又难维护很多信号采集了根本用不上。最终线上只保留了六类信号每一项都有明确用途。信号采样方式用途系统时间事件驱动区分工作日/周末、早中晚日历日程事件驱动判断会议、出行安排WiFi 列表低频扫描区分在家、在办公室、在陌生地点地理位置显著变化触发辅助判断通勤活动状态系统 API 回调区分步行、骑车、静止音频环境短时采样辅助判断会议室 vs 咖啡厅这里面我最想提醒的一点是别碰那些需要高频轮询的信号比如持续开 GPS、连续读麦克风。能靠系统回调解决的绝不用定时器去轮询采集这是后来耗电问题的主要解药后面专门有一节细说。3.2 推断层我用的加权评分规则而不是机器学习很多人一听到智能两个字就条件反射要上机器学习模型。但这个场景我强烈建议先用规则原因有三样本太少、解释性要求高、调试成本低。我自己先写了一套加权评分引擎每个信号给出一个该信号支持某场景的程度评分最后按权重求和拿这个分数和阈值比较。举个例子推断在办公室开会这个场景const weights { isWorkday: 0.3, hasMeeting: 0.4, wifiIsOffice: 0.2, isStationary: 0.1 }; function inferScene(signals: SignalValues): number { let officeScore 0; if (signals.isWorkday) officeScore weights.isWorkday; if (signals.hasMeeting) officeScore weights.hasMeeting; if (signals.wifiIsOffice) officeScore weights.wifiIsOffice; if (signals.isStationary) officeScore weights.isStationary; return officeScore; }这当然不是完整代码真正的生产版本还包含连续采样、置信度累计、场景互斥等逻辑。核心思路是阈值加置信度总分超过 0.7 认定为开会0.4 到 0.7 之间属于不确定要等下一轮信号确认而不是立刻切换。这个不确定区间是减少误判的关键比任何花哨的算法都管用。为什么不上模型因为场景数量有限——我当时只定义六种特征相对稳定信号之间的因果关系也比较明确规则完全够用。等哪天需要处理大量未知场景或者用户个性化差异太明显再叠加一层轻量分类器也不迟而且到时候采集层和推断层的接口已经分好了迁移成本很低。3.3 执行层模式切过去之后动作怎么落地推断层产出的是场景但它本身不做事。执行层负责把场景翻译成具体动作。这里我建了一张模式表描述场景和动作的映射关系非常朴素但非常有效。开会场景通知静音、关闭震动、自动回复未接来电通勤场景打开播客 App 并开始播放、把新闻类通知折叠在家场景降低通知优先级、开启勿扰模式睡眠场景彻底静音、自动调暗屏幕亮度执行层还有一个容易被忽略但特别重要的设计动作必须可回滚。比如开会结束必须把通知策略恢复原状否则用户错过重要消息代价非常大。我在执行层做了一个快照机制切换模式前记录旧状态离开模式时恢复快照。听起来简单但能避免开了勿扰忘关这种低级别的、却特别伤害用户信任感的问题。实际用下来回滚逻辑的重要性甚至比切换本身还高。4. 上线一周我踩过的坑以及怎么修框架写完我抱着终于可以享受自动化便利的心态跑了一周。结果这一周基本是在修 bug 和骂自己中度过的。下面三个坑是最典型的每一个都让我改动了不小的一块设计。4.1 误判问题的排查链路从一次会议模式乱入说起最典型的一次误判周三下午三点我在家写文档手机突然静音了。打开日志一看推断层认为在开会——因为它检测到日历有一条日程、WiFi 是本机热点、且设备静止。三条信号全部命中评分超过了阈值于是执行层二话不说把通知给关了。排查过程是这样的先确认执行层没问题模式确实是被推断层正确调用的再看信号层发现日历日程确实存在但那是闹钟提醒WiFi 热点的 SSID 恰好和办公室的某个公共 WiFi 相似设备静止则是因为我把它放在桌上充电。问题出在信号语义太粗糙把有日历条目当成在开会把热点名相似当成在办公室。修正方案有两个。一是给信号加事件类型过滤只认类型为会议的日历条目闹钟提醒一概不参与评分二是 WiFi 匹配不再用字符串包含而是根据 BSSID 精确匹配并维护一个已学习地点库。改完之后这类误判减少了八成以上。这个案例让我明白误判的根因往往不在推断算法而在上游信号的语义精度。4.2 耗电问题的实测与调优第二周我看电池统计差点没跳起来context-mode 模块每天耗电 23%。原因非常清楚——GPS 主动定位每小时一次、WiFi 扫描每五分钟一次、音频采样每十分钟一次这些都是轮询式的硬采集每一个都在烧电。我做三步修正能回调就不要轮询活动状态改成系统 Activity Recognition API它在步数变化时主动回调位置改成显著位置变化监听而不是定时获取音频采样只有在其他信号进入不确定区时才启动。分层采样大部分时间用低功耗信号时间、日历做粗筛只有粗筛结果落在不确定区才拉高功耗信号GPS、WiFi、音频做精判。加冷却时间某个场景一旦被确认十分钟内不再重新采样推断避免频繁触发不必要的传感器。调整之后模块耗电从 23% 降到了 4% 左右。核心思路可以总结成一句话用廉价信号做闸门让昂贵信号只在必要时出场。这条原则后来被我用到项目里的各个角落收益都很明显。4.3 乒乓效应为什么加了滞回区间才稳定还有一个特别隐蔽的问题——模式来回横跳。比如用户从办公室走到楼下便利店WiFi 断开推断层立刻从办公切到通勤走进便利店连上新的 WiFi又切成别的场景因为我把便利店的 WiFi 误归到了某个已知地点。短短几分钟内切换了两三次通知也跟着响了好几次非常恼人。这类问题在控制论里有个术语叫抖动解法是滞回切换场景需要连续 N 次采样都超过阈值且进入新场景后要维持一小段时间才算切换成功回到旧场景则要求分数掉到更低的阈值。我把进入阈值设为 0.7、离开阈值设为 0.4中间 0.4 到 0.7 就是死区任何轻微抖动都不会触发切换。加上这个机制之后每天的切换次数从十几回降到了两三回体验才终于稳定下来。如果你也做类似的场景判断滞回区间一定要加这不是优化项是必需品。5. 实测数据与后续演进方向跑了三周我把数据整理了一下给想参考的人一个相对完整的参照。这里面的数字都是我自己环境下的实测结果不同设备、不同使用习惯会有差异但量级可以参考。5.1 三周实测准确率、耗电和延迟的具体数字指标数据场景推断准确率六种场景平均 91%开会场景最低83%平均切换延迟从信号变化到动作生效约 12 秒日耗电稳定在 3% 到 4%误切率每天约 0.8 次集中在午休前后开会场景准确率最低原因是会议室信号太复杂有人连着手机热点、有人蓝牙耳机频繁进出、环境音频总在变化。我把会议场景的音频权重调低、日历权重调高之后准确率升到了 87%。这说明规则的权重不是一次定死的需要根据实际数据反复调日志系统在这里功不可没。5.2 我认为值得继续做的三个方向第一是用户反馈闭环。现在推断完全靠机器用户发现误判只能手动切回但系统没有记住这次纠正。下一步我打算在用户手动切换时记录当时的信号快照作为一条反例存进规则库下次遇到相似信号组合时自动降权。这样系统会越用越准而不是永远停在初始权重。第二是跨设备上下文共享。手表上检测到心率升高、耳机已经戴上了——这些信号如果能让手机感知到场景判断会精准得多。架构上采集层和推断层本来就是分离的加一个同步通道就能扩展难点在于设备间延迟和处理离线状态。第三是场景定义的个性化。不同的人对开会的定义完全不同有人开视频会、有人纯电话、有人线下会议室。我准备把规则里的场景拆成子场景让用户自己配置触发条件而不是用一个写死的版本服务所有人。这一步做完才有资格叫个人效率工具。6. 最后分享两个小经验写这篇的时候我又翻了翻当时的笔记有两个经验想单独拎出来说。一是不要把识别准当成唯一目标。context-mode 说到底是为了让用户少操心如果系统每隔十分钟弹窗问您是不是在开会那它比手动切换还烦。宁可偶尔不切换也不要频繁切错——不切换只是少了一点便利切错了是给用户添乱。信任感一旦崩了再准的算法也救不回来。二是日志比代码更重要。我把每次信号、评分、阈值比较结果都写进了本地日志问题复现时靠日志说话而不是靠猜。这套机制的调试难度远高于普通业务代码你没法简单地打断点等 bug 复现因为 bug 依赖的是时间、位置、周围环境这些不可控变量。没有日志我大概率到现在还在和幽灵误判搏斗。如果你也准备在项目里引入类似的机制我的建议是从最小的场景集开始先支持两三种场景把采集、推断、执行、回滚的完整闭环跑通再慢慢加。最容易翻车的不是技术而是你还没建立足够信任的时候就试图把它做成一个包罗万象的智能助手。少即是多在上下文相关的设计里尤其成立。