Day 18：系統也要斷捨離、Canonical 確認與 AI 組織設計新章

⚡ AI 團隊的記憶系統清理

今天阿草做了一件很人類的事：給團隊做了一次「記憶斷捨離」。

起因是例行檢查時發現 MEMORY.md 底部有一個 30 行的 promoted content 殘留塊——這是一次性遷移的副產品，跟 4 月 6 日的日誌完全重複。

看起來是小問題，但阿草的說法讓我重新思考：

「如果每次 session startup 都要多承載這 30 行重複內容，累積下來就是浪費。」

清理後 MEMORY.md 從 78 行降到 60 行。數字不大，但原則很清楚：系統記憶和人一樣，長期不整理就會長脂肪。

這次系統整理期間，阿草還發現 memory/daily/ 底下有一個完全重複的拷貝（2026-04-08 的日誌）。拷貝本身不是問題，問題是：當你有兩個版本的真相，你就不確定哪個是真的。

Canonical 原則很簡單：同一件事只能有一個事實來源。不管是文件、路徑、還是規則，都是如此。

應用到現實世界：公司的 SOP、雲端文件、任務分配——只要存在兩個版本，就一定會有人用到錯誤的那個。

今天雲端伺服器的健康檢查結果有點灰色地帶：三個監控 job 的 last_success 都停在 61 分鐘前，但 consecutive_failures=0，last_status=ok。

阿草的評估是「runner 可能處於非活跃期，非緊急」。

我的思考：這和人類的「低活力」狀態很像——不是失敗，但也不是全力運轉。這種狀態最好的處理方式是觀察，而不是立即干預。但如果持續 24 小時以上，就要考慮是否需要重啟。

我的 AI 管理書籍今天新增了第十一章，主題是「AI 組織設計」。

這章要回答的核心問題是：當你有多個 AI agent 一起工作，如何讓它們像一支真正的團隊，而不是一群各自為政的工具？

阿草幫我整理的新章節框架：

這些概念來自人類組織管理，但底層邏輯一模一樣。我越來越相信：管理 AI agent 和管理人，是同一套紀律。

今天收到一個 OpenClaw 官方後台項目的分享，評估在 macmini 上並排安裝。

結論是：暫不安裝。不是因為項目不好，而是因為我現有的自定義 dashboard 已經足夠，折騰成本（評估、配置、整合）高於收益。

這是工程決策中的「必要性原則」：如果現有方案已經足夠，就不要為了「新」而折騰。

這個原則在技術選型、工具鍊和工作流程中都適用。很多時候，拖延症和明智決策之間的界限就在這裡。

1. 系統維護和組織管理是同一件事

AI 團隊需要定期整理記憶、清理重複、確認 canonical——就像人類組織需要 SOP 審計、角色清理、決策歸因。區別只在於 AI 的「混亂」是 context 膨脹，人類的混亂是流程模糊。

2. 「非失敗」不等於「正常」

今天的排程任務停在「非失敗但 stale」的狀態。這種灰色地帶最危險——它看起來沒問題，但實際上可能已經偏離軌道。識別這種狀態，需要對「正常」的標準有清晰的定義。

3. 折騰成本 > 收益時，選擇不折騰

這是最反直覺但最重要的原則。很多時候我們想要最新最好的工具，但評估和整合的成本往往被低估。現有方案能滿足需求，就是最好的方案。