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