AI 寫程式碰大型專案就變笨？程式碼索引與 Context 預算解法

用 Cursor、Claude Code 這類工具在小專案上寫程式很順手，但一換到有數萬甚至數十萬行程式碼的專案，代理常常開始亂猜：搜尋撈出一堆不相關的結果、把整個檔案讀進去、來回翻找，token 用得很快但答案還是不準。原因不是模型變笨了，而是「程式碼搜尋」本身是一個預算問題——人類看到一堆搜尋結果可以一眼略過雜訊，模型卻得把每一行都塞進有限的 context 裡消化。

為什麼專案一大，AI 就開始亂猜？

grep（在檔案裡搜尋文字的指令）在小專案裡很好用，因為結果少、雜訊也少。但專案一大，同一個關鍵字可能命中幾十、幾百處，代理如果照單全收，或乾脆把整個檔案讀進去確認，就會把大量 context 預算耗在跟問題無關的程式碼行數上。這件事在實測裡看得很清楚：有工具做過對照，用 ripgrep 搜尋再把整個檔案讀進去，一次查詢可能吃掉四萬五千多個 token，而如果用專門設計過的檢索工具只回傳真正相關的片段，同一個查詢可能只需要五百多個 token，差距接近 98%。

換句話說，代理不是「找不到」答案，而是「找到太多、看得太雜」，把預算燒在無關的地方，留給真正推理的空間就變少了，答案自然容易失準。

好工具該回傳「最小證據包」，而不是取代 grep

如果搜尋工具的目標是省 token，最直接的做法不是完全取代 grep，而是讓回傳的東西更精準。一個好的證據包應該具備幾個特徵：夠小、標明位置（檔案路徑與行範圍）、包含足夠讓代理理解上下文的資訊，而且必要時可以「升級」——代理判斷片段不夠用時，還是能選擇打開完整檔案。這個設計思路背後的邏輯是：與其一開始就給代理全部資訊要它自己篩選，不如先給精簡但足夠的線索，讓它按需要再深入。

順著這個思路，目前實務上大致有兩條路線：一條是把程式碼庫先解析成知識圖譜，讓代理可以直接查詢結構與關係；另一條是把程式碼當成搜尋引擎的語料，用檢索排序技術找出最相關的片段。

路線一：知識圖譜索引——把程式碼庫變成可查詢的圖

codebase-memory-mcp 是這條路線的代表。它的做法是用 tree-sitter（一套通用的程式語法解析工具）做語法解析，再結合 AST（抽象語法樹，程式碼結構化後的樹狀表示）分析與 Hybrid LSP（語言伺服器協定，能做語意層級的型別解析）建立函式、類別、呼叫鏈之間的關係圖，讓代理可以直接查詢「這個函式被誰呼叫」「改了這裡會影響哪些地方」，而不用自己一檔一檔翻。

幾個比較具體的數字：它支援的語言數量從最初的 158 種，隨版本更新增加到 162 種；一般專案索引通常在毫秒等級完成，即使是 Linux kernel 這種規模（約 2,800 萬行程式碼）也能在 3 分鐘內建完，產生約 481 萬個節點、772 萬條邊；結構查詢的回應速度多在 1 毫秒以下，其中 Cypher 圖查詢與符號搜尋都在 1 毫秒以下，調用鏈追蹤在 10 毫秒以下，語意搜尋約 15 毫秒，死碼檢測約 50 毫秒，架構概覽約 80 毫秒。

Token 節省的效果同樣明顯：官方對照顯示，同樣是追蹤一條完整呼叫鏈，傳統的逐檔探索可能要消耗約 41 萬個 token，用知識圖譜查詢只要約 3,400 個，差距約 99.2%；類似的落差也出現在架構總覽、變更影響分析、死碼檢測這幾類任務上，工具呼叫次數也普遍從 5 到 10 次降到 1 到 2 次。

它總共提供 14 個 MCP 工具（涵蓋索引、搜尋、分析、協作、工具五類），其中 trace_path（追蹤完整呼叫鏈與影響範圍）跟 get_architecture（快速摸清整體架構）算是比較關鍵的兩個。查詢語言用的是 Cypher 的子集。

工程面上，根據官方 GitHub 說明，它是純 C 語言實作、單一靜態二進位檔、零依賴，不需要 Docker、不需要 API key，整個處理都在本機完成、程式碼不會上傳到伺服器。目前已支援 Claude Code、Codex CLI、Gemini CLI、Cursor、Zed 等超過三十種 AI 編程工具的自動偵測與設定。

適合的情境包括：想快速摸清一個陌生大專案的架構、改動函式前想先評估影響範圍、想清理沒人用的死碼，或是微服務架構下想追蹤跨服務的呼叫關係。導入前也要注意一些現實面：需要安裝到開發環境、寫入代理的設定檔，代表它會接觸到你的程式碼庫與工具設定，團隊如果有安全政策，這部分需要先過一輪檢查，而且工具本身的長期穩定性也還在靠社群持續驗證。

路線二：檢索排序索引——像搜尋引擎一樣找程式碼

Semble 走的是另一條路，核心主張跟前面提到的「搜尋是預算問題」是同一套邏輯：程式碼代理在用 grep 或整檔讀取時，浪費掉的大部分 context 預算其實都花在跟問題無關的內容上。

它的做法比較接近搜尋引擎：先用程式碼感知的方式切分程式碼（不是死板地按行數切，而是照函式、類別等結構切），再用 BM25（一種經典的文字檢索演算法）搭配靜態嵌入模型（Model2Vec，不需要呼叫大型語言模型就能算出語意向量）分別打分，用 RRF（Reciprocal Rank Fusion，一種融合多組排序結果的方法）把兩邊結果合併，最後再用一層程式碼感知的重排序做微調——這一層會看符號權重、是不是函式或類別的定義、識別字詞幹是否匹配、同一檔案內容的一致性,以及是否有雜訊,綜合調整排序。

它有一套跨語言的基準測試,涵蓋 19 種語言、63 個程式碼儲存庫、大約 1,250 條查詢。結果顯示 Semble 的 NDCG@10（一種評估搜尋排序品質的指標,數值愈高代表相關結果排得愈前面）約 0.854,跟另一款需要呼叫嵌入模型的 CodeRankEmbed Hybrid（約 0.862）相近,但明顯超過單純的 BM25（0.673)和單純的 ripgrep（0.126)。也就是說，即使不依賴額外的嵌入 API，光靠 BM25 加靜態嵌入加重排序，就能拿到接近頂尖方案的排序品質。

Token 節省的實測數字也很直接：同一批查詢,用 ripgrep 加完整讀檔要花約 45,692 個 token,用 Semble 只要約 566 個,節省比例約 98%。

整合方式上,Semble 提供 MCP 伺服器、CLI 指令列、Python API,以及寫進 AGENTS.md 或 CLAUDE.md（代理設定檔）的 Bash 整合。這裡有一個實務上容易忽略的細節：如果你用的是 Claude Code 或 Codex CLI 這類支援子代理（sub-agent）的工具,子代理往往沒辦法直接呼叫 MCP 工具,這時候應該用 Bash 整合的方式接進去,而不是只設定 MCP。

兩條路線怎麼選

面向	知識圖譜索引（codebase-memory-mcp）	檢索排序索引（Semble）
核心做法	tree-sitter + AST + Hybrid LSP 建立結構關係圖	BM25 + 靜態嵌入 + RRF + 程式碼感知重排序
強項	精確的呼叫鏈、依賴關係、架構總覽查詢	語意相關的片段檢索、跨語言查詢一致性高
索引速度	一般專案毫秒級，超大型專案（如 Linux kernel）數分鐘	依儲存庫規模與切分策略而定
部署形式	單一靜態二進位檔、零依賴、本機離線	MCP、CLI、Python API 多種形式
語言支援	158～162 種，部分語言有進一步的語意型別解析	基準測試涵蓋 19 種語言
適合情境	想問「這個函式改了會影響誰」這類結構性問題	想問「哪裡有處理這個邏輯」這類語意性問題

實務上這兩者不一定互斥：如果專案本身呼叫關係複雜、常常要做影響分析或架構盤點，知識圖譜的優勢比較明顯；如果團隊更常是「找相關程式碼片段來讀」這種語意搜尋需求，檢索排序式的效率會更直接反映在 token 節省上。兩者都可以用 MCP 的方式接進 Claude Code 或其他支援 MCP 的代理工具，不需要大改現有的開發流程。

延伸視角：基礎建設,而不只是模型,才是代理式開發的瓶頸

2026 年 9 月 19 日，DeepSeek 發布了一篇論文,首度揭露支撐它 Agent 訓練背後的沙箱基礎設施——DSec（DeepSeek Elastic Compute）。這是一套生產級的沙箱平台,DeepSeek V3.2 到 V4.1 所有的 Agentic RL（強化學習）訓練、評測、環境構建全部跑在上面,規模是 160 台 CPU 節點、3 萬核心、250 TB 記憶體,單日服務 300 萬個沙箱,峰值並發超過 38 萬,沙箱創建速率每秒超過 5,000 個。

這套系統花了大量工程心力解決的問題,聽起來跟程式碼索引離得很遠,但邏輯是相通的：它把環境拆成 Base Image、Workspace、Toolkit 三層,各自獨立版本化、唯讀、在執行時動態組合,把維護成本從隨版本數量線性增長壓到接近固定;用內存共享與按需加載的方式,讓運行時只需要讀取鏡像裡 4.2% 到 13.3% 的資料,大幅降低啟動與資源消耗;論文也提到訓練過程中出現覆蓋系統檔案、交換檔案資料塊、掃描網路及觸發核心崩潰等異常行為，並用 AppArmor、eBPF 這類機制做防護。

這說明一件事：讓 Agent 真正好用,往往不是單靠換一顆更強的模型就能解決。Claude 官方文件也提到，大多數工作負載建議從目前的旗艦模型開始，只有要求特別嚴苛的長時程推理任務才需要考慮更進階的版本——但即使換了更強的模型，如果代理在搜尋程式碼這一步就把大半預算浪費在無關的行數上，模型能發揮推理能力的空間本來就被壓縮了。不管是 DeepSeek 為訓練 Agent 搭的沙箱平台,還是幫程式碼代理做的索引層,本質上都是在補「基礎建設」這一塊——這塊做得好不好,決定了模型的能力能不能真正發揮出來。

自檢清單：你的專案該不該導入索引層

不是每個專案都需要額外裝一層程式碼索引工具，可以先問自己幾個問題：

• 專案規模：程式碼庫是不是已經大到代理常常要跨好幾個檔案才能回答一個問題？如果只是幾千行的小專案，額外導入索引層的效益可能不明顯。
• 團隊型態：你是不是在維護大型 monorepo（單一儲存庫管理多個專案）或微服務架構，經常需要追蹤跨服務、跨模組的呼叫關係？這類情境特別適合知識圖譜式的查詢。
• 常見任務類型：你更常需要的是「這裡改了會影響誰」這種結構性問題，還是「哪裡有處理類似邏輯」這種語意性問題？前者偏向知識圖譜，後者偏向檢索排序。
• 導入成本能不能接受：這類工具通常需要安裝到開發環境、寫入代理設定檔，代表它會接觸到你的程式碼與工具設定，如果團隊有明確的安全政策，需要先確認是否符合。
• 對本機處理的要求：如果你在意程式碼不能外流，可以留意工具是否明確標示本機離線處理、不上傳伺服器，以及有沒有相關的安全認證。
• 穩定性能不能承受風險：這類新興工具的長期穩定性多半還在靠社群持續驗證，如果是關鍵專案，建議先在非核心分支或工具鏈上小範圍試用。

如果上面幾點你點頭的比較多，代表你的專案很可能正卡在前面說的「context 預算」問題上，值得花時間評估導入一層索引或檢索工具；如果專案本來就不大、任務也單純，那先把 提示詞 寫清楚、善用現有工具的搜尋功能，可能就夠用了。想先搞懂不同 AI 寫程式工具的差異，也可以參考 Codex、Cursor、Claude Code 怎麼選 這篇比較。