karpathy-llm-wiki：把 LLM 編譯知識庫封裝成一個 Agent Skill
Agent Skills-compatible LLM wiki for Claude Code, Cursor, and Codex. Build a Karpathy-style knowledge base from raw sources, citations, and linting.
秒懂
- 它是什麼？
- 這個專案把 Karpathy 的 LLM Wiki 構想做成可安裝的 Agent Skills 技能，讓 Claude Code、Cursor、Codex 等工具以 ingest、query、lint 三個動作維護 raw/ 與 wiki/ 兩層目錄。核心判斷：它賣的是工作流程約束，不是檢索技術，適用與否取決於你能否接受模型直接改寫你的筆記。
- 適合誰用？
- 如果你已經有一批會反覆回頭查的來源材料，而且願意讓模型直接改寫 wiki/ 底下的 markdown，這個技能值得裝起來試一輪 ingest 加一次 lint。若你的需求是對大型語料做廣召回檢索，或你必須對每一條引註做行號級追溯，它明確不是為這兩件事設計的。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 54 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是重複檢索，不是檢索本身
多數人問文件問題的流程是：每次提問都重新翻一遍原始材料，模型在對話裡臨時拼湊答案，對話結束後這些拼湊結果就消失了。同一個概念下週再問一次，模型從零開始再推一遍。karpathy-llm-wiki 針對的正是這個損耗：README 把 LLM wiki 定義為「LLM 維護結構化 wiki 頁面，而不是每次提問都重新搜尋原始文件」，新來源被編譯成耐久頁面，交叉引用隨時間更新，回答則引用已經含有綜合知識的 wiki 頁。
目標使用者寫得很清楚：用 Claude Code、Cursor、Codex 或其他支援 Agent Skills 標準的工具，並且在乎「知識會隨時間變好」的人。它假設你有一批會反覆回頭查的來源（論文、部落格、PDF、網頁），而不是一次性問答。如果你只是偶爾查一份文件，這套目錄結構帶來的維護成本會大於收益。
raw/ 不可變、wiki/ 可編譯的兩層資料流
README 給出的目錄結構是整個設計的核心約束：raw/ 放不可變的來源材料，依主題分目錄，檔名帶日期（例如 raw/topic/2026-04-03-source-article.md）；wiki/ 放模型編譯出來的知識頁，另有兩個特殊檔案，index.md 是全域目錄，log.md 是唯讀追加的操作日誌。
三個操作的資料流因此不同。ingest 把來源收進 raw/、做分流判斷，然後建立或更新 wiki 頁面，若判定沒有新資訊就只寫日誌。query 搜尋 wiki 並附上連回 markdown 頁面的引註。lint 檢查索引完整性、連結與 wiki 健康度，輸出是自動修復加上問題回報。README 特別點出一個機制後果：每個新來源可以同時更新多個頁面、強化交叉引用、記錄矛盾之處，這才是 wiki 會複利的來源。換句話說，寫入路徑是多對多的，一次 ingest 可能改動好幾頁，這也意味著 ingest 之後你應該看 diff。
安裝只有一行，但 Codex 要手動放目錄
主要安裝方式是 npx add-skill Astro-Han/karpathy-llm-wiki。README 的相容性表列出四種情況：Claude Code、Cursor、OpenCode 都用同一行 npx 指令；Codex CLI 不同，要把技能複製到 .agents/skills/karpathy-llm-wiki/；其他工具則是把 SKILL.md、references/ 與 scripts/ 複製進該工具的 skill 目錄。
日常操作不是打 CLI 子命令，而是對 agent 下自然語言指令。README 的 Quick Start 給的例子是「Ingest this article: <URL>」、「What do I know about attention mechanisms?」、「Lint my wiki」。也就是說，真正的介面是 SKILL.md 裡的規則文本，agent 讀完之後自己決定怎麼動檔案。這種設計讓它跨工具，代價是你無法用 shell 腳本精確重現某一次 ingest 的行為。
設計邊界：專案自己列出的不做清單
README 有一段少見的坦白，列出刻意不做的功能，理由是三個月的生產日誌加上對生態系的調查（LLM Wiki v2、llm-wiki-compiler、OKF、agent-memory 文獻）。幾項值得單獨看。
不做來源雜湊的新鮮度追蹤，理由是 raw/ 不可變，雜湊防的是不可能發生的事件。不做持久化的行號引註，理由是實際觀察到的保真度錯誤全都是「值不存在於來源」，而整檔 grep 就能抓到；錨點只在另一種尚未發生的失敗模式裡有用，而且標註摩擦會讓 agent 直接跳過規則。不做數值化的信心分數或品質分數，理由是沒有校準的假精確，證據強度應該寫在散文裡。不做每篇文章的審閱日期，理由是編譯時無法預測各領域變化速度，維護由整庫 lint 驅動。另外還排除存取次數衰減、撤稿機制、自動 hook 與排程、向量或圖搜尋、型別化關係本體、以及 OKF 相容。
向量搜尋那條附帶一個具體門檻：在 5 萬到 10 萬 token 的策展 wiki 規模下，grep 加閱讀比檢索工具更可靠，等召回率可量測地退化再加。這個判斷有前提，超過那個規模就未必成立。
與 RAG 的差異在合成時機，不在模型好壞
README 的對照表把兩者差異放在三個維度：知識存放位置、合成發生時機、適合的場景。RAG 的知識活在原始切塊與嵌入向量裡，合成發生在查詢時，適合大型語料的廣召回。LLM wiki 的知識活在策展過的 markdown 頁面，合成發生在 ingest 與維護期間，適合會複利的知識、摘要與耐久交叉連結。
差別不在檢索品質，在錯誤發生的時間點。RAG 的合成錯誤在查詢當下產生，你看完答案就過去了；wiki 的合成錯誤在 ingest 時寫進頁面，會留在檔案裡被後續查詢引用。這是採用前最該想清楚的一點：這個工具把品質責任前移到寫入階段，而寫入是模型做的。它換來的是查詢時不必重推關係，代價是你得在 ingest 之後真的去看改了什麼。
維護成本與授權
維護負擔集中在 lint。README 說每篇文章的審閱日期刻意不做，維護由整庫 lint 驅動，所以定期跑一次 lint 是這個工作流程的實際節奏。lint 會自動修復並回報問題，這代表它會改動 wiki/ 底下的檔案，把 wiki/ 納入版本控制是合理做法，否則自動修復的結果無法回溯。
授權是 MIT，寬鬆，可商用、可修改、可再散布，只需保留著作權與授權聲明。這不是法律意見，實際使用前仍應自行確認條款。至於升級成本，README 沒有提供任何 release 資訊，也查不到 release 記錄，所以無法評估版本演進帶來的破壞性變更風險。你能掌握的只有 SKILL.md 這份規格本身，升級前先讀它的 diff 是唯一可靠的做法。
另外要提醒一點：README 引用的使用數據（94 篇文章、13 個主題目錄、99 份來源、7 天內 87 筆操作日誌）來自作者自述的單一知識庫，README 沒有說明這是誰的庫、如何統計，無法作為品質或成熟度的證據。把它當成工作流程可行性的描述，不要當成評測結果。
編輯結論
如果你已經有一批會反覆回頭查的來源材料，而且願意讓模型直接改寫 wiki/ 底下的 markdown，這個技能值得裝起來試一輪 ingest 加一次 lint。若你的需求是對大型語料做廣召回檢索，或你必須對每一條引註做行號級追溯，它明確不是為這兩件事設計的。動手前先確認三件事：你的 agent 工具是否支援 agentskills.io 標準、SKILL.md 對 ingest 與 lint 的具體規則寫到什麼程度、以及 wiki/ 是否納入版本控制，因為 lint 會自動改檔。
社群筆記