fluent-korean：用 output-style 约束 Claude Code 的韩语输出质量
Claude Code가 명확한 한국어를 구사하게 만드는 output-style 플러그인 | Claude Code output-style for clear, fluent Korean
秒懂
- 它是什么？
- 这是 snflkd 维护的 Claude Code output-style 插件，通过向系统提示词注入写作规范来减少韩语输出中的助词脱落、名词堆叠和比喻替换。它解决的是可读性问题，不是文采问题，代价是每轮对话多花一点 token。
- 适合谁用？
- 如果你的工作流是韩语输入、韩语产出，并且你已经在忍受 Claude Code 那种省略助词、堆名词的压缩式韩语，这个插件值得装，两条 /plugin 命令加一次 output-style 选择就能生效。反过来，如果你要的是翻译腔校正、AI 味消除或者 맞춤법 检查，README 自己就把这些需求指向了 im-not-ai、korean-skills 和 k-skill 的 korean-humanizer，装它解决不了。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 24 天前。
- 用什么语言写的？
- GitHub 没有给出这个仓库的主要语言。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它针对的是被压缩坏掉的韩语，不是不优美的韩语
README 把问题定义得很窄：编码代理为了压低 token 用量、应付上下文上限，被要求把话说短，韩语因此出现助词和词尾脱落、电报式名词串、以及用比喻替换掉本来的词。插件作者把目标写成「수려한 문체보다는 확실한 의미 전달」，也就是宁可平实也要把意思说准。这个定位决定了它不做什么：README 明确把翻译体校正、AI 式表达削减、拼写错误清理划给了别的项目，并点名 im-not-ai、korean-skills 和 k-skill 的 korean-humanizer。
适用人群也写得很直接：用韩语下指令的人，以及产出物里包含韩语的人。README 还提到多代理或 harness 场景，韩语在每一步之间传递，质量衰减会累加，最终影响任务本身的完成度。这是一个比单人对话更值得关注的场景，因为单轮里你能立刻发现句子不通，而链式调用里没人会逐段读中间产物。
output-style 是系统提示词层的事前约束，不是事后校对
按 README 的说法，这个工具本质上是一个 output-style，内容被加进系统提示词，在生成之前就约束韩语用法。这一点和 skill 类工具的差别值得说清楚：output-style 影响的是模型从第一个 token 开始的倾向，skill 更像是在特定时机被调用的检查步骤。README 也承认可以改用 skill 或其他方式使用，只是默认形态是 output-style。
插件包里有两个 output-style：fluent-korean 保留编码指令，用于实际写代码的场景；fluent-korean-not-coding 移除了编码指令，用于 Claude 不直接改代码的场景。这个二分法本身透露了作者对冲突的判断，即编码指令和写作约束放在一起会互相挤压，所以干脆给两个版本让用户按场景选。
README 还提到，编码版本里有一条让子代理在收到韩语提示时也遵守这个 output-style 的条款，两个版本都有一条「该用英语写的地方不要用韩语写」的条款。作者紧接着说这些条款实际被遵守的程度因情况而异，需要自己观察并修改。这是全文里最诚实的一段，也说明插件对子代理行为的控制力是有限的。
安装路径：两条命令加一次选择，然后必须重开会话
在 Claude Code CLI 里，README 给出的安装方式是先运行 /plugin marketplace add snflkd/fluent-korean，再运行 /plugin install fluent-korean@fluent-korean。装完后在 /config 之类的菜单里找到 output-style 项，从两个中选一个。README 特别提醒，output-style 的机制决定了选完之后要新开会话或者执行 /clear，改动才会生效。这一步很容易被忽略，然后误以为插件没起作用。
README 还建议了一种更省事的做法：直接把仓库链接丢给当前使用的 LLM，让它读 README 的安装段落再解释怎么装。它甚至把这段说明当作对 LLM 的行为指引来写，要求 LLM 先弄清用户的工作环境范围（可能有多个 LLM、多个 CLI 或应用）、再弄清任务目的和用户自身情况，最后按用户的技术水平调整解释的详细程度，判断不了就直接问。
不走插件的话，原理同样简单：从 plugins/fluent-korean/output-styles/ 里挑一个 md 文件，把正文插到合适的位置。在 Claude Code CLI 里也可以把 md 文件放进 ~/.claude/output-styles/ 或项目目录下的 .claude/output-styles/，README 说想用后文那些细调块的话就走这条路。要让它成为默认行为，改 settings.json 或 settings.local.json 里的 outputStyle 值。
可拼接的指令块，以及插件安装方式下的覆盖风险
README 列了一组可选的补充指令块，用法是把块内文本粘到指令末尾。块本身是韩语短句，覆盖的场景包括：面向初学者的措辞（避免「박아넣다」「치우다」「얹다」这类现场感过强的口语）、敬语称呼（把「사용자님」换成你想要的称呼）、抑制低频词典词、把约束扩展到所有韩语产出、对文体敏感的任务（小说、剧本、出题、研究）里豁免这套指令、强制用韩语思考和报告，以及在输出前自查一遍是否违反了上述指令。
这里有一个必须注意的操作细节：README 说如果是在 Claude Code CLI 里以插件方式安装的，更新时文件可能被覆盖，你追加的内容会丢。要保留自定义就得改用把 md 文件放进 output-styles 目录的方式。这是插件分发机制带来的实际代价，不是可以忽略的提示。
另外 README 在「유의점」里提到，手工安装时要注意文件名和配置的大小写，已有因此导致配置不生效的报告。这种问题排查起来很费时间，因为症状是「什么都没发生」，而不是报错。
已知限制：遵守率随任务变长而下降，token 用量上升
README 对效果的说法相当克制：可能不如预期，指令越多样、任务拖得越长、容易引发 priming 的文本越多，遵守率下降越明显。作者给出的应对不是继续改指令，而是去优化 harness，让它在产出结果之前做一次对抗性验证。换句话说，作者认为单靠 output-style 这一层挡不住长任务里的漂移。
成本方面，README 承认会多花 token：恢复被省略的句子成分和形态素会让消息 token 增加，上下文占用变大；加上系统提示词里多了这段指令，每个会话都会多消耗一点。这是用可读性换 token 的直接取舍，对上下文本来就紧张的长会话需要自己权衡。
README 末尾还有一句关于「어휘 Priming을 조절할 수 있도록」的话，但文本在这里被截断了，无法确认它想说明什么。原理层面的解释，README 指向一份标注为「작성 중」的 Google Docs 文档，也就是说截至 README 的当前版本，作者自己认为原理说明还没写完。想深入了解机制的人拿不到完整材料。
和韩语写作类 skill 的差别：预防还是修正
README 点名的替代品是 im-not-ai、korean-skills，以及 k-skill 里的 korean-humanizer。按 README 的描述，这些工具处理的是翻译体校正、AI 表达削减和拼写修正，也就是对已经生成的文本做加工。fluent-korean 走的是另一条路，它在生成前把规则放进系统提示词，目标是让坏句子一开始就别出现。
两种思路的失败方式不同。事前约束的弱点是遵守率会随上下文压力衰减，这一点 README 自己承认了；事后校正的弱点是它只作用于被它覆盖到的那部分文本，而且多一道处理步骤。如果你的问题主要是最终文档的润色，事后类工具更对症；如果你的问题是代理在长任务里持续用破碎韩语汇报，事前约束更接近根因。两者并不互斥，README 也没有把它们写成竞争关系。
非 Claude Code 环境：规则文本可以搬，但入口要自己找
README 花了不小的篇幅讲其他环境。核心思路是把 md 文件正文搬到对应位置。在 Claude 网页版和桌面应用里聊天或使用 cowork 时，可以在设置的个人指令里加，聊天对应个人资料或通用标签页，cowork 对应协作标签页，只想对某个项目生效就放进项目指令。
在 Claude 桌面应用里跑 Claude Code 的情况要麻烦一些：README 说那里输入 config 后弹出的菜单里没有切换 output-style 的选项，只能在 CLAUDE.md、settings.json 或 settings.local.json 里挑一个合适的来配置。这是环境差异导致的功能缺口，不是配置写错了。
README 反复建议就安装和用法直接和 LLM 商量，因为各环境的接入方式不一样。这个建议有实际道理，但也意味着插件本身没有提供一份跨环境的完整对照表，用户需要自己把环境信息整理清楚再动手。
许可、维护与判断依据
项目采用 MIT 许可，仓库未归档，默认分支为 main。最近发布记录显示 v1.0.0 在 2026-07-10，v1.0.1 在 2026-08-18，v1.0.2 在 2026-08-21，最后一次推送在 2026-08-23。从版本节奏看，1.0.0 之后一个月内出了两个补丁版本，处于活跃修整期。README 提到手工安装时的大小写问题「已有报告」，说明确实有人在用，但报告的具体数量和平台分布，材料里没有给出，无法判断问题集中在哪个环境。
MIT 许可意味着你可以修改和再分发这段指令文本，包括把它嵌进自己的 harness 或产品里。需要注意的只有一点：README 说插件更新时可能覆盖你追加的指令块，所以如果你做了定制，最好保留一份自己的副本，而不是依赖插件目录里的文件。具体到合规层面，请以仓库里的 LICENSE 文件为准，这里不构成法律意见。
从材料能确认的判断依据有限：README 没有给出遵守率的量化数据，对比图是作者自己跑的结果，且作者自己注明实际 Before 质量可能比图上更低。把这张图当作方向性示意可以，当作可复现的基准不行。
编辑结论
如果你的工作流是韩语输入、韩语产出，并且你已经在忍受 Claude Code 那种省略助词、堆名词的压缩式韩语，这个插件值得装，两条 /plugin 命令加一次 output-style 选择就能生效。反过来，如果你要的是翻译腔校正、AI 味消除或者 맞춤법 检查，README 自己就把这些需求指向了 im-not-ai、korean-skills 和 k-skill 的 korean-humanizer，装它解决不了。装之前先确认三件事：你的环境里 output-style 菜单是否真的存在（Claude Desktop 里跑 Claude Code 时 README 说没有这个入口，得改 CLAUDE.md 或 settings.json），文件名和配置项大小写是否一致（README 提到过因此配置不生效的案例），以及切换后是否新开了会话或执行了 /clear。
社区笔记