實戰範例 009：第一次使用 Claude-Mem — 跨會話儲存並取回一條架構觀察 · Claude-Mem

實戰背景

第一次接觸 Claude-Mem 的開發者最常問的問題是：「記憶到底有沒有真的存下來？」文件上寫得再完整，都不如自己跑一次「存一條、關掉、再開、看它還在不在」的端到端驗證。

痛點與問題描述：我們的專案是一個跑在 Cloudflare Workers 上的 TypeScript API。團隊剛剛定下一條容易踩雷的硬性規則：所有時間欄位一律以 UTC 並使用 ISO 8601 字串儲存，禁止使用本地時區或 Unix timestamp。過去已經有兩次因為新人不知道這條規則，而把 new Date().toLocaleString() 寫進儲存層，造成資料錯亂。

我們希望把這條規則寫進 AI 的長期記憶，並且確認：即使關掉目前的對話、明天再開一個全新 Session，AI 依然會自動讀到它。

本範例走完 Claude-Mem 最小閉環：install → save_observation → 重啟 → get_observations。

前置作業：安裝 Claude-Mem

Claude-Mem 透過 npx 一鍵安裝，安裝器會把 MCP 伺服器註冊到你的 Claude Code（或 Cursor、OpenCode 等支援的平台）。

npx claude-mem install

安裝完成後，重啟你的 AI 助手，確認 claude-mem 已掛載為可用的 MCP。你可以請 AI 列出可用工具，看到 save_observation、get_observations、timeline、forget 四支工具就代表記憶層已就緒。

端到端 5 輪協作紀錄

── 第 1 輪（Session A）：用白話確認共識 ──

You:

我們專案跑在 Cloudflare Workers，所有時間一律存成 UTC 的 ISO 8601 字串，
不准用 toLocaleString，也不准用 Unix timestamp。請幫我把這條規則寫進長期記憶。

AI:

收到，這是一條典型的架構層級約束，值得顯式寫入長期記憶，避免之後被自動壓縮流程稀釋。我將調用 save_observation。

CM 呼叫:

save_observation(
  key: "datetime_storage_policy",
  value: "所有時間欄位必須以 UTC 並使用 ISO 8601 字串儲存（例如 2026-08-13T03:45:00.000Z）。嚴禁使用 Date.prototype.toLocaleString 或 Unix timestamp。理由：Cloudflare Workers 跨區執行，本地時區會造成資料錯亂。",
  category: "architecture"
)

CM 回傳: {"status": "saved", "observationId": "obs_2041"}

規則已落盤，ID 為 obs_2041。請記下這個 ID，後續若要更新或刪除會用到。

── 第 2 輪（Session A）：實際驗證寫入成功 ──

You:

用 get_observations 反查一下 datetime_storage_policy，確認真的寫進去了。

AI:

我用同一個 key 反查，確保不是只寫不讀。
CM 呼叫: get_observations(query: "datetime storage policy") CM 回傳:
```
[
  {
    "observationId": "obs_2041",
    "category": "architecture",
    "summary": "所有時間欄位必須以 UTC ISO 8601 字串儲存，禁止 toLocaleString 與 Unix timestamp。"
  }
]
```
確認寫入成功。同一個 Session 內讀回只是基本款，真正的考驗是跨 Session。

── 第 3 輪：關閉 Session，隔天再開 ──

關掉這個對話視窗，徹底結束這個 Session。Claude-Mem 的持久化資料是落在本地 SQLite，不會隨對話消失。

隔天，開一個全新的對話。不要先貼任何上下文，直接交付一個會踩到時間規則的任務，看 AI 會不會自己把記憶撈回來。

── 第 4 輪（Session B）：交付新任務，看 AI 是否自動取回 ──

You:

幫我在 /v1/logs 路由加一個 audit 欄位，記錄請求進來的時間。

AI:

動手前我先查專案對時間儲存的歷史決策。

CM 呼叫: get_observations(query: "time date timestamp storage") CM 回傳:

[
  {
    "observationId": "obs_2041",
    "category": "architecture",
    "summary": "所有時間欄位必須以 UTC ISO 8601 字串儲存，禁止 toLocaleString 與 Unix timestamp。"
  }
]

提醒：根據 obs_2041，新欄位必須用 UTC ISO 8601 字串。我會這樣寫：

// src/routes/logs.ts
app.post('/v1/logs', async (c) => {
  const auditTimestamp = new Date().toISOString(); // UTC ISO 8601，符合 obs_2041
  // ...後續邏輯
});

注意我沒有用 new Date().toLocaleString('zh-TW')，也沒有用 Date.now() 存整數，兩者都被 obs_2041 禁止。

── 第 5 輪：用 timeline 回顧這條記憶的誕生軌跡 ──

You:

用 timeline 看一下 obs_2041 是什麼時候、在哪個 Session 寫進來的。

AI:

timeline 可以把記憶按 Session 時間軸排開，回顧脈絡很方便。

CM 呼叫: timeline(query: "datetime_storage_policy") CM 回傳:

[
  {
    "sessionDate": "2026-08-12T09:14:00Z",
    "summary": "Session A：使用者確立 UTC ISO 8601 為唯一時間儲存格式，顯式 save_observation 寫入 obs_2041。",
    "observationId": "obs_2041"
  },
  {
    "sessionDate": "2026-08-13T03:45:00Z",
    "summary": "Session B：實作 /v1/logs audit 欄位時自動取回 obs_2041 並套用。",
    "observationId": "obs_2041"
  }
]

兩個 Session 之間隔了一天，記憶完整延續。這就是 Claude-Mem 跨對話持久化的核心價值。

關鍵學習點

最小驗證閉環：install → save_observation → 重啟 → get_observations，五分鐘就能確認 Claude-Mem 在你的環境真的可用，不需要跑完整工作流才相信。
顯式寫入勝過自動壓縮：架構層級的硬性規則（命名、時間格式、框架限制）值得用 save_observation 主動寫入並自訂 key，後續反查與更新都比自動壓縮的摘要可靠。
記下 observationId：寫入回傳的 obs_XXXX 是後續 forget、更新或時間軸回溯的控制碼，第一次使用就養成記 ID 的習慣。
跨 Session 才是真考驗：同一個對話內讀回只是基本款；關掉、重開、丟一個會踩到規則的新任務，AI 主動取回記憶，才代表持久化真正落地。