可以開始用了，個頭

我希望前五篇有為「讓 AI 參與，對知識庫的使用與維護上有很大幫助」這點定下基調，我寫了很多「可以讓 AI 做」的陳述，到這邊我認為可以往前了，我們已經有知識庫、有輸入Prompt 有資料夾（第四篇），接下來可以開始用了。
.
.
.

並沒有那麼簡單，就像一個專案一樣，知識庫既然要與 AI 協作，就需要相關的協作設定，這一篇要說明具體是要設定什麼。

知識庫協作內容盤點

超級不說廢話直接進入正題，我這邊整理了八種知識庫在 LLM 情境下的協作內容：

1. 資料結構定義——資料夾骨架與各層用途，就像圖書館一樣會把藏書分為天文、地理、人云、亦云一樣，在維護知識庫時，我們需要 AI 知道現在圖書館（知識庫），具體有什麼分類。
   
   會像是地圖一樣。

2. 分類規則——延伸 1. ，新資料進來後，怎麼決定一則內容屬於哪裡。

3. 例行動作（SOP）——收錄新東西、查資料、定期檢查這些會一直重複做的事，包括觸發條件、步驟、輸出格式等。例如經典三動作：採集＋整理＋提取

4. 格式規格——固定欄位、允許值、連結寫法慣例。

5. 維護規則——例如輔助結構（索引/時間軸）什麼時候更新、怎麼歸檔。

6. 邊界與禁止事項——AI 不能自己動的範圍。

7. 協作風格——你希望他講話什麼調調、包括但不限於：溝通語氣、決策權分配、用語慣例。

8. 規則寫法本身的規則——規則本身該怎麼寫才合格，這條應該不太常見，這是我自己加的，詳細內容下一篇再講。

以上八種僅限「知識庫」這個情境下，資料來源是：我自己。

應該是可以涵蓋90% 以上，與 AI 協作的內容類型了，那我繼續講。

有哪些機制可以承載這些內容

撇除知識庫這個使用情境，目前已知有五種主要機制可以用來跟 AI 協作，使用工具是 Claude Code ，一樣不排除有其他機制，歡迎讀者提出不一樣看法。

1. CLAUDE.md——always-on，每次 session 自動載入的常駐 context。
2. Rules（.claude/rules/）——依檔案路徑/類型自動生效的範圍限定規則，符合條件才載入，類似 CLAUDE.md 但不是每次都載入。
3. Skills——明確呼叫或情境判斷才觸發的可重複程序，平常不佔用 context。
4. Subagents——有獨立 context 視窗跟工具權限的子代理，用來隔離／委派子任務，結果濃縮後才回主線。
5. Hooks——harness 保證觸發的 shell 指令，掛在特定事件上（如 PreToolUse、SessionStart），不需 AI 判斷、機械執行。

五種都能「裝東西」，但知識庫這個使用場景，比較常用到的只有 CLAUDE.md 跟 Skills 這兩種，稍微說明一下。

• Rules 這個靠資料夾分流省 token，理論上很好用，但是是在「資料量夠大」的前提下，這個機制產生的效用才比較明顯，問題在於：通常你的資料不會那麼多，就算多，也不是每個資料夾都很多，所以說大部分時候這個機制是用不到的。
• Subagents 適合「外包的工作」。這個我實在想不到「純知識庫」要怎麼使用到 Subagents這個機制，因為照理說，你的工作不該「在知識庫裡面做」，所以既然我想不到，就先歸類到不需要。（當然你可以讓工作融合進知識庫，但這屬於客製化需求。）
• Hooks 這個純粹是我沒用過，而且 CLAUDE.md、Skills 已經 cover 九成九的需求，所以我歸類到不需要。

簡單的事不用搞的複雜

好，八種需求、兩個容器，兜起來看：

好，我知道。 這看起來不就 CLAUDE.md + Skills 嗎？ 搞一整篇的篇幅裝什麼忙？

但沒那麼簡單好嗎，我一開始本來要把部份內容歸類到 Rules ，但我的知識庫還沒有累積到需要特別把規則挪過去，這是其一

其二是我不會這樣用，不代表你不能這樣用，現在你知道知識庫需要跟 AI 協作的內容有哪些了，也知道幾種可以使用的機制，也許你可以發揮你的創意？