個人化設定與客製化

8.1　設定檔放哪：settings.json

Claude Code 的各種設定，都記在一個叫 settings.json 的檔案裡。你可以把它想成它的「個人設定面板」——只是長相是一份文字檔，不是有勾選框的視窗。

這個檔案其實分好幾個層級，差別在「影響範圍」：由廣到窄是「全公司層（Managed，由公司 IT 統一管）→ 個人層（管你所有專案）→ 專案層（只管這個專案）→ 個人本機層（你自己的覆蓋，不進 Git）」，越窄的層級會蓋過越廣的。新手最常用的是中間兩層；下面這張表幫你分清楚：

完整的優先權順序其實還有一層沒放進表格裡：命令列參數（像啟動時加的 --model）優先權比全公司層低、但比其餘三層都高——不過它只在那一次啟動有效，關掉重開就沒了，不會被存下來，所以沒有對應的「檔案位置」可以列。還有一個例外要特別記住：放行規則（permissions）不是「窄層整個蓋過寬層」，而是「各層規則會合併」——你在個人層設的放行規則，不會因為專案層也設了規則就整批消失，兩邊是疊加生效，這跟其他大多數設定的邏輯不一樣，很容易搞混。

裡面可以設定：哪些動作要放行或擋下（權限）、自動化的 Hooks、環境變數、預設用哪個模型等等。改完大部分欄位會自動重新載入，不用重開 Claude Code——但有兩個例外，下面用提示框特別標出來。萬一改壞了、它行為怪怪的，下面這個指令會幫你體檢，告訴你哪裡設定錯了。

💡 建議執行：設定出問題時，用它找錯

/doctor

順帶一提，/doctor 能做的比「抓語法錯誤」更多：它會一次驗證全部四層的 settings.json，抓出哪個檔案、哪一條設定有問題（型別不對、路徑不存在等等）；還會幫你估算目前載入的 skill 清單佔了多少 context token、揪出跑得特別慢的 hooks、標出裝了卻沒在用的 MCP 或 skills。定期跑一次，很多還沒惡化成「打不開」的小問題都能提早抓到。

settings.json 壞掉是真實會發生、後果也不小的踩雷，先認得下面三種症狀，之後真的遇到才不會慌：

最省力的預防針，是在 settings.json 最上面加一行 $schema，讓 VS Code 這類編輯器在你打錯之前就先標紅提醒，不用等到執行期才發現：

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(npm run lint)"],
    "deny": ["Read(./.env)"]
  },
  "model": "sonnet"
}

8.2　內建指令快速導覽

Claude Code 內建了一堆「斜線指令」（就是用 / 開頭的那種）。你不用背——在對話裡打一個 /，它就會把所有能用的指令列出來給你看；再多打幾個字母，清單會跟著篩選，很快就找到你要的。下面挑幾個常用的先讓你認識。

8.3　做一個自己的 /指令（用 Skills）

有沒有一串指令你常常重複下？例如「幫我把改動整理好、寫好說明、然後 commit」。與其每次重打，你可以把它打包成一個 /名字，一鍵呼叫。官方現在推薦的做法叫「Skill」——說穿了，就是建一個小檔案，把你要它做的事寫進去。

順帶一提，Skill 並不是「只有 Claude Code 才吃得下」的功能。官方文件其實把它的規格拆成兩層：面向 API／Agent SDK 的通用規格只要求 name 和 description 兩個欄位，是跨介面共通的最小規格；Claude Code 專屬文件則在這之上疊加一整組 CLI 專屬擴充欄位（就是接下來要介紹的那些）。兩者共用同一份 SKILL.md 概念，只是後者多了本節後面會講到的那些欄位——換句話說，Skill 是一包能跨介面重複使用的能力，不是「只在終端機裡才成立」的東西。✅官方

下面用最常見的 /commit 當例子，帶你做一次。三步就好。

1. 1
   ✋動手做

   建一個檔案

   在你的專案裡，建一個檔案，路徑是 .claude/skills/commit/SKILL.md。資料夾不存在的話一起建出來——commit 這個資料夾名，之後就會變成你的指令名 /commit。

2. 2
   ✋動手做

   把下面這段內容貼進去，存檔

   打開剛建好的 SKILL.md，把下面這整段貼進去、存檔。最上面用兩條 --- 框起來的部分叫「frontmatter」，是這個指令的基本資料；下面那行，就是你要它實際做的事。

   ---
   name: commit
   description: 把目前的改動整理並 commit，寫好說明
   ---
   請幫我 stage 所有改動，寫一個清楚的提交訊息，然後 commit。

   複製
3. 3

   在對話裡打 /commit 試試

   回到 Claude Code 的對話框，打 /commit 按 Enter。它就會照你寫的那行去做：把改動整理好、寫好提交訊息、commit。

   ✅ 預期會看到

   打 / 的時候，你新建的 /commit 會出現在指令清單裡；選它執行後，它會開始幫你 stage、寫訊息、commit。看到它動起來，就成功了。

   # 打 / 時，清單裡會多出你自己的指令
   /commit   把目前的改動整理並 commit，寫好說明

   複製

Skill 的好處是：你可以手動用 /名字 叫它，Claude 也會在它覺得適合的時候自己用。

還有一個小技巧：如果你把這個檔案放在 ~/.claude/skills/（個人目錄）而不是專案裡，那它就會變成你所有專案都能用的個人指令。

進階：SKILL.md 還能寫更多東西

剛剛那個 /commit 例子，frontmatter 裡只寫了 name 和 description，這是最精簡的可用版本。實際上 frontmatter 裡只有 description 算「建議一定要寫」（讓 Claude 判斷什麼時候該用它），其餘全部是 optional，看你需不需要再加✅官方。常用的幾個欄位：

這組欄位清單、以及 disable-model-invocation／user-invocable 兩者的精確行為、還有 context: fork 搭配 agent 讓 skill 整個丟進子代理人執行的機制，都直接對照官方文件的 Frontmatter reference✅官方。（context: fork 也有反向鏡射：子代理人自己的 frontmatter 也能用 skills 欄位預先載入某些 skill 內容，兩者是同一組機制的一體兩面。）

還有一件事現在就先記住：description 本身在 frontmatter 規格層有個硬性上限——最多 1,024 字元✅官方。這跟本節後面「放在哪裡，就管多大範圍」那節會提到的 1,536 字元是兩個不同層次的數字，那邊再細講怎麼分。

description 怎麼寫，才會在對的時機被準確觸發

前面提過 description 是唯一「建議一定要寫」的欄位，因為 Claude 就是靠這幾句話判斷「現在該不該用這個 skill」。它值得你多花點心思寫好，下面是幾個官方與社群都認同的具體做法。

第一個原則：同時講清楚「做什麼」和「什麼時候用」，而且要用使用者實際會講的話，不是抽象的功能摘要✅官方。兩種寫法差在哪，看下面對照：

# ❌ 太抽象：只講做什麼，沒講什麼時候用
description: 處理 PDF 文件

# ✅ 具體：做什麼 + 什麼時候用，貼近使用者真的會講的話
description: 從 PDF 擷取表格與文字並轉成 Markdown。當使用者要求「把這份 PDF 整理成文字」「這份 PDF 的表格轉一下」時使用。

第二個原則：一律用第三人稱撰寫（像「Processes and validates PDF files」），不要寫成「I can help you...」這種第一人稱口吻——因為 description 最後會被原樣塞進系統提示，第一人稱讀起來會很奇怪，也不是寫給使用者看的文案✅官方。

第三個原則：加一句「不處理什麼」的邊界說明，避免跟其他相近的 skill 搶觸發、彼此誤會對方的地盤🌐社群。例如同時有處理 PDF 和處理 Word 文件的兩個 skill，各自在 description 補一句「不處理 .docx」「不處理 .pdf」，能明顯降低兩邊互相搶著跳出來的機率。

最後是命名慣例：skill 名稱優先用動名詞形式（像 processing-pdfs），避免取 helper、utils 這種模糊到看不出用途的名字，也避免用到保留字✅官方。

進階：SKILL.md 可以只當索引，額外檔案才是真正的血肉

目前為止的例子，SKILL.md 都是「唯一的一份檔案」。但 skill 其實可以綁定額外檔案，不用把所有東西塞進同一份文件裡——官方稱這是漸進式載入（progressive disclosure），分三層✅官方：

實際動手時，三個目錄各自的角色是✅官方：scripts/ 放可執行的腳本（Claude 用 bash 直接跑）；references/ 放唯讀的參考文件；assets/ 或 templates/ 放會被複製進最終產出成品的範本檔案，三者用途不同，別混用。

官方文件與社群整理出幾條撰寫紀律，養成習慣能少踩很多坑：

不想從零開始寫？官方在 github.com/anthropics/skills 放了一批現成範例（處理 pdf／xlsx／pptx／docx 等常見格式），另外還有一個專門協助 scaffold 新 skill 的 skill-creator 外掛，裝上之後跟著它的引導走一遍就能生出一份骨架完整的 SKILL.md✅官方。

動態注入與參數：讓 Skill 更聰明

Skill 內容裡可以直接放參數，也可以先跑一段指令、把結果塞進去再交給 Claude 看。先看參數：$ARGUMENTS 代表呼叫時你在指令後面接的全部文字，例如：

---
name: fix-issue
description: 依 GitHub issue 編號修 bug
disable-model-invocation: true
---
Fix GitHub issue $ARGUMENTS following our coding standards.
1. Read the issue description
2. Implement the fix
3. Write tests
4. Create a commit

存好之後打 /fix-issue 123，$ARGUMENTS 就會被換成 123。如果參數不只一個，也可以用位置取值（$1、$2……）或在 frontmatter 用 arguments 清單把每個位置命名成好記的名字。

另一招是動態內容注入：在 Skill 內容裡用 !`指令` 這種語法（反引號包住一行 shell 指令），Claude Code 會先真的去執行它，把輸出結果替換進去——Claude 讀到的是「已經跑好的實際資料」，不是指令本身。舉例，如果你想讓一個 skill 一開始就看到目前改了哪些檔案：

目前的改動：
!`git diff --stat`

請根據上面的改動整理一份簡短的變更摘要。

這樣少了一輪「Claude 自己再去跑一次指令」的來回，行為也更可預期。想全域關掉這個機制（例如企業環境不想讓 skill 檔案夾帶 shell 執行），可以設 disableSkillShellExecution: true。

裝別人寫的 Skill 之前，先做這些檢查

上一節提到 Skill 可以綁定 scripts/ 這類可執行檔案，前面也講過 !`指令` 這種動態注入語法會真的去執行 shell 指令——也就是說，一個 skill 本質上就是「一包能讓 Claude 取得新能力的指令加程式碼」。官方明講：只用你自己寫的、或 Anthropic 官方提供的 skill；來路不明的 skill 可能會讓 Claude 做出跟它宣稱用途完全不符的操作✅官方。

專案層 .claude/skills/ 裡設定的 allowed-tools，並不是你 clone 下來就自動生效——它要等你在工作區信任（workspace trust）對話框裡按下接受，才會真的套用。官方的提醒是：信任一個 repo 之前，先把裡面的 project skill 看過一遍，因為一個 skill 可以自己把自己的工具權限開得很寬✅官方。

這其實跟高手篇會講的子代理人 tools 欄位「省略等於給全部工具，最小權限一定要明寫」是同一套紀律，只是這裡換成 Skill 版本：別人寫的 skill 拿到的能力，可能比它宣稱的還要多。

放在哪裡，就管多大範圍

跟 8.1 的 settings.json 很像，Skill 存放的位置也分層級，越廣（層級越高）的蓋過越窄的✅官方：

同名衝突時，全公司層蓋過個人層、個人層蓋過專案層；任一層的 skill 也會蓋過同名的內建 skill✅官方。外掛層則不在這個優先序裡搶位置——它強制帶 <外掛名>:<skill 名> 這種命名空間前綴，結構上就不可能跟其他三層的裸名稱撞名，不是「排第幾順位」的問題，是根本不會撞✅官方。如果你的專案是 monorepo，不同套件資料夾底下也可以各自放 .claude/skills/，Claude 處理該目錄下的檔案時會一併載入；真的撞名，可以用「路徑：skill 名」明確指定要叫哪一個，例如 /apps/web:deploy✅官方。

寫了 Skill 卻沒照預期運作，多半是下面三種狀況，對照著調整就好：

這個功能包，到底該用 Skill、subagent，還是舊的 slash-command？

官方文件講得很直白：舊的 .claude/commands/ 自訂指令已經併入 Skills——.claude/commands/deploy.md 跟 .claude/skills/deploy/SKILL.md 建立的其實是同一個 /deploy，行為完全相同。舊格式現在仍然能用，但官方建議新做的都改用 Skills，因為 Skills 多支援綁定檔案、觸發控制、丟進子代理人執行這些能力，是舊格式做不到的✅官方。

那如果選項是「留在主對話（用 Skill）」還是「切給高手篇會細講的子代理人（subagents）」呢？官方給了一組判準✅官方：

官方原句是這樣寫的：「Consider Skills instead when you want reusable prompts or workflows that run in the main conversation context rather than isolated subagent context.」（想要能重複使用、而且是在主對話 context 裡跑、不是隔離在子代理人 context 裡的流程時，考慮改用 Skills）——這句話正好點出兩者的分界線：要不要留在主對話的脈絡裡。

兩者也不是二選一、互斥的關係：回顧前面 context: fork 那個欄位，Skill 本身就能設定成丟進子代理人執行；反過來，子代理人的 frontmatter 也能用 skills 欄位預先載入某些 skill 內容——需要的時候可以搭著用，不用堅持只選一邊。

8.4　Hooks：讓某些動作「鐵定」自動發生

先講一個關鍵差別，這也是 Hook 存在的理由。你在第 5 章寫的 CLAUDE.md，裡面那些規則比較像「建議」——Claude 多半會照做，但偶爾可能跳過。Hook 不一樣，它是「鐵則」：只要到了你設定的那個時機，它一定會執行，沒有例外。

Hook 常見的用途有：每次改完檔案自動排版、commit 前自動跑一次檢查、Claude 要動手前先攔下危險操作、需要你回應時發個通知。

聽起來很技術？好消息是：你不用自己學怎麼寫，直接叫 Claude 幫你寫就好。

1. 1
   ✋動手做

   直接用白話跟 Claude 說你要什麼

   在對話框裡，用一句白話描述你要的自動化動作就好。不用懂語法，講清楚「什麼時候、做什麼」即可。例如下面這兩句，照著打都可以：

   寫一個 hook，每次編輯檔案後自動跑 eslint。
   
   寫一個 hook，擋掉任何對 migrations 資料夾的寫入。

   複製
2. 2

   讓它寫好，之後用 /hooks 檢查

   Claude 會幫你把設定寫進 .claude/settings.json。寫好之後，你隨時可以用 /hooks 看看目前裝了哪些 hook。

   ✅ 預期會看到

   Claude 會回報它建好了哪個 hook、在什麼時機觸發；之後打 /hooks，就會列出你目前所有已設定的 hook。

實際長怎樣：一個排版 Hook 的設定範例

如果你不只想「叫 Claude 幫你寫」，也想知道它實際寫出來的東西長什麼樣子——這裡直接攤開看。假設你要的是「每次改完檔案，自動跑一次排版檢查」，寫進 .claude/settings.json 的內容大概會是這樣：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "/path/to/lint-check.sh" }
        ]
      }
    ]
  }
}

matcher 欄位是拿來比對「哪些工具會觸發這個 hook」——這裡的 Edit|Write 代表「只要是 Edit 或 Write 這兩種改檔動作就觸發」，也可以寫 * 比對全部工具。command 欄位就是真正會被執行的那行 shell 指令，這裡指向一支排版檢查腳本。

如果反過來，你要的是「動手前先攔下來」——像本節一開始「擋掉對 migrations 資料夾的寫入」那個例子——寫法會落在 PreToolUse 那組，效果也不同：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "if": "Bash(rm *)", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh" }
        ]
      }
    ]
  }
}

這裡多了一個 if 欄位：只有指令真的符合 Bash(rm *) 這個模式時才會觸發攔截，不是每次跑 Bash 都擋。command 型是目前最常見的 hook 類型；官方還支援 http（送去某個網址）、mcp_tool（呼叫已連線的 MCP 工具）、prompt ／ agent（丟給模型自己判斷是非）等進階類型，這些留到大師篇的〈Hooks 自動化〉章節細講。

退出碼在說什麼：一定要懂的三種結果

Hook 腳本執行完，用「退出碼」（exit code）告訴 Claude Code 結果怎樣，這個規則值得記住：exit 0 是「放行」，一切正常繼續；exit 2 是「攔下來」——腳本印在錯誤輸出（stderr）的內容，會被回饋給 Claude 當作「為什麼被擋」的理由；其他退出碼代表「這個 hook 本身出錯了」，動作不會被攔，但畫面上會顯示一句「＜hook 名＞ hook error」提醒你去看。要特別提醒：只有像 PreToolUse 這類「動手前」的事件才擋得住動作，PostToolUse 這類「事後觀察」的事件就算 exit 2，也沒辦法讓已經發生的事情復原，只能把 stderr 的內容顯示給 Claude 看。

還有一個容易忽略的小地方：如果你的 PostToolUse hook 是「自動排版」這類會真的改到檔案的動作，Claude 每次都會收到一則「這個檔案被改了」的系統提醒——次數一多，會慢慢吃掉不少 context。也因為每個專案慣用的排版工具、規則常常不一樣，社群普遍建議把這類 hook 放在專案層（複習 8.1 的四層設定檔）而不是個人層，讓它只在真的需要的專案裡發生。

8.5　五個積木怎麼搭（官方的心智模型）

到這裡你已經碰過好幾種「客製化」的工具了。官方把 Claude Code 能客製的部分，歸納成五塊積木，各自解決不同的問題。先有個整體印象，之後要用哪一塊就比較不會混。

實際上它們常常搭在一起用。一個典型組合是：用 CLAUDE.md 放專案規範、用 Skill 放部署流程、用 MCP 連資料庫、用 Hook 在每次編輯後自動跑檢查。不用一次學會全部，需要哪塊再回來看哪塊就好。

官方部落格另外給了一個更實用的判斷角度：與其想「這五塊各自解決什麼問題」，不如想「養它要花多少 context 成本、指令的權威性有多高」。把這兩個維度放一起看，你會更清楚該把某條規則放進哪一塊：

表格最後多列的「Output Style」是第六塊，8.8 會專門帶你設定，這裡先知道它站在這張表的哪個位置就好。

8.6　選模型與用量

這一節完全是「進階、非必須」的。 多數人用預設就很好，不用碰模型設定。等到你「想要更聰明一點」或「想省一點花費」的時候，再回來這裡照著挑就好。

Claude Code 背後其實有好幾種「模型」可以選，差別大致是「越聰明的，跑得越慢、花費越高」。你可以隨時切換，依當下任務挑剛剛好的那一個。切換的指令是 /model：在對話裡打它，就會讓你選要用哪個模型。

那要怎麼挑？用一張表記住「什麼時候用哪個」最快：

除了換模型，還有一個 /effort 指令，可以調整 Claude 在「想」這件事上投入多少力氣——願意多花一點時間想得更周全，或是快一點給答案。一樣是「需要再用」，平常不用特別管。這兩個（/model、/effort）你都不設也能正常用，它們是給你「想再調細一點」時的工具。

💡 範例：實際切換時可以這樣打

# 啟動時直接指定，只影響這一個 session
claude --model opus

# 對話中隨時切換，按 Enter 會存成新的預設值
/model sonnet

# 混合模式：規劃階段用 Opus 仔細想，動手改檔自動切回 Sonnet
/model opusplan

# 調整這個 session 的推理力氣
/effort high

# 想恢復模型的預設力氣
/effort auto

上面的 /model opusplan 值得多說一句：它是專門為「規劃要仔細、執行要快」設計的混合模式——進入計畫模式（第 7 章教過的 /plan）時自動用 Opus 做架構思考，一旦離開計畫模式開始實際改檔，又自動切回 Sonnet，你不用自己手動切兩次。

還有一個更輕量的技巧：不想切 /effort、只是這一輪想讓它多想一點，直接在你的訊息裡打 ultrathink 這個關鍵字（不是指令，就是打在句子裡的一般文字），Claude Code 會辨識並加深這一輪的推理，用完就恢復，不會動到這個 session 存下來的 effort 設定。如果你是團隊或企業帳號、想把「別人的 opus 到底指的是哪一版」鎖死，官方還提供 ANTHROPIC_DEFAULT_OPUS_MODEL 之類的環境變數，可以把模型別名釘死在特定版本號，避免它跟著官方更新自動漂移——這是團隊管理者才需要煩惱的細節，個人使用不用管。

8.7　終端機的門面：主題、狀態列、Vim 模式與按鍵綁定

前面幾節都在講「Claude 怎麼做事」，這一節換個角度，講「畫面長什麼樣子、打字手感怎麼調」。這些全部是外觀類的個人化，改了不會影響它幫你做事的能力，純粹是讓你自己盯著螢幕的時候更順眼、打指令更順手。挑你在意的挑著看就好。

切換主題

覺得目前的顏色看不順眼，或想要更高對比？打 /theme（也可以從 /config 的選單裡找到主題那一項）叫出主題選單。內建六種：

還有一個 auto 選項：不自己挑顏色，而是跟著作業系統目前的深色／淺色模式自動切換，系統換你就跟著換，不用自己盯著手動改。

Vim 編輯模式

習慣 Vim 那套「按鍵移動、按鍵編輯」手感的人，可以打 /vim 開啟 Vim 風格編輯模式（也可以直接在 settings.json 裡設 "editorMode": "vim"，讓它一開始就是這個模式）。開了之後，打字輸入框支援 hjkl 移動游標、v ／ V 進入選取、d ／ c ／ y 搭文字物件做刪除／修改／複製，這些都是 NORMAL／VISUAL 模式下最常用的操作。

重新綁定按鍵

對某個快捷鍵的位置不順手？打 /keybindings 會打開按鍵綁定的設定檔，裡面任何一個按鍵都能重新綁定成你要的組合。這個功能比較小眾，用到再回來查就好，不用特別背。

狀態列客製化：statusLine

畫面最下面那一行，可以放你想看到的即時資訊——目前用哪個模型、context 用了多少百分比、這輪對話花了多少錢，都能顯示在這裡。這是所有客製化裡「效果最直接看得到」的一個，跟著做一次就懂了。

1. 1
   ✋動手做

   打 /statusline，用人話描述你想看到什麼

   不用自己寫程式、不用懂 jq 怎麼用。直接打 /statusline 加上一句白話描述，Claude 會自動幫你生成腳本、寫進設定：

   /statusline 顯示目前的模型名稱和 context 使用百分比，用一個小進度條表示

   複製
2. 2

   畫面最下面那一行，就會照你說的樣子更新

   Claude 會把腳本寫進 settings.json 的 statusLine 欄位，運作方式是：每次要顯示前，Claude Code 把這個 session 的資料（模型名稱、目前目錄、context 用量、花費等）用 JSON 格式透過標準輸入傳給你的腳本，腳本印到標準輸出的內容，就是畫面上看到的那一行。

   ✅ 預期會看到

   畫面最下方多出一行，內容照你描述的樣子顯示；之後每次 Claude 回完一則新訊息、每次 /compact 完成、切換權限模式或 Vim 模式，這一行都會跟著刷新一次。

想自己動手寫也可以。statusLine 支援多行輸出、ANSI 顏色碼、甚至 OSC 8 超連結。下面是一個最簡單的手動範例：在 settings.json 裡指定一行 jq 指令，解析從標準輸入送進來的 session JSON，抓出模型名稱和 context 使用率：

{
  "statusLine": {
    "type": "command",
    "command": "jq -r '\"[\\(.model.display_name)] \\(.context_window.used_percentage // 0)% context\"'"
  }
}

如果你希望這行內容會自己跳動（例如放個時鐘），可以另外設 refreshInterval 讓它定時重新整理，不用等有新訊息才刷新。

8.8　換一套系統提示：Output Style

前面幾節都是「它做什麼」，這一節是「它怎麼跟你互動」。Output Style 直接改寫 Claude 的系統提示，換一套「說話的方式」——不只是語氣，連它主動教不教你、要不要留步驟給你自己動手，都可以整套換掉。

除了預設風格，內建還有兩種：Explanatory（講解型）會在完成任務的同時，穿插幾則「Insights」小提示，邊做邊教你背後的原理；Learning（協作學習型）走得更遠，它會主動在關鍵的地方停下來，請你自己動手寫一小段程式碼，而不是全部代勞。想練功、不只想要成品的話，Learning 這個模式值得一試。

💡 切換方式

# 不加參數：打開選擇清單自己選
/output-style

# 直接指名切換
/output-style Explanatory

切換的結果會存進個人本機層（.claude/settings.local.json，複習 8.1 的那張層級表）——只影響你自己、只影響這個專案。

回頭對照 8.5 那張表：Output Style 是六塊積木裡權威性最高的一塊——它直接改寫系統提示本身，而且不受 /compact 壓縮影響，適合放「角色、語氣」這種你希望整個對話從頭到尾都貫徹的長期設定，不像 CLAUDE.md 那樣可能在對話很長之後被稀釋。