Code Review Graph：給 AI 代碼評審裝一張本地圖譜
整理版優先睇
Code Review Graph 透過本地圖譜精準提供變更影響範圍，助 AI 評審減少 token 浪費。
呢篇文章介紹一個叫 Code Review Graph 嘅開源工具，作者 tirth8205 想解決 AI 編程助手做代碼評審時，成日讀咗一大堆無關上下文嘅問題。佢嘅方案唔係將成個倉庫塞入向量庫，而係先將程式碼結構化成圖譜，再用 MCP 協議畀 AI 查詢，咁樣 AI 只會讀到真正需要嘅部分。
工具用 Tree-sitter 做語法解析，將函數、類、導入、調用等關係存落本地 SQLite 圖譜，然後用 BFS 做影響面分析。根據 benchmark，喺6個真實開源倉庫中，增量方案比起全量讀法平均 token 減少 8.2 倍，但喺小型單文件變更中反而會更重，因為圖譜上下文有固定開銷。影響面分析傾向於「寧可多報」避免漏報，recall 100% 但 precision 0.38。
整體嚟講，呢個工具適合大倉庫、PR 影響範圍唔明顯、想將多個 AI 工具接入統一結構化上下文嘅團隊。作者認為呢個方向反映咗 AI 編程下一步：模型負責推理，而「應該讀乜」交畀結構化工具。如果你重視代碼私隱又希望 AI 更懂倉庫結構，呢個係一個值得留意嘅本地基礎設施。
- Code Review Graph 透過本地圖譜精準提供變更影響範圍，平均 token 減少 8.2 倍，但細項目可能 overhead 更大。
- 方法：先用 Tree-sitter 將代碼解析成 AST，再存入 SQLite 圖譜，然後用 BFS 做影響面分析。
- 差異：相比全文搜索，佢關心結構關係（調用鏈、導入、測試覆蓋），而唔係關鍵詞命中。
- 啟發：AI 編程嘅下一步唔單止係模型更強，仲要上下文供應鏈更清晰，模型負責推理，結構化工具負責決定讀乜。
- 可行動點：可以透過 pip 安裝，行 code-review-graph install 同 build 快速整合入 Claude Code、Cursor 等工具。
Code Review Graph GitHub
GitHub 倉庫，包含源碼、安裝說明及 MIT 授權
AI 評審點解浪費上下文？
好多 AI 編程助手做代碼評審時，唔知道變更真正影響邊度，結果將相關目錄、最近修改文件、搜索結果塞入上下文，模型睇得多但噪聲亦多。上下文窗口越大，成本越高，判斷越易被稀釋。
code-review-graph 嘅切入點好明確：唔好畀 AI 重新猜倉庫結構，而係先喺本地維護一張結構化圖譜
評審時，AI 先查圖，再讀代碼，避免讀取無關資訊
代碼點樣變成圖？
工具先用 Tree-sitter 將代碼解析成 AST，再將函數、類、導入、調用等關係存入本地 SQLite 圖譜，形成節點同邊嘅結構。
Tree-sitter 係增量代碼解析器，能穩定識別語法結構
AST 令代碼變成樹狀結構，唔再係純文字
SQLite 圖譜毋須額外服務，所有資訊存喺 .code-review-graph 目錄
只讀可能被波及嘅部分
呢個能力叫 blast-radius analysis，即係影響面分析，從變更點向外逐層揾調用者、依賴項同測試文件。
直接調用變更函數的函數或路由
間接依賴它的模塊
覆蓋它的測試
- 1 直接調用變更函數的函數或路由
- 2 間接依賴它的模塊
- 3 覆蓋它的測試
- 4 因導入、繼承、調用鏈而可能被帶到的相關文件
之後通過 MCP 協議將查詢結果交畀 AI 助手，令 Claude Code、Cursor、Windsurf 等工具可以問圖譜而唔使自己解析。
MCP 係 Model Context Protocol，讓 AI 助手調用外部工具嘅通用協議
實際效果同適用場景
benchmark 顯示，喺6個真實開源倉庫中，增量方案平均 token 減少 8.2 倍，但 express 呢類小型單文件變更反而用多咗 0.7 倍，因為圖譜有固定開銷。
平均 token 減少 8.2 倍
precision 0.38，傾向「寧可多報」避免漏報
pip install code-review-graph
code-review-graph install
code-review-graph buildinstall 會自動偵測本機 AI 工具並寫入 MCP 配置；build 負責解析當前項目構建圖譜。建議用 uv 以優先使用 uvx。
適合大倉庫、PR 影響範圍唔明顯、想統一 AI 工具上下文嘅團隊
本地優先，唔依賴雲服務，重視代碼私隱
Code Review Graph 唔係又一個「將倉庫塞入向量庫」嘅工具。佢更加似係幫 AI 程式助手準備咗一張本地代碼地圖：先解析代碼結構，再將函數、類、導入、調用同測試關係存成圖，最後透過 MCP 將真正需要睇嘅上下文交俾 AI 工具。 一、點解 AI 評審會浪費上下文好多 AI 程式助手做代碼評審嗰陣，會遇到一個簡單但成本好高嘅問題：佢根本唔知道今次變更真正影響咗邊度。 如果淨係將相關目錄、最近修改嘅檔案、搜尋結果全部塞入上下文，模型確係「睇得多」，但係同時都會讀到好多無關嘅資訊。上下文窗口越大，成本越高，噪音亦越容易稀釋判斷。 `code-review-graph` 嘅切入點好明確：唔好俾 AI 重新猜倉庫結構，而係喺本地先維護一張結構化圖譜。評審嗰陣，AI 先查圖，然後再讀代碼。  圖 1：冇圖譜嗰陣，AI 比較容易讀曬成個代碼庫；有圖譜之後，AI 可以先用查詢影響面，再讀取最小評審集。 二、代碼先變成圖 圖 2：由代碼倉庫出發，經過 Tree-sitter 解析做 AST，再寫入 SQLite 圖譜，最後用影響面分析俾 AI 提供最小評審集。 呢張圖裏面有幾個詞如果第一次睇會覺得有啲難明，可以拆開理解。
所以佢做嘅唔係「將代碼全文餵俾模型」，而係先將倉庫壓成一張可以查詢嘅結構圖。模型需要上下文嗰陣，查到嘅係更加接近變更嘅結構資訊。 三、只讀可能被波及嘅部分 圖 3：一次變會會沿住調用、導入、測試關係向外擴散。影響面分析嘅目標係優先揾出 AI 應該先讀嘅區域。 項目入面將呢種能力叫做 blast-radius analysis，直譯係「爆炸半徑」，喺工程語境入面更適合叫「影響面分析」。
呢個亦係佢比起普通全文搜索更加有意思嘅地方：佢關心嘅係代碼之間嘅結構關係，而唔單單係關鍵詞有冇命中。 四、將圖查詢交俾 AI 助手MCP 係 Model Context Protocol，可以理解成「讓 AI 助手調用外部工具嘅通用協議」。`code-review-graph` 透過 MCP 暴露查詢能力，咁樣 Claude Code、Cursor、Windsurf、Zed、Codex 等工具，就可以喺任務入面先問圖譜。  圖 4：AI 助手透過 MCP Server 查詢本地圖譜，再根據返嘅影響面、測試缺口同風險分數進行評審。
呢層協議嘅價值在於：AI 唔使將圖譜嘅實現細節學一次，只要識得調用 MCP 工具，就可以拎到結構化嘅上下文。 五、好慳 Token，但唔係銀彈項目給出嘅自動評測嚟自 6 個真實開源倉庫、13 個 commits。佢報告嘅平均結果係：增量方案相比全量讀法，平均 token 減少 8.2 倍。  圖 5：benchmark 展示咗唔同倉庫嘅 token 減少同評審質量對比。數字要結合任務規模理解。 但呢個數字唔可以機械咁理解成「任何項目都會慳 8 倍」。一個反例：喺 express 嘅小型單檔案變更入面，graph 上下文反而係 0.7 倍，即係比直接讀檔案仲要重。 圖譜上下文有固定開銷：節點、邊、評審提示、影響鏈都要佔 token。項目越大、變更越跨檔案、無關代碼越多，圖譜裁剪就越划算；項目好細、改動好孤立嗰陣，直接讀檔案可能更簡單。 影響面準確率都要咁樣睇。報告 recall 係 100%，平均 F1 係 0.54，precision 係 0.38。換句話講，佢傾向「寧可報多啲，都唔好漏咗真正受影響嘅檔案」。呢個對評審嚟講係合理取捨，但並唔等於每個命中都一定有問題。 六、本地、增量、多語言 圖 6：增量更新唔係重新掃描成個倉庫，而係由 git diff 同依賴關係出發，只重新解析相關檔案。
 圖 7：語言覆蓋圖展示咗 Web、後端、系統、流動裝置、腳本等唔同類別嘅語法解析能力。 呢啲點說明佢更加似一個「本地開發基礎設施」，而唔係在線 SaaS。對重視代碼私隱、又想 AI 助手更加了解倉庫結構嘅團隊，呢個形態比較友好。 七、快速上手官方俾出嘅最短路徑係三步：  圖 8：`code-review-graph install` 會嘗試自動識別本機已安裝嘅平台，並寫入對應 MCP 配置。 `install` 會嘗試檢測本機已有嘅 AI 程式工具並寫入 MCP 配置；`build` 就負責解析當前項目並構建圖譜。建議安裝 `uv`，咁樣 MCP 配置可以優先使用 `uvx`。 八、適合邊啲人，唔適合邊啲人如果你只係喺幾十個檔案嘅細項目入面偶爾俾 AI 改一行代碼，呢類工具未必可以即刻顯示出價值。圖譜構建、維護、上下文描述本身都有成本。
我更願意將佢睇成一個方向信號：AI 程式嘅下一步，唔單止係模型更加強，都包括上下文供應鏈更加清晰。模型負責推理，但「應該讀咩」呢件事，應該越來越多交俾結構化工具。 如果係需要對項目做一次完整深入嘅探查，都可以參考GitNexus：將整個代碼倉庫變成知識圖譜 項目地址GitHub：https://github.com/tirth8205/code-review-graph |
Code Review Graph 不是又一個“把倉庫塞進向量庫”的工具。它更像是給 AI 編程助手準備了一張本地代碼地圖：先解析代碼結構，再把函數、類、導入、調用和測試關係存成圖，最後通過 MCP 把真正需要讀的上下文交給 AI 工具。 一. 為什麼 AI 評審會浪費上下文很多 AI 編程助手做代碼評審時，會遇到一個樸素但昂貴的問題：它並不知道這次變更真正影響了哪裏。 如果只是把相關目錄、最近修改文件、搜索結果一股腦塞進上下文，模型確實“看得多”，但讀到的無關信息也會變多。上下文窗口越大，成本越高，噪聲也越容易稀釋判斷。 `code-review-graph` 的切入點很明確：不要讓 AI 重新猜倉庫結構，而是先在本地維護一張結構化圖譜。評審時，AI 先查圖，再讀代碼。 圖 1：沒有圖譜時，AI 更容易讀取整個代碼庫；有圖譜後，AI 可以先查詢影響面，再讀取最小評審集。 二. 代碼先變成圖圖 2：從代碼倉庫出發，經 Tree-sitter 解析為 AST，再寫入 SQLite 圖譜，最後用影響面分析給 AI 提供最小評審集。 這張圖裏有幾個詞如果第一次看會有點硬，可以拆開理解。
所以它做的不是“把代碼全文餵給模型”，而是先把倉庫壓成一張可查詢的結構圖。模型需要上下文時，查到的是更靠近變更的結構信息。 三. 只讀可能被波及的部分圖 3：一次變更會沿調用、導入、測試關係向外擴散。影響面分析的目標是優先找出 AI 應該先讀的區域。 項目裏把這個能力叫 blast-radius analysis，直譯是“爆炸半徑”，在工程語境裏更適合叫“影響面分析”。
這也是它相比普通全文搜索更有意思的地方：它關心的是代碼之間的結構關係，而不只是關鍵詞是否命中。 四. 把圖查詢交給 AI 助手MCP 是 Model Context Protocol，可以理解成“讓 AI 助手調用外部工具的通用協議”。`code-review-graph` 通過 MCP 暴露查詢能力，這樣 Claude Code、Cursor、Windsurf、Zed、Codex 等工具，就可以在任務中先問圖譜。 圖 4：AI 助手通過 MCP Server 查詢本地圖譜，再根據返回的影響面、測試缺口和風險分數進行評審。
這層協議的價值在於：AI 不必把圖譜實現細節學一遍，只要會調用 MCP 工具，就能拿到結構化上下文。 五. 很省 Token，但不是銀彈項目給出的自動評測來自 6 個真實開源倉庫、13 個 commits。它報告的平均結果是：增量方案相比全量讀法，平均 token 減少 8.2倍。 圖 5：benchmark 展示了不同倉庫的 token 減少和評審質量對比。數字要結合任務規模理解。 但這個數字不能機械理解成“任何項目都會省 8 倍”。一個反例：在 express 的小型單文件變更裏，graph 上下文反而是 0.7倍，也就是比直接讀文件更重。 圖譜上下文有固定開銷：節點、邊、評審提示、影響鏈都要佔 token。項目越大、變更越跨文件、無關代碼越多，圖譜裁剪越划算；項目很小、改動很孤立時，直接讀文件可能更簡單。 影響面準確率也要這樣看。報告 recall 為 100%，平均 F1 為 0.54，precision 為 0.38。換句話說，它傾向於“寧可多報一點，也不要漏掉真正受影響的文件”。這對評審是合理取捨，但並不等於每個命中都一定有問題。 六. 本地、增量、多語言圖 6：增量更新不是重掃全倉，而是從 git diff 和依賴關係出發，只重解析相關文件。
圖 7：語言覆蓋圖展示了 Web、後端、系統、移動端、腳本等不同類別的語法解析能力。 這些點說明它更像一個“本地開發基礎設施”，而不是在線 SaaS。對重視代碼隱私、又希望 AI 助手更懂倉庫結構的團隊，這個形態比較友好。 七. 快速上手官方給出的最短路徑是三步： 圖 8：`code-review-graph install` 會嘗試自動識別本機已安裝的平台，並寫入對應 MCP 配置。 `install` 會嘗試檢測本機已有的 AI 編程工具並寫入 MCP 配置；`build` 則負責解析當前項目並構建圖譜。建議安裝 `uv`，這樣 MCP 配置可以優先使用 `uvx`。 八. 適合誰，不適合誰如果你只是在幾十個文件的小項目裏偶爾讓 AI 改一行代碼，這類工具未必能立刻顯出價值。圖譜構建、維護、上下文描述本身也有成本。
我更願意把它看成一個方向信號：AI 編程的下一步，不只是模型更強，也包括上下文供應鏈更清晰。模型負責推理，但“該讀什麼”這件事，應該越來越多交給結構化工具。 如果是需要對項目做一次完整深入的探查，也可以參考GitNexus：將整個代碼倉庫變成知識圖譜 項目地址GitHub：https://github.com/tirth8205/code-review-graph |