Zum Hauptinhalt springen

​
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.
Die Lösung ist immer dieselbe: Adjektive durch Attribute ersetzen. „Besser“ wird zu „kürzer, zweite Person, eine klare Bitte, ein klarer nächster Schritt“. Das Modell kann auf Attribute reagieren; auf ein Gefühl nicht.

​
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.
Es gibt Ausnahmen. Manche Constraints sind genuin negativ, etwa „erfinde keine Statistiken“ oder „nenne keine konkreten Personen“. Diese bleiben. Die Regel: Positiv bevorzugen, wenn beide Formen verfügbar sind, und wenn ein Constraint negativ sein muss, wo möglich einen positiven Ersatz nachschieben.

​
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.
Das Modell kann nicht alle vier erfüllen. Es wählt diejenige, die am aktuellsten oder am spezifischsten ist, was bedeutet, dass die Ausgabe je nach übrigem Kontext driftet. Lösung: aus jedem Paar eine entfernen, entweder prägnant oder ausführlich, entweder Bullets oder Fließtext. Konflikte schleichen sich leicht ein, wenn Prompts über die Zeit von mehreren Personen bearbeitet werden. Deshalb sollte jede Änderung am System Prompt eines PANTA OS Assistenten vor der Veröffentlichung end to end gelesen werden, gezielt auf Widersprüche.

​
Ü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.
XML Tags, Triple Backticks oder Triple Quotes funktionieren alle. Die falsche Wahl ist gar kein Trennzeichen.

​
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.
Die stärkere Version verankert jede Stufe in beobachtbaren Kriterien. Das Modell kann die Kriterien anwenden; es kann nicht sinnvoll auf einer kontinuierlichen Wahrscheinlichkeitsskala introspektieren.

​
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