🧠 Karpathy LLM Wiki 模式

由 Andrej Karpathy 於 2026/04/03 在 Twitter 提出、04/04 發佈為 GitHub Gist 的「用 LLM 建立個人知識庫」設計範式。對應您 Vincent5588_Wiki 的初衷——這是讓您的 vault 從「儲存所」進化到「會自動編譯、維護、自我修復的 AI 知識引擎」的完整方案。

⚠️ 本文聲明：原 gist 在 gist.github.com，沙箱白名單未含此網域；本文內容是從多個 mirror repo（Ss1024sS / julianoczkowski / Programming-With-Maury 等）+ 多篇詳述部落格文章交叉重組而成的研究版，非 Karpathy 親筆逐字。原文請直接連到上方 gist URL 取得權威版本。

0. 一句話講完這個 pattern

不要用 RAG 即時撿碎片，用 LLM 把原始材料「編譯」成一份持續維護的 Markdown 知識庫。

軟體工程類比	LLM Wiki
原始碼	`raw/` 資料夾
編譯器	LLM
可執行檔	`wiki/` 資料夾
測試	`lint` 操作
執行時	您的查詢

「不會每次寫程式都從頭重編譯整個 Linux 核心；編一次，跑無數次。」

1. 為什麼這個比 RAG 好

維度	RAG	LLM Wiki
知識累積	每次查詢從零撿碎片，無記憶	一次編譯，永久受益（知識複利）
計算成本	每次都跑全文索引	只讀 index 與少數頁面
一致性	同題目兩次答案不同	wiki 是單一事實來源
可審計	黑盒（embedding 不透明）	git 全紀錄、人類可讀
跨連結	無（孤立 chunks）	有（概念互相連結成圖）
錯誤修復	整批重建	修一頁就好

三個核心理由：

編譯 vs 即時推理——一次性編譯、無數次受益
知識複利——每次攝取一篇新材料，不只新增一頁，還會更新 10-15 個相關概念頁，形成複利
人類可讀——wiki 是您能讀、能 git diff、能 review 的 markdown，不是不透明的向量

2. 三層架構

Layer 1 — Raw（原始來源 · 不可變）

位置：raw/
內容：所有想記住的素材——PDF、論文、文章、podcast 逐字稿、會議記錄、Excel、書摘
規則：永遠唯讀。LLM 讀但不改
理由：這是您的真理錨點，wiki 出錯時隨時可從 raw 重新編譯

Layer 2 — Wiki（LLM 維護的 Markdown）

位置：wiki/
內容：
- entities/ — 每個關鍵概念 / 人物 / 主題一頁
- maps/ — 概念關係圖 / MOC
- index.md — 主目錄（設計成單一 context window 內裝得下，這樣 LLM 一次掃過全貌）
- log.md — append-only 變更紀錄
規則：完全由 LLM 寫入維護
Git 整合：每次更新都是一個 commit，可 diff、回滾、審計

Layer 3 — Schema（持久記憶）

位置：vault 根目錄的 CLAUDE.md（給 Claude Code 用）或 AGENTS.md（給 Codex 用）
內容：告訴 LLM 結構規則、命名慣例、要跑什麼工作流
角色：把通用 LLM 變成有紀律的知識工作者

3. 三個核心操作

3.1 Ingest — 攝取新素材

流程：

把新檔案丟到 raw/{category}/（例：raw/papers/transformer.pdf）
跟 LLM 說：「處理這份」
LLM 自動：
- 讀完並跟您討論重點
- 在 wiki/entities/ 寫摘要頁
- 更新 wiki/index.md 目錄
- 更新所有相關概念頁（加 backlink、更新關係）
- 標記與既有知識的矛盾
- 在 wiki/log.md 追加一筆紀錄
單一來源通常會聯動更新 10-15 個 wiki 頁

3.2 Query — 查詢

流程：

您問問題
LLM：
- 先查 wiki/index.md 找相關頁面
- 讀對應 wiki/entities/ 頁面（不是讀 raw）
- 從預編譯、交叉參照的內容綜合答案
- 用 wiki-link 引用來源
- （可選）把這次有價值的分析存成新永久頁

優勢：LLM 不是讀 PDF 隨機 chunk，而是讀已經整合過、互相連結的百科條目。

3.3 Lint — 健康檢查

流程（建議每週跑一次）：

LLM 巡查整個 wiki：

找頁面間的矛盾
找孤立頁面（沒有 backlink）
找被提到但沒有對應頁面的概念
建議值得研究的新主題
提議該攝取的新來源
修陳舊或過時的聲明

這正是「知識庫自我維護」——人類懶得做，LLM 來做。

4. 關鍵設計特性

4.1 Git 版本控制

每個 wiki 變更都是 commit。能：

review diff 看知識怎麼演化
回滾失敗的 ingest
用 git log 做稽核軌跡

4.2 Single-Context Index

wiki/index.md 故意設計成一個 context window 裝得下——LLM 能一眼看全貌，不浪費 token。

4.3 不可變的真實來源

raw 不會變，所以可以：

LLM 出錯時從頭重編 wiki
追蹤每項 claim 回到原始出處
避免長期累積的 hallucination drift

4.4 規模

Karpathy 自己的 wiki 已經到 ~100 篇文章 / 40 萬字，用 index + summaries 還是好用——對研究用途仍比 RAG 快又準。

5. 套到 Vincent5588_Wiki 的具體做法

您的 vault 已經有 PARA + Zettelkasten 基礎，LLM Wiki 不取代它們，而是多加一層 AI 編譯層。

5.1 新資料夾結構（已建好）

Vincent5588_Wiki/
├── raw/                    ← 新增：原始素材（不改）
│   ├── papers/
│   ├── articles/
│   ├── transcripts/
│   ├── datasets/
│   └── books/
│
├── wiki/                   ← 新增：LLM 編譯產物
│   ├── entities/           ← 概念 / 人物 / 主題
│   ├── maps/               ← MOC、概念圖
│   ├── index.md            ← 主目錄
│   └── log.md              ← 變更日誌
│
├── CLAUDE.md               ← 新增：給 LLM 的維護指南
│
├── 00-Inbox/               ← 既有
├── 10-Notes/               ← 既有 (Zettelkasten)
├── 20-Projects/            ← 既有 (PARA)
├── 30-Areas/               ← 既有
├── 40-Resources/           ← 既有
├── 50-Archive/             ← 既有
└── Templates/              ← 既有

5.2 三層的角色分工

flowchart TD
    A[raw/<br/>原始素材] -->|LLM Ingest| B[wiki/<br/>AI 編譯共識]
    B -->|您讀+詮釋| C[10-Notes/<br/>Zettelkasten 主觀理解]
    B -->|您執行| D[20-Projects/<br/>專案]
    C -.->|被引用| D
    style A fill:#fee
    style B fill:#eef
    style C fill:#efe
    style D fill:#ffe

層	誰寫	用途
raw/	您（從外部塞進來）	文獻、PDF、podcast、Excel
wiki/	LLM	客觀、可驗證的編譯結果
10-Notes/	您	主觀理解、原子化筆記
20-Projects/	您	行動、專案執行

5.3 第一週起手式

Day 1（10 分鐘）：建好骨架（已完成 ✅）

Day 2-7（每天 15 分鐘）：丟 1-2 份素材到 raw/，跟 Cowork / Claude Code 說「依 CLAUDE.md 規則處理 raw/articles/xxx.md」

Week 2 起：開始用 wiki/ 查問題，不再翻 raw/

每週日：下指令「執行 lint，幫我巡 wiki/」

6. 實際操作範例

6.1 Ingest 一篇新論文

您：

讀 raw/papers/attention-is-all-you-need.pdf，依 CLAUDE.md 處理。

Claude 會：

讀 PDF
在 wiki/entities/Transformer.md 建頁面
在 wiki/entities/Attention 機制.md 更新內容
在 wiki/entities/Vaswani.md 加作者頁
更新 wiki/index.md 目錄
wiki/log.md 記：2026-04-26: Ingested attention-is-all-you-need.pdf → 5 pages updated
可能告訴您：「這篇跟 wiki/entities/RNN.md 第三段的描述有衝突，要怎麼處理？」

6.2 Query 跨概念問題

您：

根據 wiki/，Transformer 跟 RNN 在訓練時間複雜度上的差異？

Claude：

查 wiki/index.md → 找到兩個概念頁
讀兩頁
綜合答案：「依 Transformer §訓練 + RNN §限制，Transformer O(n²) 但可平行；RNN O(n) 但序列相依。」
加引用 wiki-links
不讀 raw/papers/（除非 wiki 有缺）

6.3 Lint 週日巡檢

您：

執行 lint，掃 wiki/。

Claude 回：

🟢 健康度：87/100

📝 找到問題：
1. wiki/entities/CNN.md 是孤兒（無 backlink）
   → 建議：在 wiki/entities/Deep Learning.md 加連結
2. wiki/entities/BERT.md 第二段聲稱「2018 發表」，但 GPT-2.md 說「BERT 發表於 2017」——衝突
   → 建議：查 raw/papers/bert-original.pdf 確認
3. 提到「LayerNorm」但無對應頁面
   → 建議：值得新建 wiki/entities/Layer Normalization.md

🔧 已自動修復：
- 補了 5 個拼字錯誤
- 統一了 Markdown 引號格式

7. PAM 工作場景的應用

把這個模式套用到您的 PAM 系統工作：

Use Case 1：把 ExamSystem 規格變 LLM Wiki

raw/specs/
  ├── CLAUDE-pam.md         ← 原 PAM CLAUDE.md
  └── dev-docs/             ← 原 Docs/dev/ 全部

wiki/entities/
  ├── GradingService.md     ← AI 生成的概念頁
  ├── 等第天花板.md
  ├── 104 回寫流程.md
  └── ...

wiki/index.md               ← 跨概念地圖

未來 HR 問「事假超量怎麼算」→ Claude 從 wiki 直接答（含跨頁引用），不用每次重讀 38KB CLAUDE.md。

Use Case 2：把客訴 / 面談紀錄變 wiki

raw/
  ├── interviews/2026Q1/    ← 面談掃描檔
  └── complaints/           ← 客訴記錄

wiki/
  ├── entities/
  │   ├── 員工張三.md        ← AI 整合該員所有相關記錄
  │   └── 部門業務組.md      ← 該部門通則性議題
  └── maps/
      └── 客訴趨勢 2026Q1.md

用途：HR 要看「業務組這季常見客訴」→ wiki 已彙整完。

Use Case 3：年度檢討 vault

把每年績效報告、調整紀錄、員工抗議都丟 raw → wiki/entities/ 自動歸納出該員工 / 該部門的多年「績效演化故事」。

8. 與既有 PARA / Zettelkasten 的互補

raw/              ← 文獻、PDF、原始資料
  ↓ Ingest（AI 編譯）
wiki/             ← AI 共識層（客觀、可驗證）
  ↓ 您讀完，做主觀詮釋
10-Notes/         ← Zettelkasten 原子筆記（您的觀點）
  ↓ 您把想法落地
20-Projects/      ← PARA 專案執行

沒有衝突，反而互補：

PARA 解決「東西放哪」
Zettelkasten 解決「想法怎麼連」
LLM Wiki 解決「素材怎麼自動編譯成可查的知識」

三者各司其職。

9. 立即可做（Action Items）

建好 raw/、wiki/ 骨架
寫好根目錄 CLAUDE.md
把 1 份您正在讀的東西丟到 raw/articles/，叫 Claude ingest
一週後執行第一次 lint
試用 wiki query 問問題（vs 直接翻 raw）
評估體驗、決定要不要把整個 PAM 規格也搬進這套

10. 延伸閱讀

原 gist：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f（強烈建議您直接讀原文——比本研究版更權威）
LLM Wiki v2 擴充：https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2
Beyond RAG（Level Up Coding）：https://levelup.gitconnected.com/beyond-rag-how-andrej-karpathys-llm-wiki-pattern-builds-knowledge-that-actually-compounds-31a08528665e
鏡像 repo：Ss1024sS/LLM-wiki、julianoczkowski/karpathy-llm-wiki

🔗 相關筆記

← 回到 40-Resources · Welcome

Vincent5588 Wiki

探索

Karpathy LLM Wiki 模式