Wie diese Seite zu lesen ist
Die folgenden Fehler sind die Fehlermodi, die immer wieder auftreten, wenn Teams von Playground Experimenten zu produktiven Prompts übergehen. Keiner ist exotisch. Alle sind leicht zu beheben, sobald sie erkannt sind. Diese Seite als Checkliste nutzen, wenn ein Prompt schlechte Ausgaben produziert: von oben nach unten durchgehen und jeden Fehler ausschließen, bevor zu einer komplexeren Technik gegriffen wird.
Vage Anweisungen
Das häufigste Versagen. Der Prompt fragt nach etwas Generischem, das Modell produziert etwas Generisches, der Autor ist enttäuscht.
Schlecht
Mach diese E Mail besser.
Besser
Schreibe die E Mail unten so um, dass sie 30 Prozent kürzer ist, in der zweiten
Person, mit der Kernbitte im ersten Satz und einem klaren nächsten Schritt am Ende.
E Mail:
{email}
Negative Anweisungen ohne positiven Ersatz
Negative Anweisungen sagen, was das Modell nicht tun soll. Das Modell muss das verbotene Verhalten imaginieren, um es zu vermeiden, was manchmal genau zu diesem Verhalten führt. Wo möglich, Negation durch positive Richtung ersetzen.
Schwach
Sei nicht zu formell. Verwende keinen Jargon. Sei nicht langweilig.
Stark
Verwende einen umgangssprachlichen Ton, klares Deutsch und kurze Sätze. Beginne mit
einem konkreten greifbaren Nutzen.
Zu viele Regeln stapeln
Ein Prompt mit dreißig Bullet Points an Regeln ist selten besser als einer mit den fünf wichtigsten. Ab einer bestimmten Länge beginnt das Modell, Regeln als dekorativ statt verbindlich zu behandeln.
Wenn ein Prompt über die Zeit Regeln gesammelt hat, auditieren. Verwandte Regeln gruppieren, redundante streichen und den Rest nach Wichtigkeit sortieren. Die obersten drei nach vorne ziehen und akzeptieren, dass der Rest meistens, aber nicht immer hält.
Eine nützliche Diagnose: Wenn die Absicht des Prompts nicht in einem Satz beschrieben werden kann, ist der Prompt überwuchert. Refaktorieren, bevor weiter hinzugefügt wird.
Widersprüchliche Regeln
Schlimmer als zu viele Regeln: Regeln, die sich widersprechen. Das Modell wählt eine, manchmal inkonsistent, und der Autor kann nicht diagnostizieren, warum.
Konflikt
Sei prägnant. Erkläre jeden Schritt ausführlich. Verwende Stichpunkte, wo
angemessen. Schreibe stets in Fließtext.
Über Engineering
Das andere Extrem zum Stapeln zu vieler Regeln: ein 2000 Token System Prompt für eine Aufgabe, die 200 braucht. Moderne Modelle sind sehr fähig; ein fokussierter kurzer Prompt schlägt häufig einen erschöpfenden langen.
Anzeichen von Über Engineering:
- Der System Prompt hat mehr als zehn separate Abschnitte.
- Dieselbe Anweisung erscheint in drei verschiedenen Formen.
- Es gibt Regeln für Fälle, die noch nie aufgetreten sind.
- Der Prompt wurde oft bearbeitet und nie vereinfacht.
Lösung: Den Prompt von Grund auf neu schreiben und nur die Regeln behalten, deren Notwendigkeit belegbar ist. Wenn keine konkrete Fehlfunktion benannt werden kann, die eine Regel verhindert, ist die Regel wahrscheinlich Lärm. Mit dem kleinsten Prompt starten, der die Evals besteht, und nur dann Blöcke hinzufügen, wenn sie einen gemessenen Fehlermodus beheben.
Anweisungen und Daten vermischen
Wenn User Eingaben ohne klare Trennzeichen in den Prompt verkettet werden, behandelt das Modell die Eingabe manchmal als zusätzliche Anweisung. Die Ausgabequalität leidet, und der Prompt ist auch anfällig für Prompt Injection, bei der ein böswilliger User Befehle in seine Eingabe einbettet.
Schlecht
Fasse diesen Artikel zusammen: {artikel}
Gut
Fasse den Artikel innerhalb der <article> Tags unten zusammen.
<article>
{artikel}
</article>
Few Shot Beispiele, die den Anweisungen widersprechen
Wenn der Prompt eines sagt und die Beispiele etwas anderes zeigen, gewinnen die Beispiele. Modelle folgen den Mustern in Beispielen verlässlicher als den Regeln in Prosa, was genau der Grund ist, warum Few Shot so stark ist und warum schlechte Beispiele so destruktiv sind.
Wenn die Anweisungen „antworte in formellem Deutsch“ sagen und eines der drei Beispiele Verkürzungen verwendet, wird die Hälfte der Ausgaben Verkürzungen verwenden. Beispiele bei jeder Änderung der Anweisungen mit auditieren.
Eine besondere Variante: Beispiele, die alle eine irrelevante Eigenschaft teilen. Wenn alle drei Few Shot Beispiele Kundennamen mit A nutzen, übernimmt das Modell dieses Muster manchmal und wendet es an. Beispiele auf jeder Dimension variieren, die nicht zählen sollte.
Few Shot bei Reasoning Aufgaben
Few Shot ist hervorragend für Klassifikation und Formatierung. Es ist oft kontraproduktiv für Mathematik, Logik und mehrstufiges Reasoning. Die Beispiele lenken das Modell darauf, dem Oberflächenmuster der gezeigten Argumentation zu folgen, statt frisch aus der neuen Eingabe zu denken.
Für Reasoning Aufgaben Zero Shot mit explizitem Chain of Thought bevorzugen. „Let’s think step by step“ oder eine strukturierte Anweisung „erkläre zuerst dein Reasoning, dann nenne die Antwort“ schlägt die meisten Few Shot Reasoning Prompts auf den neuesten Modellen.
Nach unprüfbarer Confidence fragen
Ein Prompt, der „wie sicher bist du?“ fragt, ohne die Confidence in etwas Konkretem zu verankern, produziert Rauschen. Das Modell sagt „hoch“ oder „85 Prozent“ ohne reale Grundlage.
Schwach
Bewerte deine Confidence in der obigen Antwort von 1 bis 100.
Stärker
Bewerte deine Confidence auf einer Skala von 1 bis 5, wobei 5 bedeutet, dass die
Antwort direkt aus der Quelle zitiert ist, 4, dass sie eng paraphrasiert ist, 3, dass
sie aus der Quelle inferiert ist, 2, dass sie teilweise gestützt ist, und 1, dass sie
nicht gestützt ist.
Temperature als Qualitätsregler behandeln
Temperature steuert Varianz, nicht Qualität. Für faktische Aufgaben produziert höhere Temperature mehr Halluzinationen, nicht mehr Kreativität. Für kreative Aufgaben produziert sehr niedrige Temperature vorhersehbare langweilige Ausgaben. Der Trade Off ist aufgabenspezifisch und keine generelle „gut gegen schlecht“ Achse.
Standardmäßig Temperature 0 für alles, was eine einzige korrekte Antwort hat, und nur dann erhöhen, wenn die Aufgabe von Varianz profitiert: Alternativen entwerfen, brainstormen, Tonalitäten erkunden.
Vergessen, dass Prompts versionierte Artefakte sind
Ein Prompt, der sechs Monate lang in einer einzigen Datei in Produktion lebt, ist ein Prompt, den niemand gegen das aktuelle Modell getestet hat. Modelle aktualisieren sich, Evals driften, und was im März funktionierte, funktioniert im September vielleicht nicht.
Prompts wie Code behandeln: in Version Control halten, Tests dafür schreiben und die Tests bei einem Modellwechsel erneut laufen lassen. Die meisten produktiven Prompts durchlaufen drei bis vier größere Überarbeitungen, bis sie stabil sind, und brauchen dann alle paar Monate leichte Pflege, wenn das zugrundeliegende Modell sich verbessert. In PANTA OS wird jede Änderung am System Prompt eines Assistenten automatisch versioniert, sodass der Rückwärtsschritt immer verfügbar bleibt.
Was als Nächstes kommt
Die nächste Seite, Muster und Vorlagen, liefert wiederverwendbare Skelette für die wiederkehrenden Aufgaben: Klassifikation, Extraktion, Zusammenfassung, Drafting, Transformation. Sie ist als Referenz beim Start eines neuen Prompts gedacht.Zuletzt geändert am 18. Mai 2026
