規模化與工具選擇：讓知識庫跟著你成長

10 頁的 Wiki 用記事本就夠了。100 頁的 Wiki 需要好工具。1000 頁的時候，你需要策略。

課程目標

理解 LLM Wiki 在不同規模下的挑戰和對策
認識 Obsidian 生態中可搭配的工具
學會「熱知識 Wiki + 冷知識 RAG」的雙軌策略
了解 LLM Wiki 在團隊場景的應用可能性

一、規模帶來的挑戰

你的 Wiki 從 5 頁長到 50 頁時，一切運作良好。但繼續長大，你會遇到三個問題：

問題 1：AI 讀不完整個 Wiki

當 Wiki 超過幾十頁，你沒辦法每次都把「整個 Wiki + 新文章」一起貼給 AI。

對策：這就是 index.md 的價值。 AI 先讀 index.md（幾十行的目錄），判斷哪些頁面跟當前任務相關，再深入讀那幾頁就好。

就像你不會為了找一個資料把整本百科全書讀完——你會先看目錄。

問題 2：搜尋變慢、找不到

index.md 是人工維護的目錄，適合幾十頁。但到了幾百頁，你需要真正的搜尋功能。

對策：加入搜尋工具。 例如：

Obsidian 內建搜尋：基本的關鍵字搜尋，免費
qmd：本地搜尋引擎，支援關鍵字 + 語意搜尋 + AI 重新排序
自己的 AI 助理搜尋：如果你用 Claude Code 或 ChatGPT，讓它直接搜尋你的 Wiki 資料夾

問題 3：不是所有知識都需要「即時可用」

你三年前讀的一篇文章，可能一年才會被用到一次。為了它維護 Wiki 頁面、更新交叉引用，成本太高。

對策：分「熱」和「冷」。

二、熱知識 Wiki + 冷知識 RAG：雙軌策略

2026 年業界的共識：不是 Wiki 或 RAG 二選一，而是根據知識的「溫度」分開處理。

什麼是熱知識、冷知識？

	熱知識	冷知識
定義	最近在研究、經常使用的知識	歷史資料、偶爾才查的知識
範例	當前專案的技術選型分析	兩年前的市場調查
更新頻率	每週都可能有新資訊	幾乎不變
查詢頻率	每週多次	每季或更少
適合的方式	LLM Wiki（編譯、交叉引用）	RAG（存起來，需要時檢索）

雙軌怎麼運作？

新資料進來
  │
  ├─ 跟當前研究主題相關？
  │   └─→ 🔥 Ingest 進 Wiki（完整編譯 + 交叉引用）
  │
  └─ 是背景資料 / 歷史文件？
      └─→ ❄️ 存進 raw/archive/，需要時再用 AI 搜尋

規模參考

Karpathy 自己的經驗：大約 100 篇文章、40 萬字以內，LLM Wiki 模式運作良好，不需要複雜的基礎設施。

超過這個規模，你可能需要：

搜尋工具（不能只靠 index.md）
分主題的子 Wiki（而不是一個大 Wiki）
定期歸檔（把不再活躍的主題移到 archive）

三、工具生態：Obsidian 和周邊

Obsidian：推薦的 Wiki 瀏覽器

Obsidian 是免費的 Markdown 編輯器，特別適合 LLM Wiki 因為：

圖形視圖（Graph View）：視覺化頁面之間的連結關係，一眼看出哪些知識是中心節點、哪些是孤立的
反向連結（Backlinks）：每頁自動顯示「誰連結到這裡」，是 Lint 找孤立頁面的好幫手
即時預覽：Markdown 即時渲染，看 AI 產出的頁面很方便
完全本地：檔案就在你電腦上，不用擔心隱私

Plugin	作用	適合階段
Dataview	把頁面的 YAML metadata 當資料庫查詢	Wiki > 30 頁後
Templater	頁面模板，確保新頁面格式統一	一開始就可以用
Git	自動備份 Wiki 到 Git repo	一開始就建議裝

Dataview 範例

如果你的 Wiki 頁面有 YAML 前置資料（frontmatter）：

---
type: source
topic: AI 商品推薦
date: 2026-04-07
confidence: high
---

# 91APP AI 推薦經驗分享
...

Dataview 可以動態產生表格：

TABLE topic, date, confidence
FROM "wiki/sources"
WHERE type = "source"
SORT date DESC

這會自動列出所有 source 摘要頁，按日期排序——比手動維護 index.md 更強大。

四、團隊場景：LLM Wiki 不只是個人工具

LLM Wiki 的模式也可以用在團隊：

場景 1：專案知識庫

一個專案的相關資訊散落在 Slack 對話、會議紀錄、email、Notion 文件裡。讓 AI 定期把這些「編譯」成一個結構化的專案 Wiki。

新人加入時，不用翻幾十頁 Slack 歷史——直接看 Wiki 的 overview 頁。

場景 2：競品分析知識庫

行銷團隊持續追蹤競品動態。每篇競品新聞、產品更新、定價變動，都 ingest 進 Wiki。

老闆問「最近競品在做什麼」時，Wiki 裡有現成的、持續更新的綜合分析。

場景 3：客戶洞察知識庫

客服對話、NPS 調查、退貨原因——這些資料很多，但很少被系統性整理。

讓 AI 每週 ingest 一批客服紀錄，維護「常見問題」「客戶痛點趨勢」「產品改善建議」等概念頁。

團隊使用的注意事項

指定維護者：就像程式碼有 code owner，Wiki 需要有人負責審查 AI 的編譯品質
控制 Ingest 品質：不是所有資料都值得 ingest，需要有人篩選
定期 Lint：團隊的知識庫比個人的更容易出現矛盾（不同人提供不同觀點）

五、長期思維：知識庫是你的數位資產

你的 LLM Wiki 是純 Markdown 檔案——不綁定任何工具、不依賴任何雲端服務。

換 AI 工具？ 沒問題，Markdown 誰都能讀
換筆記軟體？ 沒問題，Markdown 是通用格式
十年後？ 這些檔案還是能打開、能搜尋、能讓未來的 AI 繼續維護

這是 RAG 系統做不到的——RAG 的向量資料庫綁定特定工具，換工具就要重建。

維護知識庫最累的是記帳工作——交叉引用、一致性管理、格式統一。人類會放棄，AI 不會。這就是 LLM Wiki 能成功的根本原因。

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

規模化的關鍵是讓 AI 承擔更多日常維護，你專注在高價值決策。

你的人類優勢：

你決定什麼是「熱知識」、什麼可以歸檔——AI 不知道你下個月的工作重點
你判斷團隊知識庫裡哪些觀點需要保留、哪些已經過時——這需要業務判斷力

可以這樣跟 AI 說：

我的知識庫已經有 60 頁了。請幫我分析一下：哪些主題的頁面最多（熱區）？哪些頁面超過三個月沒有被更新或引用（可能的冷區）？我想把冷區的頁面歸檔，讓 Wiki 保持精簡。

小練習

本課重點回顧

規模帶來三個挑戰：AI 讀不完、搜尋變慢、不是所有知識都需要即時可用
雙軌策略：熱知識用 Wiki 編譯，冷知識用 RAG 或歸檔
100 篇 / 40 萬字是舒適區：超過就需要搜尋工具和分區策略
Obsidian 是推薦的瀏覽器：Graph View + Backlinks + 完全本地
Wiki 是純 Markdown：不綁工具、不綁服務、十年後還能用
團隊也能用：但需要指定維護者、控制 Ingest 品質、定期 Lint

課程總結

四堂課下來，你學到了：

概念：RAG 的限制 → LLM Wiki 的「編譯式知識庫」模式
動手：資料夾結構 + Schema + 第一次 Ingest
進階：Query 回寫（知識複利）+ Lint（自我修正）
規模化：雙軌策略 + 工具選擇 + 團隊應用

最重要的一句話：維護知識庫最累的是記帳，而 AI 最擅長記帳。

你的工作是策展、提問、判斷。AI 的工作是整理、交叉引用、維護一致性。這就是 LLM Wiki 的精髓——把人類不擅長但必須做的事，交給不會累的 AI。

現在，去建你的知識庫吧。