前幾天 AI 概念大神 Andrej Karpathy 寫了一條推文，講自己如何用LLM做個人知識庫： 最近我發現有一件事非常有用，就是利用大型語言模型（LLMs）為各種感興趣的研究主題構建個人知識庫。這樣一來，我近期處理的文本量中，用於操作代碼的部分大幅減少，而用於操作知識（以 Markdown 和圖片形式儲存）的部分則顯著增加。 結果推文非常火爆，超過千萬閱讀。於是今天他寫了一個完整指南，我編譯了一下，並對原文之下的高質量留言，也做了摘選。
Wow, this tweet went very viral! I wanted share a possibly slightly improved version of the tweet in an "idea file". The idea of the idea file is that in this era of LLM agents, there is less of a point/need of sharing the specific code/app, you just share the idea, then the other person's agent customizes & builds it for your specific needs. So here's the idea in a gist format: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f You can give this to your agent and it can build you your own LLM wiki and guide you on how to use it etc. It's intentionally kept a little bit abstract/vague because there are so many directions to take this in. And ofc, people can adjust the idea or contribute their own in the Discussion which is cool.
先給大家做一個總括。
這篇文章解決的是一個多數人都有但說不清楚的問題：你用大模型處理過的知識，為什麼留不下來？
現在大多數人用大模型處理文檔的方式叫 RAG（檢索增強生成），說白了就是你扔一堆文件進去，每次提問時模型臨時翻找、臨時拼湊答案。能用，但知識沒有積累。問一個需要綜合五份文檔才能回答的問題，模型每次都得從零開始找、從零開始拼。什麼都沒沉澱下來。
Karpathy 的思路反過來：別讓模型每次臨時翻書了，讓它替你維護一套持續更新的筆記。具體說，就是讓大模型把你餵給它的資料逐步編譯成一組互相鏈接的 Markdown 文件（也就是一個 wiki），像程序員維護代碼庫一樣。每加一份新資料，模型不會只是存起來，它會讀懂、提取要點、更新已有頁面、標註矛盾、補充交叉引用。知識被"編譯"一次就沉澱下來，越積越厚。
這個模式的分工一目了然：人類負責選材料、問問題、做判斷；大模型負責所有苦力活，總結、歸檔、交叉引用、保持一致性。人類之所以會放棄維護 wiki，是因為維護負擔的增速超過了價值增速。大模型消除了這個瓶頸，它不會煩、不會忘、一次操作能同時更新十幾個頁面。
下面是正文。
LLM Wiki
這是一份創意文檔，設計初衷是讓你複製粘貼到自己的 LLM Agent 中（比如 OpenAI Codex、Claude Code、OpenCode / Pi 等）。它的目標是傳達核心理念，具體細節由你的 Agent 與你協作完成。
大多數人使用 LLM（大語言模型）處理文檔的體驗是 RAG（Retrieval-Augmented Generation，檢索增強生成——即模型不靠自己的記憶回答問題，而是先從你上傳的文檔中檢索相關片段，再據此生成答案）：你上傳一批文件，LLM 在查詢時檢索相關片段，然後生成答案。這能用，但 LLM 每次都在從零重新發現知識，沒有任何積累。問一個需要綜合五份文檔的微妙問題，LLM 每次都得重新找到並拼湊相關碎片。什麼都沒有沉澱下來。NotebookLM（Google 的筆記本 AI 產品）、ChatGPT 的文件上傳以及大多數 RAG 系統都是這樣工作的。
這裡的思路不同。放棄查詢時才從原始文檔中檢索的做法，讓 LLM 逐步構建和維護一個持久化的 wiki，一組結構化、相互鏈接的 Markdown 文件（一種輕量級的純文本格式，可以用任何編輯器打開），作為你和原始資料之間的中間層。當你添加新資料時，LLM 不會只是把它索引起來留待日後檢索，它會閱讀、提取關鍵資訊、整合進現有 wiki，更新實體頁面、修訂主題摘要、標註新數據與舊結論的矛盾之處、用新證據去強化或推翻已有的綜合判斷。知識被編譯一次就沉澱下來、持續更新，不用每次查詢時從頭推導。
這就是關鍵區別：wiki 是一個持久的、不斷複利增長的產物。 交叉引用已經建好了，矛盾已經被標記了，綜合判斷已經反映了你讀過的所有內容。每添加一個新資料源、每提出一個新問題，wiki 都在變得更豐富。
你幾乎不用（或極少）親自寫 wiki——LLM 負責編寫和維護全部內容。你負責的是資料篩選、探索方向和提出正確的問題。LLM 做所有苦力活——總結、交叉引用、歸檔和 bookkeeping（指維護知識庫一致性所需的大量瑣碎更新工作，如同記賬），這些工作才是讓知識庫隨著時間推移真正有用的關鍵。在實際操作中，我一邊開著 LLM Agent（能執行操作的 AI 助手，不只是聊天，還能讀寫文件、運行命令），一邊開著 Obsidian（一款流行的本地 Markdown 筆記軟體，支持雙向鏈接和圖譜視圖）。LLM 根據我們的對話進行編輯，我實時瀏覽結果——跟蹤鏈接、查看圖譜視圖、閱讀更新後的頁面。Obsidian 是 IDE（集成開發環境），LLM 是程序員，wiki 是代碼庫。
這個模式適用的場景遠不止一種，舉幾個例子：
個人領域：追蹤你自己的目標、健康、心理、自我提升——歸檔日記、文章、播客筆記，隨著時間構建一幅關於你自己的結構化全景。
研究領域：在數周或數月內深入一個課題——閱讀論文、文章、報告，逐步構建一個帶有演進論點的綜合性 wiki。
閱讀一本書：逐章歸檔，為人物、主題、情節線索建立頁面，標註它們之間的關聯。讀完後你就擁有了一部豐富的伴讀 wiki。想想粉絲 wiki，比如 Tolkien Gateway（托爾金百科，一個由粉絲社區維護的《魔戒》系列百科全書）——數千個相互鏈接的頁面，涵蓋人物、地點、事件、語言，由志願者社區歷經數年構建。你可以在閱讀過程中由 LLM 做所有交叉引用和維護工作，個人也能構建這樣的東西。
商業/團隊：由 LLM 維護的內部 wiki，輸入來源是 Slack 討論、會議記錄、項目文檔、客戶通話。可以有人類參與審核更新。wiki 之所以能保持更新，是因為 LLM 承擔了團隊中沒人願意做的維護工作。
競爭分析、盡職調查、旅行規劃、課程筆記、愛好深挖——任何你在持續積累知識並希望它被組織起來而非散落各處的場景。
分為三層：
原始資料源（Raw Sources） ——你精心篩選的源文檔集合。文章、論文、圖片、數據文件。這些是只讀的——LLM 從中讀取但絕不修改，原始資料永遠保持原樣。這是你的權威來源（source of truth，當資訊衝突時以此為準）。
Wiki ——一個由 LLM 生成的 Markdown 文件目錄。摘要、實體頁面、概念頁面、對比分析、概覽、綜合判斷。這一層完全由 LLM 擁有。它創建頁面、在新資料到達時更新頁面、維護交叉引用、保持一切一致。你負責閱讀，LLM 負責寫。
Schema（模式定義） ——一份配置文檔（例如 Claude Code 的 CLAUDE.md 或 OpenAI Codex 的 AGENTS.md——這些是各家 AI 編程工具的項目配置文件，告訴 AI 該遵循什麼規則），定義 wiki 的結構是怎樣的、約定是什麼、在攝入資料、回答問題或維護 wiki 時應遵循什麼工作流。這是關鍵配置文件——它讓 LLM 成為一個有紀律的 wiki 維護者，而非一個通用聊天機器人。隨著你對自己領域的理解加深，你和 LLM 會一起疊代這份文檔，讓它越來越好用。
攝入（Ingest）。你把新資料放進原始資料集，然後讓 LLM 處理它。一個典型流程：LLM 閱讀資料，與你討論關鍵要點，在 wiki 中寫一個摘要頁面，更新索引，更新 wiki 中相關的實體和概念頁面，並在日誌中追加一條記錄。一個資料源可能觸及 10-15 個 wiki 頁面。我個人偏好逐條攝入資料並全程參與——我讀摘要、檢查更新、引導 LLM 強調什麼。但你也可以批量攝入大量資料，減少監督。怎麼做取決於你自己，找到適合你的工作流後，記在 Schema 里，下次開新會話時 LLM 就能沿用。
查詢（Query）。你針對 wiki 提問。LLM 搜索相關頁面、閱讀它們、綜合出帶引用的答案。答案可以根據問題採取不同形式——一個 Markdown 頁面、一個對比表格、一套幻燈片（Marp，一種把 Markdown 轉成演示文稿的工具）、一張圖表（matplotlib，Python 製圖庫）、一個畫布。重要洞察：好的答案可以作為新頁面歸檔回 wiki。 你請求的一次對比分析、一個分析結論、你發現的一個關聯，這些都值得留下來，不應該消失在聊天歷史中。這樣，你的探索就像攝入的資料源一樣，在知識庫中實現複利增長。
檢查（Lint——借用編程術語，原指代碼靜態檢查工具，這裡指對知識庫做系統性的健康檢查）。定期讓 LLM 對 wiki 做健康檢查。尋找：頁面之間的矛盾、已被更新資料取代的過時論斷、沒有任何入站鏈接的孤兒頁面（orphan pages，即沒有其他頁面鏈接到它的"孤島"頁面）、被提及但缺少獨立頁面的重要概念、缺失的交叉引用、可以通過網路搜索填補的數據缺口。LLM 擅長建議新的調查問題和新的資料來源。這讓 wiki 在增長過程中保持健康。
兩個特殊文件幫助 LLM（和你）在 wiki 增長時進行導航。它們的用途不同：
index.md 面向內容。它是 wiki 中所有內容的目錄——每個頁面列出鏈接、一行摘要，以及可選的元數據（如日期或資料源計數）。按類別組織（實體、概念、資料源等）。LLM 在每次攝入時更新它。回答查詢時，LLM 先讀索引找到相關頁面，再深入查看。這在中等規模（約 100 個資料源、數百個頁面）下效果出奇地好，避免了基於 embedding（嵌入向量，一種把文本轉成數字向量以便計算相似度的技術）的 RAG 基礎設施的需求。
log.md 面向時間線。它是一個只追加的記錄（append-only，只增不改不刪），記錄發生了什麼以及何時發生——攝入、查詢、檢查。一個實用技巧：如果每條記錄以統一的前綴開頭（例如 ## [2026-04-02] ingest | Article Title），日誌就可以用簡單的 Unix 命令行工具解析——grep "^## [" log.md | tail -5 就能給你最後 5 條記錄。日誌給你 wiki 演進的時間線，幫助 LLM 了解最近做了什麼。
到了某個階段，你可能想構建一些小工具來幫助 LLM 更高效地操作 wiki。最顯然的是一個 wiki 頁面搜尋引擎——在小規模下索引文件就夠用了，但隨著 wiki 增長，你需要正式的搜索能力。qmd 是個不錯的選擇：它是一個本地 Markdown 文件搜尋引擎，支持 BM25/向量混合搜索（BM25 是經典的關鍵詞匹配算法，向量搜索則通過語義相似度匹配，混合使用兼顧精確匹配和語義理解）和 LLM 重排序，全部在本地設備上運行。它同時有 CLI（命令行界面，LLM 可以通過 shell 調用）和 MCP 伺服器（Model Context Protocol，Anthropic 提出的讓 AI 連接外部工具的標準協議，LLM 可以把搜尋引擎作為原生工具調用）。你也可以自己造一個更簡單的——LLM 可以幫你隨需編寫一個樸素的搜索腳本。
Obsidian Web Clipper 是一個瀏覽器擴展，可以把網頁文章轉換為 Markdown。對快速把資料收入原始資料集非常有用。
把圖片下載到本地。 在 Obsidian 的設置 → 文件和鏈接中，把"附件文件夾路徑"設為一個固定目錄（如 raw/assets/）。然後在設置 → 快捷鍵中搜索"Download"，找到"下載當前文件的附件"並綁定一個快捷鍵（如 Ctrl+Shift+D）。剪藏一篇文章後按快捷鍵，所有圖片就會下載到本地磁盤。這不是必需的但實用——它讓 LLM 可以直接查看和引用圖片，而不用依賴可能失效的 URL。注意 LLM 目前不能一次性原生閱讀帶內嵌圖片的 Markdown——變通方法是讓 LLM 先讀文本，然後單獨查看部分或全部引用的圖片以獲取額外上下文。有點笨拙但夠用。
Obsidian 的圖譜視圖（Graph View，以節點和連線的方式可視化所有筆記之間的鏈接關係）是查看 wiki 全貌的最佳方式——什麼和什麼連接在一起，哪些頁面是樞紐，哪些是孤兒。
Marp 是一種基於 Markdown 的幻燈片格式。Obsidian 有它的插件。用於直接從 wiki 內容生成演示文稿。
Dataview 是一個 Obsidian 插件，可以對頁面的 frontmatter（YAML 格式的元數據頭，寫在 Markdown 文件最頂部，用於儲存標籤、日期等結構化資訊）運行查詢。如果你的 LLM 在 wiki 頁面中添加了 YAML frontmatter，Dataview 可以生成動態表格和列表。
Wiki 就是一個由 Markdown 文件組成的 git 倉庫（git 是程序員用的版本管理工具，能追蹤每次修改、隨時回滾、支持多人協作）。 你免費獲得版本歷史、分支和協作能力。
維護知識庫中令人厭煩的部分從來都不在閱讀或思考，全在記賬上。更新交叉引用、保持摘要時效性、標註新數據與舊結論的矛盾、在數十個頁面間保持一致性。人類之所以放棄 wiki，是因為維護負擔的增長速度超過了價值的增長速度。 LLM 不會厭倦、不會忘記更新某個交叉引用、而且能在一次操作中觸及 15 個文件。Wiki 能保持被維護的狀態，是因為維護成本接近於零。
人類的工作是篩選資料、指導分析方向、提出好問題、思考這一切意味著什麼。LLM 的工作是剩下的一切。
這個理念的精神源頭可以追溯到萬尼瓦爾·布希（Vannevar Bush）1945 年提出的 Memex——一個私人的、精心策劃的知識儲存，文檔之間有關聯路徑。相比後來萬維網實際走向的方向，布希的願景其實更接近 Karpathy 描述的這個模式：私密的、主動策劃的，文檔之間的連接與文檔本身一樣有價值。他沒解決的問題是：誰來做維護？LLM 解決了。
這份文檔刻意保持抽象。它描述的是理念，而非具體實現。確切的目錄結構、Schema 約定、頁面格式、工具鏈——所有這些都取決於你的領域、你的偏好和你選擇的 LLM。上面提到的一切都是可選的、模塊化的——取你所需，忽略其餘。例如：你的資料源可能全是純文本，那你完全不需要圖片處理。你的 wiki 可能足夠小，索引文件就是你需要的全部，不需要搜尋引擎。你可能不在乎幻燈片，只想要 Markdown 頁面。你可能想要一套完全不同的輸出格式。正確的用法是把這份文檔丟給你的 LLM Agent，然後一起協作，搭出一個適合你需求的版本。這份文檔唯一的任務就是把這個模式講清楚。剩下的你的 LLM 能搞定。
1. dkushnikov — "趨同驗證"
我獨立走到了相同的模式——看到它被如此清晰地描述，是一種趨同驗證，說明這個架構在根本上是對的。我們圍繞 Obsidian 和 Claude Code 構建了兩個開源工具：Obsidian Seed（通過對話生成個性化的 vault 結構和 reader-context.md 配置文件）和 Mnemon（知識提取管道，包含 7 種資料類型專用模板——因為論文需要方法論嚴謹性檢查，而播客需要發言者歸屬和信噪比分析）。關鍵補充：個性化是一等層級。同一篇文章，不同讀者 → 不同的摘要、不同的關鍵想法、不同的標籤。"種子"不只是資料源——它是"資料源 + 讀者畫像 + 模板"的組合。
2. peas — "LLM 是我的速記員，不是代筆"
我從二月開始構建了一個語音優先版本。大多數知識系統在"採集"環節就失敗了，而非"綜合"。我散步時對著 Telegram 錄語音備忘，Whisper（OpenAI 的語音轉文字模型）轉寫，LLM 分類器打標籤並路由，綜合器更新互聯的知識節點。70 多條語音備忘錄編譯成了 100 個知識節點和若干已發布的部落格文章。最重要的約束：LLM 必須是編輯，而非寫手——每句話都必須溯源到用戶實際說過的內容。空白之處標 [TODO: ...]，而非用幻覺填充。陀思妥耶夫斯基口述給妻子做速記；LLM 是我的速記員，不是我的代筆。此外，交叉鏈接用機械規則生成（標題匹配、slug 模式匹配、共現分析），不讓 LLM 生成——避免幻覺連接，讓知識圖譜可信賴。
3. bluewater8008 — "在生產環境跑了數周的實戰經驗"
我們已經在生產環境中跨多個知識領域運行這個模式數周了。幾條經驗：① 先分類再提取——50 頁報告和 2 頁信函需要不同的處理方式，不分類就只會得到千篇一律的淺層摘要；② 給索引分配 token 預算——我們用四級漸進披露（L0 約 200 token 的項目上下文，每次會話都加載；L1 約 1-2K 的索引；L2 約 2-5K 的搜索結果；L3 才是 5-20K 的完整文章），不到需要時不讀全文；③ 每種實體類型一個模板，人物頁和事件頁需要不同的必填欄位，7 種類型是甜蜜點（sweet spot，即效果與複雜度的最佳平衡點）；④ 每個任務產出兩個輸出——用戶要的東西是輸出一，對 wiki 相關文章的更新是輸出二。不寫進 Schema，LLM 就會讓知識蒸發在聊天歷史里；⑤ 人類擁有最終驗證權——LLM 綜合資訊時可能不標來源，你不主動檢查就不會發現。把來源引用寫進 Schema 規則，並預留時間抽檢 wiki 本身。
4. xoai — "做成了一個 Go 單體二進制"
做了 sage-wiki——一個跨平台的 Go 單體二進制程序。sage-wiki init --vault 在已有的 Obsidian vault 上初始化，或在空文件夾里運行。sage-wiki compile --watch 增量編譯資料源為帶概念、反向鏈接和交叉引用的 wiki 文章。sage-wiki search 和 sage-wiki query 做關鍵詞搜索和帶引用的問答。sage-wiki serve 把 wiki 暴露為 MCP 伺服器，任何 LLM Agent 都能操作它。Lint 功能也做了——捕捉不一致、建議缺失連接、填補空白。查詢輸出歸檔回 wiki 那一刻，知識庫就真正開始複利增長了。每個你問過的問題都在讓它更擅長回答下一個問題。
5. umbex — "用 cron 心跳實現自動化攝入"
我做了類似的東西，但用結構化文件系統和 cron 心跳（cron 是 Linux 的定時任務調度器，"心跳"指按固定頻率自動執行的任務）實現。系統能自動監控 inbox 文件夾、把內容路由到對應領域、用持久事實更新 foundations/（長期不變的知識底座）、用臨時資訊更新 data/current/（時效性數據），然後更新每個領域的 state.md（當前狀態摘要）。每天早上收集所有 state.md 生成 brief.md 並構建儀錶盤。攝入、路由、合併、摘要四層分離。
6. tkgally — "讓 Claude Code 每晚自動維護知識庫"
過去幾個月我一直在用 Claude Code 構建一本日英詞典。項目的複雜性讓我對整體設計和未來方向的把握感到不安。所以我在倉庫中創建了一個 planning/ 目錄，把這份 LLM wiki 文檔放進去，讓 Claude 開始構建一個知識庫，供未來數周數月項目持續增長時參考。我設置了定時任務讓 Claude Code 每晚自動維護這個知識庫。 開局看起來不錯，期待看到效果。
7. mpazik — "最先崩潰的是查詢和結構"
實踐中最先崩潰的是兩件事：查詢（超過幾百頁後你沒法靠讀文件來提問，索引文件前期能用但不能規模化）和結構（frontmatter、命名約定、文件夾規則不知不覺就長出來了，到了某個點你發現自己在跟工具打架，沒法專心做正事）。這讓我反過來做：放棄讓文件慢慢變成資料庫的路線，直接從結構化數據出發，渲染為 Markdown。 數據進入事務日誌，在 SQLite 中索引，每個實體顯示為可編輯的 Markdown 文件，編輯內容再回寫。索引不再是 Agent 手動維護的文件，它就是一個資料庫查詢，永遠是最新的。我圍繞這個思路在做 Binder。
8. localwolfpackai — "給知識庫加一個偏見發散檢查"
建議在攝入/查詢操作中加入偏見發散檢查（Divergence Check）。每次 LLM 更新概念頁時，強制生成一個隱藏的 ## 反論與數據缺口 部分。如果你連續攝入 5 篇讚揚某個 UI 框架的文章，LLM 應該被要求搜索（或模擬）對該框架最有力的批評。相當於給你的認知盲區裝了一面鏡子。最近越來越注意到自己的偏見了……也許只是我吧。
9. Astro-Han — "一行安裝，即插即用"
把它做成了一個即插即用的 skill（技能文件，讓 AI Agent 遵循特定工作流的配置），適用於 Claude Code / Cursor / Codex。一行安裝：npx add-skill Astro-Han/karpathy-llm-wiki，然後告訴 Agent "ingest this URL"，它就會處理從原始資料到 wiki 編譯、交叉引用和索引更新的全流程。讓我真正領悟的一點是：一旦建立起三層流（raw → wiki → index），每個新資料源都在真正豐富現有文章，而不只是堆積。Wiki 在複利增長。
10. flyersworder — "從單篇摘要到跨論文高階模式提取"
我們從三月中旬開始做 LENS——聚焦於從論文中提煉跨文獻的高階模式，而非摘要單篇內容。核心思路：LLM 從研究論文中提取結構化的權衡關係（tradeoffs）、架構變體和智能體模式（agentic patterns），然後聚合為跨論文的知識結構——一個矛盾矩陣（靈感來自 TRIZ 創新方法論，記錄哪些技術解決哪些權衡）、一個架構目錄（按組件槽位組織的變體）、一個智能體模式目錄（湧現出的類別）。一條洞察可能有 10 篇以上論文作為支撐。新論文通過規範詞彙表自動歸入已有結構，不需要人工整理。讀了 Karpathy 的文章後，我們直接加了兩個功能：Lint（6 項健康檢查加自動修復）和事件日誌。
