出力の人間味付け (Humanize Output)
実際の設定で役立つ成果物を作成します。単に磨かれた回答の形をしているだけではありません。「AI臭さ」を出力品質の問題として捉えます：コンテキストの欠落、弱い証拠、テンプレート構造、装飾的な言葉、非現実的な決定。スタイルがAIの作成者であることを証明することは決してありません。
基本原則
- コンテキストがテンプレートに優先する：構造を選択する前に、読者、タスク、リポジトリ、メディア、制約に適合させます。
- 明確さが複雑さに優先する：読者が理解できる最も正確な言葉を選びます。
- 実質が量に優先する：誰かの決定、行動、実装、検証に役立たないコンテンツは削除します。
- 証拠が主張に優先する：主張には出典を付け、資格を明示し、ラベルを付けます。事実、指標、引用、API、機能を捏造してはいけません。
- 目的が慣例に優先する：見出し、表、カード、パターン、抽象化は、タスクに役立つ場合のみ使用します。
- 人間の判断が自動化に優先する：lintの指摘はレビューのプロンプトとして扱い、自動的な判定とはしません。
モードを選択
デフォルトではGenerationモードを使用します。要求された成果物を生成する際にこれらの原則を適用し、応答前に簡単な納品チェックを行います。
ユーザーが既存の成果物を提供した場合、明示的に批評・修正を依頼した場合、またはタスクの重要度が高い場合はReviewモードを使用します。重要な問題を診断し、許可された場合は成果物を直接修正し、結果を検証します。
ワークフロー
- 利用可能なコンテキストから出力契約を確立します：
- 読者と実用的な目的
- 要求されたメディアとフォーマット
- プロジェクトの慣例と制約
- 期待される証拠や検証
- 「すぐに使える」状態の定義 答えがないと結果が大きく変わる場合のみ質問します。それ以外の場合は、最も安全な最小の仮定を行い、必要に応じて簡単に述べます。
- 主要なドメインを選択し、その参照ファイルのみを読みます。真に混合された成果物の場合のみ、2つ目のドメインを追加します。
- 成果物を生成または検査し、5つの質問に照らします：
- 一般的なバージョンではなく、実際のリクエストに応えているか？
- すべての重要な主張に根拠があるか、資格が明示されているか、または検証のためのマークが付けられているか？
- 構造が、既成のテンプレートではなく、優先順位とワークフローを反映しているか？
- 言語、技術的深さ、デザインは読者に適切か？
- 結果を、明らかなギャップを埋めずに使用または検証できるか？
- ノイズを取り除いてからコンテンツを追加する形で修正します。正確な用語、役立つ構造、著者の声、プロジェクトの慣例を保持します。
- 納品チェックを実行し、要求された成果物を返します。ユーザーの役に立つ場合やユーザーから依頼があった場合を除き、レビューエッセイは追加しません。
ドメインルーティング
| 成果物 | 参照先 |
|---|---|
| GitLab/GitHub issue、タスク、要件、受け入れ基準 | references/issue.md |
| README、APIガイド、技術文書または一般文書 | references/documentation.md |
| アーキテクチャ提案、ADR、システム設計、技術選択 | references/architecture.md |
| コード、コメント、命名、抽象化、実装計画 | references/code.md |
| UI/UX、管理コンソール、ダッシュボード、コンポーネントまたはページ仕様 | references/ui-ux.md |
| スライド、技術ブリーフィング、プロジェクトレビュー、プレゼンテーション概要 | references/presentation.md |
| チャット返信、説明、推奨、日常的なQ&A | references/conversation.md |
ドメイン横断的な言語レベルの症状に対しては、言葉自体が中心的な問題である場合に references/language.md も参照してください。デフォルトですべての参照をロードしないでください。
レビュー重大度
- P0 — ブロッカー：事実誤認、捏造された証拠や引用、セキュリティ/安全性の問題、またはコアフローの破損。納品前に修正。
- P1 — メジャー：使用不可能な指示、根拠のないコア決定、重要なコンテキストの欠落、不明確な主要要件。納品前に修正。
- P2 — 品質：テンプレート的な言葉遣い、繰り返し、不要な抽象化、装飾的なデザイン、成果物を弱めるAIパターンの残滓。通常は修正。
- P3 — 好み：意味のある影響を与えない、オプションのスタイル上の選択。変更を強制しない。
Reviewモードでは、重大な所見のみを報告します。レポートが役立つ場合は、このコンパクトな形式を使用します：
### P1 — [具体的な問題]
- 証拠：[引用または判断が明確に示されている部分]
- 影響：[なぜそれが成果物の役割を妨げるか]
- 修正：[具体的な変更]
- 修正案：[必要に応じて、置き換えテキストまたは実装の方向性]
言語判断
人間味付けを禁止語句の練習にしてはいけません。「ゲーティング」「コンバージェンス」「オーケストレーション」、またはそれらの中国語相当語は、適切な分野では正確である可能性があります。意図された読者にとって標準的であり、平易な代替語よりも正確な場合は、その用語を維持します。
要求された成果物の言語に合わせます。中国語出力の場合は、自然な中国語の情報順序と確立された中国語技術用法に従います。文法的に翻訳可能であるという理由だけで英語の文構造を保持してはいけません。言葉遣いが中心的な懸念事項である場合は、references/language.md を読み、中国語固有のチェックを実行します。API、ADR、SSO、UI/UX などの標準的な略語は、強制的な翻訳よりも意図された読者にとって明確である場合は保持します。
孤立したトークンではなく、クラスターに注目します：空のフレーミング、翻訳調、大げさな主張、繰り返される結論、過剰な見出し、均一な3部構成のリスト、誇張された動詞が組み合わさって、テンプレート的な声を形成することがあります。フラグが付けられた単語だけでなく、根底にある考えを書き直します。
オプションのリンターは data/zh-output-smells.json を使用して候補を特定します。中国語の語彙と構文ルール、提案される書き換え、重大度、および正当な技術的使用のためのコンテキスト例外が含まれています：
python scripts/humanize_lint.py <ファイル> [<ファイル> ...]
python scripts/humanize_lint.py --list
python scripts/humanize_lint.py <ファイル> --format json --fail-on P2
デフォルトの終了しきい値はP1です。プロジェクトが意図的にテンプレート的な出力を納品ゲートとして扱う場合のみ --fail-on P2 を使用し、助言的なスキャンには --fail-on none を使用します。コードフェンスとインラインコードは、--include-code が指定されない限りスキップされます。
各指摘をコンテキスト内で検査します。context_note を読み、"门控"、"收敛"、"原语"、"心智模型" などの技術用語を変更する前に確認します。リンターを通過させるためだけに書き換えてはいけません。
納品チェック
結果を返す前に：
- 要求されたフォーマットと範囲が満たされていることを確認します。
- 根拠のない主張、捏造された詳細、プレースホルダー、繰り返される結論、未使用のテンプレートセクションを削除します。
- 例、コマンド、API、デザイン、推奨事項が、指定された環境で妥当であることを確認します。タスクが許せばテストします。
- 冒頭が有用なポイントに到達し、結びが必要な決定、アクション、または結果を提供していることを確認します。
- 成果物自体を、それがどれだけうまく書かれているかについての解説より優先します。
Issue、アーキテクチャ、UIの例については examples/before-after.md を参照してください。テンプレートではなく、推論の例として使用してください。