CLAUDE.md 審查
針對CLAUDE.md檔案進行審查，找出那些實際上會降低輸出品質的失敗模式。
前提： CLAUDE.md會在每次會話時載入到上下文，因此每一行如果不是在產生價值，就是在浪費你的 token。大部分「模型不遵循指令」的問題，其實是指令本身的問題。
步驟
- 讀取目標檔案（預設為
./CLAUDE.md；如果專案中有巢狀的**/CLAUDE.md，也要檢查~/.claude/CLAUDE.md和這些巢狀檔案，因為最接近的檔案會勝出）。 - 針對每個維度進行評分，並引用具體失敗的行數。
- 輸出底部的報告格式。提出具體的重寫建議，而不是「考慮更具體一點」。
檢查項目
具體性 — 這是影響最大的維度。
- 標記無法驗證的指令：「寫出乾淨的程式碼」、「遵循最佳實踐」、「小心」、「使用好的命名」。
- 每個規則都應該可以通過閱讀 diff 來檢查。
「重構超過 40 行的函式」是可檢查的；「保持函式簡短」則不是。
命名錨點。
- 指向「設定檔」、「我們的 API 層」或「常見的模式」的規則，會迫使每次會話都要重新發現這些內容。請使用真實的路徑取代：
src/config/env.ts、src/api/client.ts。 - 驗證每個提及的路徑、指令和檔案名稱是否仍然存在。報告那些已不存在的路徑——一個指向已刪除檔案的
CLAUDE.md會積極地誤導模型。
陳舊性。
- 版本號碼、模型名稱和工具指令與儲存庫不再相符。
- 針對已移除的框架、腳本或目錄的指令。
- 對照
package.json、Makefile、pyproject.toml或同等檔案，交叉檢查建置/測試/lint 指令——一個錯誤的測試指令比完全沒有還要糟糕。
冗餘與浪費。
- 任何可以從程式碼本身推導出來的內容（檔案樹列表、依賴列表、重述函式的功能）。Claude 可以讀取儲存庫。
- 僅適用於某個偶發性任務的冗長程序：這些應該屬於技能（skill），其內容只有在使用時才會載入，而不是在每次對話時都佔用上下文。
- 適用於所有軟體的通用建議，因此對於這個專案沒有提供任何特定知識。
衝突。
- 互相矛盾的規則，或與程式碼實際行為矛盾的規則。標記衝突的雙方，並詢問哪個應該優先。
- 優先級驚喜：巢狀的
CLAUDE.md或~/.claude/CLAUDE.md覆蓋了作者預期的行為。
缺少的內容。 如果以下項目不存在，值得提出來：
- 如何執行測試、建置和 lint——自我驗證變更所需的三項基本操作。
- 不明顯的專案限制（不得觸碰的目錄、自動生成的檔案、必要的遷移步驟）。
- 真正令人驚訝且在快速閱讀程式碼時無法察覺的慣例。
輸出格式
## CLAUDE.md 審查 — <路徑> （<行數> 行）
**結論：** <一句話>
### 阻擋性問題
- L<行號>：<引用行> → <具體重寫>
### 值得修復的問題
- L<行號>：<引用行> → <具體重寫>
### 刪除（每次會話都消耗上下文，但沒有產生價值）
- L<行號>–<行號>：<什麼內容及原因>
### 缺少的內容
- <缺口> → <建議新增的行>
**編輯後預估大小：** <N> 行（從 <M> 行）
規則
- 引用真實的行號和真實的文字。切勿為了填滿區段而虛構發現。
- 如果某個區段沒有發現，請寫
無。——一個乾淨的檔案也是有效的結果。 - 優先選擇刪除而非重寫。最好的
CLAUDE.md必須足夠簡短，讓人們願意實際閱讀它。 - 除非被要求，否則不要編輯檔案。先報告。