Karpathy 式個人知識庫：用 LLM 把 raw 素材「編譯」成 wiki，再用 Obsidian 當前端

核心概念

前 Tesla AI 總監、OpenAI 創始成員 Andrej Karpathy 最近分享了一種用 LLM 建個人知識庫的方式：

• 先把原始素材丟進 raw/ 資料夾
• 讓 LLM 去「編譯」素材，自動整理成 wiki
• wiki 裡包含：
  • 每份素材的摘要
  • 按主題分類的概念條目
  • 條目之間的 backlink
• 用 Obsidian 當前端瀏覽
• wiki 幾乎全部由 LLM 撰寫與維護，人只做少量直接修改

當 wiki 累積到一定規模後，就可以直接對知識庫提問，讓 LLM 自己翻資料、交叉比對、組織答案。

---

知識庫會越用越厚

Karpathy 的流程不只是「問答」，而是形成一個閉環：

1. 素材進 raw/
2. LLM 編譯成 wiki
3. 人對 wiki 提問
4. LLM 產出有價值的回答
5. 把回答再存回 wiki

這代表知識庫不是靜態倉庫，而是會持續增厚的研究介面。

他也會定期讓 LLM 跑「健檢」：

• 找出資料矛盾
• 補上缺漏
• 發現素材之間意想不到的連結

---

Obsidian 的角色：不是內建 AI，而是當 AI 的拼圖

作者的觀察很準：Obsidian 過去兩三年幾乎沒有積極推 AI 功能，但這反而成了優勢。

它的策略不是「把 AI 全包進來」，而是：

不內建 AI，讓使用者自己拿去搭配，只要成為可以和 AI 銜接上的拼圖就好。

這讓 Obsidian 很適合搭配 Claude Code / LLM 工作流：

• 幫忙分類、整理資料庫
• 每天自動問三個問題，生成 Daily Note
• 參考過往文章，產出更符合需求的擬答

---

從內容產線角度的啟發

作者原本的內容流程是：

• 素材按人物或主題分資料夾
• 放文章、逐字稿、筆記等參考資料
• 再寫成電子報草稿、Podcast 大綱

流程大致是： 選題 → 讀內容 → 寫稿 → 校對 → 發布

問題在於：

素材之間的連結都在腦中。

每次開新題目，都要重新從記憶裡撈「之前讀過哪些相關材料」，素材一多，這件事就越吃力。

Karpathy 的做法補上了這個缺口：

• 自動建立素材間的 backlink
• 找出不同素材之間的新連結
• 建議哪些連結值得寫成新條目

---

可延伸到寫作系統的 3 個實用功能

如果把 Karpathy 的「編譯」概念套進寫作 / 內容產線，可以再多做幾件事：

1. 追蹤哪些段落已經寫進哪篇文章
2. 標記哪些故事還沒寫過
3. 列出還沒用過的寫作角度，讓選題時看到更多可能性

這比單純做筆記更進一步，開始接近「內容知識作業系統」。

---

為什麼這種系統會讓人有成就感

作者最後把這件事連回一個很好的心理學隱喻：

fire together, wire together

也就是 Hebb 的長期增強理論：當神經元同時激發，它們之間的連結會加強；重複得越多，連結越強。

這個概念剛好也能描述個人知識庫的價值：

• 不是每份素材都立即有用
• 但前面讀過的東西，會在未來某個主題上突然接起來
• 真正的價值常常來自跨素材、跨主題的連結被重新發現

這也是 LLM + wiki 最值得期待的地方：它不只是幫你找資料，而是幫你把過去散落的思考重新接線。

---

對知識工作者的啟示

這篇最值得記下來的，不是「Obsidian 好不好用」，而是：

未來的個人知識庫，不只是儲存系統，而是編譯系統。

真正重要的能力，會從「記得資料在哪」轉成：

• 如何讓素材被自動整理
• 如何讓連結被自動建立
• 如何把高價值輸出再回存系統
• 如何讓知識庫持續變厚、變有關聯性

---

Karpathy 這套做法最刺激的一點：未必要先上 RAG

這波討論裡最容易被忽略、但其實最關鍵的一句是：

當 wiki 累積到一定規模後，LLM 可以自己維護索引、自己寫摘要，再直接到 wiki 裡翻答案。

這意味著他的第二大腦方案，核心不一定是「先建向量資料庫、再做 retrieval pipeline」，而可能只是：

• 一個資料夾
• 一堆 markdown 檔
• 一個會整理與維護 wiki 的 LLM

也就是說，個人知識庫場景下，RAG 不一定要先等於向量搜尋。

當資料規模還在可控範圍，且知識已經被 LLM 編譯成結構化 wiki 時：

• 摘要
• backlink
• 主題條目
• 交叉引用

本身就已經是一種「由 LLM 維護的索引層」。

這和傳統先 chunk、embedding、top-k retrieval 的思路不同。Karpathy 比較像是在押注：

先把知識整理成好讀、好連結、好維護的 markdown wiki，很多檢索問題自然會變簡單。

這也是為什麼這套方法會讓很多研究 RAG pipeline 的人特別有感——它不是在否定 RAG，而是在提醒：

對個人知識庫而言，wiki compiler 可能比向量資料庫更接近第一性原理。