指令用途

在多人協作或在跨越數週的開發迭代中，專案代碼經歷了多次小重構與功能變更。如果新接手的 AI 助手只看當前的代碼現狀，是很難理解「代碼是經歷了哪些歷史妥協才演變成今天這個樣子」的。

timeline 是 Claude-Mem 提供的 開發脈絡時間軸工具。它記錄了所有歷史對話會話的摘要、修改檔案清單與變更提案。這給予了 AI 助手「逆向工程歷史脈絡」的能力，使其能還原出某個 Feature 或者是 Bug 是在什麼時間、因為什麼原因被寫入系統的。

運作流程

1. 時間軸排序：在 SQLite 中查詢所有的會話日誌（Session Logs），並依時間戳降序排列。
2. 變更映射：將每次提交（Commit）與當時的 proposal.md 進行映射關聯。
3. 日誌格式化輸出：回傳精簡的時間軸 JSON 樹狀結構。

實戰對話範例

範例：追蹤 PLC 逾時設定的變更歷史

• You:

  /opsx:explore "我想看看 PLC 連線超時時間（CommandTimeout）是在哪一天被修改的，為什麼要改？"

• AI:

  好的，我將調用 claude-mem 的 timeline 工具，檢索歷史開發會話時間軸中關於 “CommandTimeout” 的修改軌跡。

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

  [
    {
      "sessionDate": "2026-07-16T10:45:00Z",
      "changeId": "fix-ios-bluetooth-crash",
      "summary": "重構了 Swift 藍牙狀態機，解決 iOS 實機連線隨機崩潰。修改了 Info.plist 補齊藍牙權限。",
      "author": "James"
    },
    {
      "sessionDate": "2026-07-16T09:12:00Z",
      "changeId": "fix-plc-deadlock",
      "summary": "解決 PLC 通訊多執行緒嵌套鎖死 Bug。為了解決網路延遲，將全域 CommandTimeout 從 30 秒延長為 60 秒。",
      "author": "James"
    }
  ]

  分析：
  時間軸顯示，該參數是在 2026-07-16 09:12 由 fix-plc-deadlock 計畫修改的。當時延長至 60 秒的背景原因是「為了解決網路延遲引發的隨機斷線」。

  這讓我們了解了該設定的歷史緣由。接下來您想檢視當時變更的詳細 Git Diff 嗎？