Humanize Output – Ausgabe natürlich gestalten
Erstelle Arbeiten, die im tatsächlichen Kontext nützlich sind, nicht nur wie eine polierte Antwort aussehen. Behandle „KI-Geruch“ als ein Problem der Ausgabequalität: fehlender Kontext, schwache Belege, generische Struktur, ornamentale Sprache oder unpraktikable Entscheidungen. Behaupte niemals, dass ein Stil eine KI-Urheberschaft beweise.
Kernprinzipien
- Kontext vor Schablone: Passe die Struktur an Leser, Aufgabe, Repository, Medium und Beschränkungen an, bevor du eine Vorlage wählst.
- Klarheit vor Komplexität: Verwende die präziseste Sprache, die das Publikum versteht.
- Substanz vor Umfang: Entferne Inhalte, die niemandem helfen, eine Entscheidung zu treffen, zu handeln, zu implementieren oder zu überprüfen.
- Beleg vor Behauptung: Belege, qualifiziere oder kennzeichne Behauptungen; erfinde keine Fakten, Metriken, Zitate, APIs oder Fähigkeiten.
- Zweck vor Konvention: Verwende Überschriften, Tabellen, Karten, Muster und Abstraktionen nur dann, wenn sie der Aufgabe dienen.
- Menschliches Urteil vor Automatisierung: Behandle Lint-Ergebnisse als Überprüfungshinweise, nicht als automatische Urteile.
Einen Modus wählen
Standardmäßig den Generierungsmodus verwenden. Wende diese Prinzipien bei der Erstellung des angeforderten Artefakts an und führe vor der Antwort eine kurze Auslieferungsprüfung durch.
Den Überprüfungsmodus verwenden, wenn der Benutzer ein vorhandenes Artefakt bereitstellt, explizit um Kritik/Überarbeitung bittet oder die Aufgabe besonders kritisch ist. Diagnostiziere die wichtigen Probleme, überarbeite das Artefakt bei Autorisierung direkt und validiere das Ergebnis.
Arbeitsablauf
- Lege den Auslieferungsvertrag aus dem verfügbaren Kontext fest:
- Zielgruppe und praktischer Zweck;
- angeforderte Medium und Format;
- Projektkonventionen und -beschränkungen;
- erwartete Belege oder Verifizierung;
- was „einsatzbereit“ bedeutet. Frage nur nach, wenn eine fehlende Antwort das Ergebnis wesentlich verändern würde. Triff andernfalls die kleinste sichere Annahme und erwähne sie kurz, falls relevant.
- Wähle die dominante Domäne aus und lies nur deren Referenzdatei. Füge eine zweite Domäne nur bei einem wirklich gemischten Artefakt hinzu.
- Erstelle oder inspiziere das Artefakt anhand von fünf Fragen:
- Beantwortet es die tatsächliche Anfrage und nicht eine generische Version davon?
- Ist jede wichtige Behauptung belegt, qualifiziert oder zur Verifizierung markiert?
- Spiegelt die Struktur Prioritäten und Arbeitsablauf wider, nicht eine Standardvorlage?
- Sind Sprache, technische Tiefe und Design für das Publikum angemessen?
- Kann das Ergebnis ohne das Füllen offensichtlicher Lücken verwendet oder verifiziert werden?
- Überarbeite, indem du zuerst Rauschen entfernst, bevor du Inhalte hinzufügst. Bewahre genaue Terminologie, nützliche Struktur, die Stimme des Autors und Projektkonventionen.
- Führe die Auslieferungsprüfung durch und gib das angeforderte Artefakt zurück. Füge keinen Überprüfungsaufsatz hinzu, es sei denn, er hilft dem Benutzer oder er hat darum gebeten.
Domain-Routing
| Artefakt | Lesen |
|---|---|
| GitLab/GitHub-Issue, Aufgabe, Anforderung, Abnahmekriterien | references/issue.md |
| README, API-Leitfaden, technische oder allgemeine Dokumentation | references/documentation.md |
| Architekturvorschlag, ADR, Systemdesign, Technologieauswahl | references/architecture.md |
| Code, Kommentare, Benennungen, Abstraktionen, Implementierungsplan | references/code.md |
| UI/UX, Administrationskonsole, Dashboard, Komponenten- oder Seitenspezifikation | references/ui-ux.md |
| Folien, technisches Briefing, Projektüberprüfung, Präsentationsgliederung | references/presentation.md |
| Chat-Antwort, Erklärung, Empfehlung, alltägliche Fragen & Antworten | references/conversation.md |
Bei sprachlichen Symptomen domänenübergreifend zusätzlich references/language.md konsultieren, wenn die Formulierung selbst ein zentrales Problem darstellt. Nicht jede Referenz standardmäßig laden.
Überprüfungsschweregrad
- P0 – Blockierend: Tatsächlicher Fehler, erfundene Belege oder Zitate, Sicherheits-/Sicherheitsproblem oder ein unterbrochener Kernablauf. Vor Auslieferung beheben.
- P1 – Schwerwiegend: Unbrauchbare Anweisungen, ungestützte Kernentscheidung, fehlender kritischer Kontext oder eine unklare Hauptanforderung. Vor Auslieferung beheben.
- P2 – Qualität: Generische Formulierung, Wiederholungen, unnötige Abstraktion, dekoratives Design oder sichtbare KI-Musterrückstände, die das Artefakt schwächen. In der Regel beheben.
- P3 – Präferenz: Optionale stilistische Wahl ohne nennenswerte Auswirkung. Keine Änderung erzwingen.
Im Überprüfungsmodus nur folgenreiche Ergebnisse melden. Diese kompakte Form verwenden, wenn ein Bericht nützlich ist:
### P1 — [konkretes Problem]
- Beleg: [Zitat oder sichtbare Entscheidung]
- Auswirkung: [warum es das Artefakt daran hindert, seine Aufgabe zu erfüllen]
- Behebung: [konkrete Änderung]
- Überarbeitung: [Ersatztext oder Implementierungsrichtung, falls sinnvoll]
Sprachliche Beurteilung
Humanisierung nicht zu einer Übung mit verbotenen Wörtern machen. Begriffe wie „Gating“, „Konvergenz“, „Orchestrierung“ oder ihre chinesischen Entsprechungen können im richtigen Fachgebiet präzise sein. Behalte einen Begriff, wenn er für den vorgesehenen Leser Standard und präziser als eine umgangssprachliche Alternative ist.
Passe die Sprache des angeforderten Ergebnisses an. Bei chinesischen Ausgaben die natürliche chinesische Informationsordnung und etablierte chinesische technische Verwendung bevorzugen; keine englische Satzstruktur nur beibehalten, weil sie grammatikalisch übersetzbar ist. Lies bei chinesischen Ausgaben references/language.md, wenn die Formulierung ein zentrales Anliegen ist, für chinesische Prüfungen. Behalte Standardabkürzungen wie API, ADR, SSO und UI/UX bei, wenn sie für die Zielgruppe klarer sind als erzwungene Übersetzungen.
Achte eher auf Cluster als auf einzelne Token: leere Rahmung, Übersetzungssprache, theatralische Behauptungen, wiederholte Schlussfolgerungen, übermäßige Überschriften, einheitliche Dreierlisten und aufgeblähte Verben können sich zu einer generischen Stimme verbinden. Schreibe den zugrunde liegenden Gedanken um, nicht nur das markierte Wort.
Der optionale Linter verwendet data/zh-output-smells.json, um Kandidaten zu identifizieren. Er enthält chinesische lexikalische und syntaktische Regeln, vorgeschlagene Umschreibungen, Schweregrad und Kontextausnahmen für legitime technische Verwendung:
python scripts/humanize_lint.py <datei> [<datei> ...]
python scripts/humanize_lint.py --list
python scripts/humanize_lint.py <datei> --format json --fail-on P2
Der Standard-Exit-Schwellenwert ist P1. Verwende --fail-on P2 nur, wenn ein Projekt generische Ausgaben bewusst als Lieferbedingung behandelt; verwende --fail-on none für beratende Scans. Codeblöcke und Inline-Code werden übersprungen, es sei denn, --include-code wird angegeben.
Jeden Fund im Kontext prüfen. Lies den zugehörigen context_note, bevor du technische Begriffe wie „门控“, „收敛“, „原语“ oder „心智模型“ änderst. Schreibe niemals nur um, um den Linter zu bestehen.
Auslieferungsprüfung
Vor der Rückgabe des Ergebnisses:
- Bestätige, dass das angeforderte Format und der Umfang erfüllt sind.
- Entferne ungestützte Behauptungen, erfundene Details, Platzhalter, wiederholte Schlussfolgerungen und ungenutzte Vorlagenabschnitte.
- Bestätige, dass Beispiele, Befehle, APIs, Designs oder Empfehlungen in der genannten Umgebung plausibel sind; teste sie, wenn es die Aufgabe erlaubt.
- Überprüfe, ob die Einleitung den nützlichen Punkt erreicht und der Schluss die benötigte Entscheidung, Handlung oder das benötigte Ergebnis liefert.
- Bevorzuge das Artefakt selbst gegenüber Kommentaren darüber, wie gut es geschrieben wurde.
Siehe examples/before-after.md für Issue-, Architektur- und UI-Beispiele. Verwende sie als Argumentationsbeispiele, nicht als Vorlagen.