fluent-korean：把韓國語規範寫進 Claude Code 的 output-style
Claude Code가 명확한 한국어를 구사하게 만드는 output-style 플러그인 | Claude Code output-style for clear, fluent Korean
秒懂
- 它是什麼？
- 這是一個以系統提示詞約束 Claude 輸出韓國語品質的 output-style 外掛，訴求是語意明確而非文采。它解決的是什麼、以什麼機制運作、以及它在多長的工作鏈上會失效，是採用前該弄清楚的事。
- 適合誰用？
- 如果你以韓國語對 Claude Code 下指令，或產出物本身包含韓國語，這個外掛值得先試；如果你的工作環境根本不是 Claude Code，或你真正想解決的是翻譯腔與 AI 套語，那它對不上你的問題，README 也直接指向 im-not-ai、korean-skills 這類 skill。採用前先確認三件事：你的環境有沒有可切換 output-style 的設定入口、你要的是 fluent-korean 還是 fluent-korean-not-coding、以及副代理與長流程下條款是否真的被遵守。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 24 天前。
- 用什麼語言寫的？
- GitHub 沒有提供這個儲存庫的主要語言。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要修的不是文筆，是掉零件的句子
README 對病灶的描述很具體：助詞與語尾脫落、名詞堆疊的電報體、被替換成隱喻的詞彙。這三種現象在韓國語裡不是風格問題，是理解成本的問題。助詞承擔格位資訊，語尾承擔時態、敬語與句間關係，兩者一起被省略，句子就只剩關鍵詞，讀者得靠上下文回推語法。名詞堆疊則讓修飾關係完全不明，同一個複合名詞可以讀成三種不同的從屬結構。
作者把目標寫得很清楚：追求「확실한 의미 전달」，而不是修辭上的漂亮。這個定位決定了它的適用範圍。它不處理翻譯腔、不處理 AI 套語、也不處理拼寫錯誤，README 在「이 도구의 역할과 범위」一節把這些明確讓給 im-not-ai、korean-skills、k-skill 的 korean-humanizer。這種自我限縮在同類工具裡少見，也讓它的邊界比多數 prompt 集合清楚。
對象也講明了：以韓國語輸入指令的人、產出物含韓國語的人，尤其是多代理或 harness 這類代理之間互相傳遞韓國語提示與資料的環境。README 給的理由是品質劣化會逐階段累積，這個說法在架構上成立，因為前一階段的輸出就是後一階段的輸入，而低品質韓國語在壓縮成摘要時更容易丟失語意。
output-style 是在系統提示詞層先立規矩
這個外掛的機制沒有執行期元件。它是一份放在 plugins/fluent-korean/output-styles/ 底下的 md 檔，選定之後被併入系統提示詞，在對話開始之前就把韓國語規範寫進去。README 用「사전에 규율합니다」描述這件事，重點在事前約束而非事後修正。
這個選擇有代價。系統提示詞層的約束對整個 session 生效，覆蓋面最廣，但也最容易被後續內容沖淡。README 在「유의점」一節自己承認這點：指示越多樣、工作進行越久、引發 priming 的文字越多，效果就越弱。它的建議不是改寫指示，而是去調整 harness，例如在產出主要成果前安排一次對抗性驗證。這等於承認單靠 output-style 撐不住長流程。
兩個版本的差異在於是否保留編碼指示。fluent-korean 保留，用於實際寫程式的場合；fluent-korean-not-coding 移除，用於 Claude 不直接改動程式碼的時候。這個切分是合理的，因為編碼指示與語言指示在提示詞裡會互相爭奪注意力，而當模型不需要動手改檔案時，那部分指示只是雜訊。README 另提到，兩個版本都含有「該用英文寫的就不要用韓文寫」這類條款，以及編碼版對副代理提示詞的適用條款，但明說實際遵守程度因情境而異。
檔案也可以不放進外掛，直接擺到 ~/.claude/output-styles/ 或專案的 .claude/output-styles/。README 說，如果你想要後面那些可選的行為區塊，就該走這條路，因為外掛安裝的檔案在更新時可能被覆寫。
安裝只有兩行，但 README 希望你別自己動手
Claude Code CLI 的安裝指令是這兩行：
/plugin marketplace add snflkd/fluent-korean /plugin install fluent-korean@fluent-korean
裝完之後在 /config 之類的選單裡找 output-style 項目，從兩個版本中選一個。output-style 的特性是選定後要開新 session 或執行 /clear 才會生效，這點 README 特別標了出來。
有趣的是 README 並不鼓勵使用者照著做。它在安裝段落一開始就建議把 repo 連結丟給正在使用的 LLM，讓對方讀完安裝說明後再解釋怎麼裝。那段說明同時是給 LLM 看的安裝指南，列出四個判斷點：先確認執行環境、確認要套用到哪個範圍、整理工作目的與使用者狀況、以及依使用者對開發與編碼的熟悉度調整解釋深度。如果判斷不出程度，README 建議直接問。
這個設計反映了它的實際難點不在指令本身，而在環境判斷。同一個 repo 要覆蓋 Claude 網頁與桌面版的個人指示、專案指示、桌面版 Claude Code 的 CLAUDE.md 或 settings.json、CLI 的 outputStyle 預設值，以及非 Claude 環境的純文字貼用。README 對後者只給原則：從 md 檔挑一份，把正文插到適當位置。
設定時有兩個已知的坑。一是檔名與設定的大小寫，README 說有設定失敗的案例回報與此有關。二是走外掛安裝的路徑時，更新會覆寫檔案，自行加上的內容會消失。
可選區塊補的是情境，不是通用規則
README 提供一組可以貼在指示末尾的區塊，讓使用者按需求挑選。這些區塊的內容比主指示更貼近具體場合，也更能看出作者對提示詞行為的理解。
針對初學者開發者的區塊要求描述方式符合初學者可理解的程度，並節制「박아넣다、치우다、얹다」這類現場感過強的口語表達。這其實是在處理另一個問題：模型為了顯得自然而借用的口語動詞，在技術說明裡會造成語域錯位。
敬語區塊要求以指定稱謂稱呼使用者，並透過先語末語尾、語末語尾、助詞與恭敬詞彙構成敬語，且不得使用半語或非尊稱。README 給的對照例子是「네가 한 말대로 내가 진행할까?」改成「'사용자님'께서 하신 말씀대로 제가 진행하면 될까요?」。這個例子示範的不是加敬語後綴，而是主語、助詞與語尾的整套替換。
詞彙區塊針對的是模型偏好冷僻詞的傾向，要求即使詞義明確，若使用頻率低到不通行就應節制，優先選意義清楚且實際流通的詞。另一個區塊處理輸出範圍，要求所有韓國語產出物都套用同一套指示。文體敏感的工作則相反，要求在有專門指示的產出類型上不套用，判斷不明時先問使用者。
還有兩個區塊值得一提。「항상, 한국어로 사고하고, 한국어로 보고하고, 한국어로 출력합니다」把語言要求推到思考層。最後一個區塊則要求在輸出前先檢查是否違反上述指示再送出。後者是把檢查動作寫進指示，能否生效取決於模型是否真的執行這一步，README 沒有提供任何驗證方式。
它會失效，而且作者先說了
README 在「유의점」開頭就寫「생각보다 원하는 만큼 동작하지 않을 수 있습니다」。這在專案文件裡不常見，也讓評估變得直接：它是一份提示詞，不是一個有執行保證的元件。
失效的條件被列得很明確。指示越多元，模型要在多個目標間分配注意力，語言規範的權重就下降。工作時間越長，早期的系統提示詞在上下文裡被稀釋得越嚴重。引發 priming 的文字越多，模型越容易沿用眼前看到的句式，而眼前若是低品質韓國語，規範就被反向拉扯。這三種情況在長流程的編碼任務裡常常同時出現，所以最容易失效的正是它宣稱最有價值的場景。
成本也寫在明處。因為要還原被省略的句子成分與形態素，訊息的 token 用量會增加，佔用的上下文也變多。系統提示詞本身也讓每個 session 多花一點 token。這個交換是否划算取決於你原本的韓國語輸出有多糟，README 沒有給數字，也沒有給前後對比的量化結果。
還有一個無法從文件確認的變數：副代理。編碼版含有讓副代理在收到韓國語提示時也遵守此 output-style 的條款，但 README 明說遵守程度因情境而異，需要自行觀察並修正。這意味著在多代理架構裡，主代理的輸出品質與副代理的輸出品質可能不一致，而這種不一致不會有任何錯誤訊息提示你。
README 提到的原理文件仍標記為「작성 중」，也就是尚未完成，所以關於模型為何寫不好韓國語、如何矯正的推論，目前無法從這份材料核實。
與 im-not-ai、korean-skills 的分工
README 主動列出三個替代方案：im-not-ai、DaleSeo 的 korean-skills，以及 k-skill 裡的 korean-humanizer。這三個被定位為 skill，處理的是翻譯體校正、AI 表達最小化、拼寫錯誤移除。
差異不在功能清單，在介入時機。fluent-korean 是 output-style，在系統提示詞層事前約束，對整個 session 生效，但無法針對個別產出物做細部處理。skill 是在需要時被叫用的處理單元，可以只作用在特定產出物上，做的是事後校正。README 對這點的說明很清楚：想要翻譯體校正或 AI 表達最小化，就該去找那幾個專案。
兩者的失敗模式也不同。output-style 的問題是約束被稀釋，表現為品質隨對話長度下滑。skill 的問題是覆蓋範圍有限，沒被叫用的產出物不會被處理。作者自己在「유의점」裡描述的做法是把兩者疊起來：平時用 output-style，主要產出物的文體沒守住時改用 skill 補救，並在 harness 裡安排對抗性驗證。
所以這不是二選一。如果你的問題是整場對話的韓國語都在退步，先補 output-style；如果你的問題是特定幾份文件的文體不對，那幾個 skill 更直接。README 沒有比較各方案的校正效果，也沒有提供任何一方的實測數據。
授權、維護與要先確認的事
授權是 MIT。這對採用者意味著可以修改、再散布、用於商業專案，但檔案內若保留著作權與授權聲明，需一併保留。README 說明韓國語部分是人工撰寫，作者主修韓國語文學。這點對評估有實際意義：指示內容來自母語者的判斷，而不是模型生成的規則集合。本文不構成法律意見，實際條款請自行閱讀 LICENSE。
維護成本主要落在兩處。一是版本更新會覆寫外掛安裝的檔案，任何自行加上的區塊都會消失，所以自訂內容應該放在 ~/.claude/output-styles/ 或專案的 .claude/output-styles/ 底下，而不是改外掛目錄裡的檔案。二是設定的大小寫與檔名，README 說有因此設定失敗的回報，環境差異造成的問題不在專案能修的範圍內，只能自己排查。
從版本紀錄看，v1.0.0 在 2026 年 7 月，v1.0.1 與 v1.0.2 在 8 月，屬於小幅迭代。這份材料沒有提供變更日誌內容，無法判斷各版本改了什麼，也無法判斷後續是否會調整指示文字。如果你的 harness 依賴指示的具體措辭，升級前需要自行比對 md 檔的差異。
要驗證的事情不多但都要自己來：先確認你的環境有沒有可切換 output-style 的入口，桌面版 Claude Code 就沒有這個選單，README 建議改用 CLAUDE.md 或 settings.json；再確認你要的是哪一個版本；最後在真實的長流程任務裡觀察副代理與主要產出物的韓國語是否一致。這三項都無法從文件得到答案。
編輯結論
如果你以韓國語對 Claude Code 下指令，或產出物本身包含韓國語，這個外掛值得先試；如果你的工作環境根本不是 Claude Code，或你真正想解決的是翻譯腔與 AI 套語，那它對不上你的問題，README 也直接指向 im-not-ai、korean-skills 這類 skill。採用前先確認三件事：你的環境有沒有可切換 output-style 的設定入口、你要的是 fluent-korean 還是 fluent-korean-not-coding、以及副代理與長流程下條款是否真的被遵守。最後一項只能自己觀察，README 對這點沒有任何保證。
社群筆記