導讀：同樣一套 Claude Code，有人用來自動化整個開發流程，有人只會請它「幫我解釋這段程式碼」——差別不在智力，而在設定。
TL;DR
.claude/資料夾分專案層（團隊共用）與全域層（個人偏好），搞清楚放哪裡是第一步。- CLAUDE.md 的遵從率只有 80%，Hooks 卻是 100%——真正要強制執行的規則，絕對不要只寫在 CLAUDE.md。
- 過度工程化是深淵：有人花四個月打造複雜配置，最後刪掉了 60%。從簡單開始，按需疊加。
你以為在同一起跑線，其實差了一個架構師的距離
想像兩位開發者同時打開 Claude Code。
第一位，每次都在對話框裡打：「幫我 review 這段程式碼，風格要符合公司規範，記得檢查型別安全……」每次都要重複上下文，每次都祈禱 Claude 記得上次的設定。
第二位，什麼都不打。存檔的瞬間，Prettier 自動跑完；送出任何包含 rm -rf 的指令前，系統自動攔截並要求確認；輸入 /review，git diff 自動注入當前分支的所有變更，review 報告直接產出。
這不是魔法，是 .claude/ 資料夾的正確使用方式。差距的核心，在於你是否理解這套系統的設計邏輯。
四層洋蔥架構：搞錯放哪裡，規則就是廢紙
圖 1：從外到內——Global → Project → Hooks → Runtime，每層覆蓋前一層
.claude/ 的設定分四個作用域，像剝洋蔥一樣從外到內覆蓋：
- 組織層：整個組織的基底規範
- 使用者層（
~/.claude/）：你的個人偏好，不進 git，不影響別人 - 專案層（
.claude/，進 git）：團隊共用的規範與工具 - 本地覆蓋層：針對特定情境的臨時調整
大多數人只知道第三層，把所有東西都堆進專案的 CLAUDE.md——個人習慣、公司規範、臨時 workaround，全部混在一起。結果就是：團隊成員被你的個人偏好綁架，或者你的個人設定不小心污染了專案設定。
這裡還有一個常被忽略的細節：CLAUDE.md 必須控制在 200 行以內。 超過這個數字，實測遵從率會明顯下降。Claude 不是真的「忘記」了後面的內容，而是在長文件中，後段規則的權重會被稀釋。
更進階的做法是使用 rules/ 子資料夾，把規則按路徑範圍拆分——前端規範只在 src/components/ 目錄下載入，後端規範只在 api/ 目錄下載入。這樣不只讓規則更精準，還能大幅減少每次對話消耗的 token 數量。
80% 對上 100%：為什麼 Hooks 才是真正的護城河
這是架構師與菜鳥之間最關鍵的認知差距。
CLAUDE.md 的遵從率約 80%。這不是 Claude 偷懶，而是語言指令的本質——它是建議，不是約束。你寫「禁止使用 console.log」，Claude 大部分時候會遵守，但在某些推理路徑下，它就是可能滑過去。
Hooks 的遵從率是 100%。 因為 Hooks 是系統層面的強制執行，不經過 Claude 的判斷。
幾個實際案例說明這個差距有多大：
- PostToolUse Hook：每次 Claude 修改檔案後，自動觸發 Prettier 格式化。你的 codebase 永遠保持一致風格，不管 Claude 這次有沒有「記得」要格式化。
- PreToolUse Hook：在 Claude 執行任何 Bash 指令前先掃描，偵測到
rm -rf就攔截，要求使用者確認。這道護欄不依賴 Claude 的自我審查，它是物理層面的阻斷。
這個邏輯延伸到更大的架構選擇：想要建議？用 CLAUDE.md。想要強制？用 Hooks。 把這兩者混用，是大多數初學者踩的最貴的坑。
settings.json 也是強制層的一部分——它是客戶端層面的硬性設定，但要注意，Bash 的 deny 規則不會約束子程序。真正的路徑隔離，需要 sandbox 環境，這是另一個層次的話題。
四個月後刪掉 60%：過度工程化的死亡陷阱
說到這裡，可能有人已經在腦子裡規劃一套宏大的配置系統了。先停一下。
有位工程師分享了一個真實經歷：他花了四個月打造自己的 Claude Code 配置，拆分了大量 rules/ 子資料夾，建立了複雜的 Hooks 流水線，還整合了多個自訂 Skills。系統看起來非常精緻。
四個月後，他刪掉了其中 60%。
原因很簡單：複雜的系統需要複雜的維護。 有些規則在特定情境下造成摩擦，有些 Hooks 在邊緣案例中觸發了不該觸發的行為，有些 Skills 隨著 Claude 模型升級後反而變成了枷鎖——因為模型本身已經能直接處理那個問題了，而 Skills 的存在反而限制了它的發揮空間。
過度工程化的訊號很明顯：當你花在維護配置的時間，開始超過配置為你節省的時間，你就越過了那條線。
行動建議：三步起手式，不要四步
第一步：先建立個人全域設定（~/.claude/CLAUDE.md）。 把你的個人習慣、常用風格偏好放在這裡。它不進 git，只服務你自己。
第二步：專案層只放團隊必須對齊的規範。 命名慣例、架構邊界、禁止的套件——這些才是真正需要進 git 的東西。控制在 150 行以內，留 50 行給未來的擴充。
第三步：把最重要的規則寫成 Hooks，而不是祈禱 CLAUDE.md 管用。 找出你的專案裡那個「一定不能犯的錯」，把它變成 PreToolUse Hook。這一個 Hook 帶來的安全感，抵得上 100 條 CLAUDE.md 規則。
至於 Commands、Skills、多 Agent 並行架構——那些是下個月的事。先把這三步做紮實，你已經超越了 90% 的使用者。
互動埋點：你的 Claude Code 配置現在最讓你頭痛的是什麼？是規則沒被遵守，還是設定太複雜搞不清楚放哪裡？
References
- Anthropic (2025). Anatomy of the .claude/ folder — project vs. user scope design. Anthropic Documentation / Blog.
- Community Contributors (2025). 40 practices that changed everything — Claude Code power user guide. Developer Blog / Community Post.
- Engineering Team (2025). .claude 資料夾團隊配置指南 — team-level configuration patterns. Internal Guide / Blog Post.
- Pachaar, Akshay (2025). Thread on Claude Code Hooks and CLAUDE.md compliance rates. X (Twitter).