兩種管理知識的方式——為什麼其中一種不夠用
大多數 AI 實踐者今天都面對同一個困境：你收集了大量筆記、文章和文件，每次需要答案時，你把相關內容貼入 AI 對話，得到一個好答案，然後關掉視窗。第二天，你重新貼入。這個循環不斷重複。
RAG（檢索增強生成）本來是解決這個問題的方案，但它有一個結構性缺陷：每次查詢都從零開始。系統找出相關片段，交給模型冷處理，但模型無法記住上週建立的連接，也無法自動整合跨越 50 份文件的規律，除非你明確要求。你的知識庫在體積上增長，但理解深度沒有積累。
2026 年 4 月，OpenAI 聯合創始人 Andrej Karpathy 在 GitHub 發布了一個名為「LLM Wiki」的方案，描述了一種根本不同的方法：不是你向 AI 查詢知識，而是 AI 幫你維護知識庫。AI 讀取你的原始資料，提取概念，撰寫結構化文章，建立概念之間的反向連結，並在新資料到來時自動更新。
Karpathy 自己的研究 Wiki 目前包含約 100 篇文章、40 萬個字——相當於 4 本完整長篇小說——完全由 Claude 建立。與同等規模的 RAG 系統相比，查詢效率提升約 70 倍，因為知識整合的工作只需進行一次，而非每次查詢都重複。
什麼是 LLM Wiki？核心概念解釋
LLM Wiki 是一個讓 AI 代理人代你維護個人知識庫的框架。你提供原始資料，AI 讀取資料、提取概念、撰寫結構化文章，並在文章之間建立連結。你只需閱讀最終的 Wiki，無需手動整理。
這個模式解決的是「擁有資訊」與「擁有理解」之間的鴻溝。RAG 幫你找回資訊，LLM Wiki 則讓模型對你的材料進行深度思考，並將思考結果永久保存在一個不斷成長的 Markdown 目錄中。
關鍵洞察在於：大型語言模型本來就擅長摘要、概念提取和關係推理。LLM Wiki 只是給了它們一個永久存放這些思考成果的地方，讓它們隨時間積累，而不是在每次對話結束後被丟棄。
三層架構：實際運作原理
LLM Wiki 由三個協同運作的組件構成。在設置之前，理解每個組件至關重要。
第一層——原始資料（不可變）：這是你的輸入資料夾。將 PDF、文章、會議記錄、研究論文等任何你想讓 AI 學習的內容放入其中。這個資料夾只增不減，你永遠不直接編輯它。
第二層——Wiki（由 AI 維護）：這是一個包含概念文章、摘要、時間軸、詞彙表的 Markdown 文件目錄，完全由 AI 創建和更新。每篇文章都有前置資訊（標題、日期、標籤）並在末尾列出相關 Wiki 條目的反向連結。你從這一層閱讀，永遠不手動寫入。
第三層——架構文件（配置）：這是一個名為 CLAUDE.md 或 AGENT.md 的配置文件，告訴你的 AI 代理人如何運行 Wiki。它指定資料夾結構、文章格式、如何處理新資料文件，以及新資料到來時如何更新現有條目。這是你唯一需要自己撰寫的文件。
架構文件讓整個系統可重複執行。每次你添加新資料並運行代理人時，它會讀取架構、知道該做什麼，並輸出符合現有 Wiki 結構的內容。
30 分鐘內建立你的 LLM Wiki
你不需要是開發者才能運行這個模式。Claude Code 或任何具備文件訪問能力的代理人設置都可以處理所有實際工作。
第一步：創建三個資料夾：sources/、wiki/，以及根目錄下的 CLAUDE.md。
第二步：撰寫你的 CLAUDE.md 架構文件。下方有完整的入門模板可以直接複製。
第三步：將前 5–10 份文件放入 sources/。從同一主題的材料開始——你已閱讀的文章、某個項目的研究資料，任何你想讓 AI 整合的內容。
第四步：運行代理人。在 Claude Code 中，將其指向你的項目資料夾，並給出指令：「依照 CLAUDE.md 架構處理 sources/ 中的所有新文件。」代理人會讀取每個文件，提取概念，並撰寫新的 Wiki 文章或更新現有條目。
第五步：隨時間持續添加新材料。當你遇到新資料時，放入 sources/ 並重新運行代理人，Wiki 會自動成長和深化。
處理 10 份文件的首次 Wiki 運行通常需要 5–10 分鐘。此後，針對新文件的增量運行不到 2 分鐘。
架構提示：複製這個模板開始使用
這是你的 LLM Wiki 設置中最關鍵的文件。以下是完整的入門 CLAUDE.md 模板：
立即嘗試這個提示（貼入你的 CLAUDE.md 文件）：
--- CLAUDE.md 開始 ---
你是 wiki/ 目錄中個人知識庫的維護者。當我要求你「處理資料」時，請嚴格按以下步驟執行：
1. 檢查 sources/ 中尚未處理的文件（與 wiki/processed-log.md 比對）。
2. 對每個未處理文件，仔細閱讀全部內容。
3. 從文件中提取 3–7 個關鍵概念或發現。
4. 對每個概念：檢查是否已有 Wiki 文章。若有，用新資訊更新；若無，在 wiki/ 中創建新 Markdown 文件，格式如下：
- 前置資訊：標題、日期、標籤、來源文件
- 摘要段落（100 字以內）
- 要點列表
- 詳細說明（依需要的段落數）
- 相關概念（使用 [[wiki-文件名]] 格式連結至其他 Wiki 文章）
5. 處理完所有文件後，更新 wiki/index.md，列出所有 Wiki 文章及其一句話描述。
6. 將已處理的文件名添加到 wiki/processed-log.md。
永遠不要刪除現有 Wiki 文章。當新資訊與現有內容矛盾時，添加「觀點分歧」章節，而非替換原內容。
--- CLAUDE.md 結束 ---
根據你的領域調整架構。如果你的 Wiki 涵蓋特定行業，請添加關於術語慣例或相關文章分類的說明。
LLM Wiki 比 RAG 更有優勢的地方
LLM Wiki 與 RAG 的比較不在於哪個更聰明，而在於你需要哪種知識工作。RAG 擅長檢索：「找到關於 X 的部分。」LLM Wiki 擅長整合：「根據我所有資料，X 和 Y 的關係是什麼？」
RAG 按需檢索片段並進行組合，每次查詢都從零開始。LLM Wiki 中，整合工作已經完成。Wiki 文章包含預先建立的理解——概念已被定義、比較和連結。查詢一個成熟的 LLM Wiki，就像請教一位擁有十年精心整理筆記的專家，而不是讓人去搜索文件櫃。
LLM Wiki 還能自然處理跨文件整合。如果你有 20 篇文章從不同角度討論同一個概念，Wiki 會建立一篇包含所有觀點的權威文章——這是 RAG 在沒有專門工程設計的情況下無法做到的。懂AI，更懂你 UD相伴，AI不冷。
常見錯誤及如何避免
最常見的錯誤是一次性將太多不相關的資料放入 Wiki。如果你的資料跨越五個不同領域，AI 會生成一個龐雜混亂的 Wiki，缺乏清晰的組織邏輯。從聚焦的主題開始——一個項目、一個研究方向、一項你正在培養的技能。聚焦在單一主題上的 20 篇文章，遠比涵蓋所有主題的 200 篇混亂文章更有用。
第二個錯誤是架構文件過於模糊。如果你的 CLAUDE.md 沒有明確定義文章的結構——包括前置資訊欄位、章節結構和反向連結格式——代理人會自由發揮。早期文章可能與後期文章格式不一，你需要花時間整理格式，而非閱讀知識。
第三：不要跳過處理記錄。沒有代理人已處理文件的記錄，每次運行都會重新處理所有內容，產生重複文章並浪費 API 費用。處理記錄只需 5 分鐘設置，卻能節省數小時的後期清理工作。
立即嘗試：本週建立你的第一個 LLM Wiki
選擇一個你正在積極研究的主題——一個產品類別、一項技能領域，或一個進行中的項目。收集 10 份你已閱讀或保存的資料。創建三層資料夾結構，貼入本文的 CLAUDE.md 架構，然後運行代理人。
你的第一個 Wiki 會比較粗糙，第二次運行（添加更多資料後）會更好。當你處理了 30 份資料後，你將擁有一個真正反映你對某個領域思考方式的知識資源——完全由 AI 維護，隨時可查詢，並隨每份新文件的加入而變得更智能。
準備好測試你的 AI 知識水平了嗎？
掌握 LLM Wiki 這類技術，是真正深度使用 AI 的實踐者與普通用戶的分水嶺。UD 團隊手把手帶你完成每一步——從選擇適合你工作流程的工具，到建立隨時間複利增長的 AI 系統。
