---

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、圖片，都盡量轉成同一套可查詢的圖譜層。