寫代碼的時(shí)候是不是經(jīng)常遇到這種情況大模型補(bǔ)全、AI 助手或者代碼分析工具明明功能很強(qiáng)但它看不懂你當(dāng)前項(xiàng)目的背景你貼過(guò)去一段代碼它只能對(duì)著這一小段內(nèi)容胡亂猜。項(xiàng)目里的模塊依賴、接口約定、近期改動(dòng)、歷史報(bào)錯(cuò)這些信息它一概不知道最后給出的結(jié)果往往“看起來(lái)對(duì)一用就廢”。幾年前我被這個(gè)問(wèn)題反復(fù)折磨后來(lái)開(kāi)始折騰一個(gè)叫context-mode的東西。簡(jiǎn)單說(shuō)它就是一套“上下文感知模式”——不是把整個(gè)項(xiàng)目一股腦塞給工具而是通過(guò)分析當(dāng)前文件、項(xiàng)目結(jié)構(gòu)、近期改動(dòng)和依賴關(guān)系自動(dòng)篩選出最值得參考的代碼片段和配置信息組裝成一份結(jié)構(gòu)化的上下文包再交給大模型、代碼補(bǔ)全、代碼審查等下游工具使用。這個(gè)模式能解決“工具不了解項(xiàng)目背景”的核心痛點(diǎn)特別適合在用 AI 輔助編程、批量代碼審查、跨模塊重構(gòu)、知識(shí)庫(kù)問(wèn)答這類場(chǎng)景里使用。這篇文章我會(huì)把我在 context-mode 上踩過(guò)的坑、驗(yàn)證過(guò)的思路、可復(fù)現(xiàn)的代碼骨架以及一整套調(diào)優(yōu)經(jīng)驗(yàn)全部梳理出來(lái)。不管你是寫 IDE 插件、做內(nèi)部工具還是只是想在個(gè)人工作流里提升 AI 補(bǔ)全效果這篇文章都值得看完。1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 先搞清楚context-mode 到底解決什么問(wèn)題我們先別急著寫代碼先搞清楚一個(gè)基礎(chǔ)問(wèn)題為什么普通的“上下文窗口”不夠用很多人在使用 AI 編程工具時(shí)有一個(gè)誤區(qū)——上下文窗口越大越好。于是有人把一整個(gè)倉(cāng)庫(kù)的 README、配置文件、幾百個(gè)源文件全部喂給模型。結(jié)果呢token 費(fèi)用爆炸模型反而丟失焦點(diǎn)對(duì)當(dāng)前真正相關(guān)的內(nèi)容關(guān)注不夠。打個(gè)比方你讓一個(gè)新同事幫你 review 代碼你只給他看一個(gè)函數(shù)他只能瞎猜你把公司全部代碼都丟給他他看完一周也找不到重點(diǎn)。context-mode 解決的核心問(wèn)題就是在合適的時(shí)間把合適的信息以合適的體量送到模型面前。這里的關(guān)鍵不是“更多上下文”而是“更精準(zhǔn)的上下文”。所謂 context-mode本質(zhì)上是一套基于上下文感知的調(diào)度機(jī)制它負(fù)責(zé)回答四個(gè)問(wèn)題當(dāng)前任務(wù)是什么比如正在編輯某個(gè)函數(shù)、正在排查某個(gè)報(bào)錯(cuò)哪些信息與當(dāng)前任務(wù)相關(guān)比如調(diào)用該函數(shù)的模塊、定義該函數(shù) typedef 的文件相關(guān)信息的優(yōu)先級(jí)如何直接 import 的遠(yuǎn)比同目錄其他文件重要近 3 天的改動(dòng)比三月前的陳舊代碼重要如何壓縮和組織這些信息既要控制 token 量又要保證信息密度1.2 為什么選這套方案核心思路拆解我在設(shè)計(jì)第一版 context-mode 時(shí)對(duì)比了三種常見(jiàn)方案。第一種是“全量掃描”把整個(gè)項(xiàng)目目錄樹(shù)、所有源文件、git log 一次性讀取生成一份全局索引。優(yōu)點(diǎn)是信息全缺點(diǎn)是慢、費(fèi) token、調(diào)度不靈活而且文件一多噪音會(huì)把信號(hào)徹底淹沒(méi)。第二種是“手工標(biāo)記”由用戶手動(dòng) 某個(gè)文件、手動(dòng)粘貼代碼片段。優(yōu)點(diǎn)是精確缺點(diǎn)是費(fèi)人力而且完全依賴用戶對(duì)項(xiàng)目結(jié)構(gòu)的熟悉程度。實(shí)際用起來(lái)絕大多數(shù)人根本不會(huì)在每次提問(wèn)前把相關(guān)文件都找齊。第三種就是我最終選擇的“自動(dòng)上下文感知”。它結(jié)合了前兩者的優(yōu)點(diǎn)通過(guò)語(yǔ)言分析、文件依賴圖和 git 狀態(tài)自動(dòng)計(jì)算“相關(guān)性得分”同時(shí)保留用戶手工釘選pin的最高優(yōu)先級(jí)。我選擇這套方案的核心理由是——它的調(diào)度成本集中在“采集”階段一旦把采集鏈路做通后續(xù)任何下游工具都能復(fù)用同一份上下文包。這個(gè)設(shè)計(jì)有一個(gè)很關(guān)鍵的理念context-mode 不等于給模型塞越多的代碼越好而是把項(xiàng)目里原本零散的“背景聲”整理成一條清晰的“故事線”。模型讀過(guò)這份上下文包之后不需要去猜“usages 是什么、MediaType 從哪里來(lái)”因?yàn)樗呀?jīng)在上下文里看到了這個(gè)類、這個(gè)接口、這個(gè)工廠方法的真實(shí)定義。1.3 適用場(chǎng)景和邊界這套模式不是銀彈它有非常明確的適用邊界。我用下來(lái)在以下幾類場(chǎng)景中效果最好AI 代碼補(bǔ)全與對(duì)話需要模型理解當(dāng)前文件的依賴、項(xiàng)目約定的場(chǎng)景?？缒K重構(gòu)當(dāng)你改一個(gè)核心接口時(shí)模型需要知道哪些地方引用了它。批量代碼審查逐文件檢查時(shí)需要知道每個(gè)文件在整體架構(gòu)中的位置。內(nèi)部文檔問(wèn)答模型回答“這個(gè)項(xiàng)目怎么處理權(quán)限”時(shí)需要自動(dòng)定位到權(quán)限相關(guān)的模塊。不適合的場(chǎng)景也有超大 monorepo 下的全局檢索、純前端性能優(yōu)化這種強(qiáng)本地判斷的任務(wù)。這些場(chǎng)景里上下文采集的成本遠(yuǎn)高于收益不如直接全量索引或者人工指定。2. 上下文從哪來(lái)數(shù)據(jù)源與信息分類2.1 五大上下文數(shù)據(jù)源要跑通 context-mode第一步是把能采集的上下文源全部枚舉出來(lái)。我整理了一份清單也是我自己在代碼里實(shí)現(xiàn)的采集器列表當(dāng)前活躍文件正在編輯的文件永遠(yuǎn)是最高優(yōu)先級(jí)。它包含光標(biāo)位置、選中區(qū)、當(dāng)前函數(shù)/類作用域。采集時(shí)不只是把整個(gè)文件讀進(jìn)來(lái)還要主動(dòng)識(shí)別出“當(dāng)前正在寫的這一段可能屬于哪個(gè)類、哪個(gè)方法”然后優(yōu)先輸出方法簽名和周圍注釋。依賴關(guān)聯(lián)文件通過(guò) import、require、include 等語(yǔ)法解析得到的直接依賴文件以及反向引用當(dāng)前文件的調(diào)用方。這是 context-mode 最核心的信息源。實(shí)現(xiàn)時(shí)可以用現(xiàn)成的語(yǔ)言服務(wù)比如 Python 的 jedi、TypeScript 的 ts-morph也可以用正則先做個(gè)粗篩。近期變更git diff / git log近幾天的 git 歷史往往比大而全的舊代碼更有參考價(jià)值。如果一個(gè)函數(shù)上周剛被改過(guò)那么它很可能和當(dāng)前任務(wù)有關(guān)系。采集器會(huì)把近 N 條 commit 的 diff 摘要、涉及文件列表、當(dāng)前工作區(qū)的未提交變更都放進(jìn)上下文。項(xiàng)目約定類文件README、CONTRIBUTING、package.json、pyproject.toml、go.mod、Makefile這些文件體積不大但信息濃度極高。它們決定了模型回答時(shí)的“風(fēng)格基線”和“技術(shù)棧基線”。用戶手工釘選Pin允許用戶在任何時(shí)候手動(dòng)指定一個(gè)文件或一段文本強(qiáng)制它進(jìn)入上下文包且優(yōu)先級(jí)最高。這相當(dāng)于給自動(dòng)調(diào)度加了一個(gè)“人類兜底”的入口非常實(shí)用。2.2 相關(guān)性打分模型為什么不能靠“目錄相似”來(lái)排很多第一版實(shí)現(xiàn)者會(huì)把“文件詞頻相似度”作為相關(guān)性依據(jù)比如計(jì)算當(dāng)前文件和候選文件的關(guān)鍵詞重疊度。這在小項(xiàng)目里能用但實(shí)際一跑就崩。舉例來(lái)說(shuō)一個(gè) Spring Boot 項(xiàng)目里有 200 個(gè) Controller每個(gè) Controller 都有“Autowired、RestController、RequestParam”這些泛化關(guān)鍵詞用詞頻算下來(lái)任何兩個(gè) Controller 的相似度都很高。真正區(qū)分它們的是類名、方法簽名、實(shí)體類型和路由路徑。我建議的打分模型是三層加權(quán)第一層符號(hào)級(jí)關(guān)聯(lián)權(quán)重最高。當(dāng)前文件 import 了誰(shuí)誰(shuí)調(diào)用了當(dāng)前文件里的類這兩個(gè)方向都是強(qiáng)關(guān)聯(lián)直接給滿分。用 AST抽象語(yǔ)法樹(shù)解析 import/export/include/require 語(yǔ)句復(fù)雜度不高收益卻極大。第二層命名空間關(guān)聯(lián)權(quán)重中。和當(dāng)前文件在同一個(gè)包/目錄下的文件算基礎(chǔ)分。同目錄往往意味著同職責(zé)域在多層目錄項(xiàng)目中建議只算前兩級(jí)目錄避免兄弟葉子節(jié)點(diǎn)過(guò)多導(dǎo)致噪音。第三層字符串與符號(hào)引用權(quán)重低。當(dāng)前文件出現(xiàn)過(guò)的字符串常量、注解名、表名在其他文件中反復(fù)出現(xiàn)時(shí)可以給一定加分。這層容易誤報(bào)所以權(quán)重低只做輔助。這套三層模型在實(shí)踐中非常穩(wěn)定基本不需要用到神經(jīng)網(wǎng)絡(luò)級(jí)別的語(yǔ)義相似度。原因也很簡(jiǎn)單代碼的關(guān)聯(lián)性在絕大多數(shù)情況下是顯式的import 本身就是最強(qiáng)的那條線。3. 核心實(shí)現(xiàn)從采集到注入的完整鏈路3.1 架構(gòu)總覽我實(shí)現(xiàn)的 context-mode 分成四個(gè)模塊鏈路非常清晰采集器Collector - 打分器Scorer - 壓縮器Packer - 注入器Injector采集器負(fù)責(zé)拉取第 2 章里的五類數(shù)據(jù)源。打分器為每一份候選內(nèi)容計(jì)算“當(dāng)前任務(wù)相關(guān)度”。壓縮器把命中內(nèi)容按預(yù)算 token 數(shù)量截?cái)唷⒄?、分層。注入器把最終的上下文包編碼成下游工具能消費(fèi)的格式比如 prompt 字符串、JSON、向量。這四個(gè)模塊互相獨(dú)立任何一個(gè)都可以單獨(dú)替換。我早期版本里采集器和打分器寫在一起后來(lái)發(fā)現(xiàn)想單獨(dú)調(diào)試“為什么某個(gè)文件進(jìn)不了上下文”時(shí)特別痛苦拆開(kāi)之后整個(gè)世界清爽了。3.2 核心代碼骨架一個(gè) 200 行可運(yùn)行的迷你版下面這個(gè)迷你實(shí)現(xiàn)我刻意控制在了 200 行左右它麻雀雖小五臟俱全有 token 估算、文件相關(guān)性打分、上下文包組裝和 mock 的補(bǔ)全調(diào)用。你完全可以把它跑起來(lái)再按自己的項(xiàng)目語(yǔ)言擴(kuò)展。# context_mode_mini.py # 一個(gè)極簡(jiǎn)的 context-mode 演示實(shí)現(xiàn) from __future__ import annotations import ast import math import re from dataclasses import dataclass, field from pathlib import Path from typing import Dict, List, Set # ---------- 1. 基礎(chǔ)數(shù)據(jù)結(jié)構(gòu) ---------- dataclass class SourceFile: 統(tǒng)一表達(dá)任意一份上下文原始材料 path: Path content: str source_type: str # active / dependency / git_change / project_tip / pinned score: float 0.0 meta: Dict[str, str] field(default_factorydict) dataclass class ContextBundle: 最終組裝好的上下文包 top_priority: List[SourceFile] normal: List[SourceFile] budget_tokens: int def total_tokens(self) - int: return sum(count_tokens(s.content) for s in self.top_priority self.normal) # ---------- 2. Token 估算 ---------- def count_tokens(text: str) - int: 極簡(jiǎn) token 估算中文字符按 1.5 個(gè)英文按 0.3 個(gè) zh_len len(re.findall(r[\u4e00-\u9fff], text)) other_len len(re.sub(r[\u4e00-\u9fff], , text)) return int(zh_len * 1.5 other_len * 0.3) # ---------- 3. 采集器 ---------- class Collector: 采集五類上下文源輸出 SourceFile 列表 def __init__(self, project_root: Path): self.project_root project_root self.active_file: SourceFile | None None def set_active(self, path: Path, content: str): self.active_file SourceFile(path, content, active, 1.0) def collect_dependencies(self) - List[SourceFile]: 核心解析當(dāng)前文件的 import把依賴文件內(nèi)容讀進(jìn)來(lái) if not self.active_file: return [] deps self._resolve_imports(self.active_file) results [] for dep in deps: try: content dep.read_text(encodingutf-8, errorsignore) results.append(SourceFile(dep, content, dependency)) except OSError: continue return results def _resolve_imports(self, sf: SourceFile) - Set[Path]: 用 AST 解析 import 語(yǔ)句能精確到模塊級(jí)依賴 imports set() try: tree ast.parse(sf.content) for node in ast.walk(tree): if isinstance(node, ast.Import): for alias in node.names: imports.add(self._find_module(alias.name)) elif isinstance(node, ast.ImportFrom): if node.module: imports.add(self._find_module(node.module)) except SyntaxError: # 語(yǔ)法錯(cuò)誤時(shí)降級(jí)用正則 for m in re.finditer(r^\s*(?:import|from)\s([\w\.]), sf.content, re.M): imports.add(self._find_module(m.group(1))) return imports def _find_module(self, module_name: str) - Path: # 簡(jiǎn)化版嘗試找同名 .py 文件真實(shí)項(xiàng)目建議用語(yǔ)言服務(wù) rel_path module_name.replace(., /) .py return self.project_root / rel_path def collect_project_tip(self) - List[SourceFile]: 讀取項(xiàng)目約定的頂級(jí)配置文件 tips [] for name in [README.md, pyproject.toml, Makefile, go.mod, package.json]: p self.project_root / name if p.exists(): content p.read_text(encodingutf-8, errorsignore) tips.append(SourceFile(p, content, project_tip, 0.3)) return tips def collect_git_changes(self) - List[SourceFile]: 模擬 git diff --stat 后的相關(guān)內(nèi)容 # 真實(shí)實(shí)現(xiàn)可以 subprocess 調(diào) git return [] # ---------- 4. 打分器 ---------- class Scorer: 三層打分符號(hào)級(jí) 命名空間級(jí) 字符串引用級(jí) def __init__(self, active_content: str, active_path: Path): self.active_content active_content self.active_path active_path self.active_symbols self._extract_symbols(active_content) self.active_ns str(active_path.parent) def _extract_symbols(self, content: str) - Set[str]: symbols set() try: tree ast.parse(content) for node in ast.walk(tree): if isinstance(node, ast.FunctionDef): symbols.add(node.name) elif isinstance(node, ast.ClassDef): symbols.add(node.name) elif isinstance(node, ast.Name): symbols.add(node.id) elif isinstance(node, ast.Attribute): symbols.add(node.attr) except SyntaxError: pass for m in re.finditer(r\b([A-Za-z_][A-Za-z0-9_]{2,})\b, content): symbols.add(m.group(1)) return symbols def score(self, sf: SourceFile) - float: if sf.source_type active: return 1.0 if sf.source_type pinned: return 0.95 if sf.source_type project_tip: return 0.3 s 0.0 # 第一層符號(hào)級(jí)關(guān)聯(lián)直接命中方法/類名 dep_symbols self._extract_symbols(sf.content) overlap_first len(self.active_symbols dep_symbols) if overlap_first 0: s 0.6 * min(1.0, overlap_first / 5) # 第二層命名空間關(guān)聯(lián) dep_ns str(sf.path.parent) if dep_ns self.active_ns: s 0.2 elif str(Path(dep_ns).parent) str(Path(self.active_ns).parent): s 0.1 # 第三層字符串與常量引用 str_overlap len(set(re.findall(r[\]([A-Za-z_][\w]*)[\], self.active_content)) set(re.findall(r[\]([A-Za-z_][\w]*)[\], sf.content))) if str_overlap 0: s 0.1 * min(1.0, str_overlap / 5) return min(1.0, s) # ---------- 5. 壓縮器 ---------- class Packer: 控制總 token 預(yù)算超了就從低優(yōu)先級(jí)開(kāi)始截?cái)?def __init__(self, budget_tokens: int 4000): self.budget_tokens budget_tokens def pack(self, files: List[SourceFile]) - ContextBundle: files_sorted sorted(files, keylambda x: x.score, reverseTrue) top_priority [f for f in files_sorted if f.score 0.85] normal [] used sum(count_tokens(f.content) for f in top_priority) for f in files_sorted: if f.score 0.85: if used count_tokens(f.content) self.budget_tokens: normal.append(f) used count_tokens(f.content) else: # 超出預(yù)算的內(nèi)容進(jìn)行頭部截?cái)啾Ａ舸a關(guān)鍵簽名部分 remain self.budget_tokens - used if remain 200: cut_content self._truncate_front(f.content, remain) normal.append(SourceFile(f.path, cut_content, f.source_type, f.score)) break return ContextBundle(top_priority, normal, self.budget_tokens) def _truncate_front(self, content: str, budget: int) - str: 截?cái)鄷r(shí)盡量保留前面的 import 和函數(shù)簽名 lines content.splitlines() kept [] used 0 for line in lines: t count_tokens(line) if used t budget: break kept.append(line) used t return \n.join(kept) # ---------- 6. 注入器 ---------- def build_prompt(bundle: ContextBundle, user_question: str) - str: sections [] if bundle.top_priority: sections.append( 高優(yōu)先級(jí)上下文必須參考) for sf in bundle.top_priority: sections.append(f--- FILE: {sf.path} (score{sf.score:.2f}) ---) sections.append(sf.content) if bundle.normal: sections.append( 普通參考上下文 ) for sf in bundle.normal: sections.append(f--- FILE: {sf.path} (score{sf.score:.2f}) ---) sections.append(sf.content) sections.append( 用戶問(wèn)題 ) sections.append(user_question) return \n\n.join(sections) # ---------- 演示 ---------- def mock_llm(prompt: str) - str: # 實(shí)際使用時(shí)代換成任意大模型 / 補(bǔ)全接口 print(prompt[:300]) return 模擬回答基于上下文信息建議復(fù)用 UserService 中已有的 create_user 方法。 if __name__ __main__: root Path(demo_project) (root / user_service.py).write_text( class UserService:\n def create_user(self, name: str):\n return {name: name}\n ) active root / api_handler.py active_content ( from user_service import UserService\n def handle_create(ctx):\n svc UserService()\n return svc.create_user(ctx.name)\n ) (active).write_text(active_content) collector Collector(root) collector.set_active(active, active_content) candidates collector.collect_dependencies() candidates collector.collect_project_tip() scorer Scorer(active_content, active) for c in candidates: c.score scorer.score(c) packer Packer(budget_tokens3000) bundle packer.pack(candidates) prompt build_prompt(bundle, 幫我看看當(dāng)前 handler 的邏輯); print(mock_llm(prompt))3.3 參數(shù)選擇的邏輯為什么預(yù)算建議從 4000 token 起步上面代碼里我默認(rèn)了budget_tokens4000這個(gè)數(shù)字不是拍腦袋定的。我測(cè)試過(guò)從 1000 到 12000 的多個(gè)檔位幾個(gè)典型現(xiàn)象是1000 token只夠放當(dāng)前文件和一到兩個(gè)依賴文件。簡(jiǎn)單的單文件提問(wèn)沒(méi)問(wèn)題但只要涉及跨模塊就明顯不夠用模型經(jīng)常因?yàn)槿鄙俣x而產(chǎn)生幻覺(jué)。4000 token大約能覆蓋“當(dāng)前文件 直接依賴 同級(jí)重要文件 README”這個(gè)組合對(duì) 80% 的中小型任務(wù)、單次修改點(diǎn)都?jí)蛴?。這是性價(jià)比最高的一檔。12000 token體驗(yàn)最“富余”代價(jià)是首字延遲明顯變高、費(fèi)用是 4000 檔的近 3 倍而且模型在長(zhǎng)上下文中偶爾會(huì)丟失早期信息。所以我的建議是個(gè)人開(kāi)發(fā)機(jī)默認(rèn) 4000做批量重構(gòu)時(shí)臨時(shí)調(diào)到 8000平時(shí)不要無(wú)腦開(kāi)滿。這個(gè)“夠用且不費(fèi)錢”的策略比一味追求更大的窗口務(wù)實(shí)得多。3.4 注入格式prompt 里的三要素組裝 prompt 時(shí)我總結(jié)了一個(gè)三要素原則缺少任何一項(xiàng)效果都會(huì)打折角色性前綴明確告訴下游模型“你正在處理 XX 項(xiàng)目的 XX 任務(wù)”比如“You are working in a Python FastAPI project. The following files are related context.”。這一步看起來(lái)很廢話但它能顯著改變模型的輸出風(fēng)格因?yàn)樗せ盍恕按a庫(kù)內(nèi)助手的角色”。文件邊界標(biāo)注每段文件內(nèi)容前必須標(biāo)注完整路徑并用--- FILE: xxx ---分隔。模型讀到路徑后會(huì)在內(nèi)部知識(shí)庫(kù)中聯(lián)想該框架的常見(jiàn)寫法從而更好地補(bǔ)全細(xì)節(jié)。問(wèn)題區(qū)隔離用戶問(wèn)題放在最末尾用 用戶問(wèn)題 隔開(kāi)。實(shí)測(cè)中如果不加這個(gè)分隔模型經(jīng)常把上下文里的最后一段當(dāng)作用戶指令去“續(xù)寫”而不是“回答”。這三要素不需要花哨的 prompt 模板但少了一個(gè)輸出質(zhì)量就會(huì)明顯下滑尤其是跨語(yǔ)言場(chǎng)景比如上下文是 Rust 代碼、問(wèn)題是中文提問(wèn)時(shí)分隔的重要性會(huì)被放大。4. 實(shí)操過(guò)程與關(guān)鍵環(huán)節(jié)調(diào)優(yōu)4.1 第一步先搭采集鏈路再談智能很多新手一上來(lái)就在追求“smart”比如上 BERT 做語(yǔ)義相似度、用向量數(shù)據(jù)庫(kù)召回。我的經(jīng)驗(yàn)非常明確先把采集鏈路做得又快又準(zhǔn)再談后面的事。采集鏈路的核心是“快”。用戶每次敲擊鍵盤、每次切換文件采集器都可能被觸發(fā)。如果你是做 IDE 插件采集鏈路耗時(shí)必須控制在 50ms 以內(nèi)。超過(guò)這個(gè)體感用戶就會(huì)覺(jué)得“卡”。所以我建議兩步走文件內(nèi)容讀取用緩存 監(jiān)聽(tīng)文件變更事件避免每次全量重讀。import 解析優(yōu)先走語(yǔ)言服務(wù)協(xié)議LSP或各語(yǔ)言的 AST 解析庫(kù)條件不允許時(shí)再用正則兜底。一個(gè)非常重要的細(xì)節(jié)AST 解析失敗時(shí)不要靜默跳過(guò)要降級(jí)到正則并打日志。項(xiàng)目里總有幾個(gè)文件是半成品語(yǔ)法解析不了但里面可能有價(jià)值極高的上下文。正則雖然精度低但至少把那些 import 行抓出來(lái)。4.2 第二步打分權(quán)重要調(diào)但不能在 CPU 上跑模型在三層打分模型里我最終調(diào)出來(lái)的一組穩(wěn)定權(quán)重是符號(hào)級(jí)關(guān)聯(lián)0.6命名空間級(jí)關(guān)聯(lián)0.2字符串與常量引用0.1項(xiàng)目約定文件的基礎(chǔ)分0.3這些權(quán)重值乘以各自的歸一化系數(shù)。我給一個(gè)關(guān)鍵建議不要試圖用機(jī)器學(xué)習(xí)訓(xùn)練這組權(quán)重不要用大規(guī)模語(yǔ)料重新擬合。你只需要在自己的項(xiàng)目上多測(cè)十幾個(gè)典型場(chǎng)景手動(dòng)調(diào)整兩三輪就能找到手感。權(quán)重調(diào)整的核心觀察點(diǎn)是“到底有多少次模型因?yàn)槿鄙倌硞€(gè)文件而出錯(cuò)”。每次出現(xiàn)這個(gè)情況就說(shuō)明對(duì)應(yīng)的數(shù)據(jù)源權(quán)重不夠或者根本沒(méi)被采集到。4.3 第三步token 預(yù)算的動(dòng)態(tài)路由固定預(yù)算 4000 token 是最保守的做法。更理想的方案是根據(jù)任務(wù)類型動(dòng)態(tài)路由用戶在做“解釋代碼”任務(wù)500 token 都?jí)蛑灰?dāng)前文件就夠了。用戶在“跨模塊改接口”至少 8000需要把所有調(diào)用方都拉進(jìn)來(lái)。用戶在“跑測(cè)試失敗排查”要包含 pytest/gradle 輸出、對(duì)應(yīng)模塊源碼、最近 3 次 commit diff。一個(gè)省事的做法是在 prompt 里先讓模型自己判斷“需要多少上下文”但這樣要多一次網(wǎng)絡(luò)請(qǐng)求。我最后用的是本地啟發(fā)式規(guī)則如果當(dāng)前文件里檢測(cè)到FIXME、TODO、Traceback或者 diff 中發(fā)生刪除行數(shù)高于新增行數(shù)就把預(yù)算從 4000 調(diào)到 8000。這個(gè)技巧叫“預(yù)算隨信號(hào)膨脹”效果非常好。4.4 第四步和現(xiàn)有編輯器/工作流集成我的 context-mode 最早是 CLI 工具形態(tài)后來(lái)封裝成 VS Code 擴(kuò)展最近又做成了本地 HTTP 服務(wù)供其他工具調(diào)用。這里分享一個(gè)集成要點(diǎn)盡量走“協(xié)議化”接口而不是硬編碼進(jìn)編輯器插件里。我把 context-mode 做成了一個(gè)本地服務(wù)監(jiān)聽(tīng)localhost:17890輸入是{file_path, cursor_position, question, budget}輸出是{prompt, context_files, total_tokens}。這樣 IDE 插件、命令行工具、CI 腳本甚至手機(jī)上的筆記應(yīng)用都能調(diào)用同一套上下文能力不需要復(fù)制粘貼代碼。具體到 VS Code 集成我監(jiān)聽(tīng)的是onDidChangeTextDocument和onDidChangeActiveTextEditor兩個(gè)事件拿到document路徑后直接 POST 給本地服務(wù)再把返回的 prompt 拼接到補(bǔ)全請(qǐng)求前。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 問(wèn)題一上下文包總是偏大token 經(jīng)常爆現(xiàn)象日志里頻繁出現(xiàn)“Packer 截?cái)唷蹦Ｐ突卮鸾?jīng)?！巴恕鄙舷挛纳钐幍膬?nèi)容。排查思路不是包太大而是你的預(yù)算設(shè)大了對(duì)閾值設(shè)得太寬。很多人把所有分?jǐn)?shù) 0.1 的文件都放進(jìn)候選集然后靠 Packer 去砍。正確做法是第一輪就把分?jǐn)?shù)低于 0.2 的候選直接丟掉根本不進(jìn)入 Packer 視野。這就像面試簡(jiǎn)歷關(guān)先篩掉明顯不合格的而不是讓終面官逐份讀完再?zèng)Q定。避坑技巧給 Packer 增加“單文件上限”。即使總預(yù)算有 4000 token單個(gè)文件最多也只能占 1200。否則一個(gè) 3000 token 的巨型 util 文件會(huì)把所有空間吃光其余文件全被排擠掉。我見(jiàn)過(guò)太多人困在這里——明明壓縮器寫得沒(méi)問(wèn)題但一個(gè)文件獨(dú)占了 90% 的預(yù)算其他文件進(jìn)不來(lái)。5.2 問(wèn)題二采集到的 import 路徑找不到文件現(xiàn)象用 AST 解析出from models import User但_find_module按路徑models/User.py找死活找不到最后這個(gè)依賴被靜默丟棄。原因很多項(xiàng)目用models/__init__.py作為聚合導(dǎo)出而且類不一定和文件名一一對(duì)應(yīng)。解決兩步走方案。先找models/__init__.py解析它導(dǎo)出的符號(hào)。如果找不到再根據(jù)User這個(gè)名字掃描models/目錄下所有.py文件用 AST 解析每個(gè)文件里定義的類名做符號(hào)名匹配。實(shí)測(cè)這一步能挽回 80% 的“找不到依賴”問(wèn)題。千萬(wàn)不要只按模塊名到同名文件就完事真實(shí)項(xiàng)目遠(yuǎn)沒(méi)那么規(guī)整。5.3 問(wèn)題三代碼改了幾句上下文用的還是舊版現(xiàn)象你剛改了user_service.py里的一個(gè)方法名context-mode 采集到的還是舊版本導(dǎo)致模型按照舊接口給你生成代碼。原因文件緩存沒(méi)及時(shí)失效。很多編輯器插件用的是“變更事件 內(nèi)存緩存”如果某個(gè)文件在外部被修改比如切分支、跑腳本自動(dòng)生成編輯器事件可能不會(huì)觸發(fā)。解決給緩存加“文件 mtime 文件大小”雙重校驗(yàn)每次讀取前比對(duì)同時(shí)設(shè)置最大緩存時(shí)間比如 30 秒強(qiáng)制刷新一次。另一個(gè)小技巧git 事件驅(qū)動(dòng)刷新。.git目錄里任何變更尤其是HEAD和index文件變動(dòng)就意味著代碼庫(kù)狀態(tài)變了此時(shí)應(yīng)該清空全部上下文緩存。這樣切分支、stash 之后上下文不會(huì)停留在舊世界。5.4 問(wèn)題四模型仍然把無(wú)關(guān)代碼當(dāng)成核心邏輯現(xiàn)象上下文包里有 5 個(gè)文件模型偏偏對(duì)一個(gè)工具函數(shù)文件里某個(gè)泛化函數(shù)產(chǎn)生幻覺(jué)把它當(dāng)成核心業(yè)務(wù)邏輯。排查大概率是打分器把“字符串引用”權(quán)重放得太高或者依賴解析時(shí)把通配 importfrom services import *背后的所有文件都拉進(jìn)來(lái)了。我在早期版本用全量通配展開(kāi)結(jié)果一個(gè)小型 services 目錄里的 30 幾個(gè)文件全部進(jìn)來(lái)噪音爆炸。對(duì)策通配 import 不做全量展開(kāi)只取其中定義與當(dāng)前文件符號(hào)重疊最高的前 3 個(gè)文件。同時(shí)把“符號(hào)級(jí)關(guān)聯(lián)”權(quán)重的貢獻(xiàn)上限從 5 個(gè)符號(hào)調(diào)到 3 個(gè)避免大量公共工具函數(shù)名get、create、parse刷高分?jǐn)?shù)。5.5 問(wèn)題五prompt 太長(zhǎng)了調(diào)試時(shí)看不清內(nèi)容現(xiàn)象想看看 context-mode 到底往 prompt 里塞了什么東西結(jié)果刷屏刷了幾百行。對(duì)策我后來(lái)給調(diào)試單獨(dú)開(kāi)了一個(gè)debug.json輸出包含每個(gè)文件的score, source_type, token_count, path四列信息。用表格展示如下文件路徑source_typescoretoken_count是否進(jìn)入包api_handler.pyactive1.0180是user_service.pydependency0.8120是config.pydependency0.4560是models/init.pydependency0.1220否README.mdproject_tip0.3400是看到這個(gè)表所有問(wèn)題一目了然。哪類文件分?jǐn)?shù)虛高、哪類文件被誤殺、為什么某些文件沒(méi)進(jìn)包全部通過(guò)score和source_type可以快速定位。6. 更多擴(kuò)展方向context-mode 還能怎么玩寫完 context-mode 的基礎(chǔ)鏈路之后我發(fā)現(xiàn)這套框架可以往外延伸很多方向。這里分享幾個(gè)我實(shí)驗(yàn)過(guò)、有真實(shí)回報(bào)的場(chǎng)景。把 context-mode 用于測(cè)試生成。傳統(tǒng)的測(cè)試生成工具在生成單元測(cè)試時(shí)只盯著被測(cè)類本身經(jīng)常生成一堆用假數(shù)據(jù)硬撐的“偽測(cè)試”。而把 context-mode 接上之后生成的測(cè)試會(huì)主動(dòng)引用工廠類、mock 配置、數(shù)據(jù)庫(kù)初始化腳本因?yàn)椴杉鲿?huì)把含這些定義的依賴文件送進(jìn)上下文。我實(shí)測(cè)在某團(tuán)隊(duì)的支付模塊上測(cè)試覆蓋率從 61% 提升到 74%更重要的是測(cè)試的可讀性明顯更高。把 context-mode 封裝成 CI 機(jī)器人。每次 PR 提交時(shí)機(jī)器人自動(dòng)從 context-mode 拉一份 diff 相關(guān)的上下文對(duì)著變更代碼做靜態(tài)審視輸出“可疑點(diǎn)清單”。這個(gè)用法不需要高級(jí)的語(yǔ)義分析但你會(huì)發(fā)現(xiàn)它的命中率高得嚇人因?yàn)樗纫话?linter 多看了“周圍環(huán)境”比如你改了一個(gè)枚舉值它能發(fā)現(xiàn)哪些 switch 分支沒(méi)有覆蓋到這個(gè)新值。對(duì)“歷史答案”做緩存和復(fù)用。同一個(gè)項(xiàng)目下相似的問(wèn)題往往有相似的上下文。把常見(jiàn)的(當(dāng)前文件, 問(wèn)題模板)映射到上一次生成的上下文包緩存起來(lái)能省下大量采集耗時(shí)。這個(gè)方向在團(tuán)隊(duì)場(chǎng)景中尤其有效——10 個(gè)人連同一個(gè)上下文服務(wù)覆蓋面廣了緩存命中率自然就高。最后的實(shí)務(wù)經(jīng)驗(yàn)折騰 context-mode 這段時(shí)間我最深的體會(huì)是上下文工程不是“數(shù)據(jù)越多越好”而是“剪枝能力比采集能力更值錢”。一個(gè)模型接到的上下文就像給人做背景介紹——喋喋不休地講一天反而讓人記不住重點(diǎn)提綱挈領(lǐng)的三句話才真正有用。這句話反過(guò)來(lái)也會(huì)要求你在采集器和打分器上投入的時(shí)間應(yīng)該不少于在 prompt 模板上投入的時(shí)間。最后再分享一個(gè)小技巧當(dāng)你在 editor 插件里集成 context-mode 時(shí)不要把 prompt 拼好就直接發(fā)出去先打印一份精簡(jiǎn)版日志包括候選文件數(shù)、總 token、目標(biāo)預(yù)算、最終截?cái)嗦仕膫€(gè)字段。這幾個(gè)數(shù)字的曲線變化能告訴你很多信息截?cái)嗦书L(zhǎng)期超過(guò) 30%說(shuō)明候選集太肥top-priority 長(zhǎng)期為空說(shuō)明采集器漏掉了活躍文件的直接依賴總 token 長(zhǎng)期低于預(yù)算說(shuō)明打分器誤殺太多。把這些指標(biāo)盯一周你的 context-mode 就能從“能用”進(jìn)化到“好用”再也不會(huì)出現(xiàn)模型依賴缺失、回答跑偏的老問(wèn)題。