企业官网建设流程全解析

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、蓝牙、气压计、光线传感器、电量、充电状态、日历、通知栏……后来一测，发现盲目采集既耗电又难维护，很多信号采集了根本用不上。最终线上只保留了六类信号，每一项都有明确用途。

这里面我最想提醒的一点是：别碰那些需要高频轮询的信号，比如持续开 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 扫描每五分钟一次、音频采样每十分钟一次，这些都是轮询式的"硬采集"，每一个都在烧电。

我做三步修正：

1. 能回调就不要轮询：活动状态改成系统 Activity Recognition API，它在步数变化时主动回调；位置改成"显著位置变化"监听，而不是定时获取；音频采样只有在其他信号进入"不确定区"时才启动。
2. 分层采样：大部分时间用低功耗信号（时间、日历）做粗筛，只有粗筛结果落在"不确定区"才拉高功耗信号（GPS、WiFi、音频）做精判。
3. 加冷却时间：某个场景一旦被确认，十分钟内不再重新采样推断，避免频繁触发不必要的传感器。

调整之后，模块耗电从 23% 降到了 4% 左右。核心思路可以总结成一句话：用廉价信号做闸门，让昂贵信号只在必要时出场。这条原则后来被我用到项目里的各个角落，收益都很明显。

4.3 乒乓效应：为什么加了滞回区间才稳定

还有一个特别隐蔽的问题——模式来回横跳。比如用户从办公室走到楼下便利店，WiFi 断开，推断层立刻从"办公"切到"通勤"；走进便利店连上新的 WiFi，又切成别的场景（因为我把便利店的 WiFi 误归到了某个已知地点）。短短几分钟内切换了两三次，通知也跟着响了好几次，非常恼人。

这类问题在控制论里有个术语叫"抖动"，解法是滞回：切换场景需要连续 N 次采样都超过阈值，且进入新场景后要维持一小段时间才算切换成功；回到旧场景则要求分数掉到更低的阈值。我把进入阈值设为 0.7、离开阈值设为 0.4，中间 0.4 到 0.7 就是死区，任何轻微抖动都不会触发切换。加上这个机制之后，每天的切换次数从十几回降到了两三回，体验才终于稳定下来。如果你也做类似的场景判断，滞回区间一定要加，这不是优化项，是必需品。

5. 实测数据与后续演进方向

跑了三周，我把数据整理了一下，给想参考的人一个相对完整的参照。这里面的数字都是我自己环境下的实测结果，不同设备、不同使用习惯会有差异，但量级可以参考。

5.1 三周实测：准确率、耗电和延迟的具体数字

开会场景准确率最低，原因是会议室信号太复杂：有人连着手机热点、有人蓝牙耳机频繁进出、环境音频总在变化。我把会议场景的音频权重调低、日历权重调高之后，准确率升到了 87%。这说明规则的权重不是一次定死的，需要根据实际数据反复调，日志系统在这里功不可没。

5.2 我认为值得继续做的三个方向

第一是用户反馈闭环。现在推断完全靠机器，用户发现误判只能手动切回，但系统没有记住这次纠正。下一步我打算在用户手动切换时记录当时的信号快照，作为一条"反例"存进规则库，下次遇到相似信号组合时自动降权。这样系统会越用越准，而不是永远停在初始权重。

第二是跨设备上下文共享。手表上检测到心率升高、耳机已经戴上了——这些信号如果能让手机感知到，场景判断会精准得多。架构上采集层和推断层本来就是分离的，加一个同步通道就能扩展，难点在于设备间延迟和处理离线状态。

第三是场景定义的个性化。不同的人对"开会"的定义完全不同：有人开视频会、有人纯电话、有人线下会议室。我准备把规则里的场景拆成"子场景"，让用户自己配置触发条件，而不是用一个写死的版本服务所有人。这一步做完，才有资格叫"个人"效率工具。

6. 最后分享两个小经验

写这篇的时候我又翻了翻当时的笔记，有两个经验想单独拎出来说。

一是不要把"识别准"当成唯一目标。context-mode 说到底是为了让用户少操心，如果系统每隔十分钟弹窗问"您是不是在开会？"，那它比手动切换还烦。宁可偶尔不切换，也不要频繁切错——不切换只是少了一点便利，切错了是给用户添乱。信任感一旦崩了，再准的算法也救不回来。

二是日志比代码更重要。我把每次信号、评分、阈值比较结果都写进了本地日志，问题复现时靠日志说话，而不是靠猜。这套机制的调试难度远高于普通业务代码：你没法简单地打断点等 bug 复现，因为 bug 依赖的是时间、位置、周围环境这些不可控变量。没有日志，我大概率到现在还在和"幽灵误判"搏斗。

如果你也准备在项目里引入类似的机制，我的建议是从最小的场景集开始：先支持两三种场景，把采集、推断、执行、回滚的完整闭环跑通，再慢慢加。最容易翻车的不是技术，而是你还没建立足够信任的时候，就试图把它做成一个包罗万象的"智能助手"。少即是多，在上下文相关的设计里尤其成立。