寫代碼的時(shí)候最讓人血壓升高的事往往不是需求改了三版而是你滿心期待地讓AI助手改一個(gè)函數(shù)它卻把整個(gè)模塊的命名風(fēng)格都給你順手重構(gòu)了。我最初被context-mode這個(gè)詞擊中就是因?yàn)檫@類事故接二連三地發(fā)生。后來才意識(shí)到問題不在模型不夠聰明而在上下文沒管好。這里說的context-mode不是某個(gè)產(chǎn)品的專有名詞而是現(xiàn)在主流AI編程工具——Cursor、Copilot、JetBrains AI Assistant、甚至各種套殼IDE——里都在用的上下文模式與上下文管理機(jī)制。這篇文章不打算講什么抽象概念就聊聊我對(duì)這個(gè)模式的完整理解包括它是怎么工作的、有哪些形態(tài)、實(shí)操中怎么用、以及我踩過的一堆坑。1. 為什么說context-mode是AI寫代碼的命門1.1 一次現(xiàn)場(chǎng)還原當(dāng)AI忘了你五分鐘前的要求先還原一個(gè)典型場(chǎng)景。早上我剛打開項(xiàng)目準(zhǔn)備改一個(gè)用戶權(quán)限校驗(yàn)的邏輯。我告訴AI助手把getUserInfo里的超時(shí)重試邏輯抽出來單獨(dú)做一個(gè)retryWithTimeout函數(shù)注意保持返回結(jié)構(gòu)不變。AI回了一句好的然后開始輸出代碼。我以為這就完了繼續(xù)往對(duì)話框里扔需求再把調(diào)用方全部替換成新函數(shù)名。結(jié)果AI突然開始大段大段地輸出跟超時(shí)重試毫無關(guān)系的代碼甚至想把整個(gè)service層重寫一遍。我翻看對(duì)話記錄才知道它在處理第二個(gè)請(qǐng)求時(shí)自動(dòng)帶上了編輯器左側(cè)打開的五個(gè)文件其中三個(gè)跟權(quán)限校驗(yàn)完全無關(guān)。這就是context-mode失控的典型癥狀工具替你選了太多上下文。我自己調(diào)試這類問題的經(jīng)驗(yàn)是先看AI到底看到了什么。現(xiàn)在大多數(shù)AI編程工具都提供一個(gè)已引用文件或者上下文面板的入口展開之后能看到它把哪些內(nèi)容喂給了模型。那次事故里它把日志工具、路由配置、測(cè)試快照全塞進(jìn)去了。模型沒有能力在幾十個(gè)不相關(guān)文件里精準(zhǔn)鎖定你要改的那一處更糟糕的是它需要同時(shí)處理這些文件帶來的token開銷和噪聲干擾。1.2 上下文窗口不是無限的有人會(huì)覺得現(xiàn)在的模型動(dòng)輒128K、200K上下文窗口塞幾個(gè)文件進(jìn)去算什么。但這里有個(gè)很現(xiàn)實(shí)的誤解窗口大不等于有效信息多。先說一個(gè)簡(jiǎn)單的換算。128K token的上下文窗口大約能容納8到10萬英文單詞中文大約十幾萬字符。聽起來很多但一個(gè)中大型項(xiàng)目的核心文件加起來很容易超過這個(gè)量。更關(guān)鍵的是當(dāng)上下文里塞入大量與當(dāng)前任務(wù)無關(guān)的內(nèi)容時(shí)模型需要在這些噪聲中檢索有用信息注意力機(jī)制會(huì)被稀釋。我在實(shí)踐中觀察到一旦無關(guān)內(nèi)容占比超過某條線回答質(zhì)量會(huì)斷崖式下跌表現(xiàn)出來就是答非所問、邏輯自相矛盾、甚至虛構(gòu)不存在的函數(shù)。這就好比你讓一個(gè)程序員在一個(gè)1000平米的倉(cāng)庫里找一個(gè)螺絲釘你給了他一整個(gè)倉(cāng)庫的燈光卻忘了告訴他螺絲釘在哪一排貨架。燈越亮反而找得越難。1.3 context-mode的本質(zhì)采集、篩選、注入把context-mode拆開看它其實(shí)干的是三件事采集、篩選、注入。采集是決定哪些內(nèi)容能進(jìn)入候選區(qū)。有的工具自動(dòng)讀取當(dāng)前打開文件、最近的diff、工作區(qū)診斷信息有的要求你手動(dòng)通過符號(hào)或者#符號(hào)引用文件。篩選是決定這些內(nèi)容里哪一部分真正進(jìn)入提示詞。有的工具會(huì)壓縮代碼注釋、去掉空行有的會(huì)按相似度做語義檢索還有的會(huì)直接截?cái)?。注入是決定這些內(nèi)容以什么順序、什么角色出現(xiàn)在提示詞里。比如項(xiàng)目說明文件通常會(huì)放在最前面作為全局約束當(dāng)前要修改的代碼塊放中間用戶指令放最后。我剛開始用AI編程工具時(shí)完全沒關(guān)注這三件事以為它倆是同一個(gè)概念。后來發(fā)現(xiàn)很多工具里自動(dòng)上下文和手動(dòng)上下文是兩條完全不同的路徑。自動(dòng)路徑適合快速問答手動(dòng)路徑適合精確修改。搞不懂這個(gè)區(qū)分就很容易出現(xiàn)第一種事故。2. context-mode的三種工作形態(tài)從選中一段代碼到感知整個(gè)項(xiàng)目編者注稿件寫到這里時(shí)我仔細(xì)回想了自己用過的工具發(fā)現(xiàn)不同產(chǎn)品的context-mode實(shí)現(xiàn)路徑有差異但大致可以歸成三個(gè)層級(jí)。2.1 選區(qū)級(jí)上下文指哪打哪最基礎(chǔ)也最可靠的形態(tài)是選區(qū)級(jí)上下文。你在編輯器里高亮一段代碼然后對(duì)AI說幫我解釋這段邏輯或重構(gòu)這里工具默認(rèn)只把高亮部分帶上。這種形態(tài)的優(yōu)點(diǎn)是幾乎沒有誤傷。代價(jià)是AI的視野極其狹窄它看不到調(diào)用方、看不到相關(guān)依賴甚至看不到你引用的外部函數(shù)從哪來。我通常只在三種情況下用選區(qū)級(jí)一是快速解釋一段自己不熟悉的代碼二是讓AI單獨(dú)優(yōu)化一個(gè)函數(shù)體的內(nèi)部實(shí)現(xiàn)三是在代碼評(píng)審時(shí)讓它審視一小段邏輯是否有邊界問題。有個(gè)細(xì)節(jié)值得注意選區(qū)級(jí)上下文的邊界你自己要清楚。如果你在一個(gè)函數(shù)里選中了五行然后問AI這個(gè)函數(shù)有沒有并發(fā)問題它其實(shí)連這個(gè)函數(shù)完整實(shí)現(xiàn)都看不到會(huì)給出非常不負(fù)責(zé)任的回答。選區(qū)的范圍必須跟問題匹配這是使用者自己的責(zé)任。2.2 文件級(jí)上下文默認(rèn)的主力形態(tài)文件級(jí)上下文是目前默認(rèn)的主力形態(tài)。在當(dāng)前編輯器里打開的某個(gè)文件、通過或#顯式引用的文件都會(huì)被作為完整文件注入。這個(gè)形態(tài)比選區(qū)級(jí)好用得多但也潛藏一個(gè)容易被忽略的問題很多工具會(huì)把打開的文件和引用的文件混在一起處理。如果你是一次性打開十來個(gè)文件工作的類型AI拿到手的上下文就是一把亂牌。我現(xiàn)在的習(xí)慣是把與本次任務(wù)無關(guān)的文件全部關(guān)掉只保留要改的文件和被改文件的上游依賴。這樣一來即使不看上下文面板我也能大概猜到AI眼前是什么。文件級(jí)上下文還有一種情況是自動(dòng)附著。有些工具在你切換當(dāng)前文件時(shí)會(huì)自動(dòng)把新文件加入上下文。這個(gè)功能有時(shí)候很貼心意但它會(huì)把上下文內(nèi)容不斷累積導(dǎo)致越到后面AI越糊涂。我建議對(duì)這種行為保持警惕定期清理一下引用列表。2.3 項(xiàng)目級(jí)上下文最華麗的陷阱項(xiàng)目級(jí)上下文是目前最吸引人也最考驗(yàn)人的形態(tài)。工具會(huì)掃描整個(gè)倉(cāng)庫建立一個(gè)索引然后在你提問時(shí)通過語義檢索自動(dòng)召回相關(guān)文件片段。Cursor里的Codebase、Copilot里的工作區(qū)檢索都屬于這個(gè)范疇。項(xiàng)目級(jí)上下文看起來最強(qiáng)實(shí)際用起來最需要節(jié)制。我在2.2節(jié)提過注意力稀釋的問題在項(xiàng)目級(jí)形態(tài)下會(huì)格外嚴(yán)重。當(dāng)模型檢索到大量倉(cāng)庫片段并全部放入窗口時(shí)它很難判斷哪些片段是核心約束、哪些片段只是相關(guān)背景。更麻煩的是檢索本身是有誤差的它可能召回一個(gè)寫得很相似的舊版實(shí)現(xiàn)而你實(shí)際要改的是新版。所以我的建議是項(xiàng)目級(jí)上下文適合用來找答案——比如你不知道某個(gè)配置在哪里生效、某個(gè)常量在哪些地方被引用——但不適合用來動(dòng)手改。真正要?jiǎng)哟a的時(shí)候切回文件級(jí)上下文把關(guān)鍵文件明確引用進(jìn)去效果會(huì)穩(wěn)定得多。2.4 三種形態(tài)的對(duì)比與選擇我用一個(gè)表總結(jié)平時(shí)的選擇邏輯上下文形態(tài)典型使用場(chǎng)景主要風(fēng)險(xiǎn)我的選擇優(yōu)先級(jí)選區(qū)級(jí)解釋代碼、小范圍重構(gòu)、單函數(shù)評(píng)審視野太窄容易誤判全局高但需確保選區(qū)匹配問題規(guī)模文件級(jí)修改具體功能、跨文件聯(lián)調(diào)、接口對(duì)接引用了無關(guān)文件造成噪聲最高日常主力項(xiàng)目級(jí)搜索代碼、探索系統(tǒng)、定位問題根源召回誤差、上下文爆炸低僅用于查證不用于修改這個(gè)順序不是絕對(duì)的。工具能力、項(xiàng)目規(guī)模、任務(wù)類型都會(huì)影響最終選擇。但核心原則不變給AI的上下文要精準(zhǔn)匹配任務(wù)寧缺毋濫。3. 實(shí)操筆記把上下文塞得精準(zhǔn)又干凈3.1 用引用指令把文件釘進(jìn)對(duì)話先講最基礎(chǔ)的實(shí)操如何把文件手動(dòng)引用進(jìn)對(duì)話。在Cursor里輸入框直接輸入文件名或者點(diǎn)擊輸入框下方的附件圖標(biāo)選擇文件。在VS Code用Copilot Chat時(shí)輸入#文件名可以加入當(dāng)前工作區(qū)文件輸入#editor可以附上當(dāng)前打開的編輯器內(nèi)容。JetBrains的AI Assistant則通常通過輸入框旁邊的文件選擇器完成。我有一個(gè)小習(xí)慣凡是涉及跨文件的修改我會(huì)先把所有涉及文件用引用指令釘進(jìn)對(duì)話然后才開始寫需求。這樣做的目的是防止自己在寫了一大段需求之后發(fā)現(xiàn)AI還在用舊視野理解問題。你可以把這一步理解為在開會(huì)前先把參會(huì)人拉進(jìn)群而不是等會(huì)議開到一半才有人推門進(jìn)來。引用指令還有一個(gè)好處是它提供了顯式的順序。AI對(duì)上下文的注意程度并不是均勻的通常越靠后的內(nèi)容越會(huì)被重視。如果你的核心需求比較復(fù)雜可以把它放在引用文件之后、其余說明之前這樣模型在生成答案時(shí)最近約束和最重要約束都會(huì)處在比較容易生效的位置。3.2 自動(dòng)跟蹤模式的正確打開方式很多AI編輯工具里有一個(gè)跟蹤模式或者自動(dòng)跟隨的開關(guān)名字五花八門但做的事差不多當(dāng)你切換當(dāng)前編輯的文件或光標(biāo)位置時(shí)工具自動(dòng)把當(dāng)前文件加入上下文。一開始我覺得這個(gè)功能很方便直到有一次我一邊瀏覽多個(gè)文件一邊和AI聊天AI給的建議越來越混亂。回頭看上下文面板發(fā)現(xiàn)它把十幾分鐘里我點(diǎn)開過的十來個(gè)文件全附上了。我的做法是把自動(dòng)跟蹤模式的使用范圍收窄只在需要AI持續(xù)參考當(dāng)前文件的任務(wù)里打開。比如你在讀一個(gè)復(fù)雜函數(shù)邊讀邊問這時(shí)跟蹤模式很合適。但當(dāng)你要做跨文件重構(gòu)時(shí)關(guān)掉跟蹤模式改用顯式引用手動(dòng)控制上下文集合。如果你用的工具沒有這么細(xì)的開關(guān)退而求其次的方法是集中使用一個(gè)臨時(shí)工作區(qū)把本次任務(wù)涉及的文件都放到這個(gè)臨時(shí)窗口里其余文件全部關(guān)閉。這樣即使工具會(huì)自動(dòng)收集當(dāng)前打開的文件被你關(guān)掉的那些也不會(huì)出現(xiàn)在上下文中。3.3 結(jié)構(gòu)感知與語義感知為什么跳到定義比全盤搜索管用很多AI編程工具還提供所謂的結(jié)構(gòu)感知能力也就是利用編譯器或者語言服務(wù)器的信息把函數(shù)定義、類型定義、引用關(guān)系這類結(jié)構(gòu)信息注入上下文。這個(gè)能力比單純的全文搜索要精準(zhǔn)得多。舉個(gè)例子當(dāng)你在main.ts里看到某個(gè)函數(shù)調(diào)用了fetchUser你想讓AI理解fetchUser的行為用跳到定義把fetchUser所在文件加入引用一次就能拿到函數(shù)簽名、參數(shù)類型、返回值類型和關(guān)鍵實(shí)現(xiàn)。如果先用全文搜索AI可能要翻好幾個(gè)文件才能拼出一張完整的圖。我在實(shí)際使用中會(huì)刻意利用這一點(diǎn)需要理解調(diào)用鏈時(shí)我會(huì)沿著調(diào)用鏈把每一層的定義文件逐個(gè)加入引用。用快捷鍵跳轉(zhuǎn)比直接讓AI搜索一下要省錢省力得多而且給出的答案更準(zhǔn)確。結(jié)構(gòu)感知還有一個(gè)隱藏優(yōu)勢(shì)它能避免AI把同名但不同義的函數(shù)搞混。一個(gè)項(xiàng)目里經(jīng)常出現(xiàn)getUserOrder和getOrderUser這種命名相近但語義完全不同的函數(shù)全文搜索很容易召回一堆無關(guān)內(nèi)容。結(jié)構(gòu)感知?jiǎng)t能通過調(diào)用的實(shí)際位置精準(zhǔn)定位省去很多噪音。3.4 手動(dòng)控制token預(yù)算給上下文分優(yōu)先級(jí)說一個(gè)很少被人提到的實(shí)操細(xì)節(jié)手動(dòng)給上下文分優(yōu)先級(jí)。雖然工具會(huì)自動(dòng)處理token但你的主觀排序能顯著提升質(zhì)量。我把上下文分成兩檔。第一檔叫永久核心通常包括項(xiàng)目的README、架構(gòu)說明文檔、編碼規(guī)范約定。這些內(nèi)容信息密度高、變更頻率低、全局影響大每輪對(duì)話都應(yīng)該讓AI看到。第二檔叫臨時(shí)工作區(qū)就是本次任務(wù)直接相關(guān)的代碼文件、最近的diff、相關(guān)測(cè)試用例。這些內(nèi)容隨任務(wù)變化而替換。具體到操作上我會(huì)在每次新會(huì)話開始時(shí)先把README.md或者docs/architecture.md引用進(jìn)去再引用當(dāng)前任務(wù)的文件。這個(gè)方法看起來笨但實(shí)測(cè)下來非常有效。因?yàn)锳I一旦理解了項(xiàng)目整體約束就不會(huì)在某個(gè)局部需求上做出和架構(gòu)相悖的設(shè)計(jì)。如果你不主動(dòng)做這一步工具按默認(rèn)邏輯收集上下文AI很容易一頭扎進(jìn)某個(gè)細(xì)節(jié)忽略全局。token預(yù)算的另一個(gè)操作是控制文件粒度。如果一個(gè)文件有幾千行而你要改的部分只在其中一百行先看看能不能通過選區(qū)把它縮小。大部分工具允許你在引用文件之后繼續(xù)疊加上選區(qū)兩者疊加能精確控制模型看整份文件還是只看片段。這樣既保留了文件級(jí)上下文的結(jié)構(gòu)信息又避免了無關(guān)代碼的干擾。4. 避坑實(shí)錄我踩過的四個(gè)上下文相關(guān)的大坑4.1 整個(gè)倉(cāng)庫塞進(jìn)上下文的代價(jià)有一次我為了讓AI全面理解項(xiàng)目在Cursor里用Codebase把整個(gè)倉(cāng)庫交給了它然后問了一個(gè)很具體的bug排查問題。AI思考了很長(zhǎng)時(shí)間然后給出了一份覆蓋四個(gè)模塊的建議方案其中兩個(gè)模塊跟問題毫無關(guān)系還有一個(gè)方案里的文件路徑是錯(cuò)的。排查過程是這樣的我先打開上下文面板看注入內(nèi)容發(fā)現(xiàn)工具為這個(gè)問題召回了大約三十個(gè)文件片段其中一半只是提過相關(guān)關(guān)鍵詞并沒有真正參與邏輯鏈路。我猜測(cè)模型在這么多候選內(nèi)容里很難判斷哪些是當(dāng)前任務(wù)的核心結(jié)果是它對(duì)每個(gè)片段都做了等權(quán)重處理最后生成了一份雨露均沾式的回答。這個(gè)問題的最佳解法是降低項(xiàng)目級(jí)上下文的使用頻率。只有在我不確定代碼藏在哪里時(shí)才用Codebase做定位一旦鎖定目標(biāo)文件立刻關(guān)閉項(xiàng)目級(jí)上下文改用顯式引用。效果立竿見影。如果你非要用項(xiàng)目級(jí)上下文做大規(guī)模重構(gòu)我的建議是先縮小搜索范圍問問題時(shí)直接點(diǎn)名目錄或者模塊比如在src/modules/auth/目錄下搜索所有跟token刷新相關(guān)的邏輯這能有效減少召回的噪聲。4.2 過期上下文導(dǎo)致的幻覺式修改另一個(gè)讓我印象深刻的坑是過期上下文。場(chǎng)景是我讓AI修改了一個(gè)函數(shù)的實(shí)現(xiàn)它把parseConfig這個(gè)函數(shù)改成了新的參數(shù)結(jié)構(gòu)。過了一會(huì)兒我又讓它修改另一個(gè)函數(shù)而這個(gè)函數(shù)調(diào)用了parseConfig。AI沒有重新讀parseConfig的最新實(shí)現(xiàn)而是基于對(duì)話歷史中那份舊版本的記憶對(duì)調(diào)用方做了匹配結(jié)果生成了一段完全對(duì)不上號(hào)的代碼。這個(gè)問題的根因是上下文快照的時(shí)效性。AI讀出文件的那一刻會(huì)生成快照之后文件如果在本地被改動(dòng)工具不一定能在下一輪對(duì)話中自動(dòng)刷新這份快照。尤其是當(dāng)你通過外部方式修改了文件比如用git checkout或者手動(dòng)編輯對(duì)話中的舊快照依然滯留在上下文里。我的做法是每次在對(duì)話期間手動(dòng)修改了文件都重新引用一遍這個(gè)文件或者干脆新開一個(gè)會(huì)話。如果你用的工具提供重新讀取文件的按鈕很多IDE的引用文件后面會(huì)出現(xiàn)刷新圖標(biāo)也有效。千萬不要想著反正我自己知道改了AI應(yīng)該也知道AI真的不知道。4.3 多文件同步時(shí)的版本錯(cuò)位多文件場(chǎng)景里還有一類很隱蔽的坑AI在同一個(gè)會(huì)話里生成了修改userService.ts和userController.ts的代碼但生成過程中并沒有做到兩個(gè)文件互相感知。它先寫了userService.ts寫完把你傳來的任務(wù)當(dāng)作歷史再寫userController.ts時(shí)引用的某些假設(shè)跟第一個(gè)文件的新版本不一致接口簽名對(duì)不上。這種問題的根源在于工具雖然并行了多個(gè)文件編輯但提示詞中的上下文是先后拼接的。模型在生成第二個(gè)文件時(shí)雖然知道第一個(gè)文件存在但對(duì)它的完整實(shí)現(xiàn)細(xì)節(jié)并不了解。你可以想象成兩個(gè)程序員各自拿了一份舊需求說明分別在A棟和B棟里改代碼最后合并時(shí)才發(fā)現(xiàn)一個(gè)人改了接口入?yún)⒘硪粋€(gè)人還按老接口寫調(diào)用。我的排查經(jīng)驗(yàn)是遇到這種問題先看引用列表。如果AI連續(xù)改了多個(gè)文件我會(huì)強(qiáng)制在后續(xù)指令里再次引用已改完的核心文件。特別是在涉及函數(shù)簽名、數(shù)據(jù)結(jié)構(gòu)、模塊間約定的時(shí)候多引用一次沒有什么壞處反而是保障。4.4 長(zhǎng)對(duì)話中上下文被靜默截?cái)嘧詈笠粋€(gè)坑非常隱蔽長(zhǎng)對(duì)話中上下文被靜默截?cái)唷Ｓ幸淮挝疫B續(xù)跟AI聊了三十多輪前面講了很多需求約束和代碼細(xì)節(jié)。到第三十一輪時(shí)AI突然開始忽略一個(gè)我一直在強(qiáng)調(diào)的約束——不能動(dòng)數(shù)據(jù)庫表結(jié)構(gòu)。我一開始懷疑是模型智商問題后來檢查才發(fā)現(xiàn)工具在上下文接近上限時(shí)自動(dòng)丟棄了最早的一部分歷史消息而數(shù)據(jù)庫約束恰好就在被丟棄的那段歷史里。這個(gè)問題幾乎沒有直觀提示很多工具會(huì)在上下文面板里顯示內(nèi)容已超出窗口部分較早信息已被截?cái)唷Ｈ绻銢]注意看會(huì)以為AI在犯蠢。為了避免這種情況我給自己立了三條規(guī)矩一是關(guān)鍵約束反復(fù)強(qiáng)調(diào)而且盡量從永久核心文件里引用而不只是依賴對(duì)話歷史二是單次會(huì)話不要跨越太大任務(wù)完成一個(gè)獨(dú)立小任務(wù)就新開會(huì)話減少歷史累積三是每過十幾輪對(duì)話主動(dòng)問一次AI你還能看到我之前說的關(guān)鍵約束嗎或者直接重新粘貼一次約束文本。雖然看起來有點(diǎn)笨但在實(shí)際問題排查中比事后發(fā)現(xiàn)被截?cái)嘣傺a(bǔ)救要省時(shí)得多。5. 進(jìn)階用法把context-mode用成本職工作的外掛5.1 讓架構(gòu)文檔成為常駐上下文我前面提到過永久核心的概念這里展開講講具體怎么操作。對(duì)于長(zhǎng)期維護(hù)的項(xiàng)目我會(huì)在項(xiàng)目根目錄維護(hù)一個(gè)docs/decisions.md文件里面記錄架構(gòu)決策、編碼約定、模塊邊界等。這個(gè)文件不需要多長(zhǎng)但信息密度要高。每次開啟新會(huì)話處理這個(gè)項(xiàng)目的編碼任務(wù)時(shí)我會(huì)先把這個(gè)文件加入引用。它帶來的效果是AI生成的代碼天然遵守項(xiàng)目約定不會(huì)出現(xiàn)明明項(xiàng)目用函數(shù)式寫法它卻給你寫一堆類這種風(fēng)格錯(cuò)亂。你可以把這一步理解為給臨時(shí)工發(fā)員工手冊(cè)雖然麻煩但能顯著減少返工。如果你不想維護(hù)額外文件退而求其次的做法是直接在對(duì)話開頭寫一段簡(jiǎn)短的項(xiàng)目背景提示詞。但說實(shí)話提示詞很容易被后續(xù)對(duì)話沖淡而一條文件引用卻可以在整個(gè)會(huì)話中穩(wěn)定存在。這也是context-mode帶給我的最大收益之一可以把以前靠人反復(fù)口頭提醒的項(xiàng)目背景變成自動(dòng)穩(wěn)定的上下文注入。5.2 代碼評(píng)審時(shí)的高質(zhì)量上下文組合代碼評(píng)審是context-mode非常實(shí)用的場(chǎng)景但大多數(shù)人只會(huì)簡(jiǎn)單地把改動(dòng)文件扔給AI說幫我看看有沒有問題。這樣做得到的一般都是套話。我試過幾輪之后總結(jié)了一套組合把這次提交的diff、改動(dòng)文件本身、以及被改動(dòng)文件的主要調(diào)用方三樣?xùn)|西一起作為上下文?？赡艿脑捲俑缴弦环菹嚓P(guān)的測(cè)試文件。這個(gè)組合能讓AI從三個(gè)視角審代碼diff視角看改動(dòng)范圍是否合理調(diào)用方視角看改動(dòng)會(huì)不會(huì)破壞現(xiàn)有接口測(cè)試視角看覆蓋是否充足。還有一個(gè)細(xì)節(jié)如果評(píng)審的是bug修復(fù)類改動(dòng)我建議把bug的描述也放進(jìn)去作為上下文。AI沒有能力僅憑代碼推出你當(dāng)初遇到的問題場(chǎng)景你給它一個(gè)明確的前置條件它的評(píng)審才能針對(duì)性地從這段代碼是否修復(fù)了bug和這段代碼是否引入了新問題兩個(gè)角度展開。5.3 不同任務(wù)類型的上下文組合清單用久了之后我把常見的編程任務(wù)和對(duì)應(yīng)的上下文組合整理成了一張清單每次做同類任務(wù)都用同一套套路。這張清單不一定適合所有人但思路值得參考任務(wù)類型上下文組合優(yōu)先級(jí)新手探索代碼庫項(xiàng)目README、要探索模塊的目錄結(jié)構(gòu)、相關(guān)入口文件項(xiàng)目級(jí)優(yōu)先修復(fù)已知bugbug描述、相關(guān)函數(shù)實(shí)現(xiàn)、調(diào)用方文件文件級(jí)優(yōu)先跨文件重構(gòu)架構(gòu)說明、涉及的所有文件、相關(guān)測(cè)試用例文件級(jí)必要的項(xiàng)目級(jí)定位新增一個(gè)功能模塊項(xiàng)目架構(gòu)文檔、類似模塊的實(shí)現(xiàn)文件、接口設(shè)計(jì)文檔混合但核心文件必須顯式引用代碼評(píng)審diff、改動(dòng)文件、調(diào)用方、測(cè)試文件文件級(jí)為主代碼答疑當(dāng)前文件選區(qū)、結(jié)構(gòu)感知跳轉(zhuǎn)出的定義選區(qū)級(jí)優(yōu)先這里的組合不是死的但它幫我減少了很多試錯(cuò)成本。每次開工前先想清楚這次是哪個(gè)類型的任務(wù)然后按清單準(zhǔn)備上下文比邊干邊讓工具自動(dòng)收集要穩(wěn)定得多。5.4 我們最終要建立的是對(duì)AI看到什么的感知能力如果說這篇文章只能留下一件事我希望能是這句話用context-mode久了真正練出的核心能力不是熟練操作某個(gè)快捷鍵而是能夠隨時(shí)感知AI眼前到底有什么。我見過很多人把AI編程工具當(dāng)成黑盒出了問題就怪模型不行。但實(shí)際操作中絕大多數(shù)失敗案例的問題根因都可以追溯到上下文選擇不當(dāng)。一旦你建立起AI看到什么決定它生成什么的感知調(diào)試提示詞、排查奇怪輸出、提高生成質(zhì)量都會(huì)變得順理成章。我現(xiàn)在的日常工作流已經(jīng)變成了這樣開工前先想清楚任務(wù)類型按清單把上下文釘好每一輪對(duì)話前快速掃一眼引用列表每當(dāng)AI給出奇怪答案第一反應(yīng)不是重新給一遍需求而是打開上下文面板看它是不是把無關(guān)文件帶進(jìn)來了。這個(gè)習(xí)慣看起來不起眼但對(duì)我來說它比任何提示詞技巧都管用。如果你也經(jīng)常被AI編程助手的腦洞氣得不行不妨先從這次開始做一次上下文體檢。