1. context-mode 是什么一個控制“感知半徑”的模式開關(guān)第一次在命令行工具里碰到 context-mode 這個概念其實是被git diff的上下文行給逼的。當時改一個配置文件只看到-timeout: 300和timeout: 500兩行代碼塊前后到底處于哪個業(yè)務(wù)分支光看 diff 完全判斷不出來。后來換成git diff -U10把改動前后各 10 行一起帶出來問題一下就清楚了。那時候我才意識到分析任何一段信息的時候核心的“改動點”固然重要但支撐它成立的上下文同樣關(guān)鍵。context-mode直白翻譯就是“上下文模式”它決定了工具或系統(tǒng)在處理信息時把周圍多大范圍內(nèi)的相關(guān)內(nèi)容一并納入視野。這個概念其實沒有想象中復雜但比想象中更重要。拿手機來類比通知欄的鈴聲模式就是一個 context-mode靜音模式只保留震動和屏幕提示會議模式過濾掉非緊急通知睡眠模式干脆把所有推送延遲到早上。模式本身不會改變消息內(nèi)容但它會改變系統(tǒng)對消息的處理范圍和處理優(yōu)先級。技術(shù)領(lǐng)域里的 context-mode 也是這個道理——命令行工具用它控制輸出信息量編輯器用它切換代碼感知范圍AI 應(yīng)用則用它管理上下文窗口的分配和截斷。如果你正在做工具開發(fā)、腳本維護或者整天和大模型對話打交道搞懂 context-mode 能讓你少交很多學費。1.1 從 diff 的上下文行聊起最經(jīng)典的 context-mode 范例就是diff工具的上下文參數(shù)。Git 提供-U和--unified參數(shù)git diff -U3表示只顯示改動前后 3 行g(shù)it diff -U20則顯示改動前后 20 行。grep命令也有同樣的設(shè)計-C 2表示在匹配行前后各顯示 2 行-A 2只顯示后面 2 行-B 2只顯示前面 2 行。這些參數(shù)的共同點就是允許用戶調(diào)整“上下文半徑”。這種設(shè)計背后的邏輯很實在代碼的行與行之間是彼此依托的一個變量名改了需要看它的聲明位置一個函數(shù)返回值變了需要看調(diào)用方的期望一條日志報錯需要看前后幾行的執(zhí)行軌跡。半徑設(shè)置得太小看到的是孤立的零件無法判斷零件是否裝配正確半徑設(shè)置得太大又會被大量無關(guān)行干擾白白浪費注意力和終端滾動空間。所以 context-mode 本質(zhì)上是一個“感知半徑”的調(diào)節(jié)器它把信息量控制在一個任務(wù)恰好需要的范圍內(nèi)。1.2 模式的本質(zhì)是給行為限定邊界我在維護內(nèi)部 CLI 工具時發(fā)現(xiàn)如果不顯式定義 context-mode工具的行為往往會變得渾渾噩噩日志全開時刷屏刷到飛起日志全關(guān)時出了問題又無從查起讀取配置時有時讀本地的、有時讀全局的全靠猜。后來我把工具的運行參數(shù)按模式做了分組問題瞬間少了大半。為什么一定要顯式提供“模式”而不是讓系統(tǒng)自己亂猜因為上下文范圍的取舍天然是模糊的。同一個查詢條件開發(fā)調(diào)試時需要看到數(shù)據(jù)源頭日常使用時只需要看到結(jié)果摘要給老板匯報時甚至只需要一個聚合數(shù)字。這種差異不是某個單一參數(shù)能解決的需要的是一個狀態(tài)集合讀取哪些配置、加載哪些數(shù)據(jù)源、輸出什么格式、記錄哪級日志。把這一整套狀態(tài)打包成一個可切換的 context-mode本質(zhì)上就是在給程序劃定清晰的行為邊界。模式之間相互隔離切過去就是另一套行為不需要一條條改開關(guān)也不容易改漏。1.3 兩類模式靜態(tài)設(shè)定與動態(tài)感知實踐里 context-mode 大致可以分成兩類。一類是靜態(tài)設(shè)定的模式用戶手動指定切換之后一直有效下次切換前不再變化適合狀態(tài)差異明確的場景比如開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境或者編輯器里的寫代碼模式、查日志模式、做代碼 review 模式。另一類是動態(tài)感知的模式系統(tǒng)根據(jù)當前的外部環(huán)境自動判斷上下文比如根據(jù)當前所在目錄、Git 分支、系統(tǒng)負載或者當前打開的文件類型自動決定該啟用哪一套行為。動態(tài)模式聽起來更智能但它有一個代價可預測性變差。我曾經(jīng)在一個項目里加入過“自動根據(jù)文件大小決定是否壓縮日志”的邏輯結(jié)果上線之后日志時有時無排查問題反而更難。后來我改成顯式 context-mode只在用戶主動切換時才改變行為配合命令提示符里顯示當前模式名整個工具的可預測性立刻回來了。所以我的建議是能用顯式靜態(tài)模式的地方優(yōu)先用顯式模式動態(tài)探測只用來做“默認值”和“輔助提示”不要把行為的最終決定權(quán)完全交給自動判斷。2. 不同技術(shù)場景里的 context-mode形態(tài)各異思路相通2.1 命令行工具用上下文參數(shù)改變輸出與執(zhí)行結(jié)果命令行可能是 context-mode 滲透最深的領(lǐng)域。除了git diff和grep還有很多工具提供了類似設(shè)計。ripgrep的--context參數(shù)用來控制匹配行上下文less查看日志時可以先用過濾出關(guān)鍵字再在過濾結(jié)果里上下翻頁tail -f配--pid可以只跟蹤指定進程的輸出而忽略其他進程。這些工具的共性是允許你在“只給結(jié)果”和“連同背景一起給”之間調(diào)整。我自己寫腳本時也經(jīng)常用環(huán)境變量模擬 context-mode。比如一個數(shù)據(jù)導出腳本EXPORT_MODEfull時導出原始明細EXPORT_MODEsummary時只導出統(tǒng)計結(jié)果EXPORT_MODEanomaly時只導出異常記錄。腳本內(nèi)部用同一個數(shù)據(jù)處理邏輯只是在最后輸出階段按模式分支。這樣做的好處是測試和生產(chǎn)共用同一套核心邏輯模式切換只影響邊界輸出不容易出現(xiàn)兩套實現(xiàn)之間行為漂移的問題。命令行工具的 context-mode 還有一個容易被忽略的場景安全操作確認。rm運行在交互模式時刪文件會詢問運行在靜默模式時直接刪除git 的--force-with-lease比--force更安全因為它限制了只能強制推送已同步的提交很多部署腳本也都有--dry-run和--apply的區(qū)分。這些都是 context-mode 的一種變形同一個操作在保護模式里先展示將要發(fā)生的事在確認后切換成執(zhí)行模式。保護模式讀上下文、評估影響范圍執(zhí)行模式實際改動目標邊界劃得很清楚。2.2 編輯器與 IDE按任務(wù)切換代碼感知范圍編輯器里的 context-mode 同樣重要。Vim 的用戶肯定熟悉“普通模式、插入模式、可視模式”這套設(shè)計普通模式下按鍵語義是導航和操作插入模式下按鍵直接輸入文本可視模式下按鍵變成選區(qū)擴展。同一顆按鍵在不同模式下觸發(fā)完全不同的行為這就是 context-mode 在交互層面的經(jīng)典實現(xiàn)它讓有限的鍵盤空間承載了更多操作語義?，F(xiàn)代 IDE 里的工作區(qū)配置文件Profile本質(zhì)上也承擔了 context-mode 的角色。我自己在 VS Code 里維護了兩套 Profile一套是日常開發(fā)的關(guān)閉了格式化和代碼提示之外的插件保持界面干凈另一套是調(diào)試排查用的專門啟動網(wǎng)絡(luò)抓包、接口模擬和日志分析插件。切換 Profile 相當于整體替換了編輯器的“感知能力包”日常開發(fā)時編輯器只需要關(guān)心我正在編輯的代碼調(diào)試排查時則需要它同時理解前后端接口和日志關(guān)聯(lián)這兩件事對編輯器的上下文需求截然不同。另外編輯器的折疊和高亮也涉及上下文半徑問題。查看一個大型函數(shù)時只看到函數(shù)簽名會丟失內(nèi)部邏輯細節(jié)全部展開又會淹沒在幾百行代碼里。按模塊折疊、按注釋塊高亮、大綱視圖只顯示結(jié)構(gòu)化符號這些都是編輯器在不同層級上展示上下文的模式。善用這些方式代碼閱讀效率能提升不少。2.3 大模型應(yīng)用把上下文管理升級為基礎(chǔ)設(shè)施大模型應(yīng)用可能是 context-mode 最熱點的主戰(zhàn)場。模型能力再強輸入時能攜帶的信息總量也受上下文窗口大小限制而一次完整的問答通常需要多方面的上下文信息角色設(shè)定、用戶目標、相關(guān)歷史對話、檢索到的知識片段、當前執(zhí)行到哪一步。怎么把這些信息安排進有限的窗口里直接影響回答質(zhì)量。我處理過不少 RAG檢索增強生成應(yīng)用的案例最常見的失敗原因就是上下文堆疊不當。要么把一整個文檔塊不加區(qū)分地塞進 prompt導致模型被無關(guān)內(nèi)容帶偏要么只截取與問題最相似的片段導致缺少必要的前置信息回答看似有依據(jù)實則根基不穩(wěn)。合理的做法是把檢索上下文分成多檔lite模式下只放摘要和結(jié)論normal模式放相關(guān)章節(jié)加摘要deep模式才放全文段落并配合引用標注。這就是 context-mode 的思想應(yīng)用到大模型場景的典型例子。對話歷史的管理就更依賴模式了。固定上下文窗口下總是全量攜帶對話歷史會讓窗口很快耗盡完全不攜帶歷史又會丟失任務(wù)脈絡(luò)。實用方案是維護一個滑動窗口最近的 N 輪對話按原文保留較早的對話定期壓縮成摘要系統(tǒng)指令和角色設(shè)定永遠固定在窗口頂部。窗口大小、壓縮頻率、歷史保留輪數(shù)這些參數(shù)組合起來就是一組上下文策略也就是大模型應(yīng)用中的 context-mode。3. 手把手實現(xiàn)一套可直接復用的 context-mode 方案3.1 用環(huán)境變量搭建模式切換基礎(chǔ)框架想快速落地 context-mode最直接的辦法就是用環(huán)境變量作為狀態(tài)載體。環(huán)境變量天然具備進程級傳遞能力子進程能繼承外部可以讀取命名清晰而且在多個腳本之間共享狀態(tài)非常方便。我先給項目建立一套上下文目錄存放不同模式的環(huán)境配置。my-project/ ├── .context/ │ ├── dev.env │ ├── prod.env │ └── debug.env ├── ctx.sh └── app.sh每個環(huán)境文件里只放模式相關(guān)的差異變量。# .context/dev.env PROJECT_LOG_LEVELdebug PROJECT_LOG_OUTPUTconsole PROJECT_API_BASEhttp://localhost:8080 PROJECT_ENABLE_WRITE0 # .context/prod.env PROJECT_LOG_LEVELwarn PROJECT_LOG_OUTPUTfile PROJECT_API_BASEhttps://api.example.com PROJECT_ENABLE_WRITE1然后寫一個ctx.sh作為統(tǒng)一切換入口。#!/usr/bin/env bash # ctx.sh - context-mode 切換工具 CONTEXT_MODE${CONTEXT_MODE:-dev} ctx_load() { local mode$1 local ctx_file.context/${mode}.env if [[ ! -f $ctx_file ]]; then echo [ctx] context file not found: $ctx_file 2 return 1 fi set -a source $ctx_file set a export CONTEXT_MODE$mode echo [ctx] switched to context-mode: $mode } ctx_switch() { ctx_load $1 } ctx_current() { echo current context-mode: ${CONTEXT_MODE} } ctx() { if [[ $# -eq 0 ]]; then ctx_current else ctx_switch $1 fi }把這個文件在 shell 配置里 source 進來就能直接用了source ./ctx.sh ctx dev ctx prod命令執(zhí)行后查看一下echo $CONTEXT_MODE # 輸出 prod這套框架看起來簡單但實際使用中有一個值得注意的細節(jié)模式切換時source命令會把新變量加載進當前 shell但舊變量如果在新配置文件里不存在并不會被自動刪除。比如從dev切到debug如果debug.env里沒有定義PROJECT_ENABLE_WRITE這個變量仍然帶著dev模式的舊值存活。所以我建議每個上下文文件都采取“完整覆蓋”策略凡是該模式需要控制的變量一律在文件里顯式寫出來而不是只寫差異項。這樣切換時不會出現(xiàn)變量幽靈行為可預期。3.2 在應(yīng)用代碼里按模式分流行為環(huán)境變量搭好之后真正的應(yīng)用邏輯就要學會“看模式辦事”。以 Python 腳本為例可以讓日志輸出和數(shù)據(jù)處理流程跟著模式走。import logging import os CONTEXT_MODE os.getenv(CONTEXT_MODE, dev) LOG_LEVEL os.getenv(PROJECT_LOG_LEVEL, INFO) LOG_OUTPUT os.getenv(PROJECT_LOG_OUTPUT, console) handlers [] if LOG_OUTPUT console: handlers.append(logging.StreamHandler()) elif LOG_OUTPUT file: handlers.append(logging.FileHandler(app.log)) logging.basicConfig( levelgetattr(logging, LOG_LEVEL.upper(), logging.INFO), handlershandlers, format%(asctime)s %(levelname)s [%(name)s] %(message)s, ) logger logging.getLogger(app) def run(): logger.debug(當前 context-mode 已注入日志系統(tǒng): %s, CONTEXT_MODE) if CONTEXT_MODE prod: logger.info(生產(chǎn)模式開啟寫操作) # 執(zhí)行真實業(yè)務(wù)寫入 elif CONTEXT_MODE dev: logger.warning(開發(fā)模式寫操作已禁用) # 只模擬寫入不觸達真實數(shù)據(jù)這里的關(guān)鍵設(shè)計是業(yè)務(wù)代碼不需要感知每一處開關(guān)的分支只需要在最外側(cè)讀取環(huán)境變量把行為差異集中到“入口分支”里。日志控制、數(shù)據(jù)源選擇、寫入開關(guān)、告警閾值都可以歸到這一層。久而久之項目里會形成兩種代碼業(yè)務(wù)邏輯和上下文適配邏輯。后者獨立沉淀前者保持單純兩者耦合度越低越好。如果項目同時涉及多個子模塊建議集中定義一個上下文類在啟動階段一次性加載所有模式配置然后通過依賴注入傳給各模塊而不是讓每個模塊各自讀環(huán)境變量。環(huán)境變量在方案原型階段很好用但模塊多了以后散落讀取會讓“當前模式的實際配置是什么”這個問題變得很難回答。集中封裝既方便統(tǒng)一默認值也方便加日志和斷言。3.3 給 AI 對話注入模式化提示詞和檢索策略大模型應(yīng)用中的 context-mode實現(xiàn)方式略有不同核心載體從環(huán)境變量變成了 prompt 模板和檢索參數(shù)。我先區(qū)分三種基礎(chǔ)模式分析模式、生成模式、審閱模式。分析模式要求模型把問題拆解清楚、列出邊界條件、標明未知項生成模式要求模型直接輸出可執(zhí)行方案或代碼審閱模式要求模型帶著批判眼光去找漏洞、風險和遺漏。在系統(tǒng)提示詞里可以直接把模式聲明出來。# system prompt 中的 context-mode 聲明 當前運行模式{{CONTEXT_MODE}} - 當 CONTEXT_MODEanalyze 時 先給出問題的核心定義再拆解影響因子最后列出我需要的額外信息。 不要急著給方案除非我明確要求。 - 當 CONTEXT_MODEgenerate 時 直接給出可落地的實現(xiàn)方案并附上關(guān)鍵參數(shù)說明。 不要過度解釋背景除非與實現(xiàn)直接相關(guān)。 - 當 CONTEXT_MODEreview 時 逐條檢查輸入材料的風險點、不一致處和潛在缺陷。 每一條需要給出問題描述、影響評估和修改建議。這個聲明放在系統(tǒng)提示詞的固定位置歷史對話再怎么輪轉(zhuǎn)也不受影響。用戶只需要在會話開頭說“切換到 generate 模式”或者“下面用 analyze 模式看”模型就能整體調(diào)整輸出傾向而不需要用戶每次重新描述一遍需求背景。這里的模式名稱別起得過于抽象。我自己吃過一次虧用了“alpha”“beta”這種代號過了兩周自己都忘了 alpha 模式到底強調(diào)什么。后來統(tǒng)一改成動作性命名比如explain、implement、critique含義一目了然。檢索增強場景里的 context-mode控制的是“檢索寬度”和“上下文拼裝策略”。我常用的策略是lite只檢索 top 3 片段每段不超過 300 字適合快速問答。normal檢索 top 8 片段每段不超過 600 字并根據(jù)相關(guān)度重排把最相關(guān)的放前兩條。deep檢索 top 15 片段保留完整章節(jié)同時附加文檔標題、章節(jié)路徑和頁碼適合需要嚴謹考證的場景。參數(shù)選擇要結(jié)合模型上下文窗口算賬。假設(shè)窗口總量是 8k token系統(tǒng)提示占了 1k用戶問題占了 500剩下來的 6.5k 要分給檢索結(jié)果和歷史對話。如果用normal模式top 8 片段每段 600 字臨時按一個漢字約等于一個 token 的保守估算光檢索片段就吃掉 4.8k token剩下給對話歷史的只有不到 2k只能維持五六輪對話。這時候要么降級為lite檢索要么壓縮歷史保留輪數(shù)。所以模式設(shè)計不是固定的必須結(jié)合窗口預算做取舍。3.4 加入自動探測讓模式隨場景自己切換手動切換模式永遠是最穩(wěn)妥的但有些場景下手動切換本身就是負擔。比如每次進入某個項目目錄都要手動設(shè)置模式時間長了必然有人忘記。折中方案是把自動探測做成“建議機制”而不是“強制機制”。以 Bash 為例可以在chpwd目錄切換事件里判斷當前目錄和 Git 分支自動提示應(yīng)該切換的模式。# .bashrc 里加入自動提示邏輯 __ctx_auto_detect() { local branch branch$(git rev-parse --abbrev-ref HEAD 2/dev/null) || return 0 case $branch in main|master) [[ ${CONTEXT_MODE:-} ! prod ]] echo [ctx] 提示: 當前 main 分支建議切到 prod 模式 ;; dev-*|feature-*) [[ ${CONTEXT_MODE:-} ! dev ]] echo [ctx] 提示: 當前開發(fā)分支建議切到 dev 模式 ;; esac } PROMPT_COMMAND__ctx_auto_detect這樣做的好處是系統(tǒng)不會自作主張改變模式但它會在合適的時機提醒你。我把這種設(shè)計稱為“半自動模式”自動探測上下文并給出建議最終決定權(quán)仍然留給用戶。它可以避免兩種極端情況既不會因為忘記切換導致用生產(chǎn)配置跑測試也不會因為自動切換過于靈敏導致行為反復橫跳。另外在命令行提示符里顯示當前模式是一個投入產(chǎn)出比極高的做法。把CONTEXT_MODE放進 PS1時刻提醒自己當前處在哪個上下文里。這一步看似微小卻能讓上下文狀態(tài)變得“可見”從而避免大量陰差陽錯的誤操作。4. 常見問題與排查技巧實錄4.1 模式切換了但沒生效先查變量來源和進程繼承我見過最多的問題是在命令行里執(zhí)行了ctx prod輸出也提示切換成功但運行腳本時時讀取到的CONTEXT_MODE還是dev。這個問題的根源往往在于 shell 變量和作用域的傳遞方式。環(huán)境變量有一個特性子進程會繼承父進程的環(huán)境但父進程后來才設(shè)置的環(huán)境變量子進程無法感知。如果你的腳本是通過調(diào)度任務(wù)、另一個終端窗口、或者nohup方式啟動的它可能根本沒有讀到當前 shell 里的CONTEXT_MODE。排查時先做三件事第一在新開的終端里執(zhí)行echo $CONTEXT_MODE確認當前 shell 的值第二在目標腳本開頭加一行env | grep CONTEXT確認它實際看到的變量值第三檢查是不是有多個配置加載入口比如腳本自己讀取了.env文件覆蓋了環(huán)境變量里的值。我還踩過一個很隱蔽的坑.bashrc里先后 source 了兩個工具腳本兩個腳本都定義了CONTEXT_MODE的默認值后加載的默認值覆蓋了前面設(shè)置的值。后來我把模式默認值集中到一個文件里只允許從命令行手動覆蓋問題才徹底解決。多工具協(xié)作時變量加載順序一定要檢查否則模式會在不知不覺中被“重置”。4.2 上下文過大導致的性能問題與截斷策略大模型應(yīng)用和日志系統(tǒng)里普遍存在一個現(xiàn)象上下文越長響應(yīng)越慢輸出質(zhì)量反而可能下降。原因在于過量的無關(guān)上下文會分散模型的注意力同時窗口被打滿之后新信息無法進入只能靠丟棄舊信息來騰空間丟棄策略不好就會掉關(guān)鍵線索。上下文窗口的預算要提前算。一個典型的對話服務(wù)假設(shè)窗口 8k token我一般按比例分四塊系統(tǒng)提示占 15%檢索結(jié)果占 35%歷史對話摘要占 30%當前問題留 20%。實際操作時優(yōu)先保障系統(tǒng)提示和當前問題檢索結(jié)果和第二塊的歷史采用動態(tài)調(diào)節(jié)。截斷策略我推薦“分段壓縮保留錨點”。第一步把最早的歷史消息壓縮成一段 200 字以內(nèi)的摘要只保留結(jié)論和未完成事項第二步保留最近 5 輪完整對話原文因為新問題往往依賴剛才說過的細節(jié)第三步把已經(jīng)解決問題的細節(jié)從原文中丟棄只保留問題描述和結(jié)論。這種策略比簡單的一刀切“只保留最近 N 條”要可靠得多尤其適合長時間運行的多輪任務(wù)。4.3 提高模式切換的可觀測性別讓狀態(tài)隱身context-mode 天然是一個“看不見的狀態(tài)”一旦忘記檢查當前模式后面所有判斷都會被帶偏。我把可觀測性做了三層處理外殼層、日志層、斷言層。外殼層最簡單把當前模式顯示在命令行提示符里。日志層是在程序啟動時強制記錄一條包含模式信息的啟動日志比如context modeprod, log_levelwarn, api_basehttps://...。實踐里這條日志價值極大每次翻日志都能快速確認當時程序是以什么上下文運行的。斷言層是在關(guān)鍵資源操作的入口加保護性檢查例如def assert_write_allowed(): if CONTEXT_MODE ! prod: raise RuntimeError(fwrite operation blocked, current context-mode: {CONTEXT_MODE})這三層疊加起來模式狀態(tài)從“看不見”變成“處處可見”。狀態(tài)可見以后排查問題的速度會有很明顯的提升因為你知道剛才發(fā)生的行為對應(yīng)的是哪套上下文規(guī)則而不是對著代碼猜。問題現(xiàn)象常見原因排查動作模式提示切換成功但行為沒變子進程未繼承環(huán)境變量腳本里另有加載入口覆蓋在目標進程內(nèi)執(zhí)行 env從 dev 切到 debug 后混入舊變量source不會清除舊文件中不存在的新變量每個模式文件顯式完整覆蓋全部相關(guān)變量上下文過長導致響應(yīng)變慢或跑偏窗口被打滿檢索片段過多或歷史未壓縮按預算分配窗口歷史分段壓縮并保留錨點信息自動探測頻繁切換行為不穩(wěn)定動態(tài)模式?jīng)Q策權(quán)過大缺少人工確認自動探測只給建議提示最終切換由人工確認配置文件加載順序沖突多個腳本同時定義默認變量后者覆蓋前者統(tǒng)一收斂為單一加載入口集中管理默認值5. 最后分享幾條實戰(zhàn)心得這套 context-mode 的思路我用了快一年最大的變化不是代碼質(zhì)量提升了多少而是排查問題時的心態(tài)變了。以前遇到詭異行為心里第一反應(yīng)是“這地方是不是有 bug”現(xiàn)在第一反應(yīng)是“當前上下文是什么模式、加載了哪些變量、歷史會話被壓縮到了什么程度”。目標從找 bug 變成了確認上下文很多問題的答案往往在第一步就浮現(xiàn)了。如果你也想在自己的項目里引入 context-mode我的建議很簡單先別追求自動化和智能化從最樸素的環(huán)境變量切換開始。把模式名稱壓縮到三五個以內(nèi)把每個模式的差異變量寫全把當前模式顯示在提示符里。這套最小方案跑順之后再考慮動態(tài)探測、自動壓縮歷史、知識庫檢索寬度調(diào)節(jié)這些進階功能。上下文管理不是一次性的架構(gòu)設(shè)計更像是一種習慣每加一個新功能都習慣性問一句它需要感知哪些上下文又要忽略哪些上下文。搞清楚了這一點context-mode 自然就能幫你規(guī)避很多人容易踩的坑了。