控制架構總覽

一開始先不要背名詞，先看痛點

很多團隊不是工具不夠用，而是把不同層的東西全塞在一起。有人把長期政策寫成聊天提醒，有人把真正該阻擋的危險操作留在口頭規則，有人又把重複流程一直留在人工步驟。最後看起來像是 Claude Code 很亂，其實亂的是層級。

所以這一集最重要的不是介紹功能清單，而是先建立一個判斷框架。你之後看到任何一個需求，都先問自己：這是政策問題、執行問題、能力問題、協作問題，還是 context 續航問題。問題分對層，解法才會落對地方。

一句話模型

Claude Code 可以拆成五層：控制平面負責政策與路由，自動化平面負責可執行的 guardrail，能力平面負責可重用工作包，協作平面負責責任切分，Context 平面負責工作記憶與續航。

這五層不是功能分類遊戲，而是團隊治理模型。因為你真正要管理的不是單一 prompt，而是整個系統到底怎麼被讀取、怎麼被執行、誰來負責、出了錯怎麼被擋下來，以及會話結束之後還能不能接得回去。

控制平面在做什麼

控制平面的工作是定方向。像 `CLAUDE.md`、rules、settings、permissions 這些東西，最適合放在這一層。它負責回答「我們這個 repo 的原則是什麼」、「哪些事應該被限制」、「哪些設定是共享底線」。但你要記住，它能定方向，不代表它能保證每一個細節一定被執行。

這也是很多人第一個會搞錯的地方。把一段話寫進 `CLAUDE.md`，不等於它自然就變成 enforcement。如果某件事真的需要被擋下來，那你就不該停在文字層。

自動化平面和能力平面的分界

自動化平面講的是 hooks 這種可執行 guardrail。它的價值在於確定性。比如危險指令要在執行前攔下來，收尾時一定要驗收，這種事情放在 hooks 才有意義。你不能期待一句提醒文字在壓力大的時候還永遠會被遵守。

能力平面則是另一回事。skills、plugins、MCP 比較像可重用工作包。它們不是拿來定政策，也不是拿來當安全底線，而是把高頻、重複、可以封裝的工作收起來。像研究來源初步分級、稿件人話化、發佈前 metadata 生成，這些都比較像能力問題。

協作平面和 Context 平面

協作平面真正要解的是責任切分。sub-agents 不是把所有上下文複製出去就好，而是要讓每個角色有清楚 ownership。Research 做定義，Architecture 做層級與檔案體系，Content 把它講成人能理解的東西，Instructor 穩住教學人格，Distribution 確保公開面一致。角色清楚，驗收才清楚。

Context 平面則是最容易被低估的一層。因為 thread 很長的時候，你會以為東西都還在，實際上 compact、注意力衰退、訊息噪音都會讓早期決策失真。所以真正重要的決策一定要寫回檔案。這不是文書習慣，是系統續航。

五個最常見反模式

• 把 root file 寫成手冊。 這會讓最重要的規則反而最難被掃描。
• 把提醒當 enforcement。 真正要擋的事情，如果沒有往 hooks 或 permissions 升級，就只是口頭規範。
• 把技能和政策混在一起。 skill 不是治理本體，它是工作包。
• 把 sub-agent 當責任外包。 spec 沒定義清楚，分再多 agent 都只會一起亂。
• 把 context 當倉庫。 只留在對話裡的決策，最後一定會消失。

團隊實作時的最小判斷法

如果明天真的要重整一個亂掉的 repo，我會這樣做。先盤點現有 `CLAUDE.md`、settings、hooks、skills、subagents。接著先處理硬限制，不先碰漂亮不漂亮。危險操作要先分出來，重複工作要先找出來，然後才決定哪些要升成 hook、哪些要做成 skill、哪些只要留在控制平面。

最後一定要做的一件事，是把今天已經講清楚的決策寫回 repo。因為這套系統不是靠你今天懂一次就好，而是要讓別人明天接手、下週回來、甚至三個月後重看時，還能知道每一層在做什麼。