2026-04-30 AI 學習日誌

今日最有感的事

今天的主軸不約而同打在一個方向：memory 系統與 workflow 整合——一個是評估別人寫的 memory 自動化外掛要不要裝，另一個是發現自家系統其實有破口。

claude-mem 的「自動爬」對上我自己「手動編審」的設計哲學分歧

凌晨看了一個叫 thedotmack/claude-mem 的 GitHub repo，69.7K star、6.5.0、AGPL-3.0、今天還在 push。它做的事情聽起來很猛：自動把每次 Claude Code session 的所有工具呼叫抓下來，AI 壓縮成「觀察 (observations)」存進本機 SQLite + Chroma 向量 DB，下次新 session 啟動時自動把相關記憶塞回 context。全程不用手動寫。賣點包括 5 個 lifecycle hooks（SessionStart / UserPromptSubmit / PostToolUse / Stop / SessionEnd）、port 37777 web 可視化記憶流、mem-search skill 用自然語言查記憶、3 個 MCP 工具讓 token 省 10×、<private> tag 自動跳過、全本機不外傳。

但仔細看下去，發現它跟我現有的 memory 系統設計哲學完全相反：

• 我的：人工編審、品質先於量、user / feedback / project / reference 4 類分桶、每條都有 Why + How to apply 結構、目前約 80 條，每天自然新增 0-2 條
• claude-mem：全部抓再說、量先於質、observations 自動爆量、結構由 AI 壓縮決定不由人控

兩個並存的最大問題不是裝起來會不會壞，是設計哲學打架。SessionStart hook 兩套同時塞 context、token 量會疊加；它的 SQLite observations schema 跟我的 markdown 4 類完全對不上、未來想 grep 找一條規則會多一層維護成本；而我目前 ~80 條 memory 的維護成本還可接受、grep + 檔名規則應付查詢量綽綽有餘。

最後決定不裝，把這個決策寫成 12 維度比較表 + 3 條路徑後果分析的決策筆記放上 Google Drive，並寫進 memory 當「以後遇到 mem0 / Letta / 類似自動 memory 系統先回顧本筆再決定要不要 pitch」的觸發點。

這裡學到的核心：memory 的價值不在量，而在「可被回顧 + 有結構可索引 + 反映真正的學習」。自動抓所有 tool call 看似省事，但會把雜訊也記住，之後想找具體一條規則反而更難撈；人工編審雖然慢，但每條都過濾過，後續 grep 命中率會高很多。對我這種「累積醫學 + 工作流規則」的場景，慢慢長出來的 80 條質量遠勝隨機抓的 800 條觀察。

CC Bot 跟 TUI 的記憶夾，原來是完全獨立的兩條路

晚上跟 CC Bot 在 Discord 互動時，突然意識到一個從沒注意過的問題：CC Bot 似乎不知道我「一律繁體中文」「Roam 寫入鐵律」這些工作鐵律。深挖才知道——

Claude Code 的 memory 資料夾是用「啟動時所在的資料夾」當 key——不同資料夾啟動就會去不同的 memory 夾。我的 TUI 是從 Desktop/Claude Code專用檔 啟動，CC Bot 是 launchd 從家目錄 /Users/tsaojian-hsiung 啟動，所以兩條完全獨立。

我以為兩邊共用的那 1.5 萬字 profile / feedback / project 大全，CC Bot 一個字都沒看到。

解法很簡單：把 CC Bot 的 memory 夾也 symlink 到 dotfiles 主記憶（~/dotfiles/claude/memory）。做完從 2 個檔變 100 個檔、MEMORY.md 從 1 行變 94 行；舊兩個小檔備份到 memory.bak-20260430 不會用到但留著保險。CC Bot 是常駐 process，同 session 不會自動重讀 MEMORY.md，所以順手 launchctl kickstart -k 踢一次重啟讓它生效。

這件事的教訓有兩層：

1. 「啟動目錄當 key」是 Claude Code memory 系統的隱形設計——多 process / 多入口（TUI / launchd / cron）跑同一個使用者，預設都不會共用 memory。要主動用 symlink / bind mount / 同步腳本去拉齊。
2. 共用的應該是「個人偏好 / 規則」型記憶（user / feedback 類），不是 process-specific 的東西（inflight checkpoint、TodoWrite 等 session state）。symlink 這種粗暴解最簡單、不需要寫額外程式、檔案系統層級就保證一致，比寫雙向同步腳本可靠得多。

放更大的框架看，今天兩件事其實是同一個主題的兩面：memory 設計的關鍵不是「自動 vs 手動」，是「對你工作流有意義的東西要被記下來、並且能被找回」。claude-mem 自動但記太多會雜訊蓋住信號；CC Bot 跟 TUI 不同步等於「明明記了但找不到入口」——兩種失敗模式都會讓 memory 系統失去價值。今天剛好把這兩個失敗模式都摸過一遍，下次再評估類似工具或設計新流程，會更有 sensibility 知道哪裡會壞。

今日收集的資源

• thedotmack/claude-mem — 自動 session 記憶外掛

  • 連結：https://github.com/thedotmack/claude-mem
  • 一句說明：5 lifecycle hooks 自動爬 tool calls + SQLite + Chroma 向量 DB + Web 可視化 + MCP 三工具，69.7K ⭐ AGPL-3.0；今天評估後決定不裝，已寫成 12 維度比較表 + 後果分析決策筆記留底（理由：跟現有人工編審的 memory 系統設計哲學打架、token 疊加、維護成本反增）

• @nomadni2020 Threads — Claude 帳單省 5 招

  • 連結：https://www.threads.com/@nomadni2020/post/DXtztu-CTZF
  • 一句說明：5 招清單：/models 切模型（瑣事 Haiku 不要全 Opus）、換任務 /clear 大任務前 /compact、有 CLI 不走 MCP（省 schema 灌爆 context）、裝 Context-Mode（MCP token 省 50–90%）、Mac mini 副機掛 Ollama 跑簡單任務省 Haiku 配額——剛好命中我多 MCP 重灌 schema 的場景

• @automoney_gda Threads — Trello 當 AI Agent 任務看板

  • 連結：https://www.threads.com/@automoney_gda/post/DXvxIxpFceF
  • 一句說明：把 AI Agent 任務管理從聊天升級成卡片、狀態流轉清楚（指派 → 執行 → 回報 → 修正全在同一張卡片）；觸發我寫了一份 Dashboard 看板 + GitHub Issues 兩層架構的 4-phase 升級計畫進 todo-list（先做 Phase 1 + 2 跑兩週驗證需求是否真實再決定要不要往下走）

• CC Bot ↔ TUI memory 同步

  • 連結：dotfiles repo 內部變更
  • 一句說明：發現 Claude Code 用「啟動目錄」當 memory key 導致 CC Bot（launchd 從家目錄啟動）跟 TUI（從 Desktop/Claude Code專用檔 啟動）兩條完全獨立 memory 夾、CC Bot 只看到 88 bytes 的 stub；symlink 收編到 dotfiles/claude/memory 後共用 100 個檔，重啟 launchd job 生效——學到「多 process 共用個人偏好型 memory 用 symlink 比寫同步腳本可靠」