---

title: Graphify 技術拆解：從 Karpathy 的 raw/wiki 工作流走向多模態知識圖譜編譯器 date: 2026-04-08 source: https://www.threads.com/@meow.coder/post/DW0kVPXFCob category: articles tags:

• Graphify
• LLM Wiki
• Andrej Karpathy
• Knowledge Graph
• Token Optimization
• Tree-sitter
• Multimodal
• Claude Vision created: 2026-04-08 updated: 2026-04-08

---

Graphify 技術拆解：從 Karpathy 的 raw/wiki 工作流走向多模態知識圖譜編譯器

概要

這篇 Threads 的價值，在於它不是只說「Graphify 很酷」，而是把 Graphify 為什麼值得注意 講得更具體：

• 它不是單純做摘要
• 也不是單純把資料餵進 RAG
• 而是試圖把 Karpathy 的 raw/wiki 工作流 升級成一套多模態知識圖譜編譯器

如果前一篇可以視為 Graphify 的出場介紹，那這篇比較像技術側的補完版。

原始問題：Karpathy 的 raw/wiki 思路雖好，但手工維護成本高

貼文點出的痛點很準：

1. raw 資料夾雖然自由，但整理成本還是在

你可以把各種素材先丟進 ：

• 程式碼
• 文件
• 論文
• 圖片
• 隨手摘錄

但如果沒有中介工具，後面仍然要面對：

• 手動分類
• 持續追更新
• 舊知識回寫
• 新舊材料連結

所以 raw-first 只是降低輸入門檻，不等於維護成本消失。

2. 反覆讀原始檔案很燒 token

這篇直接點出 Karpathy 自己也提到的問題：

很多 token 消耗，其實不是在跑程式，而是在反覆讀取與理解原始資料。

這是知識工作流裡很真實的瓶頸。尤其一旦資料來源變成：

• repo
• PDF
• Markdown
• 圖片 / 截圖
• 混合文件夾

每次 query 都重讀一次，成本很快爆炸。

3. 傳統 raw 工作流還停在「手動流程」

也就是說，概念對了，但沒有被真正產品化 / 工具化。

Graphify 的技術路線

這篇提供了比上一篇更清楚的技術輪廓。

1. 全模態自動圖譜化

Graphify 的野心是：

不管你丟的是 code、pdf、markdown、圖片，都盡量轉成同一套可查詢的圖譜層。

這意味著它不是把資料當成單純文本，而是先依素材型態選不同的抽取方式。

2. 對 code 用 tree-sitter 做本地 AST 解析

這點很重要。

如果對 code 直接上 LLM：

• token 浪費大
• 結構理解不穩
• 很多可確定的事情卻交給語言模型猜

Graphify 這條路則是：

• 先用 tree-sitter 在本地抽 AST
• 先做 deterministic extraction
• 盡量把「可機械解析」的部分留在本地完成

這比單純把 repo 全丟給模型聰明很多。

3. 對 PDF / Markdown 做語義單元切分

這表示它不是把整份文件當一大坨文本，而是拆成更合適的知識片段。

如果做得好，這會直接影響：

• 圖譜節點品質
• 後續 query 的精準度
• summary / report 的可讀性

4. 對視覺內容用 Claude Vision 做概念抽取

這裡補上了它為什麼是「多模態」而不是「文件工具」：

• 截圖
• 圖表
• 視覺素材

都可以被抽成概念層，再納入整體知識圖譜。

這對現代工作流其實很有用，因為知識不再只存在於 和 。

為什麼它能省 71.5 倍 token？

貼文給了一個關鍵線索：

雙階段流程

第一階段：對 code 做本地 deterministic extraction

• AST
• 結構
• 零 token

第二階段：對非 code 內容用並行 LLM subagents 做語義抽取

• 文件
• 圖片
• 論文
• 其他語義內容

這種做法的厲害之處在於：

把「一定可以靠程式完成的事情」先在本地做掉， 只把真正需要語義理解的部分交給 LLM。

所以它不是神奇壓縮，而是計算分工更合理。

它和一般 RAG / 向量庫的差別

一般 RAG 比較像

• 資料切 chunk
• 做 embedding
• 問問題時撈相關片段

Graphify 比較像

• 先理解資料夾結構
• 先抽節點 / 關係 / 報告
• 先做知識表示
• 後續 query 再站在這層知識表示上操作

也就是說，它不是「搜片段」，而是更接近：

把資料夾預編譯成 AI 可讀的知識中介層。

它和 Karpathy 的 LLM Wiki 是同一個概念嗎？

Threads 底下有人留言說「看來和 Karpathy 的個人知識庫不是一個概念」，這個觀察其實半對半錯。

相同處

• 都是在解決「知識如何長期累積」
• 都不滿足於 ask-time retrieval
• 都強調把原始素材轉成更高階的知識表示

不同處

• LLM Wiki 偏重持續維護 wiki 頁面
• Graphify 偏重把資料夾編譯成 graph / report / json

所以比較準確的說法是：

Graphify 不是 LLM Wiki 本身， 但它可以被看成是 LLM Wiki 思路往「圖譜編譯器」方向的一次演化。

對 Allen / OpenClaw 工作流的啟發

這條線最值得借鏡的，不是要不要直接改用 Graphify，而是它點出了一個很好的中介層設計：

這對 Allen 現在在做的幾條線都很 relevant：

• Allen KB 知識圖譜
• OpenClaw memory / long-term memory
• repo / docs 的 agent 理解效率
• token 成本控制

我的判斷

真正值得注意的點

1. 不是單純又一個 AI 摘要工具
2. 抓到「先編譯、再查詢」這個方向
3. 把 deterministic parsing 和 LLM semantic extraction 分開
4. 把多模態內容一起拉進知識圖譜層

需要保留觀察的點

1. 圖譜品質是否穩定
2. 大型目錄重建成本如何
3. 多模態抽取的一致性如何
4. 是否真能有效代理原始文件

一句話總結

Graphify 值得注意，不只是因為它省 71.5 倍 token，而是因為它代表一種更成熟的知識處理架構：把 Karpathy 的 raw/wiki 思路從人工工作流，推進成「本地解析 + 多模態語義抽取 + 圖譜中介層」的知識編譯器。