Claude Code 環境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次講清

Thu, 23 Apr 2026 10:43:40 +0800

如果你用了 Claude Code 一段時間，很快就會發現一件事：模型本身當然重要，但你給它什麼環境、什麼邊界、什麼規則，同樣重要。

很多人一開始會把注意力放在「這次 prompt 要怎麼寫」，但真正把 Claude Code 用成熟之後，你會更在意另一件事：

它知不知道你是誰
它知不知道你怎麼工作
它知不知道哪些規則不能違反
它知不知道哪些事情必須先確認
它能不能長期記住這些邊界

Claude Code 之所以能變成一個成熟工具，不只是因為模型強，而是因為它有一整套機制，幫你把這些工作方式沉澱下來。核心上可以拆成四層：

CLAUDE.md
Rules
Memory
Hooks

這篇文章就把這四個部分一次講清楚。

為什麼環境配置比單次提示詞更重要

你可以把 Claude Code 想成你請來的一位助理。

第一天上工時，你不會只跟他說一句「幫我做事」，而是會給他一份說明書，告訴他：

你的身份是什麼
你的溝通語氣偏好是什麼
哪些操作必須先確認
哪些錯誤以前犯過、之後不能再犯
這個專案最重要的文件放在哪裡

這就是為什麼，長期來看，環境配置往往比單次 prompt 更重要。

因為 prompt 解決的是「這一次要做什麼」，而環境配置解決的是「以後每次都要怎麼做」。

第一層：`CLAUDE.md`

先從最基礎的開始。CLAUDE.md 本質上就是一個文字檔。

你可以在裡面寫給 Claude 的說明，例如：

你是誰
你在做什麼
你的溝通偏好
需要遵守的規則
當前專案的特殊背景
重要文件或目錄的位置

每次 Claude Code 啟動時，這份文件都會自動被送進上下文，所以模型一定會讀到。

我通常把它叫做「默契檔」，因為它本質上就是你和模型之間長期協作的默契。

`CLAUDE.md` 適合寫什麼

最適合寫進 CLAUDE.md 的，大致有這幾類：

身份與工作背景
溝通語氣與輸出偏好
全域性的行為規則
常會用到的重要專案背景
常見錯誤與避免方式

例如：

你的時區
你是否接受模型直接發送郵件或訊息
哪些操作屬於不可逆行為
你處理文件與檔案的習慣
安全規範與敏感資訊邊界

一個很重要的原則：盡量精簡

CLAUDE.md 有一個很重要的原則，就是一定要盡量精簡。

原因很簡單：它每次都會被強制注入上下文。

如果你寫得太長，就會佔掉大量上下文空間，導致真正重要的資訊被稀釋。模型不是不讀，而是注意力會分散，最後更容易漏掉你最在意的規則。

官方建議通常是最好不要超過 400 行。

我自己的習慣會更保守一些，盡量控制在 200 行以內。

`CLAUDE.md` 的常見作用範圍

CLAUDE.md 實際上有不同的放置層級，對應不同的作用範圍。最常用的是兩個：

1. User Level

這是全域層級。

它放在你的電腦環境裡，對你本機操作的所有專案都有效。

這個位置適合放：

你的身份資訊
通用的溝通偏好
你跨專案都適用的做事習慣
全域性的安全規則

例如，如果你的時區不是常見的預設值，而是曼谷時間，那這類資訊就很適合放在 user level，這樣模型之後幫你安排時間時就不容易出錯。

2. Project Level

這是專案層級。

它放在具體專案目錄下面，只對那個專案有效。

這個位置適合放：

專案專屬背景
只在這個專案裡成立的規則
專案目錄結構說明
這個專案的重要文件入口

舉例來說，如果一個專案處理財務，另一個專案處理人事，那兩邊的背景和限制顯然不同，就不應該混在同一個全域說明裡。

怎麼判斷該放哪一層

判斷方式其實很簡單：

你寫進去的東西，如果換到另一個專案裡還成立，那就放 user level。

如果一換專案就不成立，那就放 project level。

怎麼開始寫第一版

最常見的起手方式有兩種：

1. 用 `/init`

你可以直接在終端執行斜線命令 /init，讓 Claude 掃描目前專案，自動幫你生成一份基礎版 CLAUDE.md。

2. 讓 Claude 幫你整理

你也可以直接讓 Claude 去搜尋別人怎麼寫 CLAUDE.md，再結合你的情況問你問題，最後幫你整理成適合你自己的版本。

很多時候，這會比自己從零開始寫輕鬆得多。

一個很實用的習慣

在你和 Claude 長期協作的過程中，只要你發現某件事情屬於「以後一定要記住、不要再犯」的內容，就可以直接讓它寫進 CLAUDE.md。

不過寫之前，還是要先判斷：

這是全域規則
還是目前專案規則

不要把所有東西都塞進同一個檔案裡。

第二層：`Rules`

接下來是 Rules。

它和 CLAUDE.md 最大的差別，不是檔案形式，而是載入方式。

CLAUDE.md 是無論你做什麼，模型都會讀到。

而 Rules 的優勢在於：可以條件載入。

也就是說，只有在某些路徑、某些檔案、某些工具或某些場景下，這條規則才會被讀到。

為什麼條件載入很重要

因為上下文空間永遠是稀缺資源。

如果所有規則都無差別塞進上下文裡，就會發生兩件事：

模型負擔變重
真正關鍵的規則反而被淹沒

按需載入的價值就在這裡：讓模型在剛好的時候讀到剛好的資訊。

什麼時候該把規則從 `CLAUDE.md` 挪到 `Rules`

通常有兩種情況：

1. `CLAUDE.md` 太長了

如果你的 CLAUDE.md 開始超過 200 行，規則越來越多，重要內容被稀釋，那就該考慮把一部分規則拆出去。

2. 某些規則只和特定路徑相關

如果你已經很明確知道某些規則只在某些類型的檔案裡才有意義，例如：

只對 Python 腳本有效
只對某個 hooks 目錄有效
只對某個子專案有效

那這些規則就更適合移到 Rules。

`Rules` 最適合的場景

最典型的就是「特定情境、特定路徑、特定檔案類型」。

例如：

只在處理 hook 檔案時觸發的規範
只在某類腳本中要遵守的編碼規則
只在某個目錄下適用的工作方式

這些內容如果繼續塞在 CLAUDE.md 裡，其實不太划算。

第三層：`Memory`

第三個層面是 Memory。

它和 CLAUDE.md、Rules 一樣，也會進入模型上下文，但它最核心的差別是：

CLAUDE.md 是你主動設定的。

Memory 更像是 Claude 在協作過程中，寫給自己的筆記。

`Memory` 記的是什麼

當 Claude 判斷某件事值得記住，或需要短期保留，它就會把這些內容寫進 Memory。

常見內容包括：

你糾正過它的某種做法
你最近新增的偏好
當前專案的暫時狀態
你今天沒做完、明天還要繼續的事
你最近在跟哪些人合作
某些最近才提到的個人資訊或上下文

換句話說，Memory 更像動態知識，而不是長期制度。

`Memory` 和前兩者的差別

一個簡單的區分方式是：

CLAUDE.md / Rules：偏長期、偏制度、偏明確規則
Memory：偏暫時、偏動態、偏工作過程中的新理解

如果某件事只是在最近幾天有效，或專案狀態持續在變，那它通常更適合放進 Memory，而不是寫成長期規則。

`Memory` 也可以手動寫

雖然 Memory 有自動整理能力，但你也可以主動告訴 Claude：

請記下來我明天要做什麼
請記下來我要追蹤誰的狀態
請記下來這個月某個專案的關鍵節點

它也可以幫你寫進 Memory。

你也可以透過斜線命令 /memory 查看目前有哪些記憶，並手動編輯或刪除。

不過很多時候，我自己不會太頻繁手動維護，因為 Claude 本身也會定期整理這些記憶，把已經過時的部分清掉。

第四層：`Hooks`

最後也是最重要、最進階的一層，就是 Hooks。

前面講到的 CLAUDE.md、Rules、Memory，本質上都還是自然語言說明。

你寫了規則，模型通常會遵守，但它本質上仍然是在「理解之後再執行」。

只要還停留在自然語言，就會存在幾個問題：

模型偶爾會漏掉
規則太多時，注意力會分散
某些情境下，它會自己判斷這條規則不重要

這不是你寫得不夠認真，而是自然語言規則本來就很難做到 100% 強制。

`Hooks` 的本質是什麼

Hooks 不再是自然語言說明，而是一段腳本。

它是事件觸發的、程式層級的強制邏輯。

只要某個事件發生，這段邏輯就一定會執行，不會被模型「自己判斷後略過」。

這就是 Hooks 最關鍵的價值：

把「建議遵守」變成「必須執行」。

什麼時候該上 `Hooks`

當你發現某條規則已經寫進 CLAUDE.md 或 Rules，但 Claude 偶爾還是不執行，而且這件事一旦漏掉，風險又很大，那就應該考慮把它改成 Hooks。

簡單說：

低風險的，用規則
高風險的，用 Hooks

最典型的 `Hooks` 場景

最典型的，就是那些你絕對不希望出錯的動作，例如：

發郵件前必須確認
發 Slack、Outlook、Gmail 訊息前必須確認
刪除危險檔案前必須攔截
偵測到要外發密碼或 API Key 時必須阻止

如果這些要求只是寫成一句自然語言規則，模型有可能哪天真的忙中出錯，就送出去了。

但如果寫成 Hooks，只要事件發生，就會被強制攔截。

這才是程式層面的硬防線。

`Hooks` 常見的觸發時機

Hooks 可以設定在很多不同階段，例如：

對話剛開始時注入提醒
某個工具執行前先做檢查
某個工具執行後做結果校驗

你不一定需要自己知道那些專業術語。

很多時候，只要你能清楚描述需求，再讓 Claude 幫你判斷這條規則適不適合改成 hook，它就能幫你一起設計。

你也可以透過斜線命令 /hook 查看系統目前已經設定了哪些 hooks。

一套更實用的上手順序

如果你想把這四層串起來，我自己更推薦下面這條路徑：

第一步：先用 `/init` 生成基礎版 `CLAUDE.md`

不要一開始就手寫一份特別完整的規則文件。

先讓 Claude 幫你掃描專案，生成一個起點版本，再慢慢迭代。

第二步：邊用邊補

在協作過程中，只要你發現：

這件事以後一定要記得
這個錯誤以後不能再犯
這個偏好以後每次都適用

就讓 Claude 幫你寫進 CLAUDE.md。

第三步：當 `CLAUDE.md` 變長時，拆到 `Rules`

一旦你發現 CLAUDE.md 越來越長，模型開始不一定遵守每一條規則，就該考慮拆分：

哪些是全域規則
哪些只和某些路徑相關

把後者移到 Rules，改成條件載入。

第四步：再把高風險規則升級成 `Hooks`

如果某些規則即使寫了，模型還是偶爾會漏，而且漏掉代價很高，那就不要再停留在自然語言層面，直接升級成 Hooks。

也就是把「提醒」變成「強制」。

第五步：把暫時狀態交給 `Memory`

對於那些會過期、會變化、不是長期制度的內容，不要一股腦全寫進 CLAUDE.md。

更合適的做法是交給 Memory：

當前專案進度
最近合作對象
最近新增偏好
近期計畫和待辦

這樣上下文會更清爽，模型也更容易保持穩定表現。

這四層分別該記什麼

如果你想快速記住，可以直接用下面這個區分：

CLAUDE.md：長期默契、全域說明、專案基礎背景
Rules：按路徑或場景載入的專項規則
Memory：動態知識、暫時狀態、最近學到的東西
Hooks：高風險操作的程式級強制攔截

結語

很多人把 Claude Code 當成「會寫程式的聊天介面」，但真正用深之後，你會發現它更像一個長期協作的智慧工作台。

關鍵不只是你每次怎麼下指令，而是你有沒有給它一套穩定、清楚、能長期累積的環境。

一旦你把這四層搭起來：

CLAUDE.md
Rules
Memory
Hooks

你和模型之間的協作品質，通常會有非常明顯的提升。

因為你終於不是每次都從零開始解釋自己是誰、怎麼工作、哪些事不能做，而是把這些真正沉澱成了環境的一部分。

這才是把一個強模型，真正用成成熟工具的關鍵一步。

Memory on KnightLi的博客

Claude Code 環境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次講清

為什麼環境配置比單次提示詞更重要

第一層：CLAUDE.md

CLAUDE.md 適合寫什麼

一個很重要的原則：盡量精簡

CLAUDE.md 的常見作用範圍

1. User Level

2. Project Level

怎麼判斷該放哪一層

怎麼開始寫第一版

1. 用 /init

2. 讓 Claude 幫你整理

一個很實用的習慣

第二層：Rules

為什麼條件載入很重要

什麼時候該把規則從 CLAUDE.md 挪到 Rules

1. CLAUDE.md 太長了

2. 某些規則只和特定路徑相關

Rules 最適合的場景

第三層：Memory

Memory 記的是什麼

Memory 和前兩者的差別

Memory 也可以手動寫

第四層：Hooks

Hooks 的本質是什麼

什麼時候該上 Hooks

最典型的 Hooks 場景

Hooks 常見的觸發時機