30 praktische Claude-Prompting-Techniken aus der täglichen Anwendung
Eine im Feld getestete Aufschlüsselung von 30 Claude-Prompting-Techniken, geordnet nach dem, was sie tatsächlich erreichen – von klaren Anweisungen bis hin zu vollständigen Prompt-Systemen.
Zahlreiche „Prompt-Engineering“-Leitfäden werden als Lesezeichen gespeichert und nie wieder aufgerufen. Zu viele wirken, als hätte jemand einfach zwei Prompts eingegeben, einen Screenshot gemacht und diesen zur Methode erklärt.
Was folgt, unterscheidet sich hauptsächlich durch seine Entstehung: Monate langes, manchmal mühsames Hin- und Her mit Claude in Nebenprojekten sowie bei freiberuflicher Schreibarbeit, begleitet von viel Ausprobieren, um herauszufinden, welche häufig wiederholten „Best Practices“ tatsächlich dem Umgang mit echter Arbeit standhalten.
Einige der unten aufgeführten Techniken verändern tatsächlich die Art und Weise, wie Entwickler Prompts formulieren. Einige werden getestet, als unpraktisch empfunden, aber dennoch beibehalten, weil sie weiterhin spezifische Probleme gut lösen. Und einige Techniken, die wie Tricks wirken, erweisen sich als einige der wertvollsten Einträge in dieser gesamten Liste. Jeder Abschnitt gibt an, in welche Kategorie er fällt.
Diese werden in vier Gruppen eingeteilt, basierend darauf, was jede Technik tatsächlich erreicht – und nicht darauf, wie ausgefeilt sie auf dem Papier klingt:
Part 1 — Say What You Mean (clarity & structure)
Part 2 — Put Up Guardrails (constraints & format control)
Part 3 — Make It Reason Out Loud (thinking & iteration)
Part 4 — Build a System, Not a Prompt (workflows & long context)
Teil 1 – Sagen Sie, was Sie meinen
1. Seien Sie präzise, nicht vage
Das bleibt einer der häufigsten Fehler, die Menschen bei der Formulierung von Anfragen machen. Wenn man bittet „Machen Sie das besser“, erhält man etwas Allgemeines und Vergessliches. Wenn man bittet „Überschreiben Sie diesen Absatz so, dass ein nicht-technischer Gründer die Abwägungen in zwei Sätzen verstehen kann“, erhält man etwas Nützliches.
Eine nützliche Faustregel: Wenn es weniger als 10 Sekunden dauert, eine Anfrage zu formulieren, war sie wahrscheinlich nicht konkret genug.
2. Verwenden Sie Struktur-Tags, um die Teile Ihrer Anfrage zu trennen
XML-ähnliche Tags lohnen sich, ständig verwendet zu werden – nicht wegen der Behauptung, dies sei Claudes „Muttersprache“ (eine Behauptung, die schwer zu überprüfen ist und mit völliger Sicherheit skeptisch betrachtet werden sollte), sondern weil Tags ein reales, praktisches Problem lösen: Wenn Anweisungen, Hintergrundinformationen und Beispiele in einem Textblock miteinander verschmelzen, muss das Modell raten, wo jeder Abschnitt beginnt und endet. Tags beseitigen dieses Raten völlig.
<instructions>
Summarize the risks section only. Ignore financial projections.
</instructions>
<context>
[pasted document]
</context>
<output_format>
3 bullet points, no more than 15 words each
</output_format>
3. Zuerst der Kontext, dann die Frage
Diese Reihenfolge ist wichtiger, als es auf den ersten Blick scheint. Das Einfügen eines langen Dokuments und das anschließende Stellen einer Frage führt in der Regel zu deutlich schlechteren Antworten als das Stellen der Frage nachdem alle Informationen vorgelegt wurden. Eine plausible Erklärung, auch wenn sie wissenschaftlich nicht bewiesen ist, ist, dass diese Reihenfolge verhindert, dass das Modell versucht, eine Antwort zu formulieren, bevor es tatsächlich alles gelesen hat.
[long document]
---
Based on everything above, what's the single biggest
risk to the Q3 timeline?
4. Zeigen, anstatt nur zu beschreiben (Few-Shot-Beispiele)
Beschreibende Adjektive sind billig und oft vage. Ein einzelnes konkretes Beispiel für den gewünschten Ton, die Struktur oder das Format ist wirksamer als ein ganzer Absatz voller Beschreibungen. Bei wiederkehrenden Aufgaben – wie E-Mails an Kunden, Feedback zu Code-Überprüfungen und ähnlichen Routinen – hilft es, zwei oder drei „Gold-Standard“-Beispiele in einer Notizdatei zu speichern, die jederzeit eingefügt werden können, sobald wieder eine ähnliche Aufgabe anfällt.
5. Erklären Sie den Grund, nicht nur die Regel
Das ist eine der überraschenderen Techniken auf dieser Liste. Technisch gesehen funktioniert es, Claude zu sagen „Halten Sie dies unter 280 Zeichen“. Doch wenn man ihm mitteilt „Dies wird direkt in einen Tweet eingefügt, und alles über 280 Zeichen wird mitten im Satz abgeschnitten“, erzeugt das sichtbar sorgfältigere Ergebnisse. Es ist, als würde ein Grund dafür sorgen, dass das Modell während der gesamten Antwort über die Einschränkung nachdenkt, anstatt erst ganz am Ende die Zeichen zu zählen.
6. Erlauben Sie ausdrücklich „Ich weiß es nicht“
Eine einzige Zeile lohnt sich, in fast jeden Forschungs- oder Analyse-Auftrag einzufügen:
If the available information isn't enough to draw a
conclusion, say so directly instead of guessing.
Wenn man diese Zeile weglässt, besteht ein echtes Risiko, dass Unsinn zurückgegeben wird, der überzeugend klingt. Wenn man sie hinzufügt, lautet die Antwort manchmal „Es liegen hier nicht genug Informationen vor, um mit Sicherheit etwas sagen zu können“ – was zwar im Moment unbefriedigend ist, aber besser ist als erst Stunden später eine erfundene Tatsache zu entdecken.
7. Geben Sie das Ausgabeformat an, nehmen Sie es nicht einfach an
Es gibt einen deutlichen Unterschied zwischen der Anfrage nach „einer Tabelle“ und der Anfrage nach „einer Texttabelle, die so formatiert ist, dass sie sauber in einen Codeblock eingefügt werden kann, da Medium Markdown-Tabellen oft zerstört“. Wenn man die genaue Form der gewünschten Antwort beschreibt, wird diese Diskrepanz vollständig vermieden.
8. Definieren Sie, wie etwas als „erledigt“ aussieht – nicht nur die Aufgabe selbst
Anstatt die Aufgabe selbst zu beschreiben, führt die Beschreibung dessen, wie ein erfolgreiches Ergebnis aussehen würde, in der Regel zu präziseren Ergebnissen:
I need a competitor comparison so my co-founder can
pick a pricing tier in under 5 minutes without asking
me follow-up questions.
Jene einzige Zeile hat mehr Gewicht als drei Absätze voller Formatierungsregeln je haben könnten.
Teil 2 – Schutzmaßnahmen einführen
9. Negative Einschränkungen – angeben, was es NICHT tun soll
Mannchmal ist es schneller, das Ziel durch Ausschluss dessen zu definieren, was man nicht will, anstatt genau festzulegen, was man haben möchte:
Do not sound like: a LinkedIn thought-leader post.
Do not include: "in today's fast-paced world," filler
caveats, or a summary that repeats the intro.
10. Ein „Vertrags“-stiliger Systemhinweis
Für alles, was Sie wiederverwenden möchten, formulieren Sie den Systemhinweis wie einen kurzen Rechtsvertrag und nicht wie eine Charakterbeschreibung:
Role: technical editor for a solo dev's blog
Goal: tighten prose without changing meaning
Constraints:
- keep first-person voice
- no invented statistics
- flag anything that sounds AI-generated
If unsure: ask one clarifying question, don't guess
Output: plain markdown, no headers added
11. Vermeiden Sie das „als erfahrener Experte handeln“-Szenario
Das ist eine Technik, die man besser aufgeben sollte. Wenn die Anweisungen bereits präzise sind, scheint es keinen großen Unterschied zu machen, Claude mitzuteilen, er solle „sich wie ein 20-jähriger erfahrener Ingenieur verhalten“. Die Festlegung einer Rolle hat weitaus geringere Bedeutung als die tatsächlich gegebenen Einschränkungen. Auf eine Rolle zurückzugreifen, um fehlende Details auszugleichen, ist in der Regel ein Zeichen dafür, dass die Anweisungen selbst präzisiert werden müssen.
12. Selbsteinschätzung anhand eines Bewertungsschemas
Anstelle der allgemeinen Aufforderung „Überprüfen Sie Ihre Arbeit“ sollte man ein konkretes Bewertungsschema bereitstellen und eine selbstbewertete Punktzahl vor der endgültigen Ausgabe verlangen:
Score your draft 1-10 on: technical accuracy, whether
a beginner could follow it, and whether it sounds
like a real person wrote it. Then revise based on
your own score. Show only the revised version.
Dieser Ansatz hat bereits mehrfach echte Fehler in Code-Erklärungen und Datenzusammenfassungen aufgedeckt.
13. Lange Dokumente sorgfältig auswählen statt alles hinzuzufügen
Das Hinzufügen mehr Materials verbessert die Antwort nicht automatisch. Das Einfügen einer ganzen Codebasis oder eines langen PDFs ohne vorherige Filterung führt in der Regel dazu, dass die Antwort nur den mittleren Teil des Dokuments durchgeht und sich auf die Anfangs- und Schlussabschnitte konzentriert. Ein besseres Vorgehen besteht darin, Claude zunächst die relevanten Abschnitte herauszusuchen und erst danach darüber zu reflektieren – eine in kleinem Maßstab umgesetzte Version eines „retrieve-then-reason“-Pipelines:
Step 1: extract the 5 passages most relevant to
[my question], quoting them exactly.
Step 2: analyze only those passages.
14. Mehrere Dokumente bei der Vergleich von Quellen kennzeichnen
Beim Vergleich mehrerer Quellen sollten diese explizit benannt und nummeriert werden, anstatt sie nur mit leeren Zeilen voneinander zu trennen. Diese kleine Anpassung verringert erheblich die Wahrscheinlichkeit, dass das Modell eine Aussage dem falschen Dokument zuordnet.
<document index="1" name="Q3_report.pdf">...</document>
<document index="2" name="Q2_report.pdf">...</document>
15. Klare Grenzen für die strukturierte Ausgabe
Falls ein strenges JSON-Format oder ein bestimmtes Schema erforderlich ist, sollte dies direkt angegeben und die genauen Schlüssel aufgelistet werden, anstatt die Struktur vage zu beschreiben und darauf zu hoffen, dass das Modell sie korrekt erkennt:
Return only a JSON object with keys: title, summary,
confidence (0-1), open_questions (array of strings).
No text before or after the JSON.
Teil 3 – Die Lösung laut aussprechen
16. Bei nicht-trivialen Aufgaben nach schrittweiser Begründung fragen
Durch das Hinzufügen einer Anweisung, dem Modell mitzuteilen, das Problem in Etappen zu bearbeiten, bevor es eine endgültige Antwort gibt, sowie dabei alle Randfälle zu berücksichtigen, wird mehr Arbeit geleistet, als es auf den ersten Blick scheint. Dies lohnt sich bei allen Aufgaben, die Mathematik, mehrstufige Logik oder Entscheidungen mit Abwägungen beinhalten. Bei Aufgaben, die als „offensichtlich einfach“ erscheinen, wird diese Vorgehensweise oft weggelassen – genau dann neigen die Dinge dazu, schiefzugehen.
17. Prompt-Ketten statt einer einzigen umfangreichen Anfrage
Es ist verlockend, alles in einer einzigen Anfrage zu bündeln: Den Text lesen, zusammenfassen, daraus Social-Media-Beiträge erstellen und einen Titel vorschlagen. Die Aufgaben in sequenzielle Anfragen aufzuteilen liefert in jeder Phase bessere Ergebnisse, da jeder einzelne Schritt nur eine Aufgabe gut erledigen muss:
[1] extract key facts
|
v
[2] turn facts into a 3-paragraph summary
|
v
[3] turn summary into 5 short takeaways
18. Umgekehrtes Brainstorming für feststeckende Entscheidungen
Diese Technik schien anfangs wie ein Trick, hat sich aber als wirklich nützlich erwiesen. Anstatt direkt zu fragen, wie ein Launch erfolgreich sein kann, sollte man zunächst nach dem Gegenteil fragen:
Brainstorm 10 ways this launch could fail. For each
one, invert it into a concrete thing we'd do
differently. Flag the 3 inversions that are the least
obvious.
Dieser Ansatz macht Blindstellen sichtbar, die eine einfache Anfrage wie „Geben Sie mir eine Strategie“ oft übersehen würde.
19. Debatte mit mehreren Persönlichkeiten für Entscheidungen mit echten Abwägungen
Dies könnte die stärkste Technik auf der Liste sein. Bei Entscheidungen mit widersprüchlichen Anreizen sollten Sie Claude bitten, die Argumente aus mehreren unterschiedlichen Perspektiven darzulegen, bevor er alles zu einer Empfehlung zusammenfasst:
Optimist Skeptic End user
"ship faster" "watch runway" "don't care
| | about our
v v problems"
\ | /
\ | /
\ | /
v v v
synthesized recommendation
Eine einfache Anfrage wie „Geben Sie mir einfach Ihre Empfehlung“ führt in der Regel zu der Antwort, die am überzeugendsten klingt. Wenn man zunächst eine interne Debatte erzwingt, entsteht ein Ergebnis mit schärferen und besser nachvollziehbaren Argumenten.
20. Selbstkritik und Überarbeitung in derselben Anfrage
Dies baut auf der vorherigen Idee auf, ist aber in einer leichteren Form gehalten – man bittet um einen ersten Entwurf, eine Selbstkritik dieses Entwurfs sowie eine überarbeitete Endversion, alles in einer einzigen Anfrage anstelle mehrerer Hin- und Herwechsel:
Draft 1 -> list 3 weaknesses in Draft 1 -> Draft 2
21. Lassen Sie es vor der Arbeit klärende Fragen stellen
Für alles Unklare oder von Bedeutung sollte das Modell ausdrücklich angewiesen werden, noch nicht mit der Arbeit zu beginnen und zunächst alle notwendigen Fragen zu stellen. Dadurch entsteht eine kurze Verzögerung, bevor die erste echte Antwort kommt, doch es wird in der Regel eine ganze Runde an Nacharbeiten erspart.
22. Meta-Prompting – das Modell dazu bringen, Ihren Prompt zu verbessern
Das ist ein untergenutzter Ansatz. Wenn ein Prompt weiterhin mittelmäßige Ergebnisse liefert, sollten Sie anstelle dessen, ihn selbst umzuschreiben, direkt fragen:
Here's the prompt I've been using: [paste]. Here's the
output it produces: [paste]. What's wrong with the
prompt, and rewrite it.
Dadurch werden oft vage Formulierungen aufgedeckt, die man selbst nicht bemerkt hätte – hauptsächlich deshalb, weil man bereits weiß, was man meinte, und die Unklarheiten übersprungen hat.
23. Betrachten Sie es als Gespräch, nicht als einen einzigen perfekten Prompt
Dies ist der größte Denkwechsel hier – es handelt sich weniger um eine Technik als vielmehr darum, einen schlechten Gewohnheit abzulegen: Hören Sie auf, nach dem perfekten Prompt zu suchen. Fordern Sie eine grobe erste Version an, reagieren Sie darauf und feinjustieren Sie anschließend. Der Versuch, alle Anforderungen in einen einzigen, riesigen Prompt zu packen, führt konsequent zu schlechteren Ergebnissen als einige kurze Iterations- und Feedbackschleifen.
Teil 4 – Erstellen Sie ein System, nicht nur einen Prompt
24. Verwenden Sie persistente Regelfilter statt sich selbst zu wiederholen
Dies könnte der wertvollste Gewohnheitswechsel von allen sein. Anstatt Ton, Zielgruppe und Einschränkungen in jeden neuen Prompt neu einzutippen, speichern Sie diese in einer eigenständigen rules.md-Datei:
# Writing rules
- tone: direct, no fluff
- audience: builders, not consumers
- never use: "leverage", "in today's world"
- always: specific numbers, source links, one action item
- format: short paragraphs, 3 sentences max
Fangen Sie dann jede Sitzung damit an, darauf hinzuweisen: „Lesen Sie rules.md vollständig durch, bevor Sie beginnen. Wenn Sie dabei eine dieser Regeln brechen wollen, halten Sie inne und sagen Sie es mir stattdessen.“
Dies verändert den Ansatz bei der Anweisungsgabe von etwas, das jedes Mal neu erledigt werden muss, zu der Konfiguration eines kleinen, dauerhaften Tools. Es ist der Unterschied zwischen dem täglichen Auseinandersetzen mit derselben Aufgabe und deren einmaliger Lösung.
25. Machen Sie den Zyklus aus Planung, Handlung, Überprüfung und Iteration explizit
Bei agiler Arbeit – mehrschrittigen Aufgaben, bei denen Claude Tools aufruft, Dateien bearbeitet oder Befehle ausführt – gehen Sie nicht davon aus, dass das Modell den Prozess von selbst strukturiert. Beschreiben Sie den Zyklus direkt:
┌─────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ PLAN │ -> │ ACT │ -> │ VERIFY │ -> │ ITERATE│
│ max 5 │ │ use │ │ against│ │ or │
│ steps │ │ tools │ │criteria│ │ done │
└─────────┘ └────────┘ └────────┘ └────────┘
| fail
v
back to ACT
Die Anweisung, die die meisten stillen, kaskadierenden Fehler verhindert hat, ist einfach: Gehen Sie nur zum nächsten Schritt über, wenn der aktuelle Schritt die Überprüfung bestanden hat.
26. Beziehen Sie Behauptungen auf abgerufte Fakten und nicht auf das Gedächtnis
Für alle faktenbasierten Anfragen sollte man das Modell ausdrücklich anweisen, aus dem vorliegenden Material zu ziehen statt aus seinem Trainingserfahrungsschatz. Wenn man es bittet, „die genaue Zeile oder den entsprechenden Abschnitt anzugeben, aus dem die Information stammt“, wird eine plausibel klingende Antwort zu einer, die tatsächlich überprüft werden kann. Wenn es keine Quelle angeben kann, sollte man das als Signal betrachten, innezuhalten und die Information manuell zu überprüfen.
27. Setzen Sie menschliche Kontrollpunkte vor irreversible Aktionen
Jede Aufgabe, bei der E-Mails gesendet, Code kommittet oder Geld ausgegeben wird, sollte einen ausdrücklichen Stoppschritt beinhalten: „Stoppen Sie vor der endgültigen Aktion und zeigen Sie mir, was Sie vorhaben.“ Kein System – und keine Selbstsicherheit in der eigenen Urteilsfähigkeit, selbst spät nachts – ist zuverlässig genug, um diesen Schritt zu überspringen.
28. Erkennen Sie, wann ein riesiger Prompt nicht der richtige Ansatz ist
Große Kontextfenster machen es verlockend, einfach jedes Dokument hineinzupacken und auf das Beste zu hoffen. Manchmal funktioniert das gut. Oft jedoch übertrifft ein kürzerer, sorgfältig ausgewählter Prompt, der nur die drei relevanten Abschnitte enthält, die Verwendung des gesamten Dokuments, denn so wird das Modell nicht gezwungen, gleichzeitig zu sortieren und zu analysieren. Wählen Sie zunächst die Eingabedaten sorgfältig aus und wenden Sie das Einfügen aller Inhalte nur an, wenn Sie tatsächlich noch nicht wissen, was relevant ist.
29. Kontrollieren Sie Ihre Prompts wie Codeversionen
Sobald ein Prompt für regelmäßige, wiederkehrende Aufgaben verwendet wird – beispielsweise zur Erstellung von Berichten oder Kundenergebnissen – speichern Sie ihn in einer Datei mit einem Datumsstempel und einer kurzen Änderungsprotokoll-Eintragung. Das mag anfangs übertrieben erscheinen, bis plötzlich eine „kleine Anpassung“ ein Verhalten, auf das Sie angewiesen waren, stört und Sie keine Aufzeichnung davon haben, wie der Prompt in der Vorwoche aussah.
30. Führen Sie den Workflow lokal aus, wenn Sie die Kosten pro Token vermeiden oder Daten von externen Servern fernhalten möchten
Keine dieser Techniken erfordert zwingend eine gehostete API. Bei Aufgaben, an denen Sie wiederholt arbeiten – wie dem Testen einer Selbstbewertungsrubrik oder des oben beschriebenen Plans/Handeln/Überprüfen-Loops – macht es oft Sinn, zunächst mit einem lokalen Modell über Ollama ein Prototyp zu erstellen und den fertigen Prompt anschließend für die endgültige Bearbeitung an Claude zu übertragen. Auf diese Weise sind Iterationen günstiger, und solange Sie den Prompt noch formen, verlässt nichts Ihren Rechner.
Gehostete Version für einen schnellen Test mit der Claude API:
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 500,
"messages": [{"role": "user", "content": "Score this draft 1-10 on clarity, then revise it: [paste draft]"}]
}'
Lokaler, selbst gehosteter Äquivalent unter Verwendung von Ollama – ohne API-Schlüssel und ohne Kosten pro Token:
# one-time setup
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
docker exec -it ollama ollama pull llama3.1
# same self-evaluation prompt, run locally
curl http://localhost:11434/api/generate -d '{
"model": "llama3.1",
"prompt": "Score this draft 1-10 on clarity, then revise it: [paste draft]",
"stream": false
}'
Ein lokales Modell kann nicht die Feinheiten von Claude erreichen, doch für die Anpassung der Prompt-Struktur – zum Überprüfen, ob eine Bewertungskriterienliste korrekt formatiert ist oder ob eine Einschränkung tatsächlich eingehalten wird – reicht es mehr als aus, und es kostet nichts, sobald es eingerichtet ist.
Kurzfassung: Aufwand versus Ertrag
Hier ist eine grobe Rangliste, die zeigt, welche Techniken tatsächlich die Qualität der Ausgabe verbessern und welche lediglich beeindruckend klingen:
TECHNIQUE EFFORT TO ADOPT PAYOFF
---------------------------------- ---------------- --------
Rules/context file (#24) low very high
Multi-persona debate (#19) low high
Plan-act-verify loop (#25) medium high
Prompt chaining (#17) low high
Permission to say "I don't know"(#6) trivial high
Explain the "why" (#5) trivial high
Reverse brainstorming (#18) low medium-high
Contract system prompt (#10) medium medium
"Act as an expert" persona (#11) trivial low
Falls Sie nur eine Sache aus dieser Liste mitnehmen wollen, konzentrieren Sie sich auf die Kategorie mit geringem Aufwand und hohem Ertrag: Fügen Sie Ihren Einschränkungen einen Grund hinzu und geben Sie dem Modell ausdrücklich die Erlaubnis, anzugeben, dass es es nicht weiß. Diese beiden kleinen Ergänzungen haben still und heimlich mehr schlechte Ausgaben behoben als jedes komplexe strukturelle Konzept.
Falls Sie mit einem Teil dieser Rangliste nicht einverstanden sind oder festgestellt haben, dass eine dieser Techniken in Ihrem konkreten Anwendungsfall tatsächlich schadet, ist ein solches Gegenbeispiel weitaus nützlicher als ein weiterer allgemeiner Beitrag über „Prompts, die Ihr Leben verändern“.