Claude Code Output Style 是什麼？從 Concise 模式談起
Claude Code 的 Output Style（輸出風格）是一組可以整包切換的預設指示，用來改動 Claude 的 system prompt。 你選了哪一種，就決定了 Claude 在整個 session 裡怎麼工作、又怎麼跟你回話：從「盡量把來龍去脈解釋清楚」到「先給結果、少講廢話」，換一個 output style 就切掉了。 它直接改動 system prompt，甚至能把內建那套軟體工程預設指示整組換掉；CLAUDE.md 走的是另一條路，它把你的專案慣例補在系統指示之外，不會去動內建那套。
最近在 X 上滑到 @ClaudeDevs 的一則推文，說現在可以把 output style 設成 Concise，讓 Claude 先講結果、回應保持精簡，需要細節時再展開。 於是就查了一下資料，把目前有哪些模式、怎麼切、又有哪些容易踩的雷，一次整理清楚。
目前有哪些內建模式？
output style 是內建的，你不用自己動手寫，開箱就有好幾種可以挑。寫這篇的時候（2026 年 8 月），官方內建的有下面這幾種，之後很可能還會再增減，看到清單長得不一樣別太意外。
Default（預設），是你什麼都沒設定時的樣子，一份專門為軟體工程任務調校過的 base system prompt。多數時候你要的其實就是它：平衡、通用，沒事不用去動它。
Explanatory（解說型），會讓 Claude 一邊幫你做事，一邊在過程中穿插「Insights」小段落，解釋它為什麼這樣實作、這段程式在整個 codebase 裡扮演什麼角色。適合你想邊做邊把脈絡搞懂的時候，例如剛接手一個還不熟的專案。
Learning（學習型），是比 Explanatory 更進一步的協作模式。它除了給你 Insights，還會刻意留白：在程式碼裡插上 TODO(human) 標記，把一小段關鍵邏輯丟回來讓你自己寫。走的是 learn-by-doing 的路子，拿來練功、邊做邊學最合適。
Proactive（主動型），會讓 Claude 更傾向直接動手。遇到那種例行、無關緊要的決策，它就自己做個合理假設，不會每一步都停下來問你。重行動、輕規劃，想讓它少囉嗦、快點往前推進時滿好用的。
Concise（精簡型），是這波的新成員。Claude 會先把結果講出來，跳過開場白跟一路上的碎念旁白，但該做多仔細還是做多仔細，你要細節再追問它就補上。適合你已經知道自己要什麼、只想直接看產出的時候。
怎麼切換 output style？
切換有兩條路，互動式的話，在 Claude Code 裡打 /config，找到 Output style 那一欄，挑一個就換好了。 想把它寫死在設定檔，就在 settings.json（或專案裡的 .claude/settings.local.json）加一行 "outputStyle": "Concise"。
有個地方很容易卡到：改完不會馬上生效。 output style 是在 session 開頭就套進 system prompt 的，你在對話中途去改設定檔，當下這個 session 不會跟著變，得先 /clear、或乾脆開一個新的 session，才吃得到新的風格。
還有一個舊資訊要注意：早期是用 /output-style 這個獨立指令切換，後來被標記棄用、接著整個移除，現在一律走 /config。 如果你在網路上還翻到教你打 /output-style 的舊文章，那已經是過期資訊了。
順帶釐清一下，output style 跟 Skills 是兩件不同的事：output style 換掉的是 Claude 工作與回話的整體風格，擴充技能（Skills）則是按需載入的技能包，我之前寫過一篇介紹，想深入可以接著看。
有哪些容易踩的坑？
最需要先搞懂的，是 output style 改動的層級。開頭提過它會直接改動 system prompt，而更容易咬到人的是：有些風格會把內建的軟體工程預設指示整組關掉（例如你拿它來當純寫作或資料分析助手時）。這種風格的手感會跟 Default 差很多，那是設計如此，別一遇到就以為壞了。CLAUDE.md 跟 --append-system-prompt 就沒這回事，它們只往上「加東西」，不會拿掉任何預設行為。
再來是生效時機。前面切換那段提過，改了設定不會套用到當下的 session，要 /clear 或開新 session。這點最容易讓人卡在「我明明設定了，怎麼沒反應」。
版本落差也是一個坑。output style 這功能還在長，官方文件的更新速度不見得跟得上實作。以 Concise 為例，它推出的當下，官方的 Output styles 文件甚至還沒把它列進去，你得去翻 changelog 才找得到。所以哪天文件上的模式清單跟你 /config 裡看到的對不起來，先別懷疑自己，多半是文件還沒同步；真要確認，對一下自己的 Claude Code 版本跟 changelog 最準。
很常被搞混的一點：Proactive 不等於放寬權限。它讓 Claude 更願意直接動手、少問你那些例行決策，但它管的是「做事風格」。至於該不該讓 Claude 自動跑指令、自動改檔案，那是「權限模式（permission mode）」在決定的，跟你選哪個 output style 是兩套獨立的開關，別把「它變主動了」直接讀成「它拿到更大權限了」。
Learning 有個它專屬的狀況。選了它，Claude 會在程式碼裡插上 TODO(human) 標記，故意留一小段讓你自己補。第一次遇到很容易以為它「做到一半偷懶」，其實那正是這個模式的設計，本來就要你捲起袖子一起參與。如果你只是想趕快把功能生出來，那 Learning 就不會是你要的。
最後，要是內建那幾種不夠用的話，output style 是可以自訂的，Claude 允許我們寫自己的風格檔來進行擴充。
這部分跟 CLAUDE.md 同樣的概念，要留意設定的作用範圍（Scope）：放在使用者層級（user）會套用到你所有專案，放在專案層級（project）則只影響當前這個 repo。 團隊共用的專案尤其要想清楚，你設的到底是「我個人的偏好」還是「這個專案的規範」，這兩種東西最好別混在一起放。
詳細的內容可參考官方文件 Output styles: Create a custom output style
結論
我理想中的輸出風格，其實蠻接近 Concise 的：回應短一點、解釋精簡一點、直接切進重點，少一點鋪陳跟客套，多留一點篇幅給實際的程式碼。 多數時候我要的就是「東西做好了、結果在這」，背後的來龍去脈，如果我需要的話再自己開口問。
順著這個邏輯往下想，我猜這種風格連帶耗掉的 token 也會少一些，畢竟廢話寫得少。 不過這純粹是我的推斷，我沒有實際量過前後的 token 數。
如果你正在學一個不熟的東西，選 Explanatory 或 Learning 那種邊做邊解釋的風格反而更有價值。 Output Style 好用的地方在於，你知道手上這件事適合哪一種，然後在 /config 裡換過去就是了。