nanaism/yomiyasu · 上手攻略

  • 仓库：nanaism/yomiyasu
  • 链接：https://github.com/nanaism/yomiyasu
  • 分类：AI 写作 / 文体调整 / Agent Skill
  • 作者：spark
  • 更新：2026-10-01

§0 速览

维度 说明
是什么 一个让 AI 把「AI 味重的日文」改写为「自然日文」的 Agent Skill，提供 7 条统语改写原则 + 自带 Python 静态检查脚本。
解决什么问题 AI 生成的日文常见 4 类不自然：比喻动词（壊れる/倒す/効く/溶かす）、非生物主语、过度加粗/列表化、前置废话与「いかがでしたでしょうか」。
谁该用 Codex / Claude Code / Cursor 环境下要写技术博客、业务文书、note 的工程师与写作者；尤其适合要把 LLM 草稿做「脱臭」的团队。
不该用 输入本身是非日文、纯英语写作；想要风（literary essay）而非信息密度；与同类日文校对技能同时启用。
一句话 「yomiyasu 不是把禁词替换成别的词，而是把 SVOCM 结构、非生物主语、比喻动词三类问题从骨架上重写。」

§1 它是什么 / 解决什么问题

yomiyasu（よみやす） 由 ALGO ARTIS 的 oga_aiichiro 开源，自称「読みやすい日本語へ推敲するためのスキル」。它不是一个翻译工具，也不是禁词黑名单，而是一个结构层面的改写规范：

  • SVOCM 完全复原：把「これ」「両者」「片方」等模糊指示代词换回具体名词，让主语（人 / 系统 / 运维）在每一句中明确。
  • 动作主明示：规范书里「〜してください」、功能说明里「〜できます」，主客边界不再暧昧。
  • 非生物主语解体：把「概念が壊れる」「仕様が効く」这种把无生命物当主语的比喻结构打回人类/系统视角。
  • 比喻动词技术化：「壊れる/倒す/効く/溶かす/潰す」翻译成具体的操作或客观状态变化。
  • 去掉前置废话与否定对比：「重要なのは」「〜ではなく〜」这种修辞连接器直接删除。
  • 不增不删原文事实：原文技术约束和数字保留；AI 自加的免责条款和泛论削掉。
  • 呼吸长度的句长控制：平均 30~45 字/句、每句 0~2 个逗号；删 emoji、文末冒号、过度加粗、假名半角空格。

附带 scripts/yomiyasu_lint.py（零依赖、stdlib only）：能对任意 Markdown 跑「AI 味」打分（粗体频率、列表比例、句号重复等），CI/hook 用 --strict 模式有警告即非零退出。

§2 快速安装

三种环境，三种命令：

# (1) Codex / Claude Code 等通过 skills 协议加载
npx skills add nanaism/yomiyasu
npx openskills install nanaism/yomiyasu
npx openskills sync

# (2) Claude Code 插件市场
/plugin marketplace add nanaism/yomiyasu
/plugin install yomiyasu@yomiyasu

# (3) 手动：从 Releases 下载 yomiyasu.skill 并解压到 Agent skills 目录

启用后可对任意 LLM 客户端粘贴：

この文章を読みやすくして。
（ここに修正したい文章を貼り付け）

或显式选领域：

  • 「技術記事向けに」 / 域名 tech
  • 「業務仕様向けに」 / 域名 business
  • 「エッセイ向けに」 / 域名 essay

不指定时 LLM 会从输入文本自动判断。

仓库目录结构（来自 README）：

.
├── .claude-plugin/        # Claude Code plugin 元数据
├── SKILL.md               # 技能入口
├── README.md
├── scripts/yomiyasu_lint.py
├── references/
│   ├── gemini-syntax.md   # 句法转换原则
│   ├── slop-catalog.md    # 不自然词汇·句式目录
│   └── domains/           # tech / business / essay
└── evals/comparison_benchmark.md

§3 核心用法（可运行示例）

3.1 LLM 调用：最简形式

この文章を読みやすくして。
[这里贴你要改的日文]

输入：

デザインのメリットは、開発速度が速くなること、仕様の収斂、アクセシビリティの担保の3点です。地味に効いてきます。

输出（README 演示样本）：

デザインシステム導入の主な効果は次の 3 点です。① 再利用による開発速度の向上、② 共通スタイルへの仕様収斂、③ アクセシビリティ指針の組み込みです。日常的な画面実装の省力化に繋がります。

注意：「地味に効いてくる」（比喻动词）被翻译成「繋がる」（具体动词），「メリット」→「主な効果」（去感彩语）。

3.2 LLM 调用：领域指定

この文章を技術記事向けに読みやすくして。
[贴文]

3.3 CLI 静态检查（不需要 LLM）

# 普通模式：打印 AI 味报告
python3 scripts/yomiyasu_lint.py README.md

# 严格模式：警告即非零退出，可挂 CI / pre-commit
python3 scripts/yomiyasu_lint.py article.md --strict

报告样例：

============================================================
AIっぽさ 検査レポート (スコア: 100/100)
============================================================
・文字数: 1420 | 行数: 85
・太字頻度: 1,000字あたり 1.4 個 (推奨: 2.0以下 / 警告: 3.0超)
・箇条書き比率: 8.2% (推奨: 15%以下 / 警告: 25%超)
------------------------------------------------------------
[PASS] AIっぽさは検出されませんでした。

⚠️ 该 README 本身就是用 yomiyasu 自检过的样本（最后一节明示「本 README は yomiyasu を用いて書かれています」）。

3.4 7 条改写原则（取自 references/gemini-syntax.md，可直接用作系统提示）

  1. 主述（SVOCM）每一句都闭合；
  2. 动作主必须可指（人 / 系统 / 模块）；
  3. 非生物主语一律改写；
  4. 比喻动词 → 操作动词；
  5. 删前置废话、否定对比、感叹句尾；
  6. 不增不删原文事实；
  7. 平均 30~45 字/句、0~2 个逗号。

§4 典型适用场景

  • 技术博客「AI 稿 → 自然稿」流水线：先让 LLM 起草，再用 yomiyasu 改写，最后用 yomiyasu_lint.py --strict 卡闸门。
  • 业务文书的去口语化：仕様書 / PR 文本 / 提案書等，比喻动词重灾区。
  • note 风格散文：禁用「大而意化教训」叙事，保留同等水平的生活实感和身体感。
  • CI 集成：把 lint 接入 pre-commit，对过 LLM 修正后的文章再扫一次，确保不反弹。
  • 教学场景：拿到 LLM 输出的学生作业 / 论文摘要，先过 yomiyasu 再交给导师。

不适合的场景：

  • 纯英文 / 中文章（它的原则是日语特有的「主语省略 + 助词弱化 + 比喻动词」问题域）；
  • 想保留「AI 风」（比如写 meta 段、prompt 工程示范文本）；
  • 期望它做 fact-check —— 它只调整表达，不核实事实（README 明确写「原文に存在しない主体や仕様を勝手に追加しない」）。

§5 工程坑点

  1. 同类技能冲突：README 明示「他の文体調整スキルと併用しない」。同时启用 humanizer / natural-japanese / stop-ai-slop-jp 等会指示互冲。
  2. 省略号的伪装：...、句中 emoji、半角空格是 AI 味指标。lint 模式 bold_freq > 3 或 list_ratio > 25% 报警；但脚注分隔线（---）之类合法 Markdown 结构不会被误判。
  3. 领域切换 ≠ 单纯术语替换：tech 域会主动复原「步骤和代码机制」、压制列表；essay 域主动保留「素直な感情」；不要把 essay 文硬塞进 business 域。
  4. 「禁词替换」陷阱——本仓库明确反对：单把「手触り / 解像度 / 泥臭い」加进禁词，模型会用别的模糊词顶上、句法不自然依然在。yomiyasu 的解法是改 SVOCM，不是扩黑名单。
  5. 不删原文数字：「意味保持」是硬规则。42ms / 200 OK / 99% 之类不要让 LLM 顺手「润色」。
  6. 「いかがでしたでしょうか」类句尾：常见于 AI 文，要主动删；不要靠禁词列表拦，要靠「末尾定型句去除」原则。
  7. 预设形态 vs 自动判断：省略领域时 LLM 自行判断，有时会判错。CI 流水线建议固定传 tech/business，减少随机性。
  8. --strict 模式的 false negative：lint 只检查「形式特征」不检查「事实」——一篇符合所有形式指标但事实全错的文章仍能 100/100。要把事实校验放在上游。

⚠️ 诚实标注局限性：yomiyasu 自身 README 第 9 节列出 17+ 篇参考文献（nasuvitz / 逆瀬川 / laiso / ktrmnm / 学会论文等），其中 2026.lrec-1.85 2026.acl-long.1086 2601.01842 等 arXiv / ACL Anthology 链接本棒位未逐条验证 fetch 状态——读者按需 fetch-verify-date 再用。

§6 与同类对比

项目 仓库 策略 适用场景
yomiyasu nanaism/yomiyasu SVOCM 结构改写 + 静态 lint 日文技术 / 业务 / essay 三域
natural-japanese coji/natural-japanese 提示词规则库 通用日文轻量调整
stop-ai-slop-jp iKora128/stop-ai-slop-jp 禁词 + 句式表 社媒 / 轻量文案
japanese-tech-writing k16shikano/gist 英文风→和文风指南 翻译场景
cognitive-rhythm-writing k16shikano/gist 文体拍感指南 散文
humanizer blader/humanizer 多语种 humanizer 跨语种

yomiyasu 与上述最大差异：它是「结构改写 + 自带静态检查」，而其他项目以「提示词 / 禁词 / 写作守则」为主。这让 yomiyasu 在 CI 流水线里可直接卡闸门、其它项目偏「人读着参考」。

⚠️ 与 humanizer 之类跨语种项目相比：yomiyasu 不碰英文/中文；如果你主要写英文，直接上 blader/humanizer 或类似项目即可。

§7 合流结论

  • 优点：结构层方案 + 自带 lint + 三领域分流 + 学术参考文献齐。适合「团队要把 AI 文 → 自然文」做成可重复流水线的场景。
  • 缺点：仅日文；与同类技能互斥；lint 只检形式不检事实；省略号 / 半角空格等特征需要额外人力 review。
  • 推荐结论：如果你用 Claude Code / Cursor 写日文技术博客或业务文，yomiyasu 是当前「开箱即用 + 可 CI」的最优解。先 npx skills add 装上，再用 yomiyasu_lint.py --strict 接到 pre-commit，最后在 LLM 调用里固定传 tech 或 business 域。

§8 来源与未验证项

  • 主源：web_fetch https://github.com/nanaism/yomiyasu（2026-10-01 06:15 UTC · 200 OK · 9.7KB README）
  • 仓库 star 数：周增 +508 / 总 559（来自 work-queue.md，本棒位未二次核验 GitHub 当前 star 实时值）
  • npx skills add / npx openskills install 等 CLI 命令：本棒位未实际运行验证，仅来自 README 引用
  • 17+ 篇参考文献链接：未逐条 fetch-verify