Wird KI-Text durch mehr Regeln besser? — Wie TypeScript einen Profi-Editor zum Workflow macht

Wenn ein KI-Text mittelmäßig wirkt, liegt die naheliegende Antwort auf der Hand: ein stärkeres Modell verwenden.

Es gibt noch eine zweite Möglichkeit: Man stellt dem Modell eine absurd pingelige Redaktion zur Seite, die niemals schläft.

Sie prüft den Titel, vergleicht sein Versprechen mit dem Inhalt, findet unerklärte Fachbegriffe, erkennt wiederholte Einschränkungen, kontrolliert alle 12 Sprachen und schickt nur die fehlerhaften Stellen zurück zur Überarbeitung.

TypeScript kann nicht schön schreiben. Es kann aber einen Redaktionsprozess bauen, der schwache Texte nicht freigibt.

1. Die 5-Sekunden-Antwort: Nicht Schreibtalent codieren, sondern den Redaktionsprozess

Gemeinsame Regeln können KI-Texte verbessern. Der größere Hebel entsteht, wenn daraus ein Ablauf wird: erzeugen → prüfen → Bedeutung bewerten → Fehler gezielt überarbeiten → erneut prüfen.

OpenAI beschreibt Evals als Kreislauf: definieren, was gut bedeutet, Ergebnisse messen und das System mit neuen Fehlerklassen aus realen Ausgaben verbessern.[1]

In einer Artikelfabrik sollte ein Fehler deshalb nicht nur einen Text reparieren. Er sollte zum Prüfpunkt für die nächsten hundert werden.

2. TypeScript ist nicht der Autor, sondern die Produktionslinie

Code ist stark bei deterministischen Prüfungen:

• Gibt es mehr als ein H1?
• Widersprechen sich title und og:title?
• Fehlt eine der 12 Sprachversionen?
• Gibt es doppelte Zwischenüberschriften?
• Sind Datum oder URL falsch formatiert?
• Muss der Text zurück in die Revision?

Andere Fragen brauchen Bedeutungsverständnis: Ist der Einstieg gut? Soll die Metapher bleiben? Trifft der Titel die echte Leserfrage? Hat die Recherche die ursprüngliche Beobachtung verdrängt?

Die sinnvolle Arbeitsteilung lautet deshalb: TypeScript für mechanische Prüfungen, KI-Editor für semantische Entscheidungen.

3. “Profi-Editor” wird umsetzbar, wenn man die Rolle zerlegt

Strukturredaktion

Prüft Leserbedarf, Reihenfolge, Tempo und ob die Antwort früh genug kommt.

Textredaktion

Bearbeitet Titel, Einstieg, Wiederholungen, Wortwahl und Rhythmus.

Faktenredaktion

Prüft Zahlen, Daten, Zitate, Sicherheit von Aussagen und Quellen.

Such-Einstiegsredaktion

Prüft, ob schon der Anfang des Titels erkennen lässt, worum es auf der Seite geht.

Google Search Central erklärt, dass Suchergebnis-Titel Nutzern helfen, Inhalt und Relevanz schnell zu verstehen. Empfohlen werden beschreibende, knappe und unterscheidbare Titel; Keyword-Stuffing wird ausdrücklich abgeraten.[2]

Auch die Usability-Forschung von NN/g zeigt, dass Menschen Webseiten häufig scannen und die ersten Wörter von Links und Überschriften besonders viel Informationssignal tragen.[4][5]

Es geht also nicht darum, “magische SEO-Wörter” nach links zu schieben, sondern das Thema schnell erkennbar zu machen.

4. Vorher / nachher: Den Witz verschieben, nicht töten

Vorher

Der Nachname ist unschuldig, das Wörterbuch ist abgestürzt — Manko, Wang und Chin als “gefährliche Namen in anderen Sprachen”

Der Hook ist stark, aber das eigentliche Thema kommt spät.

Nachher

Namen, die in einer anderen Sprache peinlich klingen — Manko, Wang, Chin und sprachübergreifende Kollisionen

Der erste Satz kann dann lauten:

Der Nachname ist unschuldig. Das Wörterbuch ist abgestürzt.

Der Witz bleibt erhalten und funktioniert mit bekanntem Kontext sogar besser.

Googles People-first-Leitfaden fragt ebenfalls, ob ein Titel den Inhalt hilfreich und beschreibend zusammenfasst, statt hauptsächlich mit Übertreibung Suchtraffic einzusammeln.[3]

5. Gute gemeinsame Regeln verhindern wiederkehrende Unfälle; sie klonen nicht jeden Artikel

Wenn jeder Text immer drei Sätze, immer Frage-Zwischenüberschriften und immer zwei Beispiele haben muss, entsteht Schablonentext.

Besser ist es, Fehler zu definieren:

• Die Hauptfrage nicht hinter einem Slogan verstecken.
• Im Titel nichts versprechen, was der Text nicht beantwortet.
• Dieselbe Einschränkung nicht mehrfach wiederholen.
• Fachbegriffe nicht ohne Erklärung einwerfen.
• Zwischenüberschriften müssen allein verständlich sein.
• Recherche soll die ursprüngliche Beobachtung stützen, nicht verdrängen.
• Japanische Wortstellung nicht mechanisch in elf weitere Sprachen übertragen.

6. P0 / P1 / P2 verhindert ein Regelgefängnis

P0: darf nie scheitern

Fakten, Zahlen, Daten, Zitate, Titel-Inhalt-Konsistenz, Datenschutz, vollständige Sprachen und keine unbelegten Behauptungen.

P1: sehr wichtig

Frühe Antwort, eine Hauptidee pro Absatz, einfache Erklärung vor Fachjargon, verständliche Zwischenüberschriften und weniger Wiederholung.

P2: Stimme

Humor, Metaphern, Gesprächston, Rhythmus und starke Hooks.

P0 zu schützen heißt nicht, P2 zu töten. Sonst produziert Qualitätskontrolle nur Behördendeutsch.

7. Das eigentliche Kapital ist eine Evaluationsschleife, die aus Fehlern wächst

1. Entwurf erzeugen.
2. Mechanische Prüfungen ausführen.
3. KI-Editor semantisch lesen lassen.
4. Strukturierte Fehlergründe zurückgeben.
5. Nur die fehlerhaften Stellen überarbeiten.
6. Erneut prüfen.
7. Neue, verallgemeinerbare Fehler zu dauerhaften Kriterien machen.

OpenAIs Eval-Ansatz betont genau diese kontinuierliche Verbesserung aus realen Fehlern.[1]

Wenn nur der Titel schlecht ist, sollte man nicht zweitausend gute Wörter neu erzeugen und dabei fünf neue Fehler einführen.

8. Die TypeScript-Implementierung darf simpel bleiben

const draft = await writeArticle(input);
const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);

if (!hardCheck.ok || editorial.hasCriticalIssue) {
  const revised = await reviseOnlyFailures(draft, { hardCheck, editorial });
  return verifyAgain(revised);
}
return draft;

Deterministisches gehört in den Code. Bedeutungsabhängiges geht an den KI-Editor. Fehlergründe werden zu präzisen Überarbeitungsanweisungen.

9. Automatisierung bleibt fehlbar: Auch der KI-Editor irrt

Er kann einen guten Witz als redundant streichen, Minderheitenstile glätten, kulturellen Humor bei der Lokalisierung verlieren oder den eigenen Text zu großzügig bewerten.

Darum ist ein semantischer Score ein Prüfsignal, nicht die Wahrheit. Fakten gehen zurück zu Primär- oder offiziellen Quellen, riskante Veröffentlichungen zu menschlicher Prüfung, und jede Sprache wird als echte Sprache bewertet.

10. Bei 100 oder 1000 Artikeln zählt der Zinseszinseffekt der Verbesserung

Ein Artikel zeigt, dass ein Slogan die Hauptfrage nach hinten gedrängt hat: neuer Check.

Ein anderer zeigt, dass vier “allerdings” die Aussage verwässert haben: neues Kriterium.

Eine deutsche Version ist grammatikalisch korrekt, klingt aber übersetzt: deutscher Lokalisierungscheck.

Ein Fehler wird von einer einmaligen Korrektur zu redaktioneller Infrastruktur.

11. Fazit: Baut eine Redaktion, die nie schläft, keinen Berg aus Regeln

Das Ziel ist nicht, literarisches Talent in TypeScript zu transplantieren.

Man will die nützlichen Urteile guter Redakteure wiederholbar machen: “Man erkennt nicht, worum es geht”, “der Titel verspricht etwas, das der Text nicht liefert”, “lösche den Witz nicht, verschiebe ihn”, “diese Behauptung braucht eine Quelle”.

Wer diese Urteile in mechanische Checks, semantische Redaktion, gezielte Revision und erneute Prüfung übersetzt, kann mit demselben Modell deutlich bessere Endtexte produzieren.

Denn gelernt hat das Redaktionssystem rund um das Modell.

---

共通参考資料 / Shared sources

1. OpenAI, “How evals drive the next chapter in AI for businesses” (2025-11-19): https://openai.com/index/evals-drive-next-chapter-of-ai/
2. Google Search Central, “Influencing your title links in search results”: https://developers.google.com/search/docs/appearance/title-link
3. Google Search Central, “Creating helpful, reliable, people-first content”: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
4. Nielsen Norman Group, “First 2 Words: A Signal for the Scanning Eye”: https://www.nngroup.com/articles/first-2-words-a-signal-for-scanning/
5. Nielsen Norman Group, “How Users Read on the Web”: https://www.nngroup.com/articles/how-users-read-on-the-web/

制作メモ / Editorial note

• 個人を特定できる情報は含めていない。
• 12言語で主質問・結論・章構成・事実関係をそろえつつ、逐語訳ではなく各言語で自然な語順に再構成した。
• 「タイトル前半を重視するとGoogle順位が上がる」とは断定していない。Google公式の根拠は、具体性・簡潔さ・関連性・キーワード乱用回避であり、前半重視は主としてWebのスキャン行動と情報発見性の観点から扱った。
• TypeScriptは文章品質を直接理解する主体ではなく、機械検査、意味評価の呼び出し、再生成、再検査を統合するオーケストレーション層として説明した。