Claude Code onepage/ Output Style
Gary Chen · YouTube · 11:41
Claude 看起來降智？先調整 Output Style
有些 Claude Code 回覆讓人覺得繞、術語多、讀不下去，未必是模型能力下降。這支影片提醒一個更實用的檢查點：先把輸出的角色、語氣與格式，調成自己真正用得上的工作介面。
Published: 2026-08-12Video ID: E8Bx9OlpmdMSource: Gary Chen
01 / 先釐清
不是模型換腦
Output Style 修改系統提示中的角色、口吻與輸出格式；它不會增加模型知識，也不是解決推理或上下文不足的萬用開關。
02 / 內建選項
先從四種風格試起
Default 維持原本工程工作流；Proactive 偏向直接行動；Explanatory 多補充解釋；Learning 讓你以實作方式參與。
03 / 長期解法
把重複要求變成 style
若你總在要求同一種語氣、術語密度或回覆結構，將它寫成 project 或 user 層級的自訂 style，比每次重新 prompt 更穩定。
Key signals
這支影片真正要解的，是「理解成本」
Setting
/config
在設定介面選 Output style；也能於設定檔直接指定
outputStyle。Built in
4 styles
Default、Proactive、Explanatory、Learning，適合先用來辨認自己的偏好。
Custom
Markdown
自訂 style 是帶 frontmatter 的 Markdown 檔，可放在使用者或專案層級。
Timing
new session
Style 在 session 開始時載入；調整後以
/clear 或新 session 讓它生效。How to choose
把問題分對類，才不會錯怪模型
A
回覆太學術、太長、太難掃讀
這是 Output Style 最合適的場景。把受眾、術語程度、固定結構與「先講結論」寫清楚，讓每一輪都用相同閱讀介面回應。
B
專案慣例或架構背景沒被遵守
優先使用 CLAUDE.md。它用來提供專案脈絡、約定與規則；Output Style 則是跨回覆的表達方式，不應混成專案說明書。
C
答案真的缺資料、理解錯或推理不足
這不是換 style 能修好。補足問題、提供必要檔案與上下文，或換用更適合的模型與工作方式；先分辨能力問題和溝通問題。
Practical setup
30 秒做出一個可用的輸出規格
1. 觀察你重複改什麼例如：先給結論、少用抽象術語、用繁體中文、每個決策要交代取捨。重複出現的要求就是 style 的候選內容。
2. 先選最接近的內建 style需要邊做邊理解可試 Explanatory；想提高自主執行傾向可試 Proactive。先確認差異，再決定是否自訂。
3. 仍在寫程式，就保留 coding 指令自訂 style 可設
keep-coding-instructions: true，在改變表達方式的同時，保留 Claude Code 原本的工程工作規則。4. 重開 session 驗證設定不會回溯套用到已開始的對話。用
/clear 或新 session，拿同一題比較前後輸出是否真的降低理解成本。Trade-offs
自訂 style 很有用，但別把所有規則塞進去
它會增加系統提示與 token 使用風格指令越長，輸入 token 越多；快取能降低後續成本，但仍應保持內容精準、可檢驗。
風格與任務規則要拆開「怎麼說」放 Output Style；「此專案採用什麼框架、如何測試」放 CLAUDE.md。分開才能降低規則互相打架。
保留一份極簡版本先用十行內描述受眾、格式和禁忌，經過幾次實戰再加規則。太早寫成長篇人格設定，通常反而難以維護。
以可讀性為成效，而非「更像人」好的 style 應讓你更快判斷下一步、理解風險與修改內容；不是讓模型講得更花俏。
Timeline
11 分鐘影片的閱讀路線
從「Claude 是否變笨」的感受切入先辨識讀不懂輸出時，模型能力與表達方式是兩個不同問題。
ELI5 風格作為溝通對齊的例子用不同技術深度的說法，展示同一能力可以被包裝成不同理解門檻。
內建四種 Output Style影片依序帶到內建選項，讓使用者先有低成本的比較基準。
用 branch 建立自己的風格從個人常見需求抽出一套可反覆使用的規格，而不是每次重新下指令。
另一條路：以 skill 影響工作流影片也比較以 skill 封裝提示的做法；適用範圍和持續套用的 Output Style 不同。
讓設定跟著專案與需求調整固定人格不是目標；在不同專案、受眾與任務間有意識地選擇風格才是。
References