Claude Code 技巧：跨專案 Session 搜尋，0.1 秒找到任何對話 — 編譯摘要

濃縮

核心結論：

1. Claude Code 的跨專案知識傳遞可以從「手動整理文件」升級為「直接搜尋歷史 session」——JSONL 保留完整對話（含失敗方案和決策脈絡），比摘要文件更有價值。
2. ripgrep 掃描 766MB（38 個專案、899 個 JSONL）只需 0.1 秒，不需要快取——最簡單的方案碰巧也是最快的。
3. Session 命名（/rename）是這套方案的前提——沒命名就搜不到，養成命名習慣是關鍵。

關鍵證據：

• Session 名稱藏在 JSONL 的 local_command 系統訊息中，包含 sessionId、cwd、名稱、timestamp。
• 完整的 shell 腳本支援：列出全部、關鍵字搜尋、專案篩選、詳細資訊查看。
• 包裝成 Skill 後，可用自然語言搜尋：「幫我找之前跟 deploy 有關的對話」。

質疑

結論 1：搜尋歷史 session > 手動整理文件

• 前提假設：完整對話紀錄比精煉摘要更有價值。但完整對話中可能有大量噪音（除錯嘗試、閒聊），找到關鍵資訊的認知成本更高。
• 邊界條件：JSONL 只增不減，長期使用後資料量可能影響搜尋速度（雖然目前 ripgrep 效能充足）。
• 反例：如果跨專案的知識是概念性的（如設計模式、架構決策），對話紀錄的細節反而是干擾。

結論 2：ripgrep 不需快取

• 前提假設：全量掃描永遠比索引查詢快。當資料量增長到 TB 級別時，快取/索引可能成為必要。
• 換場景：SSD vs HDD 的儲存介質差異可能顯著影響掃描速度。

結論 3：Session 命名習慣

• 前提假設：使用者願意多做一步命名。但在高頻使用時，命名成為額外負擔。
• 反例：自動命名（如根據首次提問自動摘要）可能是更好的方案。

對標

1. 全文搜尋引擎（Elasticsearch）vs 檔案系統搜尋（grep）：在資料量適中時，簡單工具（grep/ripgrep）比重量級方案更實用。
2. 筆記軟體的搜尋功能：Notion、Obsidian 的全域搜尋本質上也是在大量文字中快速定位資訊。
3. Git log 的搜尋：git log --grep 從 commit 歷史中搜尋特定變更，與從 session 歷史中搜尋特定對話的邏輯相同。

關聯概念

• [[Session 管理與知識傳遞]]
• [[Claude Code Skill 系統]]
• [[開發工具鏈整合]]