終於讀了 Karpathy 的 LLM Wiki 要點（沒錯，我來遲了，跟不上風潮 XD）。
說真的，整個概念其實很簡單，可以歸結為一句話：「可更新的 RAG」。
1. 問題所在
當 LLM 處理文件時，知識並不會累積。每一次查詢——模型都會重新擷取資訊片段、重新生成回答、然後遺忘。知識從未被編譯整合。而我認為更重要的是：對話本身幾乎沒有提取出任何有用的資訊。
RAG 能部分解決這個問題（廣義上來說，一個放滿 .md 檔案的資料夾也算是一種 RAG），但標準的流程（也就是大家都在用的那種）本身並不具備更新、提煉或自我清理的功能。知識一旦被存入索引，就只是靜靜待在那裡。LLM Wiki 正是為了填補這個缺口而設計的。
Karpathy 的想法翻轉了傳統做法：在原始資料與你之間，存在一個由 Agent 逐步編寫和維護的 Markdown Wiki。一次編譯，持續更新。
2. 架構：3 層結構
- raw/ - 原始來源，不可修改。Agent 不會在這裡寫入。
- wiki/ - 系統的核心；LLM 自行編寫並交叉連結的 Markdown 頁面（實體、概念）。本質上就是圖形化的知識庫。
- CLAUDE.md - 僅是 LLM Wiki 的操作手冊。包含：頁面格式、連結規則、導入流程、程式碼檢查規則。這個檔案能將 Claude 從聊天機器人轉變為一個嚴謹的 Wiki 維護者。
無需任何額外調整，即可輕鬆管理數百個頁面：
3. 操作
三個核心操作——你會立刻想把它們畫成 API 函式：
- Ingest ->
add(source: file | list[file])。丟入一個來源 -> Agent 讀取 -> 與你討論 -> 撰寫摘要 -> 更新索引 -> 編輯相關實體頁面 -> 附加到日誌。一個來源可能會觸及 10-15 個頁面。 - Query ->
search(prompt: str)。最重要的操作。回答你的問題 +（關鍵點）自動將生成的內容作為新頁面存回 Wiki。探索的成果會不斷累積，而不是消失在聊天記錄中。底層運作基本上等同於add(source=dialogue)。 - Lint ->
lint()。無需參數。定期檢查 Wiki：矛盾之處、孤立頁面、過時資訊、缺失的交叉引用。觸發時機 - 每隔 N 條用戶訊息，或根據修改行數計數器。可以輕易附加到/schedule上。
這讓我想起了 Claude Dreaming——我認為 Dreaming 部分靈感源自這個模式（雖然它的功能集略有不同）。
4. 索引機制
兩個特殊檔案讓 Wiki 易於瀏覽：
- index.md - 當前狀態。每個頁面的目錄，附帶一行簡介。Agent 在任何查詢時會先讀取它——這是理解「Wiki 裡到底有什麼」的最小上下文。
- log.md - 所有事件的自由格式日誌。僅供附加的時間軸。如果行記錄的格式保持一致（例如
## [YYYY-MM-DD] ingest | title），那麼就可以用純粹的 Unix 工具輕鬆 grep 這個日誌——方便審計。
index.md 可以進一步擴展（向量索引、BM25、GraphDB……），我會在另一篇文章中說明。
5. 重點啟發
我會這樣來理解：這不是在 RAG 和 LLM Wiki 之間做選擇——它們是「複利式記憶」這個光譜上的兩個端點。
RAG 不一定要用向量資料庫——一個放滿 Markdown 檔案的資料夾也可以算是 RAG。
所以你可以把 LLM Wiki 重新定義為 RAG，並在上面疊加三項功能：
- 一個摘要層。
- 在摘要層上（幾乎）自由地撰寫結構。
- 定期的結構審計與自我改進（CRON）。
