Du fragst Claude eine Frage und kriegst eine Antwort. Aber die Qualität der Antwort hängt stark davon ab, wie du die Frage stellst. Diese Techniken zeigen wie du bessere Prompts schreibst.
Basics (Wiederholung)
Bevor es kompliziert wird — die Fundamentals:
1. Klare Anweisungen
✓ RICHTIG:
Schreibe einen Python-Funktionstest mit pytest für die login() Funktion.
Der Test soll 3 Cases abdecken:
1. Erfolgreicher Login mit validen Credentials
2. Login mit falsem Passwort
3. Login mit nicht-existierendem User
✗ FALSCH:
Schreib einen Test
2. Kontext geben
✓ RICHTIG:
Wir verwenden pytest für Unit Tests, PostgreSQL für die Datenbank.
Das Projekt ist ein FastAPI Backend.
Schreibe einen Test für...
✗ FALSCH:
Schreibe einen Test...
(Claude weiß nicht welche Tools du nutzt)
3. Format angeben
✓ RICHTIG:
Gib die Antwort als:
- JSON object mit Feldern "name", "age", "city"
- Code-Block (```json...```)
- Englisch
✗ FALSCH:
Gib die Antwort
(Claude wählt zufälliges Format)
Chain of Thought (CoT)
Chain of Thought bedeutet: "Zeige mir deine Gedankengänge, Schritt für Schritt."
Claude wird viel bessere Ergebnisse liefern wenn er sein Denken zeigt.
Basis
Frage: Ist 15 * 18 + 42 größer als 200?
✗ Ohne CoT:
Claude: "Ja"
(Schnell, aber wenig Kontext)
✓ Mit CoT:
Claude: "
Rechnung:
1. 15 * 18 = 270
2. 270 + 42 = 312
3. 312 > 200? Ja
"
(Claude zeigt Arbeit, du siehst wo Fehler sind)
Prompt-Pattern
Löse dieses Problem Schritt für Schritt:
Problem: [dein Problem]
Schritte:
1. [was first?]
2. [then?]
3. [finally?]
Antwort: [result]
Für Code-Reviews
Reviewe diesen Code auf Bugs:
[Code]
Überdenke folgende Aspekte schrittweise:
1. Sind alle Variablen initialisiert?
2. Sind Array-Grenzen gecheckt?
3. Sind alle Exception-Cases behandelt?
4. Ist die Performance OK (O(n) oder schlimmer)?
Bugs die ich finde:
- [Bug 1] → Auswirkung: ...
- [Bug 2] → Auswirkung: ...
XML-Tags für Struktur
XML-Tags helfen Claude, verschiedene Abschnitte zu verstehen und zu unterscheiden.
Beispiel: Anforderungen vs. Einschränkungen
Schreibe einen Webhook-Handler.
<requirements>
- POST Endpoint auf /webhook
- Signatur mit HMAC-SHA256 verifizieren
- Payload in PostgreSQL speichern
- HTTP 200 bei Erfolg, 400 bei Validierungsfehler
</requirements>
<constraints>
- Nur AsyncIO (nicht Threads)
- Keine externe Abhängigkeiten außer FastAPI + psycopg
- Timeout: 5s max
</constraints>
<context>
Wir verwenden Pydantic für Validation, ein existierender Pool
ist in `db.pool` verfügbar.
</context>
Claude versteht die Struktur besser und macht weniger Fehler.
Andere nützliche Tags
<goal>Was ist das Ziel?</goal>
<background>Welcher Kontext ist wichtig?</background>
<audience>Wer liest das?</audience>
<constraints>Was darf ich NICHT machen?</constraints>
<examples>Beispiele</examples>
<output_format>Was soll raus kommen?</output_format>
Few-Shot Learning
Few-Shot bedeutet: "Zeige mir ein-zwei Beispiele, dann mach es so."
Beispiel: API Response formatieren
Konvertiere diese JSON-Fehler in eine lesbare Form.
Beispiel 1:
Input: {"code": 401, "message": "Unauthorized"}
Output: "Zugriff verweigert (401) — Bitte meld dich an"
Beispiel 2:
Input: {"code": 500, "message": "Internal Server Error"}
Output: "Fehler auf unserem Server (500) — Versuche später erneut"
Jetzt konvertiere diese:
1. {"code": 404, "message": "Not Found"}
2. {"code": 422, "message": "Validation Error"}
Claude sieht das Muster und macht es genauso.
Few-Shot für Code-Stil
Schreib Python-Code im folgenden Stil:
Beispiel 1 (Was ich möchte):
```python
def process_user(user_id: int) -> dict:
"""Verarbeite einen User und return Status."""
try:
user = fetch_user(user_id)
return {"status": "ok", "user": user}
except UserNotFound:
return {"status": "error", "message": "User nicht gefunden"}
Beispiel 2 (Was ich NICHT möchte):
def processUser(userID):
u = fetchUser(userID)
return u
Jetzt schreib eine Funktion die...
Claude ahmt den Stil nach.
## Zero-Shot vs. Few-Shot
Zero-Shot: "Translate this to German" → Claude übersetzt (Claude braucht kein Beispiel)
Few-Shot: "Hier sind 3 Beispiele von German translations... Jetzt translate this" → Claude übersetzt im gleichen Stil
Few-Shot ist besser wenn:
- Format kompliziert ist
- Du einen speziellen Stil brauchst
- Edge Cases wichtig sind
## Reverse Prompting (Interview-Modus)
Statt Claude zu fragen, **fragst du Claude Fragen zu stellen**.
Claude wird bessere Antworten geben wenn er dir Fragen stellt um seinen Context zu verbessern.
### Beispiel 1: Produktkalkulation
Ich will ein Produkt kalkulieren, die Pricing ist komplex.
Statt mir zu sagen wie, frag MICH Fragen um besser zu verstehen was ich brauche.
Claude antwortet:
Gute Idee! Ich hab ein paar Fragen:
- Ist das ein SaaS-Produkt (recurring) oder Software-Lizenz (one-time)?
- Wie viele Tiers brauchst du? (z.B. Basic/Pro/Enterprise)
- Sollen Bundle-Rabatte möglich sein?
- Welche Konkurrenz-Preise sind relevant?
- Zielgruppe: KMUs (€100-500) oder Enterprise (€10k+)?
Du beantwortest die Fragen → Claude macht eine bessere Kalkulation.
### Beispiel 2: Code-Architektur
Ich hab eine Microservices-Architektur und bin mir nicht sicher ob sie skaliert. Statt mir zu sagen was falsch ist, frag mich Fragen um das zu verstehen.
Claude:
Perfekt, ich hab Fragen:
- Wie viele Services hast du aktuell?
- Wie kommunizieren sie? (REST, gRPC, Message Queue?)
- Wo sind Performance-Bottlenecks aktuell?
- Ziel: Skalierbarkeit oder Cost-Effizienz?
Das ist viel hilfreicher als eine generische Antwort.
## Meta-Prompting
Meta-Prompting bedeutet: "Claude schreibt seinen eigenen Prompt."
Das ist hilfreich wenn du ein komplexes Problem hast und nicht sicher bist wie du Claude fragen sollst.
### Beispiel
Ich hab ein Problem und weiß nicht wie ich Claude fragen soll.
Problem: Ich muss eine Reporting-Pipeline bauen die täglich Daten aus 5 Datenquellen aggregiert.
Schreib einen Prompt den ich dann verwenden kann um eine bessere Anleitung für die Implementierung zu kriegen.
Claude schreibt einen strukturierten Prompt für dich → du benutzt ihn.
## Self-Ask Pattern
Beim Self-Ask Pattern fragt Claude sich selbst Fragen bevor er antwortet.
### Wie es funktioniert
Frage: Sollten wir zu Kubernetes migrieren?
Self-Ask Pattern:
- Claude: "Okay, die Frage ist ob Kubernetes Sinn macht"
- Claude: "Was muss ich verstehen?
- Aktuelle Infrastruktur
- Team-Expertise
- Kosten vs. Benefits"
- Claude: "Fragen:
- Wie viele Server haben wir?
- Kennt das Team Kubernetes?
- Was kostet das aktuell?
- Claude: "Basierend auf [Annahmen]: Meine Empfehlung ist..."
Claude arbeitet systematischer.
### Prompt für Self-Ask
Beantworte diese Frage mit Self-Ask:
- Reformuliere die Frage
- Zerlege sie in Sub-Fragen
- Beantworte jede Sub-Frage
- Gib eine finale Antwort
Frage: [deine Frage]
## Extended Thinking (Claude 3.5+)
Extended Thinking aktiviert tiefes Nachdenken. Claude denkt länger und gründlicher nach.
### Aktivierung
Ich need extended analysis für dieses komplexe Problem.
Verwende extended thinking:
- Überdenke das Problem von mehreren Winkeln
- Prüfe deine Annahmen
- Erkläre dein Denk-Prozess
Problem: [dein komplexes Problem]
Das gibt bessere Qualität, braucht aber mehr Zeit.
## System Prompts Best Practices
System Prompts sind die Anleitung die du Claude bei Session-Start gibst (in API oder CLAUDE.md).
### Struktur
```markdown
# System Prompt — Mein Projekt
## Rolle
Du bist ein Technical Writer der Code-Dokumentation schreibt.
## Stil
- Österreichisch-informell (Du-Form)
- Technisch präzise, kein Marketing-Fluff
- Praktische Code-Beispiele
- Markdown-Format
## Kontext
- Projekt: Playbook01 (E-Commerce Plattform)
- Tech Stack: Next.js, n8n, PostgreSQL
- Target Audience: KMU-Gründer
## Regeln
- KEINE AI-Buzzwords (pivotal, landscape, delve)
- Deutsche Begriffe wenn möglich, Englisch für Tech-Terms
- Code-Beispiele MÜSSEN funktionieren
- Keine Affiliate-Links, keine CTAs
## Output-Format
- H1 Titel, H2 Sections
- Code-Blöcke mit Language-Tag
- Checklisten am Ende jeder Seite
Do's & Dont's
| Do | Don't |
|---|---|
| Spezifisch sein | Vage Anweisungen |
| Beispiele geben | Nur Theorie |
| Constraints nennen | Alles erlauben |
| Format definieren | Zufällig hoffen |
| Fehler adressieren | Blind hoffen es passt |
Claude-spezifische Tips
1. Prefill nutzen
Du kannst Claude die erste Zeile der Antwort vorgeben:
Prompt: "Schreib einen Deployment-Plan"
Prefill: "## Deployment Plan
1. Pre-flight Checks"
Claude setzt die Antwort fort und folgt automatisch der Struktur
2. Thinking Tags (Claude 3.5+)
<thinking>
Das ist ein komplexes Problem. Ich sollte:
1. Die Anforderungen verstehen
2. Edge Cases überdenken
3. Verschiedene Lösungsansätze evaluieren
</thinking>
Jetzt antworte auf Basis meiner Überlegungen.
3. Stop-Sequenzen
Wenn Claude zu viel schreibt, nutze Stop-Sequenzen:
"Antworte kurz und prägnant. Stopp nach 3 Punkten."
4. Token-Awareness
Diese Frage könnte 50k Tokens brauchen.
Bevor Claude anfängt: "/cost prüfen"
Dann bei Bedarf:
"Fass dich kürzer — max 5000 Tokens"
Praktisches Beispiel: Ein kompletter Prompt
# Aufgabe: API-Dokumentation schreiben
## Goal
Schreibe eine Übersicht für die POST /users Endpoint.
## Context
- Framework: FastAPI
- Authentication: JWT Bearer Token
- Datenbank: PostgreSQL
- Response Format: JSON
## Requirements
- Kurze Beschreibung (max 2 Sätze)
- Request-Body Schema mit Validierungsregeln
- 3 Response-Beispiele:
1. 201 Success
2. 400 Validation Error
3. 401 Unauthorized
- Curl-Beispiel
- Code-Beispiel (Python requests)
## Style
- Deutsch
- Technisch präzise
- Praktische Beispiele nur
- Markdown format
## Constraints
- Keine Marketing-Sprache
- Keine halluzinierten Felder
- Nur tatsächliche API-Behavior
Dieser Prompt gibt Claude alle Informationen um eine gute Antwort zu schreiben.
Checkliste
- Anleitung ist klar, nicht mehrdeutig
- Kontext gegeben (Tech Stack, Audience, Ziel)
- Format angegeben (JSON, Markdown, Code, etc.)
- Beispiele gegeben (Few-Shot wo sinnvoll)
- Constraints definiert (Was NICHT machen)
- XML-Tags für komplexe Struktur genutzt
- Chain-of-Thought aktiviert (für komplexe Tasks)
- Stil definiert (wenn relevant)
- Fehlerfall adressiert (Was bei Fehler tun)
- Nach kritischen Aufgaben: "/cost prüfen"
