Claude Code CLI 深入指南
Blake Crosley 的 Claude Code CLI 指南，把 hooks、MCP、subagents 串成一套可落地的 AI 寫程式流程。
Claude Code 是 Anthropic 的 CLI 代理式寫程式工具，靠 hooks、MCP 和 subagents 來處理真實軟體工作。
Anthropic 說，Anthropic 的 Claude Code 已經扛下約 4% 的公開 GitHub commits。換算下來，大約是每天 13.5 萬筆 commit。這數字很硬，代表它不是玩具。
Blake Crosley 的 Claude Code CLI guide 也寫得很狠。篇幅超過 4.8 萬字，閱讀時間約 240 分鐘。說白了，這不是速成教學，是操作手冊。
| Fact | Value | Why it matters |
|---|---|---|
| Guide length | 48K+ words | 代表它是完整參考文件 |
| Read time | 240 minutes | 說明系統表面很深 |
| GitHub commit share | 4% | 顯示真實採用量 |
| Commit volume | ~135,000/day | 不是小眾試玩 |
| Context window | 200K tokens standard | 解釋為何要分工 |
Claude Code 不是聊天框，是終端代理
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
先講白話版。Claude Code 住在你的 repo 裡。它會讀檔、跑 shell、改程式，然後繼續做下去。這跟一般聊天機器人差很多。
一旦模型能碰檔案系統和命令列，它就不是單純產生文字。它開始像代理人。它能觀察、執行、再接下一步。這也是為什麼很多人第一次用會覺得很猛，第二次就開始踩坑。
問題通常不在模型本身。問題在你有沒有把工作切開。主對話負責思考。子代理負責搜尋和整理。外部系統負責工具和資料。這三層沒分清楚，context 很快就爆。
- 核心層：主對話，最吃 context
- 委派層：subagents，專做局部任務
- 擴充層：MCP、hooks、skills
- 標準 context：200K tokens
我覺得這點很重要。很多人把 prompt 當萬靈丹。其實不是。該固定執行的事，就該放 automation。像格式化、lint、權限檢查，根本不該靠模型記得。
五個系統決定它好不好用
Crosley 把 Claude Code 拆成五個系統。分別是 configuration、permissions、hooks、MCP、subagents。這個切法很實際。因為真實團隊出問題，常常不是模型笨，是設定亂。
configuration 管預設值。permissions 管它能碰什麼。hooks 負責固定流程。MCP 把外部工具接進來。subagents 則把複雜工作拆出去。這五個東西湊起來，才像一個能上線的系統。
你如果只看表面，很容易以為這只是「AI 幫你寫 code」。其實不是。它更像一個可編排的開發工作台。你可以限制它。你也可以讓它連資料庫、GitHub、Sentry，甚至更多服務。
“Claude Code is an agentic CLI that reads your codebase, executes commands, and modifies files through a layered system of permissions, hooks, MCP integrations, and subagents.” — Blake Crosley
這句話很準。也很直白。它把整件事講穿了。Claude Code 不是一個 prompt。它是一套可控的執行系統。
- Configuration：定義預設行為
- Permissions：限制可操作範圍
- Hooks：放固定流程
- MCP：接外部資料與服務
- Subagents：拆解探索任務
Hooks 和 MCP 比花俏 prompt 更重要
Hooks 是這篇指南最實用的部分之一。Crosley 的意思很直接。凡是一定要發生的事，就不要寫進 prompt。像 lint、format、policy check，這些都應該放 hook。
原因很簡單。prompt 會忘。hook 不會。你如果把安全檢查交給模型記憶，那就等於把風險丟給運氣。這種做法在 demo 可以，在 production 很危險。
MCP，Model Context Protocol，解的是另一題。它讓 Claude 接到 repo 外的工具和資料。像資料庫、GitHub、Sentry、內部 API，都能串。這對真實開發很有用，因為程式工作從來不只是在改檔案。
- Hooks：適合固定、可重複的動作
- MCP：適合外部資料和工具
- Subagents：適合探索和摘要
- Skills：適合包裝可重用流程
講白了，這是一種分工。要可靠，就交給 automation。要廣度，就丟給 subagent。要接外部狀態，就用 MCP。把這些混在同一段對話裡，通常只會得到一堆雜訊。
模型選擇其實是成本問題
指南也很務實地談模型層級。Crosley 建議 Opus 用在重推理，Sonnet 當日常主力，Haiku 則拿來快速探索。這不是品牌站隊，是成本管理。
如果每件事都丟最強模型，錢會燒很快。反過來，如果把探索任務交給便宜模型，再把難題留給高階模型，整體效率會好很多。這種分流很像雲端架構的思路。
你可以這樣理解。Opus 適合架構判斷和多步推理。Sonnet 適合一般 coding。Haiku 適合掃描、摘要、找線索。不同任務用不同模型，才不會把 GPU 預算亂噴。
- Opus：複雜推理和架構決策
- Sonnet：日常開發主力
- Haiku：快速探索和低成本任務
- Subagents：可用較便宜模型跑
這裡的重點很現實。Claude Code 真正強的地方，不是單次回答多漂亮。是你能不能把工作切成幾層，讓不同模型做不同事。這才是能長期用下去的方式。
這套玩法放到台灣團隊會怎樣
台灣很多團隊已經在碰 AI coding。問題是，很多人還停在「叫它幫我改一段 code」。這種用法很快就會卡住。因為專案一大，context 就不夠，流程也不穩。
更實際的做法，是先定規則，再讓 Claude Code 進來。哪些檔案能改。哪些指令能跑。哪些檢查一定要過。這些先寫好，AI 才不會變成亂跑的同事。
我自己的判斷很直接。接下來真正會省時間的，不是會寫 prompt 的人，而是會設計 hooks、permissions、MCP 的人。因為那才是把 AI 變成工作流程的一部分。
背景補充：為什麼 CLI 代理會越來越重要
過去幾年，大家都在比誰的聊天介面更順。現在方向變了。真正有價值的，是能進 repo、能跑命令、能接工具的系統。這就是 CLI agent 的地盤。
原因也不難懂。軟體開發本來就是一堆工具鏈。git、CI、lint、test、deploy，全都在命令列裡。AI 如果只會聊天，能力其實很有限。能動手，才真的有用。
這也是為什麼 Claude Code、OpenAI 的工具鏈、還有各家 MCP 生態會一直被拿來比。大家比的不只是模型分數，而是誰能把模型接進工作流。
結論：先設規則，再讓它寫 code
如果你準備導入 Claude Code，我會建議先做三件事。第一，定義 permissions。第二，寫好 hooks。第三，再接 MCP。順序不要反過來，不然很容易把問題放大。
接下來一兩季，真正拉開差距的團隊，應該是那些把 Claude Code 當成開發基礎設施的人。不是拿來玩一下而已。你如果只想試新玩具，會很快膩。你如果想把它放進正式流程，現在就該開始設規則。
下一步很簡單。先挑一個 repo。設一條 hook。再加一個 MCP 服務。從最小可控範圍開始，會比直接全開來得穩。
更深入的實戰建議，可以參考我們的 Claude Code 進階使用模式，整理了用了半年後才看清的五個 CLI agent 設計重點。