Prompt Engineering bezeichnet das gezielte Formulieren und Strukturieren der Eingabe an ein Sprachmodell mit dem Ziel, verlässlichere und besser verwertbare Ergebnisse zu erhalten. Der Begriff klingt nach Textarbeit, ist in produktiven Systemen aber näher an Softwareentwicklung: Ein Prompt ist dort keine Nachricht, sondern eine Komponente mit definierter Ein- und Ausgabe, die versioniert, getestet und überwacht wird.
Die Bestandteile eines belastbaren Prompts
Ein Prompt, der in einem Produkt zuverlässig arbeiten soll, besteht typischerweise aus mehreren Teilen. Die Rollen- oder Aufgabenbeschreibung legt fest, was das Modell tun soll. Der Kontext liefert die Informationen, auf denen es arbeitet. Beispiele zeigen die gewünschte Form am konkreten Fall. Formatvorgaben legen die Struktur der Antwort fest, was besonders zählt, wenn das Ergebnis maschinell weiterverarbeitet wird. Und Abgrenzungen benennen, was ausdrücklich nicht getan werden soll. Diese Bestandteile lassen sich unabhängig voneinander verbessern, was Prompt-Arbeit systematisch statt intuitiv macht.
Warum Beispiele mehr bewirken als Anweisungen
Die wirksamste einzelne Verbesserung an den meisten Prompts ist nicht eine präzisere Anweisung, sondern ein Beispiel. Modelle lernen die gewünschte Form aus Demonstration deutlich zuverlässiger als aus Beschreibung — dieses Vorgehen wird als Few-Shot-Prompting bezeichnet. Ein einziges gutes Beispiel ersetzt oft mehrere Absätze Anweisung. Wichtig ist dabei, dass die Beispiele die schwierigen Fälle abdecken und nicht die einfachen: Ein Beispiel, das den Normalfall zeigt, verbessert wenig, weil der Normalfall ohnehin funktioniert.
Systemprompt und Nutzerprompt
In den meisten Schnittstellen wird zwischen einer übergeordneten Anweisung und der eigentlichen Nutzereingabe unterschieden. Die übergeordnete Anweisung enthält das Stabile: Rolle, Regeln, Format, Abgrenzungen. Die Nutzereingabe enthält das Variable. Diese Trennung ist keine Formalität, sondern der Grund, warum ein System vorhersagbar bleibt: Was im stabilen Teil steht, gilt für jede Anfrage gleich, und Änderungen daran sind ein bewusster Eingriff statt einer Nebenwirkung.
Der Unterschied zwischen Demo und Produktion
Ein Prompt, der im Chat gut funktioniert, ist noch kein produktionstauglicher Prompt. Im Chat korrigiert ein Mensch sofort, wenn etwas schiefgeht. In einem Produkt gibt es diese Korrektur nicht — der Prompt muss auch bei ungewöhnlichen, unvollständigen oder böswilligen Eingaben ein brauchbares Ergebnis liefern oder sauber scheitern. Der Sprung von der Demo zur Produktion besteht deshalb überwiegend aus der Arbeit an Randfällen, nicht aus der Verbesserung des Normalfalls.
Evaluation statt Bauchgefühl
Weil ein Prompt eine Komponente ist, gehört zu ihm eine Testmenge. Ohne sie ist jede Änderung ein Blindflug: Eine Formulierung, die einen Fall verbessert, kann drei andere verschlechtern, und ohne systematische Prüfung merkt das niemand. Eine kleine, aber sorgfältig zusammengestellte Sammlung von Eingaben mit erwarteten Eigenschaften der Ausgabe ist der Unterschied zwischen Prompt-Arbeit und Prompt-Raten.
Die Grenzen der Methode
Prompt Engineering löst nicht jedes Problem, und die Grenze zu kennen erspart viel verlorene Zeit. Fehlt dem Modell die nötige Information, hilft keine Formulierung — dann braucht es Kontext aus einer Wissensquelle. Ist die Aufgabe grundsätzlich zu komplex für einen Schritt, hilft ebenfalls keine Formulierung, sondern eine Zerlegung in mehrere Schritte. Und wo eine Ausgabe garantiert einem festen Schema entsprechen muss, ist eine technische Durchsetzung der Struktur verlässlicher als eine Bitte im Prompt.
Was daraus folgt
Wer Prompts in einem Produkt einsetzt, behandelt sie wie Code: versioniert, mit Testmenge, mit klarer Trennung zwischen stabilem und variablem Teil, und mit Überwachung im Betrieb. Wer sie wie Text behandelt, bekommt ein System, das gestern funktionierte und heute nicht mehr, ohne dass jemand sagen kann, warum.
