発端：10 時間以上かけて 10 種類の「AI 臭除去」スキルをテストした
まず、[Human Talk.skill] のオープンソースアドレスはこちら：https://github.com/Pluviobyte/rnskill
最近、中国のコミュニティでは様々な「AI 臭除去」スキルやオープンソースプロジェクトが非常に人気を集めています。GitHub で humanizer、shuorenhua、stop-slop、qu-ai-wei、De-AI-writing などを検索するだけで、十数個見つかります。
私のニーズは非常に具体的です。AI 関連の技術記事を書く際に、下書きが自分で書いたように読みやすくなり、テンプレート感や「AI 臭」が少なくなるようにしたいのです。そこで、見つけられる限りのプロジェクトをすべてローカルにクローンし、同じ短い下書きを使って AI Native テーマで比較テストを実施しました。
10 個のプロジェクトをテストした後、最初に気づいたのは、これらはまったく同じタイプの De-AI スキルではないということでした。またしてもクリックベイトブロガーに騙されていました。
中国語の技術下書きにそのまま使える 3 つ
shuorenhua、Humanizer-zh、De-AI-writing。
shuorenhua は、シーンとレジスターに対する認識が最も細かいです。まずテキストが技術レビューなのか、意見記事なのか、ドキュメントなのかを判断してから、何を変更し、何を保持するかを決定します。修正後は、用語や判断は通常残り、テンプレートの殻や空の要約は取り除かれます。
Humanizer-zh はルールのカバレッジが最も広く、24 種類の AI ライティング痕跡に対してそれぞれ対応処理があります。最初のクリーニングラウンドには適していますが、下書きが編集者によって磨かれた一般的なプレスリリースのようになり、個人の声が弱まることがあります。
De-AI-writing は変更が最も軽微です。元の構造を保持することを優先し、道標的な言葉、講義調のトーン、段落末尾の要約だけを取り除きます。元の下書きに比較的満足しており、大幅な変更で方向性が狂うのを心配する場合に適しています。
ルール抽出に適した 2 つ
stop-slop とオリジナルの英語版 humanizer。
stop-slop のルールは短く、ハードで、直接的です。例えば、二項対立文（「XX は A ではなく B」）、三重並列、格言風の段落末尾、過剰説明などを削除対象とします。中国語に直接適用するのは少し硬いですが、「禁止リスト」として分解するのに優れています。
オリジナルの英語版 humanizer は最も体系的で、AI 痕跡をコンテンツパターン、文法、スタイル、コミュニケーションパターンの 4 つの主要タイプに分類します。中国語への適応は手動で行う必要がありますが、上流のリファレンスとして非常に価値があります。
長期的なライティング安定性のための 2 つ
writing-agent は完全なライティングパイプラインです。テーマ選定、証拠収集、スタンス確認から校正、臭気除去、エクスポートまでの全プロセスをカバーしています。ローカルでワークフローの検証と 15 のユニットテストを実行し、すべて合格しました。フルプロセスではモデルと API の設定が必要で、将来の長期的な公式アカウント記事作成の研究に適しています。
nuwa-skill はスタイルの蒸留に焦点を当てています。自分の実際の記事を 5〜7 個入力して、ライティング特性を抽出し、パーソナライズされたスキルを生成する必要があります。1 段落だけでテストしてもあまり意味がありません。
「中国語技術記事の AI 臭除去」とは程遠い 3 つ
chatgpt-comparison-detection は HC3 データセットと検出研究のためのリポジトリです。組み込みの中国語指示リストを使ってサンプルテキストを実行したところ、1 つの高頻度 ChatGPT ワード「so」にヒットしました。検出研究用であり、修正ツールではありません。
ai-flavor-remover はスキル構造のないスタンドアロンプロンプトで、推論モデルにそのまま投入して試すのに適しています。
taste-skill はフロントエンドの美的スキルで、インターフェースデザインを管理するもので、テキストとは無関係です。
後で気づいたこと
最も有用な出力は、特定のスキルからの最終的な下書きではなく、異なるスキルから抽出された具体的なルールでした。
shuorenhua は、シーンの切り替えの問題に気づかせてくれました。Fable-5 のレビューを書くことと、AI Native の意見記事を書くことでは、保持すべきものが異なります。レビューでは、価格、速度、モデル比較などのハードデータには触れてはいけません。意見記事では、個人的な判断や経験的な詳細を滑らかにしてはいけません。
stop-slop は、自分の下書きに「XX は A ではなく B」という文構造がどれほど頻繁に現れるかに気づかせてくれました。一度気づくと、耐え難くなります。同様の問題には、空の要約の末尾、3 部構成の並列、「言い換えれば」などのトランジションの埋め草が含まれます。
Humanizer-zh の二項対立検出と De-AI-writing の忠実性戦略も、個別に抽出して使用できます。前者は文構造の問題を特定するのに役立ち、後者は過剰編集によって用語や判断が散乱するのを防ぎます。
最終的にどのように使っているか
1 つの「最強」スキルをインストールするのではなく、これらのプロジェクトから独自のチェックリストを作成しました。技術記事を書いた後、次の項目を確認します。
下書きには実際のテスト経験と自分の判断が含まれているか？これらがなければ、記事は誰でも書ける一般的なマニュアルになり、読者は特定のテストから来たものだとわかりません。
二項対立の殻、空の要約、3 部構成の並列、格言風の末尾があるか？見つけ次第削除します。
用語やモデル名が散乱していないか？Fable-5 が「このモデル」に変わったり、Claude Opus が「この製品」に変わったりしたら、それは過剰編集です。
文の長さが均一すぎないか？すべての文がほぼ同じ長さだと、一様に磨かれたように非常に平坦に読めます。
これらのルールは、どの単一のスキルよりも効果的です。誰のライティングスタイルも異なり、「AI 臭」の発生源も様々です。ルールを分解して自分で組み合わせる方が、汎用的なスキルを直接適用するよりも効果的です。
最後に、最適なモデル——Opus 4.6
テスト中、GPT シリーズは最もパフォーマンスが悪く、特に Codex で使用するとスキルルールを見逃すことがよくありました。DeepSeek V4 Pro はより良いパフォーマンスを示しました。Opus 4.8 は GPT のスタイルを蒸留した可能性が高く、パフォーマンスも悪かったです。最もパフォーマンスが良かったモデルは Opus 4.6 でした。
上記の記事は Human Talk Skill を使用して作成され、オープンソース化されています：https://github.com/Pluviobyte/rnskill
フォロー大歓迎です @Pluvio9yte。次号では、このスキルの詳細な使用方法を解説します。
次号予告：「7 日間で 1,000 フォロワー：動画制作を AI 生産ラインに分解した方法」
