利用 Tree-sitter 為程式碼建立圖譜，當檔案更動時順著圖譜追蹤受影響的「爆炸半徑」，AI 僅需讀取被波及的少數檔案。平均節省 8.2 倍 Token 消耗。
我最近觀察到一個現象：使用 Claude Code 或 Cursor 進行程式碼審查（Code Review）時，Token 的消耗量往往高得離譜。明明只是幾行程式碼的微小更動，它卻把整個專案的檔案全部讀過一遍。
起初我以為是操作方式有誤，後來才想通——這正是目前所有 AI 編碼工具的預設行為。它們缺乏對程式碼結構的認知，無法判斷哪些檔案與你的更動相關、哪些完全無關。因此，最安全的策略就是：全部讀一次。
這就像是你只是換了廚房的水龍頭，水電師傅卻把整棟大樓的水管配置圖全部重新看過一遍。安全嗎？是的。合理嗎？顯然不是。
今天要介紹一個名為 code-review-graph 的專案（已獲得 9,700 顆星），專門解決這個痛點。我認為它的核心思路比實作細節更值得探討，因為它揭示了一個常被忽視的事實：AI 編碼工具的瓶頸不在於模型能力，而在於輸入資訊的品質。
「爆炸半徑」——整個專案的靈魂概念
code-review-graph 做的第一件事，就是利用 Tree-sitter 將你的程式碼庫解析成一張圖。
這不是全文索引，也不是向量嵌入（Embedding），而是真正的結構圖：每個函式是一個節點，每個類別是一個節點；函式呼叫函式就連一條邊，類別繼承類別也連一條邊；引用關係（import）、測試覆蓋關係也都是邊。你的程式碼庫因此變成了一張「誰依賴誰」的關係網。
關鍵來了——當你更動了一個檔案，圖譜不會重新分析全部程式碼，而是從該檔案出發，沿著邊追蹤所有可能被影響的節點。這些節點就是這次更動的「爆炸半徑」（blast radius）。
修改了一個工具函式？圖譜會告訴你有哪些檔案調用了它，其中幾個有測試覆蓋、幾個沒有。AI 只需要讀取這幾個受影響的檔案，並檢視測試缺口，就能做出高品質的審查。剩下的幾百個檔案？跟這次更動毫無關聯，完全不需要浪費任何 Token。
坦白說，這個思路一點都不「AI」——本質上這是靜態分析，是編譯原理課上的老技術。但正因為這種「用舊工具解決新問題」的做法讓我感到佩服。當大家都在拚模型效能、拚提示詞（Prompt）工程時，很少有人退一步思考：餵給模型的資訊本身就有問題。
實測數據：6 個開源專案，平均節省 8.2 倍
這並非憑空想像的數字。該專案自帶一套基準測試（benchmark），在 6 個真實的開源倉庫（express、fastapi、flask、gin、httpx、nextjs）上針對 13 次提交（commit）進行了評測：
| 專案 | 不用圖（原始 Token） | 用圖（圖譜 Token） | 節省倍數 |
|---|---|---|---|
| flask | 44,751 | 4,252 | 9.1 倍 |
| gin | 21,972 | 1,153 | 16.4 倍 |
| fastapi | 4,944 | 614 | 8.1 倍 |
| nextjs | 9,882 | 1,249 | 8.0 倍 |
| httpx | 12,044 | 1,728 | 6.9 倍 |
| express | 693 | 983 | 0.7 倍 |
其中 gin 專案節省了 16.4 倍——原本需要讀取 22,000 個 Token 的程式碼，現在僅需 1,153 個。
值得注意的是，express 那行數據反而增加了。作者也坦承：對於單檔案的小型更動，圖譜自帶的結構元數據（邊、節點類型、審查指引）可能會超過原始檔案體積。這是一個誠實的局限性說明，反而讓我更信任這組數據。
更令我印象深刻的是影響分析的召回率（Recall）達到了 **100%**。也就是說，圖譜追蹤出的「爆炸半徑」絕對不會遺漏真正受影響的檔案。雖然精確率（Precision）只有 0.38——意味著可能會多報一些檔案——但在程式碼審查的情境下，遺漏一個 Bug 的後果遠比多讀幾個檔案嚴重得多。這種取捨思路非常清醒。
技術架構極度輕量，令人意外
我原本以為這類專案至少需要向量資料庫，或是運行模型來理解程式碼。結果它的核心技術棧非常簡單：
- Tree-sitter：解析抽象語法樹（AST），支援 19 種程式語言及 Jupyter notebooks。
- SQLite：將圖譜儲存於本地的
.code-review-graph/目錄檔案中。 - SHA-256 雜湊：判斷檔案是否更動，僅重新解析有變化的部分。
不需要 GPU、不需要雲端服務、也不需要外部資料庫。500 個檔案的專案首次構建約需 10 秒，之後的增量更新不到 2 秒。即便是 2,900 個檔案的專案，增量更新同樣不到 2 秒。
它透過 MCP（Model Context Protocol）與 AI 工具對接，目前支援 Claude Code、Cursor、Windsurf、Codex、Zed 等。安裝只需兩行指令：
git clone https://github.com/tirth8205/code-review-graph.git
cd code-review-graph
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"提供 22 個 MCP 工具與 5 種工作流程模板（審查、架構分析、除錯、新人上手、合併前檢查）。對於一個擁有 9,700 顆星的專案來說，功能覆蓋面已相當完整。
有個細節我覺得很有趣：它還能進行社群偵測——利用 Leiden 演算法將程式碼節點聚類，找出哪些模組耦合度高、哪些是孤岛，並自動生成架構概覽與 Markdown 維基。這已經不只是一個程式碼審查工具，更像是一個程式碼庫的「健康檢查報告產生器」。
一個大膽的判斷
code-review-graph 讓我聯想到一個更大的問題：目前所有 AI 編碼工具的上下文（Context）管理都太過粗暴。
模型越來越強大，上下文視窗也越來越大，但沒人認真思考過「該給模型看什麼、不該看什麼」。把整個程式碼庫全部塞進去，既浪費金錢（Token 並非免費），又降低品質（出現「中間遺失」效應——關鍵資訊被淹沒在大量無關程式碼中）。
code-review-graph 的做法是一個訊號：下一輪 AI 編碼工具的競爭，可能不在於模型能力，而在於上下文工程（Context Engineering）。 谁能更精準地提供資訊給模型，誰的效果就會更好。
延伸閱讀
Anthropic "洩漏"Claude Mythos 最強模型到底有多猛？
Memento-Skills VS OpenClaw 不改模型也能進化
Agent 失憶怎麼辦，Anthropic 教你做好工作交接