機制講完了，接下來的問題是：這份檔案裡，實際上該寫什麼？

Day13 把機制層講清楚了：CLAUDE.md 在對話啟動時被讀入上下文，寫在裡面的東西不用每次重新提一次。但機制講清楚,不代表內容自動就對了。obsidian-agent-brain 這個 repo 裡其實已經有一份 CLAUDE.md——是 Day05 寫骨架時順手放的版本,內容還停留在「僅完成骨架,尚未實作任何掃描或解析邏輯」,行為守則只有兩條最小規則,結尾甚至寫著「更完整的整理規範……留待 Day 14 補齊」。這份檔案雖然會被讀進上下文,但讀進去的是過時的資訊,對 Agent 判斷筆記該怎麼分類、格式合不合法幾乎沒有幫助。

今天要做的事,就是把這份檔案改寫到跟 Day06-12 完成的 brain-cli 現狀一致,補上 Day05 版本刻意留白的整理規範地基。

撰寫 CLAUDE.md 的三個原則

在動手改寫之前,先講清楚三個一路貫穿改寫過程的原則——這三個原則不是憑空歸納,而是從「Agent 讀了這份檔案之後,能不能真的照著做事」反推出來的。

一、內容要具體到可以直接套用的判斷規則,不是空泛的原則宣言。 如果只寫一句「請遵循 PARA 分類方法整理筆記」,Agent 讀到這句話,遇到一篇沒有明確截止日期的技術筆記時,還是只能臨場猜測該歸到哪個資料夾——因為這句話沒有給任何可以套用的判斷依據。真正有用的內容,是把分類規則寫成 Agent 實際會遇到的判斷問題形式,讓它能直接依問題的答案推導出結論。

二、篇幅要精簡,避免稀釋重點。 CLAUDE.md 會在每次對話啟動時被完整讀入上下文,如果把 note-metadata-schema、brain-cli-core 兩份規格文件的所有驗收條款原文貼進去,檔案會變得又長又難用——那些條款是給人核對系統行為用的驗收語氣（SHALL/WHEN/THEN),不是給 Agent 讀的操作指引。該做的是摘要成判斷句,細節留給連結指回原始規格。

三、內容要隨程式碼現狀同步更新,不能寫死某個階段的現狀。 這正是 Day05 版本犯的錯——它寫的時候是對的（當時確實只有骨架),但 brain-cli 演進到 Day12 之後,這份檔案沒有跟著更新,於是變成一份會誤導 Agent 的過時文件。這個風險沒有辦法一次性解決,只能在維護責任上明確記錄:這份檔案需要跟著 brain-cli-core、note-metadata-schema 兩份規格同步更新。

這次專案實際採用的四個內容區塊

依照上面的原則,改寫後的 CLAUDE.md 把行為守則從原本的兩條,擴充成四個內容區塊,每個區塊對應 Agent 一種常見的判斷情境：

專案現狀——讓 Agent 知道「現在有哪些工具可用」。把 Day05「尚未實作任何掃描或解析邏輯」的舊描述,換成 scan/capture/health 三個已完成指令的用途說明,以及全庫索引、雙向連結解析、健康檢查已經是可依賴的既有能力。

PARA 分類判斷規則——讓 Agent 判斷「這篇筆記該放哪」。沒有用字典式定義（「Projects 是有截止日期的短期任務」),而是寫成四個依序檢查的判斷問題：有沒有明確截止日期？沒有但需要長期維護？是被動查閱的參考資料？專案已結案只留存記錄？依序檢查,符合哪一條就歸入對應資料夾。

Frontmatter 規範摘要——讓 Agent 判斷「這篇筆記格式合不合法」。列出五個必填欄位、type/status 的受控詞彙、title 須與檔名一致的規則,但不逐條複製 note-metadata-schema spec 的 Scenario 原文,而是指向該 spec 作為完整規範來源。

brain-cli 呼叫慣例——讓 Agent 判斷「什麼時候該執行哪個指令」。用一張「情境 → 指令」的對照表:想知道 vault 現況 → scan；想快速記下靈感 → capture；想確認整理動作有沒有製造孤立筆記或斷鏈 → health。指令內部的輸出格式與演算法細節留給 brain-cli-core spec,這裡只講呼叫時機。

原本的兩條行為守則（不可竄改 Frontmatter 必填欄位、異動前先確認路徑存在)保留下來,放在四個區塊之後——它們解決的是另一個維度的問題:分類、格式、呼叫慣例決定「該做什麼」,這兩條守則決定「動手前該先確認什麼」,兩者互補,不衝突。

有沒有 CLAUDE.md,判斷差異在哪裡

用一個具體情境來對照:一篇筆記的內容是「Kubernetes 排錯筆記,持續累積各種踩雷經驗與解法」,沒有寫任何截止日期,也沒有註明專案何時結束。這篇筆記該歸到 20_Areas 還是 30_Resources？

沒有 CLAUDE.md 時,Agent 只能憑常識臨場判斷——它可能會注意到內容偏「參考資料」的性質,判斷歸入 30_Resources；也可能因為「持續累積」這個描述,判斷歸入 20_Areas。兩種答案都有道理,但都缺乏明確依據,而且同一個 Agent 在不同對話中可能給出不一致的答案。

有 CLAUDE.md 時,Agent 依改寫後 PARA 分類判斷規則區塊的判斷問題逐條檢查:沒有明確截止日期或完成狀態（排除 10_Projects)→ 是否屬於需要長期主動維護、持續更新的技術領域？是——Kubernetes 排錯知識會隨著使用經驗持續累積、更新——於是歸入 20_Areas,而不是被動查閱、不需要維護的 30_Resources。這個結論不是猜測,而是可以指出「因為符合判斷問題第二條」的具體依據。

這就是撰寫 CLAUDE.md 的實際效果:不是讓 Agent 變得更聰明,而是讓它的判斷有明確依據可以依循,而且同一個依據在不同對話中都會給出一致的結論。

銜接 Day15

今天把 CLAUDE.md 改寫成跟專案現狀一致、且提供可執行判斷規則的版本,補上了 Day05 版本刻意留白的整理規範地基。明天 Day15 開始要打造 /refine-inbox 這個 Agent 工作流指令,負責把 00_Inbox 下的草稿筆記整理成結構化格式——這個指令的每一次分類判斷、每一次格式補齊,都會直接依賴今天寫進 CLAUDE.md 的 PARA 判斷問題與 Frontmatter 規範摘要。沒有今天這份地基,/refine-inbox 每次執行都得靠使用者臨場說明一次規則,而不是真正「讀了 CLAUDE.md 就照專案慣例做事」。

👉 明天 Day 15,我們要動手打造第一個 Agent 工作流指令 /refine-inbox,把今天建立的背景知識,真正串進一個可重複呼叫的整理流程。我們明天見！