作者 | 冬梅

在“每一枚 Token 都要精打細算”的共識下，AI 圈一度流行一種略帶調侃的說法：真正的高手，不是把 Token 用在寫代碼上，而是用在更高杠桿的事情上。

最近，這一理念被再次推向臺前——主角是患上了“AI 精神病”的 Andrej Karpathy。

Karpathy 新項目爆火，技術細節(jié)完整披露

前陣子，Karpathy 在 X 上分享了一套自己正在實踐的工作流，稱之為“LLM Wiki”：他不再把大模型主要用于寫代碼，而是將絕大多數(shù) Token 消耗，轉向構建一個圍繞個人研究興趣的“可演化知識庫”（以 Markdown 和圖片形式存儲）。

這條帖子在 x 上瀏覽量超 1700 萬，圍觀者眾多。

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

Karpathy 詳細介紹了 LLM Wiki 項目的工程實現(xiàn)、數(shù)據(jù)采集、工具選擇等技術細節(jié)。

從工程實現(xiàn)上看，Karpathy 的方法并不依賴復雜的基礎設施，甚至可以說極其“樸素”。一切始于一個名為 raw/ 的原始目錄。在這個目錄中，他將與研究主題相關的所有素材一股腦地收集進來——包括論文、技術博客、代碼倉庫、數(shù)據(jù)集，乃至圖片等多模態(tài)內容。這一步并沒有任何結構設計，核心目標只有一個：最大化原始信息的完整性。

接著，Karpathy 調用 LLM 對這些素材進行增量“編譯”，生成一個 Wiki。這個 Wiki 本質上是一個具備清晰目錄結構的 Markdown 文件集合，類似一個由 AI 自動撰寫和維護的知識百科系統(tǒng)。

Karpathy 把Obsidian作為這個系統(tǒng)的“前端 IDE”，在這里他可以查看原始數(shù)據(jù)、編譯好的 Wiki 以及衍生的可視化內容。Karpathy 介紹，這么做的核心點在于：Wiki 中的所有數(shù)據(jù)都由 LLM 編寫和維護，自己極少直接動手修改。

他還嘗試了一些 Obsidian 插件來以不同方式展示數(shù)據(jù)，比如用 Marp 插件生成演示幻燈片。

當知識庫規(guī)模逐漸擴大，這一系統(tǒng)開始展現(xiàn)出更強的能力。Karpathy 提到，在一個包含約 100 篇文章、總計 40 萬字的研究項目中，他已經(jīng)可以直接向 LLM Agent 提出復雜的系統(tǒng)性問題。與傳統(tǒng)認知不同，他并沒有引入復雜的 RAG 架構，而是依賴 LLM 對 Wiki 的“內生理解”能力——模型通過自動維護的索引與摘要，可以高效定位相關信息并進行綜合分析。

這一點尤為關鍵。過去一年，RAG 幾乎成為企業(yè)級 AI 應用的“標配”，但 Karpathy 的實踐表明，在中等規(guī)模的數(shù)據(jù)集上，LLM 本身已經(jīng)具備足夠強的“自檢索”與“自組織”能力。這意味著，一部分復雜的系統(tǒng)設計，可能正在被模型能力的提升所“吞噬”。

在輸出層面，Karpathy 同樣不滿足于傳統(tǒng)的文本回答。他將 LLM 生成能力進一步擴展到多種格式：包括 Markdown 文檔、基于 Marp 的演示幻燈片，甚至是通過 Matplotlib 繪制的數(shù)據(jù)圖表。這些結果統(tǒng)一在 Obsidian 中進行可視化呈現(xiàn)，使知識不再停留在“答案”，而是轉化為可以復用、傳播和沉淀的資產。

更重要的是，這些輸出并不會被丟棄。相反，它們會被重新歸檔進 Wiki，成為知識庫的一部分。換言之，每一次提問與探索，都會對系統(tǒng)進行“增量訓練”——盡管不是傳統(tǒng)意義上的模型訓練，但在知識層面，系統(tǒng)的能力確實在持續(xù)累積。

為了維持這一系統(tǒng)的長期健康運行，Karpathy 還設計了一套“自動化運維”機制。他會定期調用 LLM 對整個 Wiki 進行“體檢”：檢測數(shù)據(jù)不一致、補全缺失信息、通過聯(lián)網(wǎng)搜索引入新資料，甚至主動挖掘潛在的關聯(lián)關系并生成新的專題文章。

此外，他還通過“Vibe Coding”的方式快速開發(fā)了一些輔助工具。例如，一個用于檢索 Wiki 的簡易搜索引擎，可以通過網(wǎng)頁界面或命令行調用。在更復雜的場景下，這些工具甚至可以作為 LLM 的外部能力接口，由模型自主調用完成任務。

隨著知識庫規(guī)模的進一步擴大，Karpathy 也在思考下一階段的演化方向：是否可以通過合成數(shù)據(jù)生成與微調，將這些結構化知識“壓縮”進模型權重之中。換句話說，從依賴上下文窗口的外部知識系統(tǒng)，邁向模型內部的長期記憶。

簡單總結一下，該架構設計極簡，僅包含三個組件：

1、一個 Markdown 文件文件夾。 這是你的知識庫。它可以包含任何內容：研究筆記、會議紀要、項目文檔、讀書筆記、個人參考資料、帶有解釋的代碼片段。

2、每個文件內部結構一致。優(yōu)秀的 LLM Wiki 文檔采用一致的內部格式——標題、簡短摘要、標簽主題以及正文內容。模型利用這種結構更快地找到相關信息。

3、使用 Claude Code 作為查詢界面。打開終端，導航到你的 wiki 文件夾，啟動 Claude Code，然后向它提出問題。Claude 會讀取所需的文件，綜合生成答案，甚至可以根據(jù)你的要求更新或添加注釋。

就是這樣，無需數(shù)據(jù)庫，無需向量嵌入也無需服務器。只需文件和一個功能強大的模型。

LLM Wiki “殺死了”RAG？

Karpathy 的這一實踐之所以能夠迅速引發(fā)關注，是因為它并非只是一個效率工具的升級，而更像是對“個人知識管理”（PKM）體系的一次重構。從 Notion、Roam Research 到 Obsidian，過去十年里，人們始終在尋找更好的知識組織方式，而在 LLM 的加持下，這一問題的解法，正在從“如何記錄”轉向“如何自動生成與演化”。

因此有 X 用戶認為，LLM Wiki “殺死了”RAG。

過去三年，為 LLM 提供專有數(shù)據(jù)訪問的主要范式是檢索增強生成（RAG）。在標準的 RAG 設置中，文檔被分割成任意的“塊”，轉換為數(shù)學向量（嵌入），并存儲在專門的數(shù)據(jù)庫中。

當用戶提出問題時，系統(tǒng)會執(zhí)行“相似性搜索”來查找最相關的數(shù)據(jù)塊，并將它們輸入到 LLM 中。Karpathy 的方法，他稱之為 LLM 知識庫，摒棄了中等規(guī)模數(shù)據(jù)集的向量數(shù)據(jù)庫的復雜性。

相反，它依賴于 LLM 對結構化文本進行推理能力的不斷提高。

系統(tǒng)架構（由 X 用戶 @himanshu 在對 Karpathy 帖子的廣泛回應中可視化呈現(xiàn)）分三個不同的階段運行：

1. 數(shù)據(jù)導入：原始資料——研究論文、GitHub 代碼庫、數(shù)據(jù)集和網(wǎng)絡文章——被導入到一個 raw/ 目錄中。Karpathy 使用 Obsidian Web Clipper 將網(wǎng)頁內容轉換為 Markdown.md 文件，確保即使是圖像也存儲在本地，以便 LLM 可以通過視覺功能引用它們。

2. 編譯步驟：這是核心創(chuàng)新點。LLM 不僅僅是對文件進行索引，而是對文件進行“編譯”。它讀取原始數(shù)據(jù)并生成結構化的維基百科頁面。這包括生成摘要、識別關鍵概念、撰寫百科全書式條目，以及——至關重要的是——在相關概念之間創(chuàng)建反向鏈接。

3. 主動維護（代碼檢查）：該系統(tǒng)并非一成不變。Karpathy 描述了運行“健康檢查”或“代碼檢查”的過程，LLM 會掃描 wiki 以查找不一致之處、缺失數(shù)據(jù)或新連接。正如社區(qū)成員 Charly Wargnier 所觀察到的，“它就像一個活的 AI 知識庫，能夠自我修復?！?/p>

Karpathy 將 Markdown 文件視為“真理之源”，從而避免了向量嵌入的“黑箱”問題。AI 做出的每一項聲明都可以追溯到特定的.md 文件，而這些文件可以由人閱讀、編輯或刪除。

在 Youtube 上，也有不少關于 “LLM Wiki killed RAG”相關話題的討論。

一位 ID 名為 DIY Smart Code 的博主闡述了為什么他認為有了 LLM Wiki 后，就不再需要 RAG 了。

該博主表示：“人類并不缺少信息，缺的是對信息的持續(xù)組織與有效利用。”

研究顯示，人類在獲取新知識后的短時間內就會遺忘其中的大部分內容，而現(xiàn)代知識工作者每天平均需要花費近兩個小時，去查找那些“自己曾經(jīng)讀過”的信息。這不僅意味著巨大的時間浪費，也揭示了一個現(xiàn)實困境——無論是筆記工具、收藏夾，還是所謂的“第二大腦”，在長期使用后，往往都會演變?yōu)橐粋€信息堆積卻難以調用的“知識墓地”。 過去幾年，AI 行業(yè)嘗試通過 RAG 等技術路徑解決這一問題，即通過向量數(shù)據(jù)庫對海量文檔進行索引，在需要時檢索相關片段并生成答案。然而在實際應用中，這類方案往往面臨落地難題：檢索可以做到，但理解不足；信息可以找到，但難以形成結構化認知。某種程度上，這類系統(tǒng)只是讓用戶“更快地搜索混亂”，卻沒有真正解決知識組織的問題。 Karpathy 的思路則截然不同。他并沒有繼續(xù)優(yōu)化“檢索”，而是從源頭出發(fā)，提出“寫出更好的文檔”。在他的體系中，原始數(shù)據(jù)被視為“源代碼”，大語言模型則充當“編譯器”，而最終生成的 Wiki 知識庫，則是可以直接使用的“可執(zhí)行產物”。

在這種情況下，基本就不會再需要 RAG 了。

技術社區(qū)和企業(yè)反響熱烈

雖然 Karpathy 自己將 LLM Wiki 描述為“一堆蹩腳的腳本”，但它在技術社區(qū)和企業(yè)級市場還是引發(fā)了不少的關注。

企業(yè)家 Vamshi Reddy (@tammireddy) 在回應 Karpathy 帖子時表示：“每個企業(yè)都有一個原始目錄。從來沒有人把它整理過。這就是產品?！?/p>

Karpathy 對此表示贊同，并認為這種方法代表了一種“令人難以置信的新產品”類別。

目前大多數(shù)公司都“淹沒”在非結構化數(shù)據(jù)中——Slack 日志、內部維基和 PDF 報告，沒有人有時間去進行綜合分析。

“Karpathy 式”企業(yè)層不僅會搜索這些文檔，還會主動編寫實時更新的“公司圣經(jīng)”。

AI 教育家兼簡報作者 Ole Lehmann 在 x 上發(fā)帖稱：“我認為，誰能把這個功能打包成普通用戶都能用的東西，就掌握了一項巨大的技術。一個應用就能與你已經(jīng)使用的工具、書簽、稍后閱讀應用、播客應用、保存的討論串同步?！?/p>

AI 企業(yè) Agent 構建和編排初創(chuàng)公司 Edra 的聯(lián)合創(chuàng)始人兼首席執(zhí)行官 Eugen Alpeza 在一篇 X 帖子中指出： “從個人研究維基到企業(yè)運營的飛躍才是真正的挑戰(zhàn)所在。成千上萬的員工，數(shù)百萬條記錄，以及團隊間相互矛盾的經(jīng)驗知識。的確，企業(yè)級市場需要一款新產品，而我們正在打造它?！?/p>

AI 代理創(chuàng)建平臺 Secondmate 的創(chuàng)始人 @jumperz 最近發(fā)布的一份架構分解報告，通過“群體知識庫”展示了這一演變過程，該知識庫將 wiki 工作流程擴展到通過 OpenClaw 管理的 10 個代理系統(tǒng)。

另一位 x 用戶還將 Karpathy 的腳本方案成功“產品化”了。她推出了一款名為：Claudeopedia（Claude 百科）的產品，并說明了她構建該產品的幾大步驟，她寫道：

1、我采納了 @karpathy 的 “l(fā)lm-wiki” 構想（這占了本項目 90% 的功勞，所以大頭要歸功于 Karpathy）； 2、結合了過去 30 天的技能（感謝 @mvanhorn 的靈感）； 3、新增了一個 /wiki 技能，支持截圖和下載參數(shù)，能更飛速地傳輸原始素材； 4、構建了一個交互式可視化界面來搜索我的知識庫（甚至帶日期范圍，可以對比知識隨時間演進的變化?。?； 5、設置了一個“質疑自我假設”的定時任務（cron job），自動將我最近的隨筆和客戶郵件與 Wiki 內容進行比對復核。 目前這一切都在 Obsidian 中運行。包括測試在內，所有這些都是在這個周末搞定的。我會繼續(xù)添加更多功能。我重點構建的是：企業(yè)級 AI。我已經(jīng)非常期待了。

整體來看，Karpathy 提出的這一方法的意義不僅在于提升效率，更在于重構知識工作的底層邏輯。當大模型能夠持續(xù)維護并擴展一個結構化知識體系時，傳統(tǒng)意義上的“筆記”正在演變?yōu)橐环N動態(tài)系統(tǒng)。對于個體而言，這意味著可以將認知能力部分外包給機器；而對于行業(yè)而言，這也預示著一個潛在的新產品方向——將“知識編譯”本身，作為核心能力進行產品化。

在信息不斷膨脹的時代，這種從“存儲信息”到“演化知識”的轉變，或許正是下一階段 AI 應用的重要突破口。

https://www.youtube.com/watch?v=RQsLXmenr48

https://x.com/NickSpisak_/status/2040448463540830705

https://x.com/alliekmiller/status/2040884878229565816

https://www.mindstudio.ai/blog/andrej-karpathy-llm-wiki-knowledge-base-claude-code

https://obsidian.md/clipper

https://venturebeat.com/data/karpathy-shares-llm-knowledge-base-architecture-that-bypasses-rag-with-an

（https://kcnrpnk9jqxn.feishu.cn/wiki/LDSUwt1Gfi5uOmkhRXScfIExnBb）

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發(fā)體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態(tài)智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業(yè)級研發(fā)體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰(zhàn)經(jīng)驗。AICon 2026，期待與你同行。

今日薦文

你也「在看」嗎？