AI 知識
把 codebase context 變成可查詢結構
AI coding assistant 能在幾秒內補出 function、寫測試、找 bug，但只要問題跨過多個模組，它常會先做一件很昂貴的事：重新搜尋、打開檔案，再從零拼回專案架構。
對小型 repository，這種做法還能運作。當 codebase 變大，問題開始涉及「誰呼叫誰」「改 schema 會影響哪些 service」「這個認證流程最後怎麼碰到資料庫」，單純文字搜尋就很容易失去跨多層關係。
2026 年 7 月公開推出的 Graphify，試著從檢索層解決這個問題。它不是另一個程式生成模型，而是一個開源工具：先把程式碼、文件與系統結構整理成知識圖譜，再讓 AI assistant 查詢節點與關係。
一般搜尋與知識圖譜差在哪
傳統 grep 或文字搜尋擅長回答「哪個檔案出現這個名稱」。
Embedding-based retrieval 擅長回答「哪些文字片段看起來和這個問題相似」。
但軟體架構最難的問題，常常不是找相似文字，而是追關係：
- 哪些 function 會一路呼叫到這個 database pool？
- 哪個 API 依賴這個 schema？
- 一個 authentication service 的改動會穿過哪些 module？
- 兩個看似無關的元件，為什麼最後共用同一個 dependency？
知識圖譜會把 function、class、file、database table 與 document 當成節點，把 call、import、definition、reference 等關係存成有方向的邊。
當 AI 回答問題時，它不只找一段相似文字，而是沿著關係 traversal，找出從 A 到 B 的實際路徑。
Graphify 如何建立圖譜
Graphify 把資料處理分成兩個不同階段。
程式碼：用 AST 在本機解析
對程式碼，Graphify 使用 tree-sitter grammar 解析 Abstract Syntax Tree。
Function、class、import 與 call 等結構，是 parser 從 source code 直接辨識出來的，不需要模型猜測。官方文件稱目前支援 36 種程式語言。
這個階段的重點是 deterministic：同一份程式碼會得到可重現的結構，且不需要把 code 傳給額外的 Graphify 雲端服務。
文件與非程式碼：由設定的模型做語意連結
Markdown、PDF、Office 文件、SQL schema、Terraform、圖片等內容，無法只靠程式碼 AST 完整理解。
Graphify 會交由使用者設定的模型 backend 做語意處理，再把內容與程式碼節點連起來。
這裡必須保留一個重要邊界：Graphify 本身沒有新增 hosted index，但如果使用的是 hosted model，資料仍會依該模型原本的方式處理。不能把「Graphify 在本機建立圖譜」延伸成「所有內容永遠不會離開本機」。
三種關係標籤，讓 AI 的判斷不再全部混在一起
Graphify 會替每條 edge 標示 provenance：
EXTRACTED：parser 直接從 AST 找到的關係。INFERRED：模型根據內容連起來的關係。AMBIGUOUS：存在證據，但因 dynamic dispatch、reflection 或字串組合 import 等情況，仍無法完全確認。
這個設計的重要性，不只是讓圖譜看起來更完整。
它讓使用者知道回答中的哪一段是程式碼直接支持，哪一段是模型推論，哪一段需要再人工確認。AI 不必把所有關係都用同一種確定語氣說出來。
建完後會得到什麼
執行 Graphify 後，主要會產生三個本機檔案：
graph.html：可以在瀏覽器探索的互動式圖譜。GRAPH_REPORT.md：整理核心節點、自然群集與值得追查關係的架構報告。graph.json：機器可讀的完整圖譜，供 CLI、MCP 或其他工具查詢。
Graphify 提供 query、path 與 explain 等查詢方式。
例如，開發者可以問「authentication 如何連到 database」，或直接要求找出某個 service 到某張 table 的最短路徑。回答不只給結論，也能帶回實際 file:line 引用與關係類型。
它也提供 MCP server，讓支援 MCP 的 AI assistant 直接把圖譜當成工具，而不是每次透過 shell 重新讀取大量檔案。
為什麼這可能降低上下文浪費
大型 codebase 的問題，不只是檔案多，而是每次 session 都會重複探索相同結構。
如果 AI 為了回答一個局部問題，需要重新打開十幾個檔案，context window 會先被檢索資料占滿。真正留給推理、修改與驗證的空間反而變少。
預先建立圖譜後，assistant 可以只拿與問題相關的 subgraph：節點、關係與路徑，而不是把整份檔案全部貼進 context。
這不代表 token 一定會下降固定倍數。實際差異取決於 repository 大小、查詢類型、graph freshness、assistant 行為與模型整合方式。現階段沒有足夠一致的官方 benchmark，可以支持每個專案都能重現固定倍數的節省。
知識圖譜不會取代所有搜尋
Graphify 官方文件也承認，對大量模糊 prose 做語意搜尋時，embedding 仍可能是比較合適的工具。
圖譜最有優勢的，是關係明確且需要跨多層追蹤的問題。它不一定比文字搜尋更適合找一段錯字，也不一定比 embedding 更適合找概念相似的長篇文件。
實務上更合理的架構通常不是「圖譜取代所有工具」，而是讓不同檢索方式各自處理擅長的問題：
- grep 處理精確字串；
- embeddings 處理模糊語意；
- knowledge graph 處理結構與多跳關係；
- source code 與測試仍作為最終真源。
星數接近十萬，代表什麼、不代表什麼
截至 2026 年 7 月 29 日查核，Graphify 的 GitHub stars 已接近 10 萬。對一個 7 月才公開推出的開源工具來說，這反映開發者確實對 codebase memory 與結構化 context 有強烈興趣。
但 stars 不是採用率、效能 benchmark，也不是品質保證。
真正需要觀察的是：圖譜能否持續更新、關係標籤是否可信、agent 是否真的優先查圖而不是照樣重讀檔案，以及團隊是否能把圖譜納入現有 review 與驗收流程。
導入前可以先問的五個問題
- 專案最常卡住的是精確搜尋、語意搜尋，還是跨模組關係？
- Code graph 更新頻率能否跟上每日 commit？
- 哪些 edge 是 parser 直接取得，哪些是模型推論？
- 使用 hosted model 處理文件時，資料會經過哪個服務？
- AI 回答後，是否仍能回到 source code、測試與
file:line驗證？
如果這五題沒有答案，再漂亮的圖譜也可能只是一張很快過期的架構海報。
結語
AI coding 工具的第一階段，競爭的是模型能寫多少程式。
下一階段可能更像記憶與檢索工程：誰能讓模型在正確的時間拿到正確的關係，而且不必每次都從零探索同一個專案。
Graphify 值得看的地方，不是它宣稱 AI 從此理解一切，而是它把 codebase context 從「每次臨時重讀」變成「可追蹤、可更新、可查詢的結構」。
模型能力仍然重要。但當 codebase 越來越大，讓 AI 不再每次失憶，可能比再多一點生成速度更有價值。
查證摘要
- Graphify 於 2026-07-01 公開推出，是 Apache 2.0 授權的開源 code knowledge graph 工具。
- 程式碼使用 tree-sitter AST 在本機解析；非程式碼內容使用設定的模型做語意連結。
- 關係分為
EXTRACTED、INFERRED與AMBIGUOUS。 - 主要產出為
graph.html、GRAPH_REPORT.md與graph.json。 - 支援 CLI 查詢與 MCP 整合，官方文件稱支援 36 種程式語言。
- 「接近 10 萬 stars」只描述 2026-07-29 查核快照，不代表採用率或成效。
- 不宣稱固定 token 節省倍數，因缺乏足夠一致的官方 benchmark。