第 1 / 4 課

正在準備工作環境...

LLM Wiki：讓 AI 幫你蓋知識庫

你讀過的文章、存過的書籤、做過的筆記——三個月後還找得到嗎？

課程目標

理解傳統 RAG 知識庫的限制，以及為什麼「每次查都重來」不是好策略
掌握 Karpathy 提出的「LLM Wiki」模式：讓 AI 持續編譯、維護一個結構化知識庫
學會規劃自己的 Raw → Wiki → Query 工作流
動手設計一個最小可行的 LLM 知識庫 Schema

一、你的知識庫，現在長什麼樣？

先想一下你現在怎麼管理工作知識：

瀏覽器書籤存了 200 個，但從來不回去看
Notion / Google Docs 裡有一堆筆記，但搜尋不到想要的那段
問 ChatGPT 時每次都要重新解釋背景
明明讀過相關文章，但要用的時候想不起來在哪裡

問題不是「你沒有在學習」，而是「學到的東西沒有累積起來」。

這就像一家電商每天都有客戶回饋進來，但從來沒有人整理成報告——資料很多，洞察為零。

二、RAG：目前最常見的做法，以及它的天花板

如果你用過 ChatGPT 的檔案上傳、NotebookLM、或任何「上傳文件問 AI」的工具，你已經在用 RAG（Retrieval-Augmented Generation） 了。

RAG 怎麼運作？

你的問題 → AI 去你上傳的文件裡搜尋相關段落 → 把找到的段落當背景 → 產生回答

就像你問一個實習生：「幫我查一下上季度退貨原因。」他翻了三份報告，找到幾段相關的，拼湊出一個答案。

RAG 的問題

每次查，都在重新發現知識。

情境	RAG 的表現
問「A 報告說了什麼？」	✅ 找得到，回答不錯
問「A 和 B 報告的結論有沒有矛盾？」	⚠️ 要同時找到兩份的關鍵段落，容易漏
問「根據過去 10 份報告，這個趨勢的變化是什麼？」	❌ 幾乎不可能，因為它每次只抓幾段

RAG 就像一個每天到職的實習生——他不記得昨天做過什麼。你每次問他，他都要從頭翻資料。

Karpathy（前 Tesla AI 主管、OpenAI 創始成員）在 2026 年 4 月公開說：「我原本以為需要搞複雜的 RAG，但後來發現讓 LLM 自己維護 index 檔案就夠了。」

三、LLM Wiki：讓 AI 當你的知識庫管理員

Karpathy 提出的做法完全不同。

不是每次查詢都去翻原始文件，而是讓 AI 事先讀完、整理好、持續更新一個結構化的 Wiki。

三層架構

┌─────────────────────────────────┐
│  你（人類）                       │
│  策展、提問、判斷                  │
└───────────┬─────────────────────┘
            │ 讀取 & 查詢
┌───────────▼─────────────────────┐
│  Wiki（AI 編譯的知識庫）          │
│  結構化 Markdown：摘要、實體頁、   │
│  概念頁、索引、交叉引用            │
└───────────┬─────────────────────┘
            │ AI 讀取 & 整合
┌───────────▼─────────────────────┐
│  Raw Sources（原始資料）          │
│  文章、報告、筆記、對話紀錄        │
│  不可變，只讀                     │
└─────────────────────────────────┘

Raw Sources（原始資料）：你收集的所有資料。文章、PDF、會議紀錄、聊天記錄。這一層是「事實來源」，AI 只能讀不能改。

Wiki（編譯後知識庫）：AI 產生並維護的 Markdown 檔案。包含摘要頁、實體頁（人物、公司、產品）、概念頁（技術、趨勢）、比較表、總覽。這一層完全由 AI 寫和維護，你只需要看。

Schema（規則設定檔）：告訴 AI「這個 Wiki 的結構長什麼樣、命名規則是什麼、遇到新資料該怎麼處理」的設定檔。你和 AI 一起演化這份文件。

用電商的比喻來說

層	電商對照
Raw Sources	客戶評論原始資料、客服對話記錄、退貨表單
Wiki	產品改善報告、客訴趨勢分析、競品比較表
Schema	報告模板、分類規則、更新頻率設定

你不會讓分析師每次被問到「客戶最常抱怨什麼」時，都從頭翻幾千筆客服記錄吧？你會讓他整理一份持續更新的報告。LLM Wiki 就是讓 AI 幫你做這件事。

四、三個核心操作：Ingest、Query、Lint

Ingest（吃進新資料）

你拿到一篇新文章或新報告，丟給 AI，它會：

讀完整篇內容
寫一頁摘要放進 Wiki
更新索引（index）
檢查 Wiki 裡有沒有相關的實體頁或概念頁，有的話就更新
如果新資料跟舊知識矛盾，標註出來

一個新 source 可能觸及 5-15 頁 Wiki 的更新。 這就是「編譯」——不是存進去就好，而是整合進既有知識網路。

Query（查詢知識庫）

你對 Wiki 提問，AI 搜尋相關頁面、綜合回答。

關鍵差異：好的回答可以寫回 Wiki 成為新頁面。

比如你問：「A 技術和 B 技術在我們的場景下，哪個比較適合？」AI 產出一份比較分析。這份分析本身就是有價值的知識——存進 Wiki，下次你或同事再問類似問題，直接有現成答案。

知識因此產生複利效應。

Lint（健康檢查）

定期讓 AI 掃描整個 Wiki，找出：

矛盾：A 頁說市場在成長，B 頁說在萎縮
過時資訊：引用的數據已經有更新的版本
孤立頁面：沒有任何其他頁面連結到它（可能是遺忘的知識）
知識缺口：多個頁面都提到某個概念，但沒有專門的概念頁

Lint 就像程式碼的 code review——讓知識庫保持健康。

五、兩個重要的導航檔案

隨著 Wiki 長大，你需要兩個特殊檔案幫助導航：

index.md（目錄）

內容導向的全局索引。每個 Wiki 頁面一行，包含連結、一句摘要、metadata。

## 概念頁
- [RAG](concepts/rag.md) — 檢索增強生成，適合即時查詢但不累積知識
- [向量搜尋](concepts/vector-search.md) — 用語意相似度找資料的技術

## 實體頁
- [Karpathy](entities/karpathy.md) — 前 Tesla AI 主管，LLM Wiki 概念提出者
- [Obsidian](entities/obsidian.md) — Markdown 知識庫工具，適合當 Wiki 前端

## 來源摘要
- [2024-Q3 客戶滿意度報告](sources/2024-q3-csat.md) — 滿意度 82%，主要抱怨出貨速度

AI 回答問題前先讀 index，就知道去哪裡找相關頁面。簡單但有效。

log.md（操作紀錄）

時間序的 append-only 紀錄，記錄每次操作：

## [2026-04-07] ingest | Classmethod LLM Wiki 實作分享
- 新增來源摘要頁 sources/classmethod-llm-wiki.md
- 更新概念頁 concepts/rag.md（新增「編譯式 vs 檢索式」段落）
- 更新實體頁 entities/karpathy.md（新增 Claude Code 實作案例）

## [2026-04-06] query | RAG vs LLM Wiki 比較
- 產出比較表 wiki/comparisons/rag-vs-llm-wiki.md
- 結論：個人規模用 LLM Wiki，企業規模混合使用

有了 log，你隨時知道知識庫「最近發生了什麼事」。

六、實際怎麼開始？最小可行方案

你不需要寫程式。用你現有的 AI 工具就能開始。

Step 1：建立資料夾結構

在你的電腦上（或 Obsidian vault 裡）建立：

my-wiki/
├── raw/          ← 原始資料（文章、筆記、PDF）
├── wiki/         ← AI 編譯的知識庫
│   ├── index.md
│   ├── log.md
│   ├── concepts/
│   ├── entities/
│   └── sources/
└── schema.md     ← 規則設定檔

Step 2：寫你的 Schema

Schema 是告訴 AI「怎麼維護這個 Wiki」的說明書。一個最小版本：

# 我的知識庫 Schema

## 結構
- sources/：每個原始資料一頁摘要
- concepts/：重要概念各一頁
- entities/：重要的人、公司、工具各一頁
- index.md：全局目錄，每頁一行摘要
- log.md：操作紀錄，每次 ingest/query 都記錄

## Ingest 流程
1. 讀完原始資料
2. 寫一頁摘要到 sources/
3. 如果提到新概念，建立 concepts/ 頁面
4. 如果提到新實體，建立 entities/ 頁面
5. 更新 index.md
6. 在 log.md 記錄本次操作

## 命名規則
- 檔名用英文小寫 + 連字號（例：llm-wiki.md）
- 每頁開頭用 # 標題
- 跨頁引用用 Markdown 連結

Step 3：做第一次 Ingest

把你的 schema.md 和一篇文章丟給 AI（Claude 或 ChatGPT），告訴它：

請根據 schema.md 的規則，幫我把這篇文章整合進 Wiki。產出所有需要建立或更新的頁面。

AI 會幫你生成 sources/ 摘要、相關的 concepts/ 和 entities/ 頁面、更新後的 index.md 和 log.md。

你只需要看一遍、確認沒問題、存檔。

Step 4：持續餵養

每次讀到好文章：存進 raw/ → 請 AI ingest。每次有好問題：請 AI query → 好答案存回 wiki/。每週一次：請 AI lint → 修正問題。

七、這跟 RAG 是二選一嗎？

不是。2026 年業界的共識是：

知識類型	適合的方式
熱知識（最近在研究的主題）	LLM Wiki 編譯
冷知識（歷史資料、偶爾查）	RAG 檢索
個人/小團隊規模（< 100 篇）	Wiki 優先，RAG 備用
企業/大團隊規模（> 1000 篇）	RAG 主力 + Wiki 作為上層摘要

Karpathy 自己說：大約 100 篇文章、40 萬字以內，LLM Wiki 模式就能運作得很好，不需要複雜的向量資料庫。

而且現在很多模型支援超長上下文（100K-1M tokens），編譯後的 Wiki 甚至可以整包塞進去讓 AI 一次看完——比 RAG 的分段檢索更不容易漏資訊。

AI 協作：學了這個，跟 AI 怎麼配合？

LLM Wiki 本身就是一種 AI 協作模式——你負責策展和判斷，AI 負責整理和維護。

你的人類優勢：

你知道什麼知識對你的工作真正重要——AI 不知道你下週要做什麼決策
你能判斷兩份矛盾資料哪個比較可信——AI 只能標註矛盾，不能替你選邊

可以這樣跟 AI 說：

我要建立一個關於「電商 AI 應用」的個人知識庫。請根據我給你的 schema，幫我把這篇文章整合進 Wiki。重點關注：實際落地案例、ROI 數據、技術選型。理論性的內容簡要帶過就好。

小練習

本課重點回顧

RAG 的限制：每次查詢都從頭來，知識不會累積，跨文件綜合能力差
LLM Wiki 的核心概念：讓 AI 持續編譯、維護一個結構化知識庫，而不是每次都重新檢索
三層架構：Raw Sources（不可變原始資料）→ Wiki（AI 編譯的 Markdown）→ Schema（規則設定檔）
三個操作：Ingest（整合新資料）、Query（查詢 + 回寫）、Lint（健康檢查）
兩個導航檔：index.md（全局目錄）、log.md（操作紀錄）
不是取代 RAG，而是互補：熱知識用 Wiki 編譯，冷知識用 RAG 檢索
維護知識庫最累的是記帳，而 AI 最擅長記帳——這就是為什麼 LLM Wiki 能成功

挑戰任務

Task 1

打開 ChatGPT 或 Claude，把本課「六、實際怎麼開始」段落中的 Schema 範例貼給 AI，然後請它幫你用一篇你最近讀過的文章做第一次 Ingest。觀察 AI 產出了幾個檔案？有沒有建立交叉引用？把你的觀察寫下來。

Task 2

用你剛建好的 Wiki，請 AI 回答一個需要綜合判斷的問題。例如：「根據目前 Wiki 裡的知識，如果我要向老闆提案導入 AI 工具，最有說服力的三個論點是什麼？」然後問自己：這個回答值不值得存回 Wiki？如果值得，請 AI 幫你存成一頁新的 wiki 頁面。寫下你的決定和理由。

Task 3

請 AI 對你的 Wiki 做一次 Lint（健康檢查）：有沒有頁面之間的資訊矛盾？有沒有被提到但還沒有專門頁面的概念？有沒有孤立頁面？有沒有可以加強的交叉引用？即使你的 Wiki 目前很小，也試試看 AI 能找到什麼。把 AI 的發現寫下來。

Next Lesson →