官方文章說 Rules 跟 Skill 都能限定「只在特定情境載入」，這兩者實際上該怎麼選？
關鍵差異在於內容的性質,不是載入機制本身。路徑限定的 Rules 適合放「具體、單一句子就能講完的限制」,例如「遷移檔案只能新增、不能修改既有內容」這種一句話規則,透過 frontmatter 的 paths 欄位控制什麼時候載入;Skill 則適合放「有步驟、需要展開成一段流程」的程序性指令,例如一份完整的部署檢查清單。官方文章給的具體判準是:如果你發現自己在 CLAUDE.md(或試圖用 Rules)裡塞進一段三十行的流程說明,這就是該搬到 Skill 的訊號——Rules 該處理的是「跨越程式碼庫多個角落、但不是全部角落」都適用的具體約束,不是完整的操作流程。
Hook 裡的 prompt 跟 agent 這兩種類型，跟其他確定性類型有什麼本質不同，為什麼官方特別把它們挑出來說明？
官方文章明確指出,command、HTTP、mcp_tool 這三種類型是確定性執行——也就是說,只要觸發條件符合,它們每次都會做完全一樣的事,行為可以完全預測;而 prompt 跟 agent 這兩種類型,則是靠 Claude 自己的判斷去決定輸出結果,而不是靠一套固定規則。這代表雖然這五種都叫做「Hook」,但只有前三種真正具備 Hook 這個機制原本想提供的「確定性保證」,後兩種本質上更接近「在生命週期的某個時間點,額外呼叫一次 Claude 去做判斷」,可靠度層級其實比較接近 Skill 或指令,而不是真正的確定性防護欄。
這個區分之所以重要,是因為如果你的需求是「這件事一定要每次都發生,不能有例外」(例如阻擋某個危險指令),該選的是 command 或 HTTP 這類確定性 Hook;如果你的需求是「在某個時間點,想讓 Claude 針對當下情況做一次額外判斷」,prompt 或 agent 類型的 Hook 才適合,但這種用法本質上跟直接在流程裡插入一個判斷步驟很像,不能拿它當成真正意義上的「保證會發生」的防護欄。
Subagent 可以巢狀到五層深,官方文章提到的動態工作流程(dynamic workflows)可以協調數十到數百個背景代理,這種規模的協作是怎麼避免上下文被塞爆的?
關鍵在於官方文章點出的一個具體設計:編排計畫(orchestration plan)跟中間結果,是存在腳本變數裡,而不是存在 Claude 的上下文視窗裡。這代表當一個流程需要協調數十甚至數百個背景代理時,負責協調的那個主要 Claude 實例,不需要把每個子代理的完整執行細節都讀進自己的上下文——它只需要知道「目前有哪些子代理在跑、各自的狀態是什麼」這類摘要層級的資訊,實際的執行細節留在各自獨立的子代理上下文裡,彼此不互相污染。
這也是為什麼子代理的隔離性,在規模化協作時特別重要:如果沒有這層隔離,協調數十個子代理的過程,光是把每個子代理的中間產出都讀進主要上下文,就足以把上下文塞滿、擠壓掉真正該用來做協調決策的空間。把中間結果留在腳本變數而非模型上下文裡,是這種規模化協作在「不犧牲指令保真度」的前提下,還能維持可擴展性的關鍵設計。
如果我現在的專案已經有一份很長的 CLAUDE.md，混雜了各種不同性質的指令，該怎麼開始整理？
比較有效率的做法,是先照官方文章提供的判準表,把 CLAUDE.md 裡的每一段內容分類:先問「這是 Claude 幾乎每次都該知道的事實,還是只在特定情境才需要?」如果是後者,再進一步問「這是具體、單句能講完的限制,還是需要展開成多步驟的程序?」前者(具體限制)適合搬進路徑限定的 Rules,後者(多步驟程序)適合搬進 Skill。剩下真正該留在 CLAUDE.md 的,應該只有建置指令、目錄結構、跨團隊都該遵守的核心慣例這類「隨時都該知道」的事實類資訊。
另一個值得檢查的訊號是「絕對不能違反」的規則——如果 CLAUDE.md 裡有任何一條規則,是那種「萬一沒被遵守會有實際嚴重後果」的等級,這條規則不該只停留在指令層級,該同時搭配一個 Hook(例如 PreToolUse 型 Hook,可以檢查工具呼叫並用退出碼 2 直接阻擋),讓這個限制從「期望被遵守的建議」升級成「確定性強制執行的防護欄」。官方文章也提到,團隊共用的 CLAUDE.md 常見的問題是「沒有人真正擁有這份檔案」,內容只會越疊越多、沒人清理——建議替 CLAUDE.md 指定一個負責人,並像審查程式碼一樣審查它的異動,避免它無止盡地膨脹下去。
Anthropic 官方部落格在 2026 年 6 月發布的一篇文章，系統性整理了 Claude Code 裡調校 Claude 行為的七種方法：CLAUDE.md 檔案、Rules、Skill、Subagent、Hook、輸出風格（output styles），以及在指令列附加系統提示。這七種方法看起來部分功能重疊，實際上各自對應的是三個不同的判斷軸：指令什麼時候被載入上下文、經過對話壓縮（compaction）後會不會保留、以及這條指令帶有多強的約束力。
每一種方法都是在「情境成本」（context cost）跟「約束力」（authority）之間做取捨。CLAUDE.md 根目錄檔案在 session 一開始就會載入,並在整個對話過程中持續佔用上下文,即使目前任務用不到某一行,那一行依然會被讀進去——這代表它的情境成本高,適合放「建置指令、目錄結構、專案慣例」這類 Claude 幾乎每次都該知道的事實類資訊。相對地,子目錄底下的 CLAUDE.md 檔案是按需載入,只有 Claude 真的去讀該子目錄下的檔案時才會載入,對話壓縮後也不會保留,情境成本因此低很多,適合放「只跟這個子目錄相關」的慣例。
Rules(規則)存放在 .claude/rules/,分成沒有路徑限定跟有路徑限定兩種。沒有路徑限定的規則行為跟 CLAUDE.md 很像,session 一開始就載入,對話壓縮後會被重新注入;有路徑限定的規則,則是透過 frontmatter 裡的 paths 欄位,只有在 Claude 真的碰觸到符合路徑的檔案時才載入,可以用來放「只適用於某個目錄或某類檔案」的具體限制,例如「所有 API handler 必須用 Zod 驗證輸入」這種規則。
Skill 存放在 .claude/skills/,session 開始時只會預先載入名稱跟描述,完整內容要等 Skill 真的被呼叫(不管是透過斜線指令還是自動比對到任務)才會載入,對話壓縮後,已呼叫過的 Skill 會被重新注入,但所有已呼叫 Skill 共用一個總額度,額度用完最舊的會先被丟棄。適合放「像部署流程、發版檢查清單這類會在主線裡逐步展開、你想親眼看著每一步、隨時可以介入調整」的程序性指令。
Subagent 存放在 .claude/agents/,表面上跟 Skill 很像——session 開始時同樣只載入名稱、描述跟工具清單——但關鍵差異在於:Subagent 內文裡更龐大的指令內容,完全不會自動載入,也永遠不會真正進入主對話的上下文,Claude 是透過 Agent 工具呼叫它,傳入一段提示字串,子代理接著在自己全新、獨立的上下文視窗裡運作,只有最終的訊息(通常是彙整過的結果)加上中繼資料,會被送回主 session。這個隔離特性,正是該選 Subagent 而不是 Skill 的關鍵判準:如果一項附帶任務(像深度搜尋、日誌分析、依賴關係稽核)產出的中間結果,你之後根本不會再參考,用 Subagent 讓這些細節完全不進主對話;如果你要的是讓整個流程在主線裡展開、能親眼看到並隨時介入每一步,才該用 Skill。
Hook 是使用者自訂的指令、HTTP 端點或 LLM 提示,靠 Claude 生命週期裡的特定事件(檔案編輯、工具呼叫、session 開始)觸發,可以註冊在 settings.json、受管理的政策設定,或 Skill／子代理的 frontmatter 裡。Hook 分成 command、HTTP、mcp_tool、prompt、agent 五種類型,前三種是確定性執行,後兩種(prompt 跟 agent)則是靠 Claude 自己的判斷,而不是一套固定規則來決定輸出。Hook 的情境成本很低,因為設定或指令內容本身活在主要上下文之外,大部分 Hook 的輸出也不會存進主要上下文視窗,除非設定裡明確要求回傳(例如一個阻擋型 Hook 的標準錯誤訊息,會被存進上下文,讓 Claude 知道這次呼叫為什麼被拒絕)。
官方文章直接點出幾個常見的誤用模式,值得對照檢查:如果你在 CLAUDE.md 裡寫「每次 X,永遠都要做 Y」這種期待穩定發生的行為(例如每次編輯後都跑格式化工具),該用的是 Hook,不是指令——因為模型「選擇」要不要執行格式化,跟格式化工具「自動」執行,是完全不同層級的可靠度;如果你在 CLAUDE.md 裡寫「絕對不要做這件事」,這也是用錯工具的訊號——指令在多數情況下會被遵守,但在長對話、模糊情境,或任務中讀到的檔案裡藏有提示注入的情況下,模型可能無法遵守單純的提示規則,真正的防護欄需要是確定性的,也就是 Hook 跟權限設定,受管理設定(managed settings)甚至能做到管理者部署、使用者本機設定完全無法覆蓋,是唯一能落實組織層級確定性防護欄的方式;如果你在 CLAUDE.md 裡塞了一段三十行的流程說明,這段內容該搬進 Skill——CLAUDE.md 該放的是 Claude 隨時都該知道的事實,不是特定情境才需要展開的程序。下次要新增一條指令之前,先用這個判準表快速確認,通常比事後發現指令沒被穩定遵守、或上下文被不相關內容塞滿才回頭調整,要有效率得多。