1. 先搞清楚 context-mode 到底解決什么問(wèn)題老實(shí)說(shuō)我第一次在工具鏈里看到context-mode這個(gè)參數(shù)時(shí)第一反應(yīng)是又一個(gè)裝腔作勢(shì)的配置項(xiàng)。但真把它用起來(lái)之后我反而覺(jué)得這個(gè)名字起得相當(dāng)準(zhǔn)——它不是在堆功能而是在管一件事你的開(kāi)發(fā)環(huán)境、AI 助手、腳本工具到底應(yīng)該基于哪一段上下文來(lái)做判斷。你可以想象這樣一個(gè)日常場(chǎng)景電腦上同時(shí)開(kāi)著公司項(xiàng)目、個(gè)人開(kāi)源項(xiàng)目、還有臨時(shí)寫(xiě)的小腳本三個(gè)終端窗口里各跑著不同任務(wù)的日志Cursor 里還掛著兩個(gè)代碼庫(kù)的索引。這時(shí)候你問(wèn) AI幫我改一下那個(gè)登錄超時(shí)邏輯它大概率會(huì)給你翻錯(cuò)倉(cāng)庫(kù)或者把 A 項(xiàng)目里改過(guò)的變量名塞進(jìn) B 項(xiàng)目里。這真不怪模型笨問(wèn)題出在上下文——你給了它一個(gè)混合模式的輸入它只能給你一個(gè)混合模式的答案。context-mode要解決的就是這個(gè)混亂。它把工具的運(yùn)行方式從一次配置到處生效改成一個(gè)上下文一套行為你切到前端項(xiàng)目它就帶著前端項(xiàng)目的目錄結(jié)構(gòu)、依賴(lài)清單、最近變更記錄去思考你切到數(shù)據(jù)分析腳本它就自動(dòng)切換成只看這幾個(gè)文件、只關(guān)心這類(lèi)報(bào)錯(cuò)的模式。說(shuō)得直白點(diǎn)它就像給每個(gè)任務(wù)建了一個(gè)獨(dú)立的隔間而不是讓所有任務(wù)在同一個(gè)大通鋪里互相串味。這個(gè)內(nèi)容適合誰(shuí)如果你是重度 AI 輔助編程的開(kāi)發(fā)者、經(jīng)常在多個(gè)倉(cāng)庫(kù)之間橫跳的全棧工程師、或者正在做內(nèi)部工具/CLI 的團(tuán)隊(duì)那這篇文章能幫你省下大量答非所問(wèn)和改錯(cuò)文件的時(shí)間。就算你只是偶爾用腳本處理文件理解 context-mode 的思路也能讓你少寫(xiě)很多if else來(lái)判斷當(dāng)前到底在哪干活。2. 上下文模式的核心設(shè)計(jì)三種模式怎么選既然叫 context-mode那最核心的問(wèn)題自然是上下文到底有哪些模式可選、它們之間的邊界在哪。別小看這一步我見(jiàn)過(guò)太多人一上來(lái)就堆代碼結(jié)果把上下文管理做成了永久內(nèi)存什么東西都往里塞最后工具反而因?yàn)樘愣l繁誤判。2.1 strict 模式只看眼前這一畝三分地第一種模式是 strict也就是嚴(yán)格局部模式。工具只讀取當(dāng)前目錄、當(dāng)前打開(kāi)的文件、或者當(dāng)前命令里明確指定的輸入絕不主動(dòng)去翻倉(cāng)庫(kù)歷史、去讀無(wú)關(guān)配置文件。它的優(yōu)點(diǎn)非常直接上下文小、響應(yīng)快、不容易跑偏。比如你在調(diào)一個(gè)fetchData函數(shù)strict 模式下 AI 就只看這個(gè)文件和它的直接依賴(lài)不會(huì)突然拿三個(gè)月前的一次重構(gòu)來(lái)提醒你。缺點(diǎn)是顯而易見(jiàn)的——當(dāng)問(wèn)題跨文件、跨模塊時(shí)strict 模式會(huì)顯得目光短淺給不出整體方案。我用一個(gè)生活化的類(lèi)比strict 模式就像你在廚房里炒菜只看面前這口鍋和手邊的調(diào)料。鍋里的情況你一清二楚但如果要問(wèn)你冰箱里還剩什么菜你就答不上來(lái)了。2.2 repo 模式帶上整個(gè)倉(cāng)庫(kù)的地圖和索引第二種模式是 repo也叫倉(cāng)庫(kù)級(jí)上下文模式。它會(huì)讀取當(dāng)前倉(cāng)庫(kù)的目錄結(jié)構(gòu)、關(guān)鍵索引文件、最近的 git 變更、甚至項(xiàng)目里的 README 和架構(gòu)文檔然后把壓縮后的倉(cāng)庫(kù)地圖作為上下文輸入。這個(gè)模式的典型場(chǎng)景是跨文件重構(gòu)比如你要把某條請(qǐng)求鏈路從 REST 改成 RPCstrict 模式根本無(wú)能為力repo 模式卻能先看清相關(guān)模塊在哪里、依賴(lài)關(guān)系長(zhǎng)什么樣再給出一個(gè)貫通前后的方案。代價(jià)也很實(shí)在token 消耗大、響應(yīng)變慢、偶爾會(huì)被無(wú)關(guān)文件干擾判斷。所以 repo 模式更適合作一次性的大手術(shù)而不是每敲一行代碼都開(kāi)啟。2.3 auto 模式讓工具自己決定看多少第三種是 auto也就是自動(dòng)混合模式。它介于 strict 和 repo 之間工具會(huì)根據(jù)當(dāng)前問(wèn)題自動(dòng)判斷需要多大的上下文范圍簡(jiǎn)單問(wèn)題只取相關(guān)文件復(fù)雜問(wèn)題自動(dòng)擴(kuò)展到倉(cāng)庫(kù)索引。auto 模式聽(tīng)著最完美但它其實(shí)是最難做好的。因?yàn)樗澈笮枰粚右鈭D識(shí)別邏輯判斷用戶(hù)問(wèn)到的是局部問(wèn)題還是全局問(wèn)題這個(gè)邏輯寫(xiě)得不仔細(xì)就會(huì)變成時(shí)靈時(shí)不靈。我在實(shí)踐里的做法是把 auto 當(dāng)作默認(rèn)入口但在命令里顯式提供--strict和--repo覆蓋開(kāi)關(guān)。這樣既能享受自動(dòng)模式的便利又在關(guān)鍵場(chǎng)景保留手動(dòng)控制權(quán)。模式上下文范圍響應(yīng)速度誤判風(fēng)險(xiǎn)適用場(chǎng)景strict當(dāng)前文件/標(biāo)準(zhǔn)輸入最快低小函數(shù)調(diào)試、單文件修改repo倉(cāng)庫(kù)索引git文檔較慢中跨文件重構(gòu)、技術(shù)方案設(shè)計(jì)auto由工具自動(dòng)判斷中等需調(diào)優(yōu)日常高頻開(kāi)發(fā)3. 實(shí)操?gòu)牧愦钜粋€(gè) context-mode 腳本下面這部分我直接攤牌與其找一個(gè)現(xiàn)成的重型框架我建議你先手寫(xiě)一個(gè)幾十行的 context-mode 腳本把原理跑通再?zèng)Q定要不要上更復(fù)雜的方案。我自己維護(hù)的這個(gè)工具叫ctx核心邏輯就三個(gè)文件放在~/.ctx/下全項(xiàng)目加起來(lái)不到 300 行。3.1 需求拆解context-mode 最少要干四件事在寫(xiě)代碼之前先想清楚工具必須具備哪些能力保存上下文把當(dāng)前的工作狀態(tài)目錄、分支、環(huán)境變量等保存成一個(gè)會(huì)話(huà)。切換上下文根據(jù)會(huì)話(huà)名加載對(duì)應(yīng)狀態(tài)改變終端行為并讓其他工具能感知。列出/刪除上下文方便管理多個(gè)會(huì)話(huà)避免越攢越多。導(dǎo)出上下文把當(dāng)前上下文的內(nèi)容整理成文件或文本方便喂給 AI 助手。我不建議一上來(lái)就做云同步、團(tuán)隊(duì)共享、界面 GUI這些都不是 context-mode 的必需品。先解決單機(jī)、單人、終端場(chǎng)景的需求工具才會(huì)真的被用起來(lái)。3.2 數(shù)據(jù)模型與存儲(chǔ)設(shè)計(jì)context 本質(zhì)上是名稱(chēng)到狀態(tài)快照的映射。我用一個(gè) JSON 文件來(lái)做存儲(chǔ)路徑是~/.ctx/contexts.json。每個(gè)上下文記錄包含這些字段{ name: blog-project, cwd: /home/dev/workspace/blog, branch: feature/context-mode, env: { NODE_ENV: development, APP_PROFILE: local }, ai_prompt: 你現(xiàn)在是我的博客項(xiàng)目助手回答問(wèn)題時(shí)優(yōu)先參考 docs 目錄下的設(shè)計(jì)方案。, updated_at: 2025-01-18T10:24:0008:00 }這里關(guān)鍵的不是字段多少而是你要明確哪些狀態(tài)需要記憶哪些狀態(tài)需要忽略。比如cwd和branch每次切換時(shí)必須恢復(fù)env里只挑會(huì)影響運(yùn)行行為的變量ai_prompt是用來(lái)描述當(dāng)前任務(wù)的說(shuō)明文字這玩意兒在 AI 時(shí)代比環(huán)境變量還有用。存儲(chǔ)格式選 JSON 是因?yàn)檎{(diào)試方便、任何語(yǔ)言都能解析。如果你擔(dān)心并發(fā)寫(xiě)入問(wèn)題可以給文件加個(gè)簡(jiǎn)單的鎖或者直接在命令執(zhí)行時(shí)用flock包一層實(shí)測(cè)下來(lái)足夠穩(wěn)。3.3 核心命令的實(shí)現(xiàn)思路有了數(shù)據(jù)模型命令實(shí)現(xiàn)就是體力活。我貼一下關(guān)鍵代碼片段你可以直接照著改造。切換上下文ctx usefunction ctx_use() { local name$1 local store$HOME/.ctx/contexts.json if [ ! -f $store ]; then echo context store not found, run: ctx save name first return 1 fi local cwd cwd$(python3 -c import json,sys datajson.load(open($HOME/.ctx/contexts.json)) ctxdata.get($name) if not ctx: sys.exit(1) print(ctx[cwd]) 2/dev/null) if [ -z $cwd ]; then echo context [$name] not found return 1 fi cd $cwd || return 1 export CTX_MODE$name # 讀取該上下文對(duì)應(yīng)的環(huán)境變量 eval $(python3 -c import json datajson.load(open($HOME/.ctx/contexts.json)) ctxdata[$name] for k,v in ctx.get(env, {}).items(): print(fexport {k}{json.dumps(v)}) ) # 把 AI prompt 寫(xiě)入臨時(shí)文件后續(xù)腳本可以讀取 python3 -c import json datajson.load(open($HOME/.ctx/contexts.json)) ctxdata[$name] print(ctx.get(ai_prompt, )) $HOME/.ctx/current_prompt.txt echo switched to context [$name] }保存上下文ctx savefunction ctx_save() { local name$1 local store$HOME/.ctx/contexts.json local tmp$HOME/.ctx/contexts.tmp.json mkdir -p $HOME/.ctx python3 - $name PY import json, os, sys name sys.argv[1] store os.path.expanduser(~/.ctx/contexts.json) try: with open(store) as f: data json.load(f) except FileNotFoundError: data {} data[name] { name: name, cwd: os.getcwd(), branch: os.popen(git rev-parse --abbrev-ref HEAD 2/dev/null).read().strip() or not-git, env: {k: os.environ[k] for k in [NODE_ENV, APP_PROFILE] if k in os.environ}, updated_at: __import__(datetime).datetime.now().isoformat() } with open(os.path.expanduser(~/.ctx/contexts.tmp.json), w) as f: json.dump(data, f, indent2, ensure_asciiFalse) os.replace(os.path.expanduser(~/.ctx/contexts.tmp.json), store) print(fcontext [{name}] saved) PY }這段代碼里有一個(gè)很容易踩的坑寫(xiě)入 JSON 時(shí)不要直接覆蓋原文件。如果腳本中途報(bào)錯(cuò)你的 contexts.json 就直接崩了。我改成先寫(xiě)臨時(shí)文件再用os.replace原子替換這個(gè)習(xí)慣建議保持反正只多兩行。3.4 把這些命令掛到 shell 生命周期里命令寫(xiě)出來(lái)之后還得讓它們自動(dòng)發(fā)生。我覺(jué)得 context-mode 最大的價(jià)值不在于手動(dòng)切來(lái)切去而在于你一進(jìn)入某個(gè)目錄它就是那個(gè)上下文。方法很簡(jiǎn)單在.bashrc或.zshrc里注冊(cè)一個(gè)PROMPT_COMMAND鉤子每次終端執(zhí)行命令前檢查當(dāng)前目錄是否關(guān)聯(lián)了已保存的 context。如果關(guān)聯(lián)了就自動(dòng)加載沒(méi)關(guān)聯(lián)就保持默認(rèn)狀態(tài)。update_current_ctx() { local store$HOME/.ctx/contexts.json local map_file$HOME/.ctx/dir_ctx_map.json [ -f $map_file ] || return 0 local ctx_name ctx_name$(python3 -c import json, os map_datajson.load(open($HOME/.ctx/dir_ctx_map.json)) cwdos.getcwd() # 使用最長(zhǎng)前綴匹配 best None for prefix, name in map_data.items(): if cwd.startswith(prefix): if best is None or len(prefix) len(best[0]): best (prefix, name) if best: print(best[1]) 2/dev/null) if [ -n $ctx_name ] [ $ctx_name ! $__CTX_CURRENT ]; then ctx_use $ctx_name __CTX_CURRENT$ctx_name fi } PROMPT_COMMANDupdate_current_ctx; $PROMPT_COMMAND這段邏輯容易忽略的是防抖如果你每次回車(chē)都去執(zhí)行完整的ctx_use終端會(huì)明顯卡頓。所以我用一個(gè)__CTX_CURRENT變量記住當(dāng)前已經(jīng)加載的上下文只有切換目標(biāo)發(fā)生變化時(shí)才真正執(zhí)行加載。4. 把 context-mode 注入 AI 編程工作流如果說(shuō)前面這些命令還只是自嗨型效率工具那真正讓 context-mode 發(fā)揮十倍價(jià)值的是把它和 AI 編程助手聯(lián)動(dòng)起來(lái)。這個(gè)年頭誰(shuí)還沒(méi)用過(guò) AI 寫(xiě)代碼但絕大多數(shù)人用不好 AI 的根本原因就是不會(huì)喂上下文。4.1 手動(dòng)粘貼已經(jīng)是過(guò)去式我見(jiàn)過(guò)很多同事的常規(guī)操作把一堆文件內(nèi)容復(fù)制粘貼給對(duì)話(huà)窗口然后開(kāi)始提問(wèn)。這種操作有兩個(gè)致命問(wèn)題——第一復(fù)制的內(nèi)容往往超出模型窗口上限聊到一半就開(kāi)始丟上下文第二你復(fù)制的未必是模型真正需要的信息它需要的關(guān)鍵線(xiàn)索可能恰恰沒(méi)被復(fù)制過(guò)去。context-mode 的正確姿勢(shì)是先通過(guò) ctx 工具把當(dāng)前上下文整理成一個(gè)結(jié)構(gòu)化文件再把文件內(nèi)容或者路徑交給 AI。我一般在 prompt 里直接寫(xiě)請(qǐng)先閱讀 __CTX__/context.md然后回答我的問(wèn)題 本地環(huán)境是 development 模式當(dāng)前分支是 feature/context-mode 項(xiàng)目結(jié)構(gòu)見(jiàn) context.md 中的目錄樹(shù)部分。我的問(wèn)題是為什么/api/login 接口在本地返回 502這樣模型拿到的不再是一堆散裝代碼而是一份當(dāng)前項(xiàng)目在什么狀態(tài)、我看哪些文件、我要解決什么問(wèn)題的說(shuō)明書(shū)。實(shí)測(cè)下來(lái)回答的有效率至少提高一倍。4.2 自動(dòng)生成 context.md那 context.md 怎么來(lái)當(dāng)然不能手寫(xiě)我在 ctx 工具里加了一個(gè) export 子命令把當(dāng)前 context 自動(dòng)整理成 markdown 文件ctx export --output $HOME/.ctx/current_ctx.md生成的 context.md 長(zhǎng)這樣# Context: blog-project - 工作目錄: /home/dev/workspace/blog - 當(dāng)前分支: feature/context-mode - 應(yīng)用環(huán)境: development ## 目錄結(jié)構(gòu)最近兩層 ... ## 當(dāng)前 git 變更文件 ... ## 關(guān)鍵配置項(xiàng) ...這里的實(shí)現(xiàn)邏輯也不復(fù)雜目錄結(jié)構(gòu)用find配合-maxdepth控制層數(shù)git 變更用git status --short配置項(xiàng)則從項(xiàng)目的.env或配置文件里挑選非敏感字段。生成之后AI 既能直接讀全文也能只讀其中的目錄結(jié)構(gòu)小節(jié)按需取用。4.3 用 .ctxignore 控制上下文邊界管理上下文最讓人頭痛的問(wèn)題不是太少而是太多。倉(cāng)庫(kù)里node_modules、vendor、.git這些目錄動(dòng)輒幾十萬(wàn)文件一旦被當(dāng)作文本讀進(jìn)去不僅沒(méi)幫助還讓模型抓不住重點(diǎn)。解決辦法是學(xué)習(xí)gitignore的思路搞一個(gè).ctxignore文件node_modules/ vendor/ dist/ build/ *.lock .git/在 export 目錄結(jié)構(gòu)時(shí)腳本逐行讀取.ctxignore用最簡(jiǎn)單的前綴匹配把不需要的目錄過(guò)濾掉。這個(gè)技巧看著不起眼但它直接決定你的 context.md 是項(xiàng)目地圖還是垃圾堆。我見(jiàn)過(guò)不少 AI 工具越用越笨就是因?yàn)闆](méi)有做上下文消解每回都把不相關(guān)的大文件一股腦塞進(jìn)去。4.4 token 預(yù)算與注入順序即便有了 context.md也還是要注意 token 預(yù)算。大模型的注意力不是平均分配的排在前面和排在后面的內(nèi)容更容易被記住中間部分容易被忽略。所以我在注入順序上的建議是最前面放任務(wù)描述和當(dāng)前上下文一句話(huà)總結(jié)中間放目錄結(jié)構(gòu)和變更文件清單最后放最核心的源碼片段或報(bào)錯(cuò)日志。這樣模型一進(jìn)來(lái)就知道自己在哪個(gè)項(xiàng)目、要干嘛核心材料又是最近讀到的不容易被無(wú)關(guān)內(nèi)容帶跑。如果你用的是支持長(zhǎng)上下文的模型可以把完整 context.md 放前面再把具體問(wèn)題放最后讓它在首尾夾擊之下抓住重點(diǎn)。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄工具寫(xiě)完之后真正讓你頭疼的往往不是功能缺失而是一些不起眼但反復(fù)出現(xiàn)的毛病。我把自己用 context-mode 半年多以來(lái)踩過(guò)的坑整理成一張速查表希望對(duì)你有實(shí)際幫助。癥狀可能原因排查思路與解法切換上下文后環(huán)境變量沒(méi)變env字段沒(méi)有匹配到變量名或者 shell 緩沖區(qū)未刷新先跑 envAI 回答的內(nèi)容明顯來(lái)自另一個(gè)項(xiàng)目上下文文件沒(méi)有清空模型吃到了上一個(gè) context 的殘留ctx use時(shí)必須先重寫(xiě)current_ctx.md不能只在原文件后追加用ctx clear清空再切換目錄結(jié)構(gòu)導(dǎo)出巨大、超出模型上限沒(méi)配置.ctxignore或者find深度太深檢查.ctxignore是否生效導(dǎo)出時(shí)用-maxdepth 3限制只保留有代表性的層級(jí)ctx save時(shí)不定期出現(xiàn) JSON 損壞多終端并發(fā)寫(xiě)入同一個(gè) contexts.json改用原子替換先寫(xiě) tmp 再os.replace腳本入口加flock鎖切換后 git 分支與目錄不匹配手動(dòng)在別處git checkout過(guò)分支context 快照過(guò)期ctx save時(shí)單獨(dú)記錄分支名ctx use時(shí)提示分支不一致但不強(qiáng)行切分支避免丟改動(dòng)上下文文件里出現(xiàn)了密碼等敏感信息export 時(shí)把.env全量寫(xiě)進(jìn)去在ctx export里使用白名單過(guò)濾只導(dǎo)出鍵名不導(dǎo)出值或者對(duì)值做脫敏這里我想特別展開(kāi)第一個(gè)坑。我在初期測(cè)試時(shí)明明ctx save存了ENABLE_Xtrue切換后echo $ENABLE_X就是打不出來(lái)。排查了半天發(fā)現(xiàn)問(wèn)題出在 shell 函數(shù)里用eval導(dǎo)出變量時(shí)值里的特殊字符被二次解析了。后來(lái)我統(tǒng)一改用export KEY$(python3 輸出的值)這種方式并且所有值都用 JSON 序列化問(wèn)題才徹底解決。5.1 串臺(tái)問(wèn)題的深層解法除了上面表格里的快速處理串臺(tái)上下文污染其實(shí)值得多講兩句。根本原因在于AI 是有狀態(tài)記憶的但你的項(xiàng)目狀態(tài)是變化的。舉一個(gè)真實(shí)教訓(xùn)一次我在 A 項(xiàng)目里問(wèn) AI這個(gè)接口的鑒權(quán)方式是什么它回答的頭頭是道。過(guò)了兩周我在 B 項(xiàng)目里又問(wèn)了同樣一句話(huà)它居然把 A 項(xiàng)目的鑒權(quán)方案原封不動(dòng)搬了過(guò)來(lái)——因?yàn)樗舷挛拇翱诶镞€留著 A 項(xiàng)目的資料。當(dāng)時(shí)我意識(shí)到單純切換上下文還不夠必須在切換動(dòng)作里主動(dòng)銷(xiāo)毀舊上下文。所以在ctx use命令里我增加了清理步驟# 切換前清空所有 ctx 相關(guān)臨時(shí)文件 rm -f $HOME/.ctx/current_prompt.txt rm -f $HOME/.ctx/current_ctx.md __CTX_CURRENT這行代碼看起來(lái)簡(jiǎn)單但它徹底堵住了串臺(tái)漏洞。每次切換都是一次失憶讓 AI 只基于當(dāng)前上下文的文件做判斷。如果你用的是 Cursor 或 Cline 這類(lèi)工具原理也一樣——通過(guò)環(huán)境變量或配置文件切換工作區(qū)并確保會(huì)話(huà)上下文不會(huì)跨項(xiàng)目復(fù)用。5.2 性能問(wèn)題的取舍有朋友問(wèn)過(guò)我每次進(jìn)入目錄都跑一遍ctx_use會(huì)不會(huì)很慢實(shí)測(cè)下來(lái)加載 JSON、解析目錄、生成 context.md整套流程大約 200 到 400 毫秒基本無(wú)感。但如果你的倉(cāng)庫(kù)非常大find都掃不完那確實(shí)會(huì)對(duì)終端造成卡頓。我的處理策略是上下文導(dǎo)出是異步的。終端切換 context 時(shí)只做最關(guān)鍵的cd和export環(huán)境變量context.md 的生成放到后臺(tái)子進(jìn)程跑生成完成后才寫(xiě)入目標(biāo)路徑。如果 AI 工具在 context.md 還沒(méi)生成好時(shí)就發(fā)來(lái)請(qǐng)求會(huì)讓模型多等一會(huì)——但相比每次命令都阻塞這種等待完全值得。提示當(dāng)上下文導(dǎo)出包含大量文件時(shí)可以先按文件類(lèi)型過(guò)濾只保留.py/.ts/.go/.md/.json等文本文件二進(jìn)制文件一律跳過(guò)。這比限制目錄深度更有效因?yàn)楹芏啻笮?wèn)題是單個(gè)大文件造成的。6. 一點(diǎn)收尾的經(jīng)驗(yàn)之談寫(xiě)到這里我并不打算做那種今天我學(xué)會(huì)了 xxx的總結(jié)。我更想分享的是在反復(fù)迭代 context-mode 的過(guò)程中我自己感受最深的三條經(jīng)驗(yàn)。第一條上下文管理的本質(zhì)是限制不是收集。我見(jiàn)過(guò)非常多的人恨不得把所有信息都喂給 AI生怕它不知道。但實(shí)際效果恰恰相反有效的上下文一定是有邊界的。你給它一棵樹(shù)的全部樹(shù)葉它反而看不清樹(shù)冠的形狀。第二條工具必須藏在工作流里而不是放在桌面上。context-mode 如果只是又一個(gè)需要手動(dòng)打開(kāi)的面板它一定會(huì)被遺忘。只有當(dāng)它掛進(jìn) shell 鉤子、每次cd自動(dòng)切換、每次 AI 回答前自動(dòng)帶上項(xiàng)目上下文它才真正活起來(lái)。不要嫌自動(dòng)化的代碼難寫(xiě)這部分的投入回報(bào)率是最高的。第三條小步快跑比一步到位更靠譜。你完全可以先只實(shí)現(xiàn)ctx save和ctx use兩個(gè)命令用一周時(shí)間感受切換帶來(lái)的變化再逐步添加 env 管理、AI 注入、自動(dòng)導(dǎo)出。我一開(kāi)始也想著做一個(gè)能云端同步、支持多人協(xié)作的完整平臺(tái)幸虧沒(méi)做——現(xiàn)在用的這套本地腳本簡(jiǎn)潔穩(wěn)定還沒(méi)那么多需要維護(hù)的依賴(lài)。最后再送一個(gè)小技巧在ctx use切換完后把當(dāng)前的上下文名打印在終端提示符里就像(blog-project) ~/workspace/blog $這樣。這比任何文檔都直觀你永遠(yuǎn)知道自己現(xiàn)在處于哪個(gè)上下文里也不會(huì)再出現(xiàn)我在哪、我要改哪個(gè)文件的恍惚感。