LLM Prompt Engineering Grundlagen 2026: Vollständiger Guide

Prompt Engineering ist keine Magie — es ist Kommunikation. Wer versteht wie LLMs denken, schreibt Prompts die zuverlässig das gewünschte Ergebnis liefern. Hier sind alle Grundtechniken, von Zero-Shot bis ReAct, mit echten Vorher-Nachher-Beispielen.

Was Prompt Engineering tatsächlich ist

Der Begriff klingt nach Hokuspokus. In Wirklichkeit ist Prompt Engineering strukturierte Kommunikation mit einem Sprachmodell — ähnlich wie gutes technisches Schreiben. Ein gut formuliertes Prompt gibt dem Modell: Kontext (wer, warum), Aufgabe (was genau), Format (wie soll die Antwort aussehen) und Constraints (was soll nicht passieren).

Das Modell ist trainiert, Muster fortzuführen. Dein Prompt ist das Muster. Je klarer und strukturierter das Muster, desto besser das Ergebnis.

Die 5 Grundprinzipien

  • 1
    Spezifisch statt vage. "Schreibe einen Artikel" ist schlecht. "Schreibe einen 400-Wort Artikel für einen Senior Developer über Redis-Caching-Strategien in Node.js, ohne Redis-Grundlagen zu erklären" ist gut.
  • 2
    Kontext vor Aufgabe. Erkläre zuerst WER du bist, WARUM du das brauchst, WOFÜR es verwendet wird. Das Modell passt Ton und Tiefe entsprechend an.
  • 3
    Format explizit definieren. Willst du Markdown? JSON? Bullet Points? Eine Tabelle? Sag es. Modelle raten sonst — manchmal richtig, oft nicht.
  • 4
    Negativ-Constraints minimieren. "Nicht zu lang" ist schlechter als "maximal 200 Wörter". Positiv formulierte Grenzen sind präziser.
  • 5
    Iterieren statt perfektionieren. Der erste Prompt wird selten perfekt sein. Analysiere was fehlt, ergänze es, wiederhole.

Prompt-Techniken: Von einfach bis komplex

BasisZero-Shot Prompting

Direkte Aufgabe ohne Beispiele. Funktioniert für einfache, klar umrissene Tasks. Der Ausgangspunkt für alles andere.

❌ Schlecht
"Erkläre mir Docker."

Problem: Zu vage. Das Modell weiß nicht für wen, wie tief, in welchem Format.
✅ Gut
"Erkläre Docker für einen Backend-Entwickler der Kubernetes noch nicht kennt. Max. 150 Wörter, 3 Analogien aus der echten Welt, kein Jargon."

BasisFew-Shot Prompting

Du gibst 2-5 Beispiele (Input → Output) bevor du die eigentliche Aufgabe stellst. Das Modell lernt das gewünschte Muster aus deinen Beispielen — kein Training nötig.

Klassifiziere Support-Tickets in: BUG / FEATURE / QUESTION Ticket: "Login funktioniert nicht nach Passwort-Reset" → BUG Ticket: "Könnt ihr eine Dark Mode Option einbauen?" → FEATURE Ticket: "Wie exportiere ich Daten als CSV?" → QUESTION Ticket: "Die App stürzt ab wenn ich auf 'Speichern' klicke" → BUG Jetzt klassifiziere dieses Ticket: Ticket: "Warum zeigt das Dashboard manchmal keine Daten?"
Few-Shot ist besonders stark für konsistente Klassifizierungen, Format-Transformationen und Aufgaben mit klar definierten Mustern.

IntermediateChain-of-Thought (CoT)

Du forderst das Modell auf, den Denkprozess Schritt für Schritt zu zeigen, bevor es zur Antwort kommt. Verbessert Qualität dramatisch bei logischen, mathematischen und mehrstufigen Aufgaben.

# Ohne CoT (schlechter für komplexe Aufgaben): Welchen Server soll ich für meinen Node.js-App wählen? # Mit CoT (viel besser): Welchen Server soll ich für meine Node.js-App wählen? Denke Schritt für Schritt: 1. Analysiere zuerst die Anforderungen (concurrent users, budget, complexity) 2. Bewerte dann die Optionen (VPS, managed Node.js, serverless) 3. Mache schließlich eine konkrete Empfehlung mit Begründung # Noch stärker: "Let's think step by step" am Ende (gilt auch auf Deutsch: "Gehe Schritt für Schritt vor.")

IntermediateRole Prompting (System-Prompt)

Du definierst eine Rolle und Persona für das Modell. Das kalibriert Ton, Tiefe und Perspektive für den gesamten Dialog. Besonders effektiv als System-Prompt in der API.

# System-Prompt Beispiel (Claude API): Du bist ein Senior Software Architect mit 15 Jahren Erfahrung in verteilten Systemen. Du: - Gibst konkrete, direkte Empfehlungen (kein "es kommt drauf an") - Nennst Trade-offs explizit - Priorisierst Simplicity über Cleverness - Verwendest Beispiele aus der echten Welt, keine akademischen Wenn eine Frage zu vage ist, fragst du nach dem spezifischen Kontext bevor du antwortest.

AdvancedReAct (Reason + Act)

Das Modell wechselt zwischen Denken (Reasoning) und Handeln (Tool-Calls) ab. Grundlage für AI-Agents. Statt direkt zu antworten, plant das Modell welche Informationen es braucht, holt sie mit Tools, und verfeinert die Antwort dann.

Thought: Ich muss den aktuellen Serverpreis prüfen bevor ich empfehlen kann. Action: search("Hetzner VPS Preise 2026") Observation: Hetzner CX22: €4.35/Mo, 2 vCPU, 4GB RAM... Thought: Das reicht für <1000 concurrent users. Jetzt Memory-Anforderungen checken. Action: calculate("Node.js + Express baseline memory usage") Observation: ~150MB base, ~50MB per 100 concurrent connections... Thought: Bei 1000 Nutzern: ~650MB benötigt. CX22 mit 4GB ist ausreichend. Answer: Hetzner CX22 (€4.35/Mo) ist für dein Use-Case ausreichend...
ReAct ist die Basis von Claude Code selbst: es denkt, ruft Tools auf (Read, Bash, Edit), verarbeitet Ergebnisse und wiederholt — bis die Aufgabe fertig ist.

AdvancedSelf-Consistency

Erzeuge mehrere unabhängige Antworten für dieselbe Frage, dann wähle die konsistenteste. Teuer aber sehr genau für komplexe Entscheidungen.

# 3x unabhängig antworten lassen, dann Konsens finden Beantworte diese Frage 3 Mal unabhängig (jedes Mal neu denken): "Soll ich meine App als Monolith oder Microservices starten?" Antwort 1 (Perspektive: Startup mit 2 Devs): ... Antwort 2 (Perspektive: Skalierung auf 100k User): ... Antwort 3 (Perspektive: Maintainability in 3 Jahren): ... Welche Empfehlung ergibt sich aus allen drei Perspektiven?

Prompts für verschiedene Output-Formate

# JSON-Output erzwingen (wichtig für programmatische Verarbeitung) Analysiere diesen Code-Kommentar und gib das Ergebnis als JSON zurück. KEIN erklärender Text, NUR valides JSON. Schema: { "category": "bug|feature|question|optimization", "priority": "high|medium|low", "assignee": "backend|frontend|devops|unklar", "summary": "max 10 Wörter" } Kommentar: "Login-Button reagiert manchmal erst nach 3-4 Klicks"
# Tabellen-Output Vergleiche PostgreSQL, MySQL und SQLite für ein Startup-Projekt. Antworte NUR mit einer Markdown-Tabelle. Kriterien: Setup-Komplexität, Performance, Skalierbarkeit, Hosting-Kosten, Geeignet für. Bewertung: ⭐⭐⭐ = sehr gut, ⭐⭐ = gut, ⭐ = eingeschränkt.

Die häufigsten Prompt-Fehler

❌ Fehler 1: Ambiguität
"Mache den Code besser."

Besser wie? Schneller? Lesbarer? Sicherer? Kürzer? Alle vier führen zu verschiedenen Outputs.
✅ Fix
"Refaktoriere diesen Code für bessere Lesbarkeit: extrahiere Funktionen, benenne Variablen nach ihrem Zweck, entferne Duplikate."
❌ Fehler 2: Zu langer Kontext ohne Struktur
Alles in einen langen Paragraphen packen ohne klare Trennung von Kontext, Aufgabe und Constraints.
✅ Fix
Struktur mit klaren Headings:
KONTEXT: ...
AUFGABE: ...
FORMAT: ...
CONSTRAINTS: ...
❌ Fehler 3: Widersprüchliche Instruktionen
"Antworte kurz und präzise" + "Erkläre alles im Detail" in einem Prompt.
✅ Fix
Priorisiere: "Antworte präzise. Falls Details nötig sind, markiere sie als [DETAIL] am Ende."

Prompt Engineering für Claude Code

Claude Code hat eine Besonderheit: CLAUDE.md ist das permanente System-Prompt. Alles was du in CLAUDE.md schreibst ist immer aktiv. Nutze das:

# CLAUDE.md — Prompt Engineering für persistenten Kontext ## Coding-Standards (immer aktiv) - TypeScript strict mode immer - Fehler: throw mit sprechender Message, KEIN silent catch - Tests: jest, immer co-lokiert (feature.test.ts neben feature.ts) ## Antwort-Format - Code-Erklärungen: max 3 Sätze - Bei Änderungen: erst kurz was geändert, dann warum - Keine Zusammenfassungen am Ende was du gemacht hast ## Constraints - NIEMALS package.json ohne Rückfrage ändern - NIEMALS .env Dateien anfassen - Bei Security-Concerns: zuerst fragen, dann implementieren

Prompt Engineering im Kurs

Im Claude Code Mastery Kurs gibt es ein vollständiges Prompt-Engineering-Modul mit 40+ getesteten Prompt-Templates für die häufigsten Entwicklungsaufgaben — direkt copy-pasten und anpassen.

14 Tage kostenlos testen →