Karpathy LLM Wiki 是什麼？把散落知識整合成概念 Wiki

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

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

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

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

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

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

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

Karpathy 的 LLM Wiki 想解決什麼？

Karpathy 在 LLM Wiki gist 裡描述的，並不是一個叫做 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 的原始架構可以畫成這樣：

1
                  Schema
2
          CLAUDE.md / AGENTS.md
3
          規定 Agent 怎麼維護 wiki
4
                       │
5
                       ▼
6
Raw sources ── ingest ──▶ Wiki
7
不可變的原始資料          LLM 維護的概念頁
8
文章、論文、圖片          摘要、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 查詢，最後定期檢查整個知識庫的健康狀態。

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 ⭐。

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

為什麼最後選 Astro-Han？

最後選 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 裡。

1
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 的理解合流成目前版本。

1
Session Summary  ── ingest ──▶  Wiki concept page
2
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 只需要負責把它們讀懂，然後幫我把「我已經討論過很多次的東西」整理成下一次真的找得到的知識。