Technische Blogartikel mit KI schreiben: Recherche, Codeprüfung und menschliches Review

Ein technischer Blogartikel enthält drei Codeblöcke, doch keiner wurde ausgeführt. Leser kopieren sie, erhalten Fehler und stellen fest: Nicht die Formulierung war das Problem, sondern fehlende Gates für Fakten und Code.

Ein KI-Entwurf kann vollständig aussehen und trotzdem Versionen, Befehlsparameter oder Ausgabeformate erraten. In einem Projekt steht etwa "type": "module" in der package.json, während das Beispiel direkt require verwendet. Ein anderer Text spricht von „2.000 GitHub-Actions-Minuten pro Monat“, ohne zu erklären, dass es sich um das Kontingent eines bestimmten Tarifs für private Repositories handelt.

Technisches Schreiben bedeutet deshalb nicht, ein Thema an ein Modell zu geben und das Ergebnis zu glätten. Zuerst kommen Quellen und ausführbare Belege, dann ordnet die KI die Erklärung, und zum Schluss prüft ein Mensch Fakten, Code und Sprache. Der folgende Ablauf gibt jeder Stufe ein Gate und eine Zuständigkeit, damit Aussagen korrekt, Beispiele ausführbar und Schlüsse reproduzierbar bleiben.

Vor dem KI-Entwurf recherchieren

Was zuerst recherchiert werden muss und was die KI entwerfen darf

Die erste Entscheidung lautet: Welche Fakten müssen von außen kommen, und welche Teile darf das Modell lediglich ordnen?

Dafür lassen sich drei Kategorien bilden.

Versionen, geänderte API-Felder, dokumentierte Grenzen, Preise oder Kontingente und Sicherheitskonfigurationen werden zuerst recherchiert. Ein Fehler kann das Projekt eines Lesers beschädigen oder unerwartete Kosten auslösen. Die aktuelle Next.js-Dokumentation verwendet beispielsweise den Schlüssel turbopack; in den Versionen 13.0.0 bis 15.2.x hieß er experimental.turbo. Wer nur „Turbopack konfigurieren“ schreibt, ohne die Version zu nennen, liefert möglicherweise eine inkompatible Konfiguration.

Allgemeine Konzepte, Framework-Nutzung, Best Practices und typische Fehler kann die KI entwerfen, aber ein Review bleibt nötig. Eine Erklärung zu React Hooks klingt oft plausibel; Anzahl der Regeln, Namenskonventionen und Versionsunterschiede werden trotzdem mit der offiziellen Dokumentation abgeglichen.

Struktur, sprachliche Überarbeitung und Formatierung darf die KI weitgehend übernehmen. Eine Erklärung verständlicher zu formulieren oder verwandte Absätze zusammenzuführen, erfordert normalerweise keine neue Recherche.

Die drei Kategorien im Vergleich:

Recherchetyp	Typische Inhalte	Stärke des Gates	Geeignete Stufe
Zuerst recherchieren	Versionen, API-Felder, Preise oder Kontingente, Sicherheit	Hoch: aus offizieller Dokumentation übernehmen und mit [VERIFY] markieren	Bei der Planung vorbereiten, am Schreibtag erneut prüfen
KI-Entwurf + Prüfung	Allgemeine Konzepte, Framework-Nutzung, Best Practices	Mittel: KI-Entwurf mit offizieller Dokumentation vergleichen	Beim Schreiben entwerfen, im Review prüfen
KI darf ordnen	Struktur, Sprache, Formatierung	Niedrig: normalerweise keine zusätzliche Recherche	Entwurfsphase

Ein Entscheidungsbaum:

Inhalt vom Typ X erscheint
  ↓
Geht es um Version, API, Preis oder Sicherheit?
  ├─ Ja → Aus offizieller Dokumentation übernehmen, [VERIFY] setzen und am Schreibtag prüfen
  └─ Nein → Geht es um eine technische Regel oder Best Practice?
      ├─ Ja → KI entwerfen lassen und im Review mit offizieller Dokumentation abgleichen
      └─ Nein → KI die Darstellung ordnen lassen

Rechercheergebnisse an den Schreibprozess übergeben

Nach der Recherche werden die Ergebnisse so abgelegt, dass der Schreibprozess sie direkt verwenden kann.

Aus research.md werden Quellen mit hoher Vertrauensstufe, besonders offizielle Dokumentationen mit high, übernommen. Dazu gehören beispielsweise die Google-Search-Central-Hinweise zu hilfreichen Inhalten, das offizielle Node.js-CI-Beispiel von GitHub und die Dokumentation zu Astro Content Collections.

Veränderliche Fakten erhalten [VERIFY], etwa „Das enthaltene GitHub-Actions-Kontingent für private Repositories hängt vom Kontotarif ab [VERIFY]“ oder „Prüfen, ob die Zielversion von Node noch unterstützt wird [VERIFY]“.

Quellenkarten, Befehlsausgaben und Prüfergebnisse kommen in die Felder source_cards und risk_notes der Outline-Eingabe:

{
  "source_cards": [
    {
      "url": "https://developers.google.com/search/docs/fundamentals/creating-helpful-content",
      "type": "official/docs",
      "confidence": "high",
      "usable_info": "Inhalte sollen eigene Informationen und eine vollständige Erklärung bieten, statt primär auf massenhafter Automatisierung zu beruhen"
    }
  ],
  "risk_notes": [
    {
      "fact": "Enthaltenes GitHub-Actions-Kontingent",
      "status": "[VERIFY]",
      "check_date": "2026-06-24",
      "source": "https://docs.github.com/en/billing/managing-billing-for-github-actions"
    }
  ]
}

Sind diese Markierungen vorhanden, muss die Schreibphase nicht die gesamte Recherche wiederholen. Sie prüft nur die ausdrücklich veränderlichen Angaben erneut.

Codebeispiele müssen laufen und nicht nur korrekt aussehen

Vier Fälle der Codevalidierung

Technische Beispiele sehen oft plausibel aus und scheitern im echten Projekt. Sobald Leser sie kopieren und einen Fehler erhalten, verliert der Artikel an Vertrauen.

Die Validierung lässt sich in vier Fälle aufteilen.

Lokale Ausführung umfasst Installationsbefehle, Konfigurationen und kleine Skripte wie npm install, git clone oder eine Konfigurationsänderung. Diese Befehle werden lokal ausgeführt, und ihre Ausgabe wird gespeichert.

CI-Tests umfassen Build- und Testbefehle sowie Umgebungsabhängigkeiten, etwa npm ci, npm run build und npm test in GitHub Actions. Eine CI-Umgebung macht die Ausführung wiederholbar.

Versionsprüfung umfasst Node-, Abhängigkeits- und API-Versionen wie .nvmrc, package.json und geänderte Endpunkte. Die Version wird notiert, relevante Unterschiede werden erklärt. Umgebungskonsistenz betrifft Unterschiede zwischen Entwicklung, Produktion und CI, darunter Umgebungsvariablen, Docker-Images und Betriebssysteme. Die ausgeführte Umgebung muss genannt werden.

Die vier Fälle:

Validierungsfall	Typische Inhalte	Methode	Erforderlicher Beleg
Lokale Ausführung	Installation, Konfigurationsdateien	Lokal ausführen	Befehlsausgabe oder Screenshot
CI-Test	Build- und Testbefehle	GitHub Actions oder anderes CI-System	CI-Log oder Build-Ergebnis
Versionsprüfung	Node- oder Abhängigkeitsversion	Versionsbefehl	Ausgabe von node --version plus Versionshinweis
Umgebungskonsistenz	Umgebungsvariablen, Docker	Mehrere Umgebungen testen oder geprüfte Umgebung nennen	Umgebungsangabe plus Bedingungen

Ausführungsbelege für Code dokumentieren

Jedes Codebeispiel braucht einen Ausführungsbeleg. „Erfolgreich ausgeführt“ reicht nicht. Die folgenden Befehle und Ausgaben zeigen nur das Format eines Belegs; sie sind kein wiederverwendbares Testergebnis. Im eigenen Artikel werden sie durch echte Versionen und Logs des Zielprojekts ersetzt.

Beispiel für einen Node.js-CI-Datensatz:

# Lokale Umgebung: macOS + Node 18.20.0 LTS
$ node --version
v18.20.0

# CI-Umgebung: GitHub Actions
$ npm ci
added 245 packages in 12s

$ npm run build
✓ Built in 1.23s

$ npm test
✓ 12 tests passed

Richtig ist eine Ausgabe als Text oder Screenshot mit Version und relevantem Ergebnis.

Falsch ist die bloße Aussage „lief erfolgreich“ ohne Ausgabe.

Code gehört in fenced code blocks mit Sprachangabe wie bash oder typescript. Lange Ausgaben werden eingeklappt oder auf die wichtigen Zeilen begrenzt. Bei mehreren Schritten wird die Umgebung als lokal, CI oder Docker benannt. Versionsprüfungen enthalten die Ausgabe von node --version oder npm --version.

Beispiel:

# Ausführungsumgebung: macOS + Node 18.20.0
$ npm install
added 124 packages in 8s

$ node --version
v18.20.0

Bei langen Build-Ausgaben genügt der relevante Ausschnitt:

$ npm run build
✓ Built in 1.23s
  ├─ dist/index.html
  ├─ dist/assets/index.js
  └─ dist/assets/index.css

GitHub beschreibt fenced code blocks und Syntaxhervorhebung in Creating and highlighting code blocks. Technische Artikel sollten kopierbaren, prüfbaren Code behalten, statt ihn als Fließtext zu tarnen.

Das menschliche Review prüft Fakten, Code und Struktur

Faktenprüfung: Versionen, Parameter und Preise zurückverfolgen

Ein menschliches Review ist keine reine Sprachkorrektur. Es prüft Fakten, Code und Struktur. Wer nur Formulierungen glättet, übersieht falsche Versionen, ungültige Parameter oder einen Widerspruch zwischen Code und Schlussfolgerung.

Im Zentrum steht die Rückverfolgbarkeit. Jede Version, jedes API-Feld, jeder Befehlsparameter, Konfigurationswert, Preis oder Kontingent und jedes Veröffentlichungsdatum wird mit offizieller Dokumentation oder einem echten Ausführungsbeleg verglichen.

Prüftabelle:

Punkt	Prüfmethode	Fehlersignal	Geeigneter Beleg
Version	Mit offiziellem Release oder Dokumentation vergleichen	Version existiert nicht oder Funktion ist falsch beschrieben	Offizieller Link plus Ausgabe von node --version
Befehlsparameter	Mit offizieller CLI-Dokumentation vergleichen	Parameter fehlt oder hat falsches Format	Offizieller Link plus echte Ausgabe
API-Feld	Mit offizieller API-Dokumentation vergleichen	Feld fehlt oder Typ ist falsch	Offizieller Link plus reale Anfrage
Preis oder Kontingent	Mit offizieller Preisseite vergleichen	Preis falsch oder Bedingung für öffentlich/privat fehlt	Offizieller Link plus Bedingungen
Veröffentlichungsdatum	Mit offizieller Ankündigung vergleichen	Datum oder Ereignis falsch	Link zur Ankündigung

Ein fehlerhaftes Beispiel:

Das Projekt deklariert "type": "module" in package.json, doch das Beispiel nutzt direkt CommonJS-require, ohne auf .cjs umzustellen oder die Modulgrenze zu erklären.

Ein weiteres fehlerhaftes Beispiel:

Der Text behauptet, GitHub Actions biete „nur 2.000 kostenlose Minuten pro Monat“, ohne zu erwähnen, dass Standard-GitHub-hosted Runner für öffentliche Repositories kostenlos sind und das Kontingent privater Repositories vom Kontotarif abhängt.

Genauer formuliert:

„Node 18 unterstützt ES modules und CommonJS. .mjs, .cjs sowie das Feld type in package.json bestimmen die Interpretation einer Datei. Dieser Ausführungsbeleg verwendet Node 18.20.0 und enthält die Ausgabe von node --version.“

„Am 26. Juli 2026 sind Standard-GitHub-hosted Runner für öffentliche Repositories kostenlos. Private Repositories erhalten je nach Kontotarif ein Kontingent, beispielsweise 2.000 Minuten mit GitHub Free und 3.000 mit GitHub Pro (Quelle: GitHub Actions billing).“

Codeprüfung: ausführbar, passende Ausgabe, benannte Umgebung

Die Codeprüfung stellt drei Fragen: Läuft der Befehl, stützt die Ausgabe den Text, und ist die Umgebung eindeutig?

Punkt	Prüfmethode	Fehlersignal	Geeigneter Beleg
Ausführbarer Befehl	Lokal oder in CI ausführen	Fehler oder fehlende Abhängigkeit	Log oder Screenshot
Passende Ausgabe	Ausgabe mit Text vergleichen	Ausgabe widerspricht der Beschreibung	Text und Protokoll stimmen überein
Benannte Umgebung	Umgebungsnotiz prüfen	Node-Version oder Betriebssystem fehlt	Node 18.20.0 + macOS
Abhängigkeitsversion	package.json prüfen	Version widerspricht dem Text	package.json oder Versionsausgabe

Fehlerhaft:

Der Text sagt, der Build erzeuge drei Dateien, aber npm run build listet fünf.

Der Text sagt „lokal ausgeführt“, obwohl das Beispiel Docker benötigt und diese Bedingung fehlt.

Korrekt:

Text und Log stimmen überein: „npm run build erzeugte index.html, index.js und index.css.“

Die Umgebung ist klar: „Getestet unter macOS mit Node 18.20.0. Unter Linux oder Windows können Pfade angepasst werden müssen.“

Struktur und Stil: H2/H3, interne Links und KI-Reste

Die Struktur- und Stilprüfung vergleicht H2/H3 mit der freigegebenen Struktur, kontrolliert interne Links und entfernt leere KI-Formulierungen.

Punkt	Prüfmethode	Fehlersignal	Geeignetes Ergebnis
H2/H3-Konsistenz	Mit outline.md vergleichen	Abschnitt fehlt oder wurde unerwartet ergänzt	Grund der Änderung dokumentieren
Interne Links	Mit Linkplan vergleichen	Link fehlt oder Anker ist irreführend	Geplanten Link mit beschreibendem Anker setzen
KI-Formulierungen	Mit anti-ai-words.json vergleichen	Leere Behauptung oder vage Zuschreibung	Durch konkrete Tatsache ersetzen oder löschen

Die Datei anti-ai-words.json der Website gruppiert Ausdrücke, die vermieden werden sollen. Leere Behauptungen, vage Zuschreibungen und übertriebene Versprechen werden ersetzt oder gelöscht.

Ein schlechtes Beispiel ist eine Einleitung, die nur einen Zeitgeist behauptet.

Auch „Dieser Artikel bietet eine umfassende Analyse“ ist ein leeres Versprechen.

Eine bessere Einleitung beginnt mit der Entscheidung: „Beim KI-gestützten technischen Schreiben muss zuerst geklärt werden, welche Fakten aus externen Quellen kommen.“

Ein prüfbares Versprechen lautet: „Dieser Ablauf setzt je ein Gate für Recherche, Validierung und Review.“

Den Prozess mit QA vor der Veröffentlichung abschließen

QA-Checkliste vor der Veröffentlichung

Ein fertiger Entwurf ist noch nicht veröffentlichungsfähig. Die letzte Stufe prüft Recherchemarker, Codebelege, Quellen, Struktur, interne Links, KI-Reste und Bilddateien.

Punkt	Prüfung	Bestanden, wenn	Reaktion bei Fehler
Recherchemarker bereinigt	Nach [VERIFY] suchen	Kein offener Marker	Zur Recherche zurückkehren
Codebeispiele validiert	Mit Ausführungslogs vergleichen	Jedes Beispiel hat einen Beleg	Zur Codevalidierung zurückkehren
Fakten rückverfolgbar	Mit Quellenkarten vergleichen	Jede wichtige Aussage hat Quelle oder Einschränkung	Quelle ergänzen oder Aussage löschen
Struktur konsistent	Mit outline.md vergleichen	H2/H3 stimmen oder Änderungen sind erklärt	Strukturaufzeichnung aktualisieren
Interne Links gesetzt	Mit Linkplan vergleichen	Links und Anker sind korrekt	Link setzen oder Plan ändern
KI-Reste entfernt	Mit anti-ai-words.json vergleichen	Keine leere KI-Sprache	Umschreiben oder löschen
Bilder vorhanden	Bildliste mit Markdown-Pfaden vergleichen	Alle referenzierten Assets existieren	Bild hochladen oder Pfad korrigieren

Status:

Bestanden: Der Artikel kann weiter zur Veröffentlichung.

Offen: Eine Quelle oder Aussage muss geprüft werden.

Fehlgeschlagen: Zur zuständigen Recherche-, Validierungs- oder Schreibstufe zurückkehren.

Jeder Punkt wird einzeln geprüft und sofort markiert. Erst wenn alle Punkte bestanden sind, erhält die Aufgabe den Status „veröffentlichungsbereit“.

Fehlgeschlagene Punkte zurückgeben

Ein QA-Fehler geht an die Stufe zurück, die ihn verursacht hat. Er wird nicht übersprungen.

Ein Faktenfehler geht an die Recherche. Eine offizielle Quelle wird ergänzt, eine unbelegte Aussage entfernt oder eine veränderliche Angabe neu geprüft.

Ein Codefehler geht an die Validierung. Der Befehl wird erneut ausgeführt, die Ausgabe gespeichert, das Beispiel korrigiert und die Umgebung genannt.

Bei einer abweichenden Struktur wird die Strukturaufzeichnung aktualisiert oder dokumentiert, welches H2/H3 sich aus welchem Grund geändert hat.

Ein fehlender interner Link geht zurück an den Linkplan. Der reale Artikel wird im Bestand gesucht und mit einem beschreibenden Anker statt „hier klicken“ verlinkt.

KI-Reste gehen an die Redaktion zurück. Markierte Wörter werden durch konkrete Informationen ersetzt; bleibt der Satz vage, wird er vollständig neu geschrieben.

Beispiel:

QA erkennt, dass beim GitHub-Actions-Kontingent die Bedingung öffentlich/privat fehlt
  ↓
Als fehlgeschlagen markieren
  ↓
Zur Recherche zurückkehren
  ↓
Offizielle Abrechnungsquelle und Bedingungen ergänzen
  ↓
QA erneut ausführen

Der Rückweg macht Verantwortung sichtbar. Die letzte prüfende Person soll nicht eine unerklärte Änderung übernehmen müssen.

Sieben Signale für Abweichungen von den Fakten

Die sieben Signale

Faktische Abweichungen entstehen schrittweise. Diese Signale helfen, sie vor der Veröffentlichung zu finden.

Signal 1: eine Aussage ohne Quelle. Der Text nennt „neueste Version“, „offizielle Empfehlung“ oder „Best Practice“, verlinkt aber keinen Beleg. Beispielsweise wird behauptet, ein Turbopack-Schlüssel funktioniere in jeder Next.js-Version, ohne die Dokumentation der betroffenen Versionen zu nennen.

Signal 2: nicht ausgeführter Code. Es gibt weder Ausgabe noch Log, nur die Aussage „funktioniert“.

Signal 3: Version oder Parameter sind falsch eingeordnet. Die Version kann existieren, aber Release-Zweig oder Supportstatus stimmen nicht. Auch Parameter und API-Endpunkte ändern sich. Node 20.1.0 als LTS zu bezeichnen ist falsch; diese Version erschien als Current.

Signal 4: Die Umgebung passt nicht. Der Beleg nennt eine Umgebung, während das Verhalten nur in einer anderen geprüft wurde.

Signal 5: Der Schluss ist nicht reproduzierbar. Ein Leistungsvorteil wird ohne Methode, Datensatz und Reproduktionsschritte behauptet.

Signal 6: Ein interner Link ist defekt. Der Artikel verweist auf /posts/ai/ai-xxx, aber diese Route existiert nicht.

Signal 7: Vage KI-Sprache verdeckt die Lücke. „Umfassende Analyse“ ersetzt eine Quelle oder ein konkretes Resultat.

Beispiele:

Signal	Falsches Beispiel	Problem
Aussage ohne Quelle	„Dieser Turbopack-Schlüssel gilt für jede Next.js-Version“	Keine offizielle Dokumentation für die Versionen
Nicht ausgeführter Code	„npm install ausführen; es funktioniert“	Kein Ausführungsbeleg
Falsche Version	„Node 20.1.0 LTS“	20.1.0 war Current, nicht LTS
Umgebung passt nicht	Alte Umgebung dokumentiert, Verhalten nur anderswo geprüft	Version und Prüfumgebung widersprechen sich
Nicht reproduzierbarer Schluss	„Die Leistung ist deutlich besser“	Keine Methode oder Daten
Defekter interner Link	Link auf /posts/ai/ai-xxx	Route existiert nicht
KI-Rest	„Umfassende Analyse des KI-Schreibens“	Vages Versprechen

Bei einem Signal wird [VERIFY] gesetzt und der Punkt an die verantwortliche Stufe zurückgegeben.

Eine unbelegte Aussage geht zur Recherche, nicht ausgeführter Code zur Validierung, eine falsche Version zum offiziellen Release. Eine unpassende Umgebung braucht korrekte Bedingungen oder die Löschung der Aussage. Ein nicht reproduzierbarer Schluss braucht Methode, Daten und Schritte oder wird entfernt. Ein defekter Link wird auf eine reale Route geändert. Vage Sprache wird konkretisiert oder gelöscht.

Entscheidend ist die sofortige Rückgabe. Sonst wachsen kleine Unsicherheiten zu einem nicht mehr nachvollziehbaren Artikel.

Ohne vollständige Testumgebung ehrlich schreiben

Drei ehrliche Vorgehensweisen

Manchmal fehlt die vollständige Umgebung: ein kostenpflichtiger Dienst, ein komplexer Cluster, ein bestimmtes Betriebssystem oder spezielle Hardware. Dann dürfen keine Belege erfunden werden. Es gibt drei saubere Wege.

Erstens: Bedingungen und Grenzen nennen. Die geprüfte Version und mögliche Abweichungen werden dokumentiert; ebenso, wenn nur der kostenlose Tarif getestet wurde. Beispiel: „Das Beispiel wurde nur mit Node 18.20.0 geprüft; andere Versionen können abweichen.“

Zweitens: eine alternative Validierung anbieten. Dazu gehören minimale Reproduktion, Mock-Daten oder ein offizieller Issue. Beispiel: „Es stand kein Kubernetes-Cluster zur Verfügung. Daher wird nur eine minimale Reproduktion gezeigt, die noch in einem echten Cluster geprüft werden muss.“

Drittens: Ungeprüftes offenlassen. „Diese Leistungsaussage wurde in der aktuellen Umgebung nicht reproduziert“ ist korrekt; andernfalls wird die Aussage gelöscht.

Vergleich:

Fall	Unehrliche Formulierung	Ehrliche Formulierung
Versionsunterschied	„Alle Versionen unterstützen es“	„Mit Node 18.20.0 geprüft; andere Versionen können abweichen“
Umgebungsunterschied	„Lokal erfolgreich“	„Unter macOS mit Node 18.20.0 geprüft; Linux, Windows oder andere Node-Versionen können Anpassungen brauchen“
Kostenpflichtiger Dienst	„Kostenlos nutzbar“	„Nur der kostenlose Tarif wurde geprüft; bezahlte Funktionen können abweichen“
Ungeprüfte Aussage	„Die Leistung ist deutlich besser“	„Die aktuelle Umgebung hat diesen Leistungsschluss nicht reproduziert“

Geeignete Beispiele:

„Getestet wurde der kostenlose Tarif von Cloudflare Workers, der derzeit 100.000 Anfragen pro Tag enthält. Bedingungen bezahlter Funktionen können abweichen; siehe offizielle Preisseite.“

„Es stand kein Kubernetes-Cluster zur Verfügung. Die minimale Reproduktion muss in einem echten Cluster mit den relevanten Pod-Ressourcen und Netzwerkeinstellungen geprüft werden.“

„Es gibt hier keinen Benchmark eines großen Projekts. Deshalb wird keine Aussage über die Build-Leistung von Turbopack getroffen. Miss Basis- und Vergleichswert im eigenen Projekt.“

Ungeeignete Beispiele:

„Cloudflare Workers ist kostenlos.“ Das Kontingent fehlt.

„Funktioniert in jeder Umgebung.“ Die Umgebung fehlt.

„Die Leistung ist deutlich besser.“ Methode und Daten fehlen.

Google Search Central empfiehlt in Creating helpful, reliable, people-first content eigene Informationen, eine vollständige Erklärung und nützliche Analyse. Eine ehrliche Einschränkung senkt den Standard nicht, sondern trennt Geprüftes von noch zu Prüfendem.

Wann veröffentlichen und wann überarbeiten?

Entscheidungsbaum für die Veröffentlichung

Nicht Wortzahl oder fertige Optik entscheiden, sondern das Bestehen von Recherche, Validierung, Review und QA.

Recherche: Sind alle hochvertrauenswürdigen Quellen vorhanden und veränderliche Fakten markiert, folgt die Codevalidierung. Fehlt eine Kernquelle, wird weiter recherchiert.

Codevalidierung: Laufen alle Beispiele, folgt das Review. Fehlerhafte Beispiele werden korrigiert oder gelöscht. Nicht prüfbare Beispiele erhalten klare Grenzen oder werden entfernt.

Menschliches Review: Sind Fakten rückverfolgbar, folgt QA. Aussagen ohne Quelle werden belegt oder gelöscht. Eine erklärte Strukturänderung darf weiter; unerklärte Abweichung geht zurück zur Planung.

QA vor der Veröffentlichung: Sind alle Punkte bestanden, kann der Artikel weiter. Offene Punkte werden geprüft, Fehler gehen an ihre Stufe zurück.

Ein Artikel kann weiter, wenn Recherche und Aktualitätsprüfung abgeschlossen sind, Codebeispiele Ausführungsbelege haben, das Review Fakten und Struktur bestätigt, leere KI-Sprache entfernt wurde und QA besteht.

Fehlen Quelle, Ausführungsprotokoll, interner Link oder Stilbereinigung, ist weitere Arbeit nötig.

Falsche Kernfakten wie Version, Parameter oder Preis, nicht reproduzierbare Hauptschlüsse oder eine unerklärte Abweichung vom vereinbarten Ziel erfordern eine Überarbeitung.

Jede Stufe hat ein Gate. Ein Fehler wird zur Ursache zurückgegeben und nicht in die Veröffentlichung getragen.

Priorität der Rückgaben:

Zuerst Faktenfehler korrigieren oder löschen. Danach Codefehler, weil Leser sie kopieren könnten. Strukturabweichungen und fehlende Links sind weniger dringend, müssen aber vor der Veröffentlichung gelöst sein.

Weiterführende Artikel

Wenn die KI zuerst den Projektkontext kennen muss, hilft CLAUDE.md gegen falschen KI-Code. Für wiederverwendbare Schreib- und Review-Schritte eignet sich ein Workflow mit Claude Code Skills.

Außerdem gibt es einen KI-Schreibworkflow für allgemeine Inhalte. Dort steht Effizienz im Vordergrund; hier geht es um technische Fakten, Ausführungsbelege und Veröffentlichungsgates. Beide Ansätze lassen sich kombinieren.