如果你用了 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

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

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

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