Prompt Engineering für Entwickler: Technik statt Trickliste
Prompt Engineering für Entwickler: Technik statt Trickliste
Artikel-Übersicht
Die meisten Anleitungen zu Prompt Engineering sammeln Formulierungen: sag „du bist ein Experte für…", schreib „denke Schritt für Schritt", bitte höflich. Das ist nicht falsch, aber es hilft niemandem, der mit einem Modell etwas baut, das morgen noch funktionieren soll. Dieser Artikel behandelt das Thema als Entwicklungsdisziplin. Er beginnt mit einer Definition, die den Unterschied setzt, zeigt die fünf Bestandteile eines belastbaren Prompts und liefert eine Techniktabelle mit einer Spalte, die in keiner anderen Übersicht steht — was die Technik an Tokens und Latenz kostet. Danach folgen drei Vorher-Nachher-Paare aus echten Entwicklungsaufgaben und der Kern des Artikels: Ein Prompt ist Code. Er gehört ins Repository, wird versioniert, bekommt Testfälle und eine Kennzahl. Zum Schluss die Unterschiede zwischen den Anbietern, die Besonderheiten kleinerer lokaler Modelle und die ehrliche Grenze, ab der kein Prompt mehr hilft.
Was Prompt Engineering ist
Prompt Engineering ist die systematische Gestaltung von Modelleingaben mit dem Ziel, reproduzierbare Ausgaben zu erhalten. Nicht: die richtige Zauberformel finden. Sondern: eine Spezifikation schreiben, die ein Sprachmodell zuverlässig genug umsetzt, dass man darauf ein System bauen kann.
Der Unterschied ist nicht akademisch. Wer eine Formulierung sucht, die diesmal funktioniert, hat ein Ergebnis. Wer eine Eingabe baut, die über hundert verschiedene Fälle hinweg dasselbe Format liefert, hat eine Komponente.
Und daraus folgt der rote Faden dieses Artikels: Alles, was hier steht, zielt auf Wiederholbarkeit. Eine Technik, die die Trefferquote von 70 auf 85 Prozent hebt, ist wertvoll. Eine Formulierung, die einmal eine besonders schöne Antwort erzeugt hat, ist es nicht.
Der Aufbau eines belastbaren Prompts
Ein Prompt, der in einem System läuft, besteht aus fünf Teilen. Nicht jeder ist immer nötig, aber wenn etwas nicht funktioniert, fehlt fast immer einer davon.
1. Rolle und Kontext. Wer spricht, in welcher Situation. Das ist der Teil, den die Ratgeber überbetonen — er hilft, aber weniger als gedacht. Nützlich ist er vor allem, um den Ton und das Fachvokabular festzulegen.
2. Die Aufgabe. Was genau getan werden soll, in einem Satz, im Imperativ. „Extrahiere die Rechnungsnummer" ist eine Aufgabe. „Hilf mir mit dieser Rechnung" ist keine.
3. Die Eingabedaten. Klar abgegrenzt vom Rest, am besten durch Auszeichnung. Das ist wichtiger, als es aussieht: Ein Modell unterscheidet nicht zuverlässig zwischen deiner Anweisung und dem, was im übergebenen Dokument steht. Eine deutliche Grenze reduziert das Problem — beseitigen kann sie es nicht.
4. Das Ausgabeformat. Der wichtigste Teil, und der, den Tricklisten auslassen. Ein Prompt ohne Formatvorgabe erzeugt Fließtext, und Fließtext lässt sich nicht maschinell weiterverarbeiten. Wer JSON braucht, verlangt JSON — und erzwingt es besser über ein Schema als über eine Bitte. Wie das geht, steht in Structured Output und JSON-Mode bei LLMs.
5. Abgrenzungen. Was nicht getan werden soll, und was passieren soll, wenn die Aufgabe nicht lösbar ist. Der zweite Punkt fehlt fast immer: Ein Modell, dem niemand gesagt hat, was es bei fehlender Information tun soll, erfindet etwas.
Ein Beispiel, das alle fünf zeigt:
Du bist ein Assistent für die Rechnungsverarbeitung eines Handwerksbetriebs.
Extrahiere aus dem folgenden Rechnungstext die Rechnungsnummer,
das Rechnungsdatum und den Bruttobetrag.
<rechnung>
{text}
</rechnung>
Antworte ausschließlich mit einem JSON-Objekt mit den Feldern
"rechnungsnummer" (String), "datum" (ISO-8601) und "brutto" (Zahl).
Wenn ein Feld im Text nicht eindeutig zu finden ist, setze es auf null.
Rate nicht und ergänze keine Felder.Der letzte Absatz ist der, der aus einem Spielzeug ein Werkzeug macht.
Die Techniken, die messbar wirken
| Technik | Was sie bewirkt | Wann sinnvoll | Kosten |
|---|---|---|---|
| Ausgabeschema erzwingen | maschinenlesbare Antworten, keine Formatabweichungen | immer, wenn weiterverarbeitet wird | keine nennenswerten |
| Few-Shot (Beispiele mitgeben) | zeigt das gewünschte Format und die Randfälle | bei Klassifikation und Extraktion | Eingabelänge je Beispiel |
| Chain-of-Thought (schrittweise denken lassen) | bessere Ergebnisse bei mehrstufigen Aufgaben | Rechnen, Herleitungen, Regelwerke | Ausgabelänge vervielfacht sich |
| Rollenzuweisung | Ton und Fachvokabular | wenn der Stil zählt | minimal |
| Negativabgrenzung | verhindert erfundene Felder und Zusätze | bei strukturierter Extraktion | minimal |
| Selbstprüfung (Antwort noch einmal prüfen lassen) | fängt Formatfehler und offensichtliche Fehler | bei hohem Qualitätsanspruch | zweiter Modellaufruf |
| Prompt-Verkettung (Aufgabe in Schritte zerlegen) | jeder Schritt einfacher und prüfbar | bei komplexen Abläufen | mehrere Aufrufe, mehr Latenz |
| Kontextreihenfolge | Wichtiges an Anfang und Ende | bei langen Eingaben | keine |
Die Kostenspalte ist der Grund für diese Tabelle. Chain-of-Thought verdoppelt bis verfünffacht die Ausgabelänge, und Ausgabe-Tokens sind bei allen Anbietern deutlich teurer als Eingabe-Tokens. Few-Shot geht auf die Eingabeseite und ist billiger, kostet aber Kontext. Wer beides gedankenlos kombiniert, hat einen Prompt, der viermal so teuer ist wie nötig — und bei Reasoning-Modellen zusätzlich gegen deren eigene Arbeitsweise arbeitet.
Zur letzten Zeile: Die Position im Kontext ist nicht neutral. Modelle verarbeiten den Anfang und das Ende einer langen Eingabe zuverlässiger als die Mitte. Wer eine Anweisung in die Mitte von zwanzig Seiten Text legt, sollte sich nicht wundern. Mehr dazu in Context Window und lange Kontexte bei LLMs.
Drei Beispiele, die den Unterschied zeigen
Extraktion aus unstrukturiertem Text
Vorher:
Was steht in dieser E-Mail an Terminen?Was schiefgeht: Die Antwort kommt als Fließtext, mal mit Datum, mal mit „nächsten Dienstag", mal mit Erklärung drumherum. Nicht weiterverarbeitbar.
Nachher:
Extrahiere alle Termine aus der E-Mail.
Gib ein JSON-Array zurück. Jeder Eintrag hat "datum" (ISO-8601),
"uhrzeit" (HH:MM oder null) und "anlass" (String).
Relative Angaben wie "nächsten Dienstag" rechnest du ausgehend
vom Sendedatum {sendedatum} um.
Findest du keine Termine, gib ein leeres Array zurück.Der Gewinn liegt nicht in der Höflichkeit, sondern in drei Entscheidungen: festes Format, Umgang mit relativen Angaben festgelegt, Leerfall definiert.
Klassifikation
Vorher:
Ist dieses Support-Ticket dringend?Was schiefgeht: Das Modell hat keinen Maßstab. Es antwortet mal „ja", mal „eher nicht", mal mit einer Begründung. Und es bewertet nach seinem eigenen Verständnis von Dringlichkeit, nicht nach deinem.
Nachher:
Ordne das Ticket genau einer Stufe zu:
- "kritisch": Produktivsystem steht, kein Workaround
- "hoch": Funktion eingeschränkt, Workaround vorhanden
- "normal": Fehler ohne Betriebsbeeinträchtigung
- "niedrig": Frage, Wunsch, Verbesserungsvorschlag
Antworte nur mit der Stufe, ohne Begründung.
<ticket>{text}</ticket>Hier wirkt vor allem eines: Die Kategorien sind definiert, nicht benannt. Ein Modell, das „hoch" von „normal" unterscheiden soll, ohne zu wissen, woran, rät.
Codeerklärung
Vorher:
Erkläre diesen Code.Was schiefgeht: Es kommt eine Zeile-für-Zeile-Paraphrase, die nichts erklärt, was man nicht sieht.
Nachher:
Erkläre den folgenden Code für jemanden, der die Sprache kennt,
aber dieses Projekt nicht.
Beantworte in dieser Reihenfolge:
1. Welches Problem löst diese Funktion? (zwei Sätze)
2. Welche Annahmen macht sie über ihre Eingaben?
3. Welche Randfälle behandelt sie nicht?
Paraphrasiere keine einzelnen Zeilen.
<code>{code}</code>Punkt 3 ist der, für den man solche Prompts überhaupt schreibt — und er kommt nur, wenn man danach fragt.
Ein Prompt ist Code
Hier trennt sich Prompt Engineering von Prompt-Sammeln, und dieser Abschnitt ist der Grund für den Artikel.
Ein Prompt, der in einem System läuft, hat alle Eigenschaften von Quellcode: Er bestimmt Verhalten, er wird geändert, seine Änderungen haben Folgen, und wenn niemand hinschaut, verrottet er. Also behandelt man ihn auch so.
Prompts gehören ins Repository. Nicht in eine Notiz, nicht in ein Wiki, nicht in eine Datenbankzeile ohne Historie. Als Datei, neben dem Code, der sie benutzt. Dann sieht man im Änderungsverlauf, wer wann was daran geändert hat — und warum.
Prompts werden versioniert. Das ist mehr als Dateiversionierung: Wenn du eine laufende Anwendung hast, brauchst du die Möglichkeit, eine Prompt-Version einer Modellversion zuzuordnen. Ein Modellwechsel kann das Verhalten desselben Prompts spürbar ändern — und dann willst du wissen, welche Kombination im Einsatz war.
Prompts brauchen Testfälle. Aber nicht wie Code: Du kannst die exakte Ausgabe nicht vorhersagen, also prüfst du Eigenschaften statt Zeichenketten:
- Ist die Antwort gültiges JSON gegen das erwartete Schema?
- Enthält sie die geforderten Felder?
- Liegt der Wert im erwarteten Bereich?
- Bei Klassifikation: stimmt die Kategorie mit der erwarteten überein?
Ein Testsatz aus dreißig bis fünfzig echten Fällen mit bekannter richtiger Antwort ist der Unterschied zwischen „fühlt sich besser an" und „ist besser".
def test_extraktion():
treffer = 0
for fall in TESTFAELLE:
ergebnis = extrahiere(fall["text"])
if ergebnis == fall["erwartet"]:
treffer += 1
quote = treffer / len(TESTFAELLE)
assert quote >= 0.9, f"Trefferquote auf {quote:.0%} gefallen"Prompts brauchen eine Regressionsprüfung. Immer dann, wenn sich etwas ändert — der Prompt selbst, das Modell, die Modellversion, die Temperatur. Der Testsatz läuft, die Quote wird verglichen. Sinkt sie, wird die Änderung nicht freigegeben.
Der Ablauf ist am Ende derselbe wie bei Code: ändern, testen, vergleichen, freigeben oder verwerfen. Nur die Zusicherung ist eine andere — statt „ist gleich" prüfst du „ist gut genug".
Was sich je Anbieter unterscheidet
Prompts sind nicht vollständig übertragbar. Drei Unterschiede, die im Alltag auffallen:
Die Behandlung des Systemprompts. Manche Modelle gewichten ihn deutlich stärker als andere. Was bei einem Anbieter als feste Regel wirkt, ist beim nächsten eine Empfehlung, die eine gegenteilige Nutzereingabe überschreibt.
Der Umgang mit langen Anweisungen. Ausführliche, strukturierte Systemprompts funktionieren nicht überall gleich gut. Manche Modelle folgen einer langen Liste von Regeln zuverlässig, andere befolgen die ersten drei und vergessen den Rest.
Reasoning-Modelle brauchen andere Prompts. Das ist der wichtigste Punkt dieses Abschnitts. Modelle, die intern schrittweise arbeiten, brauchen keine Chain-of-Thought-Anweisung — sie tun es ohnehin, und die Aufforderung kann das Ergebnis sogar verschlechtern. Was sie stattdessen brauchen, ist eine gute Zielbeschreibung: was ein gutes Ergebnis ausmacht, nicht wie man dorthin kommt. Mehr dazu in Reasoning-Modelle erklärt.
Welche Modelle sich wie verhalten und welches wofür taugt, steht im Vergleich der führenden LLM-Anbieter.
Prompts für lokale Modelle
Kleinere Modelle verzeihen weniger. Vier Regeln, die dort den Unterschied machen:
- Kürzer und expliziter. Ein 8-Milliarden-Modell folgt drei klaren Regeln besser als fünfzehn differenzierten.
- Keine impliziten Annahmen. Was ein großes Modell aus dem Zusammenhang erschließt, muss hier ausgeschrieben werden.
- Format erzwingen statt erbitten. Ein Schema durchsetzen wirkt; „bitte gib JSON zurück" wirkt oft nicht.
- Ein Beispiel schlägt drei Absätze Erklärung. Few-Shot ist bei kleinen Modellen der wirksamste einzelne Hebel.
Den Unterbau dafür beschreibe ich in Ollama: lokale Sprachmodelle betreiben, die Modellauswahl in Welches Ollama-Modell?.
Wo Prompt Engineering aufhört
Nicht jedes Problem ist ein Prompt-Problem. Drei Fälle, in denen weiteres Feilen nichts bringt:
Dem Modell fehlt Wissen. Wenn die Antwort Informationen braucht, die das Modell nicht hat — interne Dokumente, aktuelle Zahlen, firmenspezifische Regeln —, hilft kein Prompt. Das ist der Fall für Retrieval-Augmented Generation.
Das Modell soll sich anders verhalten, nicht mehr wissen. Ein bestimmter Stil, ein festes Format über tausende Fälle, eine Fachsprache: Dafür ist Fine-Tuning das passende Werkzeug — und Prompting der teure Umweg.
Die Aufgabe ist zu schwer für das Modell. Manchmal ist die ehrliche Antwort ein größeres Modell. Das festzustellen kostet einen Testlauf mit dem Testsatz von oben — und ist billiger, als drei Tage am Prompt zu feilen.
Häufige Fragen
Was versteht man unter Prompt Engineering? Die systematische Gestaltung von Modelleingaben mit dem Ziel reproduzierbarer Ausgaben. Nicht das Suchen nach der richtigen Formulierung, sondern das Schreiben einer Spezifikation.
Was ist ein guter Prompt? Einer, der Rolle, Aufgabe, Eingabedaten, Ausgabeformat und Abgrenzungen enthält — und der festlegt, was bei fehlender Information passieren soll.
Was sind Beispiele für Prompts? Drei ausgearbeitete Vorher-Nachher-Paare stehen weiter oben: Terminextraktion, Ticket-Klassifikation und Codeerklärung.
Was ist Prompt-Technik? Die einzelnen Verfahren: Few-Shot, Chain-of-Thought, Schemazwang, Prompt-Verkettung, Selbstprüfung. Jedes hat einen Anwendungsfall und einen Preis in Tokens oder Latenz.
Was macht ein Prompt Engineer? Im engeren Sinn gibt es diese Rolle als eigenständigen Beruf kaum noch — die Tätigkeit ist Teil der Arbeit von Entwicklern geworden, die mit Sprachmodellen bauen. Wer die Stellenbezeichnung sucht, findet sie meist im Umfeld von Datenaufbereitung und Qualitätssicherung für KI-Systeme.
Braucht man eine Weiterbildung oder ein Zertifikat dafür? Es gibt Angebote, aber der Nutzen ist begrenzt. Ein eigener Testsatz und drei durchgemessene Prompt-Iterationen bringen mehr als ein Kurs.
Sollte ich auf Deutsch oder Englisch prompten? Bei großen Modellen macht es für die Qualität kaum einen Unterschied, bei kleineren oft schon — dort sind englische Anweisungen häufig zuverlässiger, auch wenn die Antwort deutsch sein soll. Das ist aber kein Naturgesetz, sondern eine Messung wert: derselbe Testsatz, einmal mit deutscher, einmal mit englischer Anweisung.
Zusammenfassung und praktische Tipps
Prompt Engineering ist keine Sammlung von Formulierungen, sondern eine Entwicklungsdisziplin. Die wichtigsten Punkte:
- Fünf Bestandteile: Rolle, Aufgabe, Eingabedaten, Ausgabeformat, Abgrenzungen. Fehlt etwas, ist es fast immer das Format oder die Regel für den Leerfall.
- Das Ausgabeformat ist der wichtigste Teil, weil es darüber entscheidet, ob die Antwort maschinell weiterverarbeitbar ist.
- Jede Technik hat einen Preis. Chain-of-Thought geht auf die teure Ausgabeseite, Few-Shot auf die Eingabeseite. Beides gedankenlos zu kombinieren kostet ein Vielfaches.
- Ein Prompt ist Code. Er gehört ins Repository, wird versioniert, bekommt Testfälle und eine Kennzahl — und wird bei jedem Modellwechsel neu gemessen.
- Reasoning-Modelle brauchen keine Denkanweisung, sondern eine gute Zielbeschreibung.
- Kleine Modelle brauchen kürzere, explizitere Prompts und profitieren am meisten von Beispielen.
- Wenn Wissen fehlt, hilft RAG. Wenn Verhalten fehlt, hilft Fine-Tuning. Kein Prompt ersetzt beides.
Mein Rat für den Einstieg: Bau als Erstes den Testsatz, nicht den Prompt. Dreißig echte Fälle mit bekannter richtiger Antwort, in einer Datei. Danach ist jede Prompt-Änderung eine Messung statt einer Meinung — und du merkst innerhalb einer Stunde, welche der Techniken aus der Tabelle bei deiner Aufgabe wirklich etwas bringen und welche nur Tokens kosten.
Ressourcen
- Anthropic – Prompt Engineering Guide – Herstellerdokumentation mit belastbaren Empfehlungen
- OpenAI – Prompt Engineering – Gegenstück des anderen großen Anbieters
- Prompting Guide – umfangreiche, englischsprachige Referenz zu einzelnen Techniken
- promptfoo – Werkzeug zum systematischen Testen und Vergleichen von Prompts