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

Claude Code

AI 文章延伸

AI 幫你讀這篇文章

選擇平台後可直接帶入閱讀脈絡,快速整理重點、補齊盲點,並延伸到同站相關文章。

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-errorintegrate-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 優化你的開發流程,或有跨專案協作的需求?歡迎聯絡我們,聊聊你的想法。

作品案例

看看我們打造的產品與專案。從 WordPress 外掛到 AI 客服方案,每一個作品都是實戰經驗的累積。

瀏覽作品案例

服務項目

WordPress 開發、WooCommerce 電商、LINE 整合、AI 解決方案,依據你的需求提供最適合的技術服務。

瀏覽服務項目

Contact

聯絡我們

若你有任何技術需求、專案諮詢或合作想法,歡迎隨時與我們聊聊(首次諮詢免費)。

  • 想打造 WordPress 網站或 WooCommerce 電商
  • 需要 LINE 整合或 AI 功能導入
  • 有產品點子想找技術合夥人一起實現
  • 既有網站需要改版升級或效能優化
  • 尋找長期穩定的技術顧問合作夥伴