Code-Review-Graph 不是再做一個 AI coding 包裝，而是在用 blast radius 把 AI 讀 code 的範圍縮到真正有影響的檔案

---

title: Code-Review-Graph 不是再做一個 AI coding 包裝，而是在用 blast radius 把 AI 讀 code 的範圍縮到真正有影響的檔案 date: 2026-04-12 source: https://www.threads.com/@ci.fullstack/post/DW_0UcLlFJr?xmt=AQF0X6OeotJ6JkLEfIG3WicrjvbjSyUpnSmLx7U66rhlQS26dAXGXKtxVSOYODFOhDCrJODx&slof=1 category: threads tags:

• Code-Review-Graph
• blast radius
• Tree-sitter
• AST
• AI coding
• code review
• token efficiency
• Next.js monorepo

---

Threads 原文介紹一個叫 Code-Review-Graph 的工具，核心不是「再做一個會寫 code 的 AI」，而是先回答一個更上游的問題：當你改了一個函式，真正需要被重新閱讀、重新理解、重新檢查的檔案到底有哪些？

它的關鍵概念叫 blast radius。也就是從單一變更點出發，沿著程式的依賴與呼叫關係，自動追蹤受到影響的程式碼範圍。這樣一來，AI 不需要再把整個 repo 甚至整個 monorepo 都掃過一次，而只要聚焦在真正會被波及的區域。

這個產品在解什麼

AI coding 真正昂貴的，往往不是生成一段 code，而是 為了理解上下文而讀太多不必要的檔案。

當專案一變大，常見問題會一起出現：

• context window 被不相關檔案吃掉
• token 成本快速上升
• 真正重要的依賴關係反而被稀釋
• AI 回答速度變慢，判斷品質也跟著下降

Code-Review-Graph 的做法，是把「哪些檔案該看」這件事，從依賴人工經驗或 LLM 猜測，改成先由程式分析工具算出一個更小、更精準的候選集合。

為什麼它值得注意

原文特別強調，這套方法 不靠 LLM，而是使用 Tree-sitter AST 做靜態分析，因此幾乎沒有額外模型成本。

這帶出兩個很實際的價值：

1. 直接省錢：對 API 計費使用者來說，少讀很多不相關檔案，token 成本自然下降。
2. 直接提效：就算你用的是訂閱制模型，不必餵一大堆噪音 context，也會讓回應更快、聚焦更準。

Threads 內容提到，平均可省 8.2 倍 token，在大型 Next.js monorepo 甚至可到 49 倍。數字本身還可以後續驗證，但方向很清楚：AI coding 的效率提升，不一定來自更大的模型，也可能來自更聰明的 context selection。

更大的產品啟示

這篇最值得記的，不只是某個工具紅不紅，而是它反映了一個趨勢：

下一波 AI coding 的競爭，不只是在比誰生成得更像工程師，而是在比誰更知道「哪些內容根本不用讀」。

換句話說，context engineering 正在從 prompt 技巧，走向更底層的 repository intelligence：

• 用靜態分析先切小搜尋空間
• 用 blast radius 決定閱讀邊界
• 再把更乾淨的上下文交給 LLM 做推理與生成

這種路線特別適合大型 codebase、monorepo、review flow、以及任何 token 成本明顯的團隊環境。

Allen 的一句話版

Code-Review-Graph 的真正價值，不是讓 AI 多會寫，而是先用 blast radius 算出「真正值得讀的那一小圈」，把 AI coding 從暴力讀 repo，升級成精準讀影響面。