AI 知識

AI 寫程式為什麼這麼燒 Token？因為它常常沒有專案地圖

AI 知識｜AI 編程｜2026-07-05

AI coding agent 讓人期待的地方，是它可以幫你讀 code、改 code、寫測試、理解大型專案。

但真正用過複雜 codebase 的人都知道，很多時候 AI 不是不會寫，而是還沒搞懂專案就開始動手。

你問它：「這個函式會影響哪裡？」

它可能先 grep 一次，打開幾個檔案，再追 import，再讀更多檔案，再把一大段不一定有用的內容塞進上下文。問題還沒真正回答，token 已經大量消耗。

這不是單一模型的問題，而是 AI 探索程式碼的方式本身有成本。

問題不只是上下文不夠長

很多人遇到 AI 看不懂大型專案，第一反應是：那就給它更長的 context window。

但長上下文不是免費午餐。

把更多檔案塞進去，確實可能提高命中率，卻也會帶來三個問題：

第一，成本變高。每一次讀檔、貼上下文、追路徑，都會變成 token。

第二，雜訊變多。模型看見更多內容，不代表它更知道哪一段重要。

第三，注意力被稀釋。大型專案裡真正關鍵的可能只有幾個函式、幾條呼叫鏈、幾個 API route，但模型可能被大量旁枝資訊拖走。

所以關鍵問題不是「上下文能不能再大一點」，而是「AI 能不能先知道該看哪裡」。

先把 codebase 變成地圖

Codebase Memory MCP 這類工具的核心思路，是把專案先建立成 persistent knowledge graph。

也就是把函式、class、call chain、HTTP route、跨服務關係、檔案結構等資訊整理成一張可以查詢的圖。

這樣 AI coding agent 遇到結構問題時，就不用每次重新從資料夾裡盲找。

它可以先問圖：

這個函式被誰呼叫？

這個 API route 往下接到哪裡？

這個 class 影響哪些模組？

某個服務的入口點在哪？

回答這類問題時，knowledge graph 比「反覆 grep + 讀檔」更像一張地圖。

AI 仍然需要讀 code，也仍然需要測試與驗證。但它不必每次都從零開始找路。

benchmark 數字要小心看

公開資料裡，Codebase Memory MCP 有不同口徑的效能敘事。

專案頁與展示資料強調，某些結構查詢可大幅降低 token，甚至出現約 120x 的敘事。arXiv 論文中的正式比較則更保守：在 31 個真實 repositories 上，MCP Agent 達到 83% answer quality，相比 file-exploration agent 的 92%，但 token 約少 10 倍，tool calls 約少 2.1 倍。

這兩種說法不必硬湊成同一個數字。

比較正確的理解是：不同問題、不同 repository、不同查詢方式，省下的 token 會差很多。

但方向是一致的。

只要任務是「理解結構」，先查圖通常比盲目讀檔有效率。

它不能取代工程判斷

這類工具很有價值，但也不能神化。

knowledge graph 擅長回答結構問題，不等於它知道所有業務意圖。

它能幫 AI 找到呼叫鏈，但不代表它能直接判斷需求是否合理。

它能幫 AI 縮小閱讀範圍，但不代表改完就不用測試。

它能降低探索成本，但不代表模型不會誤解命名、歷史包袱或隱性流程。

所以更務實的定位是：

它不是讓 AI 自動變成資深工程師，而是讓 AI 比較不容易像新手一樣在專案裡迷路。

下一階段的 AI 編程：模型加上專案記憶

AI coding 的競爭，前一階段很像模型能力競賽：誰更會寫 code、誰更會修 bug、誰 benchmark 更高。

但到了大型專案，光有強模型不夠。

真正影響效率的，會是模型外面的工具層：

專案索引。

呼叫關係。

測試狀態。

變更影響範圍。

歷史決策。

架構邊界。

這些資訊如果每次都重新讓模型猜，AI 就會一直浪費 token 找路。

如果能變成可查詢、可更新、可重用的專案記憶，AI 才比較像是在同一個工程團隊裡持續工作。

最值得記住的一句話

AI 寫程式不是把整個 codebase 塞進上下文就會變聰明。

更好的做法，是先讓它知道專案長什麼樣。

大型專案裡，真正有用的上下文，不是越多越好，而是越準越好。

當 AI 先有地圖，再開始讀細節，token 才會花在真正值得看的地方。

查證來源

回文章列表