歡迎來到 Claude Code Deep Dive。

這個節目的第一集，我們先不急著講功能，不急著講技巧，也不急著講哪一個指令比較方便。我們先做一件更重要的事：把 Claude Code 講成一套可以管理、可以分工、可以驗收的系統。

很多團隊在用 Claude Code 的時候，一開始都很有熱情。他們看到很多機制，像是 CLAUDE.md、settings、permissions、hooks、skills、subagents、MCP，覺得每一個都很強，每一個都想用。結果做了幾天之後，整個 repo 開始失控。規則越寫越長，設定越放越亂，hooks 不知道該管什麼，skills 跟 subagents 的責任也越來越模糊。最後團隊不是沒有工具，而是不知道每個工具到底屬於哪一層。

所以第一集的工作，就是把這件事拆開。今天你只要帶走一個模型，後面整季的內容就會很好懂。這個模型叫做五層控制架構。

一句話定義很簡單。Claude Code 要可控，就必須把政策、確定性、自訂能力、委派協作、還有 context 管理，分成五個不同的層。這五層分別是：控制平面、自動化平面、能力平面、協作平面、以及 context 平面。

先講控制平面。控制平面處理的是政策、意圖、規則和共享設定。像是 CLAUDE.md、rules、settings、permissions，這些都屬於控制平面。控制平面的工作，不是替你執行每一件事情，而是告訴整個團隊，什麼是長期有效的規範，什麼東西該放在哪裡，什麼是可以共享的預設，什麼又屬於個人或本機實驗。

但控制平面有一個很重要的邊界。它可以表達政策，不能保證結果。很多人最容易犯的錯誤，就是把文字規則當成執行保證。好像你只要把要求寫進 CLAUDE.md，模型就一定會百分之百遵守。這不是一個穩健的想法。文字規則是控制意圖，不是程式上的強制約束。如果你要的是確定性，你就要往下一層走。

下一層是自動化平面。自動化平面最典型的表面，就是 hooks。當你需要在某個生命週期做確定性的檢查，像是阻擋危險工具、在停止前驗收輸出、在 compact 前先留下摘要，這種事情就不該只寫成一句提醒。你應該把它做成可執行的流程。這就是自動化平面存在的理由。

但是 hooks 也有邊界。hooks 很適合做明確、可判斷、可失敗的規則。比如說某個命令不准執行，某個檔案沒有更新就不准結束，某個輸出格式不合格就直接擋下來。可是一旦你想讓 hooks 去判斷一個很模糊、很需要人類主編或架構師思考的問題，它就開始失真。換句話說，hooks 很擅長做 guardrail，不擅長做模糊審稿。

第三層是能力平面。能力平面處理的是可重用能力。像 skills、plugins、MCP，都屬於這一層。這一層的核心問題不是規則，也不是審批，而是：有沒有一種能力，值得被重複使用？有沒有一組工作流程，值得被打包？有沒有一個外部工具或資料源，值得被接進來變成長期能力？

可是能力平面不是安全平面。這點要講得非常清楚。很多人會把 skills 當成某種高級規則，甚至以為只要把工作包成 skill，就自帶正確性。不是。skill 只能提供能力，不能天然提供治理。plugin 可以讓功能更可攜，MCP 可以讓外部工具更容易接入，但它們都不等於安全白名單，不等於權限策略，也不等於驗收流程。

第四層是協作平面。協作平面講的是怎麼把工作拆出去，怎麼定 ownership，怎麼隔離上下文，怎麼避免多人同時寫同一個責任區。subagents 就是這一層最典型的機制。

但 subagents 最容易被誤用。很多團隊一碰到複雜任務，就想說多開幾個 agent 平行做，應該就會更快。其實不是。假設你的 spec 根本不清楚，責任邊界也沒切好，這時候你不是在做平行化，而是在放大混亂。subagents 最適合處理的是責任明確、輸出明確、寫入範圍明確的子任務。它們不是用來掩蓋主線設計失敗的。

第五層是 context 平面。這一層很容易被忽略，因為它不像 hooks 或 skills 那麼顯眼。可是從團隊治理角度看，context 平面非常關鍵。它處理的是 context window、compact、clear、還有文件化交接。你可以把它理解成工作記憶管理，而不是知識真實來源。

很多人對 context 的第一個錯誤想像是：越多越好。其實不是。context 太長、太雜、太多不相關輸入的時候，模型不是變得更聰明，而是更容易失焦。這也是為什麼成熟的流程一定會強調 phase boundary。當任務切換了，當主題換了，當中間決策已經定案了，就要把重點寫回檔案，然後清掉不必要的對話負擔。這種 Document、Clear、Resume 的節奏，本質上就是 context 治理。

講到這裡，你大概可以看出一個關鍵原則。Claude Code 不是一堆機制的集合，而是一套分層系統。當你知道某個機制屬於哪一層，你就知道它應該放在哪個檔案、應該在什麼時候生效、應該跟哪一層配合、又不應該拿來補哪一種洞。

現在我們把最常見的三個反模式講清楚。

第一個反模式，是把所有要求都塞進 root 規則檔。這是最常見，也最傷的做法。因為一旦 root 檔變成一個什麼都想管的總控文件，最後一定出現三個結果。第一，規則越寫越長，沒有可維護性。第二，彼此衝突的規則越來越多。第三，真正需要確定性保證的事情被埋在一堆文字裡，根本沒有被升級成設定或 hook。

第二個反模式，是機制混用。明明是一個 setting scope 問題，卻想用 CLAUDE.md 解。明明是一個危險命令阻擋問題，卻只寫成一句口頭提醒。明明是一個需要反覆重用的工作流程，卻不做成 skill，而是每次在對話裡重講一次。這種混用的結果，就是團隊成員每次都得重新猜：到底哪一層才是真的？

第三個反模式，是把協作當成逃生門。也就是規格沒寫好，架構沒講清楚，就先分派給很多 subagents，希望結果自己長出來。這種做法短期看起來很忙，長期只會讓整個系統更難驗收，因為沒有人知道失敗到底發生在哪一層。

那正確做法是什麼？最小可行設計法其實很務實。Research 負責查官方定義，Architecture 負責把機制放回正確層級，Content 負責把模型寫成可教學內容，Instructor 負責把語氣和節奏穩住，Distribution 負責把 release contract、RSS、網站頁、音訊與平台連結維持一致。你會發現，這個分工其實不是為了好看，而是因為每一種責任都要有一個落檔位置，才不會在 compaction 之後整個消失。

所以如果你問我，第一集最重要的 takeaway 是什麼，我會給你三句話。

第一，先分層，再分檔。不要一開始就爭論是寫在什麼檔案，而是先判斷這件事屬於政策、確定性、能力、協作，還是 context 治理。

第二，需要確定性時，不要只寫文字。文字可以表達意圖，但不能替代設定、權限或 hooks。

第三，重要決策一定要寫進檔案。session 很長會衰退，context 會 compact，成員會換手，但檔案化的決策才能留下來。

如果你已經能用這五層模型去判斷一個機制應該放在哪裡，那這一集就達標了。因為從下一集開始，不管我們講 CLAUDE.md、settings、permissions、hooks、skills、subagents 還是 MCP，你都不會再把它們聽成一團混在一起的功能，而是能把它們放回正確的系統位置。

這就是第一集真正要建立的事。不是記住更多名詞，而是先建立一個可以讓團隊長期維持一致的架構腦圖。

我們下一集，會從控制平面的核心檔案開始，拆解 CLAUDE.md 與記憶機制到底該怎麼設計。