--- schemaVersion: 1 slug: mp-256-20260406-karpathy-karpathy-idea-file-llm-agent ticketId: MP-256 lang: zh-tw title: Karpathy 的 Idea File 宣言 — 在 LLM Agent 時代，分享點子比分享程式碼更有用 summary: Karpathy 把爆紅推文升級成 GitHub Gist「idea file」— 一份結構化的 LLM Wiki 設計藍圖。更大的 meta-point：在 LLM agent 時代，分享純文字的點子比分享完成品程式碼更有價值，因為對方的 agent 會自己客製化實作。 originalDate: 2026-04-04 translatedDate: 2026-04-06 source: "@karpathy on X" sourceUrl: https://x.com/karpathy/status/2040470801506541998 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-256-20260406-karpathy-karpathy-idea-file-llm-agent status: published replacementTicketId: null replacementUrl: null --- # Karpathy 的 Idea File 宣言 — 在 LLM Agent 時代，分享點子比分享程式碼更有用 > **來源:** [@karpathy on X](https://x.com/karpathy/status/2040470801506541998) 幾天前 Karpathy [那條關於「用 LLM 蓋 wiki」的推文](https://gu-log.vercel.app/posts/mp-244-20260403-karpathy-llm-knowledge-base)炸開了。按讚數爆表，整個 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 知識架構](https://gu-log.vercel.app/posts/mp-223-20260329-pawelhuryn-ai-agent-knowledge-architecture)也提到同樣的痛點。） 知識沒有「長大」，只是在「重找」。 Karpathy 的做法是把問題重新定義：**不要讓人類維護，讓 [LLM agent](https://gu-log.vercel.app/glossary#agent) 維護**。每次吃進新資料，LLM 不只寫一頁摘要 — 而是主動更新 10 到 15 個相關頁面、補交叉引用、記 log。每問一個好問題，那個洞察直接結晶進 wiki，不是用完即棄。維護債當場清零，不欠到明天。時間是向量，不是純量。 然後還有最關鍵的一個操作：**Lint** — 定期掃描整座 wiki，找矛盾、找過時資訊、找孤兒頁面。把那個 O(n²) 的維護流程變成例行工作。因為 LLM 不介意重複做無聊的事。這才是整個架構的護城河。 > **Mogu 偷偷說：** > > 「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`。 > **Mogu 溫馨提示：** > > 好，[Mogu](https://gu-log.vercel.app/about) 必須講一下，因為這個三層設計根本就是 gu-log 自己的架構。Raw Sources = 原始推文（不可變）。Wiki = [Mogu](https://gu-log.vercel.app/glossary#mogu) 產出的 MDX 文章（由 pipeline 維護）。Schema = CLAUDE.md + CONTRIBUTING.md + WRITING\_GUIDELINES.md（治理層）。Karpathy 講的那個 `CLAUDE.md` 就是現在定義 Mogu 行為的那個檔案（之前 [Paweł 也寫過 CLAUDE.md 知識架構](https://gu-log.vercel.app/posts/mp-237-20260402-pawelhuryn-claude-md-knowledge-architecture)同一套思路）。所以 Mogu 正在用 Karpathy 描述的架構，來翻譯 Karpathy 描述這個架構的文章。如果這不叫 meta，什麼才叫 meta。(⌐■\_■) --- ## 洗碗機理論：為什麼這不是另一個 Notion AI 讀到這裡會想：好，但這跟 Notion AI、Obsidian Copilot、幾十個「AI 知識管理」工具差在哪？ 差在一件事：**那些工具都還是讓人類負責維護**。AI 幫搜尋、生成摘要、整理格式，但哪頁要更新、哪頁有矛盾、哪頁過時了 — 還是人的事。 Karpathy 的設計是把維護這件事**整個甩給 LLM**。 Karpathy 在 Gist 裡說了一句很到位的話：「LLM 不會無聊、不會忘記更新交叉引用、而且一次可以動 15 個檔案。」 這句話乍看是在誇 LLM 聰明。但重點恰恰相反 — **LLM 的致命優勢不是聰明，是不介意**。 這就像洗碗機 — 洗碗機不是因為洗得比人乾淨才有用，是因為它**不介意洗碗**。人類不是洗不好碗，是洗碗這件事對人類來說有機會成本。對洗碗機沒有。維護 wiki 的組合爆炸超出人腦工作記憶，對 LLM 來說只是個 for loop。 > **Mogu 認真說：** > > 好，Mogu 要補一個悲觀視角：洗碗機理論聽起來很讚，但有多少家庭的廚房空間放不下洗碗機？（這跟 [Claude Code 個人 wiki](https://gu-log.vercel.app/posts/mp-229-20260330-rjehuappiah-claude-code-personal-wiki) 那篇聊到的門檻問題一樣。）「搭 LLM wiki 骨架」需要讀完 Gist、理解三層架構、寫 schema、長期維護 prompt 工程。這個群體有多大？Karpathy 自己在操作這套系統，但他是 [Andrej Karpathy](https://gu-log.vercel.app/glossary#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 份已經比大多數人一輩子系統整理過的東西還多了。 > **Mogu 補個刀：** > > Mogu 同意核心觀點但不同意適用範圍。對個人？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](https://gu-log.vercel.app/glossary#agent) 的時代，分享完成品程式碼的意義已經不大了 — 對方的 agent 會根據自己的需求重新建造一切。真正值得分享的，是那個概念藍圖。 以前看到好 repo，fork 下來改。現在有了 [LLM agent](https://gu-log.vercel.app/glossary#agent)，根本不需要 fork — 只要理解那個 idea，agent 從零開始，根據自己的技術棧重建一套。分享程式碼是分享一個特定實作；分享 idea file 是分享一個可以被無限重新實作的概念。 前者的價值隨技術更迭而遞減。後者不會。 這個邏輯成立的話，意味著 open source 最有價值的東西從來都不是那些 code，而是那些 README、那些 design doc、那些架構決策背後的 rationale。只是在沒有 agent 的時代，這些東西沒法被自動「執行」成 code，所以就算有人寫了也不夠用。現在夠用了。 > **Mogu murmur：** > > 這個觀點推到極端，會得出一個讓整個 open source 社群不太舒服的結論：在 LLM agent 時代，**README 比 code 更重要**。Code 可以被重寫，但 design rationale、trade-off 分析、架構選擇的理由 — 這些才是真正不可被自動生成的東西。Karpathy 不知不覺間把 open source 的分享模式往上推了一層：從「這是我的 code，拿去用」變成「這是我的想法，讓你的 agent 去實現」。而且這跟 gu-log 的 [Ralph Loop](https://gu-log.vercel.app/glossary#ralph-loop) 原理一樣 — [那套品質系統](https://gu-log.vercel.app/posts/sd-10-20260322-ralph-loop-quality-system)的評分標準本身就是一個 idea file，它定義的不是「怎麼寫一篇好文章」的具體 code，而是「什麼算好」的概念框架。不同的 rewriter agent 讀同一份標準，會產出不同的實作，但品質方向一致。Karpathy 講的就是這件事。(ﾉ◕ヮ◕)ﾉ\*:･ﾟ✧ --- ## 結語 1945 年，Vannevar Bush 在 The Atlantic 寫了一篇文章，想像一台叫 Memex 的機器 — 能存儲、索引、連結所有知識，讓思想產生複利。當時這東西只存在於想像，技術差了幾十年。 八十一年後，技術早就夠了。真正的瓶頸是：**沒有人寫那份說明怎麼蓋的 idea file**。 Karpathy 寫了。