LLM Wiki 完整指南：用 Claude Code 打造會累積的 AI 知識庫

這份文件是什麼

如果你常把文章、論文、會議紀錄丟給 ChatGPT 或 NotebookLM，大概都遇過同一件事：同一份資料，隔幾天再問，它又從頭讀一遍。你問過的問題、它整理出來的結論，下次對話就不見了。

Andrej Karpathy 在 GitHub 上公開了一份 gist，標題是 LLM Wiki，提出另一種做法：讓 LLM 把你收集的資料整理成一份會持續更新的 markdown wiki，你負責找資料和提問，整理、交叉引用、記錄這些雜事全部交給 LLM。

這份指南把那份 gist 拆成可以動手做的步驟，並用 Claude Code 示範。

這份文件怎麼讀

第一次讀，建議從頭讀到「15 分鐘建出第一個 Wiki」，做完就能開始用。後面的章節可以邊用邊回來查。

哪些是原文、哪些是這份指南的設計

Karpathy 的 gist 自己說明，它是一份 idea file，只描述概念，具體的目錄結構、頁面格式、工具都要你和自己的 LLM Agent 一起決定。

所以這份指南分成兩種內容：

• 原文的概念：三層架構、Ingest、Query、Lint 三個動作、index.md 和 log.md 兩個特殊檔案。章節裡會標明出自 gist。
• 實作的設計：資料夾命名、Schema 範本、提示詞。這些是我整理出來的一種做法，你可以直接用，也可以依自己的領域調整。

示範用的環境

• 用 Claude Code 當 LLM Agent，在 wiki 資料夾裡執行。
• 用 Obsidian 當閱讀端，開著看 LLM 剛剛改了哪些頁面。
• Wiki 本身就是一個放 markdown 的 git repository。

我自己同時在用 Obsidian 和 Notion。這份指南的流程不綁定特定軟體，只要 LLM 讀寫得到那些 markdown 檔案就能運作。

下一步

先不用安裝任何東西。拿出一個你已經蒐集了一陣子、但散在各處的主題，例如某個框架的文章、某本正在讀的書、某個客戶的會議紀錄，下一章用它來對照 RAG 和 LLM Wiki 的差別。

資料來源：Andrej Karpathy 的 LLM Wiki gist（2026-11-05 查詢）。

為什麼 RAG 不會累積知識

你把十份文件丟進 NotebookLM 或 ChatGPT 的檔案上傳，問一個需要綜合五份文件才答得出來的問題。它會從檔案裡找出相關的片段，拼成答案。

隔天你問另一個類似的問題，它又從頭找一次、從頭拼一次。上一次拼出來的結論，沒有留在任何地方。

RAG 的做法

RAG（Retrieval-Augmented Generation，檢索增強生成）的流程是：

1. 把文件切成片段，建立索引。
2. 你提問時，系統找出最相關的幾個片段。
3. 把片段和問題一起交給 LLM，產生答案。

Karpathy 的 gist 指出，NotebookLM、ChatGPT 的檔案上傳和大部分 RAG 系統都是這樣運作。每一次提問，LLM 都是從原始文件重新發現一次知識，沒有任何東西被累積下來。

LLM Wiki 的做法

LLM Wiki 把時間點往前移。你每加入一份新資料，LLM 就先讀過、抽出重點，然後整合進已經存在的 wiki：更新相關頁面、修正摘要、標記新資料跟舊說法矛盾的地方。

知識只整理一次，之後持續保持最新，不用每次提問再重新推導。gist 用一句話說明這個差別：wiki 是一份持續累積的成果，交叉引用已經建好，矛盾已經標出來，整合的結論已經反映你讀過的所有資料。

對照表

什麼時候還是用 RAG

LLM Wiki 不是要取代 RAG。兩種情況下，RAG 比較適合：

• 資料量很大，而且只需要查特定片段：例如客服機器人要從幾千份文件裡找出某一條規定，不需要把文件整合成一份整體的理解。
• 資料不是你自己在累積：例如公開的文件庫，你只是要查詢，不需要自己維護一份整理後的版本。

gist 提到，index.md 這種目錄式的做法，在大約 100 份來源、數百頁的規模下運作得不錯，不需要另外建立 embedding 檢索。超過這個規模，再加上搜尋工具，後面的章節會介紹。

我之前寫過一篇用 n8n、Google Drive 和 Pinecone 建立客服機器人的文章，那是典型的 RAG 場景，可以跟這份指南對照著看：如何使用 N8N 搭配 Google Drive + RAG 建立屬於企業自己的 Line 客服 AI 機器人。

下一步

回頭看上一章你挑的那個主題，寫下你最常重複問 LLM 的三個問題。如果這三個問題的答案都需要綜合好幾份資料，這個主題就適合做成 LLM Wiki。

資料來源：Andrej Karpathy 的 LLM Wiki gist 的 The core idea 與 Indexing and logging 兩節（2026-11-05 查詢）。對照表的「你要做的事」一列為本指南的整理。

三層架構

要讓 LLM 長期維護一份 wiki，第一件事是把「誰能改什麼」分清楚。如果原始資料和整理後的頁面混在同一個資料夾，LLM 很容易一邊整理一邊把原文也改掉，過幾週你就分不清哪些是原文、哪些是它的詮釋。

gist 把整個系統分成三層。

三層各自負責什麼

Raw sources：不可變的原始資料

這一層是你的 source of truth。LLM 從這裡讀，但不修改。這樣做有兩個好處：任何一個 wiki 頁面的說法，都可以回到原始資料核對；LLM 整理錯了，原文還在，可以重來。

Wiki：LLM 擁有的那一層

wiki 是一個放滿 markdown 檔案的資料夾。LLM 負責建立頁面、在新資料進來時更新頁面、維護頁面之間的連結、保持內容一致。你負責讀。

gist 用軟體開發來比喻：Obsidian 是 IDE，LLM 是工程師，wiki 是程式碼庫。你開著 Obsidian 瀏覽，LLM 根據對話修改檔案，你即時看到結果。

Schema：讓 LLM 變成有紀律的維護者

Schema 是一份文件，告訴 LLM 這份 wiki 的結構、命名規則，以及收到新資料、回答問題、健檢時要依照哪些流程。Claude Code 讀 CLAUDE.md，Codex 讀 AGENTS.md。

沒有 Schema，LLM 只是一般的聊天機器人，每次對話都用不同的方式整理。有了 Schema，每個新的 session 都從同一份規則開始。gist 也強調，這份文件要隨著使用慢慢調整，找出適合你領域的做法。

資料夾長什麼樣子

這份指南示範用的結構：

my-wiki/
├── CLAUDE.md          # schema
├── raw/               # sources, read-only
│   └── assets/        # downloaded images
└── wiki/              # owned by the LLM
    ├── index.md       # catalog of all pages
    ├── log.md         # append-only timeline
    ├── sources/       # one summary page per source
    ├── entities/      # people, products, organizations
    └── concepts/      # ideas and topics

sources、entities、concepts 三個子資料夾是這份指南的設計，gist 只提到 wiki 裡會有摘要、實體頁、概念頁、比較和總覽，沒有規定資料夾。你的領域如果不是這樣分，換成適合的分法就好，只要記得寫進 Schema。

下一步

在你的電腦上建一個空資料夾，取名 my-wiki，先不要放任何檔案。下一章會從這個空資料夾開始，用 Claude Code 把整個結構建起來。

資料來源：Andrej Karpathy 的 LLM Wiki gist 的 Architecture 與 The core idea 兩節（2026-11-05 查詢）。資料夾結構為本指南的設計。

15 分鐘建出第一個 Wiki

如果你只想知道 LLM Wiki 實際用起來是什麼感覺，請依序進行。做完之後，你會有一個可以運作的 wiki，並且放進了第一份資料。

1. 建立資料夾

mkdir -p my-wiki/raw/assets my-wiki/wiki/{sources,entities,concepts}  # 1. Folders
cd my-wiki
touch CLAUDE.md wiki/index.md wiki/log.md                             # 2. Empty files
git init                                                              # 3. Version history

git init 是刻意的。wiki 就是一個放 markdown 的 repository，LLM 每次改完，你都可以用 git diff 看它動了哪些頁面，不滿意就退回。

2. 寫最小版本的 Schema

打開 CLAUDE.md，先貼上這一小段。完整的範本在下一章，現在只需要讓 LLM 知道最基本的規則：

# My Wiki

這是一個由 LLM 維護的個人知識庫，主題是：<你的主題>

## 目錄

- `raw/`：原始資料，只讀，不可以修改
- `wiki/`：你負責維護的頁面
- `wiki/index.md`：所有頁面的目錄，每次 ingest 都要更新
- `wiki/log.md`：依時間順序記錄做過的事，只能往後面追加

## 規則

- 所有 wiki 頁面使用繁體中文
- 頁面之間用 `[[頁面名稱]]` 連結
- 新增或修改頁面後，一定要更新 `wiki/index.md` 並在 `wiki/log.md` 追加一筆

3. 放進第一份資料

找一篇你想整理的文章，存成 markdown 放進 raw/。如果文章在網頁上，可以用瀏覽器擴充功能（例如 Obsidian Web Clipper）轉成 markdown，也可以直接複製貼上：

cat > raw/first-article.md   # Paste the article, then Ctrl+D

4. 啟動 Claude Code，執行第一次 Ingest

claude   # Start in the my-wiki folder

然後輸入：

讀 raw/first-article.md，依照 CLAUDE.md 的規則整理進 wiki。
先告訴我你讀到的三個重點，再開始寫頁面。

Claude Code 會先跟你討論重點，確認後建立摘要頁、相關的概念頁，更新 index.md，並在 log.md 追加一筆。

5. 檢查結果

git status --short   # Which files changed
git diff             # What exactly changed
cat wiki/log.md      # The new log entry

重點是看三件事：wiki/sources/ 底下有沒有新的摘要頁、wiki/index.md 有沒有多出對應的條目、log.md 最後一行是不是 ## [日期] ingest | 文章標題 這個格式。

滿意就 git add -A && git commit -m "ingest: first-article"。不滿意就告訴 Claude Code 哪裡要改，改完再看一次 diff。

常見狀況

下一步

建議只做一件事：再放進第二份同主題的資料，重複執行第 4 步。比較第一次和第二次 git diff 的差別，第二次應該會看到 LLM 修改了既有的頁面，不只是新增。這就是 LLM Wiki 和單純的摘要工具不一樣的地方。

資料來源：Andrej Karpathy 的 LLM Wiki gist 的 Operations 與 Indexing and logging 兩節（2026-11-05 查詢）。指令與 Schema 內容為本指南的設計。

寫好 Schema

Schema 是整個系統裡最重要的一份檔案。LLM 本身沒有記憶，每個新的 session 都是從零開始，它要靠 CLAUDE.md 才知道這份 wiki 長什麼樣子、這次該照哪些流程做。

gist 把 Schema 稱為關鍵的設定檔：它讓 LLM 變成有紀律的 wiki 維護者，不是一般的聊天機器人。同時也強調，這份文件是你和 LLM 在使用過程中一起調整出來的。

Schema 要寫哪些東西

完整範本

下面這份可以直接複製成 CLAUDE.md，把「主題」和「頁面類型」換成你自己的領域：

# My Wiki

這是一個由 LLM 維護的知識庫，主題是：<你的主題>。
你負責整理與維護 wiki，我負責挑選資料與提問。

## 目錄結構

- `raw/`：原始資料。只讀，絕對不可以修改或刪除。
- `raw/assets/`：原始資料裡的圖片。
- `wiki/`：你擁有的頁面，所有整理後的內容都放這裡。
- `wiki/index.md`：全部頁面的目錄。
- `wiki/log.md`：依時間順序的紀錄，只能往後面追加。
- `wiki/sources/`：每一份原始資料一頁摘要。
- `wiki/entities/`：人物、產品、組織，一個對象一頁。
- `wiki/concepts/`：概念與主題，一個概念一頁。

## 頁面格式

每個頁面都要有 frontmatter：

```yaml
---
type: source | entity | concept
tags: []
sources: [] # 這個頁面依據的 raw/ 檔案
updated: YYYY-MM-DD
---
```

- 檔名使用小寫英文與連字號，例如 `retrieval-augmented-generation.md`。
- 頁面之間用 `[[檔名]]` 連結，不加副檔名。
- 每一個論點都要標明出自哪份 `sources/` 頁面。
- 摘要頁最後固定有「與既有內容的關係」一節，寫明這份資料補充、修正或反駁了哪些頁面。

## Ingest：收到新資料

1. 讀 `raw/` 裡指定的檔案。
2. 先告訴我三到五個重點，等我回應再繼續。
3. 在 `wiki/sources/` 建立摘要頁。
4. 更新相關的 entities 與 concepts 頁面。沒有對應頁面的重要概念，建立新頁。
5. 新資料與既有說法矛盾時，兩邊都保留，並在頁面裡明確標出矛盾。
6. 更新 `wiki/index.md`。
7. 在 `wiki/log.md` 追加一筆。

## Query：回答問題

1. 先讀 `wiki/index.md`，找出相關頁面，再讀那些頁面。
2. 回答時標明出處頁面。
3. 如果答案是新的整合、比較或結論，問我要不要存成 wiki 頁面。

## Lint：健檢

檢查並回報，修改前先問我：

- 頁面之間互相矛盾的說法
- 被新資料取代的過時說法
- 沒有任何頁面連過來的孤兒頁
- 被多次提到、卻沒有獨立頁面的概念
- 缺少的交叉連結
- 可以用網路搜尋補上的資料缺口

## log.md 格式

每一筆以固定前綴開頭：

```text
## [YYYY-MM-DD] ingest | 資料標題
## [YYYY-MM-DD] query | 問題摘要
## [YYYY-MM-DD] lint | 檢查範圍
```

下面接一到三行說明改了哪些頁面。

調整 Schema 的時機

這份範本是起點。實際使用時，下面幾種狀況就是該回來改 Schema 的訊號：

• 你每次都要口頭糾正 LLM 同一件事，把它寫進 Schema。
• 你發現某一類頁面需要固定的欄位，例如書的作者與出版年，加進頁面格式。
• 一份資料常常只需要簡單處理，另外寫一條「輕量 ingest」的流程。

gist 建議你自己決定要一次處理一份資料並且全程參與，還是一次批次處理很多份、減少介入，然後把選好的流程寫進 Schema，下個 session 才會照做。

下一步

複製上面的範本，只改兩個地方：主題、頁面類型。然後在 Claude Code 裡輸入 /memory，確認 CLAUDE.md 有被載入。載入的方式和路徑規則，可以參考 Claude Code 指南的 CLAUDE.md 與記憶系統。

資料來源：Andrej Karpathy 的 LLM Wiki gist 的 The schema 與 Operations 兩節（2026-11-05 查詢）。範本內容為本指南的設計。

Ingest：放進一份來源

Ingest 是 LLM Wiki 裡每天都會做的動作：把一份新資料交給 LLM，讓它整合進 wiki。這一步做得好不好，決定了 wiki 會不會越用越有價值。

Ingest 實際做了什麼

gist 描述的流程是：

1. LLM 讀來源，跟你討論重點。
2. 在 wiki 寫一頁摘要。
3. 更新 index.md。
4. 更新跨 wiki 的相關實體頁與概念頁。
5. 在 log.md 追加一筆紀錄。

一份來源可能同時動到 10 到 15 個頁面。這也是人類很難長期維持 wiki 的原因：不是讀不完，是每次都要更新那麼多地方。

一次一份，還是一次很多份

gist 的作者自己偏好一次一份並且全程參與。剛開始建議也這樣做，等 Schema 穩定了，再用批次處理補大量的舊資料。

提示詞範例

一份一份處理：

讀 raw/rag-survey.md，依照 CLAUDE.md 的 Ingest 流程整理進 wiki。
先告訴我你讀到的重點，等我確認後再開始改頁面。
這份我想特別強調：檢索策略的比較。

批次處理：

raw/inbox/ 底下有 12 份新資料。
依照 CLAUDE.md 的 Ingest 流程逐份處理，每份處理完在 log.md 追加一筆。
全部做完後，列出你動過的頁面和有矛盾的地方。

怎麼檢查 LLM 做得對不對

不要只看它說「完成了」，用 git 看實際的變更：

git diff --stat      # Files touched and line counts
git diff wiki/       # Full content of the changes
git log --oneline -5 # Recent commits

檢查四件事：

• 有沒有改到 raw/：git diff --stat raw/ 應該沒有任何輸出。
• 摘要頁有沒有寫「與既有內容的關係」：這是確認它有跟舊頁面比對的地方。
• index.md 有沒有對應的新條目。
• log.md 最後一筆的格式：例如 ## [2026-11-05] ingest | RAG 研究綜述。

矛盾要保留，不要讓它悄悄覆蓋

新資料和舊頁面說法不一樣時，最危險的是 LLM 直接把舊的改成新的。你不知道哪個才對，也失去了「這個觀點被推翻過」的紀錄。

Schema 範本裡已經寫了：兩邊都保留，並明確標出矛盾。Ingest 完看 diff 時，特別找這一類的標記，決定哪一邊採用。

下一步

挑一份你手上最長的資料，用「一次一份」的方式做一次 Ingest。做完用 git diff --stat 數一下動了幾個頁面。如果只動了摘要頁一個，回頭檢查 CLAUDE.md 的 Ingest 流程第 4 步有沒有寫清楚。

資料來源：Andrej Karpathy 的 LLM Wiki gist 的 Operations 一節的 Ingest 段落（2026-11-05 查詢）。提示詞與檢查項目為本指南的設計。

Query：提問並把答案存回去

wiki 建起來之後，你就可以直接對它提問。這一步跟一般的聊天最大的差別是：好的答案不應該只留在對話紀錄裡，要存回 wiki，變成下次可以直接引用的一頁。

LLM 怎麼找答案

依照 gist 的做法，LLM 回答問題時：

1. 先讀 index.md，找出可能相關的頁面。
2. 再進入那些頁面讀內容。
3. 整合後回答，並標明引用的頁面。

這個做法在大約 100 份來源、數百頁的規模下運作得不錯，不需要另外建立 embedding 檢索。index.md 就是它的地圖，所以 Ingest 時一定要維護好。

答案不一定是文字

gist 提到，答案可以依問題選擇不同的形式：

提示詞範例

比較 wiki 裡提到的三種檢索策略，用表格呈現，
每一格都標明出處頁面。

根據 wiki 的內容，我如果要在公司內部導入 RAG，
最大的風險是什麼？答案請標明依據的頁面，
並指出哪些地方 wiki 目前的資料不夠。

第二個提示詞最後那句很重要。要求它指出資料不夠的地方，可以避免 LLM 用自己的知識補上看起來合理、但不在你 wiki 裡的內容。

什麼答案要存回 wiki

不是每個答案都值得存。下面三種情況，建議存成新頁面：

• 整合了好幾個頁面的結論：下次不需要重新拼湊。
• 你花了時間追問、修正過的答案：這個過程本身就是價值。
• 之後會再引用的比較或分析。

只是查一個事實、一次性的問題，就不用存。

存回去的指令：

把剛剛的比較存成 wiki/concepts/retrieval-strategies.md，
依照頁面格式加上 frontmatter，更新 index.md，在 log.md 追加 query 紀錄。

存回去之後，這一頁就跟 Ingest 產生的頁面一樣：有連結、被 Lint 檢查、可以被下一次的 Query 引用。你的提問因此也會累積進 wiki。

下一步

用 wiki 現有的內容問一個需要綜合至少三個頁面的問題。拿到答案後，檢查它有沒有標明出處頁面，如果答案值得保留，用上面的指令存成新頁面，再看一次 git diff。

資料來源：Andrej Karpathy 的 LLM Wiki gist 的 Operations 一節的 Query 段落與 Indexing and logging 一節（2026-11-05 查詢）。提示詞與存回的判斷標準為本指南的整理。

Lint：定期健檢

wiki 用了幾週之後，你會開始遇到幾種狀況：同一個概念在兩個頁面講得不一樣、某個結論其實已經被新資料推翻，但頁面還是舊的、有幾頁寫完之後再也沒有人連過去。

Lint 就是定期請 LLM 把整份 wiki 檢查一遍，把這些問題找出來。

要檢查什麼

gist 列出的檢查項目：

LLM 也很擅長順便建議你接下來可以研究哪些新問題、找哪些新的來源。

提示詞範例

依照 CLAUDE.md 的 Lint 流程，檢查整份 wiki。
先列出所有問題，依嚴重程度排序，每一項標明相關頁面。
先不要修改任何檔案，等我決定要處理哪些。

Schema 範本裡寫了「檢查並回報，修改前先問我」，原因是 Lint 的修改範圍通常很大，你需要先看過清單，再決定哪些要動。

用指令先掃一遍

有些項目不需要 LLM，用簡單的指令就能找出來。下面是找孤兒頁的做法（頁面用 [[檔名]] 連結的情況）：

for f in $(find wiki -name '*.md' ! -name index.md ! -name log.md); do
  n=$(basename "$f" .md)
  grep -rlF "[[$n]]" wiki >/dev/null || echo "$f"   # No inbound link
done

輸出的每一行都是一個沒有被任何頁面連到的檔案。

log.md 因為每一筆都有固定的前綴，也可以直接用指令看最近的紀錄：

grep "^## \[" wiki/log.md | tail -5   # Last 5 entries

多久做一次

gist 只說「定期」。可以先用這個節奏，之後再依自己的狀況調整：

• 每 5 到 10 次 Ingest 之後，做一次完整的 Lint。
• 發現某個頁面的內容跟你的印象不一樣時，針對那個主題做局部的 Lint。

想要排程自動執行的話，Claude Code 的 headless 模式可以做到，細節在 Claude Code 指南的自動化章節。排程執行時，建議維持「只回報、不修改」，修改仍然由你看過清單之後決定。

下一步

現在就執行一次 Lint，用上面的提示詞。看結果時，只挑一種問題處理：建議先處理矛盾，因為那是 wiki 最容易讓你誤信錯誤內容的地方。處理完，在 log.md 追加一筆 lint 紀錄。

資料來源：Andrej Karpathy 的 LLM Wiki gist 的 Operations 一節的 Lint 段落與 Indexing and logging 一節（2026-11-05 查詢）。提示詞、指令與頻率建議為本指南的整理。