前言
關於如何有效整理屬於自己的知識庫（Knowledge Base），我可是嘗試了許多種方法與工具。從早期講究以文件資料夾如何分類、到使用 PARA 方法論只簡化為四個主目錄（Project, Area, Resource, Archive），但在實務應用上仍覺得不太順手。
其實原因在哪裡？我覺得先釐清所要整理的素材有相當的關係。我發現自己真正花時間整理的，並不是日常筆記，也不是既有的工作文件，而是在研究某個主題時，所收集的大量素材——包含文章、影片、PDF 等。接著再進行閱讀、分析、彙整、摘要，甚至進一步實作或撰寫成文章。
如果是一次性的短期研究素材倒也還好，消化完即丟棄。這類情境下使用如 NotebookLM 或 ChatGPT Project 或 Gemini Gems 等，將資料集中後交由 AI 進行分析與整理，其實已經相當足夠。
但當研究主題變得長期且持續擴展時，情況就完全不同：
- 研究範圍廣泛
- 參考資料數量龐大
- 新資料會不斷加入
- 舊結論需要反覆修正
在這種情境下，建立「屬於自己的本地知識庫」就變得必要。而真正的挑戰，不再只是分類，而是：
如何有效整合知識，以及如何快速定位可用的資訊。
恰好在這個月初（4/3），AI 大佬 Karpathy 在他的 X 社群上貼了這篇：「LLM Knowledge Bases」，分享他如何使用 LLM 建立各種研究主題的個人知識庫（Personal Knowledge Bases）。這套方法論一經發表，便如往常般引發廣泛關注；除了大量轉傳分享外，也有許多知識工作者（包括我）已開始著手實踐。
這套方法有幾個關鍵特點：
- 不依賴複雜的 RAG 架構
- 使用極簡工具（如 Obsidian）
- 搭配 LLM（Claude Code、Codex、Gemini 等）
- 將原始素材「編譯」為具備摘要與雙向連結的 Wiki
- 並以 LLM 作為查詢與推理界面
Karpathy 這套方法透過簡單的工具組合，將原本複雜的知識庫建構流程轉化為個人與小型團隊可行的實踐方式，這也正是我所需要的。
Karpathy LLM Wiki 方法論總覽
Karpathy 隨後在其 Gist〈LLM Wiki〉中，補充了一份較為完整的架構設計筆記。
其核心觀點在於：將原始資料（文章、PDF、影片等）與最終使用之間，加入一層由 LLM 維護的 Wiki。
知識不再每次查詢時從原始資料重新拼接，而是先被整理、整合，並持續累積在 Wiki 中。
整體而言，這套方法可視為一種知識處理流程的轉換：
- 原始資料（Raw sources）作為輸入來源
- Wiki 作為主要知識介面
- LLM 負責整理、更新與維護內容
在此基礎上，Karpathy 進一步將其做法拆分為結構與流程兩個層面，使系統得以持續演化，而非一次性整理完成。
這裡就依其內容，分為三個面向進行解析與說明。
一、核心構想：從文件檢索轉向持續累積的 Wiki
在傳統做法中，原始資料通常直接作為查詢來源；但在這套方法中，這些資料被視為輸入，而非最終知識。
透過 LLM 處理後，內容會被整理為具備結構的 Wiki 頁面，包含主題、摘要與關聯連結。
查詢時，優先基於這些已整理的頁面，而非直接回到原始資料進行檢索。
當新的資料加入時，LLM 並不是單純產出摘要，而是會：
- 更新既有主題頁面
- 補充相關概念
- 修正或調整原有內容
知識因此不再是分散的文件集合，而是逐步累積與演化的整體。
二、系統設計：三層架構與三種操作流程
為了讓知識系統具備穩定結構，Karpathy 將其設計拆分為三個層次：
三層架構
- Raw sources
- 原始資料來源（文章、PDF、影片等）
- 保持不變，作為事實依據 - Wiki
- 由 LLM 維護的知識頁面
- 包含摘要、主題與交叉連結 - Schema
- 定義操作規範與行為方式
- 指導 LLM 如何進行處理
三種操作流程
- Ingest
- 將新資料整合進既有 Wiki
- 可能同時更新多個相關頁面 - Query
- 從 Wiki 查詢並生成回答
- 查詢結果可再回寫為新知識 - Lint
- 定期檢查內容品質
- 包含矛盾、過時資訊與缺漏補強
透過這三種操作，Wiki 不斷被更新與修正，形成可持續演化的知識結構。
三、維運關鍵：索引、記錄與持續整理
在實際運作上，Karpathy 特別強調幾個維持系統穩定的關鍵要素。
首先是索引與記錄：
- `index.md` 作為知識導覽入口，用於快速定位主題與頁面
- `log.md` 記錄 ingest、query、lint 等操作，追蹤系統演化過程
其次是維持低複雜度設計：
- 在資料規模尚小時，不依賴複雜的 RAG 或 embedding 系統
- 以簡單結構優先，避免過早引入額外工具
最後是工具的彈性使用：
- 可搭配 Obsidian、Web Clipper、CLI 工具等
- 但這些皆為輔助，而非必要條件
整體而言，這套方法並不強調工具本身，而是透過明確的結構與流程，使知識整理能持續進行，而非一次性完成。
後續實踐
理解 Karpathy 所提出的 LLM Wiki 方法論後，下一步即是落實為可運作的知識系統。
我將分為兩個階段，逐步說明實際建置與優化的方式：
一、基礎建置：以最少工具快速建立可運作流程
在基礎建置階段，重點不在於工具堆疊，而在於先建立一套可運作的最小流程（Minimum Viable Workflow）。
此階段將採用：
- Obsidian 作為 Wiki 知識載體
- Obsidian Web Clipper（Browser extension）作為資料收集工具
- LLM（Codex 或 Claude Code）負責內容整理與結構化
並透過行為規範檔（如 `AGENTS.md` 或 `CLAUDE.md`），明確定義：
- 如何 ingest 原始資料
- 如何更新 Wiki 結構
- 如何維持內容一致性
目標是在最少工具的前提下，快速建立從「資料收集 → 知識萃取 → 結構化輸出」的基本流程。
二、進階優化：導入 Skill 與工具鏈強化系統能力
當知識庫規模逐步擴大後，單純依賴手動規範與基本流程，將逐漸面臨效率與一致性的挑戰。
在進階階段，將導入既有的工具與設計，以提升整體系統的可維運性與效能。
主要包含：
- 採用現有的 Obsidian Wiki專案（目前我看到把 llm-wiki 核心理論具體化為 skill 的最完善的專案）
- 並搭配其所建議的延伸工具，例如：
- obsidian-skills（定義可重用的提示與操作流程，強化 LLM 在 Obsidian 內的行為一致性）
- qmd（提供本地 Markdown 知識庫的快速搜尋與索引能力，作為查詢輔助工具）
透過這些工具的導入，可達成：
- 更有效的文件組織與知識連結
- 自動化程度的提升
- 查詢與處理效率的優化
- 面對大量資料時的系統穩定性
整體而言，這兩個階段分別對應：
- 基礎建置：建立可運作的知識流程
- 進階優化：強化系統能力與擴展性
後續將依序針對這兩個部分，進行實作層面的詳細說明。