動手建你的第一個 LLM Wiki

與其讀十篇「知識管理方法論」，不如花 30 分鐘真的建一個。

課程目標

從零開始建立一個可運作的 LLM Wiki 資料夾結構
寫出你的第一份 Schema（規則設定檔）
完成第一次 Ingest，看到 AI 幫你產出結構化的知識頁面
理解 Schema 設計的關鍵決策點

一、準備工作：你需要什麼？

必備：

一個 AI 對話工具（Claude、ChatGPT、Gemini 都行）
電腦上的一個空資料夾

推薦但非必要：

Obsidian（免費）— 可以即時看到 Markdown 檔案之間的連結關係
一篇你最近讀過、覺得有價值的文章

不需要會寫程式。整個過程都是跟 AI 對話 + 把檔案存到資料夾。

二、建立資料夾結構

在你的電腦上建立以下資料夾：

my-knowledge-base/
├── raw/                ← 原始資料（你收集的文章、筆記）
├── wiki/               ← AI 編譯的知識庫
│   ├── sources/        ← 每篇原始資料的摘要頁
│   ├── concepts/       ← 重要概念各一頁
│   ├── entities/       ← 重要的人、公司、工具各一頁
│   ├── comparisons/    ← 比較分析頁
│   ├── index.md        ← 全局目錄
│   └── log.md          ← 操作紀錄
└── schema.md           ← 規則設定檔

為什麼這樣分？

資料夾	作用	誰來寫
`raw/`	保存原始資料，當作「事實來源」	你（收集資料）
`wiki/sources/`	每篇原始資料的重點摘要	AI
`wiki/concepts/`	跨多篇文章的概念整理	AI
`wiki/entities/`	人物、公司、工具的資訊卡	AI
`wiki/comparisons/`	A vs B 的比較分析	AI（你問問題時產生）
`schema.md`	告訴 AI 怎麼維護 Wiki	你 + AI 一起演化

記住核心原則：raw/ 你管，wiki/ AI 管，schema.md 你們一起管。

三、寫你的第一份 Schema

Schema 是整個 LLM Wiki 的靈魂。它告訴 AI：「你是這個知識庫的管理員，這是你的工作手冊。」

最小可行 Schema

把以下內容存成 schema.md：

# 知識庫 Schema

## 這個知識庫是關於什麼的
[你的主題，例如：電商 AI 應用 / 數位行銷趨勢 / 產品管理方法論]

## 資料夾結構
- raw/：原始資料，只讀不改
- wiki/sources/：每篇原始資料的摘要（一篇一頁）
- wiki/concepts/：跨文章的重要概念（一個概念一頁）
- wiki/entities/：重要的人、公司、工具（一個實體一頁）
- wiki/comparisons/：比較分析
- wiki/index.md：全局目錄
- wiki/log.md：操作紀錄

## Ingest 流程（收到新資料時）
1. 讀完整篇原始資料
2. 在 wiki/sources/ 建立摘要頁，包含：標題、來源、日期、三句話摘要、關鍵重點（3-5 點）
3. 檢查有沒有新概念需要建立 wiki/concepts/ 頁面
4. 檢查有沒有新實體需要建立 wiki/entities/ 頁面
5. 如果新資料跟既有頁面相關，更新那些頁面（加入新資訊或標註矛盾）
6. 更新 wiki/index.md（加入新頁面的連結和一行摘要）
7. 在 wiki/log.md 記錄本次操作

## Query 流程（回答問題時）
1. 先讀 wiki/index.md 找到相關頁面
2. 讀取相關頁面後綜合回答
3. 如果回答有價值，建議存成新頁面

## 命名規則
- 檔名：英文小寫 + 連字號（例：llm-wiki.md）
- 每頁開頭：# 標題
- 跨頁引用：用 Markdown 連結 [頁面名稱](相對路徑)

## 語言
- 所有 Wiki 頁面用繁體中文撰寫

Schema 設計的三個關鍵決策

決策 1：知識庫的範圍

「這個知識庫是關於什麼的」這一行很重要。範圍太大（「所有我感興趣的事」），AI 不知道什麼該深入、什麼該略過。範圍太小（「只有 Python 語法」），很快就沒東西可加。

好的範圍範例：

✅ 「電商產業的 AI 應用案例與技術選型」
✅ 「我的團隊在用的行銷工具評比與最佳實踐」
❌ 「所有科技新聞」（太廣）
❌ 「ChatGPT prompt 範本」（太窄，而且會過時很快）

決策 2：摘要的詳細程度

Schema 裡的「三句話摘要 + 3-5 個關鍵重點」是起點。你可以根據需要調整：

學術研究型：加上方法論、數據、局限性
商業應用型：加上 ROI、適用場景、風險
個人學習型：加上「我的心得」、「跟之前讀的 X 的關聯」

決策 3：什麼值得建立概念頁 / 實體頁

不是每個名詞都需要獨立頁面。經驗法則：被兩篇以上 source 提到的概念或實體，就值得獨立一頁。

四、完成第一次 Ingest

Step 1：準備一篇原始資料

把一篇你最近讀過的文章存成 Markdown 或純文字，放進 raw/ 資料夾。

沒有現成的？用這段範例文字：

標題：91APP 用 AI 做商品推薦的經驗分享
來源：假設的案例文章
日期：2026-04

91APP 在 2025 年底開始導入 AI 商品推薦系統。原本的推薦邏輯是基於規則（購買 A 的人也買了 B），
改為使用機器學習模型分析用戶行為。導入後，商品頁的點擊率提升 23%，但退貨率也上升了 5%。

團隊發現退貨率上升的原因是 AI 推薦了「看起來相關但實際上不符需求」的商品。
後來加入了「退貨原因回饋」作為模型的負面信號，退貨率回降到原本水準。

技術棧使用 Google Cloud Vertex AI + BigQuery，部署在 Cloud Run 上。
推薦模型每週重新訓練一次，使用過去 90 天的行為數據。

Step 2：把 Schema + 原始資料餵給 AI

打開你的 AI 工具，貼上以下 prompt：

我要建立一個 LLM 知識庫。以下是我的 Schema（規則設定檔）和一篇新的原始資料。

請按照 Schema 的 Ingest 流程，幫我產出所有需要建立或更新的 Wiki 頁面。

每個檔案用 --- 分隔，開頭標明檔案路徑。

[貼上你的 schema.md]

[貼上你的原始資料]

Step 3：檢查 AI 產出的結果

AI 應該會產出類似這樣的檔案：

wiki/sources/91app-ai-recommendation.md — 文章摘要 wiki/concepts/ai-recommendation.md — AI 商品推薦概念頁 wiki/entities/91app.md — 91APP 實體頁 wiki/entities/vertex-ai.md — Vertex AI 實體頁 wiki/index.md — 更新後的目錄 wiki/log.md — 操作紀錄

一篇文章觸及了 6 個檔案——這就是「編譯」的威力。如果你只是存書籤，這些交叉引用永遠不會出現。

Step 4：存檔

把 AI 產出的每個檔案存到對應的資料夾。如果你用 Obsidian，馬上就能看到頁面之間的連結圖。

五、Schema 會長大

你的 Schema 不是寫一次就定案的。隨著你 ingest 更多資料，你會發現：

「我需要多一個 wiki/tools/ 資料夾來放工具評比」
「摘要格式應該加上『適用場景』欄位」
「概念頁應該要有『相關概念』區塊」

這很正常。 Schema 就像程式碼——你和 AI 一起迭代。每次你覺得「這裡可以更好」，就更新 Schema，然後讓 AI 按新規則處理後續的資料。

Karpathy 自己也說：Schema 是你和 AI「共同演化」的文件。不要追求一開始就完美，先跑起來再說。

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

建立 Wiki 的過程本身就是在訓練你「怎麼跟 AI 協作」——你定方向和規則，AI 做繁瑣的整理工作。

你的人類優勢：

你決定什麼資料值得收進知識庫——AI 不知道你的工作優先順序
你能看出 AI 的摘要有沒有抓到重點——因為你讀過原文、有業務直覺

可以這樣跟 AI 說：

你漏掉了一個重點：這篇文章最有價值的不是技術細節，而是「退貨回饋當負面信號」這個做法。請在摘要和概念頁中強調這點。

小練習

本課重點回顧

資料夾結構：raw/（你管）、wiki/（AI 管）、schema.md（一起管）
Schema 是 LLM Wiki 的靈魂：它把 AI 從「通用聊天機器人」變成「你的知識庫管理員」
三個關鍵設計決策：知識庫範圍、摘要詳細度、何時建立獨立頁面
一篇文章的 Ingest 會觸及多個檔案：這就是「編譯」vs「存書籤」的差別
Schema 會演化：先跑起來，再根據實際使用調整