2026-04-07 踩坑實錄 · 真實案例

Claude Code 設定陷阱
本地覆蓋全局，AI 瞬間失憶

settings.local.json 遮蔽了 settings.json，導致 Hooks 消失、記憶碎片化。
花了半天才搞清楚：你以為 AI 記得你，其實它讀到的是空記憶。

Part 1：問題發現 Part 2：原因分析 Part 3：記憶碎片化 Part 4：GitHub Issues Part 5：雙機架構 Part 6：解決方案 Part 7：防止再犯 Part 8：FAQ
1
問題發現：Claude 怎麼不認識我了？

Thomas 讓 Claude 刪除 AnyDesk，正常完成。接着讓 Claude 記住百度網盤路徑，Claude 也照做了。一切看似正常——直到 Thomas 問了一句：

「你剛才有沒有觸發 Stop Hook？」

Claude 的回答暴露了問題：「你有沒有設定 hooks？」——它根本不知道自己有 Stop Hook。

事件時間線
Step 1 — 正常操作
Thomas 讓 Claude 刪除 AnyDesk，Claude 正常執行完畢。
Step 2 — 存記憶
Thomas 讓 Claude 記住百度網盤路徑。Claude 存到了本地記憶——但主記憶庫有 40+ 條，這裡只有 2 條。
Step 3 — 問 Hooks
Thomas 問 Claude 是否觸發了 Stop Hook。Claude 反問：「你有沒有設定 hooks？」
Step 4 — 發現異常
Thomas 意識到 Claude 只讀了 settings.local.json（沒有 hooks），完全沒讀全局 settings.json（有 Stop Hook）。AI 失憶了。
關鍵線索：Claude 反問「你有沒有設定 hooks」，代表它完全不知道全局 settings.json 裡的 Stop Hook 設定。這不是 AI 的問題——是它讀到的設定文件裡根本沒有 hooks。
settings.json
全局設定檔，包含 hooks、permissions、所有規則。這是你花時間精心調整的「完整配置」。
家裡的大書櫃，你的藏書全在這裡。
settings.local.json
本地設定檔，優先級更高。如果它存在，會覆蓋全局設定的同名 key。
你帶在身上的小筆記本——一旦你拿出來，就只看小筆記本，大書櫃的東西全忘了。
2
原因分析：「替換」不是「合併」

Claude Code 有兩層設定系統：全局的 settings.json 和本地的 settings.local.json。你可能以為它們會「合併」——local 的補充 global 的，兩邊都生效。

錯。合併規則是「替換」（override），不是「合併」（merge）。

合併規則圖解
settings.json
全局設定
hooks + permissions + memory
+
settings.local.json
本地設定
只有 permissions
=
最終結果
permissions 被 local 覆蓋
hooks 從全局繼承?

問題的核心：當 settings.local.json 有 permissions key 時，它會完全遮蔽全局 settings.json 裡的 permissions。同理，如果 local 裡有其他 key，也會遮蔽全局的相同 key。

核心問題
Thomas 的情況
Thomas 的全局 settings.json 有完整配置：hooks、permissions、memory 規則。

但啟動目錄下有一個 settings.local.json，裡面只有 permissions（因為兩台電腦路徑不同，所以需要本地設定）。

結果：Claude 讀了 local 的 permissions，但 hooks 設定就此消失——因為 Claude 讀到了 local，就不再去看全局的同類配置。
你以為的「合併」
全局有 hooks，local 有 permissions → 兩個都生效，各管各的。就像兩份通知疊加在一起看。
班規和校規互不衝突，兩邊都遵守。
實際的「替換」
local 存在就用 local，全局被遮蔽。local 沒有 hooks → hooks 就消失了。
班導師說「這學期只看我的規定」，校規直接無視。
GitHub Issue #17017 已經記錄了這個行為：settings 的合併規則是 key-level replace（鍵級替換），而不是 deep merge（深度合併）。這是社區長期抱怨的痛點。
3
記憶碎片化：隱形殺手

設定覆蓋只是問題的一半。另一半更隱蔽：記憶碎片化。Claude Code 根據你的啟動目錄建立項目級配置，每個目錄有自己的記憶庫。

Thomas 的記憶分散情況
啟動目錄 記憶條數 說明
C:\Windows\System32 2 條 Windows cmd 的預設目錄，幾乎是空的
C:\Users\Administrator 5 條 偶爾從這裡啟動，零散幾條
D:\Backup\Downloads 40+ 條 主工作目錄，完整的記憶庫
陷阱
從 System32 啟動 = AI 失憶
Windows 的 cmd 預設打開在 C:\Windows\System32。Thomas 從這裡啟動 Claude Code，Claude 只能讀到 2 條記憶，而 Thomas 的主記憶庫（40+ 條）在 D:\Backup\Downloads，完全讀不到。

你以為 AI 記得你的所有偏好、路徑、習慣。但實際上，它讀到的是幾乎空白的記憶。
記憶碎片化
Claude Code 會在每個「啟動目錄」下建立獨立的項目配置（.claude/ 資料夾），包含記憶（CLAUDE.md）。從不同目錄啟動，讀到不同的記憶。
你有三本日記，分別放在辦公室、客廳、臥室。每次只翻當下房間的那本，其他兩本的內容完全看不到。
cmd 預設啟動
C:\Windows\System32
→
Claude 讀到 2 條記憶
幾乎空白
→
看不到 hooks
settings.local 遮蔽
→
AI 完全失憶
你的 40+ 條記憶消失
4
GitHub 上的已知問題

Thomas 遇到的不是個案。以下是 GitHub 上的相關 Issues，全部指向同一個設計缺陷。

Issue 狀態 描述 與本文的關係
#17017 OPEN settings 合併規則是「替換」不是「合併」 最大痛點
#34822 OPEN settings.local.json 遮蔽全局 permissions 直接原因
#26770 OPEN Stop hook 在 settings.json 中不觸發 hooks 消失
#6305 OPEN hooks 在 session 啟動時快照鎖定 相關機制
一句話總結：四個 Issues 全部 OPEN。#17017 是根本原因（替換而非合併），#34822 是 Thomas 遇到的直接問題（local 遮蔽 global），#26770 是後果（hooks 不觸發）。
為什麼遲遲不修？
「替換」邏輯在某些場景下是合理的（比如你就是想讓某個項目完全覆蓋全局設定）。問題是 Anthropic 沒有提供選項讓用戶決定要「替換」還是「合併」，也沒有在文件裡清楚說明這個行為。
不是規則本身錯了，而是規則沒有寫在門口，你進來才被罰。
5
Thomas 的雙機架構

理解 Thomas 的架構才能明白為什麼這個坑特別深。他有台式機和筆記本兩台電腦，透過 GitHub repo 同步 Claude Code 配置。

架構概覽
settings.json（台式機版）
全局設定，包含 hooks、permissions、所有規則。進 git，兩台電腦共享。
公司的標準規章制度，每間分店都一樣。
settings.local.json（筆記本版）
本地設定，路徑不同（台式機 D: 盤 vs 筆記本 C: 盤）。不進 git，每台電腦各自維護。
分店的本地補充規定——因為當地法規不同，所以路徑要改。
同步機制
1
Junction + Symlink
把記憶（CLAUDE.md）、agents、commands 等文件夾用 Junction 指向 git repo 目錄。
效果：Claude 以為它在讀本地文件，實際上讀的是 git repo 裡的共享文件。
2
Stop Hook 自動同步
每次 Claude 回覆完畢，Stop Hook 自動執行 git add + commit + push。
效果：台式機改了記憶，筆記本 git pull 後立刻同步。
3
settings.local.json 的存在理由
兩台電腦的磁碟路徑不同：台式機 D:\Backup\Downloads，筆記本 C:\Users\abc25\repos\downloads-config。
所以 local 文件是故意設計的，用來處理路徑差異。問題是它意外遮蔽了 hooks。
諷刺的是：這套架構的每個部分都是對的——Junction 對的、Stop Hook 對的、local 文件也有正當理由。但合在一起，「替換」規則就把你坑了。
6
解決方案比較：一條命令 vs 一堆 Junction

Thomas 找到了兩個方案。兩個都能解決問題，但成本完全不同。

方案 A — Thomas 的選擇
改 cmd 預設目錄
+ 一條 registry 命令搞定
+ cmd 打開就在 git repo 目錄
+ Claude 自動讀到完整配置
+ 不需要額外維護
- 唯一風險：D 盤掛了 cmd 會報錯
（本機硬碟正常不會發生）
方案 B
每個目錄建 Junction
+ 不改系統設定
- 每個項目目錄都要建
- 兩台電腦都要建
- 維護成本高
- 新增目錄要記得再建一次
方案 A：改 cmd 預設目錄
Registry 命令（以管理員身份執行）
:: 台式機（D 盤）
reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun /t REG_SZ /d "cd /d D:\Backup\Downloads" /f

:: 筆記本（C 盤）
reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun /t REG_SZ /d "cd /d C:\Users\abc25\repos\downloads-config" /f

執行後，每次打開 cmd 會自動切換到你的 git repo 目錄。Claude Code 從這裡啟動，自然讀到完整的 settings.json 和 40+ 條記憶。

安全性驗證
1
不影響 Junction 和 Symlink
改預設目錄只是換了 cmd 打開時的起始位置，已有的 junction 和 symlink 完全不受影響。
2
系統命令照常運行
ipconfig、ping、netstat 等系統命令都在 PATH 裡，從任何目錄都能正常執行。
3
唯一風險極低
如果目標目錄不存在（比如 D 盤壞了），cmd 會報一行錯誤但仍然可用。本機硬碟正常運作時不會發生。
Thomas 的選擇理由：最簡單的解法往往最好。一條 registry 命令 vs 建十個 junction——改一次搞定 vs 每次新增目錄都要記得建 junction。選擇很明顯。
如果你要復原
刪除 AutoRun 設定
reg delete "HKCU\Software\Microsoft\Command Processor" /v AutoRun /f
7
防止再犯：存進共享記憶庫

Thomas 把這次教訓存進了共享記憶庫（CLAUDE.md），確保兩台電腦的 Claude 都知道這個規則。

存入記憶庫的規則
記憶規則 #1
禁止建立本地 settings 或獨立 memory
絕對禁止在任何項目目錄下建立 settings.local.json 或獨立的記憶文件。 所有配置必須通過全局 settings.json 管理，所有記憶必須存入共享記憶庫。

原因：本地設定會覆蓋全局設定，導致 hooks 消失和記憶碎片化。
記憶規則 #2
cmd 預設目錄已更改
台式機：D:\Backup\Downloads
筆記本：C:\Users\abc25\repos\downloads-config

所有 Claude Code 對話都從這些目錄啟動，確保讀到完整配置和主記憶庫。
記憶合併操作

Thomas 把三個目錄的記憶（System32 的 2 條、Administrator 的 5 條、Downloads 的 40+ 條）合併到主記憶庫 D:\Backup\Downloads，然後刪除其他兩個目錄的零散記憶。從此只有一份記憶。

效果驗證：改完後，Thomas 重新打開 cmd，Claude Code 自動啟動在 D:\Backup\Downloads，讀到完整的 40+ 條記憶，Stop Hook 正常觸發。問題徹底解決。
8
FAQ：常見問題
我只用一台電腦，也會遇到這個問題嗎？
會。只要你的 cmd 預設目錄和你存記憶的目錄不同，就會記憶碎片化。比如 cmd 預設在 C:\Windows\System32，但你的項目在 D:\projects，Claude 啟動時讀到的記憶可能是空的。
settings.local.json 是不是完全不該存在？
不是。它有合理用途：當兩台電腦路徑不同時，用 local 文件處理路徑差異。問題是它的「替換」邏輯太激進——只要它存在，就會遮蔽全局設定的同名 key。解法是確保 local 文件裡的 key 和全局設定不衝突，或者把需要的 key 也複製一份到 local 裡。
改 cmd 預設目錄會不會影響其他程式？
不會。這個 registry 設定只影響 cmd.exe 的 AutoRun 行為。PowerShell、Git Bash、Windows Terminal 的 profile 各有各的設定方式，不受影響。系統命令（ipconfig、ping 等）也不受影響，因為它們在 PATH 裡，從任何目錄都能執行。
怎麼檢查我的 Claude 讀到了哪些記憶？
直接問 Claude：「你現在能看到多少條記憶？列出你所有的 memory。」如果數量比你預期的少很多，說明你可能從錯誤的目錄啟動了，或者記憶碎片化了。
我有 Junction 指向共享記憶，還需要改 cmd 預設目錄嗎？
要看你的 Junction 覆蓋了什麼。如果你在每個可能的啟動目錄下都建了 Junction 指向同一份記憶和 settings，那不需要改。但如果只有部分目錄有 Junction，從沒有 Junction 的目錄啟動時還是會碎片化。改 cmd 預設目錄是最省力的兜底方案。
Anthropic 會修這個問題嗎？
GitHub Issue #17017 要求把「替換」改成「深度合併」或至少提供選項。目前 (2026-04) 還是 OPEN 狀態。在官方修復之前，最好的策略是：確保只從一個固定目錄啟動 Claude Code，並把所有需要的配置都放在那個目錄下。
給小白的四條建議
1
用兩台電腦共享配置？確認啟動目錄一致
兩台電腦的 cmd 預設目錄要指向各自的 git repo 目錄，確保 Claude 讀到同一套配置。
2
不要讓 settings.local.json 有多餘的 key
local 文件裡只放必要的差異（如路徑），不要放和全局設定重複的 key，否則會覆蓋全局。
3
記憶碎片化是隱形殺手
你以為 AI 記得你，其實它讀到的可能是空記憶。定期問 Claude 「你看到多少條記憶」來驗證。
4
最簡單的解法往往最好
改一條 registry 比建十個 junction 靠譜。維護成本為零的方案，永遠優先。