Claude 沒照 MD 做：找出載入與規則衝突

Claude 沒有照 CLAUDE.md 做時，繼續增加「一定」「絕對」通常無法指出原因。本篇用四種可重現的故障，教你分清楚檔案未載入、指引互相矛盾、舊資訊仍在上下文，以及相對路徑指向錯誤位置。最後產出的是別人可以照著重跑的診斷表。

先讀自動記憶、settings.json與規則工作坊。下載第 63 篇材料，開啟 starter。需要 Node.js 22 以上及可登入的 Claude Code；閱讀約 20 分鐘，實作約 45 分鐘。

先記錄失敗，不急著改字句

閱讀完整文字說明

Claude 沒照 MD 做：找出載入與規則衝突，以流程和文件圖形呈現教學重點。

好的故障描述至少包含啟動目錄、工具版本、檔案位置、原始任務、預期行為與實際行為。例如「從 starter 啟動，要求找測試命令，卻回答 npm run test:old」比「完全不聽話」容易調查。先以 claude --version 與目前路徑補齊環境，再保存不含私人內容的必要回答片段。

材料提供正確的 .claude/CLAUDE.md 與刻意過期的 config/broken-CLAUDE.md。正常基準是 node --test tests/model.test.mjs，應執行四個模型測試。先手動跑一次，確認終端機和教材檔案正常。若連這個命令都失敗，先處理 Node 或解壓縮問題，不能把所有失敗都歸因於 MD 載入。

claude --version
node --version
node --test tests/model.test.mjs

在編輯器另建 diagnosis.md，記錄每次只調整一個變因。保留原始規則副本，但不要把副本放到會自動載入的 rules 目錄；否則你以為已停用的舊規則仍可能繼續作用。診斷資料可放在 config/cases，明確標為故障材料。

案例一：檔名或位置不符合載入條件

先將練習專案的 .claude/CLAUDE.md 暫時改名為 CLAUDE.backup.md，保留在同一目錄，另開 Claude 工作階段。請它查看規則來源，而不是在提示詞貼入備份文件。預期自動載入不應把任意命名的備份當成標準 CLAUDE.md。然後恢復檔名，建立另一個新階段比較。

先確認本次可觀察到的專案規則來源，再找出模型測試命令。
請列出你實際讀取的檔案及命令出處。
若找不到某份規則，直接寫找不到，不要推測其內容。
這一輪不要修改檔案，也不要執行安裝。

使用 /memory 等版本提供的介面查閱來源，再看讀檔與執行紀錄。如果備份仍被模型主動讀取，要在紀錄寫「由工具讀檔取得」，不要寫成「自動載入」。這兩條取得資訊的路徑可能導致相同回答，但診斷結論不同。若檔名大小寫在本機能工作，也不要推定移到大小寫敏感環境一定相同。

本案例的完成證據是檔案位置與載入來源的對照，並且恢復後能找到正確測試入口。不要透過刪除個人整個 .claude 目錄來排查；那會混入更多變因，也可能影響其他專案。教材只調整自己解壓縮出的練習檔。

案例二：兩條規則互相矛盾

在有效的練習 CLAUDE.md 加上一句「待辦項目使用標題作為唯一識別」，同時保留原本「以 id 辨識，可有重複標題」。請 Claude 解釋 toggleTodo 應怎麼定位項目。這個設定刻意矛盾，沒有可靠的文字強調方式能讓兩句同時成立。

對照 model.js 與兩個同名項目的測試，選定符合教材資料契約的一條，刪除過期要求，並在診斷筆記記錄理由。不要只把正確句移到檔案最後就宣稱問題永遠解決；模型如何處理自然語言矛盾，不是你可以依賴的設定優先順序。真正的修正是消除衝突。

重新開啟工作階段，以相同問題重測，再請它指出如果依標題切換會造成哪個案例失敗。預期回答能連到具體資料及測試。若只得到「會遵循最新規則」，還沒有證明它理解了錯誤的影響，需要追查實際讀取了什麼。

案例三：舊資訊留在對話或記憶中

在同一段練習對話先告知「這是故障注入：假設測試命令是 npm run test:old」，之後更正檔案並請它再次回答。這一輪觀察的是對話上下文殘留，不應稱為自動記憶已故障。另開全新階段、只提供目前專案，再比較結果，便能分離兩個來源。

若 /memory 顯示有相關自動記憶，開啟該檔案確認內容，僅修正與本次練習直接有關的錯誤行。先保留差異，再重試。沒有看到記憶檔時，應記錄「未觀察到此來源」，不要為了完成實驗把所有個人記憶刪掉，也不要將一次錯答推論為記憶系統永遠不可靠。

長對話常會混有先前已放棄的方案。/compact 能整理上下文，但它不是把規格保存到版本庫，也不是所有錯誤資訊必定消失的保證。需要跨階段繼續的事實，請另外寫入交接文件，標明來源及目前版本。

案例四：同名檔案與相對路徑

在 config/cases 下放一份同名 CLAUDE.md 作為故障材料。從專案根目錄與子目錄各確認一次當前路徑，記錄你實際編輯的是哪個檔案。若你修改的是 config/cases/CLAUDE.md，卻在根目錄測試另一份規則，重啟再多次也不會修好目標檔。

node -e "const fs=require('node:fs');const p=require('node:path');console.log(process.cwd());for(const f of ['.claude/CLAUDE.md','config/cases/CLAUDE.md'])console.log(p.resolve(f),fs.existsSync(f));"

若規則內用 @ 引用其他 MD，以該引用文件所在位置檢查相對位置，逐個開啟連到的檔案。練習時故意指向不存在的檔名，觀察系統提示或模型是否能讀到，再修回。引用失敗與權限拒絕、檔案不存在是不同原因，診斷表不要把它們都縮成「找不到」。

多份規則存在時，先畫出來源與適用範圍。個人偏好、組織管理設定、專案規則及子目錄規則並非同一種機制。尤其 JSON 的權限優先順序不能套用來推導每句自然語言規則一定如何覆蓋，必要時回到分層規則實驗重做最小案例。

用一次只改一個因素縮小問題

若同時搬動規則、修改路徑模式與換工作階段，即使最後成功，也不知道是哪一項修正生效。先固定其他條件，只改最小可疑因素，保留之前的檔案位置和讀取結果。接著逐步加入子目錄規則，每次都使用不同辨識標記，才能追查實際來源。

辨識標記只適合實驗環境，不應成為正式規則的一大串暗號。確認載入關係後，把標記換成有意義的工作要求，並保留一張「檔案位置、適用範圍、確認方法」表供日後維護。

把診斷寫成可以重現的紀錄

每個案例保留七項資料：變因、修改前檔案、原始任務、新階段與否、可見證據、修正方式、修正後結果。記錄可用「預期」「實際」「仍未知」三欄，讓沒有直接看見的載入資訊保留為未知。模型對自己行為的解釋只能算輔助證據。

小練習是請另一位讀者只看 diagnosis.md，重現其中一個故障。對方若還需要詢問你「在哪裡啟動」「改哪份檔案」，就把那些資訊補上。完成四個案例後恢復正確規則，執行模型測試，確認沒有把故障注入留在下一篇要使用的專案。

本篇完成的標準是四個具體根因及對照證據，不是保證所有未來回答都相同。自然語言指引仍需要成果驗證；真正限制操作範圍的部分，接著交由權限與 Sandbox處理。

回 Claude Code 教學總目錄

• AI 工具
• 教學
• Claude Code