機器之心編輯部

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為何要構建「LLM Wiki」

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

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

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

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

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

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

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

「LLM Wiki」是如何構建的？

這個系統(tǒng)可以分為三個層次：

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

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

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

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

操作（Operations）

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

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

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

「LLM Wiki」應用場景

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

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

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

讀書場景：隨著閱讀進度整理每一章內(nèi)容，建立人物、主題、情節(jié)線索之間的關聯(lián)頁面。讀完之后，你會得到一個豐富的配套 wiki。可以類比像 Tolkien Gateway 這樣的維基，由社區(qū)多年構建的、包含人物、地點、事件、語言等內(nèi)容的龐大知識網(wǎng)絡?，F(xiàn)在，你可以在閱讀過程中個人構建類似系統(tǒng)，由 LLM 完成所有的關聯(lián)和維護。

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

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

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

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