code-review-graph：讓 AI 程式碼審查更精準、更節省 Token

code-review-graph 是一個面向 AI 編碼助手的開源工具，它會先在本地為程式碼庫建立一張結構化「知識圖譜」，再把真正相關的上下文交給 AI，從而避免每次任務都全量掃描整個倉庫。 它基於 Tree-sitter 解析 AST，把函式、類別、匯入、呼叫關係和測試關係組織成圖結構，再透過 MCP 提供給 Claude Code、Codex、Cursor 等工具使用。

它解決了什麼問題

當前很多 AI 編碼工具在做程式碼審查、定位影響範圍或理解改動時，會反覆讀取整個程式碼庫，這會帶來明顯的 Token 浪費與成本上升。 在一個數百檔案的倉庫裡，即使只改了一個函式，AI 也可能需要重新掃很多無關檔案，導致速度變慢、上下文雜訊增加、費用變高。

code-review-graph 的思路是把「程式碼依賴關係」提前建模出來，讓 AI 在審查時只讀取改動真正波及到的檔案，而不是靠猜測去做全量掃描。 官方文件把這種能力稱為 blast-radius analysis，也就是「爆炸半徑分析」：當某個檔案變更後，工具會沿著呼叫、繼承、依賴和測試鏈條往外追蹤，找出所有可能受影響的程式碼。

它怎麼工作

工具首先用 Tree-sitter 把倉庫解析成 AST，並抽取函式、類別、匯入、呼叫點、繼承關係與測試覆蓋等結構資訊，再把這些資訊存到本地 SQLite 圖資料庫中。 到了 review 階段，AI 不再直接讀整個專案，而是先查詢圖譜，拿到一份最小上下文集合，只閱讀與當前問題直接相關的檔案和節點。
它還支援增量更新。官方說明顯示，後續更新只會重新解析發生變化的檔案，並透過哈希和依賴追蹤來重新整理相關節點；在一個約 2,900 檔案的專案中，重新索引可以控制在 2 秒以內。 對 monorepo 這類大型倉庫來說，這種方式尤其有價值，因為它能從上萬檔案裡縮小到十幾個真正需要讀取的檔案。

支援的平台與工具

code-review-graph 透過 MCP 整合到多種 AI 編碼平台中，官方快速開始與平台說明中列出的支援對象包括 Claude Code、Codex、Cursor、Windsurf、Zed、Continue、Kiro、OpenCode、Antigravity、Qwen 和 Qoder。 這意味著它並不局限於某一個 AI 編輯器，而是盡量把「圖譜上下文」能力接到不同的 coding agent 或 AI IDE 上。

如果只想給某個平台單獨安裝，也可以明確指定平台名，例如 code-review-graph install --platform codex、code-review-graph install --platform cursor、code-review-graph install --platform claude-code 或 code-review-graph install --platform kiro。

如何使用

最基礎的使用流程很簡單：先安裝，再給 AI 工具寫入 MCP 組態，最後回到具體專案中建構圖譜。

pip install code-review-graph
code-review-graph install
cd /path/to/your/project
code-review-graph build

這裡有一個非常重要、也很容易寫含糊的點：code-review-graph install 不是在專案根目錄裡執行的「專案初始化指令」，它本質上是一個全域組態指令。 官方文件寫得很清楚，這個指令會自動偵測你機器上已安裝的 AI 編碼工具，寫入對應的 MCP 組態，並把圖譜相關指令注入這些平台的規則組態中；執行完之後還需要重啟對應的編輯器或工具。

相對地，code-review-graph build 才是應該在專案根目錄中執行的指令。 官方說明是 「Then open your project」，接著讓 AI assistant 為「this project」建構 code review graph；同時，工具的忽略檔案 .code-review-graphignore 也明確要求放在 repository root，而本地圖譜資料則存放在專案中的 .code-review-graph/ 目錄裡。 換句話說，install 負責把能力接入你的 AI 工具，build 負責對當前倉庫真正建圖。

為了避免讀者混淆，也可以把這兩個指令的職責直接對照著寫清楚：

如果編輯器本身不支援 hooks，或者希望圖譜在背景持續保持最新，還可以使用 daemon 模式。官方文件提供了 crg-daemon add、crg-daemon start、crg-daemon status 等指令，用來註冊多個倉庫並自動監聽檔案變化。

常用指令

除了安裝與建圖，官方文件還給出了比較完整的 CLI 能力。

在支援 Slash Commands 的工具中，還可以直接用 /code-review-graph:build-graph、/code-review-graph:review-delta 和 /code-review-graph:review-pr 來呼叫相應工作流程。

效果如何

官方基準測試基於 6 個真實開源倉庫、13 次提交進行評估，結果顯示 graph 模式相對 naive 全量讀取，平均可把 Token 消耗降到原來的約八分之一，整體減少 8.2 倍。 從公開資料看，不同倉庫的收益並不完全一樣，但大部分中大型專案都有比較明顯的下降幅度。

它的另一個重點指標是影響分析準確率。官方給出的結果是召回率達到 100%，平均 F1 為 0.54、平均精確率為 0.38。 這說明它在策略上偏保守：寧可多提示一些「可能受影響」的檔案，也盡量不漏掉真正會被改動波及的依賴。

不過，這種方式也不是所有場景都佔優。官方明確提到，在體量較小、改動又非常局部的專案中，圖譜元資料本身的上下文開銷可能反而大於直接讀取檔案的成本，例如 express 的單檔案變更測試中 reduction 只有 0.7x。 所以它最適合的場景，仍然是中大型專案、多檔案改動、複雜依賴關係以及高頻 AI review 工作流程。

適合哪些團隊

如果團隊已經把 Claude Code、Codex、Cursor 或類似工具納入日常開發流程，而且專案規模較大、模組關係複雜、PR 評審頻繁，那麼 code-review-graph 的價值會比較直接。 它本質上不是替代程式碼審查，而是先幫 AI 把「該讀什麼」這件事做對，從而讓後續的 review、除錯、架構分析和 onboarding 都建立在更準確的上下文之上。

對於單人專案、很小的倉庫或偶發性的簡單改動，它未必總能帶來明顯收益。 但對於希望系統性降低 AI 編碼成本、減少上下文雜訊、提升程式碼審查命中率的團隊來說，它已經展示出了相當實用的效果。