JSON wirkt auf den ersten Blick wie ein Detail – in der Praxis entscheidet es oft darüber, ob ein KI-Workflow stabil läuft oder ständig manuell nachgebessert werden muss. Viele nutzen KI-Tools wie ChatGPT, Claude, Gemini oder DeepSeek, um Daten für Automationen, Tabellen, CMS oder APIs zu erzeugen. Das Problem: Sprachmodelle sind auf Sprache optimiert, nicht auf „bitgenaues“ Format. Kleine Abweichungen (fehlende Anführungszeichen, ein zusätzliches Komma, ein Kommentar im JSON) reichen, um den gesamten Output unbrauchbar zu machen.
Die Lösung ist nicht „mehr Druck“ im Prompt, sondern ein sauberes Zusammenspiel aus klarer Struktur, einem festen Schema und einem Prüf- sowie Reparaturprozess. Genau darum geht es hier: Wie sich JSON-Output so anleiten lässt, dass er in WordPress, n8n, Make, Zapier oder eigenen Skripten zuverlässig verarbeitet werden kann.
Warum KI bei JSON so oft scheitert (und wie man es verhindert)
JSON ist streng – Modelle sind kreativ
JSON erlaubt keine Kommentare, keine nachträglichen Erklärsätze und keine „ungefähr so“-Strukturen. Ein Modell hingegen versucht oft zu helfen, indem es den Output erläutert („Hier ist dein JSON:“) oder Felder ergänzt. Für Menschen nett, für Parser fatal.
Typische Fehlerbilder aus der Praxis
- Zusätzlicher Text vor oder nach dem JSON (z. B. Einleitung, Hinweise, Codeblock-Markierungen).
- UngĂĽltige Syntax: trailing comma, fehlende AnfĂĽhrungszeichen, falsche Klammern.
- Feldtypen passen nicht: Zahl als String („12“ statt 12), true/false als „ja/nein“.
- Inkonsistente Keys: mal firstName, mal first_name.
- Unerwartete Felder, weil das Modell „hilfreich“ erweitert.
Das wichtigste Prinzip: Maschine zuerst
Wenn JSON weiterverarbeitet werden soll, muss es als Datenausgabe behandelt werden – nicht als Text. Eine gute Arbeitsregel: Alles, was ein Mensch „schön“ findet (Erklärungen, Formatierungstricks, zusätzliche Beispiele), ist oft genau das, was eine Automation bricht.
Ein Schema definieren, das wirklich durchhält
Welche Felder sind Pflicht – und welche optional?
Der schnellste Weg zu instabilem JSON ist ein schwammiger Auftrag wie „mach mir eine Zusammenfassung als JSON“. Besser ist eine klare Feldliste. Dazu gehört auch die Entscheidung: Was ist zwingend vorhanden (Pflichtfelder), was darf fehlen (optional)? Optional heißt: Feld kann wegfallen oder null sein – aber es sollte vorher festgelegt werden, sonst entstehen Mischformen.
Feldtypen und Formate klar festlegen
Modelle raten bei Typen. Deshalb lohnt sich ein Mini-Regelwerk im Prompt, zum Beispiel:
- Strings immer in doppelten AnfĂĽhrungszeichen.
- Zahlen ohne AnfĂĽhrungszeichen.
- Booleans nur true oder false.
- Datum als ISO-Format (YYYY-MM-DD), wenn ĂĽberhaupt ein Datum gebraucht wird.
Das ist keine „Kleinlichkeit“, sondern reduziert Nacharbeit drastisch – besonders, wenn mehrere Tools beteiligt sind.
Beispiel: Ein robustes Ziel-Objekt
Für einen typischen Content-Workflow (z. B. Ideensammlung oder Briefing) könnte das Ziel-JSON so aussehen:
- topic (String, Pflicht)
- audience (String, Pflicht)
- key_points (Array von Strings, Pflicht)
- risks (Array von Strings, optional)
- next_steps (Array von Strings, Pflicht)
Wichtig: Je kleiner und eindeutiger das Schema, desto stabiler das Ergebnis. Komplexität kann später schrittweise wachsen.
Prompt-Baustein: So entsteht verlässlicher JSON-Output
Eine Vorlage, die in vielen Tools funktioniert
Der folgende Aufbau ist oft stabiler als lange FlieĂźtext-Prompts. Er ist bewusst knapp und datenorientiert.
Schema (zum EinfĂĽgen in den Prompt):
- Gib ausschließlich gültiges JSON aus (keine Kommentare, keine Erklärungen, keine Codeblöcke).
- Nutze exakt diese Keys: topic, audience, key_points, risks, next_steps.
- Pflichtfelder dĂĽrfen nicht leer sein. Wenn risks unbekannt: [].
- key_points und next_steps sind Arrays mit 3–7 Einträgen.
Warum „nur JSON“ nicht reicht
Viele schreiben nur „Antworte nur mit JSON“. Das hilft, aber es bleibt eine Bitte. Stabiler wird es, wenn zusätzlich Regeln zur Struktur, zu Pflichtfeldern und zur Behandlung von „Unbekannt“ definiert werden (z. B. leeres Array statt erfundener Risiken).
Mit Beispielen arbeiten – aber richtig
Ein Mini-Beispiel kann helfen, aber es darf nicht dazu verleiten, Inhalte zu kopieren. Besser: ein Beispiel mit offensichtlich neutralen Werten (z. B. „Beispiel-Topic“), damit das Modell das Format versteht, ohne semantisch hängen zu bleiben. Wenn Beispiele genutzt werden, dann als „Form“, nicht als Inhalt.
PrĂĽfen und reparieren: ein kleiner Prozess, der viel Ă„rger spart
Vier PrĂĽfungen, die sich immer lohnen
Bevor JSON in eine Automation geht, helfen vier schnelle Checks. In Teams lässt sich das sogar als Gate definieren.
| Check | Woran er scheitert | Einfacher Fix |
|---|---|---|
| Syntax gĂĽltig? | Komma zu viel, Klammern falsch, Quotes fehlen | JSON in Validator prĂĽfen, dann gezielt korrigieren |
| Schema eingehalten? | Keys fehlen oder heißen anders | Modell um „Reformat to schema, do not add keys“ bitten |
| Datentypen korrekt? | Zahl als Text, Boolean als „ja/nein“ | Typregeln erneut nennen, Ausgabe neu erzeugen lassen |
| Pflichtfelder gefüllt? | Leere Strings, Arrays ohne Inhalt | Nachprompt: „Fülle nur die leeren Pflichtfelder“ |
Reparatur-Prompt statt Neu-Anlauf
Wenn das JSON fast stimmt, ist Reparieren schneller als neu generieren. Der Reparaturauftrag sollte sehr eng sein: Eingabe = fehlerhaftes JSON, Ausgabe = korrigiertes JSON, ohne neue Inhalte zu erfinden.
Praktische Formulierung: „Korrigiere ausschließlich Syntax und Keys, ändere keine Werte, füge keine Felder hinzu.“ Das verhindert, dass das Modell beim Fix „kreativ“ wird.
So wird JSON in echten Workflows stabil (ChatGPT, Claude, Gemini & Co.)
Wenn mehrere Tools beteiligt sind: vorher normalisieren
In der Praxis wandert JSON oft durch mehrere Stationen: KI → Automation → Datenbank → CMS. Jede Station kann strenger sein als die vorherige. Deshalb lohnt sich eine Normalisierungsstufe: erst prüfen, dann speichern, dann weiterleiten. Wer tiefer in wiederholbare Outputs einsteigen will, findet passende Ansätze in KI-Output standardisieren – Vorlagen für klare Ergebnisse.
Weniger Felder, mehr Zuverlässigkeit
Viele JSON-Probleme entstehen durch zu ambitionierte Strukturen: verschachtelte Objekte, gemischte Typen, optionale Unterfelder. Besser ist ein iterativer Aufbau:
- Version 1: flache Struktur, wenige Pflichtfelder.
- Version 2: zusätzliche Felder, aber weiterhin flach.
- Version 3: erst dann Verschachtelung, wenn es wirklich nötig ist.
Modellwechsel einplanen, ohne alles neu zu bauen
Je nach Anbieter und Modell kann die Format-Treue variieren. Deshalb sollte der Prompt nicht auf „Tricks“ basieren, sondern auf klaren Regeln. Wenn ein Modell-Update den Stil ändert, muss das JSON trotzdem gültig bleiben. Sinnvoll ist hier eine klare Trennung aus: (1) Schema, (2) Inhalt, (3) Validierung. Passend dazu: KI-Model-Updates verstehen – Qualität, Stil und Risiken steuern.
Mini-Ablauf fĂĽr den Alltag: von Text zu sauberem JSON
Dieser Ablauf funktioniert fĂĽr viele typische Aufgaben: Briefings, Produktdaten, Content-Planung, Support-Tickets oder Meeting-Notizen.
- Schema-Validierung: Keys, Typen und Pflichtfelder vorab festlegen.
- Prompt in zwei Teile trennen: erst Regeln, dann Eingabedaten.
- Output direkt prĂĽfen: Syntax, Keys, Typen, Pflichtfelder.
- Wenn nötig: Reparatur-Prompt mit „nur korrigieren, nicht erweitern“.
- Erst nach bestandener PrĂĽfung in Automationen ĂĽbernehmen.
Häufige Fragen aus der Praxis: das lässt sich schnell klären
Was ist besser: JSON als Objekt oder als Array?
FĂĽr einzelne Ergebnisse ist ein Objekt meist einfacher. FĂĽr Listen (z. B. mehrere Aufgaben, mehrere Produkte) ist ein Array sinnvoll. Wenn beides vorkommt, hilft eine klare Top-Level-Struktur, zum Beispiel: { „items“: [ … ] }, statt direkt ein Array ohne HĂĽlle auszugeben. Das ist in vielen APIs leichter zu versionieren.
Warum tauchen manchmal zusätzliche Felder auf?
Modelle ergänzen gern „hilfreiche“ Felder. Dagegen hilft eine harte Regel: „Nutze exakt diese Keys; keine weiteren.“ Außerdem sollte im Schema stehen, wie mit Unsicherheit umzugehen ist (z. B. leere Arrays), damit das Modell weniger Anlass hat, zu improvisieren.
Wie bleibt der Output stabil, wenn sich Anforderungen ändern?
Am besten mit Versionierung: Das Schema bekommt eine Versionsnummer als Feld, zum Beispiel schema_version. Dann können Automationen je Version reagieren. Das Feld sollte nur genutzt werden, wenn es wirklich gebraucht wird – ansonsten steigt die Komplexität unnötig.
Wer JSON in Teams einführt, profitiert zusätzlich von klaren Regeln rund um Freigaben und Verantwortlichkeiten, damit nicht jeder Prompt anders aussieht. Dazu passt: KI-Zusammenarbeit im Team – Rollen, Regeln, Freigaben.
Wann lohnt sich ein strengeres Schutzkonzept?
Sobald JSON nicht nur „ausgegeben“, sondern als Eingabe für weitere KI-Schritte genutzt wird (z. B. Agenten-Workflows), steigt das Risiko für Manipulation durch eingeschleuste Instruktionen. Dann sind zusätzliche Schutzmaßnahmen sinnvoll, etwa Input-Regeln und Tests. Ein guter Einstieg dazu: Prompt-Injection verhindern – Schutz, Tests, Guardrails.
Parsing-Fehler sind kein Zeichen „schlechter KI“, sondern ein Hinweis auf fehlende Prozessschritte: Schema definieren, Ausgabe einschränken, prüfen, reparieren. Mit dieser Routine wird JSON von einer Fehlerquelle zu einem zuverlässigen Baustein für produktive KI-Workflows.
