Graphify：先把資料變成知識圖譜，再讓 Claude Code 讀懂你的專案

當資料散落在程式碼、文件、簡報、截圖、PDF、白板照片裡時，很多 AI 助手的第一步其實不是「理解」，而是「反覆讀檔」。問題在於，原始素材越多，重複掃描的成本就越高，真正能被引用、追蹤、延伸的結構卻沒有被留下來。

Graphify 想解的，就是這個很現實的痛點。

它是一個 Claude Code skill。你只要在 Claude Code 裡輸入 /graphify，它就會讀取你指定的資料夾，先建立一張知識圖譜，再把結果回饋給你。官方 README 對它的定位很直接：不是單純做摘要，而是把雜亂的素材連成節點與關係，讓後續查詢能建立在結構上，而不是每次從零開始重讀。

它不是只看程式碼，而是把「專案上下文」一起吃進去

Graphify 支援的輸入類型比一般開發工具廣得多。README 明確提到，它可以處理：

程式碼
SQL schema
R scripts
shell scripts
文件
論文
圖片
截圖
圖表
白板照片
其他語言的圖片內容

這件事很重要，因為真實專案的上下文通常不是純程式碼。架構圖可能在簡報裡，需求說明在文件裡，資料結構在 SQL 裡，討論結論在截圖裡，甚至關鍵決策只存在某張白板照片上。Graphify 的價值不是把其中一種檔案做得更漂亮，而是把這些原本分散的資訊放進同一個關係網裡。

對 AI 工作流來說，這會改變很多事情。當模型下次再問同一個專案問題時，它不需要重新掃一遍所有原始檔，而是可以先查圖譜裡的節點、關係與群落，再回到最有價值的上下文。

輸出不是單一報告，而是一整套可重用的資料結構

Graphify 產生的不是一份靜態總結，而是一組可以延伸使用的輸出：

graph.html：互動式圖譜，可以點節點、搜尋、過濾群落
obsidian/：可直接當成 Obsidian vault 開啟
wiki/：類維基文章，方便代理導航
GRAPH_REPORT.md：包含重點節點、意外連結與建議問題
graph.json：可持久化的圖譜資料，之後不用重讀全部來源
cache/：用 SHA256 快取，只處理變更過的檔案

這組輸出很有意思，因為它把「給人看」和「給機器用」一起考慮了。graph.html 適合人工探索，graph.json 適合機器查詢，wiki/ 和 GRAPH_REPORT.md 則介於兩者之間，讓你可以先快速掌握結構，再進一步深入。

如果你有用過類似的資料整理工具，就會知道很多工具會停在「輸出一份摘要」就結束。但對知識工作來說，摘要只是入口。真正有價值的是：下一次要查的時候，這份結構還在，而且可以持續累積。

它最大的特色，是把圖譜做成「持久化」流程

官方 README 特別強調兩件事：

圖譜可以跨 session 持續保留
重新執行時只會處理變更過的檔案

這代表 Graphify 的工作方式不是一次性的批次摘要，而是比較接近一個可維護的知識層。你每次新增文件、換了一批截圖、補了一些筆記，它不需要全部重建；它會盡量只更新變動部分。

對團隊來說，這種設計的意義在於降低維護成本。很多 AI 工具在 demo 階段看起來很厲害，但一旦進入真實專案，就會卡在「重新餵資料太麻煩」、「每次上下文都要重建」、「前一次的整理無法沿用」這些問題。Graphify 嘗試把這些問題前移，在資料層先做結構化。

這個工具適合誰

如果你的工作內容符合下面幾種情境，Graphify 會特別有感：

你常常在一個資料夾裡混放程式碼、截圖、需求、研究筆記
你希望 AI 先理解結構，再開始回答問題
你想讓專案知識可以重複利用，而不是每次重新摘要
你有 Obsidian、維基式文件或知識圖譜的使用習慣
你在做多代理工作流，想把「資料整理」變成前置步驟

它不只適合大型程式碼庫，也適合研究資料、原型設計、產品討論紀錄，甚至混合了圖片與文件的多模態專案。只要你的上下文不是整齊地待在單一程式目錄裡，Graphify 就有機會把散落的東西重新接起來。

安裝與上手門檻其實很明確

README 寫得很清楚：Graphify 需要兩個前提。

Claude Code
Python 3.10+

安裝方式也很直白：

pip install graphifyy && graphify install

這裡有一個小細節值得注意：PyPI 套件暫時叫做 graphifyy，不是 graphify。官方 README 也提醒了 Windows 與 macOS 的安裝注意事項；如果環境是外部管理或 PATH 沒設好，可以考慮用 pipx。

安裝完成後，你只要在任意資料夾裡開 Claude Code，輸入：

/graphify .

如果你不想依賴套件安裝，README 也提供了手動安裝方式，直接把 skill 放進 ~/.claude/skills/graphify/SKILL.md，再加入 ~/.claude/CLAUDE.md。這種雙路徑設計很好，因為它同時照顧了想快速試用的人，以及想把技能固定進工作流的人。

這類工具真正值得寫成文章的原因

Graphify 之所以值得注意，不只是因為它「會做知識圖譜」，而是因為它把知識圖譜放進了實際代理工作流的入口。

很多知識圖譜工具是在事後分析資料，Graphify 則是讓代理在讀資料之前，先把資料結構化。差別在於，前者偏向回顧，後者偏向工作流前置。

這會讓整個 AI 協作方式變得比較像「先整理，再推理」，而不是「先胡亂掃過，再硬生出答案」。當資料來源越複雜，這個差異越大。

如果你正在設計一個會持續演化的專案知識庫，Graphify 提供的其實不是一個漂亮的視覺化，而是一種更穩的中間層：把文件、程式碼、圖片和關係先留下來，讓後面的分析、搜尋、問答與寫作都可以站在同一個基礎上。

我會怎麼看它

我會把 Graphify 看成一個很實用的「結構化前處理器」。它不是要取代你的編輯器、筆記工具或文件系統，而是補上這些工具之間最缺的一段：把原始素材轉成可查詢、可延續、可跨 session 使用的知識圖譜。

如果你手上剛好有一堆雜亂的專案資料，這種工具的價值會非常直接。因為它解決的不是抽象的 AI 願景，而是每天都會遇到的現實問題：

這個專案到底有哪些重要節點？
哪些文件彼此有關聯？
哪些圖片其實是關鍵上下文？
下次提問時，能不能不要再從頭讀一次？

Graphify 的回答是：可以，先把它們變成圖。

參考資料

GitHub：<https://github.com/Graphify-Labs/graphify>
README：<https://raw.githubusercontent.com/Graphify-Labs/graphify/main/README.md>