千里之堤，潰於蟻穴——AI 知識庫的地雷很少是一次寫錯的 bug，而是一連串「當下看起來合理」的自動化決定，一點一點蛀出來的蟻穴。

Day28 把 gofmt/go vet/go test/brain health 交給 ci.yml 自動跑，也在文章最後劃了一條線：CI 不會去觸發 /weekly-report 這類 Claude Code slash command，因為那些指令依賴對話脈絡，headless 呼叫等於讓 LLM 產生的內容在無人審閱下自動落地。這句話寫下去的時候，其實已經在暗示一件事：這不是 Day28 才第一次出現的問題，而是任何一個「用 Agent + CLI 自動化維護知識庫」的專案，遲早都會撞上的一組共通地雷。

今天不寫新功能，obsidian-agent-brain 這個 repo 也不會有任何程式碼變更。Day29 要做的事情是把視角拉高一層：不只回頭盤點這個系列自己的決定，而是整理出建立 AI 知識庫時最常遇到的 5 個地雷與反模式——每一個都用「實際會遇到什麼問題」「為什麼會發生」「系列裡實際發生的例子」「怎麼避免」來說明，先講清楚一般情境下的問題與判斷原則，再用這個系列開發過程中真的踩到的地方當作具體佐證。這篇不提出具體的程式碼變更提案，也不是要宣告過去的設計是錯的：每個地雷之所以危險，通常是因為造成它的每一步決定，在當下看起來都合理。

地雷 1：過度自動化——人工審閱退化成「事後看一眼」

實際會遇到的問題：一開始，自動化只是幫忙做「使用者當下就在看」的小動作——例如替一篇筆記補幾個欄位、順手織入幾條連結。因為使用者就在現場，順手看一眼結果幾乎不花額外成本，人工審閱看起來完全沒有消失。但當同一套「Agent 產生內容、工具做結構性檢查、使用者事後看一眼」的模式被沿用到更重的場景——事故記錄、週報、甚至排程自動觸發——審閱實際上只剩下「事後掃過摘要」，沒有任何一關要求內容落地前先被明確確認過。一旦觸發者從「正在對話的人」換成排程或 CI，這個審閱關卡會直接消失，而系統本身完全不會發現少了什麼。

為什麼會發生：因為「人工審閱」從來不是一個被設計出來的獨立機制，而是「剛好使用者當下在場」這個環境條件的副產品。只要把觸發情境從「對話中」換成「背景執行」，這個副產品就會跟著不見，但沒有人會主動去檢查這件事有沒有發生。

系列裡實際發生的例子：/refine-inbox（Day15）把自動回填雙向連結（Day16）當成既有步驟的一部分直接執行，指令跑完之後，唯一能知道「剛剛動了什麼」的方式是事後打開 git diff 或回頭讀 Agent 的回覆摘要，過程中沒有任何一步要求使用者在連結真的寫進筆記前按下確認。Day26 的 /new-postmortem、Day27 的 /weekly-report 沿用同一套模式，寫入前唯一的把關是 brain scan/brain health，而這兩個工具檢查的是連結完不完整，不是內容對不對。

怎麼避免：把「審閱」當成一個需要獨立設計的關卡，而不是依賴觸發情境的副作用——區分「低風險、可事後修正」與「高風險、難以復原」的動作，只有前者才適合完全自動落地；後者無論觸發者是人還是排程，都應該有一個明確的「確認後才落地」步驟（例如寫入暫存區、產生 PR 而非直接 commit、或要求一次明確的核准動作）。Day28 明確排除 CI 觸發 slash command，是這條路徑上第一個被主動擋下的觸發來源，但「事後看摘要」這個審閱方式本身，並沒有因此被重新設計過。

地雷 2：標籤爆炸——分類詞彙不受控，字串比對取代語意判斷

實際會遇到的問題：知識庫的標籤/分類系統，一開始為了對人友善，通常只驗證格式（例如型別、命名慣例），不驗證語意。這在筆記數量還少時完全沒問題。但只要有自動化流程開始「消費」這些標籤——例如用共享標籤自動建立雙向連結、統計孤立筆記——語意上其實相同的標籤（ai-agent vs. ai-agents、大小寫變體、單複數混用）在字串比對之下會被當成完全無關的兩個東西。自動化不會報錯、不會警告，它只是安靜地判定「這兩篇筆記沒有關聯」，於是該建立的連結沒有建立、該被算進去的孤立筆記統計也悄悄失真。筆記數量越多、標籤詞彙越豐富，這種同義變體出現的機率就越高。

為什麼會發生：格式驗證跟語意驗證是兩件成本天差地遠的事——格式驗證是一次性、規則明確的檢查；語意驗證需要詞彙表、相似度比對，甚至人工維護，在專案早期幾乎不會被排進優先順序，只會被記成「未來可能需要的能力」，然後長期停留在「未來」。

系列裡實際發生的例子：internal/vault.Index.Tags 是一個 map[string][]*Note，Day16 判斷「兩篇筆記要不要自動織入連結」完全靠這個 map 的 key 是否完全相同。ai-agent 跟 ai-agents 是兩個不同的 key，比對邏輯不會丟出任何錯誤或警告，只是安靜地找不到共同標籤、判定兩篇筆記無關——這正是 Day04 只驗證格式、Day10 明確排除語意驗證並承諾「未來的 lint 能力」之後，直到 Day28 都還沒兌現所留下的具體後果。

怎麼避免：不要等語意驗證「有空再做」，而是及早決定一個受控詞彙表（controlled vocabulary）或至少定期跑一次相似度比對，把疑似同義的標籤攤出來讓人決定要不要合併；如果暫時做不到，至少要讓「自動連結沒有建立」這件事變成可觀察的訊號（例如列出所有只出現一次、且跟高頻標籤字面相似的標籤），而不是讓它完全沉默地發生。

地雷 3：結構正確 ≠ 內容正確——自動化檢查給的是假的安全感

實際會遇到的問題：CI 或 lint 工具很擅長回答「這篇筆記有沒有斷鏈」「格式有沒有跑掉」「測試有沒有過」，但這些全部都是結構性檢查，沒有一個在回答「這篇筆記寫的內容是不是事實」。當一個知識庫開始靠 Agent 自動生成內容（事故記錄、週報、摘要），團隊很容易把「CI 全綠」誤讀成「內容沒問題」——因為過去在純手寫筆記的時代，能通過結構檢查的筆記幾乎都是人寫的、內容大致可信，這個經驗直接被延續到了 Agent 生成內容的情境，但兩者的可信度來源完全不同。

為什麼會發生：結構性檢查的成本低、可以完全自動化、有明確的通過/失敗標準，所以會被優先做出來；內容正確性的驗證幾乎沒有辦法自動化到相同程度，通常只能靠人工抽查。當團隊的信心來源被結構檢查填滿之後，內容正確性這一塊很容易被默默忽略。

系列裡實際發生的例子：Day28 的 ci.yml 讓 validate job 執行 go run ./cmd/brain health，這個指令的結束碼語意在 Day11 就定義好了——只認斷鏈存不存在，不認內容對不對。即使 /new-postmortem（Day26）生成的事故記錄整段內容判斷錯誤、/weekly-report（Day27）的週報摘要張冠李戴，只要連結沒斷、格式沒壞，brain health 一樣回傳 0，CI 一樣全綠，不會有任何一個訊號提醒使用者去核對內容。

怎麼避免：把「結構檢查通過」和「內容正確」明確標示成兩件不同的事，不要讓 CI 的綠燈替內容背書；對 Agent 生成的高風險內容（會影響決策的事故記錄、對外報告），保留一個輕量但強制的人工抽查機制，並且讓抽查的頻率跟內容的影響範圍成正比。

地雷 4：靜默失敗——自動化沒有跳錯誤，不代表沒有錯

實際會遇到的問題：很多自動化流程會刻意設計成「某些狀況不算失敗」——例如孤立筆記數量增加不會讓 CI 失敗，因為孤立筆記本身不是錯誤，只是一個需要人留意的訊號。這個設計決定本身完全合理，但它有一個容易被忽略的副作用：如果沒有人另外去追蹤這個訊號的趨勢，一個原本用來提醒人「該注意了」的數字，會因為從來沒有觸發任何警報，而被長期忽略，直到累積到某個規模才被發現。

為什麼會發生：「不讓某個狀況導致失敗」跟「這個狀況不重要、可以完全不管」，是兩個容易被混為一談的決定。前者只是不希望它擋住其他工作，後者才是真正放棄追蹤。當自動化流程把兩者做出的行為完全一樣（都是「不報錯、不提醒」），團隊很容易誤以為系統已經在幫忙看著這個問題。

系列裡實際發生的例子：ci-cd-pipeline 的規格明講「孤立筆記數量 SHALL NOT 影響結束碼」——這代表 brain health 每次都會算出孤立筆記數字，但這個數字完全不會反映在 CI 的成功/失敗訊號裡。只要沒有人主動去看 workflow log 裡的實際輸出內容，孤立筆記數量可以持續上升好幾週，而所有 workflow 畫面上看到的都還是綠色打勾。

怎麼避免：對於「刻意不讓它失敗」的訊號，另外找地方讓它可見——例如把趨勢數字定期輸出成報表或 artifact、設定一個明顯高於正常值的門檻做提醒（而不是硬性失敗），或至少定期人工回顧一次。不報錯不等於沒問題，關鍵是要讓這個訊號被看見的頻率，跟它的重要性成正比，而不是跟它多容易被自動化忽略成正比。

地雷 5：情境坍縮——摘要與生成內容切斷了與原始來源的可追溯性

實際會遇到的問題：Agent 幫忙把一堆對話、commit、事故過程整理成一篇摘要或報告，讀起來流暢、結構完整，但讀者無法分辨哪些句子是直接轉述原始資料、哪些是 Agent 自己歸納甚至推測出來的。時間一久，這篇摘要會被當成「原始事實」被引用、被連結、被拿去做下一次摘要的素材，原始來源反而漸漸沒有人回頭去查——知識庫裡累積的，變成一層又一層「看起來很像事實」但已經很難逐句查證的內容。

為什麼會發生：摘要類內容天生就是用來取代閱讀原始資料的，這正是它的價值所在，但也因此讀者原本就不會去核對每一句話的出處。如果生成流程沒有刻意保留「這句話對應哪個原始來源」的痕跡，這個可追溯性一旦在生成當下沒被記下來，之後幾乎不可能補回去。

系列裡實際發生的例子：Day26 的 /new-postmortem、Day27 的 /weekly-report 都是把 Agent 整理好的內容直接寫成 vault 裡的一篇筆記，筆記本身除了內文之外，並沒有強制要求記錄「這段內容對應哪些 commit、哪段對話」的來源範圍。一旦這篇筆記之後又被 Day16 的自動連結或另一次摘要引用，最初的原始依據會比筆記本身更快被淡忘。

怎麼避免：讓 Agent 生成內容時，盡量保留可以回頭核對的線索——標明資料來源範圍（例如對應的 commit 範圍、對話時間區間）、用 metadata 標示這段內容是「Agent 生成」還是「人工撰寫」、對高風險內容保留一個「回頭核對原始來源」的檢查點，而不是假設摘要本身就是最終事實。

五個地雷共同的根源：自動化拿走的是「人在場」，不是「判斷力」

這五個地雷各自的表現不同，但拆開來看，共同的根源只有一個：自動化真正拿走的，是「有人剛好在場、順手看一眼」這個環境條件，而不是判斷力本身。判斷力這件事從頭到尾都需要人來做——差別只在於，當觸發情境從「對話中」換成「背景執行」、當分類詞彙從「少量、人工可控」換成「大量、字串比對」、當內容來源從「人手寫」換成「Agent 生成」，原本靠「剛好有人在場」撐著的把關方式，會在你完全沒感覺到的時候悄悄失效。obsidian-agent-brain 目前還是一個筆記數量個位數到二十餘篇的 demo repo，這五個地雷帶來的實際傷害都還很有限，但這篇要指認的不是「demo repo 已經出事了」，而是「往哪個方向持續疊加自動化，風險會往哪裡累積」。

銜接 Day30

Day29 整理出的 5 個地雷——過度自動化、標籤爆炸、結構正確不等於內容正確、靜默失敗、情境坍縮——不會在這篇文章裡被解決，也不打算現在就解決。Day30 是這個系列最後一天的總結，會直接引用這份地雷清單，作為展望 Personal AI Agent 下一步方向時優先考慮補強的候選項，不需要重新盤點一次 Day01 到 Day28 做過的所有決定。今天的角色只是把這份盤點做完、講清楚，讓 Day30 可以踩在這個基礎上往前看，而不是回頭看。