1. 一個讓我頭疼的真實(shí)場景為什么該安靜時不安靜大概兩三個月前我在自己維護(hù)的一個效率小工具里加了一個看起來特別簡單的需求工作日早晨到公司之后自動把通知聲音關(guān)掉午休結(jié)束再打開。寫個定時任務(wù)不就完了我當(dāng)時也是這么想的?？烧嬲芷饋碇笪也虐l(fā)現(xiàn)自己嚴(yán)重低估了上下文這三個字的重量。第一次翻車是在一個周六。我加班到了公司手機(jī)在九點(diǎn)整準(zhǔn)時不帶感情地靜了音十一點(diǎn)半又準(zhǔn)時把聲音打開——可那一刻我正開著會手機(jī)在桌上震得嗡嗡響全組人都看了我一眼。這個場景讓我徹底放棄了按時間定規(guī)則的幼稚思路轉(zhuǎn)而開始琢磨一套真正能感知環(huán)境、再決定表現(xiàn)的狀態(tài)機(jī)制。我把這套機(jī)制命名為context-mode后來它從一個小定時器慢慢長成了一個三層結(jié)構(gòu)的輕量框架。這篇文章想講清楚三件事context-mode 到底在解決什么問題、我具體怎么實(shí)現(xiàn)它、以及上線之后踩過的那些坑。如果你在做個人效率工具、自動化聯(lián)動、或者任何根據(jù)環(huán)境自動調(diào)整行為的功能這篇應(yīng)該能幫你少走不少彎路。代碼本身不算復(fù)雜真正的難點(diǎn)在于思路——很多細(xì)節(jié)是跑了一兩周才想明白的。2. 先想清楚再說實(shí)現(xiàn)上下文模式不是一堆 if else很多人一聽到根據(jù)場景自動切換就想到寫判斷if 是工作日 時間是九點(diǎn)就靜音。我一開始也是這么干的而且為此付出了代價。這么寫有兩個致命問題一是規(guī)則之間很容易打架二是外部條件稍微變化整套邏輯就塌了。2.1 上下文不等于場景兩個容易混淆的概念先說兩個概念。很多文章混著用但實(shí)際設(shè)計(jì)時必須分清楚不然代碼結(jié)構(gòu)一定會亂。上下文context是原始信號比如當(dāng)前時間、GPS 坐標(biāo)、WiFi 名稱、加速度計(jì)數(shù)據(jù)、日歷里的日程、藍(lán)牙設(shè)備列表。它是客觀事實(shí)還沒有經(jīng)過任何解釋。場景scene / scenario是對上下文的解讀結(jié)果比如在開會通勤中在家休息。同一個上下文可能對應(yīng)多個場景同一個場景也可能由完全不同的上下文組合觸發(fā)。context-mode 的核心價值不在采集——采集這件事誰都會它真正難的部分在把上下文解釋成場景這步。解釋得準(zhǔn)后續(xù)動作才有意義解釋得不準(zhǔn)后面所有自動化都是在錯誤的假設(shè)上跳舞還不如手動切換。2.2 三層結(jié)構(gòu)為什么必須拆開我把整個機(jī)制拆成了三層采集層Signal Layer負(fù)責(zé)拿原始信號屏蔽不同數(shù)據(jù)源之間的差異。推斷層Inference Layer根據(jù)信號算出一個當(dāng)前場景概率分布也就是對置信度的評估。執(zhí)行層Action Layer根據(jù)推斷結(jié)果去調(diào)用具體動作比如改通知策略、切界面主題、暫停后臺任務(wù)。為什么必須拆開因?yàn)槲页赃^不拆的虧。最早我把采集和判斷寫在同一個模塊里結(jié)果換一個定位服務(wù)商就要改幾十處調(diào)用改完還引入了一堆新 bug。拆開之后每一層只對接口負(fù)責(zé)替換數(shù)據(jù)源、調(diào)整推斷邏輯、變更動作策略彼此不影響。而且每一層可以單獨(dú)測試——這對調(diào)試為什么又誤判了這種問題特別重要你不需要為了確認(rèn)一個問題翻遍整個項(xiàng)目。3. 從零搭一套 context-mode采集層和推斷層的具體實(shí)現(xiàn)下面說實(shí)現(xiàn)。我用的技術(shù)棧是 TypeScript 加 React Native但下面的設(shè)計(jì)不綁定任何平臺Android、iOS、Web 端都能照著這個思路做。核心不是某個框架的 API而是分層方式和推斷策略。3.1 采集層哪些信號要采哪些信號別碰采集層最初我列了一個特別長的信號清單GPS、WiFi、藍(lán)牙、氣壓計(jì)、光線傳感器、電量、充電狀態(tài)、日歷、通知欄……后來一測發(fā)現(xiàn)盲目采集既耗電又難維護(hù)很多信號采集了根本用不上。最終線上只保留了六類信號每一項(xiàng)都有明確用途。信號采樣方式用途系統(tǒng)時間事件驅(qū)動區(qū)分工作日/周末、早中晚日歷日程事件驅(qū)動判斷會議、出行安排WiFi 列表低頻掃描區(qū)分在家、在辦公室、在陌生地點(diǎn)地理位置顯著變化觸發(fā)輔助判斷通勤活動狀態(tài)系統(tǒng) API 回調(diào)區(qū)分步行、騎車、靜止音頻環(huán)境短時采樣輔助判斷會議室 vs 咖啡廳這里面我最想提醒的一點(diǎn)是別碰那些需要高頻輪詢的信號比如持續(xù)開 GPS、連續(xù)讀麥克風(fēng)。能靠系統(tǒng)回調(diào)解決的絕不用定時器去輪詢采集這是后來耗電問題的主要解藥后面專門有一節(jié)細(xì)說。3.2 推斷層我用的加權(quán)評分規(guī)則而不是機(jī)器學(xué)習(xí)很多人一聽到智能兩個字就條件反射要上機(jī)器學(xué)習(xí)模型。但這個場景我強(qiáng)烈建議先用規(guī)則原因有三樣本太少、解釋性要求高、調(diào)試成本低。我自己先寫了一套加權(quán)評分引擎每個信號給出一個該信號支持某場景的程度評分最后按權(quán)重求和拿這個分?jǐn)?shù)和閾值比較。舉個例子推斷在辦公室開會這個場景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; }這當(dāng)然不是完整代碼真正的生產(chǎn)版本還包含連續(xù)采樣、置信度累計(jì)、場景互斥等邏輯。核心思路是閾值加置信度總分超過 0.7 認(rèn)定為開會0.4 到 0.7 之間屬于不確定要等下一輪信號確認(rèn)而不是立刻切換。這個不確定區(qū)間是減少誤判的關(guān)鍵比任何花哨的算法都管用。為什么不上模型因?yàn)閳鼍皵?shù)量有限——我當(dāng)時只定義六種特征相對穩(wěn)定信號之間的因果關(guān)系也比較明確規(guī)則完全夠用。等哪天需要處理大量未知場景或者用戶個性化差異太明顯再疊加一層輕量分類器也不遲而且到時候采集層和推斷層的接口已經(jīng)分好了遷移成本很低。3.3 執(zhí)行層模式切過去之后動作怎么落地推斷層產(chǎn)出的是場景但它本身不做事。執(zhí)行層負(fù)責(zé)把場景翻譯成具體動作。這里我建了一張模式表描述場景和動作的映射關(guān)系非常樸素但非常有效。開會場景通知靜音、關(guān)閉震動、自動回復(fù)未接來電通勤場景打開播客 App 并開始播放、把新聞類通知折疊在家場景降低通知優(yōu)先級、開啟勿擾模式睡眠場景徹底靜音、自動調(diào)暗屏幕亮度執(zhí)行層還有一個容易被忽略但特別重要的設(shè)計(jì)動作必須可回滾。比如開會結(jié)束必須把通知策略恢復(fù)原狀否則用戶錯過重要消息代價非常大。我在執(zhí)行層做了一個快照機(jī)制切換模式前記錄舊狀態(tài)離開模式時恢復(fù)快照。聽起來簡單但能避免開了勿擾忘關(guān)這種低級別的、卻特別傷害用戶信任感的問題。實(shí)際用下來回滾邏輯的重要性甚至比切換本身還高。4. 上線一周我踩過的坑以及怎么修框架寫完我抱著終于可以享受自動化便利的心態(tài)跑了一周。結(jié)果這一周基本是在修 bug 和罵自己中度過的。下面三個坑是最典型的每一個都讓我改動了不小的一塊設(shè)計(jì)。4.1 誤判問題的排查鏈路從一次會議模式亂入說起最典型的一次誤判周三下午三點(diǎn)我在家寫文檔手機(jī)突然靜音了。打開日志一看推斷層認(rèn)為在開會——因?yàn)樗鼨z測到日歷有一條日程、WiFi 是本機(jī)熱點(diǎn)、且設(shè)備靜止。三條信號全部命中評分超過了閾值于是執(zhí)行層二話不說把通知給關(guān)了。排查過程是這樣的先確認(rèn)執(zhí)行層沒問題模式確實(shí)是被推斷層正確調(diào)用的再看信號層發(fā)現(xiàn)日歷日程確實(shí)存在但那是鬧鐘提醒WiFi 熱點(diǎn)的 SSID 恰好和辦公室的某個公共 WiFi 相似設(shè)備靜止則是因?yàn)槲野阉旁谧郎铣潆?。問題出在信號語義太粗糙把有日歷條目當(dāng)成在開會把熱點(diǎn)名相似當(dāng)成在辦公室。修正方案有兩個。一是給信號加事件類型過濾只認(rèn)類型為會議的日歷條目鬧鐘提醒一概不參與評分二是 WiFi 匹配不再用字符串包含而是根據(jù) BSSID 精確匹配并維護(hù)一個已學(xué)習(xí)地點(diǎn)庫。改完之后這類誤判減少了八成以上。這個案例讓我明白誤判的根因往往不在推斷算法而在上游信號的語義精度。4.2 耗電問題的實(shí)測與調(diào)優(yōu)第二周我看電池統(tǒng)計(jì)差點(diǎn)沒跳起來context-mode 模塊每天耗電 23%。原因非常清楚——GPS 主動定位每小時一次、WiFi 掃描每五分鐘一次、音頻采樣每十分鐘一次這些都是輪詢式的硬采集每一個都在燒電。我做三步修正能回調(diào)就不要輪詢活動狀態(tài)改成系統(tǒng) Activity Recognition API它在步數(shù)變化時主動回調(diào)位置改成顯著位置變化監(jiān)聽而不是定時獲取音頻采樣只有在其他信號進(jìn)入不確定區(qū)時才啟動。分層采樣大部分時間用低功耗信號時間、日歷做粗篩只有粗篩結(jié)果落在不確定區(qū)才拉高功耗信號GPS、WiFi、音頻做精判。加冷卻時間某個場景一旦被確認(rèn)十分鐘內(nèi)不再重新采樣推斷避免頻繁觸發(fā)不必要的傳感器。調(diào)整之后模塊耗電從 23% 降到了 4% 左右。核心思路可以總結(jié)成一句話用廉價信號做閘門讓昂貴信號只在必要時出場。這條原則后來被我用到項(xiàng)目里的各個角落收益都很明顯。4.3 乒乓效應(yīng)為什么加了滯回區(qū)間才穩(wěn)定還有一個特別隱蔽的問題——模式來回橫跳。比如用戶從辦公室走到樓下便利店WiFi 斷開推斷層立刻從辦公切到通勤走進(jìn)便利店連上新的 WiFi又切成別的場景因?yàn)槲野驯憷甑?WiFi 誤歸到了某個已知地點(diǎn)。短短幾分鐘內(nèi)切換了兩三次通知也跟著響了好幾次非常惱人。這類問題在控制論里有個術(shù)語叫抖動解法是滯回切換場景需要連續(xù) N 次采樣都超過閾值且進(jìn)入新場景后要維持一小段時間才算切換成功回到舊場景則要求分?jǐn)?shù)掉到更低的閾值。我把進(jìn)入閾值設(shè)為 0.7、離開閾值設(shè)為 0.4中間 0.4 到 0.7 就是死區(qū)任何輕微抖動都不會觸發(fā)切換。加上這個機(jī)制之后每天的切換次數(shù)從十幾回降到了兩三回體驗(yàn)才終于穩(wěn)定下來。如果你也做類似的場景判斷滯回區(qū)間一定要加這不是優(yōu)化項(xiàng)是必需品。5. 實(shí)測數(shù)據(jù)與后續(xù)演進(jìn)方向跑了三周我把數(shù)據(jù)整理了一下給想?yún)⒖嫉娜艘粋€相對完整的參照。這里面的數(shù)字都是我自己環(huán)境下的實(shí)測結(jié)果不同設(shè)備、不同使用習(xí)慣會有差異但量級可以參考。5.1 三周實(shí)測準(zhǔn)確率、耗電和延遲的具體數(shù)字指標(biāo)數(shù)據(jù)場景推斷準(zhǔn)確率六種場景平均 91%開會場景最低83%平均切換延遲從信號變化到動作生效約 12 秒日耗電穩(wěn)定在 3% 到 4%誤切率每天約 0.8 次集中在午休前后開會場景準(zhǔn)確率最低原因是會議室信號太復(fù)雜有人連著手機(jī)熱點(diǎn)、有人藍(lán)牙耳機(jī)頻繁進(jìn)出、環(huán)境音頻總在變化。我把會議場景的音頻權(quán)重調(diào)低、日歷權(quán)重調(diào)高之后準(zhǔn)確率升到了 87%。這說明規(guī)則的權(quán)重不是一次定死的需要根據(jù)實(shí)際數(shù)據(jù)反復(fù)調(diào)日志系統(tǒng)在這里功不可沒。5.2 我認(rèn)為值得繼續(xù)做的三個方向第一是用戶反饋閉環(huán)?，F(xiàn)在推斷完全靠機(jī)器用戶發(fā)現(xiàn)誤判只能手動切回但系統(tǒng)沒有記住這次糾正。下一步我打算在用戶手動切換時記錄當(dāng)時的信號快照作為一條反例存進(jìn)規(guī)則庫下次遇到相似信號組合時自動降權(quán)。這樣系統(tǒng)會越用越準(zhǔn)而不是永遠(yuǎn)停在初始權(quán)重。第二是跨設(shè)備上下文共享。手表上檢測到心率升高、耳機(jī)已經(jīng)戴上了——這些信號如果能讓手機(jī)感知到場景判斷會精準(zhǔn)得多。架構(gòu)上采集層和推斷層本來就是分離的加一個同步通道就能擴(kuò)展難點(diǎn)在于設(shè)備間延遲和處理離線狀態(tài)。第三是場景定義的個性化。不同的人對開會的定義完全不同有人開視頻會、有人純電話、有人線下會議室。我準(zhǔn)備把規(guī)則里的場景拆成子場景讓用戶自己配置觸發(fā)條件而不是用一個寫死的版本服務(wù)所有人。這一步做完才有資格叫個人效率工具。6. 最后分享兩個小經(jīng)驗(yàn)寫這篇的時候我又翻了翻當(dāng)時的筆記有兩個經(jīng)驗(yàn)想單獨(dú)拎出來說。一是不要把識別準(zhǔn)當(dāng)成唯一目標(biāo)。context-mode 說到底是為了讓用戶少操心如果系統(tǒng)每隔十分鐘彈窗問您是不是在開會那它比手動切換還煩。寧可偶爾不切換也不要頻繁切錯——不切換只是少了一點(diǎn)便利切錯了是給用戶添亂。信任感一旦崩了再準(zhǔn)的算法也救不回來。二是日志比代碼更重要。我把每次信號、評分、閾值比較結(jié)果都寫進(jìn)了本地日志問題復(fù)現(xiàn)時靠日志說話而不是靠猜。這套機(jī)制的調(diào)試難度遠(yuǎn)高于普通業(yè)務(wù)代碼你沒法簡單地打斷點(diǎn)等 bug 復(fù)現(xiàn)因?yàn)?bug 依賴的是時間、位置、周圍環(huán)境這些不可控變量。沒有日志我大概率到現(xiàn)在還在和幽靈誤判搏斗。如果你也準(zhǔn)備在項(xiàng)目里引入類似的機(jī)制我的建議是從最小的場景集開始先支持兩三種場景把采集、推斷、執(zhí)行、回滾的完整閉環(huán)跑通再慢慢加。最容易翻車的不是技術(shù)而是你還沒建立足夠信任的時候就試圖把它做成一個包羅萬象的智能助手。少即是多在上下文相關(guān)的設(shè)計(jì)里尤其成立。