Prompt Engineering — vom Trial-and-Error zum Pattern-Katalog

Warum Prompt Engineering eine Disziplin ist

Mit dem produktiven Einsatz von Large Language Models (LLMs) hat sich eine neue Schnittstelle in der Softwareentwicklung etabliert: natürliche Sprache. Anders als bei klassischen APIs gibt es keinen festen Syntax-Kontrakt — derselbe Sachverhalt lässt sich auf hunderte Arten formulieren, und kleine Änderungen im Wortlaut führen zu großen Unterschieden im Ergebnis.

Genau darin liegt der Reiz und das Problem zugleich. Wer beim Bauen einer Funktion mit einem LLM dreimal anders fragt und dreimal etwas anderes bekommt, hat keine reproduzierbare Lösung, sondern eine Glücksserie. In der Forschung wie in der Industrie ist daher eine eigene Disziplin entstanden: Prompt Engineering — die Kunst, mit dem Wissen über natürliche Sprache so mit einem Sprachmodell zu interagieren, dass das Ergebnis vorhersagbar wird.

In regulierten Branchen kommt eine zweite Ebene dazu: Wo Audits stattfinden, müssen LLM-Antworten nachvollziehbar bleiben. „Wir haben den Bot mal etwas Nettes gefragt" ist kein zulässiges Verfahren. Prompts werden zu Artefakten — versioniert, dokumentiert, getestet wie Code.

Ein Pattern-Katalog macht aus dieser Disziplin etwas Lehrbares. Was die „Gang of Four" 1994 für Software-Design leistete, leisten heute Veröffentlichungen wie der „Prompt Pattern Catalog" von White et al. (2023) für die Interaktion mit Sprachmodellen: wiederverwendbare Lösungen für wiederkehrende Probleme, in einer gemeinsamen Sprache beschrieben.

Anatomie eines Prompt Pattern

Ein Prompt Pattern folgt einem klaren Aufbau — angelehnt an die Design-Patterns aus der Software-Entwicklung. Sechs Elemente reichen, um es lehr- und teilbar zu machen:

• Name — der Pattern-Bezeichner, der bereits die Aufgabe verrät und in Reviews als geteiltes Vokabular dient.
• Kontext — die Domäne oder das Problem, auf das sich das Pattern bezieht; bewusst domänen­unabhängig formuliert.
• Motivation — welches Problem das Pattern löst und warum es nützt.
• Struktur und Schlüsseltechnik — wie dem Modell die relevanten Informationen übermittelt werden, oft mit Formulierungs­bausteinen.
• Beispiel — ein konkreter Beispiel-Prompt, der das Pattern in Aktion zeigt.
• Ergebnisse — Vor- und Nachteile sowie Anpassungs­möglichkeiten an verschiedene Aufgaben.

Der Charme dieser Form liegt im geteilten Vokabular. Wenn ein Team „Persona-Pattern" oder „Cognitive Verifier" sagt, wissen alle, was gemeint ist, ohne dass es wiederholt erklärt werden muss — wie bei „Strategy" oder „Observer" im klassischen objektorientierten Code. Reviews werden kürzer, Onboarding schneller, Wissen weniger personenabhängig.

Die fünf Kategorien

Der Katalog ordnet die Patterns in fünf Kategorien, die zugleich Phasen einer LLM-Interaktion abbilden — von der Frage über die Antwort bis zur Validierung.

1. Eingabesemantik — wie die Eingabe verstanden oder umformuliert wird, etwa durch eine Meta-Sprache, die Strukturen verdichtet.
2. Ausgabeanpassung — wie die Antwort eingeschränkt oder strukturiert wird: bestimmte Formate, Personae, Templates, Schritt-für-Schritt-Anleitungen.
3. Fehleridentifikation — wie sich Fehler in der Ausgabe finden und beheben lassen, etwa durch Faktenlisten oder die Aufforderung zur Selbstbegründung.
4. Prompt-Verbesserung — wie die Eingangsfrage selbst durch das Modell besser gemacht wird, etwa durch Rückfragen oder Alternativ­vorschläge.
5. Interaktion — wie der Dialog zwischen Anwender und Modell gestaltet wird: Modell als Frager, Spiel, unendliche Generierung.

Die Kategorisierung hilft beim Auswählen. Wer ein konkretes Problem hat — etwa „die Antwort halluziniert Fakten" — findet schnell die zuständige Kategorie (Fehleridentifikation) und die passenden Patterns (Fact Check List, Reflection). Die Reihenfolge im Katalog ist nicht hierarchisch, sondern dient als Landkarte.

Sechzehn Patterns im Überblick

Der Katalog umfasst insgesamt sechzehn Patterns. Wir greifen die wichtigsten heraus — die in unseren Projekten regelmäßig den Unterschied machen — und nennen die übrigen zur Vollständigkeit.

Persona — das Modell schlüpft in eine Rolle

Vielleicht das bekannteste Pattern. Indem das Modell eine definierte Rolle einnimmt — IT-Sicherheits­expertin, Sachbearbeiter im Bürgeramt, Senior-Architekt — erhalten Antwort, Stilregister und Wissensfokus eine klare Richtung. Beispiel: „Verhalte dich wie eine IT-Sicherheits­expertin und prüfe diesen Code-Review-Vorschlag." Stärke: gezielter Wissensfokus. Schwäche: das Modell halluziniert eher, wenn die Rolle Detailwissen verlangt, das es nicht hat.

Template — Antwort folgt einer vorgegebenen Struktur

Das Modell wird angewiesen, seine Antwort in eine fest definierte Form zu gießen. Besonders nützlich, wenn die Ausgabe maschinell weiterverarbeitet wird: „Ich gebe dir eine Vorlage für deine Ausgabe, wobei X der Platzhalter für den Inhalt ist. Erzeuge ein gültiges JSON-Objekt auf Grundlage von Vor-, Nachname und Adresse." Vorteil: maschinenlesbare Ausgaben. Nachteil: die Struktur dominiert manchmal über inhaltliche Tiefe.

Recipe — die Antwort als nummerierte Schritt-für-Schritt-Anleitung

Wenn das Ziel klar, der Weg aber unbekannt ist. „Ich möchte X erreichen, indem die Schritte A, B, C ausgeführt werden. Erstelle eine vollständige Schritt­sequenz, vervollständige Lücken und entferne überflüssige Schritte." Vorteil: nachvollziehbarer Prozess. Nachteil: das Modell ergänzt manchmal Schritte mit eigenen Annahmen — die Liste lesen, nicht blind übernehmen.

Question Refinement — eine bessere Frage vorschlagen lassen

Wer fragt, gewinnt — wer besser fragt, gewinnt schneller. Pattern: „Wenn ich eine Frage zum Thema X stelle, schlag mir eine bessere Version der Frage vor und frag mich, ob ich stattdessen diese verwenden möchte." Reduziert das klassische Trial-and-Error und führt häufig zu präziseren Folgefragen.

Cognitive Verifier — Frage in Unterfragen zerlegen

Das Pattern zwingt das Modell, eine komplexe Frage in mehrere einfachere zu zerlegen, diese zu beantworten und die Teilantworten zu einer Gesamtantwort zu kombinieren. Beispiel: „Wenn ich dir eine Frage stelle, erzeuge drei zusätzliche Fragen, die helfen, die Eingangsfrage besser zu beantworten. Wenn ich die drei zusätzlichen Fragen beantwortet habe, kombiniere die Antworten und erzeuge eine Ausgabe für meine Eingangsfrage." Vorteil: durchdachte Antworten bei komplexen Themen. Nachteil: die Unterfragen sind nicht immer beantwortbar.

Fact Check List — Faktenliste zur Überprüfung

Das Modell wird aufgefordert, am Ende der Antwort eine Liste der Fakten beizulegen, auf denen seine Ausgabe beruht. Diese Liste lässt sich anschließend einzeln prüfen — der wirksamste Hebel gegen Halluzinationen, sehr gut kombinierbar mit Question Refinement und Persona.

Reflection — Erklärung der Begründung

Das Modell soll erklären, warum es so geantwortet hat. „Bei jeder Antwort von dir erklärst du mir bitte die Gründe und Annahmen, die zu dieser Antwort geführt haben." Vorteil: Überprüfbarkeit für Domänen­expertinnen. Nachteil: das Modell kann Gründe erfinden, die nichts mit dem tatsächlichen Reasoning zu tun haben — Erklärung ist nicht Beweis.

Flipped Interaction — das Modell stellt die Fragen

Bei komplexen Aufgaben weiß das Modell oft nicht genug, um eine sinnvolle Antwort zu geben. Das Pattern dreht den Spieß um: „Ab jetzt stellst du mir Fragen zur Bereitstellung einer Python-Anwendung auf AWS. Wenn genügend Informationen vorhanden sind, erstelle ein Python-Skript." Das Modell führt das Gespräch, bis genug Kontext da ist. Resultat: deutlich höhere Trefferquote bei mehrdeutigen Aufgaben.

Meta Language Creation — eine Mini-Sprache für das Problem

Wenn die Domäne eine natürliche Notation hat, lohnt es sich, das Modell darauf zu eichen. „2B,4N bezeichnet Benutzer­namen mit zwei zufälligen Buchstaben gefolgt von vier zufälligen Zahlen. Generiere zehn Benutzer­namen." Spart Beschreibungs­aufwand und reduziert Mehrdeutigkeiten — vorausgesetzt, die Notation ist eindeutig dokumentiert.

Weitere im Katalog

Daneben definiert der Katalog Patterns für Output Automater (das LLM erzeugt ein Skript, das Aufgaben automatisiert), Visualization Generator (Ausgabe, die ein Grafik-Tool wie Graphviz oder DALL·E weiterverarbeitet), Game Play (das Modell erzeugt ein Spiel zum gewählten Thema), Infinite Generation (unendliche Ausgaben ohne erneutes Prompten — gut für Testdaten), Alternative Approach (das Modell schlägt alternative Lösungswege vor), Refusal Breaker (Umformulierung gegen Filterregeln — mit klaren ethischen Vorzeichen, hohes Missbrauchs­potenzial), Context Manager (Eingrenzung oder Erweiterung des Themenfokus). Sechzehn Patterns insgesamt — kein Pflichtwerk, sondern ein Werkzeugkasten, aus dem situativ gewählt wird.

Kombination und iterativer Prozess

Patterns sind wirksam, aber wirklich gut werden sie erst in Kombination. Drei besonders häufige Verbindungen aus der Projektpraxis:

• Persona + Cognitive Verifier — „Verhalte dich wie ein Senior-Architekt. Wenn ich dir eine Frage stelle, erzeuge drei Unterfragen, beantworte sie und kombiniere die Antworten." Resultat: tiefergehende Antworten mit einer fachlichen Stimme.
• Template + Fact Check List — strukturierte JSON-Ausgabe mit angehängter Faktenliste. Maschinenlesbar und prüfbar — die Grundlage für jeden Audit-Prozess.
• Flipped Interaction + Recipe — das Modell stellt Fragen, bis genug Kontext da ist, und liefert dann eine durchnummerierte Anleitung. Funktioniert besonders gut für komplexe Setup-Aufgaben.

Wichtig ist: Prompt Engineering ist iterativ. Selten ist der erste Wurf der finale. Der Zyklus läuft typischerweise so:

1. Idee

   Eine Aufgabe, die mit einem LLM gelöst werden soll — vom Antrags­assistenten bis zur Code-Review-Hilfe. Klarheit über das gewünschte Ergebnis ist der erste Schritt, nicht die Wahl des Modells.

2. Implementierung

   Ein erster Prompt, basierend auf passenden Patterns. Hier zeigt sich der Wert eines Katalogs: statt vom leeren Blatt zu starten, kombiniert man bekannte Bausteine.

3. Analyse der Ausgabe

   Beantwortet das Modell tatsächlich die Eingangsfrage? Gibt es Halluzinationen, Format-Fehler, Auslassungen, unerwünschte Höflichkeitsfloskeln? An dieser Stelle steht häufig der größte Teil der Arbeit.

4. Verbesserung

   Pattern austauschen, Reihenfolge anpassen, Beispiele ergänzen, Constraints schärfen. Zurück zu Schritt 2. Drei bis fünf Iterationen sind normal, bis ein Prompt produktionsreif ist.

Was reift, wird versioniert — als Artefakt im Repository, mit Tests, die seine Ausgabe­qualität gegen frühere Versionen prüfen. Dasselbe Disziplin-Niveau wie bei Code.

Empfehlung — wie wir Patterns in Projekten einsetzen

Drei Beobachtungen aus der Projektpraxis, die den Unterschied zwischen „kennen" und „wirksam einsetzen" markieren.

• Patterns im Team einführen, nicht im stillen Kämmerlein. Der Wert eines Pattern-Katalogs entsteht durch das geteilte Vokabular. Wenn drei Entwicklerinnen drei verschiedene Namen für dasselbe Pattern verwenden, ist der Wert weg. Ein gemeinsamer Glossar-Eintrag und ein, zwei Beispiele im Wiki sind oft mehr wert als ein dickes Konzept.
• Prompts sind Artefakte, keine Wegwerf-Eingaben. Wer LLM-basierte Funktionen produktiv schaltet, behandelt Prompts wie Code: versioniert im Repository, mit Tests, mit Code-Reviews. Was reift, schickt man nicht jedes Mal neu raus — und veröffentlicht es nicht ungeprüft in einer Produktivumgebung.
• Patterns ergänzen, sie ersetzen nicht. Threat Modeling, Datenschutz-Bewertung, Halluzinations-Tests bleiben separate Pflichten. Ein hübsches Persona-Pattern macht keine Output-Qualität, wenn niemand prüft, ob die Ausgabe stimmt.