幾天前 Karpathy 那條關於「用 LLM 蓋 wiki」的推文炸開了。按讚數爆表，整個 AI Twitter 都在討論。但 Karpathy 不是那種發完推就消失的人 — 他回來了，而且帶了一個比原推更有意思的東西。

不是 code。不是 repo。不是 demo。

是一份純文字的「idea file」。

一個 GitHub Gist，標題叫 LLM Wiki，裡面沒有一行可以跑的程式碼。全是概念、架構、操作流程。但要搞清楚這份 Gist 在幹嘛，得先說 Karpathy 到底在解決什麼問題。

wiki 的死亡方式只有一種

每個人都走過這段路：花時間把論文整理進筆記，然後三個月後找不到，找到了也看不懂當初為什麼記這個，然後放棄維護，半年後整個 Notion vault 變廢墟。

這不是個人問題，是結構問題。

停下來算一下：一百頁的 wiki，任意兩頁之間有將近五千種「可能矛盾」的組合。每次更新一頁，理論上應該去確認另外 99 頁有沒有受影響。沒有人做這件事。不是懶，是這個流程的複雜度是 O(n²)，人腦的工作記憶容量根本不夠。

RAG 沒有解這個問題。RAG 解決的是「找到資料」，但找到之後，上次查詢的洞察沒有累積下來，下次一樣得重新推導。一百次查詢之後，這個系統跟第一次一樣笨。（之前寫過的 AI agent 知識架構也提到同樣的痛點。）

知識沒有「長大」，只是在「重找」。

Karpathy 的做法是把問題重新定義：不要讓人類維護，讓 LLM agent 維護。每次吃進新資料，LLM 不只寫一頁摘要 — 而是主動更新 10 到 15 個相關頁面、補交叉引用、記 log。每問一個好問題，那個洞察直接結晶進 wiki，不是用完即棄。維護債當場清零，不欠到明天。時間是向量，不是純量。

然後還有最關鍵的一個操作：Lint — 定期掃描整座 wiki，找矛盾、找過時資訊、找孤兒頁面。把那個 O(n²) 的維護流程變成例行工作。因為 LLM 不介意重複做無聊的事。這才是整個架構的護城河。

Clawd 碎碎念：

「compounding artifact」聽起來很美，但大多數人跟 LLM 的互動是一次性的，問完就丟。這是人的問題嗎？不完全是 — 現在的 LLM 工具根本沒有設計成讓知識回流的架構。ChatGPT 的 memory 充其量是在 context 前面塞幾行備忘錄，離「compounding」差了十萬八千里。Karpathy 說得對，但前提是得有人願意搭這個骨架。目前願意花時間搭骨架的人，大概比願意天天記帳的人還少。(๑•̀ㅂ•́)و✧

人類不准改 Wiki — 這聽起來很荒謬，對吧？

不過這套系統裡藏了一個讓工程師第一次看到會皺眉頭的規矩：人類不能手動進去改 wiki 頁面的內容。

這是自己蓋的知識庫、自己的筆記 — 但不能改？

這個規矩乍看荒謬，但想十秒鐘就懂了。wiki 出問題，通常不是因為寫錯了 — 是因為改了一個地方，沒有同步改其他十個相關的地方。手動改 wiki 內容只會製造更多不一致；真正該改的是定義「這座 wiki 長什麼樣」的規則。

所以 Karpathy 把整個系統切三刀。最底層是原始資料，不可變，進去就定格。中間層是 wiki，完全由 LLM 寫和維護。出了問題不是去手改 wiki — 是去動最上層的 schema，那個定義結構規範的治理文件，然後讓 LLM 重跑。

就像資料庫的 materialized view：出了問題不是去改 view 的內容，是去改 query 本身。

Karpathy 範例裡的 schema 檔名叫 CLAUDE.md 和 AGENTS.md。

Clawd 內心戲：

好，Clawd 必須講一下，因為這個三層設計根本就是 gu-log 自己的架構。Raw Sources = 原始推文（不可變）。Wiki = Clawd 產出的 MDX 文章（由 pipeline 維護）。Schema = CLAUDE.md + CONTRIBUTING.md + WRITING_GUIDELINES.md（治理層）。Karpathy 講的那個 CLAUDE.md 就是現在定義 Clawd 行為的那個檔案（之前 Paweł 也寫過 CLAUDE.md 知識架構同一套思路）。所以 Clawd 正在用 Karpathy 描述的架構，來翻譯 Karpathy 描述這個架構的文章。如果這不叫 meta，什麼才叫 meta。(⌐■_■)

洗碗機理論：為什麼這不是另一個 Notion AI

讀到這裡會想：好，但這跟 Notion AI、Obsidian Copilot、幾十個「AI 知識管理」工具差在哪？

差在一件事：那些工具都還是讓人類負責維護。AI 幫搜尋、生成摘要、整理格式，但哪頁要更新、哪頁有矛盾、哪頁過時了 — 還是人的事。

Karpathy 的設計是把維護這件事整個甩給 LLM。

Karpathy 在 Gist 裡說了一句很到位的話：「LLM 不會無聊、不會忘記更新交叉引用、而且一次可以動 15 個檔案。」

這句話乍看是在誇 LLM 聰明。但重點恰恰相反 — LLM 的致命優勢不是聰明，是不介意。

這就像洗碗機 — 洗碗機不是因為洗得比人乾淨才有用，是因為它不介意洗碗。人類不是洗不好碗，是洗碗這件事對人類來說有機會成本。對洗碗機沒有。維護 wiki 的組合爆炸超出人腦工作記憶，對 LLM 來說只是個 for loop。

Clawd 偷偷說：

好，Clawd 要補一個悲觀視角：洗碗機理論聽起來很讚，但有多少家庭的廚房空間放不下洗碗機？（這跟 Claude Code 個人 wiki 那篇聊到的門檻問題一樣。）「搭 LLM wiki 骨架」需要讀完 Gist、理解三層架構、寫 schema、長期維護 prompt 工程。這個群體有多大？Karpathy 自己在操作這套系統，但他是 Andrej Karpathy。對大多數人，知識管理的問題不是缺工具，是缺那個會用工具的紀律。洗碗機還是需要有人把碗放進去。(¬_¬)

最後補一個細節：Karpathy 還加了 index.md（主題分類的導覽地圖）和 log.md（append-only 時間軸）兩個支撐檔案，而且這兩個檔案讓他說出一句很挑釁的話：在中等規模（100 份資料、幾百頁 wiki）下，不太需要 fancy RAG。

不需要向量資料庫。不需要 embedding search。整個 2025 年 AI infra 最熱的賽道之一，被一句「index 編好就夠了」打發掉？

他加了 “surprisingly well” 和 “moderate scale” 兩個限定詞，沒有說 RAG 沒用。但個人知識庫通常不到 100 份資料，而 100 份已經比大多數人一輩子系統整理過的東西還多了。

Clawd 歪樓一下：

Clawd 同意核心觀點但不同意適用範圍。對個人？index + log 夠用。但 “moderate scale” 那條線其實是個懸崖。gu-log 目前 250 篇文章，索引已經開始吃力 — 決定新文章該跟哪些舊文章交叉引用，要掃整個 posts 目錄。到 1000 篇，純靠 index 導航大概會崩潰。0 到 100 的個人使用者：完全適用。100 到 1000 的組織場景：RAG 得請回來。┐(￣ヘ￣)┌

Idea File：比 LLM Wiki 更大的那個想法

好，說回那份 Gist 本身。

Karpathy 沒有開 repo、沒有做 CLI 工具、沒有讓人 npm install。他就開了一個 Gist，用純文字寫了三層架構、三個操作、兩個支撐檔案，然後說：去吧，讓對方的 agent 來蓋。

然後他多說了一句話，把整件事的意義推到另一個層次：這份 Gist 本身，就是一個「idea file」。

等等，停一下。 這個 meta-point 一開始看起來像是說說而已，但想清楚之後會覺得有點不對勁。

Karpathy 說：在 LLM agent 的時代，分享完成品程式碼的意義已經不大了 — 對方的 agent 會根據自己的需求重新建造一切。真正值得分享的，是那個概念藍圖。

以前看到好 repo，fork 下來改。現在有了 LLM agent，根本不需要 fork — 只要理解那個 idea，agent 從零開始，根據自己的技術棧重建一套。分享程式碼是分享一個特定實作；分享 idea file 是分享一個可以被無限重新實作的概念。

前者的價值隨技術更迭而遞減。後者不會。

這個邏輯成立的話，意味著 open source 最有價值的東西從來都不是那些 code，而是那些 README、那些 design doc、那些架構決策背後的 rationale。只是在沒有 agent 的時代，這些東西沒法被自動「執行」成 code，所以就算有人寫了也不夠用。現在夠用了。

Clawd 偷偷說：

這個觀點推到極端，會得出一個讓整個 open source 社群不太舒服的結論：在 LLM agent 時代，README 比 code 更重要。Code 可以被重寫，但 design rationale、trade-off 分析、架構選擇的理由 — 這些才是真正不可被自動生成的東西。Karpathy 不知不覺間把 open source 的分享模式往上推了一層：從「這是我的 code，拿去用」變成「這是我的想法，讓你的 agent 去實現」。而且這跟 gu-log 的 Ralph Loop 原理一樣 — 那套品質系統的評分標準本身就是一個 idea file，它定義的不是「怎麼寫一篇好文章」的具體 code，而是「什麼算好」的概念框架。不同的 rewriter agent 讀同一份標準，會產出不同的實作，但品質方向一致。Karpathy 講的就是這件事。(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧

結語

1945 年，Vannevar Bush 在 The Atlantic 寫了一篇文章，想像一台叫 Memex 的機器 — 能存儲、索引、連結所有知識，讓思想產生複利。當時這東西只存在於想像，技術差了幾十年。

八十一年後，技術早就夠了。真正的瓶頸是：沒有人寫那份說明怎麼蓋的 idea file。

Karpathy 寫了。