import KeyTakeaways from '../../../components/KeyTakeaways.astro';

<KeyTakeaways>
  <p>手上有多篇散落的筆記，AI 之後是不是還得每篇重讀才能拼出完整理解？Karpathy LLM Wiki 把分散的 source 編譯成按概念整合、由 LLM 持續維護的 Markdown wiki；這篇從原始架構一路介紹它的三個工作流程，再比較五個實作。</p>
</KeyTakeaways>

手上有多篇散落、彼此重疊的知識，怎麼把它們整合成一份之後真的能用的完整理解？這是我開始研究 LLM Wiki 的原因。

我在〈[Session is Knowledge：把 AI 對話保存成自己的知識庫](/posts/session-is-knowledge/)〉寫過這個做法：每次和 AI 討論完一件事，就把過程整理成一份 Markdown。它很適合保留「當時發生了什麼」——原本怎麼想、查了什麼、哪個方案被否決，以及最後為什麼這樣決定。問題是，當同一個主題在不同 session 裡出現好幾次，知識就會分散在好幾份摘要裡。

五月整理 OpenMemory 時，我手上已經有好幾份相關紀錄：一份記 MCP 修復，一份記架構，一份記 memory strategy。OpenMemory 可以幫我叫回某個片段，但要回答一個比較完整的問題，我還是得把幾份摘要一起翻出來，重新拼回脈絡。筆記確實保存了，但「保存」和「整合」是兩件事。

## 散落的筆記，怎麼變成一份完整理解？

Session Summary 和 LLM Wiki 的差別，可以先用兩個方向來看：

| | Session Summary | LLM Wiki |
|---|---|---|
| 組織方式 | 按時間，一個 session 一份紀錄 | 按概念，一個主題一頁 |
| 寫入方式 | Append-only，保留原始紀錄 | Upsert，新 source 更新既有頁面 |
| 主要回答 | 這次討論發生了什麼？ | 目前對這個概念的理解是什麼？ |
| 角色 | 後續整理的 source | 跨 session 合併後的知識 |

如果我有五篇討論 OpenMemory 的 Session Summary，它們可以完整保存五次討論的脈絡，卻不會自動變成一份「截至今天，我對 OpenMemory 的完整理解」。我可以用 tag 或搜尋把五篇找出來，但最後還是得自己讀完，再做一次整合。

這就是我開始需要 LLM Wiki 的時刻：不是找不到資料，而是每次找到之後，都還要重新做同一份整理工作。

## Karpathy 的 LLM Wiki 想解決什麼？

Karpathy 在 [LLM Wiki gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) 裡描述的，並不是一個叫做 LLM Wiki 的現成產品，而是一個可以交給 Agent 實作的 idea file。

常見的 RAG 工作方式是：把一堆檔案切成 chunks，等使用者提問時，再找出相關片段，交給 LLM 生成答案。這種方式很有用，但每一次提問都可能要重新找資料、重新比對、重新拼出跨文件的關係。上一個問題做過的整合，不一定會留下來。

LLM Wiki 的方向相反。新的 source 進來時，LLM 不只是替它建立索引，而是讀完後把資訊編譯進既有的 wiki：更新 entity page、補充 concept page、修正摘要、建立 cross-reference，也標記新舊資料之間的矛盾。

查詢發生時，Agent 先讀已經整理過的 wiki，再根據需要回頭查 source。知識不是每次問問題才重新發現，而是在 ingest 時先被整理一次，之後持續累積。

這也是 Karpathy 所說的 persistent, compounding artifact：每增加一份 source，wiki 不只是多一頁，而是可能讓原本的頁面、連結與整體理解一起變完整。

## 原始架構：Raw、Wiki，還有 Schema

Karpathy 的原始架構可以畫成這樣：

```text
                  Schema
          CLAUDE.md / AGENTS.md
          規定 Agent 怎麼維護 wiki
                       │
                       ▼
Raw sources ── ingest ──▶ Wiki
不可變的原始資料          LLM 維護的概念頁
文章、論文、圖片          摘要、entity、comparison
```

### Raw sources：人整理，LLM 只讀

Raw layer 是來源的集合，可以是文章、論文、圖片、資料檔或其他研究材料。它是 immutable 的：LLM 可以讀，但不應該直接修改。這層的價值在於，之後如果 wiki 裡出現錯誤，還能回頭檢查原始資料。

放回我的情境，`summaries/` 本身就已經是內部的 raw layer。它們是時間軸紀錄，應該保留，不需要為了配合某個工具再複製一份。

### Wiki：LLM 寫，人閱讀

Wiki layer 是由 LLM 產生與維護的 Markdown 頁面。它不再按照「哪一次討論」分頁，而是按照知識的概念組織：某個工具可以有 entity page，某個方法可以有 concept page，兩種方案也可以整理成 comparison page。

一份 source 可能同時更新多個頁面。這也是它和單純「一篇 source 對一篇 summary」的差異：source 是輸入，wiki 是整合後的投影。

### Schema：讓 Agent 知道自己不是普通聊天機器人

Schema 通常是一份 `CLAUDE.md` 或 `AGENTS.md`，告訴 Agent wiki 的資料夾結構、頁面格式、連結規則，以及 ingest、query、lint 時要遵守的流程。

這一層很關鍵。沒有 schema，Agent 可能只會幫你摘要一篇文章；有了 schema，它才知道自己要維護的是一個會持續變動的知識系統。

原始 gist 刻意沒有規定一棵唯一正確的資料夾樹。`raw/`、`wiki/` 和 schema 是責任邊界，不是要求每個人照抄相同檔名。這點很重要，因為我的 summaries 已經存在，真正需要新增的是從 summaries 合流到 wiki 的 ingest 步驟。

## LLM Wiki 的三個工作流程

LLM Wiki 不是把 source 丟進資料夾就結束，而是有三個彼此接續的工作流程：先把新資料整合進 wiki，再從 wiki 查詢，最後定期檢查整個知識庫的健康狀態。

| 操作 | 做什麼 |
|---|---|
| Ingest | 讀取新 source，建立或更新 wiki 頁面、index 與 cross-reference |
| Query | 搜尋 wiki，根據已整合的頁面回答問題，必要時附上 citations |
| Lint | 檢查矛盾、過時內容、孤兒頁面、缺少的連結與資料缺口 |

### LLM Wiki 的 `index.md`：先看目錄，再讀內容

`index.md` 可以把它想成書的目錄，但它不只列檔名。每個 wiki page 會有連結、一行摘要，以及必要的 metadata。Agent 查詢時先讀這份小型索引，先知道有哪些頁面、哪幾篇可能相關，再只讀真正需要的內容。

這就是漸進式披露：先用少量 token 看全貌，再把 context 花在相關頁面上。`index.md` 不需要塞進每篇文章的完整內容，它的工作是替 Agent 指路。

### LLM Wiki 的 `log.md`：記下知識庫怎麼長大

`log.md` 是另一條時間軸，記錄什麼時候 ingest 了哪個 source、做過哪些 query、跑過哪些 lint。它不是知識頁面的目錄，而是 wiki 的操作履歷。

把兩者分開後，角色就很清楚：`index.md` 幫忙找到「該讀什麼」，`log.md` 保存「這個 wiki 怎麼一路變成現在的樣子」。

## 理解模式後，才開始比較實作

Karpathy 提出的是架構模式，不是官方套件。因此下一個問題很自然：如果真的要開始用，該選哪一套實作？

我當時比較的是不同形態的 repository。下面的 stars 是 2026-08-16 查詢值，只代表當下的社群關注度，不是功能排名；當時的 session summary 另外記錄 `Astro-Han/karpathy-llm-wiki` 是 932 ⭐。

| Repo | 形式 | 主要特色 | 這次的判斷 |
|---|---|---|---|
| [Astro-Han/karpathy-llm-wiki](https://github.com/Astro-Han/karpathy-llm-wiki)<br />1,913 ⭐ | Agent Skill | `raw/ → wiki/`、Ingest / Query / Lint，支援 Claude Code、Cursor、Codex | 選用 |
| [kfchou/wiki-skills](https://github.com/kfchou/wiki-skills)<br />176 ⭐ | Claude Code plugin | 多個 wiki skill、helper scripts、audit 與 git hook | 值得比較，但更綁 Claude Code |
| [toolboxmd/karpathy-wiki](https://github.com/toolboxmd/karpathy-wiki)<br />99 ⭐ | Claude Code skills | 以 Shell skill 組成 Karpathy-style wiki workflow | 另一種 skill 實作 |
| [green-dalii/obsidian-llm-wiki](https://github.com/green-dalii/obsidian-llm-wiki)<br />463 ⭐ | Obsidian plugin | 在 Obsidian 裡 ingest、query、graph retrieval 與 lint | 不想把流程綁在 App 裡 |
| [lucasastorian/llmwiki](https://github.com/lucasastorian/llmwiki)<br />1,500 ⭐ | 獨立 Web App | Web UI、MCP、Chrome clipper，也有 local mode | 功能完整，但架構方向不同 |

這張表有一個容易被 stars 帶偏的地方：星數最高的不一定是最適合自己的方案。`lucasastorian/llmwiki` 看起來很完整，但它是一套獨立的應用程式；我當時要接的是既有的 Markdown summaries、Claude Code 與 MCPVault，不是搬去另一個 Web App 重新管理資料。

## 為什麼最後選 Astro-Han？

最後選 [Astro-Han/karpathy-llm-wiki](https://github.com/Astro-Han/karpathy-llm-wiki)，是因為它本身就是一個純 Agent Skill：把 Karpathy 的模式寫成 Agent 可以執行的規則，不綁定特定的 Web App、筆記介面或 retrieval service。

它是可安裝的 Agent Skill，不要求我先導入一個獨立 App。安裝後，Agent 仍然透過既有的檔案與工作目錄工作，能把 `summaries/` 當作 internal source，再把整合後的內容寫到 `wiki/`。它也把單次 ingest 和後續的 query、lint 規則放在同一套 schema 裡。

```bash
npx add-skill Astro-Han/karpathy-llm-wiki
```

這個選擇的核心不是「它最強」，而是「它最像我已經在使用的工作方式」。對我來說，LLM Wiki 不需要取代原本的 Session Summary；它只需要在中間補上一個編譯步驟。

## LLM Wiki 的邏輯，和 OpenSpec 很像

看到這個「原始紀錄 → 整合後的主要知識」結構，我想到另一套自己熟悉的系統：OpenSpec。

OpenSpec 裡，一次次 feature 的 `change spec` 是開發過程中的局部變更；完成後，再把重要內容收斂成之後開發可以查閱的 `main spec`。LLM Wiki 也有一個相似的方向：Session Summary 保留每次討論的原始脈絡，concept page 則把跨 session 的理解合流成目前版本。

```text
Session Summary  ── ingest ──▶  Wiki concept page
change spec      ── merge  ──▶  main spec
```

這不是 Karpathy 原文使用的術語，也不是說 OpenSpec 和 LLM Wiki 是同一套工具。它比較像是我用來理解這個模式的對照：原始紀錄不能消失，但如果每次都只讀原始紀錄，下一次就得重新做一次整合。

## LLM Wiki 不是取代 Session Summary

到這裡，兩者的分工就清楚了。

Session Summary 保存時間軸：這次討論怎麼開始、哪個假設被推翻、最後做了什麼決定。LLM Wiki 保存概念軸：截至目前，這個主題整合後的理解是什麼、它和哪些主題有關、哪些說法曾經互相矛盾。

如果一個主題只出現過一兩次，直接搜尋 Session Summary 可能就夠了。當同一個主題累積到三到五個 session，開始需要反覆解釋、反覆比對，才值得建立 concept page。

所以第一篇先停在這裡：我理解了 LLM Wiki 的原始模式，比較了幾種實作，也選好了要用的 Agent Skill。至於安裝後怎麼接上 `summaries/`、50 篇 summary 怎麼批次 ingest，以及實際跑過後哪些地方不合用，那是下一篇的工作。

我喜歡這個選擇的一點，是它沒有要求我把過去的紀錄整理得像一個完美的資料庫。那些有點凌亂、但保留了思考過程的 Session Summary 可以繼續留著；LLM 只需要負責把它們讀懂，然後幫我把「我已經討論過很多次的東西」整理成下一次真的找得到的知識。