實測 codegraph:給 agent 一張預建的代碼地圖,少爬一大半

你看到的樣子

讓 AI 改一份它沒看過的程式碼,它預設會用最笨的方式理解:grep 一下、開幾個檔、再開幾個檔,自己在腦裡拼出「誰呼叫誰、改這裡會動到哪」。真正動手前,先燒掉一堆來回。

預建代碼圖譜(像 codegraph 這類工具)換個做法:先把每個符號、每條呼叫關係、每個依賴解析進一個本地索引(用 tree-sitter 解析、存進 SQLite、透過 MCP 給 agent 用)。之後 agent 問一句,就直接拿回「相關的程式碼 + 它們之間的呼叫路徑 + 改這裡的影響範圍」。

實測觀察

我拿它跟「沒有圖、純靠 agent 自己爬」對比,觀察到的差異很明顯:大約少一半的工具呼叫(~58%)、整體快約兩成、檔案開啟次數趨近於零。原因不神祕——把「搞清楚結構」這件事,從執行期(agent 邊做邊爬)搬到了索引期(事先建好)。agent 拿到的是「答案大小」的脈絡,而不是「檔案數量」的脈絡。

可遷移的點,跟它的代價

可遷移的觀念是:這是一種 context engineering——與其把一堆檔塞進模型讓它自己找,不如先把結構整理好、只餵它需要的那塊。代價也很誠實:你得維護索引的新鮮度(檔案一改,圖要跟著更新),所以這類工具都得配一個檔案監看、過期提醒的機制。

一條評估原則:看一手證據

最後記一條我評估任何工具都用的原則:看一手證據,別信宣傳數字。 上面那個「58%」也一樣——它是工具自己的 benchmark + 我自己對比時的觀察,不是第三方公證。真正可信的訊號是:它的原始碼、它的 issue 區、以及你自己在自己的專案上跑一遍。聚合網站的星數、README 上的漂亮數字,都只是參考。工具值不值得用,自己測一遍最準。