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

Claude Code 的 session 搜尋沒有內建的跨專案方案。我們用一條 shell 指令，在 0.1 秒內掃完 766MB、橫跨 38 個專案的對話紀錄，找到任何一個命名過的 session。這篇記錄從發現問題到打造工具的完整過程。

問題的起點：跨專案的知識孤島

我們同時在維護多個專案——企業官網、旅遊平台、WordPress 外掛、SaaS 產品。每個專案都有自己的 Claude Code 對話紀錄，每天累積幾十到上百回合的對話。

一開始，當 A 專案需要用到 B 專案的經驗時，我的做法是這樣：先請 Claude Code 把當前的需求和解法整理成一份文件，存到專案裡。然後切換到另一個專案，把那份文件的絕對路徑貼給新的 Claude Code session，請它讀取後繼續開發。

這個流程有幾個問題。

第一，每次都要「主動」整理。忘了整理就等於沒做過。第二，整理出來的文件是靜態的摘要，丟失了對話中的來回推敲和關鍵決策脈絡。第三，跨專案一多，光是管理這些中繼文件就變成負擔。

某天我在想——Claude Code 的每一次對話不都完整保留在本機嗎？與其手動整理文件當作跨專案的橋樑，不如直接去翻歷史 session。

先搞清楚 Session 存在哪裡

Claude Code 的對話紀錄並不像你想像的那麼直覺。打開 ~/.claude/ 目錄，你會看到兩個關鍵位置：

~/.claude/sessions/ —— 存放正在執行的 session 的 JSON 元資料。每個檔案以 PID（Process ID）命名，內容長這樣：

{
  "pid": 15064,
  "sessionId": "39029d88-07fe-4752-ac2d-f17b13800bcf",
  "cwd": "/Users/user/SideProjects/codotx",
  "startedAt": 1775002864872
}

這裡有 session ID 和工作目錄。但問題是，這些檔案只在 session 執行期間存在，關掉就沒了。

~/.claude/projects/ —— 這才是重頭戲。每個專案的工作目錄會被轉換成資料夾名稱（把 / 換成 -），例如 /Users/user/SideProjects/codotx 變成 -Users-user-SideProjects-codotx。每個對話紀錄是一個 JSONL 檔案，以 session UUID 命名。

我們的專案目錄下有 899 個 JSONL 檔案，總共 766MB。每個檔案都是完整的對話紀錄——使用者訊息、助手回覆、工具呼叫，全部都在裡面。

那 Session 名稱呢？

用 /rename 指令幫 session 命名之後，名稱存在哪裡？這一步花了點時間才搞清楚。

活躍的 session 名稱會出現在 ~/.claude/sessions/<pid>.json 裡。但前面說了，這些檔案會隨 session 結束消失。

歷史 session 的名稱藏在 JSONL 對話紀錄裡。當你執行 /rename my-session 時，Claude Code 會在 JSONL 中寫入一條系統訊息：

{
  "type": "system",
  "subtype": "local_command",
  "content": "<local-command-stdout>Session renamed to: my-session</local-command-stdout>",
  "sessionId": "39029d88-...",
  "cwd": "/Users/user/SideProjects/codotx",
  "timestamp": "2026-03-30T04:40:27.526Z"
}

這條訊息同時包含了 session 名稱、ID、專案路徑和時間戳。換句話說，只要能從所有 JSONL 中把這些紀錄撈出來，就能建出完整的 session 索引。

用一條指令建索引

知道資料結構之後，解法變得很直接。ripgrep 是我們開發環境的標配工具，掃描大量文字檔是它的強項。

rg --no-filename 'Session renamed to:' ~/.claude/projects/ \
| jq -r '[.sessionId, .cwd, (.content | capture("Session renamed to: (?<name>.+)</local") | .name), .timestamp] | @tsv' \
| sort -t$'\t' -k4 -r \
| awk -F'\t' '!seen[$1]++'

這條指令做了四件事：

1. ripgrep 掃描所有 JSONL，找到包含 Session renamed to: 的行
2. jq 從 JSON 中擷取 session ID、專案路徑、名稱和時間戳
3. sort 按時間倒序排列
4. awk 去除重複（同一個 session 可能被 rename 多次，只取最新的名稱）

766MB 的資料，0.1 秒跑完。

輸出結果長這樣：

SESSION NAME                    PROJECT              DATE
────────────                    ───────              ────
how-to-find-session-quickly     codotx               2026-04-01
setup-reverse-proxy             codotx               2026-03-31
update-dns-config               codotx               2026-03-31
post-claude-memory              codotx               2026-03-31
update-ga-env                   codotx               2026-03-30
debug-backup-vendor             codotx               2026-03-30
外掛還原除錯                    codotx               2026-03-27
修改選單結構                    codotx               2026-03-26

38 個專案、49 個命名 session，一目了然。

包裝成 Shell 腳本

光有一條指令還不夠好用。我們在 ~/.claude/ 底下自己建了一個 scripts/ 資料夾（這不是 Claude Code 官方的目錄，純粹是我們自己放腳本的地方），把它包裝成一個 shell 腳本 find-session.sh，支援幾種使用場景：

# 建立腳本目錄（首次使用才需要）
mkdir -p ~/.claude/scripts

# 列出所有命名 session
~/.claude/scripts/find-session.sh

# 用關鍵字搜尋
~/.claude/scripts/find-session.sh "deploy"

# 只列某個專案的 session
~/.claude/scripts/find-session.sh -p codotx

# 組合使用：在某個專案中搜 api 相關的 session
~/.claude/scripts/find-session.sh -p codotx api

# 查看特定 session 的詳細資訊
~/.claude/scripts/find-session.sh -i update-ga-env

詳細資訊模式會顯示完整的 session 元資料，包括 JSONL 檔案路徑和 resume 指令：

Session: update-ga-env
ID:      5fb6323d-8330-4c36-8579-0d5376f24957
專案:    /Users/user/SideProjects/codotx
時間:    2026-03-30T04:23:58.179Z
Resume:  claude --resume "update-ga-env"
JSONL:   ~/.claude/projects/-Users-user-SideProjects-codotx/5fb...jsonl
大小:    980K (419 行)

有了 JSONL 路徑，就能直接讀取對話內容。有了 resume 指令，就能回到那個 session 繼續對話。

再包一層：做成 Skill

腳本解決了「怎麼搜」的問題，但每次還是要自己跑指令。能不能讓 Claude Code 自己知道怎麼搜？

Claude Code 的 Skill 機制就是為這種場景設計的。在 ~/.claude/skills/find-session/skill.md 裡定義一個 Skill，告訴 Claude Code 這個工具的使用方式和執行步驟：

---
name: find-session
description: 快速搜尋跨專案的 Claude Code session 對話紀錄
user_invocable: true
argument_description: "[關鍵字] 或 --info <session名稱>"
---

# Find Session：跨專案 Session 搜尋工具

直接執行腳本：
~/.claude/scripts/find-session.sh [ARGUMENTS]

設定完之後，在任何專案裡都能直接用 /find-session 指令搜尋。也可以用自然語言：「幫我找之前跟 deploy 有關的對話」，Claude Code 會自動呼叫腳本。

從「整理文件」到「直接搜尋」

回到最初的問題。以前跨專案傳遞知識，流程是這樣的：

1. 在 A 專案整理一份文件
2. 切換到 B 專案
3. 把文件路徑貼給 Claude Code
4. 等它讀完再繼續

現在的流程：

1. 在 B 專案說「幫我找之前 A 專案裡處理 XX 的 session」
2. Claude Code 用 /find-session 找到對應的 JSONL
3. 直接從對話紀錄中提取需要的脈絡

少了「手動整理」這個步驟，也不會因為忘記整理而丟失知識。更重要的是，JSONL 保留的是完整對話——包括試過但失敗的方案、中途的判斷轉折、最後為什麼選了某個做法。這些脈絡是摘要文件很難保留的。

幾個值得注意的細節

Session 沒命名就搜不到。 這套方案完全依賴 /rename。如果你沒有命名 session 的習慣，建議從現在開始養成。我的習慣是每做一個新任務就開一個新的 session，然後用 /rename 命名這個任務的名稱，用英文加 dash 的格式，例如 fix-deploy-error 或 integrate-payment-api。

JSONL 只增不減。 Claude Code 的對話紀錄是 append-only 的。即使你執行 /compact 壓縮 context window，磁碟上的 JSONL 不會變小。這代表搜尋的資料量會持續成長。目前 766MB 跑 0.1 秒，以 ripgrep 的效能來說，短期內不需要擔心。

不需要快取。 我一開始想說要不要建一個索引快取檔，每次搜尋從快取讀取。實測之後發現 ripgrep 直接掃全量比讀快取還快，而且不需要維護快取的更新邏輯。工程上最簡單的方案碰巧也是最快的。

常見問題

Claude Code 的 Session 對話紀錄存在哪裡？

Claude Code 的對話紀錄存放在 ~/.claude/projects/ 目錄下，依專案路徑分類。每個 session 是一個 JSONL 檔案，以 UUID 命名，包含完整的使用者訊息、助手回覆和工具呼叫紀錄。活躍中的 session 元資料則存在 ~/.claude/sessions/ 裡。

執行 /compact 會刪除 JSONL 對話紀錄嗎？

不會。/compact 只壓縮記憶體中的 context window，讓你能在不超出 token 限制的情況下繼續對話。磁碟上的 JSONL 檔案是 append-only 的，所有訊息（包括 compact 產生的摘要）都會持續追加，不會被修改或刪除。

怎麼讓 Claude Code 讀取其他專案的歷史對話？

找到目標 session 的 JSONL 檔案路徑後，可以直接請 Claude Code 讀取該檔案。或者使用 claude --resume "session名稱" 回到原本的 session 繼續對話。搭配本文介紹的 /find-session Skill，可以快速定位任何專案中的歷史對話。

---

想用 Claude Code 優化你的開發流程，或有跨專案協作的需求？歡迎聯絡我們，聊聊你的想法。