Graphify 把資料夾變成知識圖譜，但 71.5x 需要前提

Graphify 這週進帳大約 7,300 顆星，一舉擠進 GitHub 週榜前段，總數突破 137,000。它的賣點只有一句話：把編碼代理指向一個資料夾，輸入 /graphify .，就會拿回這個資料夾裡所有內容的知識圖譜。

真正有意思的不是圖譜本身，而是掛在它旁邊的那個數字：相較於直接讀原始檔案，每次查詢的 token 用量少了 71.5x。如果這個結論能夠普遍成立，它就不是一個順手的小工具，而是改變了代理需要承載多少上下文這件事。

它從哪裡來

作者 safishamsi 把這個專案描述成對 Andrej Karpathy 某個習慣的回應：Karpathy 有一個 /raw 資料夾，論文、推文、截圖、筆記全往裡丟，然後就再也找不到東西。這個問題很多人都有共鳴，而這個起源故事比大多數都誠實，因為它描述的是一個失敗模式，而不是一個市場。

它宣稱的目標比「搜尋你的文件」窄得多：產出某種能跨工作階段存活的持久物，並且明確區分哪些是推論出來的、哪些是抽取出來的。圖裡每一條邊都掛了標籤：EXTRACTED、INFERRED 或 AMBIGUOUS。這是不常見的設計選擇，在我看來，也是整件事裡最有價值的部分。

它到底在做什麼

安裝是兩行指令。是的，PyPI 套件名稱暫時是錯的：

pip install graphifyy && graphify install

那個雙寫的 Y 是命名糾紛，不是打錯字。CLI 和 skill 指令至今都還是 graphify。在 Windows 上，如果安裝完指令無法辨識，要嘛把 Python 的 Scripts 資料夾加進 PATH，要嘛改用 pipx install graphifyy，直接繞過這個問題。

接著在 Claude Code 裡，任何目錄下：

/graphify .
/graphify ./raw --mode deep
/graphify query "what connects attention to the optimizer?"
/graphify path "DigestAuth" "Response"
/graphify explain "SwinTransformer"

產出落在 graphify-out/。裡面有一個可以點著看的互動式 graph.html，一個能當成 vault 開啟的 obsidian/ 資料夾，一個持久化的 graph.json（幾週後再查，也不用重讀任何檔案），一個以 SHA256 為鍵的 cache/（重跑時只處理更動過的檔案），還有一份 GRAPH_REPORT.md，列出它所謂的 god nodes —— 連接度最高的概念 —— 以及依綜合評分排序的「意外連結」，其中程式碼到論文的邊比程式碼到程式碼的邊權重更高。

多模態那部分是玩真的，不是行銷話術。程式碼檔案走 tree-sitter 做 AST 解析，再加一輪呼叫圖分析。Markdown、PDF 和圖片走 Claude：從散文裡抽概念與關係，從論文裡挖引用，用視覺能力處理截圖、示意圖、白板照片和其他語言的圖片。

還有一些匯出格式，對不想被困在這個工具裡的人很重要：--svg、給 Gephi 或 yEd 用的 --graphml，以及 --neo4j —— 它產生一個 cypher.txt，而不是要求你跑一個資料庫。技術堆疊是 NetworkX、透過 graspologic 做 Leiden 分群、tree-sitter 和 vis.js。沒有伺服器。除了 Claude 呼叫之外，什麼都不離開本機。

拆解那個 71.5x

基準語料是 52 個檔案：Karpathy 的儲存庫、五篇論文、四張圖。結果是相較於直接讀原始檔案，每次查詢的 token 少了 71.5x。

這個儲存庫對「規模變大時會怎樣」異常誠實，這種誠實罕見到值得引述重點：token 的節省會隨語料規模成長；而在只有六個檔案時，圖譜的價值在於結構清晰，而不是壓縮，因為六個檔案本來就塞得進上下文視窗。他們自己拿 graphify 原始碼加上 Transformer 論文的範例是 5.4x。在六個合成的函式庫檔案上，大約是 1x。

這個形狀是對的。如果你的語料本來就在一個上下文視窗之內，你省下的不是 token，你買的是一張地圖。如果是五十個混雜類型的檔案，節省是真的而且很大 —— 因為替代方案不是把檔案讀一遍，而是在多個回合裡反覆讀，每次代理都丟了位置。

這個對比在一邊稍微抬高了 graphify，在另一邊又低估了它。讀原始檔案是最差情況的基準；一個調校過的檢索索引在對比中會比原始檔案好看。但檢索索引回傳的是段落，而 graphify 回傳的是關係 ——「注意力機制和優化器之間靠什麼連起來」的答案不是一段話，而是一條路徑。這是兩種不同的查詢，而向量資料庫只能服務其中一種。

「不用向量資料庫」是一個真正的架構立場

大多數檢索系統把文字切塊、做 embedding、然後做最近鄰搜尋。Graphify 把這些全部跳過：程式碼用本機確定性的 AST 解析，散文和圖片用 LLM 抽取，然後建圖。沒有 embedding 步驟，也沒有相似度搜尋。

換來的是可解釋性。問它兩樣東西為什麼相連，你拿到的是那些邊，每一條都標著是從原文抽取，還是模型推論。向量索引給不了這個。它只能告訴你餘弦距離很小。

代價是覆蓋率。圖只知道抽取器找到的東西。如果抽取那一輪漏掉了一個關係，任何查詢都不會把它翻出來，也沒有模糊備援。AMBIGUOUS 標籤是對此的誠實承認，而 --mode deep 這個旗標之所以存在，是因為預設那一輪對推論邊很保守。

它在哪裡站得住

依我對這類工具的經驗，兩種工作流程。

第一種是上手一個陌生的程式碼庫。不是「函式 X 在哪」—— 這種 grep 就夠了 —— 而是「這裡承重的概念是什麼，其中哪些碰到了計費程式碼」。這是圖的問題，而 god nodes 報告給出的答案，你兩分鐘就能讀完。

第二種是多代理的場景。幾個代理並行寫程式碼時，各自對儲存庫的模型幾分鐘內就會過期。每次提交就重建的圖（graphify hook install 會裝一個 post-commit hook），或者在檔案存檔時重建（--watch），能讓每個代理拿到同一張當前地圖，而不是五份彼此分歧的猜測。

明顯的限制：這東西首先是當成 Claude Code 的 skill 做的。手動安裝路徑會把一個 SKILL.md 丟進 ~/.claude/skills/graphify/，並在 CLAUDE.md 裡加一行。有一個 MCP server 模式（--mcp）給其他用戶端使用，但使用體驗明顯是為單一生態最佳化的；而且對 Claude 的依賴意味著在大型語料上，抽取那一輪要花真金白銀。

誠實的結論

Graphify 不是搜尋引擎，也不該用搜尋引擎的標準去評價。它是一個關於某個資料夾裡有什麼的、持久且可檢查的模型，而且帶有一個不尋常的性質：它會告訴你哪些部分是它猜的。對一個 137,000 顆星、已經紅了一週的專案來說，有意思的問題不是這張圖夠不夠厲害，而是「替推論貼標籤」這個習慣，能不能在只想要答案的使用者手裡活下來。

我猜大多數人只會用 query，無視邊的標籤，永遠不看 graph.json。能留下來繼續用的人，是那些需要地圖、而不是需要標準答案的人。