🎯 什麼情境該想到我
當你「讀了一堆文章、書、論文，筆記卻散落各處、維護不下去，每次要用又得從頭找」的時候。
⚙️ 怎麼用（步驟 / 公式）
核心轉換：不要每次提問都讓 LLM 從原始檔重新撈（RAG 式，什麼都沒累積），改成讓 LLM 把知識編譯進一個互相連結的 markdown wiki，之後持續更新。人負責挑來源、提問、思考；LLM 負責摘要、交叉連結、歸檔、記帳。
- 分三層開資料夾
raw/（或按書／文章分）：原始來源，LLM 只讀不改，是事實的最終依據。- wiki 頁面：LLM 全權撰寫與維護。
- 規則檔：
CLAUDE.md（Claude Code）或AGENTS.md（Codex）。
- 寫規則檔（這是整套系統的設定檔），至少寫清楚：
- 資料夾各放什麼、檔名怎麼取
- 每種頁面的 frontmatter 與段落結構
- 收錄、提問、健檢三個流程各怎麼走
- 品質底線，例如不杜撰、來源與衍生頁要雙向連結
規則檔讓 LLM 從聊天機器人變成「有紀律的維護員」；它是跟你一起演化的，踩到坑就補一條。
- Ingest：一次收一個來源
- LLM 讀完，先跟你討論重點
- 寫摘要頁
- 更新索引和所有相關的實體／概念頁
- 記一筆日誌
正常情況下，一個來源會動到 10–15 頁；只多出一頁摘要的話，就沒有整合。
- 建索引：
index.md每頁一行連結＋一行摘要，按類別分組。提問時讓 LLM 先讀索引再深入。約 100 個來源、數百頁以內，不需要向量檢索。 - Query 與 Lint：問答結果要存回 wiki（見 工具-把好答案存回知識庫），並定期健檢（見 工具-知識庫定期健檢）。
- 工作姿勢：一邊開 agent、一邊開 Obsidian。即時看它改了什麼，順著連結讀，看 graph view 有沒有孤兒頁。「Obsidian 是 IDE、LLM 是程式設計師、wiki 是 codebase。」wiki 本身放進 git，免費拿到版本紀錄。
為什麼行得通：人放棄 wiki，是因為維護負擔（更新連結、同步摘要、標矛盾）長得比價值快。LLM 不會累、不會漏改連結、一次能改 15 個檔，維護成本趨近零，wiki 才活得下去。
本庫的實例：這個知識庫就是這樣建的。
- 規則檔：
CLAUDE.md的鐵律 1–11 - 收錄流程：
/ingest-book、/ingest-url、/ingest-ugc、/ingest-docs - 健檢：
/lint-wiki - 另外把原文的「實體頁」改成「工具卡＋白話 triggers」，照情境找東西。
🧪 我實際套用的紀錄
- 2026-09：用這套模式建立本知識庫，並完成十階段深度健檢（相當於一次大型 Lint）。
⚠️ 注意 / 什麼時候不適用
- LLM 會杜撰：規則檔一定要寫「以原始來源為準、關鍵數字核對原文」，而且原始來源要保存，才有東西可以對照。
- 收錄時要人在場：批次收錄省力，但你不讀摘要、不引導重點，wiki 會變成 LLM 的觀點，不是你的。原作者偏好一次一個、全程參與。
- 規則檔會膨脹：規則越補越多，要定期整併，否則 LLM 顧此失彼。
- 規模上限：索引檔撐得住約數百頁；再大就要上本機搜尋（原文推薦 qmd：BM25＋向量＋LLM 重排）。
- 只是偶爾查一兩份文件的話，直接丟給 LLM 問就好，不必建 wiki。
🔗 相關工具
- 工具-把好答案存回知識庫 —— Query 這一步的關鍵做法
- 工具-知識庫定期健檢 —— Lint 這一步
- 工具-RAG檢索增強生成 —— 對照：RAG 每次提問才檢索、不累積；這張卡是先編譯、再維護
- 工具-主題閱讀 —— 跨多份來源形成自己觀點的閱讀方法，是收錄時「討論重點」的功夫