mcpField
H
humanizer-zh

humanizer-zh

github.com/ai-zixunクリエイティブ・メディア2011.3k 回インストール23 週間前に更新
リポジトリ

humanizer-zh について

中国語の文章を自然な母語表現に整えつつ、事実、立場、情報量を保つライティングスキルです。文章の種類に応じて編集の度合いを調整し、指定された作家の文体を任意で取り入れられます。

主な機能

  1. 01翻訳調の表現を検出
  2. 02構成と段落の流れを調整
  3. 03文章の種類に応じた編集度
  4. 04事実と執筆者の意図を保持
  5. 05作家の文体を任意で適用

活用シーン

  1. 01中国語の記事や評論の推敲
  2. 02技術文書や告知文の修正
  3. 03長文の構成を再編
  4. 04指定された中国人作家の文体を適用

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ai-zixun/humanizer-zh --skill humanizer-zh

インストール後、Claude Code で/humanizer-zhを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

.gitignore
README.md
README.en.md
CLAUDE.md
VERSION
CHANGELOG.md
LICENSE
.claude-plugin/
plugin.json
.github/workflows/
release.yml
agents/
openai.yaml
references/
corpus.md
patterns.md
corpus-quickpick.md
references/voices/
fengtang.md
hefan.md
liuzichao.md
helaoshi.md
index.md
lishanglong.md
lixiaolai.md
luozhenyu.md
wujun.md

詳細

中国語のAIっぽさをなくす

概要

中国語の文章を「モデルがつなぎ合わせたような原稿」から、「中国語を母語とする人が実際に書いたような文章」に整えます。 翻訳調、構成の硬さ、レイアウトの硬さ、判断の強さを優先して見直しつつ、原文の事実、立場、情報量は保ちます。

ワークフロー

  1. まず文章の種類を判断します。 ブログ、コラム、書籍原稿、論評、製品分析では、リズムや書き手の判断をより前面に出せます。告知、説明文、技術文書では、正確さと抑制を優先します。
  2. まず記事の主軸を確認します。 第一段落で何を主題として掲げているか、本文の各段落がどのような役割を担っているか、最後の段落が同じ話題をまとめているかを判断します。
  3. 目立つAI特有の痕跡を探します。 英語の構文を直訳した表現、機械的な対比、漠然とした結論、箇条書きの羅列、コロンやダッシュの連発、整いすぎた段落のリズムに注目します。
  4. 次に、どの程度書き換えるかを決めます。 軽い推敲では言葉遣いと句読点を整えるだけにします。大幅に書き換える場合は、文の順序を組み替え、弱い文をまとめ、主語や因果関係を補います。
  5. 書き手の意図を保ちます。 事実を勝手に付け加えず、慎重な判断を断定に変えず、一般的な結論を無理に時代の宣言へと引き上げません。
  6. 最後に声に出して確認します。 英語の発想を中国語の語彙に置き換えたようではなく、中国語として自然に読める文章にします。

文体の採用(任意)

デフォルトでは、humanizer-zh は特定の書き手の文体を当てはめず、中立的にAIっぽさをなくす推敲を行い、## Core Rules に従います。

次の条件をすべて満たす場合に限り、機会を見て(1回の会話につき最大1回)、ユーザーに「特定の中国語作家の文体も取り入れますか?」と尋ねます。

  • この会話で、まだ文体の採用について尋ねていない。
  • 今回の依頼が大幅な書き換え、長文の推敲、書き直し、または文体を意識した創作である(告知、説明書、短文の修正ではない)。
  • ユーザーが依頼の中で「中立的な文体を保つ」「文体を変えない」などの制限を明示していない。

尋ねる際は、まず references/voices/index.md を読み、8人の作家を一言で紹介したうえで、リストをユーザーに提示します。李笑来、鹤老师、罗振宇、吴军、李尚龙、何帆、冯唐、刘子超。

ユーザーが断った場合、または返答しなかった場合、この会話の残りのやり取りでは再度尋ねず、すべて中立的な方針で進めます。 ユーザーが特定の作家を自分から指定した場合(例:「李笑来的口气重写」)、質問の手順を飛ばし、読み込みの手順に進みます。

読み込みの手順に入ったら、次のように進めます。

  1. references/voices/<author>.md の該当ファイルを読みます。
  2. 書き換え時には、そのファイルにある人物像、構文の型、リズムのルール、避けるべきパターンを ## Core Rules に加味します。
  3. voice プロファイルと Core Rules が衝突する場合(代表例:李笑来と刘子超は長いダッシュ —— を許容し、Core Rules §6 より優先します。鹤老师は短文を独立した段落に多用することを推奨し、吴军は 首先……其次……最后 を許容します)、作家プロファイルを優先します。
  4. ユーザーが後から「Xに変えて」と言った場合、現在の voice プロファイルを破棄して新しいものを読み込みます。「作家の文体はやめて」と言った場合は、中立的な方針に戻します。

避けるべきパターン:

  • ユーザーが選んでいないのに、特定の作家の文体を勝手に模倣しないでください。
  • 複数の作家の文体を一つの記事に混ぜないでください。
  • voice プロファイルにある persona preamble(「You are a guy from 东北…」のような英語の執筆指示)をそのままユーザーに出力しないでください。これはあなた向けの指示であり、記事の内容ではありません。
  • 作家プロファイルの避けるべきパターンを、humanizer-zh のデフォルトルールとして扱わないでください。その文体を適用するやり取りでのみ使用します。

基本ルール

1. まず翻訳調を直す
  • 英語の構文を中国語にそのまま当てはめた文は、分けて書き直します。
  • 「对于……来说」「基于……」「围绕……展开」「使得……得以……」のような翻訳調の強い表現は控えます。
  • 対比が必要な場合も、不是……而是…… を機械的に使わず、自然な転換や段階的な展開、重点の移動で表現します。
2. 漠然とした大げさな言葉や決まり文句をなくす
  • 「颠覆」「革命」「赋能」「重塑」「深刻改变」「开启新篇章」のように、仕組みの説明を伴わない言葉は控えます。
  • 「这标志着……」「这意味着……的时代已经到来」のような、定型的に締めくくる文は避けます。
  • 抽象的な判断は、具体的な行動、制約、コスト、役割分担、結果に結び付けます。
3. 機械的な構成をほぐす
  • すべての段落を三つの文、対句、整った対比に無理にそろえないでください。
  • 「首先」「其次」「最后」「与此同时」「值得注意的是」「从某种意义上说」を続けて使わないでください。
  • 箇条書きを自然な文章にできる場合は、段落に書き換えることを優先します。
4. 中国語らしいリズムを保つ
  • 長文と短文を織り交ぜ、すべての文を同じ長さにしないでください。
  • 文の主語と動作を明確にし、主語のない文を連ねるのは控えます。
  • 段落の最後を、漠然とした大きな価値判断で締めくくらないようにします。
5. 記事全体の構成を整える
  • 冒頭では早めに主題を示します。第一段落でAを述べたのに、その後の話がBへと流れていくような構成は避けます。
  • 本文の各段落には、それぞれ役割を持たせます。背景の説明、判断の提示、根拠の展開、例示、転換、まとめなどが一般的です。
  • 主軸を進めることも必要な情報を加えることもない段落は、無理に残さず、削除、統合、移動を優先します。
  • 結びでは、前文で提起した本当の問いに答えます。最後になって、より大きな時代の命題へ無理に話を広げないでください。
  • 大幅に書き換える場合は、段落の順序を組み替えても構いませんが、整って見せるために無理に三段論法にしないでください。
  • 構成を要約する際は、段落の関係を 先……再……最后…… の羅列で表すのを控え、それぞれの段落が同じ問いに沿って自然につながっているかを重視します。
6. 句読点とレイアウトを整える
  • 本文の引用符は、デフォルトで全角の二重引用符 "" を使い、入れ子には全角の単一引用符 '' を使います。プロジェクトの CLAUDE.md/AGENTS.md で 「」 の使用が宣言されている場合、またはユーザーが今回の依頼で明示的に指定した場合は、文書全体で 「」 に統一し、入れ子には 『』 を使います。二つの形式を混在させないでください。
  • 長いダッシュ —— は使わず、読点、句点、または文の分割で置き換えます。
  • コロン : を密集して使わないでください。特に、複数の文を続けてコロンから説明するのは避けます。
  • 中国語本文中の複数語からなる英語の用語は、半角スペースで区切ります。例:AI Design Agent。
  • 英語の用語に中国語の括弧を続ける場合、( の前にスペースを入れません。例:LLM(大语言模型)。
  • 英語の用語をスラッシュで並べる場合は、スラッシュの前後にスペースを入れません。例:coworkers/agents。
  • 英語のブランド名は、公式の大文字・小文字表記を使います。例:YouTube、OpenAI、GitHub。
7. よく使う用語と日付の表記を統一する
  • token は英語のままにします。
  • API は英語のままにします。
  • 長文の中国語では、プロジェクトに別の明確な取り決めがない限り、PR は 代码审查 と表記することを優先します。
  • 数字で表す日付は、2026 年 2 月 26 日、2 月 5 日 のように書きます。
  • 中国語で月を表す場合は、一月、二月 と書きます。
8. 判断の強さを調整する
  • 「完全取代」「彻底结束」「只剩一种可能」のような極端な結論を安易に出さないでください。
  • 根拠のない陰謀論的な推測、資本市場に関する憶測、人物の動機の決め付けをしないでください。
  • 重要性を強調する必要がある場合は、まず仕組みを説明し、その後で判断を示します。

リポジトリ固有の上書きルール

  • 現在のプロジェクトに CLAUDE.md、AGENTS.md、サンプル記事、用語集がある場合は、まずプロジェクト内のルールに従い、その後でこのスキルの一般ルールを適用します。
  • プロジェクトに明確な文体のサンプルがある場合は、文の長さ、判断の示し方、段落の展開、用語の取り決めをまね、別の文体を新たに重ねないでください。
  • 引用符の形式は、次の順で決定します。ユーザーが今回の依頼で明示した指定 → プロジェクトの CLAUDE.md/AGENTS.md にある宣言(例:humanizer-zh quotes: 「」)→ デフォルトの ""。
  • 原文全体で 「」 が明らかに使われていて、プロジェクトに指定がない場合は、原文の形式を踏襲し、デフォルトの "" に無理に変えないでください。

詳細レビュー

次の場合は、追加で references/patterns.md を読みます。

  • 軽い推敲ではなく、大幅な書き換えが必要な場合。
  • 「この中国語がなぜAIっぽく感じられるのか」を説明する必要がある場合。
  • 文章に英語の原文構造、マーケティングの決まり文句、プレスリリース調が明らかに残っている場合。
  • 「修正前/修正後」の例を示す必要がある場合。
  • 冒頭、本文、結びが同じ主軸でつながっているか確認する必要がある場合。
  • より自然な記事の骨組みを先に作り、全体の構成を組み直す必要がある場合。

次の場合は、追加で references/corpus.md を読みます。

  • この中国語が、どのような母語話者の文章に近いか判断する必要がある場合。
  • ユーザーが「ブログや本に載っているような文章に直して」と明示的に求めている場合。
  • 技術文、論評、スピーチ稿にそれぞれ異なる参照先が必要な場合。
  • 個人の強い文体を、一般的な中国語と誤認しないようにする場合。

手早く参照先を選ぶだけでよい場合は、まず references/corpus-quickpick.md を読み、足りなければ references/corpus.md 全体を読みます。

ユーザーがこの会話ですでに特定の作家の文体を選んでいる場合は、該当する references/voices/<author>.md も追加で読み込みます。このプロファイルのルールは Core Rules と衝突する場合に優先されます。

出力

デフォルトでは、次の順で結果を提示します。

  1. 書き換えた文章をそのまま提示します。
  2. ユーザーが説明を求めた場合は、目立つ問題を3~6点、簡潔に指摘します。
  3. ユーザーが原文をより多く残すよう求めた場合は、「軽い修正版」と「大幅な書き換え版」を追加します。

Final Check

交付前逐项确认:

  • 读起来像中文作者在写,不像翻译后的英文。
  • 第一段提出的问题,最后一段确实有回应。
  • 主体段落都在服务主线,没有明显跑题段或重复段。
  • 句子之间有自然推进,不靠模板连接词硬粘。
  • 结论不过火,判断和事实强度匹配。
  • 全文节奏不要总是「先定义、再拆项、最后拔高」,更不能让读者连续三节都能预测下一节的写法。
  • 标点、术语、日期和品牌大小写统一。
  • 引号样式全篇统一("" 或 「」 二选一),没有把两种样式混用。
  • 如果本次启用了某位作者的声音,对照该档案的 anti-patterns 和测试清单再扫一遍,确认风格不跑偏,也没有把它的口癖泄漏到默认润色里。

コメント