我先說個結(jié)論用了這么久的AI編程助手大部分“AI寫得不對”的問題根子根本不在模型智商而在“context-mode”也就是上下文模式。這個詞在國內(nèi)討論還真不多但我覺得它才是決定AI寫代碼質(zhì)量的最關(guān)鍵一環(huán)——沒有之一。它解決的是“AI怎么知道你當(dāng)前真正在想什么、改什么、項(xiàng)目里有哪些約束”的問題。如果你正準(zhǔn)備把AI塞進(jìn)日常開發(fā)流程或者已經(jīng)用過但總覺得效果飄忽不定這篇就專門掰開揉碎講上下文模式。1. 上下文模式到底是干什么的為什么它決定AI輸出質(zhì)量1.1 一個被嚴(yán)重低估的工程質(zhì)量杠桿很多人把AI編程助手當(dāng)成“高級補(bǔ)全工具”覺得只要把問題問得夠清楚AI就能給出完美代碼。實(shí)際用過的人都知道完全不是這么回事。AI的每次生成本質(zhì)上都是“基于當(dāng)前給它看到的所有信息做一次概率預(yù)測”。它能看到什么、看不到什么完全由上下文模式?jīng)Q定。同樣一句“幫我加個緩存”在只有當(dāng)前文件上下文和擁有整個項(xiàng)目的調(diào)用鏈、數(shù)據(jù)模型、歷史改動記錄這兩種模式下產(chǎn)出代碼的差距可以大到像兩個不同水平的人寫的。我見過不少團(tuán)隊(duì)興致勃勃引入AI輔助開發(fā)結(jié)果發(fā)現(xiàn)AI生成的代碼經(jīng)常跟現(xiàn)有架構(gòu)打架明明項(xiàng)目里統(tǒng)一用某個工具函數(shù)處理時間AI卻自己new了一個Date格式化明明數(shù)據(jù)庫表結(jié)構(gòu)里字段叫user_nameAI卻按userName來寫查詢。這些問題的元兇都不是提示詞寫得不好而是上下文模式?jīng)]有把項(xiàng)目里已有的“約定俗成”喂給AI。上下文模式的核心任務(wù)就是解決“AI的臨時記憶該裝什么”這個問題。它決定了哪些文件內(nèi)容會進(jìn)入AI的視野哪些歷史對話會被保留哪些倉庫掃描結(jié)果會被當(dāng)作約束條件。理解了這個你才算真正邁過了“會用AI寫代碼”和“用好AI寫代碼”之間的分水嶺。1.2 上下文就是AI的工作記憶類比一下就懂了把上下文模式想象成給一個記憶力超強(qiáng)但“只看眼前”的實(shí)習(xí)生分配任務(wù)。這個實(shí)習(xí)生智商很高但有個特點(diǎn)你給他看什么材料他就基于什么材料干活。你要是只甩給他一個文件他就盯著這一個文件發(fā)揮你要是把整個項(xiàng)目文檔、代碼規(guī)范、相關(guān)模塊的源碼都擺在他面前他就能寫出跟團(tuán)隊(duì)風(fēng)格一致的代碼。人跟人協(xié)作時很多背景知識是不用說的——大家都默認(rèn)知道項(xiàng)目分層是什么樣、命名規(guī)范是什么、線上環(huán)境有什么限制。但AI沒有這種“默認(rèn)”。它唯一的了解渠道就是上下文模式給它的信息。這就是為什么很多人覺得AI寫的代碼“一股機(jī)味”不像團(tuán)隊(duì)自己人寫的——因?yàn)樯舷挛哪Ｊ綁焊鶝]把團(tuán)隊(duì)的技術(shù)債、風(fēng)格偏好轉(zhuǎn)達(dá)給AI。在具體技術(shù)層面上下文模式涉及一個核心指標(biāo)上下文窗口。這是AI單次能處理的最大信息量你可以理解為工作臺上的最大面積。窗口是有限的但項(xiàng)目代碼是無限的。上下文模式要做的就是在有限的窗口里塞進(jìn)最值得看的內(nèi)容。這本身就是一道做減法的工程題。2. 上下文模式的主要形態(tài)與選型思路2.1 按作用范圍劃分單文件、多文件與全倉庫上下文模式在實(shí)際工具里通常體現(xiàn)為不同的作用范圍。最基礎(chǔ)的是單文件模式AI只能看到你當(dāng)前打開的那個文件頂多再加上你粘貼到對話框里的代碼。這種模式輕量、反應(yīng)快適合問一些孤立的小問題比如“這個函數(shù)為什么報錯”“幫我給這段代碼加注釋”。但它的上限也很明顯一旦問題牽扯到別的文件里的定義或調(diào)用AI就只能靠猜了。往上一個層級是多文件模式你可以手動把相關(guān)文件添加進(jìn)上下文AI會同時看到這些文件的內(nèi)容。這個模式是目前我覺得性價比最高的形態(tài)因?yàn)樗尅澳恪眮頉Q定看什么而不是讓工具盲目掃描。比如改一個接口我就把接口定義文件、實(shí)現(xiàn)文件、調(diào)用方的代碼一起加進(jìn)上下文AI就能理解改動的牽連面。再往上就是全倉庫模式工具會建立索引AI可以按需檢索整個代碼庫里的相關(guān)內(nèi)容。這種模式聽起來很美實(shí)際用起來卻要留個心眼。倉庫一大檢索結(jié)果五花八門AI經(jīng)常會把不相關(guān)的模塊也作為參考反而產(chǎn)生信息污染。全倉庫模式適合跨模塊排查問題或新人理解老項(xiàng)目架構(gòu)但日常改BUG時未必比定向添加幾個文件效果更好。2.2 按信息獲取方式劃分顯式指定、自動掃描與對話記憶除了范圍上下文模式還有一個維度是獲取方式。顯式指定最直接就是你告訴AI“去看哪個文件、關(guān)注哪個部分”。這種方式的最大優(yōu)點(diǎn)是完全可控信息是精確的不會有多余干擾。缺點(diǎn)是費(fèi)手每次都要手動維護(hù)一份“材料清單”。自動掃描則是工具通過監(jiān)聽文件變更、Git改動記錄自動把相關(guān)文件塞進(jìn)上下文。比如你改了A文件工具自動把引用A的B文件也加進(jìn)來。這個模式省心但偶爾會好心辦壞事比如自動加進(jìn)來的文件過多導(dǎo)致上下文被無關(guān)內(nèi)容占滿反而擠掉了真正重要的信息。我傾向于把自動掃描當(dāng)成“輔助”而不是“全權(quán)代理”。對話記憶則是另一種容易被忽略的上下文形態(tài)。它指的是AI能記住你們之前聊過什么、你糾正過它什么。有些上下文模式開啟長對話記憶后AI會沿用之前幾輪對話里的偏好和修正比如你說過“不要用可選鏈”之后它再生成代碼時就會避開這種寫法。這是把協(xié)作經(jīng)驗(yàn)沉淀下來的機(jī)制非常值得長期用。2.3 選擇上下文模式的三個判斷標(biāo)準(zhǔn)選哪種模式我最看重三個標(biāo)準(zhǔn)。第一是相關(guān)性密度也就是單位上下文里有多少信息真正有用。單文件模式的相關(guān)性密度最高但覆蓋不足全倉庫模式覆蓋足但密度會被稀釋。第二是維護(hù)成本手動指定雖然準(zhǔn)但每次任務(wù)都手動配置也很煩需要權(quán)衡。第三是反饋閉環(huán)也就是AI能不能知道自己上次哪里錯了并糾正對話記憶在這里起主要作用。有一個粗糙的經(jīng)驗(yàn)法則任務(wù)越聚焦上下文范圍越要小任務(wù)越開放才需要動用更大的索引范圍。改一個函數(shù)三步之內(nèi)的調(diào)用關(guān)系用多文件手動指定就夠排查一個偶發(fā)的線上異常才值得讓AI去全倉庫里搜線索。明確任務(wù)邊界再倒推需要多大的上下文范圍這比盲目追求“看得越多越好”要實(shí)用得多。3. 實(shí)操階段配置上下文模式的關(guān)鍵步驟與參數(shù)3.1 建立項(xiàng)目級代碼索引的正確姿勢不管用哪種上下文模式第一步都應(yīng)該是把項(xiàng)目的關(guān)鍵信息結(jié)構(gòu)化地喂給AI。我在實(shí)操中會先在項(xiàng)目根目錄維護(hù)一份AGENTS.md這樣的說明文件把項(xiàng)目的技術(shù)棧、目錄結(jié)構(gòu)、命名規(guī)范、特殊約束寫進(jìn)去然后讓上下文模式把這份文件作為“永久啟動項(xiàng)”。這么做的好處是AI在每次會話開始時就先讀這份文件就像給實(shí)習(xí)生一份入職手冊后面再讓它干活它的行為就會明顯更貼合團(tuán)隊(duì)習(xí)慣。配置這個說明文件有幾個要點(diǎn)。一是要寫“禁止項(xiàng)”而不僅僅是“要做什么”。比如“不要修改 xxx 模塊的接口定義”“不允許在業(yè)務(wù)代碼里直接操作原生SQL”這種負(fù)面清單對AI糾偏的效果特別顯著。二是要描述目錄職責(zé)而不是貼目錄列表。直接貼整個目錄樹意義不大AI記不住也理解不了但寫明“src/services 放業(yè)務(wù)編排層src/repos 放數(shù)據(jù)訪問層跨層調(diào)用一律走 services”就能讓AI生成新文件時選對位置。其次是配置文件里通常需要設(shè)置忽略列表。有些工具支持類似context.ignore的配置把 node_modules、構(gòu)建產(chǎn)物目錄、鎖文件排除在上下文掃描之外。這一步看著不起眼實(shí)際對上下文質(zhì)量的提升非常明顯。因?yàn)橐蕾嚹夸浝锏奈募虞m成千上萬如果不排除AI進(jìn)行全倉庫模式掃描時會被海量無關(guān)代碼淹沒檢索相關(guān)性的精度會斷崖式下降。3.2 控制上下文規(guī)模窗口占用與優(yōu)先級管理上下文窗口是所有上下文模式的硬約束所以掌握基本的占用估算很重要。一個粗略的換算經(jīng)驗(yàn)是1個英文字符約占1個token左右1個中文字符約占1.5到2個token。一個300行左右的源碼文件大概會占用掉 2000 到 3000 個token。主流工具的上下文窗口常見在數(shù)萬到十幾萬token之間聽起來很大但如果你一次性把整個項(xiàng)目的二十個核心文件都加進(jìn)去窗口很快就會報警。所以我會給上下文里的文件排優(yōu)先級。第一優(yōu)先級是當(dāng)前正在修改的文件本身第二是它直接依賴的接口、類型定義、Schema第三是調(diào)用方的代碼用來確認(rèn)改動不破壞外部契約第四才是項(xiàng)目級規(guī)范說明文件。按這個優(yōu)先級順序添加文件就算窗口再緊張也能保證最關(guān)鍵的約束信息都在。有一類工具會把上下文按“會話內(nèi)文件列表”展示出來我強(qiáng)烈建議你每次開會話時養(yǎng)成檢查這個列表的習(xí)慣。看看里面是不是混進(jìn)了過期文件、無關(guān)模塊及時做清理。很多AI輸出質(zhì)量不穩(wěn)定的問題其實(shí)就藏在那些你沒注意到的多余上下文里。3.3 典型場景的上下文配置示例我舉一個真實(shí)的例子某次要給一個結(jié)算模塊增加新的計費(fèi)規(guī)則。這個任務(wù)橫跨數(shù)據(jù)模型、業(yè)務(wù)服務(wù)、對外接口三個層面。我沒有直接開啟全倉庫模式而是手動指定了這幾個文件計費(fèi)規(guī)則的表結(jié)構(gòu)遷移文件、結(jié)算服務(wù)的核心實(shí)現(xiàn)、對外暴露的REST接口定義、項(xiàng)目根目錄的架構(gòu)說明文件。四個文件加上當(dāng)前會話上下文總量控制得很舒服AI生成的代碼不但符合表結(jié)構(gòu)字段命名還自動遵循了服務(wù)層已有的事務(wù)邊界寫法。另一個典型場景是排查編譯報錯。這種任務(wù)最好用單文件模式起步先把報錯文件丟給AI讓它解釋錯誤原因。如果它提到某個外部符號或依賴再按需把那部分代碼加進(jìn)上下文。這樣做的好處是鏈路短、反饋快不會在排查初期就被大量無關(guān)文件干擾判斷。排查類任務(wù)講究的是“沿著線索逐步展開”不是一張信息大網(wǎng)撒下去這點(diǎn)跟開發(fā)類任務(wù)的上下文策略有很大區(qū)別。4. 上下文模式的常見問題與排查技巧4.1 上下文被無關(guān)文件污染AI反而變笨很多人在從單文件模式切換到多文件或全倉庫模式后發(fā)現(xiàn)自己IDE里的AI反而開始亂寫。最典型的表現(xiàn)是AI引用了不該引用的工具類或者融合了多個模塊的不同風(fēng)格生成出一段四不像代碼。原因幾乎可以斷定是上下文里塞進(jìn)了大量相關(guān)性弱的文件把真正關(guān)鍵的信息擠到邊緣去了。排查方法是先清空上下文然后按我前面說的優(yōu)先級順序重新一個個添加文件。每次添加完一個文件都觀察AI在后續(xù)任務(wù)里的行為是否更準(zhǔn)。如果添加某個文件后反而開始出現(xiàn)錯誤傾向說明這個文件本身就是干擾源應(yīng)該剔除。這種“控制變量法”排查上下文污染效率遠(yuǎn)高于盲目清空重開。4.2 上下文過期文件更新了AI還在用舊邏輯另一個高頻坑是上下文里的內(nèi)容跟磁盤上的實(shí)際代碼不一致。比如你改了某個函數(shù)簽名但上下文是靠啟動會話時的快照建立的AI對話時用的還是舊簽名于是生成的調(diào)用代碼全部對不上。這在我早期使用自動掃描模式時踩過好多次后來養(yǎng)成了習(xí)慣每次大幅度改動文件后要么手動刷新上下文要么干脆重開會話。如果使用的工具支持“基于Git變更同步上下文”我會優(yōu)先開啟并且確保每次提交前帶著新改動開會話。還要特別留意一個場景代碼里存在被注釋掉的舊邏輯塊。AI默認(rèn)會把這些注釋內(nèi)容當(dāng)作有效信息學(xué)習(xí)如果你在重構(gòu)期間保留了大量歷史注釋代碼AI參考到它們后很容易輸出過時代碼。遇到這種情況我會在上下文說明文件里加一句“忽略所有被注釋的舊實(shí)現(xiàn)”讓AI從源頭上避開這些干擾。4.3 上下文不足AI開始憑空發(fā)明接口和污染對應(yīng)的是另一種情況上下文相關(guān)文件沒加夠AI只能用訓(xùn)練記憶里的“常見套路”來填空。比如你項(xiàng)目里明明有個封裝好的冪等工具但上下文里沒提AI根本不知道它的存在就自己用Redis手寫了一套。這種行為最難排查因?yàn)锳I生成的代碼看起來能跑但和項(xiàng)目里已有的能力重復(fù)屬于隱性技術(shù)債。這種問題的解決辦法不是把整個項(xiàng)目的文件都塞進(jìn)上下文而是在項(xiàng)目的AGENTS.md里明確羅列“能力清單”。把項(xiàng)目里已經(jīng)封裝好的公共能力比如緩存工具、冪等組件、統(tǒng)一異常處理、日志工具逐條寫明白標(biāo)注“已存在不要重復(fù)實(shí)現(xiàn)”。AI只要讀到這些就會優(yōu)先復(fù)用而不是重新發(fā)明。這個技巧對降低AI生成代碼與現(xiàn)有架構(gòu)的沖突非常有效實(shí)操中強(qiáng)烈建議落實(shí)。4.4 上下文模式常見問題速查表現(xiàn)象根因處理方式AI總引用不存在的API依賴方代碼未進(jìn)上下文添加被調(diào)用模塊的入口文件輸出風(fēng)格與項(xiàng)目不一致規(guī)范說明文件缺失建立并掛載AGENTS.md規(guī)范全倉庫模式下答非所問掃描范圍過大壓縮忽略列表或改多文件模式改了文件但AI還在用舊代碼上下文快照過期手動刷新上下文或重開會話上下文窗口頻繁報滿單次添加文件過多按優(yōu)先級刪減只留關(guān)鍵文件AI重復(fù)造輪子已有能力未告知在規(guī)范文件寫明現(xiàn)有組件清單5. 我自己的使用習(xí)慣與后續(xù)擴(kuò)展方向5.1 日常開發(fā)中已經(jīng)固化的上下文鐵律用久了之后我給自己總結(jié)了幾條關(guān)于上下文模式的鐵律。第一條是“開工前必寫規(guī)范”不管項(xiàng)目多小我都會花十分鐘給AI準(zhǔn)備一份項(xiàng)目速覽這筆投資的回報率高得驚人。第二條是“會話按任務(wù)開不按時間開”一個會話只圍繞一個明確任務(wù)任務(wù)完成就開新會話避免舊對話記憶干擾新方向。第三條是“上下文寧缺毋濫”只在AI明確表示“少了信息”時才追加文件絕不提前把整倉代碼都喂進(jìn)去。這幾條習(xí)慣看上去不起眼但它們直接決定了我和AI協(xié)作的效率。我身邊不少同事也配置了頂級的AI工具但產(chǎn)出質(zhì)量的差距很大細(xì)聊下來幾乎都是上下文管理習(xí)慣的差距而不是工具本身。一個會管理上下文的人哪怕用一個基礎(chǔ)模型也能寫出符合項(xiàng)目約束的代碼一個不會管理上下文的人就算模型再強(qiáng)也只能得到一堆“正確但沒用”的答案。5.2 這個方向還可以怎么深入上下文模式這個方向目前能玩的點(diǎn)其實(shí)還很多。一個是把上下文模式跟項(xiàng)目沉淀結(jié)合起來比如把多個歷史會話里AI犯過的錯誤整理成一條條“團(tuán)隊(duì)避坑規(guī)范”持續(xù)回灌到規(guī)范文件里讓后邊的會話越來越懂你們團(tuán)隊(duì)。另一個是利用工具的指令模板功能把“代碼審查”“性能優(yōu)化”“寫單元測試”這些高頻任務(wù)的上下文范圍固化下來每次調(diào)用直接復(fù)用不用重新配置。我覺得后續(xù)更值得關(guān)注的是上下文管理的自動化程度比如按文件依賴圖自動計算關(guān)鍵路徑、自動識別過期內(nèi)容并標(biāo)記這些能力會讓上下文模式從“手動調(diào)教”進(jìn)化為“智能編排”。不過在那之前先把基礎(chǔ)的手動管理做扎實(shí)一定是穩(wěn)賺不賠的投入。我自己的下一步是把規(guī)范文件按模塊拆分讓AI拿到任務(wù)時只加載對應(yīng)模塊的規(guī)范進(jìn)一步降低上下文噪音這也是我對context-mode這個方向最期待的部分。