codebase-memory 是什麼？跟本地 Qwen3.6，Claude Code 用戶必看兩個工具

Claude Code 要查一個函式被誰呼叫，最笨的做法是叫它把整個 repo 翻一遍——一個檔案一個檔案讀，讀完再 grep 一次確認沒漏掉。這樣做不是不行，是很燒 token。

這兩週有兩則推文剛好都在講同一件事：怎麼讓本地跑的 coding agent 少做重複工。一個是把整個程式庫壓成一張圖的工具，一個是專門調給本地 agent 用的 Qwen3.6。兩則都是廣告味很重的推文，數字一個比一個漂亮。這篇把能查到來源的都查了一遍，哪些是真的、哪些只是廠商自己講，講清楚。

codebase-memory 到底在解決什麼問題

這則推文講的工具，真名叫 codebase-memory-mcp，作者是 DeusData，MIT 授權，GitHub 上是開源專案。它是一個 MCP（Model Context Protocol）伺服器，裝好之後 Claude Code、Codex、Cursor、Gemini CLI、Zed、Aider 這些常見的 coding agent 都能接上，官方安裝腳本會自動幫你偵測你在用哪一個。

它做的事沒有想像中神秘。用 tree-sitter 加上 Language Server Protocol 解析你的程式碼，把函式、檔案、依賴關係全部畫成一張圖，存進本機的 SQLite 資料庫裡——不是 LLM，也不是向量資料庫，單純結構化的圖。裝好以後 agent 要查「誰呼叫了這個函式」，直接查圖，一次查詢就有答案，不用再一個檔案一個檔案翻。程式碼一改，背景會用內容雜湊只重新索引改過的部分，不用整個重來。

官方自己的數字是這樣的：一般大小的專案索引只要幾秒到幾毫秒，Linux kernel 這種 2800 萬行、7.5 萬個檔案的巨獸，大概 3 分鐘。這個數字推文裡有寫，官方教學影片的說明欄也獨立寫了一樣的數字，算是有兩個來源互相對上。

那 10 倍省 token、83% 答案品質，能信嗎

推文裡最吸引人的其實是這三行：31 個真實 repo 做 benchmark，結構查詢省 10 倍 token，複雜任務答案品質 83%，工具呼叫次數少 2.1 倍。

老實講，查了一圈，這組「31 個 repo」的具體 benchmark 方法論，只在這則推文裡出現過。找不到第三方複現過，連工具自己的官方網站都沒有詳細公開過方法。更妙的是，官方文件自己寫的倍數是「大約 120 倍更少 token」，跟推文講的 10 倍完全對不上——連自家行銷數字都不一致，這已經不是「有沒有獨立來源」的問題，是廠商自己都沒講清楚。

機制本身是合理的：查一張已經建好的圖，確實比一個個讀檔案省 token，這個邏輯沒問題。但具體省多少倍、答案品質多少百分比，現階段只能當成廠商自己講的行銷數字，不是有人驗證過的結果。

這其實是一個很擠的戰場

「讓 agent 記住整個 codebase」不是新題目，而且早就很多人在做。Cursor 用的是類 RAG 的語意索引，把程式碼切片做 embedding；Claude Code 走的是另一條路，靠 100 萬 token 的超長 context 加上自己去搜尋，不特別建立持久圖譜；企業端的 Sourcegraph Cody 做的是跨多個 repo 的程式碼圖，一年訂閱費用要價一萬六千美元起跳，鎖定的是大型工程團隊。這幾年還冒出 Augment Code、Sentra Code Memory 這類新玩家，各自主打不同的記憶方式。

codebase-memory-mcp 的差異化，是它完全不需要另外接 LLM 或 API key——純結構分析，全部在本機跑，透過 MCP 同時服務好幾種 agent，不綁死在單一 IDE 裡。這個定位是真的有意義，只是它進場的時候，戰場早就很擠了。如果你已經在用 autoskills 讓 Claude Code 自動讀懂你的 tech stack，這類結構化索引工具算是同一條路線上的下一步。

Qwen3.6 這支模型是什麼來頭

先講清楚一件事：這不是 Alibaba 自己訓練發布的模型。真正的作者是社群開發者 bytkim，在 Hugging Face 上發布，叫 Qwen3.6-27B-MTP-pi-reasoning-GGUF，用的底座是官方的 Qwen/Qwen3.6-27B。Tongyi Lab 這則推文做的事是「推薦」，不是「發布」——這點推文自己寫得很清楚，只是很容易被滑過去沒注意到。

這支微調鎖定的是 Pi 這類終端機 coding agent，用的是 4-bit QLoRA，在私有的、跑成功過的 agent 任務紀錄上做監督微調。GGUF 是給 llama.cpp、Ollama、LM Studio 這類本機推論引擎吃的量化格式，一個檔案打包所有東西，不用另外裝設定檔。MTP 是 Multi-Token Prediction，一次預測好幾個 token 再驗證，讓生成變快——注意，是變快，不是變聰明。llama.cpp 到 2026 年 5 月 16 日才正式合併 MTP 支援，算是很新的功能。

最有意思的是模型作者自己貼的 benchmark：在 Pi harness 上跑 pass@1，原始的 Qwen3.6 27B 底座拿到 42.70%，更早一版不帶推理的微調版掉到 28.09%，這一版「pi-reasoning」拉回 40.45%。算下來，這支被 Tongyi Lab 推薦的微調版，連自己的數據都沒贏過沒動過的原始底座。它真正的賣點是「把前一版微調掉的分數補回來」，不是「比官方模型更強」——這種誠實貼出自己數據不如原版的做法，反而比一堆只講贏的模型卡可信。

27B 的模型，本機真的跑得動嗎

Qwen3.6 27B 用 Q4_K_M 量化，實際佔用大約 16 到 21GB，差別在你開多長的 context window。一張 24GB VRAM 的顯卡，比如 麗臺 RTX PRO 4000 Blackwell，放這支模型還有餘裕，不用擔心跑到一半 OOM。

r/LocalLLaMA 社群確實有不少人在推薦 Qwen3.6 27B MTP 當本機 coding agent 的首選，如果你手上是 RTX 3090、4090 這個等級的卡，這是社群公認值得先試的選擇。但誠實說，這條路線目前還是需要一張像樣顯卡的玩法，不是隨手打開電腦就能上手的主流選項——退訂 Claude Code 或 Codex 改跑本地 agent，現階段比較像少數人願意折騰的選擇，不是大部分開發者的日常。

兩個工具，兩種省法

codebase-memory 省的是「查詢次數」——用一張圖取代一次次讀檔，前提是圖真的建得準。本機跑 Qwen3.6 這類調過的模型，省的是「每次呼叫的成本」——不用付 API 費用，但你得自己準備硬體、自己維護環境。這兩件事解決的是不同層的問題，合在一起用才會真的有感。如果你在意的是 agent 開發流程本身怎麼管，可以參考 Multica 這篇聊 coding agent 缺的管理層；想看完整工具鏈怎麼搭，AI Coding 時代的工程師工具鏈 也整理過型別、規則、skill 三層怎麼疊。

省的不是聰明，是重複做同一件事的次數。

利益揭露：本文部分連結為聯盟連結，點擊購買我會獲得回饋，不影響你的價格。

裝一個結構化索引工具，或者換一支本機模型，都不會讓你的 agent 突然變強。它們做的事，是讓 agent 少繞遠路。如果你已經在被逐檔翻找拖慢，先從 codebase-memory 這類工具試起，比等本機模型追上雲端模型的品質，實際多了。