兩套「省 token」的 code 工具，我拿自己的專案實測
你有沒有想過，AI 幫你改 code 之前，它到底怎麼「看懂」你的專案？答案通常很土法煉鋼：先用關鍵字一個一個把檔案搜出來，然後把搜到的檔案整份讀進去。檔案一多，光是「搞懂現況」就先燒掉幾萬個 token——你還沒開始問問題呢。
所以最近冒出一類工具，想法都一樣：先把整個 codebase 掃成一張圖（誰呼叫誰、誰 import 誰），之後 AI 要問「這個函式被誰用到」，就查圖、回你三行，不用再翻檔案。GitHub 上兩個做這件事的專案——codebase-memory-mcp 跟 graphify——都掛著很唬人的數字，前者首頁直接寫「省 99% token」。
我不太信這種數字，所以拿自己正在做的一個小專案，兩套都裝起來、設計 6 種問題各跑一次，順便量了「答案到底對不對」。結果跟宣傳的不太一樣：省最多 token 的那個，答錯最多題。
我怎麼測的
受測專案是我自己的 Agents-social（35 個 TypeScript 檔，整份讀進去約 43,935 tokens）。6 個問題，每題三種做法對照：
- 土法煉鋼：
rg搜關鍵字，然後把搜到的檔案整份讀完（沒裝工具的 AI 就是這樣做） - codebase-memory-mcp：用它的查詢工具
- graphify：用它的查詢工具
token 數用 tiktoken 算（跟 Claude 的算法不完全一樣，但三邊用同一把尺，比較才公平）。每題跑 3 次取中位數。
兩邊建索引都很快，而且都不用花 LLM 的錢：
| 建索引時間 | 節點 / 邊 | LLM 花費 | |
|---|---|---|---|
| codebase-memory-mcp | 0.24 秒 | 465 / 985 | 0 |
| graphify（純 code 模式） | 0.28 秒 | 146 / 237 | 0 |
結果：省 token 這件事，兩個都做到了
| 問題 | 土法煉鋼 | codebase-memory-mcp | graphify |
|---|---|---|---|
| 架構總覽 | 44,233 | 3,116 | 1,196 |
| 某個函式定義在哪、內容是什麼 | 4,837 | 1,502 | 103 |
| 誰呼叫了這個函式（改了會炸到誰） | 911 | 147 | 243 |
| 兩個模組怎麼串起來的 | 10,226 | 300 | 35 |
| 「反諂媚」的邏輯寫在哪 | 5,226 | 834 | 687 |
| server 開了哪些 API 路由 | 4,026 | 153 | 339 |
| 合計 | 69,459 | 6,052 | 2,603 |
單看 token：codebase-memory-mcp 省 91.3%（11.5 倍），graphify 省 96.3%（26.7 倍）。graphify 大勝。
如果我到這裡就收工，結論會是「graphify 更省，選它」。但我多做了一件事。
我去對答案，然後結論翻盤
省 token 沒意義，如果答案是錯的——AI 拿到錯的答案，還是得回去翻檔案，你等於白省。所以我把 6 題的正確答案自己挖出來，一題一題對。
codebase-memory-mcp 6 題全對。graphify 對 2 題、部分對 2 題、錯 2 題。
錯得最乾脆的是這題：「反諂媚的邏輯寫在哪？」我直接問它 graphify query "sycophancy"，它回我——
No matching nodes found.
但那個字在我專案裡出現 4 次，分佈在兩個檔案。codebase-memory-mcp 不只找到，還把行號一起給我（第 12、65、69 行）。
原因不是 graphify 做壞了，是它本來就只吃「符號名稱跟關聯」——函式叫什麼、誰呼叫誰。至於字串裡面、prompt 內容裡面寫了什麼，它的圖裡根本沒存。所以只要你要找的概念沒剛好被拿去當函式名字，它就找不到。codebase-memory-mcp 另外內建了全文檢索，這種題目才接得住。
另一題也一樣：問「server 開了哪些 API 路由」，我專案裡有 22 條，graphify 回了一堆不相干的檔案，一條都沒對到；codebase-memory-mcp 用 153 個 token 把 22 條的行號全列出來。
把「答錯就得回去翻檔案」這個成本算回去，數字整個翻過來：
| 帳面省下 | 算進正確率之後 | 答對 | |
|---|---|---|---|
| codebase-memory-mcp | 91.3%（11.5x） | 91.3%（11.5x） | 6 / 6 |
| graphify | 96.3%（26.7x） | 84.4%（6.4x） | 2 / 6 |
幾件我不想含糊帶過的事
第一，我測的是 graphify 的「純 code 模式」。 它真正的賣點其實是能一起吃文件、PDF、圖片、影片，把它們跟 code 連成同一張圖——但那部分要動用 LLM。我為了跟對手公平比（兩邊都零 LLM 成本），只跑了 code 的部分。所以上面那個「錯 2 題」是這個模式的限制，不是整個工具的判決。你要是拿它來理解一個混著設計文件跟論文的專案，這個比較就不適用。
第二，那個「省 99%」在我這裡沒複製出來。 我測到 91%。原因也單純：我的專案才 35 個檔案，整份讀完也就 44k tokens，本來就塞得進 AI 一次能讀的範圍。省的比例會隨專案變大而變大——他們拿 Linux kernel 去測，跟我這種小專案不是同一個量級。這類首頁數字，你都得先問一句「拿多大的專案測的」。
講到這個，graphify 自己產的報告倒是很誠實，開頭第一句就寫：
Corpus is ~21,832 words - fits in a single context window.
You may not need a graph.
一個工具主動跟你說「你可能不需要我」，這點我給它加分。
第三，codebase-memory-mcp 也不是沒缺點。 問「某個函式在哪」那題，它花了 1,502 個 token，graphify 只用 103。差在它每個節點都硬塞一堆指紋雜湊（一長串亂碼似的 fp、sp 欄位），對我沒用，但 token 照算。另外它首頁列的 semantic_query 這個工具，我裝的 npm 版（0.9.0）裡面根本沒有，實際只有 14 個工具。
想自己試的話
codebase-memory-mcp（MIT）：
npm install -g codebase-memory-mcp
codebase-memory-mcp install # 自動幫你寫好各家 agent 的設定
graphify（Apache-2.0 / MIT 雙授權）：
uv tool install graphifyy # 注意套件名是兩個 y
graphify install
裝完在你的 agent 裡打 /graphify . 就會開始建圖。
兩個都是本機跑、不上傳你的 code，這點都一樣。
我從這輪測試學到的
老實說，我原本以為這篇會寫成「A 比 B 好」。實際跑完，比較有價值的反而是那個方法本身：只量「省了多少 token」，會選到錯的工具。
省 token 是手段，不是目的。目的是「AI 少讀一點、還能答對」。一個工具幫你把 44,000 個 token 壓到 700，聽起來很猛，但如果那 700 個 token 裡沒有答案，AI 接下來還是得去翻那 44,000 個——你不但沒省，還多繞一圈。
所以下次看到任何 AI 工具掛「省 90%／快 10 倍」，值得多問一句：省下來之後，事情還做得成嗎？這句話拿去問 RAG、問各種 context 壓縮工具，也一樣成立。
至於這兩個工具，我自己的結論是：如果你的專案主要是 code、而且你會問「這東西寫在哪」這類問題，codebase-memory-mcp 目前穩一些；如果你的專案有大量文件要跟 code 串在一起看，那才是 graphify 真正想解的問題——只是那條路要花 LLM 的錢，得另外算一次帳。
最近開始做免費的一對一諮詢，幫你把 AI 接進自己的工作流——有需要的話可以約：https://www.dawsonwang.com/
資料來源： codebase-memory-mcp（GitHub，MIT 授權）https://github.com/DeusData/codebase-memory-mcp graphify（GitHub，Apache-2.0 / MIT 雙授權）https://github.com/Graphify-Labs/graphify 實測環境：MacBook Air (M-series)、codebase-memory-mcp 0.9.0、graphifyy 0.7.0 受測專案：Agents-social（35 個 TypeScript 檔案 / 43,935 tokens） token 計算：tiktoken cl100k_base，每題 3 次取中位數 擷取：2026-07-25