Graphify：無需向量庫，把任意程式碼庫變成可查詢的知識圖譜

程式碼庫在變大，筆記、論文和截圖也在不斷堆積，而程式設計智慧體每次開啟新會話，幾乎都要從零開始重讀這些原始檔案。這既燒掉大量 token，也讓知識無法跨會話沉澱。Graphify 正是針對這一痛點出現的開源專案。它是一個 Claude Code 技能：在 Claude Code 裡輸入 /graphify，它會讀取目錄下的檔案，構建一張知識圖譜，再把你原本不知道存在的結構交還給你。專案自述稱，與直接閱讀原始檔案相比，每次查詢所用的 token 少 71.5 倍，圖譜可以跨會話持久儲存，並且會誠實地區分哪些內容是“找到的”，哪些只是“猜測的”。專案 README 還借用了 Andrej Karpathy 的做法作類比：Karpathy 習慣保留一個 /raw 資料夾，隨手丟進論文、推文、截圖和筆記，而 Graphify 想解決的正是這種“資料越堆越多、卻無法被有效呼叫”的問題。需要說明的是，71.5 倍這個數字來自專案自身的說明，我們沒有獨立復現，讀者應把它當作量級參考，而不是保證。

Graphify 的第一個特點是完全多模態。它的輸入不限於原始碼：PDF、Markdown 文件、螢幕截圖、架構圖、白板照片，甚至其他語言書寫的圖片，都可以直接丟進去。專案使用 Claude 的視覺能力，從這些異構材料中抽取概念與關係，再把它們連線進同一張圖。這意味著一張手繪的系統草圖、一份設計評審的 PDF 和一段核心模組的原始碼，可以在圖譜裡成為相互關聯的節點，而不是散落在三個互不相通的目錄裡。對於經常需要在“文件說的”和“程式碼做的”之間來回核對的團隊來說，這種統一表示本身就有價值。同時，它採用的是結構化圖而不是向量檢索，因此標題裡強調“無需向量庫”：查詢依賴節點與邊的顯式關係，而不是嵌入空間裡的相似度。

第二個特點在於產出物的設計。執行 /graphify . 之後，會生成一個 graphify-out 目錄，裡面分工明確。graph.html 是可互動的圖譜，可以點選節點、搜尋，並按社群過濾。obsidian 目錄可以直接作為 Obsidian 知識庫開啟。啟用 --wiki 引數時，會生成類似維基百科風格的條目，專門供智慧體導航使用。GRAPH_REPORT.md 是一份報告，列出“上帝節點”（連線最密集的核心概念）、出人意料的跨領域連線，以及建議你繼續追問的問題。graph.json 是持久化的圖譜本體，數週之後無需重讀原檔案即可查詢。最後，cache 目錄儲存 SHA256 快取，使得重新執行時只處理發生變化的檔案。這套設計把“給人看”和“給智慧體用”兩條路徑同時照顧到了，而增量快取讓它在日常迭代的倉庫裡不至於每次都重新付費。

安裝方式也很輕量。它要求已安裝 Claude Code 與 Python 3.10 以上，執行 pip install graphifyy 再執行 graphify install 即可。這裡有一個容易踩坑的細節：PyPI 上的包名暫時叫 graphifyy，因為 graphify 這個名字仍在回收中，但命令列工具和技能命令依然叫 graphify。Windows 使用者若安裝後找不到命令，需要把 Python 的 Scripts 目錄加入 PATH，或者改用 pipx；macOS 上遇到“外部管理環境”報錯時，同樣建議使用 pipx。也可以手動安裝：用 curl 下載技能檔案 SKILL.md 放到 ~/.claude/skills/graphify 目錄，再在 ~/.claude/CLAUDE.md 中登記。之後在任意目錄開啟 Claude Code，輸入 /graphify . 即可開始。

把它放進具體場景，價值會更清楚。設想一位新加入團隊的工程師，面對一個陌生的大倉庫，手邊還有幾份設計文件和一張白板照片。過去的做法是讓智慧體逐個檔案開啟，邊讀邊總結，下一次會話又得重來。有了圖譜之後，智慧體可以先看 GRAPH_REPORT.md，瞭解哪些是核心節點、哪些模組之間存在意料之外的耦合，再沿著圖中的邊去追問具體問題，只在需要時回到原檔案核對細節。這種“先看地圖，再進現場”的工作方式，與傳統的檢索增強生成並不衝突，而是換了一個切入點：它先把關係理清，再談召回。當然，它是否優於純向量檢索，取決於任務型別。對於強調結構、依賴與概念關聯的問題，圖通常更直觀；對於需要在大量相似段落中模糊匹配措辭的問題，向量檢索仍有其位置。兩者並用，也許才是更穩妥的選擇，團隊可以先小範圍試用，再逐步擴大。

從行業視角看，Graphify 代表了一條值得關注的路線：不把長期記憶完全交給向量庫，而是讓大模型一次性把材料“編譯”成顯式的圖結構，之後的查詢只讀圖。這樣做的好處是結果可審計、可增量更新、跨會話穩定；代價是圖的質量取決於模型抽取的準確度，錯誤的邊會被固化下來。專案強調要區分“找到的”和“猜測的”，正是對這一風險的回應，但具體做到什麼程度，仍需要讀者在自己的語料上抽樣檢驗。另外，首次構建大型目錄時需要呼叫模型，尤其是視覺抽取，成本不可忽略，增量快取只能緩解後續執行的開銷。我們的建議是：先在一箇中等規模的倉庫上試跑，對照 GRAPH_REPORT.md 裡的核心節點，檢查它是否真的符合你對系統的理解，再決定是否把它納入日常的智慧體工作流。如果結果可信，它有望成為連線程式碼、文件與視覺資料的一層通用上下文基礎設施。