本地 AI 知識庫

先說我為什麼要做這個

我每天用 AI 工作。三個月下來，對話記錄積了 854.7 MB——其中被提煉成文檔的，只有 214 KB。

比例是 1 : 4000。也就是說，我和 AI 一起做過的決策、推翻過的方案、踩過的坑，99.97% 爛在原始記錄裡，誰也不會再看。

後果很具體，三種：

• 判斷散在碎片裡——一個決策不是一次成型的，是好幾次對話裡逐步長出來的。要用的時候，AI 只能憑 30 條一行摘要理解我，細節全丟
• 想法關掉對話框就沒了——沒特別要求存的東西，聊完即蒸發
• 最痛的：我是在實際做事時撞見矛盾的——改方案改到一半才發現和之前拍板的結論衝突，代價是返工

它長什麼樣

它不是網站，不是 App——就是一個資料夾。以下是真實的目錄結構與現狀：

D:\000_SAKURA_claude\
├── CLAUDE.md      規矩層，214 行——AI 讀它就知道怎麼運轉
├── INDEX.md       全庫索引，一頁一行，查東西先讀這裡
├── raw/            5 篇原文，120 KB，只讀不改（唯一事實來源）
├── notes/          單條筆記，必須帶立場
├── wiki/           編譯層——同主題多條筆記合成一頁結論
└── briefs/         週報（兜底的矛盾檢查關口）

每個檔案頭部都有一段結構化標記。看一頁真實的編譯頁是怎麼自我描述的：

---
topic: 自建 AI 知識庫方法論
status: current          ← 現行結論；被推翻會標 superseded
sources:              ← 由哪 6 份原料編譯而來，可追溯
  - raw/2026-06-02-zsxq-為什麼要自己搭一個AI知識庫.md
  - raw/2026-06-04-zsxq-07產品思維.md
  - …（共 5 篇原文 + 1 條筆記）
conflicts: []         ← 未解決的矛盾掛在這裡，不藏
---

它是怎麼運作的

我丟一個連結或說一句「存起來」，AI 走六步。全程手動觸發——我沒有重複提起的東西，就是不重要，不做自動收集。

三個關鍵設計決定

一、不用 RAG，用「編譯」

知識的本質是被反覆加工、彼此連接之後的產物，不是原始資訊的堆疊。所以這個庫把「理解」前置成一次性的編譯，之後永久複用——個人規模的庫（幾百頁以內）靠一個索引檔就能導航，根本不需要向量檢索。

二、編譯層 v1 就要有，不能等

參考的原方案裡，編譯層是作者跑了一段時間翻車後 v2 才補的。我的 v1 直接內建——因為我的情況更嚴重：

三、把庫嫁接到 AI 的自動記憶上

光有庫還不夠——我得記得去查，它才有用。這是所有知識庫工具的死穴。解法是分兩層：

效果：我不需要記得庫的存在。新對話一開，AI 已經知道有這個庫、知道去哪查——「先讀索引、再鑽頁面」的導航被接進了 AI 天然的啟動流程。

附：矛盾不是錯誤，是編譯觸發器

我撞見矛盾，說明我的認知更新了——這是資產。所以系統不把矛盾當「待清理的髒資料」，而是當成重新編譯的信號：舊結論標 superseded，新結論成為 current，正文必須寫清為什麼變。檢測有三個時機，最重要的排第一：做事前主動提示，其次是入庫時比對，週報只是兜底。

它實際跑出來的東西

建庫第一天的真實成果（2026-08-03）：

一條真實的 stance 長這樣（對一篇 1.8 萬字文章的判斷）：

三個月後我重看這條筆記，只需要讀這一句就知道原文還要不要重讀——這就是「帶立場」和「中性摘要」的差別。

那頁編譯出來的結論裡，最值錢的不是原文摘要，是一張原文裡不存在的表：「本庫抄什麼 / 改什麼 / 不抄什麼」——原作者不知道我的環境、不知道我在做事時才撞矛盾，這張表是把他的方案落到我的處境裡的判斷。

做的時候踩過的坑

庫剛建三天，規矩已經被實踐改了三次——每次修改都記錄在案。

坑 1 · 同系列文章拆成多條筆記，純屬自碎

最初的規則是「攢到 3 條同主題筆記再編譯」。結果同一個系列的五篇文章，按規則要拆成五條筆記等著攢——它們本來就在講同一件事，拆開就是自己製造碎片。

修法：給編譯觸發條件加了一條——同來源多篇材料一起進來，入庫時直接合成一頁。判斷標準：這些材料要用的時候會不會總是一起用？會，就當場編譯。

坑 2 · 標籤配額會逼 AI 硬湊

規則寫「打 3-5 個標籤」，AI 就會為了湊數貼不相干的詞——而假標籤會直接毒化將來按標籤算關聯的機制。

修法：一嚴一鬆。詞表封閉（防止「跨境電商」和「電商」並存把關聯算法廢掉），數量放開（寧少勿湊，兩個講得完就打兩個）。

坑 3 · 「raw 只讀」寫得太絕對

規矩層最初寫「raw 任何情況不改」。結果第一次要給原文補一個來源網址就卡住了——照字面連元資料都不能動。

修法：分三檔——正文一個字不動；frontmatter 元資料可以補；用更完整的同源版本整體替換需要告知。規則寫太死，第一個絆倒的是自己。

動手：照這個做，今天就能有自己的

你不需要會寫程式。需要的只有兩樣：一個能讀寫本地檔案的 AI 助手（如 Claude Code），和 30 分鐘。

第 1 步 · 建骨架（1 分鐘）

隨便找個地方建一個資料夾，裡面四個子資料夾、兩個空檔案：

我的知識庫\
├── CLAUDE.md       ← 規矩層，下一步填
├── INDEX.md        ← 索引，先空著
├── raw\            ← 原文
├── notes\          ← 帶立場的筆記
├── wiki\           ← 編譯後的結論
└── briefs\         ← 週報，先空著沒關係

第 2 步 · 寫規矩層（10 分鐘）

把下面這份最小模板複製進 CLAUDE.md，改成你的名字就能用。它就是大白話，不是程式碼——AI 讀它，照著執行：

# 我的知識庫規矩

## 我丟東西進來時，按這個流程：
1. 抓原文存進 raw/，一個字都不許改
2. 讀完先跟我聊要點，我說存才存；沒用就直說「不值得收」
3. 寫一條筆記進 notes/，開頭必須有一句 stance：
   回答「這對我有什麼用」，帶判斷——
   禁止寫「本文介紹了…」這種中性復述
4. 和庫裡已有結論衝突的，當場告訴我
5. 同主題筆記超過 3 條，或同系列多篇一起進來：
   合成一頁結論放進 wiki/，寫清楚
   「現行結論是什麼、舊的是什麼、為什麼變」
6. 每次入庫後更新 INDEX.md，一條一行

## 紅線：
- raw/ 的正文永遠不改不刪
- 標籤寧少勿湊，兩個夠就打兩個
- 查東西先讀 INDEX.md 定位，不通讀全庫

第 3 步 · 餵第一條（10 分鐘）

找一篇你最近覺得有用的文章，丟給 AI 說「按 CLAUDE.md 的規矩存進我的知識庫」。然後只檢查一件事：

第 4 步 · 用兩週再說（別跳過）

先別加任何功能。兩週後看兩個信號：

• 你真的去查過它嗎？一次都沒有，說明選的主題不對，改主題，不是改工具
• 它有沒有幫你避免一次重複勞動？有一次，這個系統就成立了

三個最容易犯的錯，先打預防針

• 別做自動收集。什麼都往裡塞，三週後它就是你的第二個「收藏了等於看過」的收藏夾。手動觸發是特性，不是缺陷
• 別一開始就上工具鏈。不需要向量庫、不需要插件、不需要同步服務——先用純資料夾跑通流程，跑不通的話工具再多也救不了
• 別追求全量遷移舊資料。從今天的新東西開始存，舊帳想起什麼補什麼。「漏了就漏了」比「必須完整」更能讓系統活下來

它不需要部署——這正是設計的一部分