Claude Code 的架構、治理與實作

Claude Code 最近很紅。很多團隊把它當 AI 結對編程工具。可是真正用順的人，沒那麼多。原因很直白。它不是聊天框。它更像一個會讀倉庫、跑命令、改檔案的執行系統。

你如果只拿它來問答，問題很快就來。上下文會亂。工具會亂用。模型會把舊資訊當新事實。這篇文章要講的，就是怎麼把它當工程系統來管。核心主題很明確：上下文治理、Skills、Hooks、Subagents，還有 Prompt Caching。

說白了，這不是「會不會用」的問題。這是「能不能長期穩定跑」的問題。對開發團隊來說，這差很多。一次 demo 很容易。每天都能用，才是真本事。

Claude Code 不是聊天工具，而是執行系統

Claude Code 的工作方式，跟一般聊天機器人不一樣。它會讀專案內容。它會看歷史對話。它會依照你的指令去呼叫工具。這代表它不是單次輸出，而是連續決策。每一步都會影響下一步。

這種設計很強，但也很脆弱。只要上下文混進太多雜訊，模型就會開始誤判。它可能改錯檔。也可能重跑不該跑的命令。更麻煩的是，它還會把錯誤延續下去。這就是工程上最煩的地方。

所以，Claude Code 的重點不在模型多聰明。重點在資訊流怎麼整理。你給它什麼，它就會拿什麼做決策。資料乾淨，它就穩。資料亂，它就飄。這很像在管一個很會做事的實習生。能力有，但你得把規格講清楚。

• 它會同時處理指令、檔案、工具回傳結果。
• 上下文越亂，錯誤越容易累積。
• 工程使用時，邊界比自由度更重要。
• 模型品質之外，資訊整理才是主戰場。

上下文治理：別讓模型替你記憶

很多人第一次用 Claude Code，會犯同一個錯。把太多東西塞進去。專案背景、臨時討論、舊需求、個人偏好，全都丟給它。結果很常見。模型開始混淆。它不知道哪些是現況，哪些只是過去的聊天內容。

正確做法是分層。固定規則放一層。專案結構放一層。任務資訊放一層。臨時討論不要硬塞進長對話。要嘛寫回文件，要嘛收斂成明確結論。不要期待模型幫你記住一切。那樣只會讓它更亂。

Anthropic 的 Claude Code 文件 也一直在講同一件事。好的上下文，不是堆出來的，是整理出來的。這句話很土，但很對。你把資訊整理好，模型才知道該信什麼。

“Good context is the result of good curation.” — Anthropic, Claude Code documentation

這句話很值得貼在團隊牆上。因為它講的是實務，不是口號。上下文治理，本質上就是知識管理。你要的是穩定輸入，不是更多輸入。這點一旦搞懂，Claude Code 的表現通常會好很多。

另外，Prompt Caching 也會放大這個差異。穩定內容可以重用。變動內容要保持短。你如果把雜訊也拿去快取，只是把問題固定住而已。

Skills、Hooks、Subagents：別把功能用成裝飾

很多人聽到 Skills、Hooks、Subagents，會以為這些是進階選配。其實不是。它們是治理工具。用對了，整個工作流會清楚很多。用錯了，只會多出一堆難維護的自動化。

Skills 適合放穩定規範。像是 code style、測試流程、提交格式、常用指令。Hooks 適合處理事件。像是檔案變更後自動檢查，或提交前先驗證。Subagents 則適合拆工。像是檢索、重構、測試，各做各的。

這三個東西的差別，講白了就是角色不同。Skills 是規則庫。Hooks 是觸發器。Subagents 是分工單元。你如果把所有邏輯都塞進同一層，最後就會得到一個很難追的 AI 工作流。看起來很炫，實際上很累。

• Skills 用來沉澱長期規範。
• Hooks 用來自動觸發檢查與同步。
• Subagents 用來拆解複雜任務。
• 三者都要先定義輸入、輸出、失敗條件。

Prompt Caching：省成本只是表面

很多人把 Prompt Caching 當省錢功能。這講得太小了。它真正的價值，是逼你重新設計上下文。當固定規則可以重用，系統就不必每次都全量送出。這會影響延遲，也會影響 token 成本。

對大團隊來說，這件事很實際。專案規則、資料夾說明、測試流程，通常不常變。這些很適合進快取。反過來，當前任務、最近幾輪討論、某個檔案的局部修改，應該保持短小。這樣才不會讓會話越跑越重。

如果你把快取和上下文治理一起做，Claude Code 會比較像一個有邊界的工程助手。它不會每次都從零開始想。這對長會話很重要。對跨檔案重構也很重要。對大型 repo 更重要。因為大專案最怕的，就是每次互動都像第一次見面。

• 固定規則適合快取。
• 臨時任務不適合快取。
• 快取能降低重複輸入成本。
• 錯誤的固定內容也會被持續復用。

CLAUDE.md：寫成操作手冊，不要寫成心情日記

很多團隊會問，CLAUDE.md 到底要寫什麼。答案其實很簡單。把它寫成操作手冊。不是寫心得。也不是寫一堆廢話。它應該告訴模型，這個專案怎麼跑，怎麼測，哪裡不能亂動。

最實用的內容通常很固定。專案架構。常用指令。測試方式。提交規範。危險操作。哪些情況要先問人。這些資訊越明確，模型越不容易亂猜。你要的是減少歧義，不是增加文字量。

我覺得很多團隊低估了這件事。CLAUDE.md 寫得好，Claude Code 才有機會穩定工作。它不是附錄。它是系統入口。第一次讀倉庫時看到什麼，會直接影響後面所有動作。

工程團隊該怎麼落地

如果把這套方法放到真實團隊，我會先做三件事。第一，整理上下文。第二，定義 Skills。第三，切清楚哪些動作交給 Hooks，哪些任務交給 Subagents。不要一開始就想全自動。那通常只會把問題放大。

更務實的做法，是先挑一個固定場景。像是單元測試補齊、文件同步、簡單重構，或 PR 檢查。先把一條流程跑穩，再慢慢擴大。這樣比較不會把整個團隊帶進一個很難回頭的設計。

從產業角度看，這類工具的競爭點也很清楚。不是誰的 demo 比較炫。是誰能把模型、工具、記憶、規則接成一個可維護流程。Claude Code 的 GitHub 與官方文件，已經把很多基礎能力攤開了。接下來比的是工程紀律，不是話術。

• 先挑單一場景做落地。
• 先穩定，再擴張。
• 把規則放進文件，不要放進口頭記憶。
• 讓自動化服務流程，不要反過來綁住流程。

結尾：先問自己，資料準備好了沒

Claude Code 能不能用好，答案通常不在模型。答案在你的 repo。你的文件夠不夠清楚。你的規則夠不夠穩。你的上下文有沒有整理。這些問題不先解掉，再強的模型也會被拖慢。

我自己的判斷很直接。接下來 6 到 12 個月，真正跑得穩的團隊，不會是最會下 prompt 的那群。會是最會做治理的那群。你如果已經在用 Claude Code，我會建議先從 CLAUDE.md、Skills 和 Prompt Caching 下手。先把一個流程做穩，再談擴大。

講白了，問題不是 Claude Code 能不能幫你寫程式。問題是，你的工程流程，準備好讓它長期工作了沒。