場景是這樣的。你在一個 monorepo 裡工作，剛剛在 services/auth 這個模組跟 Claude Code 來回了二十幾輪——它讀過這塊的 CLAUDE.md、摸清了你的 service 怎麼串、改完了一個 bug。現在你要去隔壁 services/billing 做下一件事。

過去你只有兩條路，而且兩條都不太舒服。

第一條，開一個新 session。乾淨是乾淨，但剛才那二十幾輪建立起來的上下文全沒了，你得重新跟它解釋一遍這個 repo 的慣例。更痛的是 prompt cache 從零開始重建——前面那段對話本來已經被快取住、每輪只算增量，現在等於把整本書重新影印一次，又慢又貴。

第二條，用 /add-dir 把 billing 加進來。但這個指令的本意不是「搬過去」，是「順便也讓我看得到那個資料夾」。你的 session 還釘在 auth，billing 的 CLAUDE.md 預設不會自動載入，--resume 之後也還是從 auth 找回來。它解的是「跨目錄讀檔」，不是「換工作目錄」。

繞了一圈會發現，你真正想要的那件事——「把這場對話原封不動搬到新目錄，cache 別重燒」——以前還真沒有一個乾淨的做法。Claude Code 在 6 月 8 日的 v2.1.169 補上的 /cd，補的就是這個洞。

它就是字面上的意思，但魔鬼在 cache 那一句

/cd 的官方描述很短：把這個 session 移到新的工作目錄。重點全在後面那句——對話的 prompt cache 會被保留。

怎麼做到的？官方講得很直白：新目錄的 CLAUDE.md 是「當成一則訊息附加上去」，而不是去重建系統提示。同時這個 session 會被重新定位到新目錄的專案儲存空間，所以你之後 --resume、--continue 都能在新目錄找到它。如果你沒在那個目錄工作過，它會先跳出來問你信不信任。

用起來就一行：

1
/cd services/billing

對話接著走，context 還在，cache 沒重燒。聽起來像變魔術，但只要搞懂 prompt cache 是怎麼運作的，就會發現這一點都不神奇，反而是順理成章。

先搞懂 cache 為什麼那麼容易被弄壞

prompt cache 你可以想成一本你跟 Claude 共讀的書，由上往下分三層、越上面越少動：

最上面是系統提示層——核心指令、工具定義、輸出風格。這層只有在你升級 Claude Code、或工具集變了的時候才會改。中間是專案上下文層——CLAUDE.md、自動記憶、那些不分目錄的規則，通常在 session 啟動或 /clear 之後才重建。最下面是對話層——你的每一句話、Claude 的每一個回應、每個工具呼叫的結果，這層每一輪都在長。

關鍵的機制在這裡：cache 命中靠的是「前綴的精確匹配」。它不是按檔案、按段落分塊快取的，而是從書的第一頁開始逐字比對，只要中間某一頁變了，從那一頁往後的所有內容全部要重算。

那為什麼換個目錄就會踩到這條線？因為系統提示層裡，偷偷嵌了「工作目錄、平台、shell、OS 版本」這些環境資訊。你人在 auth 跟人在 billing，光是工作目錄這個字串不一樣，書的第一頁就不同了——前綴對不上，後面整本對話跟著作廢，全部重算。

這就是費曼會說的那種「名字騙了你」的情況：你以為 cd 只是換個資料夾的小動作，但在 cache 的世界裡，它動到的是整本書的第一頁。

/cd 的巧思：別去動第一頁

理解了上面那段，/cd 的設計就一目了然了。

它沒有去改系統提示層那個藏著工作目錄的第一頁——動了那裡，整本書就廢了。它選擇把新目錄的 CLAUDE.md 接在對話層的最後面，當成一則新訊息。對 cache 來說，前面那幾百頁一個字都沒變，前綴完整命中，只是書的結尾多了一頁而已。增量計算，省下的就是把整段歷史重新影印一遍的成本。

換句話說，/cd 不是「想辦法讓換目錄變便宜」，而是「換一個不碰前綴的方式去達成換目錄」。同一個目的，避開了會引爆 cache 的那一步。好的工具設計常常就是這樣——不是把貴的操作優化得快一點，是繞過去，讓那個貴的操作根本不發生。

那到底什麼時候該用哪個

三個動作長得有點像，但解的是不同的問題，分清楚才不會用錯：

/cd —— 你在做同一件事的延伸，要把整場對話搬到新目錄，而且想保住 context 和 cache。典型場景就是 monorepo 模組之間的接力。

/add-dir —— 你的工作主場不變，只是需要「順便看得到」另一個目錄的檔案。session 留在原地，不搬家。

開新 session —— 你要做的是一件全新、跟剛才無關的事。這時候你「不想」帶著舊 context，乾淨重來反而是對的，cache 重建是合理代價。

判準其實就一句話：你是想帶著這場對話走，還是想把它留下。想帶走、用 /cd；想留下、開新的；只是要多看一個資料夾、用 /add-dir。

幾個用之前該知道的邊界

信任提示會擋一下。 第一次 /cd 到一個沒去過的目錄，它會先問你信不信任那個目錄。這是設計上的安全閘，不是 bug。

可以用權限規則鎖住它。 如果你不希望某些 session 亂切目錄，可以在 settings.json 用 Cd 規則限制，甚至完全關掉：

1
2
3
4
5
{
  "permissions": {
    "deny": ["Cd"]
  }
}

或者只放行特定範圍：

1
2
3
4
5
{
  "permissions": {
    "allow": ["Cd(~/code/**)"]
  }
}

cache 還是有別的方式會被弄壞。 /cd 保住了「換目錄」這一刀，但別的操作照樣會讓 cache 失效——切換模型會整個重來、改 effort 層級會整個重來，MCP server 連上或斷開、plugin 開關也可能波及。所以 /cd 之後如果你又順手切了個模型，省下來的又吐回去了。把會動到前綴的操作集中處理、別跟 /cd 穿插著用，是個值得養的習慣。

老實說一句邊界：monorepo 的具體最佳實踐，官方文件目前沒有明文，上面那些用法是依它的設計邏輯推出來的。實際在你自己的 repo 結構裡跑跑看，再決定要不要把 /cd 排進日常流程。

回到那個 monorepo 的下午

現在再回到開頭。你在 auth 跟 Claude 聊完了，要去 billing。

你不用再開新 session 從頭解釋，也不用糾結 /add-dir 為什麼沒真的把你搬過去。一行 /cd services/billing，對話接著走，剛才建立的理解還在，cache 沒重燒——你省下的不只是那筆 token 錢，是「又要重新跟它講一遍這個 repo」的那股煩。

這功能小，小到很容易被當成又一個沒什麼的 slash command 滑過去。但它背後那個道理值得記著：很多看起來「就是慢、只能忍」的操作，慢的原因往往不是它本質貴，而是你用的那條路剛好踩到了某個會引爆成本的開關。看懂開關在哪，常常就能繞過去。/cd 是繞過 prompt cache 那顆開關的一個漂亮例子，而你手邊那些「每次都要重來」的麻煩，說不定也各自藏著一顆還沒被人找到的開關。

參考來源：Claude Code Slash Commands - 官方文件、Prompt Caching - Claude Code Docs