unslop

Unslop

AI によく見られるパターンを取り除くよう、テキストを編集します。

手順

1. 以下のパターンがないか確認します。
2. 書き直します。意味を保ち、意図されたトーンに合わせます。

検出して修正するパターン

ルール番号は、ほかのスキルから参照される固定 ID です。ルールが削除されても、番号は欠番のままになります。

内容

3. 表面的な -ing 句。 「highlighting...」「ensuring...」「reflecting...」「showcasing...」「fostering...」。削除するか、実際の情報源に基づいて説明を補います。
4. 曖昧な帰属表現。 「専門家は〜と考えています」「業界レポートによると〜」「一部の批評家は〜と主張しています」。情報源を明示するか、削除します。

言葉づかい

7. AI が多用する語彙。 Additionally、crucial、delve、enduring、enhance、fostering、garner、interplay、intricate、抽象的な意味での landscape、pivotal、showcase、抽象的な意味での tapestry、testament、underscore、vibrant。平易な語に置き換えます。
8. 「〜です」の気取った言い換え。 「serves as」「stands as」「boasts」「features」。単に「is」または「has」とします。
9. 「X だけでなく Y も」。 代わりに要点を直接述べます。
10. 3 つ並べるルール。 アイデアを無理に 3 つのグループにまとめることです。自然な数にします。
11. 類義語の使い回し。 1 つの段落で「主人公」「メインキャラクター」「中心人物」「ヒーロー」を使い分けることです。1 つに決めて、繰り返し使います。
12. 実態のない範囲表現。 意味のある尺度でない X と Y に「X から Y まで」を使うことです。話題をそのまま列挙します。

スタイル

13. ダッシュの多用。 ダッシュは一切使いません。ピリオドかコンマを使います（括弧、ダッシュ、ダッシュ代わりのハイフンも使いません）。文を区切る必要がある場合は、文を終わらせるかコンマを使います。
14. コロンの多用。 リストや例の前にコロンを使うのは問題ありません。文中をつなぐためには使いません。「従来の自動化を使っている場合は、イベントハンドラーを登録する代わりに、条件を記述します」のようなコロンは不要です。比較を持ち出さず、要点が伝わるように書き直します。「スケジューラーが実行されるタイミングは、平易な言葉で記述するのが最適です」とすれば、同じ意味を不要な記号なしで伝えられます。
15. 太字の多用。 固有名詞や頭字語をすべて太字にするのは避けます。
16. 見出し風のリスト項目。 太字のラベルとコロンで始まり、その行の内容を言い換えているのが特徴です。「パフォーマンス： パフォーマンスが向上しました」のようなものです。散文に書き換えます。項目名を示す太字の導入部分がピリオドで終わり、その後に新しい情報が続く場合（「TypeScript のスキーマ。 テーブルは 1 つのファイルにまとめます」）は問題ありません。
17. 見出しのタイトルケース。 文頭のみ大文字にする形式を使います。
18. 装飾的な絵文字。 見出しや箇条書きから削除します。
19. 曲線形の引用符。 半角の直線引用符に置き換えます。

コミュニケーション上の不要表現

20. チャットボット風の表現。 「お役に立てれば幸いです！」「何かあればお知らせください」「もちろんです！」「承知しました！」「原因を突き止めました！」などは削除します。
21. 過剰にへりくだる表現。 「すばらしい質問です！」「まったくそのとおりです！」などを避け、直接答えます。

冗長表現

23. 冗長な表現。 「〜するために」は「〜するため」にします。「〜という事実により」は「〜なので」にします。「注意すべき重要な点は」を削除します。
24. 過剰なぼかし表現。 「〜の可能性があるかもしれないと主張できる可能性がある」を「〜かもしれない」にします。
25. ありきたりな結論。 「未来は明るいです」のような表現は避け、具体的な計画や事実を述べます。

専門用語

26. 抽象的な比喩表現。 Substrate、wedge、vector、locus、vantage、nexus、名詞としての primitive、比喩としての harness、「API surface」の surface、bedrock、比喩としての scaffolding、modality、paradigm、gold-plating、比喩としての ratchet、コードの移動を指す evacuate、endgame、north star、flywheel。技術的に聞こえますが、たいていはもっと平易で具体的な言葉に置き換えられます。「Substrate」は「base」に、「Wedge in」は「add」に、「Vector」は「way」または「method」に、「Gold-plating」は「必要以上のもの」に、「Ratchet」は実際の仕組みの名称、または「一方向にしか厳しくならない制限」に、「Evacuate」は「move out」に置き換えます。具体的な言葉を選びます。

平易な表現

27. どう感じるかではなく、何をするかを書きます。 「データベースをすぐ使える状態に保つ」「読みやすい SQL」「スキーマに従う型」は、感覚を表しています。仕組みや数値を示す表現に置き換えます。「.toSQL() はデータベースに送信する文字列をそのまま返します」「列の名前を変更するとビルドに失敗します」のように書きます。その文が読者に何をすべきか、何を知るべきかを伝えているかを考え、それを書きます。具体的な指示、事実、数値として言い換えられない場合は削除します。もう一つ確認します。その文が別のプロジェクトのドキュメントにもそのまま載せられるなら、このプロジェクトについて何も述べていません。削除します。
28. 長く複雑な文は短くするか、分割します。 文を理解するために読み返す必要があるなら、二つに分けるか、節を削ります。一文につき一つの考えにします。
29. 能動態を使います。 能動態を優先します。「is/are/was/were + 過去分詞」の形に注意し、動作の主体を明記します。「queries are validated」は「the compiler validates queries」に、「the file is parsed by the loader」は「the loader parses the file」に置き換えます。動作の主体が不明、または本当に重要でない場合に限り、受動態を使ってもかまいません。
30. 副詞を削るか、より力強い動詞を使います。 「runs quickly」は「is fast」または数値に置き換えます。「significantly improves」は測定した差に置き換えます。弱い動詞を補う副詞があるなら、その動詞は適切ではありません。
31. 平易な言葉を選びます。 「utilize」は「use」に、「leverage」は「use」に、「facilitate」は「help」に、「numerous」は「many」に、「in the event that」は「if」に置き換えます。凝った類義語を使っても、たいてい分かりやすくはなりません。
32. 気取った文章を避けます。 文字どおりの表現があるのに比喩や装飾的な表現を使うこと、格言めいた表現（「配線するか削除するか」など）、効果を狙った断片的な文、コードを擬人化する表現（「計画がそれを保持する」など）、比喩的な動詞（「同乗する」「〜の上に立つ」など）、ありきたりな前置きの表現は避けます。「調整する価値のあるダイヤル」は「値を変える価値のあるパラメーター」に置き換えます。言いたいことをそのまま述べます。比喩的な名詞についてはルール 26 を参照してください。
33. 過度に圧縮しないでください。 冠詞を省いたり、動詞のない断片的な文にしたり、記号だけで表したり、読者に解読させるような略語を使ったりすることは避けます。「Parser rejects bad date → exit 2, no write」は「The parser rejects a bad date, exits with code 2, and writes nothing.」に置き換えます。冠詞と動詞を備えた完全な文を書き、矢印や略語は省略せずに表します。