一開始，大家都是這樣湊合的。

你嫌 Claude 回話太囉嗦，於是在 CLAUDE.md 最上面加一行：「請簡短回答，不要解釋。」過幾天你在帶一個新人，又想讓它多講一點原理，於是把那行刪掉，改成「請詳細說明每個決策」。再過幾天你自己想學東西，又想要它邊寫邊考你……於是這個檔案變成一個被反覆塗改的便條紙，今天要它閉嘴、明天要它多嘴，改到最後你自己都忘了現在到底設成哪一套。

這個小麻煩，就是 Output Styles 會出現的原因。它把「Claude 該怎麼跟你說話」這件事，從散落在 CLAUDE.md 裡的零碎叮嚀，變成一個可以一行指令切換的開關。

先搞清楚它改的是什麼

這裡有個概念很容易混。Output Styles 改的，不是 Claude 知道什麼，是 Claude 怎麼把知道的東西講給你聽。

打個比方。同一個資深工程師，今天面對客戶簡報，他會講重點、不碰細節；明天帶實習生，他會把每一步拆開、邊做邊解釋為什麼；後天跟同級的人結對寫程式，他可能寫一半停下來說「這段你來」。這個人的知識完全沒變，變的是他根據對象切換的「表達模式」。Output Styles 就是給 Claude 裝上這個切換開關。

理解這點，你就懂了它跟 CLAUDE.md 的分工：CLAUDE.md 存的是「這個專案的事實」——用什麼框架、有哪些慣例、別碰哪幾個檔；Output Style 存的是「Claude 這個角色怎麼表現」——話多話少、解不解釋、要不要反過來考你。一個是劇本，一個是演法。把演法從劇本裡抽出來，劇本才不會每次調語氣就被改得面目全非。

內建的兩種，剛好對應兩種場景

更新到最新版後，用 /output-style 這個指令就能看到內建選項。除了預設的 Default，最值得認識的是另外兩種。

Explanatory（解說模式）。打開它，Claude 在寫程式的過程中會一路附上推理：為什麼選這個做法、這裡有什麼取捨、背後的架構決策是什麼、什麼是這個情境下的最佳實踐。它適合的場景很具體——你在讀一份不熟的 codebase，或你想搞懂它「為什麼這樣改」而不只是「改了什麼」。把它想成那種會邊修車邊跟你講「我為什麼先拆這顆螺絲」的師傅。

Learning（學習模式）。這個更有意思，它直接把互動變成結對程式設計：Claude 寫一寫，會在程式碼裡插入 #TODO 註解，然後停下來，要你親手補完那一小段。它不是替你把活全幹完，是故意留白讓你動手。這背後的道理，任何學過東西的人都懂——你看別人寫一百遍，都不如自己卡住一次學得牢。Learning 模式賭的就是這個：把「看懂」逼成「做過」。

光是這兩種的存在就透露了一件事：Anthropic 很清楚，同一個工具，給「想趕快交差的人」和「想順便學會的人」用，最好的回應方式根本是相反的。

自己做一個，其實就是寫一張角色設定

內建的不夠用？Output Style 本質上就是一段 Markdown，描述你要 Claude 用什麼模式回應。你可以為自己常見的情境各做一個——比如一個「Code Review 模式」只挑問題不寫程式、一個「簡報模式」只給結論不給過程。

做法跟你寫 CLAUDE.md 的肌肉記憶很像，差別只在你寫的不是專案知識，而是「表達規則」。寫的時候有個小心法：別把它寫成知識庫（那是 CLAUDE.md 的活），就專心描述語氣、詳略、互動方式這幾件事。一個 style 只管一種「演法」，越純粹越好切換。

順帶一提，這套「把擴充打包成可分享單元」的思路，在 Claude Code 裡是一以貫之的——output styles 跟 skills、subagents、slash commands、hooks 一樣，都能被收進一個 plugin 裡整包帶走。所以你今天為自己調的回應風格，哪天要分給整個團隊，並不需要每個人重設一遍。

不是只有 Claude 在想這件事

值得停下來看一眼隔壁。讓 AI 換個方式跟你互動，是 2026 年這一整類工具的共同方向，只是各家切入點不同。

GitHub Copilot CLI 在六月初加了一個 /rubber-duck 指令，專門讓它用「唱反調」的方式給你對抗性的回饋——不是順著你講，是逼你把想法講清楚到能反駁。Kiro 則走得更前面，它乾脆把整個開發流程改成 spec-driven：不急著生程式碼，先陪你把目標、邊界情況、驗收條件定義清楚。

把這三者擺在一起看，方向是一致的：大家都發現，AI 真正的價值不只在「能不能寫對」，更在「用什麼方式陪你工作」。Claude 的 Output Styles 是其中最輕、最即時的一種——一行指令就換一種演法，不用改設定檔、不用重開專案。

（這部分我大多是讀文件和官方更新整理的，Learning 模式我自己跑過幾次、Explanatory 用得最多；自訂 style 的細節各版本可能會調整，以官方 /output-style 當下顯示的為準。）

接下來往哪走

如果你是第一次碰，最快的上手路徑是這樣：先用 /output-style 把 Explanatory 打開跑一兩天，習慣「它會解釋」這件事；接著在你想學新東西時切到 Learning，逼自己動手；等你開始覺得「這兩種都不完全是我要的」，那一刻就是你該動手寫第一個自訂 style 的時候——因為你已經清楚知道自己要什麼演法了。

往更大的方向看，Output Styles 其實是一個更根本的轉變的縮影：我們正在從「調教 AI 懂更多」，慢慢移到「設計 AI 怎麼跟人協作」。前者拼的是模型，後者拼的是你對自己工作方式的理解。而後面這件事，沒有任何模型能替你想清楚——它只能等你決定好了，照著演。

參考來源：Claude Code Docs - What’s New