你有沒有這種經驗：跟 Claude 工作了兩小時，關掉對話窗，隔天再開——它完全不記得昨天做了什麼。
Claude Code 的 context window 很大，但它有一個根本限制：session 結束，記憶歸零。這帶來三個痛點：
每次開新 session，重新解釋專案架構、上次改到哪、為什麼做了某個決定。一天三次 session，浪費半小時。
上週討論 30 分鐘決定用 A 方案，這週它又建議 B 方案。更糟的是——你自己也不一定記得為什麼選了 A。
跨 session 的任務每次都手動交接：「上次做到 Step 3」「這些檔案改了那些沒」。人腦不該做這種工作。
讓 Claude 自己管記憶——開場讀上次紀錄、結束寫這次紀錄。三個 slash command 搞定。
Session 開始 → 讀上次的紀錄 → 接續工作
Session 結束 → 寫這次的紀錄 → 下次能接| 指令 | 做什麼 | 何時用 |
|---|---|---|
| /start | 讀記錄，顯示「上次做到哪」 | 每次開 session |
| /save | 存當前進度（中途檢查點） | 做完一個里程碑 |
| /wrap-up | 完整收尾 + 存檔 | 要關掉 session 時 |
零依賴，3 分鐘設定。所有記錄存在你電腦上的一個 SQLite 檔案裡。
進階版。語意搜尋、多裝置同步、namespace 隔離、baton 追蹤。
| 比較 | SQLite（方式 A） | memhall（方式 B） |
|---|---|---|
| 設定時間 | 3 分鐘 | 30 分鐘（Docker） |
| 搜尋 | Keyword match | BM25 + 向量語意 |
| 跨裝置 | ✗ | ✓ |
| 多專案隔離 | ✗ | ✓ Namespace |
| 團隊共享 | ✗ | ✓ team-memhall |
| Open Loop 追蹤 | ✗ | ✓ Baton |
| 外部依賴 | Python（內建） | Docker + API server |
你：/start
Claude：
## Session 開場 Summary
**上次進度**（2026-07-07 wrap-up）：
重構 auth 模組，已完成 token refresh 邏輯，
剩下 middleware 整合還沒做。卡在 CORS 設定。
**下一步**：先解決 CORS，再整合 middleware。
要接續嗎？不用花 10 分鐘交代背景——Claude 自己讀到了。
你：我想用 Redis 來做 cache
Claude：（讀到 session 記錄）
注意：2026-06-20 的 session 記錄顯示，
你們當時評估過 Redis vs 本機 LRU cache，
最後選了 LRU cache，理由是「這個服務單機部署，
Redis 增加維運成本但沒有跨節點需求」。
現在的需求有變嗎？你：先這樣，我去吃飯
Claude：
## Session 摘要
- **完成**: 修復 #117 附件上傳，部署到 trac-server
- **未完成**: API 文件更新
- **下一步**: 更新 MCP-API.html，加入 attachment endpoints
- **關鍵決策**: 用 Trac 1.6 SHA1 hashed path 而非自訂路徑
- **寫入紀錄**: SQLite ✓ | job-memo ✓下次 /start 就能看到這些。
如果你一開始用 SQLite，後來想要語意搜尋或多裝置同步，可以無痛升級：
記憶的格式是相容的——slug、content、tags 的結構不變。
最快的方式：花 3 分鐘設定 SQLite 版。