Warum Struktur zählt
Je länger ein Prompt wird, desto wichtiger wird seine Struktur. Ein 200 Token Prompt kann unstrukturiert sein und trotzdem funktionieren. Ein 2000 Token Prompt mit gemischten Anweisungen, Kontext, Beispielen und Eingaben wird fast garantiert schlechtere Ergebnisse liefern, sofern seine Teile nicht klar abgegrenzt sind.
Struktur leistet drei Dinge gleichzeitig. Sie macht den Prompt parsbar für das Modell, sodass es Anweisungen von Daten unterscheiden kann. Sie macht den Prompt lesbar für das Team, sodass er über die Zeit gepflegt werden kann. Und sie macht die Ausgabe parsbar für den Code, sodass das Ergebnis verlässlich extrahiert werden kann.
In PANTA OS hat jeder Assistent einen System Prompt, der von der hier beschriebenen Struktur profitiert. Je länger der System Prompt, desto wichtiger die Struktur.
XML Tags sind das flexibelste Strukturwerkzeug, weil sie verschachtelt, frei benannt und einfach geparst werden können. Die meisten modernen Modelle wurden umfangreich auf XML markierten Prompts trainiert und reagieren besonders gut darauf.
Es gibt keinen kanonischen Satz von Tag Namen. Namen wählen, die beschreiben, was sie enthalten, und konsistent über die Prompts hinweg verwenden.
<role>
Du bist ein Technical Writer, der API Referenzdokumentation produziert.
</role>
<style_guide>
- Sentence Case für Überschriften.
- Imperativ für Beschreibungen.
- Keine Marketingsprache.
</style_guide>
<input>
{api_specification}
</input>
<task>
Erzeuge Referenzdokumentation für die API in der Eingabe. Für jeden Endpoint die HTTP
Methode, den Pfad, die Parameter und eine Beschreibung von einem Absatz angeben.
</task>
<output_format>
Gib Markdown zurück, mit einer H2 Überschrift pro Endpoint.
</output_format>
- Konsistente Tag Namen verwenden. Wenn etwas einmal
<context> heißt, später nicht <background> nennen. Konsistenz reduziert das Risiko von Fehlinterpretationen.
- Verschachteln, wo die Struktur eine natürliche Hierarchie hat. Mehrere Dokumente in ein
<documents> Tag, jedes als <document> mit einem index Attribut.
- Tags in den Anweisungen namentlich referenzieren. „Anhand des Vertrags in den
<contract> Tags oben identifiziere …“ ist klarer als „Anhand des Vertrags oben identifiziere …“.
JSON Output Verträge
Wenn die Ausgabe von Code geparst wird, gehört das Schema in den Prompt. Es gibt drei Wege, in steigender Verlässlichkeit.
Der erste ist eine prosaische Beschreibung des Schemas:
Gib ein JSON Objekt mit den Schlüsseln „company“ (string), „amount“ (number) und
„due_date“ (ISO 8601 Datumsstring) zurück.
Gib ein JSON Objekt zurück, das diesem Schema entspricht:
{
"company": "string",
"amount": "number",
"due_date": "YYYY-MM-DD"
}
Verwende null für jedes Feld, das aus der Eingabe nicht ermittelt werden kann.
Anatomie eines System Prompts
Der System Prompt ist der Ort für alles, was über die gesamte Konversation hinweg gelten soll: Rolle, Regeln, Constraints, Format Erwartungen. Ein sauberer System Prompt hat etwa sechs Abschnitte, in dieser Reihenfolge:
- Rolle und Identität. Wer der Assistent ist, welche Expertise er hat, mit wem er spricht.
- Kernverantwortungen. Die Aufgaben, die der Assistent ausführen soll.
- Verhaltensregeln. Wie der Assistent kommunizieren soll: Tonalität, Formalität, Länge, Sprache.
- Constraints und Ablehnungen. Was der Assistent nicht tun darf, und was zu tun ist, wenn er gefragt wird.
- Output Format. Das Standardformat für Antworten.
- Beispiele (optional). Zwei oder drei kurze Interaktionen, die die Regeln demonstrieren.
Ein durchgespieltes Beispiel für einen Customer Support Assistenten:
## Rolle und Identität
Du bist der Support Assistent für ACME Software, eine B2B Plattform für Bestandsverwaltung.
Du hilfst Kundinnen und Kunden, Probleme mit dem Produkt zu diagnostizieren und zu lösen.
Du sprichst mit technischer Genauigkeit und vermeidest Fachjargon, wo ein einfaches Wort
ausreicht.
## Kernverantwortungen
- Fragen zur Nutzung des Produkts beantworten.
- Fehlermeldungen diagnostizieren und Lösungen vorschlagen.
- An einen menschlichen Agenten eskalieren, wenn das Problem nach drei Austauschen nicht
gelöst ist.
## Verhaltensregeln
- Antworte in der Sprache der letzten Nachricht.
- Verwende die zweite Person, sprich die Person direkt an.
- Halte Antworten unter 150 Wörtern, außer eine schrittweise Anleitung ist nötig.
- Zitiere den passenden Abschnitt der Dokumentation, wenn vorhanden.
## Constraints
- Erfinde keine Produktfeatures. Bei Unsicherheit ob ein Feature existiert, das offen sagen.
- Diskutiere keine Preise, Verträge oder Roadmap Themen. Diese Fragen an Sales verweisen.
- Wenn eine Person beleidigend wird, das Gespräch höflich beenden und eskalieren.
## Output Format
Reiner Text. Keine Markdown Überschriften. Code oder Befehle in Codeblöcken.
## Beispiele
[zwei kurze Beispielinteraktionen]
Reihenfolge der Elemente
Innerhalb eines Prompts zählt die Reihenfolge mehr, als oft angenommen wird. Recency Bias bei Modellen ist gut dokumentiert: Anweisungen, die ganz am Ende eines Prompts stehen, werden tendenziell zuverlässiger befolgt als Anweisungen in der Mitte.
Einige praktische Leitlinien:
- Rolle und Kernregeln nach oben. Sie definieren den Rahmen.
- Langer Kontext in die Mitte. Dokumente, Transkripte, Beispiele.
- Die unmittelbare Aufgabe ans Ende. „Produziere nun, gegeben das obige Dokument, …“ sollte das Letzte sein, was das Modell vor der Generierung liest.
Bei langen Prompts, die sowohl System Anweisungen als auch User Anweisungen enthalten, kritische Constraints am Anfang und am Ende wiederholen. Die Redundanz ist günstig, der Zuverlässigkeitsgewinn real.
Trennzeichen für Eingaben
Eingaben immer klar abgrenzen. Die häufigsten Optionen, in der Reihenfolge der Bevorzugung:
- XML Tags.
<document>...</document>. Am flexibelsten und über moderne Modelle hinweg am besten unterstützt.
- Triple Backticks.
.... Standard für Code und unstrukturierten Text.
- Triple Quotes.
"""...""". Der klassische Trenner, weiterhin funktional.
- Markdown Überschriften.
# Document gefolgt vom Inhalt. Weniger präzise, aber lesbar.
Die falsche Wahl ist gar kein Trennzeichen. Wenn User Eingaben ohne Trennzeichen direkt in einen Prompt verkettet werden, behandelt das Modell die Eingabe manchmal als zusätzliche Anweisung, was sowohl ein Qualitätsproblem als auch ein Sicherheitsproblem ist (Prompt Injection).
Ein vollständiger strukturierter Prompt
Alles zusammen für eine realistische Aufgabe:
<role>
Du bist Senior Research Analyst und produzierst Executive Summaries für einen
Vorstand. Deine Zielgruppe ist nicht technisch, zeitlich begrenzt und entscheidungsorientiert.
</role>
<task>
Lies den Bericht in den <report> Tags und erstelle eine Executive Summary.
</task>
<style_guide>
- Länge: 250 bis 300 Wörter.
- Beginne mit dem wichtigsten Befund.
- Klares Deutsch. Jede Abkürzung beim ersten Auftreten ausschreiben.
- Wo möglich quantifizieren. „Signifikant“ durch die Zahl ersetzen.
- Keine Wertung. Wiedergeben, was der Bericht sagt, nicht, was du denkst.
</style_guide>
<output_format>
Gib die Antwort in <summary> Tags zurück. Drinnen drei Abschnitte, getrennt durch
Leerzeilen: Headline (ein Satz), Findings (ein Absatz), Implications (ein Absatz).
Die Abschnittsbezeichnungen nicht in die Ausgabe übernehmen.
</output_format>
<report>
{report}
</report>
Erstelle nun die Summary, gemäß Style Guide und Output Format oben.
Was als Nächstes kommt
Eine starke Struktur verhindert die meisten Fehler. Die verbleibenden Fehler, bei denen das Modell selbstbewusste, aber falsche Ausgaben liefert, behandelt Halluzinationen reduzieren.Zuletzt geändert am 18. Mai 2026
