這幾乎是我這兩年被問(wèn)得最多的一個(gè)問(wèn)題手里攥著一個(gè)百萬(wàn)行級(jí)別的代碼倉(cāng)庫(kù)怎么才能讓 AI 真正“讀懂”它注意不是那種“這個(gè)文件是干嘛的”的玩具級(jí)理解而是讓它面對(duì)一個(gè) bug、一次重構(gòu)、一次技術(shù)債清理時(shí)能像資深工程師一樣帶著全局上下文去思考。很多人第一反應(yīng)就是把倉(cāng)庫(kù)喂給 AI?？涩F(xiàn)實(shí)很骨感目前主流大模型的上下文窗口撐死了是百萬(wàn) token 級(jí)別聽(tīng)起來(lái)能裝下百萬(wàn)行真算下來(lái)裝不下。因?yàn)?token 不等于“行”真實(shí)的代碼里有注釋、縮進(jìn)、類名、超長(zhǎng)字符串一行代碼經(jīng)常要被拆成 4 到 8 個(gè) token。百萬(wàn)行的倉(cāng)庫(kù)全量塞進(jìn)去至少要消耗幾百萬(wàn) token先不說(shuō)成本就算硬塞進(jìn)去模型在超長(zhǎng)文本里的注意力也嚴(yán)重衰減關(guān)鍵的調(diào)用鏈早就被淹沒(méi)在代碼噪音里了。這篇文章我想把一條經(jīng)過(guò)真實(shí)項(xiàng)目驗(yàn)證的路線拆開(kāi)講為什么“全文背誦”式喂代碼行不通索引和檢索要怎么設(shè)計(jì)代碼塊應(yīng)該怎么拆混合檢索怎么做以及我在真實(shí)倉(cāng)庫(kù)里踩過(guò)的坑和排查經(jīng)驗(yàn)。不管你是正在研究 RAG、想做內(nèi)部 AI 編程助手還是想用 AI 管理遺留老項(xiàng)目這套思路都可以直接參考。1. 直接把百萬(wàn)行代碼塞給 AI先算賬再說(shuō)話1.1 上下文窗口的數(shù)字真相先做一道算術(shù)題。假設(shè)一個(gè)倉(cāng)庫(kù)有 100 萬(wàn)行代碼按平均每行 5 個(gè) token 算那就是 500 萬(wàn) token。市面上能買到的“超長(zhǎng)上下文”服務(wù)單次最大輸入也就 100 萬(wàn)到 200 萬(wàn) token看起來(lái)勉強(qiáng)能塞下但你必須給回答留出輸出空間。打了折扣之后真正能裝進(jìn)上下文的代碼大約只有一半剩下的一半就得靠截?cái)喽財(cái)嗟舻耐『檬钦麄€(gè)模塊的核心部分。更麻煩的是 token 單價(jià)。百萬(wàn) token 級(jí)別的輸入每次對(duì)話都在消耗大量算力哪怕是對(duì)一個(gè)大方點(diǎn)的團(tuán)隊(duì)一天問(wèn)上百個(gè)問(wèn)題光 token 費(fèi)用就夠買一臺(tái)不錯(cuò)的開(kāi)發(fā)機(jī)了。所以無(wú)論從成本還是技術(shù)可行性上把整個(gè)倉(cāng)庫(kù)塞進(jìn)提示詞都是一種偷懶且不可持續(xù)的做法。1.2 長(zhǎng)文本里的注意力衰減即便你財(cái)大氣粗把 100 萬(wàn) token 全部塞進(jìn)去模型的表現(xiàn)也遠(yuǎn)沒(méi)有想象中好。學(xué)術(shù)界和工程界都有大量實(shí)驗(yàn)證明當(dāng)上下文長(zhǎng)度增長(zhǎng)到一定程度后模型會(huì)更關(guān)注開(kāi)頭和結(jié)尾中間部分的信息會(huì)被“選擇性遺忘”。這在代碼場(chǎng)景里是致命的。舉個(gè)例子你問(wèn)它“登錄接口為什么會(huì)報(bào) 500”正確答案可能需要跨五個(gè)文件接口入口、參數(shù)校驗(yàn)、業(yè)務(wù)邏輯、ORM 映射、異常處理。這五個(gè)文件在倉(cāng)庫(kù)里分布在不同位置如果它們恰好落在長(zhǎng)上下文的中間地帶模型很可能會(huì)“自信地”漏掉最關(guān)鍵的那一環(huán)然后給你生成一個(gè)看起來(lái)很有道理、實(shí)際上完全錯(cuò)誤的排查結(jié)論。這種“幻覺(jué)式自信”比直接說(shuō)“不知道”害人得多。因?yàn)樗鼤?huì)把人帶偏等到你發(fā)現(xiàn)方向錯(cuò)了一兩個(gè)小時(shí)已經(jīng)過(guò)去了。1.3 “讀懂倉(cāng)庫(kù)”本質(zhì)上要一張活地圖換個(gè)角度想人在閱讀百萬(wàn)行代碼的時(shí)候也不是從頭到尾逐行背下來(lái)的。資深工程師打開(kāi)一個(gè)陌生倉(cāng)庫(kù)習(xí)慣是先看目錄、找入口文件、看依賴關(guān)系、讀接口文檔然后在需要深入時(shí)才展開(kāi)具體函數(shù)的實(shí)現(xiàn)。這其實(shí)就是“索引 按需加載”的思維。所以想讓 AI 讀懂倉(cāng)庫(kù)正確的做法不是讓 AI 記住所有代碼而是讓 AI 擁有一張可以隨時(shí)查閱的“倉(cāng)庫(kù)地圖”哪里有什么模塊、模塊之間怎么依賴、某個(gè)函數(shù)被哪些地方調(diào)用、某個(gè)類的關(guān)鍵屬性是什么。真正需要細(xì)節(jié)時(shí)再按圖索驥把相關(guān)代碼片段取出來(lái)。這才是工程上可行、成本可控、準(zhǔn)確率也更高的路子。2. 核心思路先用“地圖”代替“全文背誦”2.1 別急著向量化先做靜態(tài)結(jié)構(gòu)索引我見(jiàn)過(guò)很多團(tuán)隊(duì)一上手就把全部代碼切成小塊丟進(jìn)向量數(shù)據(jù)庫(kù)結(jié)果召回效果差得離譜。原因是代碼和自然語(yǔ)言不一樣自然語(yǔ)言靠詞義相關(guān)代碼更依賴符號(hào)、依賴與調(diào)用關(guān)系。你寫“用戶登錄失敗”嵌入模型能聯(lián)想到“authentication error”但如果問(wèn)的是“改了下單接口之后怎么影響積分發(fā)放”光靠語(yǔ)義搜索根本抓不住那條跨越多個(gè)服務(wù)的數(shù)據(jù)流。所以第一件事不是向量化而是靜態(tài)分析。用工具把倉(cāng)庫(kù)里的符號(hào)和關(guān)系抽出來(lái)函數(shù)、類、接口的定義位置與簽名文件與目錄的層級(jí)結(jié)構(gòu)import 關(guān)系與模塊依賴函數(shù)調(diào)用關(guān)系和類繼承關(guān)系路由表、配置項(xiàng)、數(shù)據(jù)庫(kù)表名等業(yè)務(wù)錨點(diǎn)這些信息構(gòu)建起來(lái)的“符號(hào)索引”和“依賴圖”才是 AI 理解代碼的基礎(chǔ)骨架。向量化只是索引之上的一個(gè)補(bǔ)充維度而不是全部。2.2 代碼分塊是一門學(xué)問(wèn)有了索引接下來(lái)要考慮的問(wèn)題就是喂給模型時(shí)代碼應(yīng)該按什么粒度切塊這個(gè)選擇直接決定了檢索質(zhì)量。分塊策略粒度優(yōu)點(diǎn)缺點(diǎn)適合場(chǎng)景按固定行數(shù)切最粗實(shí)現(xiàn)簡(jiǎn)單工作量小函數(shù)被切斷語(yǔ)義不完整緊急原型、小倉(cāng)庫(kù)按函數(shù)或方法切中等語(yǔ)義邊界清晰檢索準(zhǔn)確小函數(shù)太多索引量大絕大多數(shù)業(yè)務(wù)代碼按類或模塊切較粗帶上類屬性和方法全集上下文冗長(zhǎng)成本高架構(gòu)理解、模塊級(jí)問(wèn)答按文件切粗結(jié)構(gòu)最簡(jiǎn)單大文件容易超上下文文檔生成、代碼概覽我在實(shí)操中最推薦的是“函數(shù)級(jí)切塊 類級(jí)摘要”的組合一個(gè)函數(shù)作為一個(gè)獨(dú)立索引單元保證檢索時(shí)拿到的代碼是完整、可執(zhí)行的同時(shí)為每個(gè)類生成一段摘要描述這個(gè)類是什么、核心職責(zé)是什么這樣檢索到函數(shù)時(shí)還能把所屬類的摘要一起帶上讓 AI 補(bǔ)足上下文。一個(gè)常見(jiàn)的錯(cuò)誤是切塊切得太碎。有人把每個(gè)函數(shù)單獨(dú)切完后把函數(shù)名也丟了只保留函數(shù)體。結(jié)果檢索時(shí)命中了一個(gè)匿名片段模型根本不知道它屬于哪個(gè)類、哪個(gè)模塊。切塊時(shí)一定要保留完整的“索引元數(shù)據(jù)”文件路徑、類名、函數(shù)簽名、調(diào)用關(guān)系、依賴信息。這就像讀書時(shí)不能只把某一頁(yè)撕下來(lái)必須在書頁(yè)上留下頁(yè)碼和章節(jié)名。2.3 混合檢索關(guān)鍵詞、語(yǔ)義、依賴關(guān)系三條腿走路純靠向量搜索在代碼場(chǎng)景里很容易翻車。比如“登錄”和“認(rèn)證”在語(yǔ)義上相近但代碼里可能對(duì)應(yīng)完全不同的模塊而一個(gè)變量的名字完全無(wú)關(guān)卻因?yàn)橘x值鏈關(guān)系決定了另一個(gè)接口的行為。單一策略無(wú)法應(yīng)對(duì)這種復(fù)雜性所以我一直推薦混合檢索。我常用的組合是三類召回方式關(guān)鍵詞召回基于 BM25 或 Elasticsearch用來(lái)命中函數(shù)名、變量名、注釋里的專業(yè)術(shù)語(yǔ)。這種方式對(duì)“我只記得有個(gè)函數(shù)叫 parse_token”這類問(wèn)題非常管用。語(yǔ)義召回基于向量嵌入把自然語(yǔ)言問(wèn)題映射到代碼語(yǔ)義空間適合“模糊記得功能不記得名字”的場(chǎng)景。依賴圖召回當(dāng)命中了某個(gè)函數(shù)后順著依賴圖把它的調(diào)用者、被調(diào)用者、關(guān)聯(lián)類一起拉出來(lái)相當(dāng)于給 AI 配了條“沿著調(diào)用鏈找問(wèn)題”的路徑。把三類結(jié)果合并、去重、按相關(guān)度排序后再作為上下文交給模型準(zhǔn)確率會(huì)比單一路徑高一個(gè)量級(jí)。這部分你可能覺(jué)得聽(tīng)起來(lái)復(fù)雜但實(shí)際做下來(lái)只要管線搭好后續(xù)維護(hù)成本并不高。3. 實(shí)操給百萬(wàn)行倉(cāng)庫(kù)做一個(gè)能問(wèn)答的索引3.1 準(zhǔn)備一個(gè)真實(shí)的倉(cāng)庫(kù)作為實(shí)驗(yàn)對(duì)象如果你還沒(méi)想好拿什么倉(cāng)庫(kù)練手就在 Gitee 上找一個(gè)你熟悉的中型開(kāi)源項(xiàng)目或者直接拿自己公司的老項(xiàng)目 clone 一份。注意克隆下來(lái)先不要把整個(gè)倉(cāng)庫(kù)推給 AI我們要做的是給倉(cāng)庫(kù)建索引所以只需要本地有完整代碼就行。我建議第一次實(shí)驗(yàn)選擇一個(gè)規(guī)模在 10 萬(wàn)到 20 萬(wàn)行之間的項(xiàng)目。太小沒(méi)有參考價(jià)值太大做起來(lái)太慢容易挫敗信心。等整條鏈路跑通再擴(kuò)展到百萬(wàn)行倉(cāng)庫(kù)。環(huán)境準(zhǔn)備也很簡(jiǎn)單Python 3.10 以上裝好 tree-sitter 用于語(yǔ)法解析裝一個(gè)向量數(shù)據(jù)庫(kù)我用的是 Chroma方便本地起服務(wù)。嵌入模型可以用通用 embedding 服務(wù)也可以本地跑一個(gè)小模型。我自己的經(jīng)驗(yàn)是代碼專用嵌入模型的效果會(huì)比通用模型好很多但如果你只是想先跑通流程用現(xiàn)成的通用 embedding 也完全沒(méi)問(wèn)題。3.2 用 tree-sitter 做函數(shù)級(jí)切塊tree-sitter 是當(dāng)前做代碼解析比較順手的工具它支持幾十種語(yǔ)言能把源碼解析成語(yǔ)法樹(shù)再通過(guò)語(yǔ)法樹(shù)精確定位每個(gè)函數(shù)聲明的起始行和結(jié)束行。這樣切出來(lái)的塊不會(huì)截?cái)嗪瘮?shù)也不會(huì)把兩個(gè)函數(shù)粘在一起。我用一個(gè) Python 例子演示切塊思路from tree_sitter import Language, Parser def extract_functions(source_bytes, tree, namespace): functions [] root tree.root_node def walk(node): if node.type function_definition: name_node node.child_by_field_name(name) if name_node is None: return func_name name_node.text.decode(utf-8) full_name f{namespace}.{func_name} if namespace else func_name start node.start_point[0] end node.end_point[0] code source_bytes[node.start_byte:node.end_byte].decode(utf-8, errorsignore) functions.append({ id: full_name, name: func_name, file: namespace, start_line: start, end_line: end, code: code, }) return # 不往更深層再找嵌套函數(shù) for child in node.children: walk(child) walk(root) return functions實(shí)際使用不需要你親自實(shí)現(xiàn)語(yǔ)法樹(shù)遍歷那么底層很多開(kāi)源工具都有現(xiàn)成的函數(shù)抽取功能比如 pycparser、jedi、ctags以及各種語(yǔ)言的 AST 庫(kù)。但理解原理很重要切塊的顆粒度決定了檢索精度精確到函數(shù)比精確到行好得多。3.3 構(gòu)建向量索引與元數(shù)據(jù)索引切完塊之后下來(lái)的任務(wù)是把每個(gè)函數(shù)塊向量化并寫入數(shù)據(jù)庫(kù)。import chromadb from chromadb.utils import embedding_functions client chromadb.PersistentClient(path./code_index) collection client.get_or_create_collection( namerepo_code, embedding_functionembedding_functions.DefaultEmbeddingFunction() ) # 假設(shè) functions 是上一步提取的函數(shù)列表 for f in functions: metadata { file: f[file], name: f[name], start_line: f[start_line], end_line: f[end_line], } collection.upsert( ids[f[id]], documents[f[code]], metadatas[metadata] )向量化這一步要特別關(guān)注成本。一個(gè)百萬(wàn)行倉(cāng)庫(kù)切出來(lái)的函數(shù)塊可能有幾萬(wàn)甚至十幾萬(wàn)條每條都要過(guò)一次嵌入模型時(shí)間不短費(fèi)用也不低。如果單位預(yù)算有限我建議挑最核心的模塊先建索引比如業(yè)務(wù)主流程、支付、登錄、權(quán)限這些高價(jià)值區(qū)域外圍的工具類、測(cè)試代碼可以先不建。同時(shí)別把元數(shù)據(jù)只放在向量庫(kù)的 metadata 里。我通常會(huì)另外用一張 SQLite 表專門存“符號(hào)表”函數(shù)名、文件、行號(hào)、調(diào)用者和被調(diào)用者。這樣在向量召回命中后我能立刻通過(guò)這張表把調(diào)用鏈、依賴關(guān)系查出來(lái)作為混合檢索的補(bǔ)充輸入。3.4 組裝讓 AI“讀懂”的上下文模板索引建好后真正的核心環(huán)節(jié)是“如何把檢索結(jié)果組裝成 prompt”。這一步最容易被忽略但也最影響效果。我先說(shuō)一個(gè)反面案例。有人把檢索到的代碼直接丟給 AI沒(méi)有任何說(shuō)明。結(jié)果 AI 看到一堆碎片化的函數(shù)定義完全不知道這些問(wèn)題之間的關(guān)系只能從函數(shù)名猜測(cè)回答自然不靠譜。我平時(shí)用的模板長(zhǎng)這樣你是一名資深工程師。下面是代碼倉(cāng)庫(kù)中與問(wèn)題相關(guān)的上下文片段。 每個(gè)片段包含文件路徑、函數(shù)簽名、調(diào)用關(guān)系和代碼內(nèi)容。 用戶問(wèn)題{question} 上下文 --- 片段 1 --- 文件{file_path} 類或模塊{class_name} 函數(shù){signature} 調(diào)用關(guān)系{callers} - {callees} 代碼 {code_snippet} --- 片段 2 --- ...關(guān)鍵點(diǎn)在于把“調(diào)用關(guān)系”顯式寫出來(lái)。AI 不一定能從函數(shù)體里看出誰(shuí)在調(diào)用它但如果你把“這個(gè)函數(shù)被 login_service.py 里的 authenticate() 調(diào)用”寫清楚它的推理路徑就清晰了很多。然后檢索邏輯是這樣的用戶輸入問(wèn)題先做一個(gè) Query Rewrite比如把“登錄失敗”改寫為“authenticate 異常返回錯(cuò)誤碼 500涉及 login 接口”。用改寫后的 query 做混合檢索關(guān)鍵詞查一遍、向量查一遍、符號(hào)表里再查一遍調(diào)用鏈。取 top 8 到 10 個(gè)片段按相關(guān)度排序。拼進(jìn)模板整體交給大模型。實(shí)測(cè)下來(lái)這種“先改寫、再檢索、再結(jié)構(gòu)化拼裝”的流程比“直接拿原始問(wèn)題搜索、拼原始代碼”的準(zhǔn)確率至少高 30%。原因很樸素大模型對(duì)“你到底想查什么”的理解遠(yuǎn)強(qiáng)于傳統(tǒng)關(guān)鍵詞搜索引擎。3.5 實(shí)測(cè)一輪的效果記錄我曾經(jīng)在一個(gè) 50 萬(wàn)行的老項(xiàng)目上做過(guò)實(shí)驗(yàn)。項(xiàng)目的結(jié)構(gòu)非?；靵y模塊之間互相 import循環(huán)依賴都有好幾處。我用上面的方案搭建了一個(gè)簡(jiǎn)單的問(wèn)答助手然后故意問(wèn)了一個(gè)跨多個(gè)模塊的問(wèn)題“用戶下單后沒(méi)有收到積分是什么原因造成的”系統(tǒng)檢索到的情況是語(yǔ)義搜索命中了下單接口 and 積分發(fā)放方法關(guān)鍵詞搜索命中了“integral”和“order”相關(guān)函數(shù)依賴圖發(fā)現(xiàn)積分發(fā)放方法被一個(gè)異步任務(wù)調(diào)用而異步任務(wù)的觸發(fā)條件依賴訂單狀態(tài)回調(diào)三路結(jié)果合并后最終推給模型的是下單接口的片段、積分發(fā)放方法的片段、以及訂單回調(diào)模塊的調(diào)用關(guān)系鏈。模型給出的結(jié)論是“積分發(fā)放方法本身沒(méi)問(wèn)題但它在異步回調(diào)中的觸發(fā)條件被上游限流策略擋掉了?！边@個(gè)結(jié)論后來(lái)被開(kāi)發(fā)同學(xué)驗(yàn)證為真實(shí)原因。如果在傳統(tǒng)全文搜索下要找到這條鏈路大概得手動(dòng)翻上很久。這個(gè)案例說(shuō)明混合檢索的價(jià)值不是某一路特別強(qiáng)而是三路互補(bǔ)后能把“正確的碎片”拼成“正確的邏輯鏈”。4. 真實(shí)倉(cāng)庫(kù)里踩坑最多的 5 個(gè)點(diǎn)4.1 檢索到的代碼“相關(guān)”但不是“根因”這是最讓人崩潰的坑?？雌饋?lái) AI 引用的代碼確實(shí)跟問(wèn)題相關(guān)文件名對(duì)、函數(shù)名也對(duì)但問(wèn)題的真正根因在另外一個(gè)不相關(guān)的文件里。原因是檢索器只圍繞“字面相關(guān)”做匹配而代碼缺陷往往藏在隱式約定里比如兩次調(diào)用的時(shí)序、全局變量的狀態(tài)、配置文件里的開(kāi)關(guān)。排查思路是別讓 AI 只看一次檢索結(jié)果而是給它多輪迭代的權(quán)限。比如第一輪先讓它定位候選模塊第二輪要求它沿著調(diào)用鏈向外擴(kuò)一跳再看有沒(méi)有更深的線索。我見(jiàn)過(guò)不少團(tuán)隊(duì)把單次檢索當(dāng)作最終結(jié)果這是對(duì) RAG 的誤用。4.2 prompt 上下文塞得太滿反而變傻有些人覺(jué)得檢索到的片段越多越保險(xiǎn)一口氣塞 50 個(gè)函數(shù)進(jìn)去結(jié)果模型上下文被大量無(wú)關(guān)信息占滿回答質(zhì)量肉眼可見(jiàn)地下降。我實(shí)踐下來(lái)的結(jié)論是對(duì)絕大多數(shù)問(wèn)題top 10 個(gè)片段就夠了。超過(guò)這個(gè)數(shù)量信息密度迅速下降模型開(kāi)始“平均分配注意力”甚至?xí)荒承┑拖嚓P(guān)度的片段帶偏?？梢约右粋€(gè)重排序環(huán)節(jié)把粗排結(jié)果用更精細(xì)的模型重新打分再?zèng)Q定保留哪幾個(gè)。重排序模型不復(fù)雜現(xiàn)在很多開(kāi)源方案直接支持比如 bge-reranker 系列輸入一個(gè) query 一個(gè)文檔輸出打分。把它加在向量檢索之后效果提升非常明顯。4.3 倉(cāng)庫(kù)一直在變索引更新跟不上真實(shí)項(xiàng)目的代碼每天都在變?nèi)绻憬o AI 建的索引還是上周的回答必然過(guò)時(shí)。很多團(tuán)隊(duì)以為索引是一次性的建完就再也不管結(jié)果兩周后所有答案都開(kāi)始失真。我建議給索引建立增量更新機(jī)制。最簡(jiǎn)單的方式是監(jiān)聽(tīng) Git 提交或者 Gitee 倉(cāng)庫(kù)的 Webhook每次有合并請(qǐng)求時(shí)只重新向量化變更文件涉及到的函數(shù)塊而不是全量重建。全量重建一個(gè)百萬(wàn)行倉(cāng)庫(kù)可能要跑一整個(gè)晚上但增量更新通常幾分鐘就能完成。這個(gè)差別直接影響開(kāi)發(fā)同學(xué)愿不愿意用你的 AI 助手。4.4 代碼塊重疊錯(cuò)誤互相污染還有一次我排查一個(gè)異常發(fā)現(xiàn) AI 給出的代碼里把兩個(gè)同名函數(shù)的實(shí)現(xiàn)搞混了。原因是項(xiàng)目里有多個(gè)同名函數(shù)分別屬于不同類切塊時(shí)只按函數(shù)名做 ID導(dǎo)致向量庫(kù)里出現(xiàn)了重復(fù) ID部分?jǐn)?shù)據(jù)被覆蓋。這個(gè)教訓(xùn)后面我改成用“文件路徑 類名 函數(shù)名 起始行”生成唯一 ID才徹底解決。切塊后的 ID 必須保證全局唯一否則你根本不知道自己檢索到的是哪一份代碼。4.5 權(quán)限和合規(guī)容易被忽略企業(yè)內(nèi)部倉(cāng)庫(kù)很多涉及敏感業(yè)務(wù)邏輯把代碼交給云端大模型處理時(shí)要考慮數(shù)據(jù)出境和內(nèi)部合規(guī)問(wèn)題。我不建議把敏感代碼直接發(fā)往第三方服務(wù)可以優(yōu)先考慮本地部署的開(kāi)源模型或者先做代碼脫敏把變量名、注釋里的業(yè)務(wù)關(guān)鍵詞替換成無(wú)關(guān)符號(hào)只保留結(jié)構(gòu)信息。這一點(diǎn)看起來(lái)不像技術(shù)問(wèn)題但在實(shí)際項(xiàng)目中往往是卡得最久的流程早點(diǎn)想清楚能省不少事。5. 讓這套能力落進(jìn)團(tuán)隊(duì)幾條被驗(yàn)證過(guò)的經(jīng)驗(yàn)5.1 先定“讀懂”的邊界別一上來(lái)就做全能助手“讓 AI 讀懂倉(cāng)庫(kù)”這句話范圍太大了。落到團(tuán)隊(duì)里最常見(jiàn)的失敗誤區(qū)是試圖做一個(gè)什么都能干的 AI 助手結(jié)果什么都做不精。我更推薦把它拆成幾個(gè)具體能力逐個(gè)擊破解釋能力給定一個(gè)函數(shù)AI 能說(shuō)明它是干什么的、涉及哪些依賴。定位能力讓 AI 從倉(cāng)庫(kù)中找出可疑代碼塊而不是直接給結(jié)論。審查能力給 AI 一個(gè) diff讓它基于倉(cāng)庫(kù)全局上下文做代碼審查。重構(gòu)支持讓 AI 梳理解耦關(guān)系指出哪些模塊可以拆分。每項(xiàng)能力對(duì)檢索粒度和上下文要求都不一樣。比如“解釋能力”只要函數(shù)級(jí)索引就夠“重構(gòu)支持”則必須依賴完整的依賴圖。先做“定位”和“解釋”這兩條線性價(jià)比最高也最容易讓團(tuán)隊(duì)看到效果。5.2 用“多 AI 協(xié)作”代替“一個(gè)大模型包辦一切”這里特別想聊一下最近很火的多 AI 協(xié)作。做倉(cāng)庫(kù)理解這件事天然適合拆成多個(gè)角色而不是讓一個(gè)模型同時(shí)扮演“檢索引擎 分析引擎 結(jié)論引擎”。我現(xiàn)在的實(shí)踐方式一個(gè) Agent 負(fù)責(zé)“信息檢索”專門做查詢改寫、混合搜索、重排序。一個(gè) Agent 負(fù)責(zé)“代碼分析”拿到檢索結(jié)果后做靜態(tài)推理給出一份“線索清單”。一個(gè) Agent 負(fù)責(zé)“回答生成”基于線索清單組織語(yǔ)言輸出結(jié)論。這么做的好處是每個(gè) Agent 只要做好一件小事整體可控性強(qiáng)很多。哪怕某一個(gè)環(huán)節(jié)出錯(cuò)你也能清楚看見(jiàn)錯(cuò)在哪一步而不是面對(duì)一個(gè)“看起來(lái)都合理但不知道哪一步幻覺(jué)”的最終答案。5.3 把用戶的反饋?zhàn)兂伤饕酿B(yǎng)分最后一條經(jīng)驗(yàn)來(lái)自實(shí)踐AI 讀懂倉(cāng)庫(kù)不是一個(gè)一次性工程它需要不斷被使用、被糾錯(cuò)、被優(yōu)化。我每次做完檢索都會(huì)在系統(tǒng)里記錄一個(gè)問(wèn)題哪幾個(gè)片段最終進(jìn)入了 prompt用戶后來(lái)有沒(méi)有點(diǎn)“這個(gè)回答有用”。如果某個(gè)回答被點(diǎn)贊說(shuō)明這幾片代碼的組合是有效索引如果被點(diǎn)踩我就去看模型到底被哪段代碼帶偏了然后調(diào)整分塊策略或重排序權(quán)重。這聽(tīng)起來(lái)不像技術(shù)點(diǎn)但它才是讓“倉(cāng)庫(kù)理解”效果持續(xù)變好的真正引擎。你建的索引再完美也一定有覆蓋不到的長(zhǎng)尾場(chǎng)景反饋閉環(huán)能幫你用最少的成本覆蓋住這些長(zhǎng)尾。我自己的體會(huì)是做 AI 與代碼倉(cāng)庫(kù)的結(jié)合最終 60% 的功夫都花在數(shù)據(jù)治理上模型只是最后讀報(bào)告的人。先把代碼索引、依賴關(guān)系、分塊質(zhì)量這些基本功做扎實(shí)AI 自然“讀懂”得快。反過(guò)來(lái)如果只盯著模型參數(shù)量倉(cāng)庫(kù)里的代碼還是一團(tuán)亂麻再聰明的模型也只能給你一個(gè)看起來(lái)聰明、實(shí)際到處碰壁的答案。