Claude Code 為什麼有效：模型無狀態，狀態在執行環境
Claude Code 有效，是因為模型無狀態，狀態由 harness 組裝：工具 schema、系統提示、CLAUDE.md、skills 與權限。客製的是執行環境；開發重心轉向意圖表達與驗證審查，而非背誦神奇 prompt。
很多人把 Claude Code 想成「會寫程式的 Claude」。這不夠準。更精確的說法是：
模型仍然無狀態；Claude Code 是把檔案、對話、設定與權限組裝成請求、並執行工具的 harness（執行環境）。
你真正客製的，不是模型的記憶，而是每一次呼叫被餵進去的狀態與約束。
理解這一點，代理工程才站得住：精通 Claude Code，本質上是精通如何提供狀態、如何限制行動、如何表達意圖、如何驗證結果。本文整理底層迴圈、權限與 Skills，以及「意圖驅動開發」為何把重心從打字搬到審查。
模型無狀態：每次都是從零開始
大型語言模型在 API 意義上沒有跨呼叫的工作階段記憶。每次請求，它只看到這一次被放進上下文的 token。
因此必須由執行環境扛起全部狀態，例如：
- 工作目錄裡的檔案
- 對話紀錄
- 設定（CLAUDE.md、skills、權限、hooks、MCP）
- 執行環境（OS、shell、git 分支、目前模型）
Claude Code 的工作，就是在你按下 Enter 的瞬間，把這些東西組裝成一個大型請求，送進 Messages API，再根據模型回傳的 tool call 在本機執行，把結果塞回訊息陣列，再組裝、再呼叫——形成代理迴圈。
模型本身不會「記得你上次允許過 git commit」；是 harness 與你的設定檔在記得。
按下 Enter 之後：請求裡有什麼
概念上，一包請求大致包含：
| 區塊 | 作用 |
|---|---|
| 工具 Schema | bash、read、edit、agent、webfetch… 各工具的名稱、描述、輸入結構。模型據此知道「框架能替我做什麼」 |
| 系統提示 | 框架寫死的身分、語氣、規範、安全規則 |
| 環境資訊 | 作業系統、shell、模型、git 分支等 session 快照 |
| 訊息陣列 | 對話史 ＋ CLAUDE.md 全文 ＋ Skills 清單（多半只有 name/description）＋ 你的這句 prompt |
兩點容易誤解：
- 模型不直接「讀 JSON」——API 端轉成 token；你在 network panel 看到的結構，是協議，不是模型的母語。
- 模型不能自己執行 bash——它只回傳 tool use；真正跑
fs.readFile或 shell 的是 harness。若權限拒絕，工具呼叫可以「到達」但不會執行。
一輪最小迴圈
你：幫這個模組加測試
→ harness 組裝 prompt（此時檔案內容可能還沒在上下文裡）
→ 模型：呼叫 read
→ harness：讀檔，tool result 寫回 messages
→ 再次組裝完整上下文
→ 模型：呼叫 edit / 繼續推理
→ …
所以你在 CLI 裡看到的「正在 read…」，是 API 回應之後 harness 的行為，不是模型神秘連線進你的磁碟。
客製化的真正旋鈕
既然狀態在環境，客製化就落在這些旋鈕上（你想得到的幾乎都是在餵狀態或限行動）：
| 旋鈕 | 在做的事 |
|---|---|
| CLAUDE.md | 被動塑造行為與航向（專案大腦） |
| 權限 | 允許／詢問／拒絕哪些工具與指令 |
| Plan 模式 | 先別改碼，只規劃——一種強約束的「行為模式」 |
| Skills | 把重複多步驟流程寫成可重用程序 |
| Hooks | 工具前後自動跑腳本 |
| 外掛／MCP | 擴充可呼叫的外部能力 |
權限：被動規則，主動控制
工具呼叫來自模型；是否執行由你的規則決定。常見分層：
- allow：不詢問（如
npm run、安全的檢查指令） - ask：先問（如刪檔）
- deny：硬擋（如
git push、改package.json）
規則可放在專案或全域設定；企業／管理層設定應優先於個人與專案，避免下層覆寫公司禁令。用過一陣子之後，可用「依歷史對話建議權限規則」這類指令，把你反覆點允許的模式收成設定——但應保持保守，可疑項宁可省略。
這回答了一個實際恐懼：「模型想 rm -rf 怎麼辦？」——在正確設定下，想和做得成之間，隔著 harness。
Skills：重複流程的產品化
Skill 本質是帶 front matter 的 Markdown 程序：部署、審查、問答循環……那些你不想每次重打的提示詞。
進階控制包括：
- 某 skill 固定用較便宜的模型
- 只當斜線指令、禁止模型自行呼叫
- 或相反：只允許模型呼叫、使用者不直接觸發
- 帶參數（如
/deploy staging）
更重要的是心智轉換：
日常卡點出現時，先問：「這件事能不能變成 skill／已經有自動化？」
而不是預設「我必須親手寫一段腳本」。
這與「漸進式揭露」一致：傳給模型的 skill 清單往往只有名稱與描述；真用到才載入全文，省上下文。
意圖驅動開發：從「怎麼寫」到「要什麼＋怎麼驗」
社群與產品方愈來愈常用 intent-driven development（意圖驅動開發） 描述一種用法：
| 較弱的焦點 | 較強的焦點 |
|---|---|
| 背誦神奇 prompt 句式 | 精確說出你要打造什麼 |
| 逐步當人肉編譯器 | 表達意圖，讓 harness＋模型去拆步驟 |
| 只信自己敲的每一行 | 驗證行為與變更成為主業 |
實務上有效的輔助包括：
- 語音輸入：說話往往比打字更快倒出意圖（含「嗯」、改口都沒關係）
- Plan 模式或明確要求先別寫碼：意圖未清前不燒實作
- 附圖、跑起來看、測試、CI：意圖必須可被驗證
- 軟體工程背景仍有用：不是為了手寫每行，而是為了把意圖說清楚、知道哪裡該卡控
Anthropic 側的觀察也對齊：內部與外部重度使用者路徑不同，但回饋都在強調——Claude 需要驗證；產品目標是降低「有想法 → 可部署」的阻力，而不是鼓勵無人看管的自動合主幹。
心態帳本：時間花在哪
| 過去 | 現在更健康的分配 |
|---|---|
| 大部分時間在「寫」 | 更多時間在審查與驗證（可部分自動化，不可省略） |
| 只盯 diff 語法 | 也驗行為：跑應用、測、草稿 PR |
| 把 agent 當程式生成器 | 把終端機／Code 當連接電腦與數位世界的通用介面 |
寫 code 的產能上移之後，戰略判斷與驗收變成稀缺——這和「AI 加速軟體熵」「深度模組需要將軍視角」是同一條線：戰術可以外包給 agent，長期健康不能。
Code 與 Cowork：同一 runtime，不同介面
當用途從「寫程式」擴到剪片、研究、清檔、分析、寫作，並不奇怪：底層都是「無狀態模型 ＋ 能碰環境的 harness」。
產品分層可以記成：
- Claude Code：技術向、repo、CLI、工程工作流
- Claude Cowork：非技術事務向（郵件、日曆、檔案整理等），更好的連線器與系統提示；底層仍可走類似 Code 的執行能力
選擇介面，是為了意圖類型；狀態與權限紀律兩邊都適用。
可執行的最小清單
1. 記住：模型無狀態 → 你養的是 harness 狀態
2. 讀懂一輪：組裝 → tool call → 執行 → 再組裝
3. 設定權限階層：危險 deny、破壞性 ask、重複安全 allow
4. 專案大腦 CLAUDE.md + 重複流程 skills
5. 意圖：語音／Plan／圖；未清前少改碼
6. 驗證：行為 + 測試 + 草稿 PR；加大 review 比重
7. 學 git / gh / CLI，讓 agent 走可審查的交付路徑
結語
Claude Code 有效，不是因為模型突然「住進」你的筆電有了靈魂，而是因為：
無狀態的智力，被包進一個負責組裝世界狀態、執行工具、並可被你權限與程序約束的執行環境。
你客製 md、skills、hooks、MCP 與權限，是在設計這個環境。
你練習意圖驅動與驗證，是在設計自己與環境的介面。
把模型當黑盒神諭，會高估記憶、低估設定。
把 harness 看清楚，你才知道：每一次 Enter，究竟送出了什麼世界——以及，下一次如何把世界組得更對。
延伸閱讀
- 從 CLAUDE.md 到「做夢」：上下文工程如何把模型智力變成可用系統
- 從聊天框到本機執行：非工程師的 AI 飛輪
- AI 加速的是軟體熵：用深度模組與戰略工程師救程式碼庫
- 腦在雲、手可在你這：Claude Managed Agents 到底解決什麼
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。