【免费下载链接】yomiyasuAI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese项目地址https://gitcode.com/gh_mirrors/yo/yomiyasu点击查看免费下载本文以 yomiyasu 仓库语料库中的一篇改写样本——推敲后的代码评审建议——为绝对主体逐段对照 AI 原始输出结合 SKILL.md 的转换原则、slop-catalog 的语汇目录以及yomiyasu_lint.py/yomiyasu_diff.py的实际运行输出完整还原 yomiyasu 推敲一篇「服务层职责拆分」代码评审文本的决策过程。读完本文你将掌握AI 生成的评审建议中典型的「混在」「につながる」「読み取りにくい」等表达是如何被系统化改写的、改写背后 7 条转换原则如何逐条落地以及如何用静态检查与差分工具验证推敲质量。yomiyasuよみやす是一个面向 AI 生成日语的推敲 Agent Skill核心目标是在「不改变主张、比重、言い切りの強さ、文の働き」的前提下修正不自然比喻、模糊主述关系、多余装饰与复制文案式的表达。语料库tests/corpus/用同一批 AI 输出构造了 4 组对照raw_ai原始输出、blacklist_ai仅做禁止语替换的对照、yomiyasu_rewrittenyomiyasu 推敲后、human人工样本覆盖 8 个业务场景 × casual/default/formal 三种语体共 160 个文件见 benchmark_results.json 的total_files: 160。一、样本定位代码评审场景、default 语体07_code_review_sonnet_default.md属于 8 个场景中的「代码评审建议」07_code_review语体为 default默认、居中语体casual 更口语、formal 更书面三版原始输出由 Claude Sonnet 按不同语体提示生成。其内容是一段对「服务层」的改进建议指出 DB 访问、外部 API 调用、业务逻辑混在同一个方法中的问题并提议按 Repository / Gateway / Client 拆分职责。在 4 组语料中这一篇对应三个文件可直接对照阅读AI 原始输出4 段仅黑名单替换的对照版_bl无后缀版对应raw_ai的替代方案yomiyasu 推敲版5 段即本文主体值得注意的是benchmark_results.json 中三个版本的静态检测得分差异明显raw_ai版 100 分 / 0 指摘blacklist_ai版 85 分 / 3 处指摘yomiyasu_rewritten版 100 分 / 0 指摘。这个反差恰好印证了 yomiyasu 的设计前提静态规则能捕捉的 AI 特征只是一部分单纯替换禁止语甚至可能引入新的问题推敲的真正价值在语义层主述对应、文末立场、信息不增补这部分要依靠 diff 工具与人工判断来把关。二、推敲前后完整对照原文与改写版逐段引用2.1 AI 原始输出raw_ai 版 全文このサービス層では、DBアクセス、外部API呼び出し、ビジネスロジックが1つのメソッドに混在しています。責務を分けることを提案します。今の構造には3つの問題があります。第一に、DBや外部APIをモックしないと単体テストを書けません。第二に、外部APIの仕様変更やDBスキーマの変更が、そのままサービス層の修正につながります。第三に、トランザクション境界とリトライ処理の置き場所が曖昧で、障害時の挙動を追いにくくなっています。具体的には、永続化をRepositoryに、外部API呼び出しをGatewayまたはClientに切り出してください。サービスはそれらをインターフェース経由で受け取り、注文の検証や金額計算といった業務ルールだけを持たせます。依存はコンストラクタで注入すれば、テストでスタブに差し替えられます。一度に全部を直すのが重い場合は、まず外部API呼び出しの切り出しから始めてください。変更の影響が小さく、テストの書きやすさもすぐに改善します。2.2 yomiyasu 推敲版关联文档 全文このサービス層では、DBアクセス、外部API呼び出し、ビジネスロジックを1つのメソッドにまとめて書いています。これらの責務を分けることを提案します。今の構造には3つの問題があります。第一に、DBや外部APIをモックしないと単体テストを書けません。第二に、外部APIの仕様やDBスキーマが変わるたびに、サービス層も修正しなければなりません。第三に、トランザクション境界とリトライ処理をどこで行うのかがコードから読み取れず、障害が起きたときに挙動を追えません。具体的には、永続化をRepositoryに、外部API呼び出しをGatewayまたはClientに切り出してください。サービスはそれらをインターフェース経由で受け取り、注文の検証や金額計算といった業務ルールだけを扱います。依存オブジェクトをコンストラクタで注入すれば、テストでスタブに差し替えられます。一度に全部を直すのが難しい場合は、まず外部API呼び出しの切り出しから始めてください。変更の影響範囲が小さく、すぐにテストを書きやすくなります。粗读对比可以发现段落骨架3 个问题 → 具体方案 → 渐进式起步建议完全保留主张与比重未变但几乎每个句子的「表现层」都被重写。下面用 SKILL.md 的 7 条转换原则逐条还原这些改动的依据。三、7 条转换原则在本文本上的逐条落地SKILL.md 开头即声明最高优先级规则意味の保持主张・比重・言い切りの強さ・文の働きを変えない与情報の不増補不擅自添加信息。以下每条原则都服务于这两个前提。3.1 主述・修飾・条件の点检原则 1原文第一段「ビジネスロジックが1つのメソッドに混在しています」——「混在」一词只描述状态没有说清「谁把什么放进了哪里」。推敲版改为「ビジネスロジックを1つのメソッドにまとめて書いています」把「書いています」这一具体动作补入动作主体书写代码的人与对象DB 访问、外部 API 调用、业务逻辑之间的对应关系立刻清晰。这与 SKILL.md「主語と目的語の明確化」一节「誰が・何を・どうした」を明確にする一致补充对象的前提是「原文或提供文脉能确定」这里「混在しているもの」在原文已列举属于可确定的补全。第二段第三点「トランザクション境界とリトライ処理の置き場所が曖昧で」被改为「どこで行うのかがコードから読み取れず」把抽象名词「置き場所」展开为可追问的动作「どこで行うのか」把评价语「曖昧」替换为可验证的观察「コードから読み取れず」。这正是「曖昧な語を、より狭い具体的な事実に勝手に置き換える」的禁区之外——「読み取れず」保持了「曖昧」的负面评价与「无法确定」的幅度并未编造新事实。3.2 文の働き与文体の保持原则 2原文「責務を分けることを提案します」在推敲版中变成「これらの責務を分けることを提案します」——新增指示语「これらの」把提案的指代对象显式化属于「指示代名词→名词或明确的指示语」的合理还原而不是添加新信息。yomiyasu_diff.py的实际输出显示本样本出现了 3 处「文末の種類が変わった文」其中两处尤其值得关注説明〜ます→ 義務「…そのままサービス層の修正につながります」→「…サービス層も修正しなければなりません」説明〜ています→ 動作〜します)「…挙動を追いにくくなっています」→「…挙動を追えません」这两处改写把「客观因果说明」「困难状态描述」换成了「义务表现」「可能性否定」语气强度有所变化。SKILL.md 明确要求「言い切りの強さ断定・推量・可能性を保つ」因此 diff 工具把它们列为「意味が変わりやすいところ」的候选等待人工确认。这里可以看到工具的角色定位diff 输出是检查候选不是自动判定——它负责把容易被忽略的强度变化摆到桌面上。3.3 擬人化の整理原则 3本样本中「サービス層も修正しなければなりません」「サービスはそれらをインターフェース経由で受け取り」等句主语都是「サービス層」「サービス」这样的非生物主语。但 SKILL.md 的拟人化原则只针对「道具や概念に感情や意志を持たせた表現」如「コードが語る」而「システムの客観的な動作を述べる非生物主語」应当保留——本样本的服务层主语属于后者因此改写版没有强行把主语换成「開発者」。这与 gemini-syntax.md 原则 3「道具や仕組みの働きを客観的に述べている文はそのまま残す」完全一致。3.4 比喩を平易な言葉へ原则 4本样本没有「壊れる」「倒す」「効く」这类典型比喩動詞但存在两处值得按此原则处理的表达「外部APIの仕様変更やDBスキーマの変更が、そのままサービス層の修正につながります」→「外部APIの仕様やDBスキーマが変わるたびに、サービス層も修正しなければなりません」把名词化的「仕様変更」还原为动作「仕様やDBスキーマが変わる」把「〜につながる」这一模糊因果换成「〜たびに」的条件对应。yomiyasu_diff.py也因此记录了「条件 2→3」的增减元: れば、場合後: れば、れば、場合。「一度に全部を直すのが重い場合」→「…難しい場合」重い对「改动工作量」的比喻在 slop-catalog.md 中虽未直接列出但按「比喻要保留原含义宽度」的要求「難しい」保留了「负担大、不轻松」的幅度未改为「不可能」之类的更强表达。3.5 前置き・否定対比の役割の確認原则 5原文「今の構造には3つの問題があります」在推敲版中完整保留。乍看这是一句「予告だけの文」——SKILL.md「段落と文の論理構造」一节建议把「中身を伴わない予告文」与后续内容合并。但这里的前置是「3 个问题」的数量预告后面三句逐一对应「第一に・第二に・第三に」取消预告反而会破坏列举结构SKILL.md 同时规定「1文にまとめると意味が変わる場合は無理にまとめず残します」。yomiyasu_diff.py的输出仍将这句列入「予告だけの文」候选但结合原文结构判断保留是正确选择——这正是「工具给候选、人做判断」的典型场景。3.6 情報を勝手に足さない原则 6yomiyasu_diff.py对本样本列出了「元の文にない語: オブジェクト、コード、影響範囲」。逐一核对「依存オブジェクトをコンストラクタで注入」原文已有「依存はコンストラクタで注入すれば、テストでスタブに差し替えられます」「オブジェクト」只是把「依存」明确为依赖对象的补全且有原文依据。「コードから読み取れず」原文「置き場所が曖昧」的语境是代码组织补入「コード」可确定。「変更の影響範囲が小さく」原文「変更の影響が小さく」「範囲」是「影響」的细化属可确定范围。这三处都符合「原文・依頼・提供資料に対象と関係が明示されているときだけ補う」的限定条件SKILL.md「情報の不増補」一节因此工具只作提示、不构成违规。反过来看如果改写擅自补入「サーバー再起動」「リトライ回数の上限」这类原文没有的信息就违反了本原则——README 的比较例中曾明确批评「過去の適用後には直前のAI生成文だけでは確定できない条件や手順の追加」正是这类反面教材。3.7 文長・読点・装飾の調整原则 7本样本无太字、无箇条書き、无絵文字、无文末コロン——yomiyasu_lint.py实测输出为「太字頻度 0.0 個推奨 2.0 以下・箇条書き比率 0.0%推奨 15% 以下」。SKILL.md 的文长目安是平均 30〜45 字、1 文読点 0〜2 个改写后的句子均落在该区间内且「どこで行うのかがコードから読み取れず」通过插入短句分割长句保持了「条件→结果」的追读顺序。注意这些数字是 yomiyasu 自己的编辑目安不是学术论文的实验数值gemini-syntax.md 开头即声明这一点使用时不应机械套用。四、语体变体与黑名单对照为什么「只禁词」不够同一篇代码评审文本在语料库中还有 casual 与 formal 两个推敲变体可与 default 版对照casual 版使用「入っています」「はどうでしょうか」「と思います」等口语表达最后以协商口吻「まずは外部API呼び出しをクライアントクラスに移すところから始めてはどうでしょうか」收尾。formal 版使用「本サービス層では」「改めてください」「依存性注入を採用すれば」等书面表达三段落结构更工整。yomiyasu 的原则是「常体・敬体は変更指定がない限り原文を保つ」SKILL.md因此三版差异主要继承自原始输出的语体推敲本身不强行统一语尾也不为了「语尾多样」而改变句子的働き——SKILL.md 明确「語尾を散らすこと自体を目的にしません」。再看 blacklist_ai 对照版它同样做了职责拆分建议DB→Repository、外部 API→Client、服务层只留业务规则但表达上保留了大量原文句式。benchmark 中该版静态检测得 85 分、3 处指摘而同场景raw_ai与yomiyasu_rewritten均为 100 分/0 指摘。这说明黑名单式替换禁词→替代词在某些维度可能引入新的「AIっぽさ」痕迹而 yomiyasu 的推敲是在结构层主述、条件、文末整体处理二者思路不同。README 背景部分所述「禁止語の置き換えにとどまる対処」的局限在这里有了语料级的印证。另一个容易被忽略的事实raw_ai原文在 lint 下也是 100 分/0 指摘——静态 lint 无法区分「原文本来就干净」和「推敲后变得干净」。这与 yomiyasu 的立场一致AIらしさの検出文体统计与読みにくさの判定是两回事README 引用了 Zaitsu et al. 的研究作为区分两者的逻辑依据。因此评价推敲质量不能只看 lint 分数必须配合yomiyasu_diff.py检查语义增减再交由人工通读。五、用工具验证推敲质量lint 与 diff 的实际输出本文撰写过程中直接在仓库内对关联文档执行了同梱工具以下是真实输出。5.1yomiyasu_lint.py静态检查python3 scripts/yomiyasu_lint.py tests/corpus/yomiyasu_rewritten/07_code_review_sonnet_default.md输出 AIっぽさ 検査レポート (スコア: 100/100) ・文字数: 451 | 行数: 4 ・太字頻度: 1,000字あたり 0.0 個 (推奨: 2.0以下 / 警告: 3.0超) ・箇条書き比率: 0.0% (推奨: 15%以下 / 警告: 25%超) ------------------------------------------------------------ [PASS] 設定された検査ルールによる指摘はありません。该脚本检查不自然比喻动词、过度太字/箇条書き、絵文字、文末コロン、同一文末连续、以及bold_not_rendered因 Markdown 分隔符规则可能不显示为太字的写法详见 yomiyasu_lint.py 与共享模块 markdown_visibility.py。如前所述[PASS]只表示「按设定的规则没有指摘」不保证自然さ・意味保持README 与 SKILL.md 均明确声明这一点。5.2yomiyasu_diff.py推敲前后差分python3 scripts/yomiyasu_diff.py tests/corpus/raw_ai/07_code_review_sonnet_default.md tests/corpus/yomiyasu_rewritten/07_code_review_sonnet_default.md --stance説明输出摘要节选■ 言い回しの種類の増減意味が変わりやすいところ - 義務: 0 → 1元: なし後: なければなりません - 条件: 2 → 3元: れば、場合後: れば、れば、場合 ■ 元の文にない語: オブジェクト、コード、影響範囲 ■ 消えた語: 仕様変更、場所、改善、曖昧、混在、障害時 ■ つながりを確かめる場所書き直した文。何と何をつないでいるか言えるか - 文頭の指示語: このサービス層では、…略 - 文頭の指示語: これらの責務を分けることを提案します。 - 予告だけの文: 今の構造には3つの問題があります。 ■ 文末の種類が変わった文立場に合う向きか見る - 説明〜ます → 義務: …修正しなければなりません略 - 説明〜ています → 動作〜します): …挙動を追えません略 - 動作〜します → 説明〜ます): …すぐにテストを書きやすくなります略 ■ 文末の立場説明の文書として見た - 事実・結果・考えの文書に、読み手への勧めや頼みがある最後の1文を除く。立場が合っているか見る ・具体的には、永続化をRepositoryに、…略 ・一度に全部を直すのが難しい場合は、まず外部API呼び出しの切り出しから始めてください。--stance参数取值勧め|決まり|説明对应 SKILL.md 的三种文書立场本样本整体是「说明现状问题 建议改进方向」的混合文書因此以「説明」为基准检查时diff 会提示「有勧め/頼み的句子」——而按 SKILL.md「助言を含む文書でも、事実や道具の動作を説明する文は説明のまま残します」这种混合本来就是代码评审这类文書的合理形态只需人工确认立场没有错位即可。5.3 工具的角色边界两项工具的输出共同构成「检查候选」而非「终审结论」。README 明确说明检测结果是「見直し候補」「指摘がゼロになるまで機械的に直すのではなく、元の文や文脈と照らし合わせて判断してください」。对本文样本而言diff 提示的 3 处文末变化与新增语词经逐条核对均属于「有原文依据的明确化」或「需人工取舍的语气微调」这正是推敲工作应有的流程先让工具把风险点列出来再逐点判断是否保留。六、把 yomiyasu 用在你的代码评审文本上6.1 最小用法在 AI 聊天或编码 Agent 中粘贴草稿并指示この文章を読みやすくして。 这里粘贴待推敲的文本6.2 按文档类型指定领域代码评审建议更接近「业务・提案」性质时可指定 domainこの文章を業務仕様向けに読みやすくして。 这里粘贴待推敲的文本domain 可选tech技术文章、business规格书・PR 文・提案书、essay个人随笔省略时从输入内容自动判定README「ドメインの指定」一节。各领域的详细指针对应 references/domains/ 下的 tech.md、business.md、essay.md。注意领域名只决定文风侧重不决定文書立场——立场勧め/決まり/説明要根据「写给谁、为什么写」另行判断SKILL.md「文書の立場と文末」。6.3 推敲后自查流程运行python3 scripts/yomiyasu_lint.py 対象ファイル确认无太字渲染风险与明显 AI 特征运行python3 scripts/yomiyasu_diff.py 元の文.md 書き直した文.md --stance説明核对言い回し増減、新增/消失的语词、文末立场人工通读 diff 候选参照原文与提供文脉逐一判断对无法确定的关系遵循「情報が足りない場合の暫定文」处理不擅自补写条件或数值。若输出出现混乱可检查是否与其他日语校正 Skill 冲突README 建议类似 Skill 临时停用。七、小结通过07_code_review_sonnet_default.md这一样本可以看到yomiyasu 对 AI 生成的代码评审文本的推敲是一条完整流水线结构层保持「问题→方案→渐进起步」的骨架与比重不变表达层把「混在」「つながる」「置き場所が曖昧」「重い」等模糊比喻与名词化表达还原为可追读的动作和条件指代层用「これらの」等显式指示语消除指代歧义文末层以「説明」基准通读全文、区分说明与勧め的句子最后用 lint diff 工具把风险点显式化交由人工终审。值得记住的三个边界静态 lint 的 100 分不等于「原文天然合格」diff 提示的新增语词不等于「违规增补」工具的全部输出都只是「見直し候補」。这正是 yomiyasu 与简单禁词替换方案的本质区别——它把「AI 文本为什么不自然」转化为可逐条核对的检查项让推敲从「感觉」变成「可验证的流程」。同一批语料raw_ai/blacklist_ai/yomiyasu_rewritten/human与 benchmark_results.json、test_benchmark_categories.py 提供了继续深入研究这一流程的完整素材。赞分享【免费下载链接】yomiyasuAI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese项目地址https://gitcode.com/gh_mirrors/yo/yomiyasu点击查看免费下载相关推荐yomiyasu 实战把 AI 生成的日语代码评审推敲成自然日语——以服务层职责拆分建议为例yomiyasu 实战把 AI 生成的日语代码评审推敲成自然日语——以服务层职责拆分建议为例 本篇技术指南以仓库评测语料中的一篇真实样例为核心AI 生成的日yomiyasu 推敲实践把 AI 生成的日语代码评审评论改写成自然表达——以「服务层拆分重构」建议为例yomiyasu 推敲实践把 AI 生成的日语代码评审评论改写成自然表达——以「服务层拆分重构」建议为例 导读 本篇文章以开源仓库 yomiyasu 语料库中yomiyasu 实战拆解AI 生成的障害报告如何被改写为自然日语casual 文体示例yomiyasu 实战拆解AI 生成的障害报告如何被改写为自然日语casual 文体示例 本篇技术指南以 yomiyasu 仓库中保存的推敲样本 test上一篇如何快速集成腾讯云COSJavalin对象存储完整指南下一篇React Native SQLite Storage源码解析深入理解插件架构与实现原理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考