Prompt Engineering: Das Maximum aus KI herausholen

Was ist Prompt Engineering – und warum es so viel ausmacht

Prompt Engineering ist die Kunst, einem KI-Modell genau das zu sagen, was man von ihm braucht – in einer Form, die das Modell versteht und optimal beantwortet. Es geht nicht ums Zaubern, sondern ums Strukturieren. Ein guter Prompt gibt Kontext, definiert die Rolle des Modells, benennt das gewünschte Format und schränkt den Suchraum sinnvoll ein.

Warum das wichtig ist: Dasselbe Modell kann auf die Frage „Erkläre Docker" zehn sehr verschiedene Antworten geben – je nachdem ob man fragt als Neuling, als erfahrener DevOps-Engineer oder als jemand, der eine 3-Satz-Zusammenfassung für seinen Chef braucht. Der Prompt entscheidet, welche Antwort man bekommt.

Die vier Kernelemente eines guten Prompts:

• Rolle/Persona: „Du bist ein erfahrener DevOps-Ingenieur..."
• Kontext: Was ist die Situation, was ist bekannt?
• Aufgabe: Was soll konkret geliefert werden?
• Format: JSON, Markdown, Stichpunkte, Fließtext – klar angeben

Die wichtigsten Prompting-Techniken

Je nach Aufgabe gibt es unterschiedliche Ansätze. Diese drei sind in der Praxis am nützlichsten:

• Zero-Shot Prompting: Direkte Aufgabe ohne Beispiele. Funktioniert für klar definierte, alltägliche Aufgaben. „Klassifiziere folgenden Text als positiv, neutral oder negativ: [Text]"
• Few-Shot Prompting: 2–4 Beispiele mitgeben, die das gewünschte Muster zeigen. Sehr wirksam wenn das Modell ein spezifisches Output-Format lernen soll, das es sonst nicht kennt.
• Chain-of-Thought (CoT): Das Modell zum Denken zwingen: „Denke Schritt für Schritt nach." Reduziert Fehler bei Aufgaben die Reasoning erfordern – Mathematik, Logik, mehrstufige Entscheidungen.

Für KI-Automatisierungen ist das Format entscheidend: Wenn ein Workflow das Ergebnis weiterverarbeiten muss, sollte der Prompt immer explizit ein maschinenlesbares Format (JSON, CSV) verlangen.

Prompts für Automatisierungen und lokale Modelle optimieren

Prompts für Workflows haben andere Anforderungen als interaktive Chat-Prompts. Sie müssen konsistent funktionieren, bei jedem Input das gleiche Format liefern und robust gegenüber unerwarteten Eingaben sein.

Drei Regeln die ich für Automatisierungs-Prompts immer einhalte:

1. Immer ein klares Output-Format erzwingen. „Antworte ausschließlich mit gültigem JSON. Kein Text davor oder danach." – Sonst bricht der Parser.
2. Edge Cases explizit ansprechen. „Falls der Text keine E-Mail-Adresse enthält, gib null zurück." – Sonst halluziniert das Modell eine.
3. System-Prompt von User-Prompt trennen. Der System-Prompt definiert Verhalten und Format, der User-Prompt liefert den variablen Input.

Bei lokalen LLMs ist zusätzlich die Modellgröße relevant: Kleinere Modelle (7B) brauchen klarere, einfachere Prompts als große Modelle (70B+). Zu komplexe Instruktionen bei zu kleinen Modellen führen zu Konfusion statt Gehorsam.

Versioniere deine Prompts wie Code. Ein Prompt der heute gut funktioniert, kann nach einem Modell-Update anders reagieren. In n8n Workflows lohnt es sich, kritische Prompts als benannte Konstanten oder in einer Konfig-Tabelle abzulegen.

Wie die Prompts in meinen produktiven Systemen aufgebaut sind

Die Regeln oben stammen aus Systemen, die bei mir täglich laufen. Ein Beispiel ist der WhatsApp-Bot der Taverne. Sein System-Prompt ist fest und hat drei Teile: eine Rolle, einen Wissensblock, der aus dem Leistungskatalog erzeugt wird, und Regeln. Zwei dieser Regeln stehen wörtlich so drin:

Wenn ein Ergebnis von Code weiterverarbeitet wird, steht das Antwortschema als Beispielzeile im Prompt. Cloud-Modelle bekommen zusätzlich response_format: json_object. Im Bankabgleich sieht das so aus:

Im selben Prompt stehen Few-Shot-Beispiele mit Grenzfällen: eine PayPal-Teilzahlung über 104,98 € gegen eine Rechnung über 101,83 € und eine Zahlung in US-Dollar, die in Euro abgerechnet wurde. Dem Modell glaube ich danach trotzdem nicht blind. Der Code verwirft jeden Treffer mit einer confidence unter 0,55, mit falschem Vorzeichen oder mit einer ID, die es nicht gibt.

Bei lokalen Modellen über LM Studio auf einem Mac mini setze ich bewusst kein response_format. Stattdessen läuft ein toleranter Parser: Code-Fence entfernen, json_decode versuchen, sonst das erste {…} herausschneiden, sonst als Parse-Fehler markieren. Bei Fehler oder Timeout greift eine regelbasierte Lösung ohne LLM.

Praxiswerte aus der Werkstatt (Stand: Oktober 2026)

Die Temperatur stelle ich nach Aufgabe ein, nicht nach Gefühl:

• 0,05: Datenextraktion und Bankabgleich
• 0,2–0,25: Analysen
• 0,3: Kundenkontakt im WhatsApp-Bot, Antworten bis 600 Zeichen
• 0,35–0,4: Briefings
• 0,65: Newsletter
• bis 0,9: Ideensammlung
• Wortziel Content-Automatik: 600–2.000 Wörter, die Kapitelzahl wird daraus berechnet

Für die Content-Automatik von kids24.de kommen echte Suchdaten der Website in den Prompt, mit der Anweisung, sie zu bevorzugen, wenn sie zum Thema passen. Text und Hilfsaufgaben laufen dort über getrennte Modelle.

Fehler, die Modelle bei mir gemacht haben, und was der Code jetzt prüft

• Falsch abgeschriebene IDs: In einer internen Akten-Auswertung sollte das Modell auf Datenbank-IDs verweisen. Lange IDs hat es oft falsch abgeschrieben. Jetzt bekommt es kurze laufende Nummern, und jede Aussage braucht einen Beleg in der Form [#Nr]. Ungültige Belege markiert die Oberfläche als „Beleg?“.
• Erfundene Zitate: Ein Zitat wird verworfen, wenn es nicht wörtlich im Quelltext steht. Im Code steht dazu der Kommentar „Belegzitat muss wirklich im Text stehen (sonst verwerfen statt erfinden lassen)“. <think>-Blöcke von Reasoning-Modellen werden vorher entfernt.
• Abgebrochene Streams: Bei der Content-Automatik kam gelegentlich halbes JSON ohne finish_reason zurück. Das wird erkannt und genau einmal neu angefordert.
• Das schnellere Modell war das schlechtere: Für die Akten-Auswertung habe ich zwei lokale Modelle mit 12 erfundenen Einträgen getestet. Qwen3-32B kam auf F1 0,79 und fand 12 von 12 relevanten Einträgen, gpt-oss-20b auf F1 0,20 und 9 von 12. Ich nutze Qwen3-32B, obwohl ein Bericht 96 statt 15 Sekunden dauert.

Wie so ein Prompt in einem Kundenprojekt aussieht, zeigt die Fallstudie Bewerber-Bot. Weitere Anwendungen findest du unter KI-Automatisierung und RAG, das Angebot dazu unter Leistungen.