Claude 又寫出「load-bearing decision」「hard gate」「the shape of the work」這類句子,你讀得懂每個字,卻要多花一輪翻譯才知道該做什麼嗎?這種被社群戲稱為 Claudish 的語氣,問題不只在「聽起來很像黑話」:如果你只要求它變短,改寫後仍要檢查數字、否定詞、例外與不確定性是否被刪掉。
2026 年 8 月,Reddit 上先後出現 English ↔ Claudish translator 討論與「又用 Claudish 回答」的貼文。這些貼文說明需求存在,卻沒有回答最重要的問題:改成白話後,必要資訊還在不在?
這篇教學會帶你建立一套可重跑流程:先用 Claude Code 內建 Concise 或自訂 Output Style 改寫,再以 CEFR B1/B2 作為語言目標,最後用同一批任務做 A/B Test。你不需要先懂語言學;完成後會有一份 style 檔、一張必留資訊清單,以及能判定「比較好讀但沒有失真」的驗收表。
先說結論:Claudish 白話化要同時通過兩道門
🧭 記憶把手:白話輸出=可讀性提升 × 資訊保真。
任一項為零,就算失敗。句子變短不代表讀者更會做決定;資訊全在,也不代表讀者找得到答案。

Claudish 是什麼?先把社群用語與官方功能分開
本文用 Claudish 指社群專案整理的一組語氣特徵:句子常用抽象名詞、隱喻與組織語言,例如 load-bearing、spine、shape、gating、hard gate。Claudish translator 的公開規格列出了這些詞;另一個 load-bearing vocabulary 專案則觀察公開 GitHub PR 描述的詞彙分布,不是 Claude 作者歸因研究。
截至 2026 年 8 月 29 日,Output Styles 官方文件列出 Default,以及 Proactive、Concise、Explanatory、Learning 四個額外內建 style,未列出 Claudish;Claudish translator 的 README 也明確稱自己是未隸屬 Anthropic 的非官方 parody project。換句話說,我們可以把這個詞當成方便辨認語氣的標籤,不能把它當作模型能力、診斷結果或所有 Claude 輸出的共同特徵。
更實用的判斷方式不是數「黑話」出現幾次,而是問:這個詞是否讓目標讀者更快找到答案、理解意思並採取正確行動?這也符合加拿大無障礙標準的 plain language 定義:讀者要能找到、理解並使用資訊。若 hard gate 真正意思只是「這項沒通過就不能發布」,直接寫後一句通常更好;但 API 名稱、檔案路徑或法規術語不能為了口語化而改掉。
先做 baseline:從自己的 Claude 對話抽 10 個真實案例
不要從一段特別誇張的回答開始。先從最近的對話抽 10 個你真的會做的任務,涵蓋進度摘要、錯誤解釋、方案比較、風險通知與下一步建議。數量只是容易起跑的最小樣本,不是統計保證;真正重要的是未來能用同一批案例重跑。
- 保存輸入:原始 prompt、附件文字與必要背景不能改。
- 標記重複語彙:例如 load-bearing、shape、gating;只作診斷,不直接判錯。
- 記錄句長:計算最長句與中位句長,找出需要重讀的段落。
- 圈出抽象名詞:把「alignment」「trajectory」改問成「誰在何時做什麼」。
- 建立必留清單:把每個數字、單位、日期、否定、條件、例外、風險、信心程度與必要下一步拆成獨立項目。
「必留清單」是整套方法的地基。例如原文是「若錯誤率高於 2%,才停止部署;測試環境除外」,至少要拆成:門檻是 > 2%、動作是停止部署、條件詞是「若」、例外是測試環境。改寫後只剩「錯誤率過高就停止」,讀起來更順,卻已經不能做同一個決定。
步驟一:先試 Claude Code 內建 Concise
如果你使用 Claude Code 2.1.237 或更新版本,先在 /config 的 Output style 選擇 Concise。這是可先試的內建起點,適合先確認「篇幅太長」是否已改善。官方文件也說明:Output Style 會改變 system prompt 中的回應風格,不會替換 Claude 的知識。
切換後執行 /clear 或開新 session,因為 style 在 session 開始時載入。截至 2026 年 8 月 29 日,官方文件已把 /output-style 標為移除,目前入口是 /config。若你主要困擾只是重複總結,Concise 可能已經夠用;若你還要指定繁體中文、CEFR 目標與保真規則,再進下一步。
步驟二:建立 Plain Fidelity Output Style
在專案建立 .claude/output-styles/plain-fidelity.md;想讓所有專案使用,則放在 ~/.claude/output-styles/。下面這份 style 把「白話」與「不得刪除的資訊」寫在同一處:
---
name: Plain fidelity
description: Plain language that preserves every decision-changing detail
keep-coding-instructions: true
---
Match the user's language.
For English prose, aim for CEFR B1. Use B2 only when a necessary
technical relation cannot be stated precisely at B1.
Lead with the answer. Use one main idea per sentence.
Prefer everyday, concrete words.
Explain an essential technical term once: "term (plain meaning)".
Use the same term for the same concept.
Remove ceremony, repeated summaries, and decorative metaphors.
Never remove or weaken numbers, units, dates, names, negations,
conditions, exceptions, uncertainty, warnings, required actions,
code, paths, commands, or exact error text.
Preserve modal force: must is not should; may is not might.
If simpler wording would change meaning, keep the precise wording
and explain it. Before answering, silently restore any lost
decision-changing detail.
keep-coding-instructions: true 很重要:自訂 style 預設可能排除 Claude Code 內建的 software-engineering instructions;若任務包含改 code,就應明確保留。完成檔案後回到 /config 選擇 Plain fidelity,再 /clear。如果一般 subagent 也會撰寫文件,要另外測它,因為一般 subagent 使用自己的 system prompt;只有 fork 型 subagent 會繼承主對話 style。
Output Style 管跨任務的表達方式;專案特有規則仍放 CLAUDE.md。如果你還不熟這些層次,可先看《Claude、Claude Code 與 Cowork 差在哪》與《AI Agent Harness 是什麼》。
步驟三:用 CEFR B1/B2 當目標,不當自動及格章
歐洲理事會的 CEFR用六個等級與「能做什麼」描述語言能力。它原本是語言學習者能力框架,不是單篇 Claude 回答的官方可讀性分數。因此,要求 B1/B2 可以幫你描述目標讀者,不能單靠某個自動分數宣告文字已經清楚。
以下只是本文的寫作 heuristic,不是 CEFR 官方文本分級:優先用常用、具體詞與較短句;若簡化會改變必要技術關係,就保留精確表述並補一句白話解釋。最後仍要讓真實目標讀者回答問題與做決定。這比只追求「句子越短越好」可靠,也能避免把必要專有名詞換成模糊同義詞。
步驟四:做 Claudish before/after A/B Test
Anthropic 的 Eval 指南建議成功條件要具體、可量測且貼近真實任務,測試案例也要涵蓋常見情況與 edge cases。把 A 設為目前使用的 Default 或 Concise,B 設為 Plain fidelity;兩組使用完全相同的 prompt、附件與必留清單,並各自開新 session。
- 把輸出隨機標成 X、Y,先不要讓評讀者知道哪個 style。
- 記錄讀到可以回答任務問題所需的時間,而不是捲到最底的時間。
- 要求評讀者選擇下一步,計算決策是否正確。
- 逐項核對必留清單,計算資訊保留率。
- 最後才比較重複術語、句長與總字元;它們是診斷,不是勝負條件。
最小 scorecard 可寫成:資訊保留率=保留的必留項目 ÷ 全部必留項目。但別讓平均分掩蓋致命缺漏:任何一個數字、否定、條件、例外或不確定性遺失,都直接判為 hard fail。只有兩版都通過保真,才比較閱讀時間與決策正確率。
如果只有你一位評讀者,也能先做小型測試:隔一天、打亂順序、遮住 style 名稱,再回答事先寫好的三個問題。這不能取代多人研究,卻比「我覺得 B 比較順」更可重跑。若你同時想量 token 與篇幅,參考《Claude 怎麼省 token》;兩者要分開記錄,因為字少不必然等於成本或理解負擔較低。
Translator 只能當最後一道改寫器
社群的 Claudish translator可用來辨認語癖或產生改寫候選;它的規格也要求保留 facts、intent、certainty 與 implications。不過,第三方改寫器仍不應取代驗收。較可控的用法是:原文與必留清單先凍結,translator 只處理複本,改完逐條比對。
- 數字與單位:
2%、2 個百分點與「大約 2%」不能互換。 - 否定詞:「不會刪除」不能被縮成「會保留大部分」。
- 條件與例外:if、unless、except、only when 都要保留作用範圍。
- 模態強度:must、should、may、might 分別代表不同義務與信心。
- 不確定性與歸屬:估計、觀察、官方說法、作者推論不能混成確定事實。
- 不可改識別字:程式碼、路徑、命令、API 名稱與完整錯誤文字保持原樣。
三個常見失敗:變短、換詞、全域套用
- 只設字數上限:可能讓條件被刪除。先鎖定必留資訊,再設定軟性篇幅目標。
- 每個術語都換成日常詞:技術精度可能一起消失。解法是保留必要術語,第一次出現補白話括號。
- 一份 style 套所有輸出:錯誤 log、程式碼、合約與新手教學的需求不同。解法是用真實任務分組,逐組設 acceptance criteria。
如果你還想讓 AI 保留個人語氣,而不只降低術語密度,可延伸閱讀《AI 寫作去 AI 味:5 步打造個人聲音系統》。若你的規則越寫越多,則應把 style、專案規則與驗收工具拆層,避免所有問題都塞進一個超長 prompt。
Claudish 常見問題 FAQ
1. Claudish 是 Anthropic 的官方名稱嗎?
截至 2026 年 8 月 29 日,官方 Output Styles 文件未列這個名稱;本文把它當作 2026 年社群描述特定語氣的暱稱。
2. 只在 prompt 寫「請用白話」不行嗎?
單次任務可以,但很難保持一致,也沒有定義什麼不能刪。Output Style 適合放跨任務規則,必留清單負責驗收。
3. CEFR B1 一定比 B2 好嗎?
不一定。B1 是較低的語言門檻;遇到必要技術關係時,精確的 B2 表達加一句解釋,可能比勉強換詞更清楚。
4. 怎麼知道改寫沒有丟資訊?
改寫前先列原子化必留項目,改寫後逐項核對。任何數字、否定、條件、例外或不確定性遺失,都判失敗。
5. Output Style 會改變 Claude 的知識嗎?
官方文件把它描述為改變回應風格的 system-prompt 調整,不是替換模型知識。它仍可能影響資訊如何被選擇與表達,所以要做保真驗收。
6. 為什麼改完 style 要執行 /clear?
因為 style 在 session 開始時載入;要讓新內容生效,需清除目前 session 或重新開啟。
7. Claudish translator 可以直接處理機密文件嗎?
先查清楚你採用的工具如何處理資料,再決定能否放入敏感內容。本文流程不要求上傳文件;也可以只把 translator 當詞彙範例,手動改寫複本。
8. 這套方法只適用 Claude Code 嗎?
自訂 Output Style 的檔案與選單是 Claude Code 工作流;baseline、必留清單與盲化 A/B Test 則可套用到其他 AI 寫作工具。
五個重點帶走
- Claudish 是本文採用的社群語言標籤;截至 2026 年 8 月 29 日,官方 Output Styles 文件未列這個名稱。
- 先試內建 Concise;需要明確保真規則時,再用 Plain fidelity。
- CEFR B1/B2 是目標讀者的語言提示,不是單篇文字的自動及格章。
- A/B Test 先看決策正確率與資訊保留,再看閱讀時間與句長。
- 任何數字、否定、條件、例外或不確定性遺失,都不能用「更精簡」抵銷。
想把同一套驗收思路延伸到更多工具,可瀏覽 AlphaLab AI 專區;需要循序練習完整工作流,則可從 AlphaLab 線上課程開始。
接著閱讀
左右滑動查看更多推薦
現在就做:先拿一則回答建立必留清單
不要先追求完美 style。從今天的一則 Claude 回答開始:圈出數字、否定、條件、例外與不確定性,開新 session 跑一次 Plain fidelity,再請另一位讀者回答「結論是什麼、下一步是什麼、什麼情況例外」。三題答對且必留資訊全在,才算真的從 Claudish 變成可用白話。






