Karpathy 的 LLM Wiki 工作流和 NotebookLM 有什麼差別？

NotebookLM 是 RAG 系統，每次提問時 AI 臨時去找資料，知識不會累積。Karpathy 的 LLM Wiki 工作流是讓 AI 主動把每份新資料整合進現有知識庫，知識持續累積，每次加入新資料都讓整個系統更聰明，而不只是增加了一份文件。

這套 LLM 知識庫工作流一定要用 Claude Code 才能實作嗎？

完整實作需要 Claude Code 或 OpenAI Codex 等可操作本地文件的 AI Agent，有一定技術門檻。但核心思維不需要寫程式就能借鑒：把筆記分成原始資料和整理後的知識兩層，每次請 AI 把新文章整合進已有的筆記，並把好的 AI 回答存下來而不是讓它消失在對話記錄裡。

Andrej Karpathy LLM 知識庫工作流解析：AI 幫你管理筆記和資料

Karpathy 的 LLM 知識庫工作流：用 AI 管理筆記和資料

最後更新於 2026 年 4 月 6 日 – 作者: Lazy Kar

📌 Karpathy 的 LLM 知識庫工作流在講什麼？（30 秒摘要）

前 OpenAI 聯合創辦人、前特斯拉 AI 總監 Andrej Karpathy，於 2026 年 4 月 3 日在 X 發文分享了用 LLM 建立個人知識庫的工作流，隨後在 4 月 4 日發布完整的 GitHub Gist（LLM Wiki）。核心概念是：與其每次問 AI 都重新找資料，不如讓 AI 幫你把資料「編譯」成一個持續累積的 Wiki 知識庫。本文完整解析他的方法論，涵蓋三層架構、四個核心操作、Obsidian 實用技巧，以及非技術用戶如何借鑒這套思路。

你有沒有這個經驗：收藏了幾百篇文章，記了不少筆記，三個月後回頭看——完全想不起來哪篇在講什麼，也找不到你要的東西。

傳統解法是「定期整理」，加標籤、補連結、重新分類。試了兩週就放棄了。靠人來維護筆記庫，理論上可以，實際上很難持續。

Karpathy 提出了一個不同的思路：別讓人整理，讓 LLM 整理。

Karpathy 是誰？為什麼值得關注？

Andrej Karpathy 是 AI 圈的頂級研究者——OpenAI 聯合創辦人之一、前特斯拉 AI 總監，也是「vibe coding」這個詞的發明者，現在專注於 AI 教育。他在 2026 年 4 月 3 日發的推文迅速引爆討論，隨後在 4 月 4 日整理成完整的 Gist 文件分享出來。

原始 Gist：github.com/karpathy/442a6bf555914893e9891c11519de94f（發布兩天內獲得超過 4,400 個 Star）

核心問題：你的知識庫為什麼會廢掉？

Karpathy 點出了一個大多數人沒意識到的問題。

現在多數人用 AI 處理文件的方式，叫做 RAG（Retrieval-Augmented Generation）：你上傳一堆文件，AI 在你提問時去找相關片段，生成答案。NotebookLM、ChatGPT 的檔案上傳功能、大多數 AI 知識庫工具都是這個邏輯。

這個方式有個根本問題：AI 每次都在從零開始重新發現知識，沒有任何累積。你問一個需要整合五份文件才能回答的複雜問題，AI 每次都要重新找、重新整合。知識庫用了三年，AI 的理解程度跟第一天一樣。

💡 RAG vs LLM Wiki：核心差異

RAG 的邏輯：每次問問題 → AI 臨時去找資料 → 生成答案 → 結束，下次重來
LLM Wiki 的邏輯：每加入一份資料 → AI 把它整合進已有的知識庫 → 知識庫持續累積 → 下次問問題時知識已經在那裡了

Karpathy 的解法：把知識庫當作程式碼來管理

Karpathy 用了一個對工程師來說很直覺的比喻：原始資料就像原始碼。你不直接編輯編譯後的產物，你只修改原始碼，然後重新編譯。知識庫也一樣——原始資料是你的「原始碼」，AI 幫你「編譯」成有組織的 Wiki，你讀的是編譯後的結果。

即使你不寫程式，這個比喻也很清楚：Obsidian 是前端介面，LLM 是後端工程師，Wiki 是他們共同維護的產品。

💡 對企業的啟示

在 Karpathy 的推文下，創業者 Vamshi Reddy 的評論被廣泛轉發：「每個企業都有一個 raw/ 目錄——Slack 記錄、會議逐字稿、客戶電話、產品文件。沒有人編譯過它。那就是產品機會所在。」Karpathy 本人對此表示認同。

三層架構：raw / wiki / schema

Karpathy 的系統由三層組成：

第一層：raw/（原始資料，只讀）

這是你收集的所有原始資料——文章、論文、播客筆記、圖片、數據集。這個目錄的規則只有一條：AI 可以讀，但不能修改。這是你的真相來源（source of truth），必須保持原封不動。

如何把資料放進來：

網頁文章：用 Obsidian Web Clipper 瀏覽器擴充功能，一鍵把網頁轉成 Markdown 存入
PDF / 論文：直接放進資料夾
播客：用 Podwise 等工具轉成文字稿後放入
圖片：建議下載到本地（詳見下方 Obsidian 技巧）

第二層：wiki/（AI 維護的知識庫）

這是整個系統的核心。Wiki 是一個由 Markdown 文件組成的目錄，完全由 AI 撰寫和維護，你幾乎不直接編輯它。

每次你把新資料加入 raw/，AI 會：

讀取這份新資料，與你討論重點
在 wiki/ 裡建立這份資料的摘要頁面
更新相關的概念頁面（一份新資料可能觸及 10-15 個已有頁面）
標注新資料與舊知識的矛盾或補充之處
更新索引（index.md）和操作記錄（log.md）

第三層：schema（給 AI 的工作說明書）

Schema 是一份文件，告訴 AI 這個知識庫的結構規範、命名慣例、以及遇到各種情況要怎麼處理。在 Claude Code 裡這個文件叫 CLAUDE.md，在 OpenAI Codex 裡叫 AGENTS.md。這個文件的存在讓 AI 從「一個通用聊天機器人」變成「這個知識庫的專屬維護者」。你和 AI 會隨著時間一起完善這份文件。

📌 三層架構速覽

raw/ ── 原始資料，你收集，AI 只讀不改

wiki/ ── 知識庫，AI 撰寫和維護，你讀

schema（CLAUDE.md / AGENTS.md）── 工作說明書，告訴 AI 怎麼維護這個知識庫

工具：Obsidian 當前端瀏覽器，LLM Agent（Claude Code / OpenAI Codex / OpenCode）當後端維護者

四個核心操作

1️⃣ Ingest（資料匯入）

你把新資料放進 raw/，告訴 AI 處理它。AI 讀取資料、跟你討論重點、建立摘要、更新相關頁面、記錄日誌。Karpathy 偏好一次匯入一份資料，保持參與感——他會讀 AI 寫的摘要，確認方向對，再讓 AI 繼續更新相關頁面。你也可以批次匯入多份資料，端看你的工作風格，並把這個工作流偏好記錄在 schema 裡供日後使用。

2️⃣ Query（問答）

Wiki 夠大之後，直接對著知識庫提問。AI 會先讀 index.md 找到相關頁面，再深入這些頁面，整合出帶有引用來源的答案。輸出形式很靈活：Markdown 頁面、比較表格、Marp 投影片、matplotlib 圖表，都可以。

Karpathy 的一個重要洞察：好的答案本身就可以存回 Wiki。你問了一個比較分析，AI 整理出來的結果很有價值，就把它存成一個新的 Wiki 頁面。你的每一次提問都在讓知識庫變厚，而不是消失在對話記錄裡。

3️⃣ Lint（健康檢查）

定期請 AI 掃描整個 Wiki，找出：

不同頁面對同一概念有矛盾定義
有重要概念被提到但沒有自己的頁面
孤島頁面（沒有任何其他頁面連到它）
被新資料推翻的舊有說法
資料缺口（可以補充網路搜索）

這一步是讓知識庫保持健康、不隨時間腐爛的關鍵機制。Karpathy 形容它是讓知識庫「自我修復」的機制。

4️⃣ Index + Log（導航系統）

兩個特殊文件讓 AI（和你）在知識庫變大後還能找到東西：

index.md——內容導向的目錄，列出所有頁面、一行摘要、分類標籤（實體、概念、資料來源等）。AI 在回答問題前先讀這個，找到相關頁面再深入。在中等規模（約 100 份資料、幾百個頁面）下，這個方式比建向量資料庫的 RAG 更簡單，效果已經夠好。

log.md——時間軸式的操作記錄，追加模式（不刪改），記錄每次匯入、問答、健康檢查的時間和內容。Karpathy 建議每條記錄用統一的前綴格式開頭（例如 ## [2026-04-04] ingest | 文章標題），這樣可以用簡單的工具解析記錄。

這套方法適合哪些場景？

Karpathy 在 Gist 裡列舉了幾個他認為最適合的應用場景：

個人成長與自我追蹤：目標、健康、心理狀態——把日記、文章、播客筆記歸檔，讓 AI 幫你建立一個關於自己的結構化圖像
深度研究：花幾週或幾個月鑽研某個主題，持續累積論文、報導、報告，讓 Wiki 跟著你的研究一起演化
讀書筆記：每讀完一章就歸檔，讓 AI 建立人物、主題、情節的頁面並相互連結。Karpathy 以 Tolkien Gateway 為例——那是一個由社群志願者建立的托爾金作品百科，有數千個相互連結的頁面。你一個人讀一本書，就可以建出類似結構的私人 Wiki，而且不需要自己做任何連結工作
企業/團隊內部知識庫：以 Slack 討論、會議記錄、專案文件、客戶電話為原料，讓 LLM 維護一個持續更新的內部 Wiki，解決「沒有人想做維護」這個老問題
其他：競品分析、盡職調查、旅遊規劃、課程筆記、任何需要長時間累積知識的領域

Obsidian 使用技巧

Karpathy 在 Gist 裡附了幾個具體的 Obsidian 技巧：

圖片下載到本地

在 Obsidian 設定裡，進入「Files and links」，把「Attachment folder path」設為固定目錄（例如 raw/assets/）。然後在「Hotkeys」搜尋「Download」，找到「Download attachments for current file」並設定快捷鍵（例如 Ctrl+Shift+D）。剪藏一篇文章後，按快捷鍵就能把所有圖片下載到本地。這讓 AI 可以直接引用圖片，不依賴可能失效的網址。

💡 關於 LLM 讀圖的注意事項

Karpathy 特別提到：LLM 無法在一次讀取 Markdown 時同時處理內嵌圖片。變通方式是讓 AI 先讀文字，再單獨查看相關圖片獲取補充資訊。有點繁瑣，但實際效果還不錯。

Graph View（圖譜視圖）

Obsidian 的 Graph View 是查看 Wiki 整體形狀的最佳方式——哪些頁面是核心樞紐、哪些是孤島。這是判斷知識庫健康狀態的視覺工具。

Marp 投影片

Marp 是基於 Markdown 的投影片格式，Obsidian 有對應的插件。可以直接從 Wiki 內容生成簡報，讓 AI 幫你把知識庫裡的分析輸出成投影片格式。

Dataview 插件

Dataview 可以對 Obsidian 頁面的 YAML frontmatter 執行查詢。如果讓 AI 在建立 Wiki 頁面時加入 frontmatter（標籤、日期、來源數量），Dataview 就能生成動態表格和清單，讓你用資料庫的方式瀏覽 Wiki。

Wiki 本身就是 Git Repo

因為所有內容都是純文字 Markdown 文件，整個 Wiki 就是一個 git repo。你免費獲得：版本歷史、分支、協作能力。

進階：CLI 工具和搜索引擎

當 Wiki 成長到一定規模，index.md 可能不夠用，你需要真正的搜索功能。Karpathy 推薦 qmd——一個本地 Markdown 搜索引擎，使用 BM25 + 向量搜索的混合模式，加上 LLM 重排序，全部在設備上運行。它同時提供 CLI 和 MCP server 兩種介面，可以讓 AI 直接把它當工具使用。

如果不想用第三方工具，也可以請 AI 幫你寫一個簡單的搜索腳本——Karpathy 自己也是這樣做的，他說這是「vibe coded 出來的小工具」。

為什麼這個方法行得通？

維護知識庫最累的部分，不是閱讀和思考，而是書記工作：更新交叉引用、保持摘要與最新資料一致、標注矛盾、維護命名一致性。這些工作人類會做膩、會忘記、會覺得不值得花時間。所以所有人建的 Wiki 最後都死了——維護成本增長的速度比知識累積的價值快。

LLM 不會厭倦，不會忘記更新一個交叉引用，可以在一次操作裡更新 15 個文件。維護成本趨近於零，知識庫才能持續存活。

💡 歷史背景：Vannevar Bush 的 Memex（1945）

Karpathy 提到，這個概念在精神上類似 Vannevar Bush 1945 年提出的 Memex——一個私人的、主動策展的知識庫，文件之間的關聯和文件本身一樣有價值。Bush 的願景比現在的網路更接近這個理念：私人的、主動策展的、連結本身有價值。他當年無法解決的問題是「誰來做維護」。LLM 現在解決了它。

不需要 Claude Code 也能借鑒的核心思維

Karpathy 的完整實作需要 Claude Code 或 OpenAI Codex 這類可以操作本地文件的 AI Agent，門檻比一般 AI 工具高。如果你沒有這些工具，這套方法論仍然有可以立即借用的部分：

思維層面：把你的筆記分成「原始資料」和「整理後的知識」兩層，不要混在一起。原始資料不要動，讓 AI 幫你整理出另一份有組織的版本。

操作層面：每次把新文章貼給 ChatGPT 或 Claude，不要只問「幫我總結」，而是說「幫我把這篇文章的重點整合進我已有的筆記裡，並標注與之前內容有什麼矛盾或補充」。這是手動版的 Ingest 操作。

積累層面：把 AI 給你的好答案存下來，而不是讓它消失在對話記錄裡。每一次好的 AI 對話都是可以累積的知識，丟掉是浪費。

⚠️ 目前的門檻和限制

Karpathy 自己坦承，這套方法目前還是「一堆腳本拼起來的原型」，不是一個完整的產品。完整實作需要 Claude Code、OpenAI Codex 等工具，有一定技術門檻。他認為這裡藏著一個顛覆級產品的機會——等待有人把這套工作流做成真正易用的產品。

Karpathy 說的「下一步」

在原文的最後，Karpathy 提到了他認為自然的下一步：當知識庫夠大，就可以用它來做合成數據生成和微調（fine-tuning）——讓 LLM 把知識「記在權重裡」，而不只是放在上下文視窗中。這意味著個人化 AI 的終極形態：一個真正「消化」了你所有知識的 AI，而不是每次都要重新讀你的筆記。