Karpathy知識庫「LLM Wiki」火爆了，全網圍觀討論

機器之心編輯部

還記得前幾天，AI 領域知名學者 Andrej Karpathy 做客一檔節目時，半開玩笑地提到：token 用不完會讓人焦慮，就像患上了某種「AI 精神病」。

這句話當時聽起來有點夸張，但當你仔細看他最近在做的一系列東西，會發現他確實在用 AI 不斷試各種路徑。

就在近日，Karpathy 構建的 LLM 知識庫「LLM Wiki」爆火，在社區迅速傳播，引發大量討論。

就連 Karpathy 自己都忍不住自夸一句：哇，我這條推文真的火爆了！

這條爆火的推文介紹了「LLM Wiki」的構建思路。Karpathy 表示，他把最近的想法稍微整理、優化了一下，然后用一個「idea file」的形式分享出來。在 LLM agent 時代，分享具體代碼或應用的意義正在變弱，現在只需要分享想法，然后把它交給 Claude、Grok 等 Agent，它就可以根據你的需求，自動搭建一個屬于你自己的個人知識庫。

Karpathy 把這個想法整理成 gist 形式進行分發：你可以把它交給你的 agent，它會幫你構建一個屬于你自己的 LLM wiki，并指導你如何使用等等。

地址：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

這個思路可以說是有點超前，在 Agent 時代，這意味著我們已經不需要再分享具體代碼或應用了！只需要把「想法」交給對方的 Agent，讓它根據你的需求自動完成定制和實現！

有觀點認為，這不只是一個 AI 工具，而更像是一種元框架（meta-framework）。它并不依賴某個具體模型或技術棧，而是在嘗試定義一種人類與 AI 協作管理知識的方式。隨著模型不斷迭代、框架持續演進，讓 LLM 幫助編譯并維護一個持續生長的 Wiki 這一模式，反而具備更長期的穩定性和適用性。

還有觀點將這套「LLM Wiki」的工作方式梳理成一個更清晰的閉環，方便大家理解其核心邏輯：

• 將原始資料（論文 / 文章 / 代碼 / 圖片等）整理到 raw/ 目錄中
• 由 LLM 將其編譯為一個結構化的 wiki（包含 .md 文件、反向鏈接以及概念分類）
• 使用 Obsidian 作為前端進行瀏覽
• 當 wiki 達到一定規模（他的案例是：100 篇文章、40 萬字）后，可以直接圍繞整個 wiki 提出復雜問題
• 將每一次問答的輸出重新歸檔回 wiki—— 這一點我認為是核心；知識庫會隨著使用不斷變強
• 由 LLM 定期進行健康檢查：發現矛盾數據、補全缺失信息、挖掘新的研究方向

在這一過程中，一個頗具啟發性的判斷是：在中等規模下，這套體系并不依賴傳統意義上的 RAG。只要 LLM 能夠維護好索引和摘要，就已經可以支撐起有效的檢索與推理。

進一步看，這一思路的延伸方向也逐漸清晰，通過合成數據與微調，將知識逐步內化進模型權重，而不再僅僅依賴上下文窗口進行調用。

從這個角度來看，這已經不只是一個使用技巧，而是在逼近一種自我增強的知識系統形態，也可以被視為一個具備產品潛力的雛形。

為何要構建「LLM Wiki」

Karpathy 表示，大多數人使用 LLM 處理文檔的方式，基本都類似于 RAG：你上傳一組文件，模型在查詢時檢索相關片段，然后生成答案。

這種方式是有效的，但問題在于每一次提問，模型都在從零重新發現知識。沒有積累。如果你問一個需要綜合五篇文檔的復雜問題，模型每次都要重新去找相關片段，再拼接起來。沒有任何東西被沉淀下來。像 NotebookLM、ChatGPT 文件上傳，以及大多數 RAG 系統，基本都是這種模式。

「LLM Wiki」提出的是一種不同的思路，不是在查詢時直接從原始文檔中檢索，而是讓 LLM 逐步構建并維護一個持續存在的 wiki，一個結構化、相互鏈接的 Markdown 文件集合，作為你和原始資料之間的中間層。

當你添加新的資料時，模型不只是簡單地索引以備后用，而是會真正去閱讀它，提取關鍵信息，并將其整合進現有的 wiki：更新實體頁面、修訂主題總結、標記新信息與舊結論之間的沖突，對整體認知進行強化或修正。知識被編譯一次，并持續更新，而不是在每次查詢時重新推導。

用 Karpathy 的話來說，這個 wiki 是一個持續存在、不斷累積的產物。交叉引用已經提前建立，矛盾已經被標注，綜合結論已經反映了你讀過的所有內容。隨著你不斷加入新資料、提出新問題，這個 wiki 會持續變得更豐富。

你幾乎不需要（或者很少需要）親自去寫這個 wiki，所有內容都由 LLM 來生成和維護。你負責的是提供資料、進行探索、提出問題；而模型負責所有苦活：總結、建立關聯、歸檔整理、維護結構，讓知識庫隨著時間真正變得有用。在實際使用中，通常是一邊打開 LLM agent，一邊打開 Obsidian：模型根據對話不斷修改內容，而你可以實時瀏覽結果，點開鏈接、查看知識圖譜、閱讀更新后的頁面。

這么說吧，Obsidian 是 IDE，LLM 是程序員，wiki 是代碼庫。

「LLM Wiki」是如何構建的？

這個系統可以分為三個層次：

原始數據：這是你整理好的原始資料集合，包括文章、論文、圖片、數據文件等。這一層是不可變的：LLM 只讀取它們，但不會對其進行任何修改，這是整個系統的事實來源。

Wiki 層（The wiki）：一個由 LLM 生成的 Markdown 文件目錄，包含摘要、實體頁面、概念頁面、對比分析、整體概覽以及綜合性總結等內容。這一層完全由 LLM 負責：它會創建頁面，在新增資料時更新內容，維護交叉引用，并保證整體一致性。你負責閱讀它；LLM 負責編寫和維護它。

Schema 層（The schema）：一份指導性文檔（例如給 Claude Code 用的 CLAUDE.md，或給 Codex 用的 AGENTS.md），用于告訴 LLM：這個 wiki 的結構是什么、遵循哪些規范，以及在處理數據（ingest）、回答問題、維護內容時應采用什么樣的工作流程。

這是整個系統的關鍵配置文件，正是它讓 LLM 從一個通用聊天模型，變成一個有紀律的 wiki 維護者。隨著你在具體領域中不斷實踐，這一層也會與你和 LLM 一起持續演化、不斷優化。

操作（Operations）

數據攝取（Ingest）：你將新的資料加入到原始數據集合中，并讓 LLM 對其進行處理。一個典型流程是：LLM 讀取資料，與你討論關鍵要點，在 wiki 中寫出一篇摘要頁面，更新索引，同時更新整個 wiki 中相關的實體頁和概念頁，并在日志中追加一條記錄。一個來源往往會影響 10–15 個 wiki 頁面。Karpathy 個人更傾向于一次處理一個來源，并保持參與，他會閱讀摘要、檢查更新，并引導 LLM 強調重點。但你也可以選擇批量導入多個來源，減少監督。最終，你可以形成一套適合自己風格的工作流，并將其記錄在 schema 中，供后續使用。

查詢（Query）：你可以圍繞 wiki 提出問題。LLM 會搜索相關頁面，閱讀內容，并綜合生成帶引用的回答。回答形式可以根據問題而變化，可以是一個 Markdown 頁面、一個對比表、一份幻燈片（Marp）、一張圖表（matplotlib），甚至是一個畫布（canvas）。關鍵的一點是：好的回答可以被重新歸檔進 wiki，成為新的頁面。無論是一次對比分析、一段推理，還是你發現的一條關聯，這些內容都具有價值，不應該消失在聊天記錄里。通過這種方式，你的探索會像導入的資料一樣，在知識庫中持續積累。

質量檢查（Lint）：可以定期讓 LLM 對 wiki 進行健康檢查。重點包括：頁面之間是否存在矛盾；是否有被新資料取代的過時結論；是否存在沒有入鏈的孤立頁面；是否有被提及但尚未建立頁面的重要概念；是否缺少交叉引用；是否存在可以通過網頁搜索補充的數據空缺。LLM 也很擅長提出新的研究問題和建議新的信息來源。這一過程可以幫助 wiki 在不斷擴展的同時，保持結構清晰和內容一致。

「LLM Wiki」應用場景

這種方式可以應用在很多不同場景中，例如：

個人層面：記錄你的目標、健康、心理狀態、自我成長過程，整理日記、文章、播客筆記，逐步構建一個關于你自己的結構化認知。

研究場景：圍繞某個主題深入數周甚至數月，閱讀論文、文章、報告，逐步構建一個不斷演化的完整知識體系和核心觀點。

讀書場景：隨著閱讀進度整理每一章內容，建立人物、主題、情節線索之間的關聯頁面。讀完之后，你會得到一個豐富的配套 wiki?？梢灶惐认?Tolkien Gateway 這樣的維基，由社區多年構建的、包含人物、地點、事件、語言等內容的龐大知識網絡。現在，你可以在閱讀過程中個人構建類似系統，由 LLM 完成所有的關聯和維護。

企業 / 團隊：一個由 LLM 維護的內部 wiki，持續接入 Slack 對話、會議記錄、項目文檔、客戶溝通等信息，必要時由人工參與審核更新。由于維護工作由模型承擔，這個 wiki 能夠保持實時更新，而不再依賴團隊成員額外投入精力。

競品分析、盡職調查、旅行規劃、課程筆記、興趣深度研究，任何需要長期積累知識、并希望其被系統化組織而不是零散分布的場景，都可以采用這種模式。

最后，Karpathy 還強調了，關于「LLM Wiki」，他只是提供了一種思路，而不是一個具體實現。具體的目錄結構、schema 規范、頁面格式以及工具鏈，都會取決于用戶使用場景、個人偏好以及所選擇的 LLM。

上面提到的所有內容都是可選且模塊化的，有用的就用，不合適的可以忽略。