recordings-35.txt

# Mobile Capture 20260510T131118+0000-local-36a051afaa44

Captured: 2026-05-10T13:11:18+00:00
Source: local
From: macbook

Original files:
- Recordings-35-.txt

## Content

# Recordings-35-.txt

Recordings
Andrej Karpathy 最近分享了一個關於 LLM 知識庫的全新思路，引發了極大迴響。傳統做法（RAG）的問題在於：每次提問，AI 都從零開始檢索文件片段，然後重新組織答案。知識沒有積累，每次都在重複勞動。

Karpathy 提出的替代方案是：讓 LLM 主動建立一個持續維護的 Wiki。這個 Wiki 是一組結構化的 Markdown 文件，由 LLM 全權負責維護。每當有新資料進來，LLM 不是單純索引，而是真的去閱讀、提取關鍵資訊、整合進現有知識體系。更新實體頁面、修訂主題摘要、標記新舊資料的矛盾、補充交叉引用。知識被「編譯」一次，然後持續維護，而不是每次查詢都重新推導。

架構分為三層：

第一層 Raw Sources（原始資料）：所有原始材料——論文、文章、圖片、數據文件。這層是不可變的，LLM 只讀不寫。這確保你可以隨時回溯、核查。

第二層 The Wiki（知識層）：由 LLM 完全擁有和維護的 Markdown 文件群。摘要、實體頁面、概念頁面、對比分析、總覽。這不是原始資料的簡單搬運，而是 LLM 在理解、提煉、關聯之後的產物。

第三層 The Schema（規則層）：配置文件（如 CLAUDE.md 或 AGENTS.md），告訴 LLM Wiki 的結構、約定、處理流程。這是把 LLM 從「通用聊天機器人」變成「有紀律的 Wiki 維護者」的關鍵。

四種核心操作模式：

Ingest（攝入）：新資料進入 raw 目錄，LLM 讀完後與你討論重點，撰寫摘要頁面，更新索引和相關實體頁面。一個資料來源可能觸及 10-15 個 Wiki 頁面。

Query（查詢）：向 Wiki 提問。LLM 搜尋相關頁面、閱讀、綜合回答。關鍵洞察：好的回答應該存回 Wiki——你的對比分析、關聯發現，不該消失在聊天記錄裡。

Lint（健康檢查）：定期讓 LLM 給 Wiki 體檢。找矛盾、找過時資訊、找孤立頁面、找被提及但沒有獨立頁面的重要概念、找缺失的交叉引用。

Indexing & Logging（索引和日誌）：index.md 是內容索引，log.md 是時間線。

Karpathy 發現，當 Wiki 規模不大時（約 100 個資料來源、數百個頁面），LLM 直接讀 index.md 來定位相關頁面就夠用了，不需要搭建 embedding + 向量檢索系統。這跟很多人的直覺相反——如果 Wiki 組織得好，一個結構化索引文件可能比花哨的檢索系統更有效。

最後，Karpathy 提出了「idea file」這個概念：在 LLM agent 時代，分享代碼和分享想法的邊界正在改變。以前你要分享一個工具，得寫代碼、建 repo、寫文檔。現在你只需要把想法描述清楚，別人的 agent 會根據這個想法定製屬於他們自己的實現。

這個 Gist 本身就是這個理念的實踐。它沒有代碼，只有清楚的思路描述。你把它丟給 Claude Code 或 Codex，agent 就會幫你把整套系統搭出來。

如果這個轉變真的成立，「知識的傳播單位」正在從代碼變成想法。開源社區的基本單位從 repository 變成 idea file。

#gist.github.com/karpathy/llm-wiki