Einleitung: Der Unterschied zwischen OK und Grossartig liegt in der Prompt-Qualität
Zwei Automationen mit demselben Modell, derselben Aufgabe und unterschiedlichen Prompts liefern unterschiedlich brauchbare Ergebnisse. Wie Prompts in laufende Abläufe eingebettet werden, gehört zu den Grundlagen der AI Automation; hier geht es ausschliesslich um die Formulierung selbst.
Der Unterschied zwischen einem Prompt, der ständig nachkontrolliert werden muss, und einem, der produktiv laufen kann, ist meist nicht das Modell — beide nutzen GPT-5.6. Der Unterschied ist die Prompt-Qualität.
Diese Seite erklärt, wie man Prompts so schreibt, dass sie:
- Konsistent sind (gleicher Input = gleicher Output jedes Mal)
- Zuverlässig sind (hohe Accuracy mit minimalen Fehlern)
- Effizient sind (schnell zum richtigen Ergebnis)
- Testbar sind (messbare Qualität)
Diese Fähigkeit trennt "experimentelle KI-Spielereien" von "Production-ready Automation".
Was ist Prompt Engineering im Automation-Kontext?
Definition: Die Kunstfertigkeit, LLMs für zuverlässige, automatisierte Aufgaben einzuspannen
Prompt Engineering ist NICHT:
- "Einfach eine Frage an ChatGPT stellen"
- "Ausprobieren bis was funktioniert"
- "Jedes Mal neu schreiben, je nach Tagesform des Modells"
Prompt Engineering IST:
- Systematisch, Regeln-basiert, wiederholbar
- Strukturiert nach bewährten Mustern
- Mit Fallback-Szenarien für Edge Cases
- Getestet gegen echte Daten
Warum ist das wichtig für Automation?
Manuelle Prozesse können tolerant sein: «Normalerweise funktioniert das; wenn nicht, frage ich einen Menschen.»
Automation kann nicht tolerant sein: "Wenn das manchmal nicht funktioniert, ist das eine fehlerhafte Automation."
Mit gutem Prompt Engineering läuft der Grossteil der Fälle ohne Eingriff durch. Mit schlechtem bleibt eine Fehlerquote, die jede Automatisierung wieder zur Handarbeit macht.
Wirtschaftlicher Impact:
- Schlechter Prompt → viele Fälle brauchen manuelle Nachkontrolle → die Ersparnis verschwindet im Review
- Guter Prompt → Nachkontrolle nur bei Ausnahmen → die Automatisierung trägt sich
- Wie gross der Unterschied ausfällt, zeigt erst die gemessene Fehlerquote auf den eigenen Daten
Die Anatomie eines guten Prompts
Ein guter Automation-Prompt hat typischerweise diese Komponenten:
1. Role/Persona
Definiere, in welcher Rolle der LLM handelt.Schwach: "Schreibe eine E-Mail"
Stark: "Du bist ein Senior-Kundenservice-Manager mit 10 Jahren Erfahrung. Du schreibst Antworten auf Kundenreklamationen, die professionell, empathisch und lösungsorientiert sind."
Warum wichtig: Der LLM passt seinen Ton und Niveau an die Rolle an.
2. Context
Gib genug Hintergrund, damit der LLM die Situation versteht.Schwach: "Analysiere diese E-Mail"
Stark: "Du erhältst Customer-Support-E-Mails. Jede E-Mail ist von einem Kunden, der ein Problem mit unserem Produkt hat. Deine Aufgabe ist, das Problem zu klassifizieren (billing, technical, complaint, feature request) und eine Routing-Empfehlung zu geben."
Warum wichtig: Context reduziert Mehrdeutigkeit.
3. Task/Goal
Sage klar, was das Ziel ist.Schwach: "Mach was mit dem Text"
Stark: "Extrahiere aus der E-Mail: (1) das Kundenproblem in einem Satz, (2) die Kontaktmethode (Email, Phone, Chat), (3) die Dringlichkeit (High/Medium/Low)"
Warum wichtig: Klare Tasks haben klare Outputs.
4. Format-Spezifikation
Sage genau, wie das Output aussehen soll.Schwach: "Gib die Ergebnisse"
Stark: "Antworte im folgenden JSON-Format:
{
"problem": "...",
"contact_method": "...",
"urgency": "..."
}Warum wichtig: Strukturierter Output ist einfach zu parsen und zu integrieren.
5. Beispiele (Few-Shot)
Gib 1-3 Beispiele von guten Outputs.Beispiel:
"Beispiel 1:
E-Mail: 'Ich habe zwei Lizenzen gekauft, aber sie sind nicht in meinem Account. Helft mir bitte!'
Output:
{
'problem': 'Gekaufte Lizenzen sind nicht im Account',
'contact_method': 'Email',
'urgency': 'High'
}"
Warum wichtig: Beispiele zeigen dem Modell das Zielformat. Sie beseitigen genau die Fehler, die keine noch so ausführliche Erklärung im Fliesstext verhindert — falsche Struktur, erfundene Kategorien, Prosa statt JSON.
6. Constraints/Guardrails
Definiere Limits und Regeln.Beispiel:
"Wichtig:
- Antworte NUR mit validem JSON, nichts sonst
- Wenn das Problem unklar ist, setze 'urgency' auf 'Low'
- Benutze nur deutsche Klassifikationen, nie englisch"
Warum wichtig: Constraints vermeiden unerwünschte Outputs.
Prompt Engineering Best Practices
Die 7 Golden Rules:
1. Spezifität über Allgemeinheit
Je spezifischer der Prompt, desto besser die Outputs.Schwach: "Schreibe einen guten Antwortsatz"
Stark: "Schreibe einen Antwortsatz, der: (1) das Problem zusammenfasst, (2) Verständnis zeigt, (3) eine konkrete Lösungszeitlinie gibt"
2. Beispiele sind dein Freund
Zeige dem Modell, was du erwartest, statt es nur zu beschreiben.Tipp: 3-5 Beispiele für komplexe Tasks sind Standard.
- Leichte Tasks (Klassifikation): 1-2 Beispiele
- Mittlere Tasks (Analyse): 3 Beispiele
- Komplexe Tasks (Synthese): 5+ Beispiele
3. Test gegen echte Daten
Prompts funktionieren oft anders mit echten Daten als mit erfundenen Test-Daten.
Prozess:
- Prompt schreiben
- Mit 50 echten Beispielen testen
- Error-Cases identifizieren
- Prompt anpassen
- Nochmal mit 50 echten Beispielen testen
4. Iterative Optimierung
Kein Prompt ist beim ersten Mal perfekt.
Prozess:
- v1.0: Basis-Prompt schreiben
- Test: 50 Beispiele durchlaufen
- Analyse: Wo fehlt es?
- Iteration: Prompt anpassen
- Wiederhole
Typische Iterationen: 3-5 bis Production-Ready
5. Fehler-Handling einplanen
Was wenn der LLM einen Fehler macht?Strategien:
- Retry mit leicht anderem Prompt
- Rückfall auf eine einfachere Klassifikation
- Eskaliere zu Human Review
Beispiel:
"Wenn du unsicher bist (Confidence < 70%), antworte statt mit einer Klassifikation mit: {'error': 'uncertain', 'reason': '...'}"
6. Temperatur & Parameter richtig setzen
LLM-Parameter beeinflussen Output.- Temperature 0: Deterministisch, zuverlässig (für Automation)
- Temperature 0.7: kreativ (fürs Ideensammeln)
- Top-P 0.9: Balanciert
7. Dokumentiere deine Prompts
Produktions-Prompts sind kritischer Code, nicht Wegwerf-Text.Dokumentation sollte enthalten:
- Use Case (wofür ist dieser Prompt?)
- Versionshistorie (was hat sich geändert?)
- Known Limitations (wo funktioniert der Prompt nicht?)
- Test Results (Accuracy auf Test-Set)
- Fallback-Strategien
Chain-of-Thought Prompting — Komplexität meistern
Was ist Chain-of-Thought (CoT)?
Statt den LLM direkt zur Antwort zu führen, lässt du ihn schrittweise denken. Der Effekt ist bei mehrstufigen Aufgaben belegt: In der Untersuchung, die die Technik eingeführt hat, stieg die Trefferquote von PaLM mit 540 Milliarden Parametern auf dem Mathematik-Benchmark GSM8K von 17.9 auf 56.9 Prozent, allein durch acht Beispiele mit ausformuliertem Rechenweg. Der Wert gilt für dieses Modell und diesen Benchmark — übertragbar ist die Richtung, nicht die Zahl.
Quelle: Wei et al., «Chain-of-Thought Prompting Elicits Reasoning in Large Language Models», arXiv:2201.11903 — Volltext-PDF, Tabelle 2, Zeile PaLM 540B, Spalte GSM8K: «Standard 17.9», «Chain of thought 56.9 (+39.0)». Abgerufen am 24. August 2026. Das Abstract auf der Übersichtsseite nennt die beiden Werte nicht, sondern nur «state of the art accuracy on the GSM8K benchmark» — die Zahlen stehen im PDF.Beispiel ohne CoT: Prompt: "Eine Rechnung hat 3 Positionen: 50 CHF, 200 CHF, 150 CHF. Die Mehrwertsteuer beträgt 8.1 %. Was ist der Gesamtbetrag?" Output (oft falsch): "408.1 CHF"
Beispiel mit CoT:
Prompt: "Berechne Schritt für Schritt:
- Addiere alle Positionen
- Berechne Steuern auf die Summe
- Addiere Steuern zur Summe
Output (meist richtig): "
Schritt 1: 50 + 200 + 150 = 400 CHF
Schritt 2: 400 * 0.081 = 32.4 CHF
Schritt 3: 400 + 32.4 = 432.4 CHF
Gesamtbetrag: 432.4 CHF"
Warum funktioniert CoT?
- LLMs sind besser beim Schritt-für-Schritt Denken
- Fehler in frühen Schritten sind sichtbar und korrigierbar
- Final-Output ist transparenter
Wann CoT nutzen?
- Mathematische Berechnungen
- Multi-Step Logic
- Komplexe Klassifikation (viele Kriterien)
- Entscheidungsfindung mit mehreren Faktoren
Wann nicht nötig?
- Simple Klassifikation (A oder B)
- Kurze Text-Extraktion
- Ja/Nein Fragen
Prompt-Fehler und wie man sie vermeidet
Die 10 häufigsten Prompt-Fehler (und wie man sie behebt):
1. Prompt ist zu vage
Falsch: "Schreibe einen guten Text" Richtig: "Schreibe einen Business-Brief an einen Kunden, der eine Rechnung bezahlt hat. Der Brief soll Dank ausdrücken und die Geschäftsbeziehung bestärken. Länge: 3-4 Absätze, Ton: professionell aber warm"2. Format-Spezifikation fehlt
Falsch: "Gib die Ergebnisse" Richtig: "Antworte im JSON-Format: {\"result\": \"...\", \"confidence\": ...}"3. Keine Beispiele
Falsch: "Klassifiziere diese Tickets" Richtig: "[Gib 3 Beispiele von Tickets + erwartete Klassifikation]"4. Zu lange Prompts
Problem: Bei Prompts über 1'000 Wörtern tun sich Modelle schwer Lösung: Kürzen, wichtigste Infos zuerst, Details in Kontext-System-Message5. Mehrdeutige Anforderungen
Falsch: "Analysiere diese Daten" Richtig: "Identifiziere Top 3 Trends in den Daten, sortiert nach Impact. Format: Bullet Points"6. Keine Fallback-Strategie für Fehler
Problem: LLM macht Fehler, Automation bricht Lösung: "Wenn du unsicher bist, gib {\"error\": \"uncertain\"} statt falsche Antwort zurück"7. Prompt passt nicht zum Model
Falsch: Einen Prompt unverändert von einem Modell auf ein anderes übertragen Richtig: Prompts an das eingesetzte Modell anpassen und nach jedem Modellwechsel gegen den Test-Datensatz neu prüfen8. Temperature nicht beachten
Falsch: Temperature 1.0 für kritische Automation (zu viel Variabilität) Richtig: Temperature 0-0.3 für Automation (deterministische Outputs)9. Keine Versionierung
Falsch: Prompt ändert sich ständig, keine Dokumentation Richtig: v1.0, v1.1, v1.2 mit Changelog dokumentieren10. Prompts nicht getestet vor Production
Falsch: "Sieht gut aus, geh live" Richtig: 50-100 Test-Fälle durchlaufen, Accuracy messen, erst dann liveSystematisches Prompt Testing & Optimierung
Der Test-Prozess:
Phase 1: Vorbereitung
- Test-Datensatz vorbereiten (50-100 echte Beispiele)
- Expected Outputs definieren (Ground Truth)
- Metriken definieren (Accuracy, Precision, Recall, je nach Task)
Phase 2: Initiales Testing
- Prompt v1.0 gegen alle Test-Fälle laufen lassen
- Accuracy berechnen
- Error-Cases analysieren ("Wann funktioniert es nicht?")
Phase 3: Iteration
- Auf Basis von Errors Prompt anpassen
- Vermutung: "Wenn ich X ändere, werden Y% besser"
- Nächster Test: v2.0 gegen die gleichen Test-Fälle
Phase 4: Validierung
- Wenn die Accuracy die gesetzte Abnahmeschwelle erreicht, mehr Test-Daten nachlegen
- Neuer Test-Datensatz (weitere 100 ungesehene Beispiele)
- Final-Metriken messen
Task: E-Mail Klassifikation (Billing, Technical, Complaint)
- Accuracy: % richtig klassifiziert
- Precision pro Klasse: Von 100 "Complaint"-Klassifikationen, wie viele sind wirklich Complaints?
- Recall pro Klasse: Von 100 echten Complaints, wie viele erkennt der Prompt?
Abnahmeschwellen, die sich bei uns bewährt haben (Richtwerte aus eigener Praxis, keine Branchennorm — setzen Sie sie nach Schadenshöhe eines Fehlers an):
- Einfache Klassifikation: 85 % Accuracy
- Mittlere Aufgaben: 90 % Accuracy
- Kritische Aufgaben: 95 % Accuracy
Prompt Templates für häufige Automation-Aufgaben
Template 1: E-Mail Klassifikation
Du bist ein Kundensupport-Triage-System. Deine Aufgabe ist, eingehende E-Mails zu klassifizieren.
Kategorien:
- "billing": Fragen zu Rechnungen, Zahlungen, Refunds
- "technical": Problem mit dem Produkt, Bugs, Features
- "complaint": Unzufriedenheit mit Service/Produkt
- "feedback": Positive oder neutrale Vorschläge
- "other": Nicht in obige Kategorien passend
Beispiele:
E-Mail: "Ich habe meine Lizenz nicht erhalten, obwohl ich bezahlt habe"
Kategorie: "billing"
E-Mail: "Die Software crasht wenn ich auf speichern klicke"
Kategorie: "technical"
Antworte nur mit der Kategorie (nicht erklären):
[HIER KOMMT DIE E-MAIL]
Kategorie:Template 2: Daten-Extraktion
Du extrahierst Informationen aus Rechnungen.
Extrahiere folgende Felder:
- Lieferant-Name
- Rechnungs-Datum (Format: YYYY-MM-DD)
- Gesamtbetrag (Zahl, z.B. 1234.56)
- Steuersatz (%, z.B. 8.1)
Antworte im JSON-Format:
{
"vendor": "...",
"date": "...",
"amount": number,
"tax_rate": number
}
Rechnungs-Text:
[HIER KOMMT DIE RECHNUNG]Template 3: Sentiment-Analyse mit CoT
Du analysierst Customer-Feedback. Nutze folgende Schritte:
1. Identifiziere die Hauptaussage (positiv, negativ, neutral)
2. Identifiziere spezifische Punkte (was ist gut/schlecht?)
3. Bestimme Gesamt-Sentiment basierend auf Gewichtung
Antworte im Format:
{
"main_sentiment": "positive|negative|neutral",
"specific_points": ["...", "..."],
"reasoning": "...",
"overall_score": -1.0 to 1.0
}
Feedback:
[HIER KOMMT DAS FEEDBACK]Template 4: Entscheidungslogik
Du triffst Entscheidungen zu Rechnungs-Freigaben.
Regeln:
- Betrag < 1000 CHF und keine früheren Beanstandungen → Approve
- Betrag > 1000 CHF → Manual Review
- Vendor ist nicht auf Whitelist → Manual Review
- Invoice ist älter als 30 Tage → Escalate
Antworte im Format:
{
"decision": "approve|manual_review|escalate",
"reasoning": "...",
"confidence": 0.0 to 1.0
}
Rechnung Details:
[DETAILS]Handlungsplan: Prompts für Ihre Automation verfeinern
Der 4-Wochen-Optimierungs-Plan:
Woche 1: Baseline & Test-Datensatz
Aufgaben:
- Dokumentieren Sie alle aktuellen Prompts (wie sieht Ihre aktuelle Automation aus?)
- 50 echte Beispiele sammeln, Expected Outputs definieren
- Baseline-Accuracy messen (wie gut funktioniert es jetzt?)
Output:
- Liste der Prompts mit aktueller Accuracy
- Test-Datensatz mit 50 Beispielen
Woche 2: Analyse & Hypothesen
Aufgaben:
- Fehler analysieren (Wann funktioniert es nicht?)
- Muster erkennen (z. B. "Fehler bei langen E-Mails" oder "Fehler bei Spezial-Kategorien")
- Optimierungs-Hypothesen aufstellen (z. B. "Wenn ich Beispiele hinzufüge, steigt Accuracy um X%")
Output:
- Fehler-Analyse Report
- 3-5 Optimierungs-Hypothesen
Woche 3: Iteration & Testing
Aufgaben:
- Prompt v2.0 schreiben (basierend auf Hypothesen)
- Nochmal testen gegen Test-Datensatz
- Accuracy vergleichen (v1.0 vs v2.0)
- Erfolgreiche Änderungen beibehalten, fehlgeschlagene verwerfen
Output:
- Optimierte Prompts (v2.0)
- Vergleich-Report (Accuracy-Verbesserung)
Woche 4: Validierung & Dokumentation
Aufgaben:
- Neue Test-Daten (weitere 50 ungesehene Beispiele) testen
- Final Accuracy messen
- Prompts dokumentieren (Version, Was geändert?, Limitations?)
- Live-Rollout mit Monitoring
Output:
- Dokumentierte, optimierte Prompts
- Monitoring Dashboard (wie läuft die Automation?)
Wer nicht bei null anfangen will: Die Prompt Library sammelt 20 getestete Prompts für Content, Datenanalyse, Kundenservice, Sales und Code — jeder als Vorlage zum Übernehmen und Anpassen.
Zusammenfassung: Prompts sind Code, nicht Text
Gute Prompts sind wie guter Code: spezifisch, getestet, dokumentiert, versioniert.
Drei zentrale Erkenntnisse:
- Prompt-Qualität bestimmt Automation-Qualität: Derselbe Prozess trägt sich oder scheitert, je nachdem wie viel Nachkontrolle er erzwingt
- Systematisches Testing ist kritisch: "Sieht gut aus" ist keine ausreichende QA für Production
- Iterative Optimierung funktioniert: 3-5 Iterationen sind normal bis Production-Ready
Nächste Schritte:
- Dokumentieren Sie Ihre aktuellen Prompts
- Sammeln Sie 50-100 Test-Beispiele
- Messen Sie aktuelle Accuracy (Baseline)
- Identifizieren Sie Top 3 Fehler-Pattern
- Optimieren Sie Prompts (Versioning, Testing, Documentation)
- Messen Sie verbesserte Accuracy
- Rollout mit Monitoring
Häufig gestellte Fragen
- Was ist Prompt Engineering im Automation-Kontext?
Prompt Engineering ist die Kunstfertigkeit, LLMs für zuverlässige, automatisierte Aufgaben einzuspannen — systematisch, regelbasiert und wiederholbar statt blossem Ausprobieren. Der wirtschaftliche Unterschied steckt in der Nachkontrolle: Ein Prompt, dessen Ergebnisse ein Mensch laufend nachprüfen muss, verschiebt die Arbeit nur; ein getesteter Prompt läuft durch und braucht den Menschen nur für Ausnahmen.
- Welche Komponenten gehören in einen guten Automation-Prompt?
Ein guter Automation-Prompt besteht typischerweise aus sechs Komponenten: Role/Persona, Context, Task/Goal, Format-Spezifikation, Beispiele (Few-Shot) und Constraints/Guardrails. Beispiele zeigen dem Modell das Zielformat und verhindern genau die Fehler, gegen die keine Erklärung im Fliesstext hilft; für leichte Tasks wie Klassifikation genügen 1–2 Beispiele, für komplexe Synthese-Aufgaben sind 5 oder mehr Standard.
- Was bringt Chain-of-Thought Prompting in der Automation?
Beim Chain-of-Thought Prompting lässt man das LLM schrittweise denken, statt es direkt zur Antwort zu führen. In der Untersuchung, die die Technik eingeführt hat, stieg die Trefferquote eines 540-Milliarden-Parameter-Modells auf dem Mathematik-Benchmark GSM8K dadurch von 17.9 auf 56.9 Prozent (Wei et al., arXiv:2201.11903, Tabelle 2 im Volltext-PDF; das Abstract nennt die Werte nicht). Sinnvoll ist die Technik bei mathematischen Berechnungen, Multi-Step-Logik und komplexer Klassifikation mit vielen Kriterien; für simple Klassifikationen, kurze Text-Extraktion oder Ja/Nein-Fragen ist sie nicht nötig.
- Wie testet man Prompts systematisch vor dem Produktiveinsatz?
Der Test-Prozess läuft in vier Phasen: einen Test-Datensatz mit 50–100 echten Beispielen und Expected Outputs vorbereiten, den Prompt initial testen und Error-Cases analysieren, danach iterieren und gegen dieselben Test-Fälle vergleichen, zuletzt mit weiteren ungesehenen Beispielen validieren. Als Abnahmeschwellen empfehlen wir 85 % Accuracy für einfache Klassifikation, 90 % für mittlere und 95 % für kritische Aufgaben (Richtwerte aus eigener Praxis, keine Branchennorm). Typisch sind 3–5 Iterationen, bis ein Prompt Production-Ready ist.
- Welche Prompt-Fehler sollte man bei AI Automation vermeiden?
Zu den häufigsten Fehlern gehören zu vage Formulierungen, fehlende Format-Spezifikation, fehlende Beispiele, mehrdeutige Anforderungen und fehlende Fallback-Strategien für Unsicherheit. Ebenso verbreitet sind Temperature 1.0 bei kritischer Automation (statt 0–0.3 für deterministische Outputs), fehlende Versionierung und der Go-live ohne vorherigen Test mit 50–100 Fällen und gemessener Accuracy.
Quellen
- Wei et al., «Chain-of-Thought Prompting Elicits Reasoning in Large Language Models», arXiv:2201.11903 — Volltext-PDF, Tabelle 2, Zeile PaLM 540B, Spalte GSM8K: «Standard 17.9», «Chain of thought 56.9 (+39.0)». Abgerufen am 24. August 2026. Das Abstract auf der Übersichtsseite nennt die beiden Werte nicht, sondern nur «state of the art accuracy on the GSM8K benchmark» — die Zahlen stehen im PDF.
