2026 年 4 月 3 日，Andrej Karpathy 發了一條推文。沒說什麼驚天動地的事，只說他最近很少用 AI 寫代碼了。取而代之，他把 AI 拿去做另一件事：維護一個自己讀書、自己摘要、自己建交叉連結的個人知識維基。
隔天，他把完整的架構丟到 GitHub 上變成一個 gist。檔名叫 llm-wiki。
這條推文在英文 AI 圈炸了。轉推、翻譯、二次創作的文章兩週內超過三十篇。原因很簡單，前 OpenAI 創辦人、前 Tesla AI 總監、教出整代 LLM 工程師的那個人，公開示範了他對 AI 的用法。而他的用法，跟 99% 的普通用戶完全不同。
Karpathy 換了一個姿勢：從「工人」到「員工」
先講清楚概念差別。大多數人用 AI 的姿勢是這樣的：想到一個問題，開 ChatGPT 或 Claude，問一次，得到答案，關掉。下一次再問，AI 不記得上次的對話，從零開始。
這叫「工人模式」。AI 是按件計酬的臨時工，來幹活、幹完走人、下次再找同一批臨時工再幹一次。
Karpathy 做的不是這樣。他給 LLM 一個固定的工作空間（一個資料夾）、一本工作手冊（一個 CLAUDE.md 之類的檔案）、一疊原始資料（論文、文章、PDF）。然後讓 LLM 每天做三件事：讀新資料、寫摘要、把摘要跟舊摘要用 wiki 連結串起來。
他給這套系統取了個名字，叫 LLM Wiki。他自己的那個，單一主題已經累積了 約 100 篇文章、40 萬字。全部 AI 自動寫、自動更新、自動互連。他只做一件事：把原料丟進去。
「LLM 不會膩、不會忘記要更新交叉連結、一次能碰 15 個檔案。」—Karpathy
這句話翻譯成白話就是：他把 AI 從「寫程式碼的工人」升級成「自己管理資料庫的員工」。工人要你盯著，員工自己上班。
拆開來看，LLM Wiki 就三個資料夾
很多人看到「架構」兩個字就怕，以為要寫一堆程式。LLM Wiki 的結構意外的簡單，簡單到看完這段你就能建一個。
第一個資料夾：raw/。放原始資料。PDF、文章、截圖、逐字稿，什麼都行。這層是唯讀的，LLM 只看、不改。
第二個資料夾：wiki/。LLM 的工作區。裡面是一堆 markdown 檔案，每一篇對應一個主題、人物、概念、事件。這些全部由 LLM 寫，也由 LLM 維護。
第三個檔案：index.md。wiki 的目錄。每個主題一行摘要，整個 index.md 小到能塞進一次 LLM 的 context window。這是整套設計的關鍵。LLM 不用搜尋，它可以「一次看完整個目錄」，就知道要去哪個子頁面找東西。
再加一個 log.md（歷次摘要動作的流水帳）和一份 schema 說明書（告訴 LLM 怎麼寫 wiki 頁），整套就齊了。
三個動作：Ingest、Query、Lint
操作只有三個動詞。
Ingest（吸收）：丟一篇新文章給 LLM，讓它自動摘要、寫成 wiki 頁、找出跟舊頁的關聯、在相關舊頁上補加反向連結、在 log.md 記一筆「今天我吃了什麼」。Karpathy 提過，一份新資料通常會牽動 10 到 15 個 wiki 頁面的更新。這件事人類做一次就累了，LLM 做一百次還是一樣。
Query（查詢）：你問一個問題，LLM 不從 raw/ 找答案，它從 wiki/ 找。因為 wiki 已經把知識壓縮、交叉連結過了，答案直接有來源、有脈絡。如果發現有新洞察，可以把這次查詢本身也 ingest 成一篇新 wiki 頁。
Lint（體檢）：定期讓 LLM 檢查 wiki 有沒有矛盾、有沒有孤兒頁（沒有其他頁連結過來的）、有沒有資訊過期。這個動作大多數知識管理系統都缺，因為人類不會沒事去維護自己的筆記。
這跟 RAG 差在哪？為什麼是「下一種做法」
過去兩年，企業做「AI + 我的資料」基本都是同一套：RAG（Retrieval-Augmented Generation）。把所有文件切塊、做 embedding、丟進向量資料庫、查詢時撈最相關的幾塊塞進 prompt。
RAG 的問題 Karpathy 其實一句話就點破了：每次問問題，LLM 都是從零開始拼湊答案。五十篇文章分開看，每次只看三塊。知識從來沒有被「整合過」。就像你請了一個很聰明的實習生，但每次問他事情，他都要重新翻一次所有檔案。
LLM Wiki 的邏輯反過來。先把所有文章預先整合成一張結構化的知識網，之後所有查詢都走這張網。你一次性付出「整理成本」，後面每次查詢都在享受複利。
| 面向 | RAG | LLM Wiki |
|---|---|---|
| 知識儲存 | 向量資料庫 + 原始文件 | 結構化 markdown wiki |
| 查詢時做的事 | 臨時撈相關片段 | 讀已經整合好的頁面 |
| 知識會累積嗎 | 不會，每次重來 | 會，每次 ingest 後沉澱 |
| 適合場景 | 大規模、多用戶、機器查 | 個人或小團隊、持續研究 |
| 維護成本 | 幾乎沒有 | 需要偶爾 lint |
這不是說 RAG 要死。企業問答系統、客服機器人、大規模文件搜尋，RAG 還是對的。但如果你的目標是「把一個主題研究到骨頭裡」，例如一個投資議題、一個技術領域、一個產業賽道，LLM Wiki 這套明顯更適合。
散戶能不能抄這套？三步就能開始
來講你真正想知道的：我能不能用。答案是可以。Karpathy 發的是一個提示詞 + 資料夾結構的設計，沒有要你寫 code。
第一步：選一個主題，開一個資料夾。不要貪心一次做五個主題。挑一個你接下來三個月會持續碰的題目。例如「穩定幣理財」「AI Agent 框架」「熱門 DePIN 項目」。建三個子資料夾：raw/、wiki/、然後一個空的 index.md。
第二步：寫一份 schema。這是寫給 LLM 看的工作手冊。告訴它：每篇 wiki 頁用什麼模板（例如「一句話摘要 + 關鍵數據 + 相關頁面連結」）、頁面命名規則（例如用英文連字號）、index.md 怎麼更新。Karpathy 的 gist 裡有完整範本，複製貼上改一下就能用。
第三步：開 Claude Code（或 Codex、Cursor 都可以），指向這個資料夾，下指令。比如「我丟了一篇文章到 raw/，請 ingest 它」。LLM 會自動讀、寫、更新、記錄。你的工作就是丟料進去，偶爾下 query 指令或 lint 指令。
我自己測了一週，用 Claude Code 跑這套，主題選「HyperLiquid 生態」。丟了 20 篇文章、5 份報告進去。現在當我想問「HYPE 質押收益跟其他 L1 比怎麼樣」這種需要交叉五個頁面的問題，它能直接給有來源、有連結的回答。對比之前我用 Notion AI 或 ChatGPT 翻來翻去，效率差兩到三倍。
Tony 的判斷：這是「AI 指揮官思維」的起點
Karpathy 這篇 gist 重要，不是因為架構本身有多複雜，是因為他示範了一個觀念轉換：不要把 AI 當工具，把它當員工。
工具的邏輯是你用它做一件事。員工的邏輯是你給它一個職責，它持續把事做好。兩個姿勢的產出差一個數量級。
過去半年有個趨勢越來越明顯：頂級的 AI 使用者都在從「Prompt 工程師」變成「AI 管理者」。Karpathy 的 LLM Wiki、OpenAI 的 Agents 框架、Claude 的 skills 和 MCP，這些東西本質上都在做同一件事，把 AI 從「一次性回答機」變成「有記憶、有任務、有工作流的同事」。
如果你還在「問問題、得答案、關視窗」這個循環裡，你用的是 2023 年的 AI。2026 年已經在做的事，是設計一套讓 AI 自己上班的制度。
接下來該關注什麼
三件事值得追。
第一，LLM Wiki 會不會被產品化。現在已經有開源項目把 Karpathy 的 gist 包成可用的工具（例如 LLM Wiki v2、antigravity.codes 出的實作）。如果出現一個像 Obsidian 那樣好裝好用的版本，這套就會破圈。
第二，企業會不會導入。一個團隊共用一個 LLM Wiki，知識不再跟著人走而跟著倉庫走。這對離職交接、知識沉澱、跨部門協作是根本性的改善。但前提是 LLM 要便宜到可以每天刷幾百次 ingest。
第三，個人級的用法會長什麼樣。Karpathy 示範的是研究員模式。但如果有人把它改成「個人財務 wiki」「健康紀錄 wiki」「投資決策 wiki」，應用面會完全不同。這是接下來三到六個月最值得試的個人生產力實驗。
結論：整理是一次性成本，理解是永久複利
Karpathy 這條推文之所以值得寫一篇文章去拆，不是因為他講了什麼新技術，是因為他公開了自己的「使用姿勢」。
一個頂級研究員不用 AI 寫代碼了，改用 AI 管理自己的知識。這個選擇本身就在告訴你，哪個方向會長出更強的能力。
如果你也在某個領域想紮根，不管是加密貨幣、AI 工具、還是別的專業，今天就可以開一個資料夾，開始 ingest。三個月後你會擁有一張別人沒有的知識網。這不是雞湯，是 Karpathy 用 40 萬字證明過的做法。
免責聲明：本文資訊來自 Karpathy 於 2026 年 4 月 3 日發表的 X 推文與隔日公開的 GitHub gist，以及多家媒體與開發者社群的二手分析。AI 工具更新極快，本文內容截至 2026 年 4 月 21 日。Tony 個人的測試結果僅供參考，不代表所有使用情境下的效果。
發表迴響