最近社區(qū)里冒出個(gè)熱詞context-mode。我第一次注意到它是在整理幾個(gè)開(kāi)源項(xiàng)目的 issue 時(shí)發(fā)現(xiàn)不少人用這個(gè)詞描述自己的工具鏈改造——有人說(shuō)把所有切換動(dòng)作交給 context-mode 之后效率提升很明顯也有人說(shuō)這不過(guò)是老概念換了層皮。我?guī)е@點(diǎn)好奇在自己的開(kāi)發(fā)環(huán)境里反復(fù)試了兩周在 Shell 工作流、AI 對(duì)話工具、編輯器配置三塊分別做了實(shí)踐最后確定它確實(shí)是個(gè)有用的工作方式但能不能發(fā)揮價(jià)值取決于你怎么定義“上下文”以及你愿意為“自動(dòng)切換”付出多少可維護(hù)性成本。這篇文章不是概念科普是我實(shí)際調(diào)校 context-mode 行為的記錄包含可以直接抄走的配置也包含我踩過(guò)的坑。如果你也想讓工具在合適的時(shí)機(jī)讀取合適的背景信息、自動(dòng)進(jìn)入合適的模式這篇應(yīng)該能給你一個(gè)比較實(shí)在的參考。1. context-mode 是什么熱詞外殼下的兩種真實(shí)能力1.1 上下文感知工具開(kāi)始“讀懂”你在做什么context-mode 這個(gè)詞經(jīng)常被掛在嘴邊但真正拆開(kāi)看它至少包含兩層能力第一層是上下文感知第二層是模式切換。上下文感知說(shuō)的是工具不再只看你按下的按鈕而是會(huì)結(jié)合你當(dāng)前所處的情境做出判斷。這個(gè)情境可以很小例如你當(dāng)前處于哪個(gè)目錄、最近執(zhí)行過(guò)哪條命令、光標(biāo)停在哪一行也可以很大例如你打開(kāi)的是哪一類項(xiàng)目、當(dāng)前是不是在 deadline 前夜、對(duì)話歷史上文已經(jīng)聊了什么。智能手機(jī)上的經(jīng)典案例你們一定見(jiàn)過(guò)手機(jī)連接到家中的 Wi-Fi 后自動(dòng)把鈴聲調(diào)低、把智能家居設(shè)備設(shè)為“在家”狀態(tài)離開(kāi)家后恢復(fù)成響鈴模式。這個(gè)過(guò)程沒(méi)有你手動(dòng)參與系統(tǒng)通過(guò)“Wi-Fi 名稱”這個(gè)上下文信號(hào)判斷出“他回家了”于是完成切換。開(kāi)發(fā)者工具里的 context-mode本質(zhì)上也是這個(gè)邏輯用盡量少的信號(hào)判斷出你正在做什么然后調(diào)整出一套最合適的行為。我在實(shí)踐中最常見(jiàn)的上下文信號(hào)是“項(xiàng)目根目錄”。只要我進(jìn)入某個(gè)項(xiàng)目的目錄工具就知道這是一個(gè) Node.js 項(xiàng)目還是 Python 項(xiàng)目是業(yè)務(wù)代碼還是基礎(chǔ)設(shè)施代碼從而決定要加載哪些命令、采用哪種代碼風(fēng)格。1.2 模式切換不新鮮的東西一旦加入“自動(dòng)”就不一樣了模式切換本身不稀奇。Vim 的普通模式與插入模式、手機(jī)的飛行模式與勿擾模式本質(zhì)都是“一組預(yù)設(shè)狀態(tài)的集合隨時(shí)可以切換”。但傳統(tǒng)模式切換幾乎都靠手動(dòng)你按一個(gè)鍵或者點(diǎn)一下開(kāi)關(guān)然后才生效。context-mode 的關(guān)鍵差異在于切換的觸發(fā)條件不是用戶操作而是上下文變化。工具先感知環(huán)境再自動(dòng)選擇預(yù)置模式。這一步看似簡(jiǎn)單實(shí)際上解決了真實(shí)痛點(diǎn)——手動(dòng)切換最大的問(wèn)題不是麻煩而是你常常忘記切。最常見(jiàn)的代價(jià)就是你帶著項(xiàng)目 A 的環(huán)境變量去跑項(xiàng)目 B 的命令報(bào)錯(cuò)半天才發(fā)現(xiàn)NODE_ENV、DATABASE_URL這些全局變量早就不是當(dāng)前項(xiàng)目想要的值了。如果有一套機(jī)制能在你進(jìn)入項(xiàng)目目錄的那一刻自動(dòng)完成切換離開(kāi)時(shí)再自動(dòng)還原這類“串環(huán)境”事故會(huì)減少一大半。至于為什么這個(gè)詞最近變得流行排在前面的原因我猜有兩個(gè)一是大模型相關(guān)工具把“上下文”變成了顯式的資源概念上下文窗口多長(zhǎng)、怎么塞信息成了日常話題context-mode 這個(gè)提法也隨著火起來(lái)二是現(xiàn)在大家電腦上同時(shí)維護(hù)的項(xiàng)目越來(lái)越多手動(dòng)切換配置開(kāi)始跟不上節(jié)奏誰(shuí)先做到自動(dòng)感知誰(shuí)就少受一份罪。2. 第一類實(shí)戰(zhàn)Shell 工作流里的上下文自動(dòng)切換2.1 問(wèn)題一臺(tái)電腦上無(wú)數(shù)個(gè)“項(xiàng)目環(huán)境”糾纏在一起先描述一個(gè)大多數(shù)人都經(jīng)歷過(guò)的場(chǎng)面。你的電腦上同時(shí)存在公司的業(yè)務(wù)項(xiàng)目要求 Node 16、包管理器必須是 pnpm、測(cè)試環(huán)境連的是內(nèi)網(wǎng)數(shù)據(jù)庫(kù)個(gè)人開(kāi)源項(xiàng)目Node 20用的是 npm格式化規(guī)則是雙引號(hào)不帶分號(hào)偶爾還要臨時(shí)寫點(diǎn)腳本跑一遍 Python 虛擬環(huán)境。如果所有環(huán)境變量都寫死在 shell 配置里結(jié)果就是項(xiàng)目之間互相污染。最常見(jiàn)的是DEBUG開(kāi)關(guān)你在 A 項(xiàng)目里打開(kāi)調(diào)試日志忘了關(guān)切到 B 項(xiàng)目后控制臺(tái)刷出大量無(wú)關(guān)輸出排查半天還以為是 B 項(xiàng)目本身的日志系統(tǒng)壞了。這類問(wèn)題定位起來(lái)很浪費(fèi)時(shí)間因?yàn)楣ぞ邎?bào)錯(cuò)信息不會(huì)提示你“有一個(gè)全局環(huán)境變量正在干擾我”。我當(dāng)時(shí)的念頭很簡(jiǎn)單能不能讓終端環(huán)境“跟著目錄走”進(jìn)到什么項(xiàng)目就用什么環(huán)境離開(kāi)了自動(dòng)還原。這就是我理解的第一層 context-mode。2.2 我的做法direnv 與 .envrc 組合在常見(jiàn)工具鏈里實(shí)現(xiàn)“跟著目錄走”最直接的是 direnv。它做的事情很純粹當(dāng)你在 Shell 里進(jìn)入一個(gè)目錄時(shí)自動(dòng)檢查該目錄下有沒(méi)有.envrc文件有的話加載里面的環(huán)境變量離開(kāi)目錄時(shí)再自動(dòng)卸載。先裝工具以 macOS 和 Linux 為例# Debian/Ubuntu sudo apt install direnv # macOS brew install direnv然后在 shell 配置里掛上鉤子。Bash 用戶# ~/.bashrc eval $(direnv hook bash)Zsh 用戶# ~/.zshrc eval $(direnv hook zsh)重啟終端之后在項(xiàng)目目錄里創(chuàng)建.envrc文件例如# my-app/.envrc export PROJECT_ROOT$(pwd) export NODE_ENVdevelopment export DATABASE_URLpostgres://localhost:5432/myapp_dev PATH_add $PWD/node_modules/.bin第一次進(jìn)入目錄direnv 會(huì)提示你運(yùn)行direnv allow來(lái)信任這個(gè)文件。這一步是安全設(shè)計(jì)防止你 clone 一個(gè)陌生倉(cāng)庫(kù)后里面的.envrc直接在你機(jī)器上執(zhí)行任意命令。這套方案的實(shí)際體驗(yàn)是進(jìn)入my-app目錄NODE_ENV自動(dòng)變成developmentnode_modules/.bin自動(dòng)進(jìn)入 PATH直接可以用eslint、prettier這些本地命令不用 npx退出到其他目錄這些變量又自動(dòng)清掉不會(huì)影響下一個(gè)項(xiàng)目。這種“進(jìn)則加載、出則卸載”的機(jī)制幾乎就是 context-mode 的教科書實(shí)現(xiàn)。2.3 進(jìn)階自寫 Shell 鉤子讓同一套配置服務(wù)不同目錄direnv 適合管理環(huán)境變量但它不會(huì)替你決定“我該用哪套提示符主題”或“要不要加載某個(gè)函數(shù)”。如果你想做更輕量的上下文切換自己寫 Hook 也完全可行。Zsh 里有一個(gè)chpwd鉤子目錄變化時(shí)會(huì)觸發(fā)。我用來(lái)切換終端提示符主題# ~/.zshrc function chpwd_context_mode() { if [[ -f .nvmrc ]]; then export SHELL_CONTEXTnode-project elif [[ -f pyproject.toml ]]; then export SHELL_CONTEXTpython-project else export SHELL_CONTEXTdefault fi } autoload -Uz add-zsh-hook add-zsh-hook chpwd chpwd_context_mode chpwd_context_mode這個(gè)鉤子做的事情很樸素根據(jù)當(dāng)前目錄下的標(biāo)志文件設(shè)置一個(gè)上下文變量。你的提示符配置可以讀取$SHELL_CONTEXT不同項(xiàng)目顯示不同顏色或前綴。這樣做的好處是信號(hào)明確、邏輯直白半年后回來(lái)看還能一眼讀懂。不過(guò)有個(gè)細(xì)節(jié)我踩過(guò)坑在嵌套目錄里選擇哪個(gè)標(biāo)志文件。假設(shè)你在frontend/packages/ui下工作當(dāng)前目錄沒(méi)有.nvmrc但它的上級(jí)目錄有。如果你只檢查當(dāng)前目錄上下文就會(huì)誤判為 default。我后來(lái)的做法是寫一個(gè)向上查找的邏輯從當(dāng)前目錄逐級(jí)往上找找到最近的標(biāo)志文件再判斷。這個(gè)“最近項(xiàng)目根目錄”的概念在下一部分還會(huì)用到。3. 第二類實(shí)戰(zhàn)AI 使用場(chǎng)景中的 context-mode 組織法3.1 模型沒(méi)“忘”信息是上下文沒(méi)組織好AI 工具流行之后“上下文”這個(gè)概念徹底浮出水面。不少人的使用體驗(yàn)是同一個(gè)模型有時(shí)候理解力驚人有時(shí)候又笨得離譜同一份背景講了三遍還是記不住。我自己的觀察是多數(shù)時(shí)候不是模型記憶力差而是你塞給它的上下文信息組織得太亂。對(duì)話窗口里有很多內(nèi)容已經(jīng)過(guò)期了兩輪前的一個(gè)猜測(cè)現(xiàn)在已經(jīng)被推翻但你后來(lái)發(fā)的新問(wèn)題里又帶上了那個(gè)錯(cuò)誤前提某個(gè)背景在第一輪寫過(guò)但中間被幾十條無(wú)關(guān)消息沖淡了模型已經(jīng)分不清哪些背景仍然有效。這恰好可以用 context-mode 的思路來(lái)治理在真實(shí)任務(wù)開(kāi)始前先顯式地構(gòu)造好一個(gè)“上下文包”確定當(dāng)前模式下應(yīng)該攜帶哪些信息然后只在這個(gè)模式內(nèi)進(jìn)行操作。3.2 用 context pack 替代臨時(shí)拼湊的提示詞我現(xiàn)在的習(xí)慣是給 AI 工具建一個(gè)固定目錄專門存放常用任務(wù)的上下文包~/.contexts/ ├── code-review.md ├── refactor.md ├── explain-simple.md └── write-doc.md每個(gè)文件包含一個(gè)模式所需要的全部背景。以代碼審查為例~/.contexts/code-review.md的內(nèi)容長(zhǎng)這樣- 定位后端服務(wù)負(fù)責(zé)人 - 目標(biāo)審查一段代碼變更 - 項(xiàng)目背景訂單服務(wù)gRPC 接口MySQL 存儲(chǔ) - 重點(diǎn)關(guān)注并發(fā)寫入、錯(cuò)誤包裝、超時(shí)控制、日志脫敏 - 輸出要求按嚴(yán)重程度排序列出文件與行號(hào)給出最小修復(fù)建議使用方式很簡(jiǎn)單在 AI 對(duì)話里先讓它讀取這個(gè)文件再粘貼待審查的 diff。這樣每次的對(duì)話起點(diǎn)都一致模型不需要從零推測(cè)項(xiàng)目背景也省去了你反復(fù)復(fù)述的時(shí)間。實(shí)際跑下來(lái)我發(fā)現(xiàn)這套做法最大的收益不是模型變聰明了而是對(duì)話成本變低了同樣的背景不用重復(fù)占據(jù)上下文窗口模型可以把注意力放在真正的變更內(nèi)容上。你只要維護(hù)好這幾個(gè) md 文件相當(dāng)于同時(shí)維護(hù)了所有 AI 對(duì)話的“預(yù)置模式”。3.3 上下文窗口的按需加載什么該放什么不該放上下文窗口是有限資源。我見(jiàn)過(guò)不少人的失敗案例不是因?yàn)樯舷挛奶俣且驗(yàn)槿颂酂o(wú)關(guān)內(nèi)容把重點(diǎn)稀釋了。在實(shí)踐 context-mode 時(shí)我對(duì)每個(gè)上下文包都做了一次“內(nèi)容審計(jì)”總結(jié)出這樣一張清單該放進(jìn)去的不該放進(jìn)去的當(dāng)前任務(wù)的目標(biāo)與產(chǎn)出格式已經(jīng)解決的舊問(wèn)題討論必要的項(xiàng)目背景與技術(shù)棧大段無(wú)關(guān)的產(chǎn)品功能介紹與本次變更直接相關(guān)的代碼只是因?yàn)椤芭侣倍迟N的代碼明確的正反例重復(fù)粘貼多次的歷史上下文期望的約束與禁忌長(zhǎng)對(duì)話里早就過(guò)期的假設(shè)原則就是每條信息都要回答“如果模型不知道這個(gè)會(huì)不會(huì)影響本次輸出質(zhì)量”答不上來(lái)的就不放。這個(gè)“按需加載”思維正好對(duì)應(yīng) context-mode 的精髓不是把所有上下文都塞給工具而是先判斷當(dāng)前處于什么模式再只加載該模式下必要的那部分上下文。事實(shí)上現(xiàn)在不少 AI 產(chǎn)品開(kāi)始支持引用文件、預(yù)設(shè)模板、按需掛載知識(shí)庫(kù)本質(zhì)上就是把這套做法產(chǎn)品化了。4. 第三類實(shí)戰(zhàn)編輯器與代碼工具如何感知項(xiàng)目上下文4.1 LSP 與格式化器同一份代碼不同上下文要不同處理如果說(shuō) Shell 的 context-mode 管的是“環(huán)境變量”AI 場(chǎng)景管的是“提示詞信息”那么編輯器里的 context-mode 管的就是“代碼處理規(guī)則”。最典型的例子是代碼格式化。你在參與兩個(gè)倉(cāng)庫(kù)一個(gè)倉(cāng)庫(kù)約定用雙引號(hào)、無(wú)分號(hào)、縮進(jìn) 2 空格另一個(gè)倉(cāng)庫(kù)約定用單引號(hào)、帶分號(hào)、縮進(jìn) 4 空格。編輯器如果只會(huì)用一套全局配置那一定有一個(gè)倉(cāng)庫(kù)的代碼會(huì)被改得亂七八糟。更麻煩的是 LSP語(yǔ)言服務(wù)器協(xié)議這類工具它要根據(jù)當(dāng)前文件的上下文判斷出該用哪個(gè)編譯參數(shù)、哪些符號(hào)可用、哪里該報(bào)錯(cuò)。LSP 其實(shí)就是一種非常成熟的 context-mode 實(shí)現(xiàn)——它沒(méi)有全局規(guī)則而是持續(xù)讀取當(dāng)前項(xiàng)目的配置并據(jù)此調(diào)整行為。4.2 編輯器配置示例按項(xiàng)目根目錄切換行為我把 context-mode 的思路落到了 Neovim 配置里。想法是進(jìn)入一個(gè)文件時(shí)向上查找最近的標(biāo)志文件確認(rèn)項(xiàng)目根目錄再?zèng)Q定使用哪個(gè)格式化工具。一個(gè)簡(jiǎn)化版的配置長(zhǎng)這樣-- Neovim: 根據(jù)項(xiàng)目根目錄配置格式化命令 vim.api.nvim_create_autocmd({ BufEnter }, { pattern { *.js, *.ts, *.jsx, *.tsx }, callback function() local root vim.fs.root(vim.fn.getcwd(), { .prettierrc, .prettierrc.json, .prettierrc.js }) if root then vim.bo.formatprg prettier --config .. root .. /.prettierrc --stdin-filepath % end end, })這個(gè)片段做的事情很具體每次進(jìn)入 JS/TS 文件向上查找最近的.prettierrc文件找到就設(shè)置本緩沖區(qū)使用的格式化命令。這樣即使在多層嵌套的目錄結(jié)構(gòu)里每個(gè)文件也能對(duì)應(yīng)自己所屬項(xiàng)目的格式規(guī)則。如果你用 VS Code也有等價(jià)的思路不把格式規(guī)則寫在全局 settings 里而是寫進(jìn)項(xiàng)目的.vscode/settings.json或使用.code-workspace多根工作區(qū)文件。VS Code 本身對(duì)工作區(qū)級(jí)配置優(yōu)先級(jí)很高這正是它內(nèi)置的 context-mode 機(jī)制。4.3 容易翻車的三個(gè)細(xì)節(jié)實(shí)踐下來(lái)編輯器類的 context-mode 有三個(gè)坑值得單獨(dú)說(shuō)。第一個(gè)坑是 LSP 緩存。你切換項(xiàng)目后LSP 有時(shí)仍保留著上一個(gè)項(xiàng)目的緩存配置導(dǎo)致新項(xiàng)目里的診斷結(jié)果不對(duì)。我的處理方法是切換項(xiàng)目后主動(dòng)重啟 LSP而不是等它自己發(fā)現(xiàn)。第二個(gè)坑是嵌套項(xiàng)目識(shí)別。monorepo 結(jié)構(gòu)下一個(gè)倉(cāng)庫(kù)里可能有多個(gè)子包每個(gè)子包有自己的 config 文件。如果你只認(rèn)倉(cāng)庫(kù)根目錄就會(huì)導(dǎo)致整倉(cāng)都用同一套規(guī)則子包差異完全丟失。正確做法是找“最近的配置”而不是“最頂層的配置”。第三個(gè)坑是最隱蔽的格式化工具互相打架。有時(shí)候你配置了formatprg但 LSP 的formatting也訂閱了同一個(gè)保存事件。兩個(gè)工具都認(rèn)為自己有權(quán)格式化結(jié)果保存一次文件代碼被來(lái)回改兩遍。這個(gè)問(wèn)題的解決方法不是靠 context-mode而是明確指定優(yōu)先級(jí)要么全局禁用 LSP 的格式化只用外部工具要么反過(guò)來(lái)。5. context-mode 的邊界什么場(chǎng)景值得用什么場(chǎng)景是過(guò)度設(shè)計(jì)5.1 三條判斷標(biāo)準(zhǔn)說(shuō)了這么多實(shí)踐我也想潑點(diǎn)冷水。不是所有場(chǎng)景都適合上 context-mode。我的判斷標(biāo)準(zhǔn)有三條缺一不可第一上下文信號(hào)必須明確且容易檢測(cè)。比如“當(dāng)前目錄是不是 git 倉(cāng)庫(kù)”“是否存在.nvmrc文件”“文件名是否為測(cè)試文件”這些都是可靠的信號(hào)。反過(guò)來(lái)“用戶此刻的情緒”“今天是不是高效日”這類模糊信號(hào)就不適合作為切換依據(jù)。第二不同模式之間的行為差異必須足夠大。如果切換前后只是改了一個(gè)不太重要的變量那自動(dòng)切換帶來(lái)的收益可能還抵不上維護(hù)成本。我自己的經(jīng)驗(yàn)閾值是至少有三處行為同時(shí)變化才值得引入一套 context-mode。第三必須有逃生通道。任何自動(dòng)化都可能誤判一旦誤判你要能立刻手動(dòng)覆蓋。我所有的自動(dòng)切換邏輯都會(huì)保留一個(gè)手動(dòng)開(kāi)關(guān)保證出問(wèn)題時(shí)可以快速恢復(fù)到默認(rèn)模式。5.2 上下文污染我看到的最常見(jiàn)事故context-mode 用不好最典型的事故是上下文污染。我在實(shí)際項(xiàng)目里見(jiàn)過(guò)兩種比較有代表性的情況。一種發(fā)生在環(huán)境層面有人把項(xiàng)目 A 的數(shù)據(jù)庫(kù)地址寫進(jìn)了全局環(huán)境變量后來(lái)所有項(xiàng)目啟動(dòng)都連到項(xiàng)目 A 的庫(kù)。這種問(wèn)題特別難看查因?yàn)閳?bào)錯(cuò)信息五花八門表面上跟環(huán)境變量毫無(wú)關(guān)系。我后來(lái)排查時(shí)習(xí)慣先跑一條echo $DATABASE_URL十次里能中八次。另一種發(fā)生在 AI 工具里本來(lái)在做代碼審查結(jié)果同一個(gè)會(huì)話窗口里繼續(xù)問(wèn)了幾個(gè)生活問(wèn)題再回到代碼審查時(shí)模型已經(jīng)被之前的話題帶偏了。這其實(shí)不是模型的錯(cuò)是這個(gè)會(huì)話已經(jīng)混入多套上下文卻仍然以“同一個(gè)模式”在運(yùn)行。按 context-mode 的思路這種場(chǎng)景就應(yīng)該拆成不同會(huì)話、不同上下文包而不是硬塞在一個(gè)窗口里。5.3 我的取舍原則與保留開(kāi)關(guān)經(jīng)過(guò)這段時(shí)間的調(diào)整我對(duì) context-mode 的取舍原則基本固化成三條。第一條默認(rèn)不感知信號(hào)明確才感知。我不是每個(gè)項(xiàng)目都配.envrc只有那些環(huán)境差異確實(shí)影響運(yùn)行結(jié)果的項(xiàng)目才配。閾值設(shè)為“切錯(cuò)一次要花兩三分鐘排查”才值得自動(dòng)化。第二條所有自動(dòng)化都留手動(dòng)入口。比如 direnv 里我習(xí)慣在.envrc頂部留一個(gè)export CONTEXT_MODE${CONTEXT_MODE:-auto}環(huán)境變量本身可以被外部覆蓋。這樣萬(wàn)一某次自動(dòng)判斷不合適我仍然可以直接在命令前臨時(shí)指定。第三條自動(dòng)化程度以“半年后還能看懂”為準(zhǔn)。我見(jiàn)過(guò)有人把切換邏輯寫得極其精巧但半年后連自己都忘了有哪些上下文信號(hào)在生效工具黑箱化之后出問(wèn)題反而是災(zāi)難。寧可寫得樸素一點(diǎn)、慢一點(diǎn)也不能讓它變成玄學(xué)。說(shuō)到底context-mode 不是一套別人寫好的工具而是一種設(shè)計(jì)習(xí)慣。它要求你認(rèn)真想一想當(dāng)前這個(gè)工具應(yīng)該在什么時(shí)候、讀取哪些背景信息、切換成什么行為才不會(huì)讓你在錯(cuò)誤的環(huán)境里多浪費(fèi)半小時(shí)。我現(xiàn)在的做法是每引入一個(gè)自動(dòng)化切換就在筆記里記一句“它根據(jù)什么信號(hào)、切換什么行為、我該怎么臨時(shí)覆蓋”記錄比腳本本身還重要。