的開發(fā)工作流)
最近朋友問(wèn)我同時(shí)推進(jìn)三個(gè)項(xiàng)目還能都接住是不是記性特別好。我說(shuō)不是是我不太靠腦子記事了。過(guò)去我打開一天工作的方式通常是瀏覽器掛著十幾個(gè)標(biāo)簽頁(yè)IDE里躺著兩個(gè)分支的改動(dòng)終端還停著上次沒(méi)跑完的構(gòu)建日志。一旦中途被拉去處理另一個(gè)任務(wù)回來(lái)后至少要花十幾分鐘才能重新進(jìn)入狀態(tài)這還算是運(yùn)氣好的。后來(lái)我把這堆混亂收拾成了一個(gè)叫 context-mode 的工作流它把“當(dāng)前在做什么”這個(gè)問(wèn)題從人腦記憶變成機(jī)器可保存、可恢復(fù)、可交接的狀態(tài)任務(wù)切換變得像關(guān)燈開燈一樣簡(jiǎn)單。這篇文章就把這套東西完整拆開講講背后的設(shè)計(jì)思路、每一層的實(shí)現(xiàn)方法以及我在落地過(guò)程中踩過(guò)的坑。1. 上下文切換為什么這么貴一次“換擋”的隱藏成本1.1 多任務(wù)不是并行而是頻繁換擋很多人以為同時(shí)推進(jìn)幾個(gè)任務(wù)效率會(huì)像多核 CPU 一樣成倍增長(zhǎng)。真實(shí)情況恰恰相反。在寫代碼這件事上人腦干的多線程其實(shí)是“快速切換 恢復(fù)現(xiàn)場(chǎng)”而每一次恢復(fù)現(xiàn)場(chǎng)都要付出額外開銷。舉個(gè)很典型的例子你正在改一個(gè)支付回調(diào)的簽名邏輯代碼已經(jīng)看到“這里需要處理超時(shí)重試”腦袋里正推演著異常分支。這時(shí)候同事過(guò)來(lái)問(wèn)了個(gè)部署問(wèn)題你答完回來(lái)屏幕上的代碼還是剛才那幾行但你腦中那個(gè)“推演到一半”的狀態(tài)已經(jīng)被打斷了。你得重新看一遍方法名、參數(shù)類型、上下文里的調(diào)用關(guān)系才能找回那種“我知道下一步要改哪里”的感覺(jué)。這個(gè)過(guò)程短則三五分鐘長(zhǎng)則十幾分鐘而且越復(fù)雜的任務(wù)恢復(fù)成本越高。有個(gè)概念叫注意力殘留大意是切換任務(wù)后大腦的一部分資源仍然停留在上一個(gè)任務(wù)上。這也是為什么頻繁看手機(jī)消息會(huì)顯著降低寫代碼質(zhì)量的原因——表面上你只分心了一兩秒但大腦從消息里掙脫出來(lái)還需要額外的緩沖時(shí)間。我做過(guò)一段時(shí)間的粗略統(tǒng)計(jì)一天里被打斷三次以上并且每次切換都涉及不同項(xiàng)目時(shí)光是“重新進(jìn)入狀態(tài)”的時(shí)間加起來(lái)就能超過(guò)四十分鐘。這還沒(méi)算切換時(shí)順手刷兩下瀏覽器、翻翻消息記錄這些隱性時(shí)間。對(duì)我來(lái)說(shuō)這就是 context-mode 最開始想解決的問(wèn)題——不是讓你不切換而是讓每次切換后的“恢復(fù)成本”趨近于零。1.2 上下文真正包含的東西狀態(tài)、目標(biāo)、線索在動(dòng)手搭工具之前得先搞清楚“上下文”到底指什么。我自己的拆解結(jié)果是三樣?xùn)|西狀態(tài)當(dāng)前這個(gè)任務(wù)進(jìn)行到哪一步了。比如哪幾個(gè)文件改過(guò)、服務(wù)是否在運(yùn)行、依賴裝沒(méi)裝、測(cè)試跑到哪個(gè)用例掛掉了。目標(biāo)這個(gè)任務(wù)最終要交付什么。是修復(fù)一個(gè) bug還是實(shí)現(xiàn)一個(gè)接口驗(yàn)收標(biāo)準(zhǔn)是什么。線索你剛才“想到哪了”。比如下一步要改哪個(gè)函數(shù)、那個(gè)深藏的配置項(xiàng)在哪里、某個(gè)臨時(shí)繞開的邏輯要不要回來(lái)清理。這三樣?xùn)|西在腦子里通常是隱性的不落到紙面上。而它們散落在機(jī)器里的形式又極其碎片化Git diff 里有狀態(tài)分支名里可能藏著目標(biāo)終端歷史記錄里留著線索。context-mode 的核心不是發(fā)明新東西而是把這三個(gè)信息統(tǒng)一收納到固定的、可快速檢索的位置讓你只需要看一眼就知道“我在哪、要去哪、下個(gè)動(dòng)作是什么”。1.3 先給上下文“打分”才知道自己的瓶頸在哪我不建議一上來(lái)就照著別人的配置抄。因?yàn)椴煌说那袚Q場(chǎng)景差別很大有人是純編碼任務(wù)之間的切換有人是編碼和會(huì)議之間的切換還有人是在兩個(gè)項(xiàng)目組之間橫跳。先做一周的審計(jì)記錄以下信息切換事件切換前在做什么切換后要做什么花了多久找回狀態(tài)最卡的點(diǎn)去回同事消息改用戶登錄邏輯繼續(xù)改用戶登錄邏輯約8分鐘忘了剛才推演到哪里切到B項(xiàng)目看報(bào)錯(cuò)寫A項(xiàng)目接口定位B項(xiàng)目線上日志約15分鐘不記得B項(xiàng)目的部署路徑吃完午飯回來(lái)寫README繼續(xù)寫README約3分鐘目標(biāo)明確狀態(tài)仍在記錄三四天后基本就能看清自己最痛的切換場(chǎng)景。我當(dāng)時(shí)的結(jié)論是跨項(xiàng)目切換最傷因?yàn)椴粌H代碼狀態(tài)要恢復(fù)連項(xiàng)目如何啟動(dòng)、日志在哪、分支情況如何都是獨(dú)立的。所以后面的方案也優(yōu)先解決“跨項(xiàng)目切換”這件事。2. 第一層實(shí)現(xiàn)用 tmux 和 direnv 把終端變成可恢復(fù)的工作臺(tái)2.1 tmux 會(huì)話布局一個(gè)項(xiàng)目一個(gè) session終端是我干活的主場(chǎng)所以第一層先解決“終端上下文”的問(wèn)題。我選了 tmux理由很簡(jiǎn)單它能讓每個(gè)項(xiàng)目擁有獨(dú)立的會(huì)話session會(huì)話里再按需開窗口window而且脫開會(huì)話后所有狀態(tài)都保留在服務(wù)器端下次 attach 回來(lái)就是原封不動(dòng)的現(xiàn)場(chǎng)。以前我開終端的方式很隨意一個(gè)窗口切目錄到處跑窗口一關(guān)歷史全沒(méi)?，F(xiàn)在的規(guī)范是一個(gè)項(xiàng)目對(duì)應(yīng)一個(gè) tmux session常年駐留不關(guān)。session 內(nèi)的窗口布局固定默認(rèn)四個(gè)窗口shell跑各種命令行操作editor打開編輯器或者直接文件預(yù)覽server跑開發(fā)服務(wù)器日志常年駐扎在這里logs查看指定服務(wù)的實(shí)時(shí)日志這樣的好處是肌肉記憶很直觀想看服務(wù)狀態(tài)就切到 server 窗口想查日志就切到 logs 窗口不用每次重新敲命令。我寫了一個(gè)小函數(shù)來(lái)新建項(xiàng)目會(huì)話省得每次手動(dòng)擺窗口ctx-new() { if [ -z $1 ]; then echo usage: ctx-new project-name return 1 fi local name$1 local dir$HOME/work/$name if [ ! -d $dir ]; then echo directory $dir does not exist return 1 fi tmux new-session -d -s $name -c $dir tmux rename-window -t $name:0 shell tmux new-window -t $name:1 -n editor -c $dir tmux new-window -t $name:2 -n server -c $dir tmux new-window -t $name:3 -n logs -c $dir tmux select-window -t $name:0 tmux attach -t $name }需要恢復(fù)某個(gè)項(xiàng)目的現(xiàn)場(chǎng)時(shí)只需要tmux attach -t project-name窗口布局、歷史輸出、當(dāng)前目錄全部還在。這一步不用任何插件tmux 原生就能做到。2.2 direnv進(jìn)入目錄自動(dòng)切換環(huán)境解決了終端布局還有個(gè)隱性問(wèn)題每個(gè)項(xiàng)目的環(huán)境變量、工具鏈版本完全不同。比如 A 項(xiàng)目用 Node 18B 項(xiàng)目用 Python 3.11C 項(xiàng)目需要設(shè)置一個(gè)特殊的API_BASE_URL。如果靠人肉記憶去 export那又是一個(gè)需要恢復(fù)的上下文。direnv 解決的就是這個(gè)。它會(huì)在你進(jìn)入目錄時(shí)自動(dòng)加載.envrc文件里聲明的環(huán)境變量離開目錄時(shí)自動(dòng)卸載。配置方式簡(jiǎn)單粗暴# 在項(xiàng)目根目錄創(chuàng)建 .envrc export NODE_VERSION18.18.0 export API_BASE_URLhttp://localhost:8080 export DEBUG_MODEtrue首次進(jìn)入目錄時(shí)執(zhí)行direnv allow放行即可。之后每次cd進(jìn)去環(huán)境變量就已經(jīng)按項(xiàng)目設(shè)好了終端提示符上甚至可以顯示當(dāng)前激活的項(xiàng)目名。這一步把“項(xiàng)目相關(guān)配置”從人腦記憶里徹底轉(zhuǎn)移到了文件里換項(xiàng)目時(shí)連 export 都不用敲。有人可能覺(jué)得 .envrc 和.env文件不是一回事嗎區(qū)別在于 .env 多數(shù)是給應(yīng)用本身讀取的配置而 .envrc 是開發(fā)環(huán)境層面的開關(guān)直接注入到 shell 環(huán)境里對(duì)命令行工具同樣生效。兩者完全可以配合使用。2.3 上下文快照與恢復(fù)的一鍵腳本tmux 能保存終端現(xiàn)場(chǎng)direnv 能切換環(huán)境但還有一類上下文它們存不了你腦子里正在想的“下一步動(dòng)作”。我一開始也以為沒(méi)救后來(lái)想通了——不能靠工具自動(dòng)記錄腦內(nèi)活動(dòng)那就人工制造一個(gè)“記憶錨點(diǎn)”。做法很簡(jiǎn)單定義一對(duì)ctx-save和ctx-load命令。ctx-save 把當(dāng)前分支、改動(dòng)文件、最近執(zhí)行的命令、隨手寫的備注打包成一個(gè)快照文件ctx-load 在恢復(fù)時(shí)把這個(gè)快照打印到終端并打開對(duì)應(yīng)編輯器ctx-save() { local note${1:-.ctx/quick-note.md} mkdir -p $(dirname $note) { echo # Context Snapshot: $(date %Y-%m-%d %H:%M) echo echo ## current branch git branch --show-current 2/dev/null || echo (not a git repo) echo echo ## changed files git status --short 2/dev/null | head -30 echo echo ## recent commands history 15 | tail -15 echo echo ## next step (self note) echo - } $note echo snapshot saved to $note } ctx-load() { local note${1:-.ctx/quick-note.md} if [ -f $note ]; then echo CONTEXT RESTORE cat $note else echo no context note at $note fi }這套靈感來(lái)自一個(gè)很樸素的生活經(jīng)驗(yàn)書看到一半合上之前夾個(gè)書簽第二天翻開就知道看到哪了。ctx-save 就是那個(gè)書簽。它不需要寫長(zhǎng)篇大論只要記錄“目標(biāo)、卡點(diǎn)、下一步”三個(gè)關(guān)鍵詞就夠。3. 第二層實(shí)現(xiàn)編輯器和 Git 分支組成的上下文閉環(huán)3.1 編輯器的會(huì)話恢復(fù)方案讓打開的文件也記得終端層面恢復(fù)后編輯器成了下一個(gè)斷層。以前我切回項(xiàng)目要重新打開一堆文件入口文件、組件、測(cè)試、配置文件少說(shuō)也要花一兩分鐘回憶“上次改了哪些文件”。把編輯器的會(huì)話狀態(tài)也納入 context-mode 管理之后這個(gè)動(dòng)作變成了自動(dòng)的。我用 Neovim 的時(shí)候用的是 persistence 插件。它能自動(dòng)保存當(dāng)前打開的文件列表、光標(biāo)位置、折疊狀態(tài)并在啟動(dòng)時(shí)恢復(fù)。核心配置也就幾行require(persistence).setup({ dir vim.fn.stdpath(state) .. /sessions/, options { buffers, curdir, tabpages, winsize } }) vim.api.nvim_create_autocmd(VimEnter, { callback function() require(persistence).load() end, })這樣每次打開項(xiàng)目編輯器自動(dòng)切回上次的打開狀態(tài)不用自己想起底改了哪些文件。如果你用 VS Code思路也一樣把.code-workspace文件提交到倉(cāng)庫(kù)里它可以聲明這個(gè)項(xiàng)目的多根目錄、調(diào)試配置、推薦插件。值得留意的是工作區(qū)文件里盡量別存機(jī)器相關(guān)的絕對(duì)路徑否則換電腦后一堆報(bào)錯(cuò)。3.2 分支名即上下文把任務(wù)狀態(tài)掛載到分支上編輯器恢復(fù)的是“文件狀態(tài)”但任務(wù)層面的上下文還需要一個(gè)載體。我最終選了 Git 分支——它本來(lái)就是任務(wù)的最小單元?，F(xiàn)在我的分支命名規(guī)范是類型/任務(wù)號(hào)-簡(jiǎn)短描述比如feat/42-user-login、fix/103-timeout-refactor。分支名本身就是一個(gè)上下文標(biāo)簽看到分支就知道在做什么。但這還不夠真正讓我覺(jué)得閉環(huán)的是把“任務(wù)筆記”也塞進(jìn)分支里。具體做法每個(gè)任務(wù)分支在創(chuàng)建時(shí)就生成一個(gè).ctx/NOTES.md隨分支一起走git checkout -b feat/42-user-login mkdir -p .ctx cat .ctx/NOTES.md EOF # Task: 用戶登錄功能 ## Goal (一句話) 實(shí)現(xiàn)郵箱密碼 JWT 的登錄接口并補(bǔ)充集成測(cè)試。 ## Acceptance Criteria - [ ] POST /api/login 返回 accessToken - [ ] 密碼錯(cuò)誤超過(guò)5次鎖定賬號(hào) - [ ] 集成測(cè)試覆蓋正常、錯(cuò)誤密碼、鎖定場(chǎng)景 ## Progress - [x] 搭建用戶模塊 - [ ] 編寫登錄服務(wù) - [ ] 接入 Redis 做失敗計(jì)數(shù) ## Blockers - 暫無(wú) ## Next Step - 編寫 AuthService.login() 的具體實(shí)現(xiàn) EOF這個(gè) NOTES.md 跟著分支走切回主分支時(shí)它不在工作目錄里不會(huì)礙事。等分支合并后整個(gè).ctx目錄隨分支一起被清理或保留完全不用單獨(dú)維護(hù)。它的作用不是寫日?qǐng)?bào)而是在你切走又切回時(shí)只花十秒鐘就能恢復(fù)任務(wù)全貌。3.3 上下文文檔模板別高估自己的筆記習(xí)慣很多人的筆記系統(tǒng)之所以堅(jiān)持不下去是因?yàn)閺摹跋胗洝钡健坝浵聛?lái)”之間摩擦太大。模板的作用就是把這個(gè)摩擦降到最低。我在.ctx/template.md里固定了五個(gè)小標(biāo)題沒(méi)有多余字段Goal一句話表達(dá)最終要交付什么Acceptance Criteria驗(yàn)收標(biāo)準(zhǔn)用 checkboxProgress當(dāng)前進(jìn)展控制在十條以內(nèi)Blockers卡點(diǎn)只寫暫時(shí)解不了的Next Step下一步的具體動(dòng)作這套模板的核心邏輯是無(wú)論上下文多么復(fù)雜最終落到行動(dòng)上的只有“下一步做什么”。只要 Next Step 是清晰的這個(gè)任務(wù)就不會(huì)丟如果 Next Step 寫不出來(lái)說(shuō)明你還沒(méi)真正理解任務(wù)這時(shí)候?qū)懴聛?lái)本身就是一種思考。我自己吃過(guò)虧曾經(jīng)把模板設(shè)計(jì)成十幾個(gè)字段負(fù)責(zé)人、預(yù)計(jì)時(shí)間、依賴方、風(fēng)險(xiǎn)等級(jí)……結(jié)果記了兩天就再也不想打開。模板越輕越容易被記錄。寫 NOTES.md 的時(shí)間我會(huì)控制在五分鐘以內(nèi)超出五分鐘說(shuō)明記的不是有效上下文而是流水賬。4. 第三層實(shí)現(xiàn)AI 輔助編程時(shí)代的上下文投喂與回收4.1 為什么 AI 總在“答非所問(wèn)”上下文窗口不等于有效信息隨著 AI 輔助編碼成為日常我意識(shí)到 context-mode 又多了一層新任務(wù)管理人與模型之間的上下文。很多人覺(jué)得 AI 回答不靠譜其實(shí)一半情況是上下文給得不到位。大語(yǔ)言模型的上下文窗口是有限的而且窗口內(nèi)塞入大量無(wú)關(guān)代碼后模型對(duì)關(guān)鍵信息的注意力會(huì)被稀釋。這跟給人交接任務(wù)一樣——你把一個(gè)項(xiàng)目壓縮包直接發(fā)過(guò)去對(duì)方也不知道該從哪看起。最常見的失敗姿勢(shì)有兩種一是只丟一句“幫我看看這個(gè)報(bào)錯(cuò)”沒(méi)有任何文件路徑、代碼片段、環(huán)境信息模型只能瞎猜二是把整個(gè)項(xiàng)目代碼粘進(jìn)去動(dòng)輒幾百行結(jié)果模型被無(wú)關(guān)邏輯帶跑回復(fù)看似完整但完全不對(duì)癥。有效上下文的核心是“信息密度”不是“信息總量”。我給 AI 喂上下文時(shí)的原則是讓它在沒(méi)有額外猜測(cè)的情況下能直接理解三件事——要解決什么問(wèn)題、相關(guān)代碼在哪個(gè)文件負(fù)責(zé)什么、期望的輸出形式是什么。4.2 一套固定的上下文打包模板為了解決這個(gè)問(wèn)題我把給 AI 提問(wèn)時(shí)的上下文整理成了固定模板保存成一個(gè) snippet每次直接套用當(dāng)前任務(wù)修復(fù)登錄接口在密碼錯(cuò)誤時(shí)返回 500 的問(wèn)題 涉及文件 - server/routes/auth.ts登錄路由入口調(diào)用 AuthService.login - server/services/auth.service.ts核心邏輯密碼校驗(yàn)和 JWT 簽發(fā)在這里 相關(guān)報(bào)錯(cuò) POST /api/login 返回 500 日志Error: Password verification failed: invalid signature 已嘗試的方法 - 用正確密碼可以登錄說(shuō)明接口和 JWT 簽發(fā)邏輯基本正常 - 確認(rèn)數(shù)據(jù)庫(kù)連接正常 目標(biāo)定位密碼校驗(yàn)失敗的具體原因輸出修復(fù)后的代碼 diff 和原理說(shuō)明注意看這個(gè)模板的結(jié)構(gòu)任務(wù)目標(biāo)、涉及文件路徑及每文件的作用、報(bào)錯(cuò)原文、已嘗試過(guò)的方向、期望輸出。它能用的原因在于它把模型需要“腦補(bǔ)”的空間壓縮到了最小同時(shí)給出了足夠強(qiáng)的檢索信號(hào)。我還發(fā)現(xiàn)一個(gè)小細(xì)節(jié)當(dāng)你列出“已嘗試的方法”時(shí)模型會(huì)明顯減少重復(fù)建議回復(fù)會(huì)更聚焦到剩余的可能性上。這本質(zhì)上是在給模型的推理過(guò)程劃定上下文邊界。4.3 讓 AI 自己總結(jié)上下文長(zhǎng)對(duì)話的接力技術(shù)上下文管理還有一個(gè)更隱蔽的問(wèn)題同一個(gè)任務(wù)在聊天窗口里聊了很久新開窗口時(shí)之前的內(nèi)容全丟了。重新粘貼一遍所有信息不僅累還容易漏。我的做法是把“總結(jié)”作為對(duì)話的一部分而不是事后的工作。在長(zhǎng)時(shí)間任務(wù)的關(guān)鍵節(jié)點(diǎn)我會(huì)讓 AI 生成一份“當(dāng)前狀態(tài)確認(rèn)”請(qǐng)基于我們剛才的討論輸出一份簡(jiǎn)短的上下文交接文檔 1. 當(dāng)前要解決的問(wèn)題 2. 已經(jīng)確定的方案 3. 已修改的文件和修改要點(diǎn) 4. 尚未解決的問(wèn)題 5. 下一步建議動(dòng)作 用清單形式控制在一屏以內(nèi)。這樣獲得的狀態(tài)文檔可以直接粘貼給新對(duì)話也讓自己的 NOTES.md 有了可復(fù)制的來(lái)源。每次開新對(duì)話時(shí)先粘貼這段狀態(tài)再繼續(xù)提問(wèn)效果接近無(wú)縫銜接。另外我強(qiáng)烈建議在項(xiàng)目根目錄維護(hù)一個(gè)AGENTS.md或CLAUDE.md文件用來(lái)記錄項(xiàng)目級(jí)的長(zhǎng)期上下文技術(shù)棧、目錄結(jié)構(gòu)、啟動(dòng)命令、代碼風(fēng)格約束。把這種穩(wěn)定信息寫入文件臨時(shí)對(duì)話時(shí)就不用反復(fù)粘貼它們。短期上下文靠模板長(zhǎng)期上下文靠文件兩者配合AI 輔助編程的體驗(yàn)會(huì)穩(wěn)定很多。5. 落地過(guò)程中踩過(guò)的坑與最終的簡(jiǎn)化版本5.1 坑一方案太重裝完就不想用一開始我構(gòu)建這套東西時(shí)犯了個(gè)典型錯(cuò)誤——追求“完整”而不是“好用”。我給 tmux 加了 statusline 插件給 Neovim 配了自動(dòng) session 選擇器寫了一個(gè)支持參數(shù)解析的巨型.bashrc腳本甚至計(jì)劃把瀏覽器標(biāo)簽頁(yè)也用插件統(tǒng)一管理。結(jié)果呢搭建用了整整兩天第三周就開始覺(jué)得維護(hù)成本太高腳本報(bào)錯(cuò)不知道改哪插件升級(jí)后又出現(xiàn)兼容問(wèn)題最后連ctx-new這個(gè)命令都懶得用了。后來(lái)我把大量自定義腳本砍掉只保留 tmux 原生命令、direnv、編輯器插件和極簡(jiǎn)的兩個(gè) shell 函數(shù)。真正留下來(lái)被高頻使用的是那些“一眼看得懂、壞了不用修”的東西。自動(dòng)化本身是有成本的每個(gè)自定義腳本都意味著未來(lái)的維護(hù)負(fù)擔(dān)在真正常駐工作流之前盡量先用現(xiàn)成方案。5.2 坑二上下文筆記寫成了流水賬我一度認(rèn)為筆記記得越多越安全于是變成了每半小時(shí)記錄一次。結(jié)果是 NOTES.md 長(zhǎng)得像工作日志列了一堆已完成操作卻找不到一句明確的“下一步”。切換回來(lái)時(shí)看這種筆記等于重新讀一遍歷史根本沒(méi)有起到快速恢復(fù)的作用。后來(lái)我給 NOTES.md 設(shè)了硬限制只保留模板里的五個(gè)字段Progress 出現(xiàn)超過(guò)十條就必須清理合并每次更新只允許在 Next Step 上花最多五分鐘思考。這個(gè)約束逼著我提煉真正關(guān)鍵的信息而不是把所有動(dòng)作都囤積在文件里。筆記的價(jià)值不在厚而在“能讓人在三十秒內(nèi)做出繼續(xù)行動(dòng)的決定”。5.3 坑三只存上下文不設(shè)恢復(fù)檢查點(diǎn)我早期做了ctx-save卻沒(méi)做對(duì)應(yīng)的恢復(fù)動(dòng)作。剛開始挺得意覺(jué)得有個(gè)快照總比沒(méi)有強(qiáng)。結(jié)果真實(shí)場(chǎng)景中我切回來(lái)時(shí)經(jīng)常忘記執(zhí)行ctx-load或者執(zhí)行后發(fā)現(xiàn)快照是兩天前的根本沒(méi)有恢復(fù)到最新的狀態(tài)?？煺杖绻辉凇扒谢厝蝿?wù)”的那一刻被使用就只是一串靜默躺在磁盤上的文字。這也是為什么我現(xiàn)在把 save 和 load 設(shè)計(jì)成一對(duì)并且要求“長(zhǎng)時(shí)間離開前必須 save回來(lái)后必須先 load”。load 不僅僅是打印內(nèi)容更是一個(gè)儀式感動(dòng)作它強(qiáng)迫你接收“任務(wù)已恢復(fù)可以繼續(xù)”的心理信號(hào)。沒(méi)有檢查點(diǎn)的上下文管理等于沒(méi)有存檔的游戲——你保存了但讀取的入口不在手邊最終還是會(huì)被打回原形。5.4 我最后留下的最小閉環(huán)折騰一圈后真正長(zhǎng)期在用的其實(shí)是一套非常樸素的最小閉環(huán)一個(gè) tmux session 對(duì)應(yīng)一個(gè)項(xiàng)目關(guān)掉終端也不影響現(xiàn)場(chǎng)每個(gè)任務(wù)分支都有一個(gè).ctx/NOTES.md只記目標(biāo)、驗(yàn)收、卡點(diǎn)、下一步給 AI 提問(wèn)前套用固定模板打包必要上下文長(zhǎng)任務(wù)用 AI 生成的“狀態(tài)確認(rèn)”做交接長(zhǎng)時(shí)間離開任務(wù)前執(zhí)行 ctx-save回來(lái)后先 ctx-load 再動(dòng)手這套東西加起來(lái)搭建時(shí)間不到半小時(shí)并且大部分依賴都是現(xiàn)成工具壞了隨時(shí)能重來(lái)。它不華麗但足夠穩(wěn)。如果你也想搭一套屬于自己的 context-mode我的建議是別從我的完整配置抄起。先只做一件事給當(dāng)前正在進(jìn)行的任務(wù)建一個(gè).ctx/NOTES.md把目標(biāo)和下一步寫進(jìn)去。等這個(gè)習(xí)慣穩(wěn)固了再去加 tmux 會(huì)話、再加編輯器恢復(fù)、再加 AI 上下文模板。上下文管理這種東西最貴的從來(lái)不是技術(shù)實(shí)現(xiàn)而是你愿不愿意在每個(gè)“切換點(diǎn)”上多花十秒鐘給未來(lái)的自己留一條回來(lái)的路。 上下文切換太貴？用 context-mode 打造可恢復(fù)的開發(fā)工作流
最近朋友問(wèn)我同時(shí)推進(jìn)三個(gè)項(xiàng)目還能都接住是不是記性特別好。我說(shuō)不是是我不太靠腦子記事了。過(guò)去我打開一天工作的方式通常是瀏覽器掛著十幾個(gè)標(biāo)簽頁(yè)IDE里躺著兩個(gè)分支的改動(dòng)終端還停著上次沒(méi)跑完的構(gòu)建日志。一旦中途被拉去處理另一個(gè)任務(wù)回來(lái)后至少要花十幾分鐘才能重新進(jìn)入狀態(tài)這還算是運(yùn)氣好的。后來(lái)我把這堆混亂收拾成了一個(gè)叫 context-mode 的工作流它把“當(dāng)前在做什么”這個(gè)問(wèn)題從人腦記憶變成機(jī)器可保存、可恢復(fù)、可交接的狀態(tài)任務(wù)切換變得像關(guān)燈開燈一樣簡(jiǎn)單。這篇文章就把這套東西完整拆開講講背后的設(shè)計(jì)思路、每一層的實(shí)現(xiàn)方法以及我在落地過(guò)程中踩過(guò)的坑。1. 上下文切換為什么這么貴一次“換擋”的隱藏成本1.1 多任務(wù)不是并行而是頻繁換擋很多人以為同時(shí)推進(jìn)幾個(gè)任務(wù)效率會(huì)像多核 CPU 一樣成倍增長(zhǎng)。真實(shí)情況恰恰相反。在寫代碼這件事上人腦干的多線程其實(shí)是“快速切換 恢復(fù)現(xiàn)場(chǎng)”而每一次恢復(fù)現(xiàn)場(chǎng)都要付出額外開銷。舉個(gè)很典型的例子你正在改一個(gè)支付回調(diào)的簽名邏輯代碼已經(jīng)看到“這里需要處理超時(shí)重試”腦袋里正推演著異常分支。這時(shí)候同事過(guò)來(lái)問(wèn)了個(gè)部署問(wèn)題你答完回來(lái)屏幕上的代碼還是剛才那幾行但你腦中那個(gè)“推演到一半”的狀態(tài)已經(jīng)被打斷了。你得重新看一遍方法名、參數(shù)類型、上下文里的調(diào)用關(guān)系才能找回那種“我知道下一步要改哪里”的感覺(jué)。這個(gè)過(guò)程短則三五分鐘長(zhǎng)則十幾分鐘而且越復(fù)雜的任務(wù)恢復(fù)成本越高。有個(gè)概念叫注意力殘留大意是切換任務(wù)后大腦的一部分資源仍然停留在上一個(gè)任務(wù)上。這也是為什么頻繁看手機(jī)消息會(huì)顯著降低寫代碼質(zhì)量的原因——表面上你只分心了一兩秒但大腦從消息里掙脫出來(lái)還需要額外的緩沖時(shí)間。我做過(guò)一段時(shí)間的粗略統(tǒng)計(jì)一天里被打斷三次以上并且每次切換都涉及不同項(xiàng)目時(shí)光是“重新進(jìn)入狀態(tài)”的時(shí)間加起來(lái)就能超過(guò)四十分鐘。這還沒(méi)算切換時(shí)順手刷兩下瀏覽器、翻翻消息記錄這些隱性時(shí)間。對(duì)我來(lái)說(shuō)這就是 context-mode 最開始想解決的問(wèn)題——不是讓你不切換而是讓每次切換后的“恢復(fù)成本”趨近于零。1.2 上下文真正包含的東西狀態(tài)、目標(biāo)、線索在動(dòng)手搭工具之前得先搞清楚“上下文”到底指什么。我自己的拆解結(jié)果是三樣?xùn)|西狀態(tài)當(dāng)前這個(gè)任務(wù)進(jìn)行到哪一步了。比如哪幾個(gè)文件改過(guò)、服務(wù)是否在運(yùn)行、依賴裝沒(méi)裝、測(cè)試跑到哪個(gè)用例掛掉了。目標(biāo)這個(gè)任務(wù)最終要交付什么。是修復(fù)一個(gè) bug還是實(shí)現(xiàn)一個(gè)接口驗(yàn)收標(biāo)準(zhǔn)是什么。線索你剛才“想到哪了”。比如下一步要改哪個(gè)函數(shù)、那個(gè)深藏的配置項(xiàng)在哪里、某個(gè)臨時(shí)繞開的邏輯要不要回來(lái)清理。這三樣?xùn)|西在腦子里通常是隱性的不落到紙面上。而它們散落在機(jī)器里的形式又極其碎片化Git diff 里有狀態(tài)分支名里可能藏著目標(biāo)終端歷史記錄里留著線索。context-mode 的核心不是發(fā)明新東西而是把這三個(gè)信息統(tǒng)一收納到固定的、可快速檢索的位置讓你只需要看一眼就知道“我在哪、要去哪、下個(gè)動(dòng)作是什么”。1.3 先給上下文“打分”才知道自己的瓶頸在哪我不建議一上來(lái)就照著別人的配置抄。因?yàn)椴煌说那袚Q場(chǎng)景差別很大有人是純編碼任務(wù)之間的切換有人是編碼和會(huì)議之間的切換還有人是在兩個(gè)項(xiàng)目組之間橫跳。先做一周的審計(jì)記錄以下信息切換事件切換前在做什么切換后要做什么花了多久找回狀態(tài)最卡的點(diǎn)去回同事消息改用戶登錄邏輯繼續(xù)改用戶登錄邏輯約8分鐘忘了剛才推演到哪里切到B項(xiàng)目看報(bào)錯(cuò)寫A項(xiàng)目接口定位B項(xiàng)目線上日志約15分鐘不記得B項(xiàng)目的部署路徑吃完午飯回來(lái)寫README繼續(xù)寫README約3分鐘目標(biāo)明確狀態(tài)仍在記錄三四天后基本就能看清自己最痛的切換場(chǎng)景。我當(dāng)時(shí)的結(jié)論是跨項(xiàng)目切換最傷因?yàn)椴粌H代碼狀態(tài)要恢復(fù)連項(xiàng)目如何啟動(dòng)、日志在哪、分支情況如何都是獨(dú)立的。所以后面的方案也優(yōu)先解決“跨項(xiàng)目切換”這件事。2. 第一層實(shí)現(xiàn)用 tmux 和 direnv 把終端變成可恢復(fù)的工作臺(tái)2.1 tmux 會(huì)話布局一個(gè)項(xiàng)目一個(gè) session終端是我干活的主場(chǎng)所以第一層先解決“終端上下文”的問(wèn)題。我選了 tmux理由很簡(jiǎn)單它能讓每個(gè)項(xiàng)目擁有獨(dú)立的會(huì)話session會(huì)話里再按需開窗口window而且脫開會(huì)話后所有狀態(tài)都保留在服務(wù)器端下次 attach 回來(lái)就是原封不動(dòng)的現(xiàn)場(chǎng)。以前我開終端的方式很隨意一個(gè)窗口切目錄到處跑窗口一關(guān)歷史全沒(méi)?，F(xiàn)在的規(guī)范是一個(gè)項(xiàng)目對(duì)應(yīng)一個(gè) tmux session常年駐留不關(guān)。session 內(nèi)的窗口布局固定默認(rèn)四個(gè)窗口shell跑各種命令行操作editor打開編輯器或者直接文件預(yù)覽server跑開發(fā)服務(wù)器日志常年駐扎在這里logs查看指定服務(wù)的實(shí)時(shí)日志這樣的好處是肌肉記憶很直觀想看服務(wù)狀態(tài)就切到 server 窗口想查日志就切到 logs 窗口不用每次重新敲命令。我寫了一個(gè)小函數(shù)來(lái)新建項(xiàng)目會(huì)話省得每次手動(dòng)擺窗口ctx-new() { if [ -z $1 ]; then echo usage: ctx-new project-name return 1 fi local name$1 local dir$HOME/work/$name if [ ! -d $dir ]; then echo directory $dir does not exist return 1 fi tmux new-session -d -s $name -c $dir tmux rename-window -t $name:0 shell tmux new-window -t $name:1 -n editor -c $dir tmux new-window -t $name:2 -n server -c $dir tmux new-window -t $name:3 -n logs -c $dir tmux select-window -t $name:0 tmux attach -t $name }需要恢復(fù)某個(gè)項(xiàng)目的現(xiàn)場(chǎng)時(shí)只需要tmux attach -t project-name窗口布局、歷史輸出、當(dāng)前目錄全部還在。這一步不用任何插件tmux 原生就能做到。2.2 direnv進(jìn)入目錄自動(dòng)切換環(huán)境解決了終端布局還有個(gè)隱性問(wèn)題每個(gè)項(xiàng)目的環(huán)境變量、工具鏈版本完全不同。比如 A 項(xiàng)目用 Node 18B 項(xiàng)目用 Python 3.11C 項(xiàng)目需要設(shè)置一個(gè)特殊的API_BASE_URL。如果靠人肉記憶去 export那又是一個(gè)需要恢復(fù)的上下文。direnv 解決的就是這個(gè)。它會(huì)在你進(jìn)入目錄時(shí)自動(dòng)加載.envrc文件里聲明的環(huán)境變量離開目錄時(shí)自動(dòng)卸載。配置方式簡(jiǎn)單粗暴# 在項(xiàng)目根目錄創(chuàng)建 .envrc export NODE_VERSION18.18.0 export API_BASE_URLhttp://localhost:8080 export DEBUG_MODEtrue首次進(jìn)入目錄時(shí)執(zhí)行direnv allow放行即可。之后每次cd進(jìn)去環(huán)境變量就已經(jīng)按項(xiàng)目設(shè)好了終端提示符上甚至可以顯示當(dāng)前激活的項(xiàng)目名。這一步把“項(xiàng)目相關(guān)配置”從人腦記憶里徹底轉(zhuǎn)移到了文件里換項(xiàng)目時(shí)連 export 都不用敲。有人可能覺(jué)得 .envrc 和.env文件不是一回事嗎區(qū)別在于 .env 多數(shù)是給應(yīng)用本身讀取的配置而 .envrc 是開發(fā)環(huán)境層面的開關(guān)直接注入到 shell 環(huán)境里對(duì)命令行工具同樣生效。兩者完全可以配合使用。2.3 上下文快照與恢復(fù)的一鍵腳本tmux 能保存終端現(xiàn)場(chǎng)direnv 能切換環(huán)境但還有一類上下文它們存不了你腦子里正在想的“下一步動(dòng)作”。我一開始也以為沒(méi)救后來(lái)想通了——不能靠工具自動(dòng)記錄腦內(nèi)活動(dòng)那就人工制造一個(gè)“記憶錨點(diǎn)”。做法很簡(jiǎn)單定義一對(duì)ctx-save和ctx-load命令。ctx-save 把當(dāng)前分支、改動(dòng)文件、最近執(zhí)行的命令、隨手寫的備注打包成一個(gè)快照文件ctx-load 在恢復(fù)時(shí)把這個(gè)快照打印到終端并打開對(duì)應(yīng)編輯器ctx-save() { local note${1:-.ctx/quick-note.md} mkdir -p $(dirname $note) { echo # Context Snapshot: $(date %Y-%m-%d %H:%M) echo echo ## current branch git branch --show-current 2/dev/null || echo (not a git repo) echo echo ## changed files git status --short 2/dev/null | head -30 echo echo ## recent commands history 15 | tail -15 echo echo ## next step (self note) echo - } $note echo snapshot saved to $note } ctx-load() { local note${1:-.ctx/quick-note.md} if [ -f $note ]; then echo CONTEXT RESTORE cat $note else echo no context note at $note fi }這套靈感來(lái)自一個(gè)很樸素的生活經(jīng)驗(yàn)書看到一半合上之前夾個(gè)書簽第二天翻開就知道看到哪了。ctx-save 就是那個(gè)書簽。它不需要寫長(zhǎng)篇大論只要記錄“目標(biāo)、卡點(diǎn)、下一步”三個(gè)關(guān)鍵詞就夠。3. 第二層實(shí)現(xiàn)編輯器和 Git 分支組成的上下文閉環(huán)3.1 編輯器的會(huì)話恢復(fù)方案讓打開的文件也記得終端層面恢復(fù)后編輯器成了下一個(gè)斷層。以前我切回項(xiàng)目要重新打開一堆文件入口文件、組件、測(cè)試、配置文件少說(shuō)也要花一兩分鐘回憶“上次改了哪些文件”。把編輯器的會(huì)話狀態(tài)也納入 context-mode 管理之后這個(gè)動(dòng)作變成了自動(dòng)的。我用 Neovim 的時(shí)候用的是 persistence 插件。它能自動(dòng)保存當(dāng)前打開的文件列表、光標(biāo)位置、折疊狀態(tài)并在啟動(dòng)時(shí)恢復(fù)。核心配置也就幾行require(persistence).setup({ dir vim.fn.stdpath(state) .. /sessions/, options { buffers, curdir, tabpages, winsize } }) vim.api.nvim_create_autocmd(VimEnter, { callback function() require(persistence).load() end, })這樣每次打開項(xiàng)目編輯器自動(dòng)切回上次的打開狀態(tài)不用自己想起底改了哪些文件。如果你用 VS Code思路也一樣把.code-workspace文件提交到倉(cāng)庫(kù)里它可以聲明這個(gè)項(xiàng)目的多根目錄、調(diào)試配置、推薦插件。值得留意的是工作區(qū)文件里盡量別存機(jī)器相關(guān)的絕對(duì)路徑否則換電腦后一堆報(bào)錯(cuò)。3.2 分支名即上下文把任務(wù)狀態(tài)掛載到分支上編輯器恢復(fù)的是“文件狀態(tài)”但任務(wù)層面的上下文還需要一個(gè)載體。我最終選了 Git 分支——它本來(lái)就是任務(wù)的最小單元?，F(xiàn)在我的分支命名規(guī)范是類型/任務(wù)號(hào)-簡(jiǎn)短描述比如feat/42-user-login、fix/103-timeout-refactor。分支名本身就是一個(gè)上下文標(biāo)簽看到分支就知道在做什么。但這還不夠真正讓我覺(jué)得閉環(huán)的是把“任務(wù)筆記”也塞進(jìn)分支里。具體做法每個(gè)任務(wù)分支在創(chuàng)建時(shí)就生成一個(gè).ctx/NOTES.md隨分支一起走git checkout -b feat/42-user-login mkdir -p .ctx cat .ctx/NOTES.md EOF # Task: 用戶登錄功能 ## Goal (一句話) 實(shí)現(xiàn)郵箱密碼 JWT 的登錄接口并補(bǔ)充集成測(cè)試。 ## Acceptance Criteria - [ ] POST /api/login 返回 accessToken - [ ] 密碼錯(cuò)誤超過(guò)5次鎖定賬號(hào) - [ ] 集成測(cè)試覆蓋正常、錯(cuò)誤密碼、鎖定場(chǎng)景 ## Progress - [x] 搭建用戶模塊 - [ ] 編寫登錄服務(wù) - [ ] 接入 Redis 做失敗計(jì)數(shù) ## Blockers - 暫無(wú) ## Next Step - 編寫 AuthService.login() 的具體實(shí)現(xiàn) EOF這個(gè) NOTES.md 跟著分支走切回主分支時(shí)它不在工作目錄里不會(huì)礙事。等分支合并后整個(gè).ctx目錄隨分支一起被清理或保留完全不用單獨(dú)維護(hù)。它的作用不是寫日?qǐng)?bào)而是在你切走又切回時(shí)只花十秒鐘就能恢復(fù)任務(wù)全貌。3.3 上下文文檔模板別高估自己的筆記習(xí)慣很多人的筆記系統(tǒng)之所以堅(jiān)持不下去是因?yàn)閺摹跋胗洝钡健坝浵聛?lái)”之間摩擦太大。模板的作用就是把這個(gè)摩擦降到最低。我在.ctx/template.md里固定了五個(gè)小標(biāo)題沒(méi)有多余字段Goal一句話表達(dá)最終要交付什么Acceptance Criteria驗(yàn)收標(biāo)準(zhǔn)用 checkboxProgress當(dāng)前進(jìn)展控制在十條以內(nèi)Blockers卡點(diǎn)只寫暫時(shí)解不了的Next Step下一步的具體動(dòng)作這套模板的核心邏輯是無(wú)論上下文多么復(fù)雜最終落到行動(dòng)上的只有“下一步做什么”。只要 Next Step 是清晰的這個(gè)任務(wù)就不會(huì)丟如果 Next Step 寫不出來(lái)說(shuō)明你還沒(méi)真正理解任務(wù)這時(shí)候?qū)懴聛?lái)本身就是一種思考。我自己吃過(guò)虧曾經(jīng)把模板設(shè)計(jì)成十幾個(gè)字段負(fù)責(zé)人、預(yù)計(jì)時(shí)間、依賴方、風(fēng)險(xiǎn)等級(jí)……結(jié)果記了兩天就再也不想打開。模板越輕越容易被記錄。寫 NOTES.md 的時(shí)間我會(huì)控制在五分鐘以內(nèi)超出五分鐘說(shuō)明記的不是有效上下文而是流水賬。4. 第三層實(shí)現(xiàn)AI 輔助編程時(shí)代的上下文投喂與回收4.1 為什么 AI 總在“答非所問(wèn)”上下文窗口不等于有效信息隨著 AI 輔助編碼成為日常我意識(shí)到 context-mode 又多了一層新任務(wù)管理人與模型之間的上下文。很多人覺(jué)得 AI 回答不靠譜其實(shí)一半情況是上下文給得不到位。大語(yǔ)言模型的上下文窗口是有限的而且窗口內(nèi)塞入大量無(wú)關(guān)代碼后模型對(duì)關(guān)鍵信息的注意力會(huì)被稀釋。這跟給人交接任務(wù)一樣——你把一個(gè)項(xiàng)目壓縮包直接發(fā)過(guò)去對(duì)方也不知道該從哪看起。最常見的失敗姿勢(shì)有兩種一是只丟一句“幫我看看這個(gè)報(bào)錯(cuò)”沒(méi)有任何文件路徑、代碼片段、環(huán)境信息模型只能瞎猜二是把整個(gè)項(xiàng)目代碼粘進(jìn)去動(dòng)輒幾百行結(jié)果模型被無(wú)關(guān)邏輯帶跑回復(fù)看似完整但完全不對(duì)癥。有效上下文的核心是“信息密度”不是“信息總量”。我給 AI 喂上下文時(shí)的原則是讓它在沒(méi)有額外猜測(cè)的情況下能直接理解三件事——要解決什么問(wèn)題、相關(guān)代碼在哪個(gè)文件負(fù)責(zé)什么、期望的輸出形式是什么。4.2 一套固定的上下文打包模板為了解決這個(gè)問(wèn)題我把給 AI 提問(wèn)時(shí)的上下文整理成了固定模板保存成一個(gè) snippet每次直接套用當(dāng)前任務(wù)修復(fù)登錄接口在密碼錯(cuò)誤時(shí)返回 500 的問(wèn)題 涉及文件 - server/routes/auth.ts登錄路由入口調(diào)用 AuthService.login - server/services/auth.service.ts核心邏輯密碼校驗(yàn)和 JWT 簽發(fā)在這里 相關(guān)報(bào)錯(cuò) POST /api/login 返回 500 日志Error: Password verification failed: invalid signature 已嘗試的方法 - 用正確密碼可以登錄說(shuō)明接口和 JWT 簽發(fā)邏輯基本正常 - 確認(rèn)數(shù)據(jù)庫(kù)連接正常 目標(biāo)定位密碼校驗(yàn)失敗的具體原因輸出修復(fù)后的代碼 diff 和原理說(shuō)明注意看這個(gè)模板的結(jié)構(gòu)任務(wù)目標(biāo)、涉及文件路徑及每文件的作用、報(bào)錯(cuò)原文、已嘗試過(guò)的方向、期望輸出。它能用的原因在于它把模型需要“腦補(bǔ)”的空間壓縮到了最小同時(shí)給出了足夠強(qiáng)的檢索信號(hào)。我還發(fā)現(xiàn)一個(gè)小細(xì)節(jié)當(dāng)你列出“已嘗試的方法”時(shí)模型會(huì)明顯減少重復(fù)建議回復(fù)會(huì)更聚焦到剩余的可能性上。這本質(zhì)上是在給模型的推理過(guò)程劃定上下文邊界。4.3 讓 AI 自己總結(jié)上下文長(zhǎng)對(duì)話的接力技術(shù)上下文管理還有一個(gè)更隱蔽的問(wèn)題同一個(gè)任務(wù)在聊天窗口里聊了很久新開窗口時(shí)之前的內(nèi)容全丟了。重新粘貼一遍所有信息不僅累還容易漏。我的做法是把“總結(jié)”作為對(duì)話的一部分而不是事后的工作。在長(zhǎng)時(shí)間任務(wù)的關(guān)鍵節(jié)點(diǎn)我會(huì)讓 AI 生成一份“當(dāng)前狀態(tài)確認(rèn)”請(qǐng)基于我們剛才的討論輸出一份簡(jiǎn)短的上下文交接文檔 1. 當(dāng)前要解決的問(wèn)題 2. 已經(jīng)確定的方案 3. 已修改的文件和修改要點(diǎn) 4. 尚未解決的問(wèn)題 5. 下一步建議動(dòng)作 用清單形式控制在一屏以內(nèi)。這樣獲得的狀態(tài)文檔可以直接粘貼給新對(duì)話也讓自己的 NOTES.md 有了可復(fù)制的來(lái)源。每次開新對(duì)話時(shí)先粘貼這段狀態(tài)再繼續(xù)提問(wèn)效果接近無(wú)縫銜接。另外我強(qiáng)烈建議在項(xiàng)目根目錄維護(hù)一個(gè)AGENTS.md或CLAUDE.md文件用來(lái)記錄項(xiàng)目級(jí)的長(zhǎng)期上下文技術(shù)棧、目錄結(jié)構(gòu)、啟動(dòng)命令、代碼風(fēng)格約束。把這種穩(wěn)定信息寫入文件臨時(shí)對(duì)話時(shí)就不用反復(fù)粘貼它們。短期上下文靠模板長(zhǎng)期上下文靠文件兩者配合AI 輔助編程的體驗(yàn)會(huì)穩(wěn)定很多。5. 落地過(guò)程中踩過(guò)的坑與最終的簡(jiǎn)化版本5.1 坑一方案太重裝完就不想用一開始我構(gòu)建這套東西時(shí)犯了個(gè)典型錯(cuò)誤——追求“完整”而不是“好用”。我給 tmux 加了 statusline 插件給 Neovim 配了自動(dòng) session 選擇器寫了一個(gè)支持參數(shù)解析的巨型.bashrc腳本甚至計(jì)劃把瀏覽器標(biāo)簽頁(yè)也用插件統(tǒng)一管理。結(jié)果呢搭建用了整整兩天第三周就開始覺(jué)得維護(hù)成本太高腳本報(bào)錯(cuò)不知道改哪插件升級(jí)后又出現(xiàn)兼容問(wèn)題最后連ctx-new這個(gè)命令都懶得用了。后來(lái)我把大量自定義腳本砍掉只保留 tmux 原生命令、direnv、編輯器插件和極簡(jiǎn)的兩個(gè) shell 函數(shù)。真正留下來(lái)被高頻使用的是那些“一眼看得懂、壞了不用修”的東西。自動(dòng)化本身是有成本的每個(gè)自定義腳本都意味著未來(lái)的維護(hù)負(fù)擔(dān)在真正常駐工作流之前盡量先用現(xiàn)成方案。5.2 坑二上下文筆記寫成了流水賬我一度認(rèn)為筆記記得越多越安全于是變成了每半小時(shí)記錄一次。結(jié)果是 NOTES.md 長(zhǎng)得像工作日志列了一堆已完成操作卻找不到一句明確的“下一步”。切換回來(lái)時(shí)看這種筆記等于重新讀一遍歷史根本沒(méi)有起到快速恢復(fù)的作用。后來(lái)我給 NOTES.md 設(shè)了硬限制只保留模板里的五個(gè)字段Progress 出現(xiàn)超過(guò)十條就必須清理合并每次更新只允許在 Next Step 上花最多五分鐘思考。這個(gè)約束逼著我提煉真正關(guān)鍵的信息而不是把所有動(dòng)作都囤積在文件里。筆記的價(jià)值不在厚而在“能讓人在三十秒內(nèi)做出繼續(xù)行動(dòng)的決定”。5.3 坑三只存上下文不設(shè)恢復(fù)檢查點(diǎn)我早期做了ctx-save卻沒(méi)做對(duì)應(yīng)的恢復(fù)動(dòng)作。剛開始挺得意覺(jué)得有個(gè)快照總比沒(méi)有強(qiáng)。結(jié)果真實(shí)場(chǎng)景中我切回來(lái)時(shí)經(jīng)常忘記執(zhí)行ctx-load或者執(zhí)行后發(fā)現(xiàn)快照是兩天前的根本沒(méi)有恢復(fù)到最新的狀態(tài)?？煺杖绻辉凇扒谢厝蝿?wù)”的那一刻被使用就只是一串靜默躺在磁盤上的文字。這也是為什么我現(xiàn)在把 save 和 load 設(shè)計(jì)成一對(duì)并且要求“長(zhǎng)時(shí)間離開前必須 save回來(lái)后必須先 load”。load 不僅僅是打印內(nèi)容更是一個(gè)儀式感動(dòng)作它強(qiáng)迫你接收“任務(wù)已恢復(fù)可以繼續(xù)”的心理信號(hào)。沒(méi)有檢查點(diǎn)的上下文管理等于沒(méi)有存檔的游戲——你保存了但讀取的入口不在手邊最終還是會(huì)被打回原形。5.4 我最后留下的最小閉環(huán)折騰一圈后真正長(zhǎng)期在用的其實(shí)是一套非常樸素的最小閉環(huán)一個(gè) tmux session 對(duì)應(yīng)一個(gè)項(xiàng)目關(guān)掉終端也不影響現(xiàn)場(chǎng)每個(gè)任務(wù)分支都有一個(gè).ctx/NOTES.md只記目標(biāo)、驗(yàn)收、卡點(diǎn)、下一步給 AI 提問(wèn)前套用固定模板打包必要上下文長(zhǎng)任務(wù)用 AI 生成的“狀態(tài)確認(rèn)”做交接長(zhǎng)時(shí)間離開任務(wù)前執(zhí)行 ctx-save回來(lái)后先 ctx-load 再動(dòng)手這套東西加起來(lái)搭建時(shí)間不到半小時(shí)并且大部分依賴都是現(xiàn)成工具壞了隨時(shí)能重來(lái)。它不華麗但足夠穩(wěn)。如果你也想搭一套屬于自己的 context-mode我的建議是別從我的完整配置抄起。先只做一件事給當(dāng)前正在進(jìn)行的任務(wù)建一個(gè).ctx/NOTES.md把目標(biāo)和下一步寫進(jìn)去。等這個(gè)習(xí)慣穩(wěn)固了再去加 tmux 會(huì)話、再加編輯器恢復(fù)、再加 AI 上下文模板。上下文管理這種東西最貴的從來(lái)不是技術(shù)實(shí)現(xiàn)而是你愿不愿意在每個(gè)“切換點(diǎn)”上多花十秒鐘給未來(lái)的自己留一條回來(lái)的路。