Präzises Prompting ist Kontextspezifikation
20. Juni 2026 · 10 Min. Lesezeit
Abstract
Für Prompting gibt es eine bekannte Einsteiger-Checkliste: Aufgabe, Zielgruppe, Ton, Rolle, Kontext, Einschränkungen, Beispiele und Ausgabeformat definieren. Das ist nützlich. Es reicht aber nicht.
Meine Hypothese ist: Präzises Prompting wird weniger zu einer universellen Checkliste und stärker zu der Frage, welche Details für ein bestimmtes Modell, eine bestimmte Aufgabe, einen Workflow, ein Risiko und eine Bewertungsmethode tatsächlich relevant sind. Anders gesagt: Prompt-Präzision ist nicht Prompt-Länge. Es ist Passung.
Dieser Artikel betrachtet Praxisleitfäden von OpenAI, Anthropic und Microsoft sowie wissenschaftliche Arbeiten zu Prompt-Taxonomien, Prompt Patterns, automatischem Prompt Engineering, Software-Engineering-Aufgaben und Context Engineering. Die Quellen zeigen in dieselbe Richtung: Welche Details in einem Prompt nützlich sind, hängt stark vom Kontext ab. Ein Prompt für strukturierte JSON-Extraktion braucht andere Details als ein Prompt für juristische Synthese, Frontend-Generierung, Tutoring, Agenten mit Tools oder Code-Reparatur.
Die These ist noch eine Arbeitshypothese. Aber sie ist bereits praktisch brauchbar.
Das Problem mit der Prompt-Checkliste
Die meisten Menschen, die LLMs länger als ein paar Wochen nutzen, kennen die Standardratschläge.
Sag dem Modell, was du willst. Gib ihm eine Rolle. Definiere die Zielgruppe. Lege den Ton fest. Gib Beispiele. Beschreibe das Ausgabeformat. Ergänze Einschränkungen.
Das ist nicht falsch. Es ist ein ordentlicher Einstieg. Aber als ich begann, LLMs zu nutzen, um detailliertere Prompts zu schreiben, fiel mir etwas leicht Ärgerliches und ziemlich Interessantes auf: Die Liste der nützlichen Details änderte sich ständig.
Für eine Literaturübersicht waren Quellenhierarchie, Zitierstil, Unsicherheitssprache und die Trennung von Evidenz und Interpretation entscheidend.
Für eine Frontend-Aufgabe waren Viewport-Verhalten, vorhandenes Designsystem, Interaktionszustände, Barrierefreiheit und visuelle Assets entscheidend.
Für einen Agenten-Workflow waren Tool-Berechtigungen, Freigabegrenzen, Abbruchkriterien, Verifikationsschritte und zu erhaltender Zustand entscheidend.
Dasselbe Wort: "Prompt". Aber ein sehr anderes Engineering-Objekt.
Die eigentliche Frage lautet daher nicht, ob ein Prompt "mehr Details" enthalten soll. Das ist zu grob. Die bessere Frage ist:
Welche Details sind für diese Aufgabe operativ relevant?
Ein Detail ist operativ relevant, wenn seine Aufnahme die Wahrscheinlichkeit verändert, dass das Modell ein akzeptables Ergebnis liefert.
Das klingt etwas formal, ist aber wichtig. Ein langer Prompt kann trotzdem vage sein. Ein kurzer Prompt kann präzise sein. Entscheidend ist, ob der Prompt die Variablen benennt, die das Modell tatsächlich steuern.
Wie ich die Quellen betrachtet habe
Dies ist eine narrative Literaturübersicht, keine Benchmark-Studie. Ich habe Quellen gesucht, die eine von fünf Perspektiven abdecken:
| Quellentyp | Beispiele | Warum es relevant ist |
|---|---|---|
| Modelldokumentation | OpenAI, Anthropic, Microsoft | Zeigt, wie sich Prompting-Hinweise je nach Modell, Workflow und Ausgabe ändern |
| Prompt-Taxonomien | The Prompt Report und verwandte Surveys | Zeigt Prompting als großen Designraum, nicht als kleines Rezept |
| Prompt-Pattern-Forschung | White et al. | Behandelt Prompts als wiederverwendbare Muster, die dennoch angepasst werden müssen |
| Optimierung und Empirie | APE, Studien zu Software-Engineering-Prompts | Zeigt, dass Prompt-Details getestet und gegen Ergebnisse verbessert werden können |
| Context Engineering | Neuere Surveys zu Context Engineering | Verschiebt den Fokus von Formulierung zum gesamten Informationspaket |
Das Ziel war nicht zu beweisen, dass jeder Prompt komplex sein muss. Eher im Gegenteil. Die nützliche Aussage ist enger: Die richtigen Details hängen von der Arbeit ab, die der Prompt leisten soll.
Was die Anbieter-Dokumentation bereits nahelegt
Die aktuellen OpenAI-Dokumente zu Prompt Engineering und Prompt Generation zeigen beide Seiten des Problems. Es gibt allgemeine Hinweise, aber die Empfehlungen werden schnell ausgabespezifisch. Der Prompt-Generation-Guide behandelt zum Beispiel Ausgabetyp, Schemas, Beispiele, Reihenfolge von Begründung und Ergebnis, Konstanten und Aufgabenkomplexität als Variablen, die geprüft werden müssen, nicht als starre Vorlage [1][2].
Anthropic formuliert besonders klar, dass man mit Erfolgskriterien beginnen sollte. Die Übersicht zu Prompt Engineering sagt, dass man vor der Verbesserung eines Prompts klare Erfolgskriterien, eine Testmöglichkeit und einen ersten Prompt-Entwurf haben sollte [3]. Das ist wichtig. Prompting wird dadurch als Iteration gegen ein Ziel verstanden, nicht als magische Formulierung.
Die Best-Practices von Anthropic unterscheiden dann viele Situationen: Beispiele, XML-Struktur, Rollen, langer Kontext, Ausgabeformat, Tool-Nutzung, Thinking, agentische Systeme, Frontend-Arbeit, Migration zwischen Modellversionen und mehr [4]. Das klingt weniger nach "hier ist die eine Prompt-Formel" und mehr nach "unterschiedliche Aufgaben legen unterschiedliche Steuerungsflächen frei".
Die Microsoft-Dokumentation zu Azure OpenAI ergänzt eine hilfreiche Warnung: Prompt-Konstruktion sei eher Kunst als Wissenschaft, und unterschiedliche Modelle verhalten sich unterschiedlich [5]. Das ist keine Ausrede für schlampiges Prompting. Es ist ein Grund, Prompts zu testen statt sie zu verehren.
| Signal aus der Dokumentation | Was es nahelegt |
|---|---|
| OpenAI trennt Prompt-Erzeugung nach Aufgabe, Ausgabetyp, Schema und Beispielen | Prompt-Details sollten nach erwartetem Output und Constraints ausgewählt werden |
| Anthropic beginnt mit Erfolgskriterien und empirischen Tests | Ein Prompt ist eine Hypothese darüber, was das Modell braucht |
| Anthropic hat eigene Hinweise für langen Kontext, Tools, Agenten und Frontends | "Gutes Prompting" zerfällt nach Workflow-Typ |
| Microsoft warnt vor begrenzter Übertragbarkeit zwischen Modellen | Präzision ist auch modellabhängig |
Die Forschung macht den Designraum sichtbar
Die stärkste wissenschaftliche Unterstützung liegt in der Breite des Feldes selbst.
The Prompt Report katalogisiert 58 LLM-Prompting-Techniken und 40 Techniken für andere Modalitäten [6]. Das ist keine Einsteigerliste. Es zeigt, dass unter dem Begriff Prompting viele verschiedene Probleme gelöst werden.
Der Prompt-Pattern-Katalog von White et al. ist aus einem anderen Grund nützlich [7]. Er behandelt Prompts ähnlich wie Software-Patterns: wiederverwendbare Lösungen für wiederkehrende Probleme in einem bestimmten Kontext. Genau diese letzte Einschränkung zählt. Ein Pattern ist wiederverwendbar, aber nicht kontextfrei.
Automatic Prompt Engineer geht noch einen Schritt weiter. Zhou et al. behandeln Instruktionen als Kandidaten, die erzeugt, bewertet und anhand der Aufgabenleistung ausgewählt werden können [8]. Das ist ein anderes Denken als "einen schönen Prompt schreiben". Prompt-Qualität hängt von Aufgabe, Bewertungsfunktion und Suchraum ab.
Auch die Software-Engineering-Studie von Shin et al. passt dazu. Sie vergleicht Basic Prompting, In-Context Learning und aufgabenspezifisches Prompting für Code-Generierung, Code-Zusammenfassung und Code-Übersetzung. Prompt Engineering schlägt Fine-Tuning nicht in jeder Situation, und konversationelles Prompting verbessert sich, wenn Menschen Kontext, Feedback und spezifische Anweisungen ergänzen [9].
Das entspricht der Alltagserfahrung. Man erkennt, was im Prompt fehlt, indem man sieht, wie das Modell scheitert.
Detail-Elemente ändern sich mit der Aufgabe
Praktisch sieht das so aus:
| Aufgaben-Kontext | Details, die oft wichtig werden |
|---|---|
| Synthese langer Dokumente | Quellenhierarchie, Zitatregeln, Metadaten, Umgang mit Widersprüchen, Zitierregeln |
| Code-Generierung | Repo-Konventionen, Ziel-Dateien, Tests, Architektur, Abhängigkeiten, Security-Constraints |
| Frontend-Generierung | Designsystem, Responsiveness, Interaktionszustände, Barrierefreiheit, visuelle Assets |
| Rechts- oder Policy-Analyse | Jurisdiktion, Datum, Autorität der Quelle, Unsicherheitssprache, Eskalationsgrenzen |
| Strukturierte Extraktion | Schema, erlaubte Werte, Null-Regeln, Validierung, Edge Cases |
| Tutoring | Lernniveau, Fehlvorstellungen, Tempo, Feedback-Stil, wann Fragen gestellt werden |
| Agentische Tool-Nutzung | Tool-Berechtigungen, Freigaberegeln, Abbruchkriterien, Verifikationsbefehle, Audit-Evidenz |
| Kreative Arbeit | Genre, Zielgruppe, Stimme, Negativbeispiele, Constraints, Neuheitskriterien |
Eine generische Checkliste sagt: "Kontext hinzufügen." Gut. Aber in einer Codebase kann Kontext die lokale Architektur und der Testbefehl sein. In einer juristischen Zusammenfassung können es Jurisdiktion und Datum der Regelung sein. In einer Extraktionsaufgabe können es Schema und Regeln für fehlende Felder sein.
Das Wort bleibt gleich. Das Detail-Array nicht.
Prompt-Präzision ist nicht Ausführlichkeit
Hier laufen viele Diskussionen über Prompting schief.
Menschen hören "sei präzise" und übersetzen es mit "füge mehr Anweisungen hinzu". Manchmal hilft das. Oft entsteht nur ein längerer Prompt mit mehr Stellen, an denen Anweisungen kollidieren.
Die bessere Definition ist:
Präzises Prompting ist die Auswahl von aufgabenrelevantem Kontext, Constraints, Beispielen und Bewertungskriterien, die das Modellverhalten tatsächlich beeinflussen.
Damit ist Präzision von Länge getrennt.
Ein Prompt wie "schreibe in professionellem Ton für ein allgemeines Publikum" ist nicht präzise, wenn das eigentliche Problem Zitattreue ist. Ein Prompt wie "extrahiere Claims als JSON mit claim, source_quote, confidence und needs_verification; nutze null, wenn die Quelle nichts sagt" kann präzise sein, obwohl er kurz ist.
Der eine Prompt klingt glatt. Der andere verändert Verhalten.
Context Engineering ist der größere Rahmen
Die neuere Context-Engineering-Literatur beschreibt denselben Gedanken auf einer größeren Ebene. Mei et al. verstehen Context Engineering als Optimierung des Informationspakets, das einem LLM gegeben wird, einschließlich Retrieval, Kontextverarbeitung, Memory, Tools, RAG-Systemen, tool-integriertem Reasoning und Multi-Agent-Systemen [10].
Der Begriff kann schnell modisch und unscharf werden. Aber der Kern ist nützlich: Der sichtbare User-Prompt ist nur ein Teil des Kontextfensters.
In einer ernsthaften LLM-Anwendung erhält das Modell möglicherweise auch:
- Systemanweisungen
- Developer-Anweisungen
- abgerufene Dokumente
- Memory
- Tool-Definitionen
- Policy-Regeln
- User-Präferenzen
- Beispiele
- Schemas
- vorherige Ausgaben
- Bewertungsrubrics
Wenn man dieses ganze Paket sieht, wirkt die alte Prompt-Checkliste zu klein. Die Aufgabe ist nicht nur, die Anfrage gut zu formulieren. Die Aufgabe ist, die Informationsumgebung zusammenzustellen, in der das Modell die Aufgabe lösen kann.
Ein kleines Modell für präzises Prompting
Aus den Quellen ergibt sich ein einfaches Arbeitsmodell. Ich würde es noch nicht Theorie nennen. Eher ein praktisches Gerüst.
| Ebene | Frage | Beispiel |
|---|---|---|
| Aufgaben-Fit | Was macht die Ausgabe korrekt oder nützlich? | Primärquellen zitieren, nicht nur zusammenfassen |
| Modell-Fit | Was braucht dieses Modell, um sich gut zu verhalten? | Frontend-Features müssen explizit gewünscht werden |
| Workflow-Fit | Welche Tools, Dateien oder Zustände sind beteiligt? | Dateien lesen ja, Schreiben nur nach Freigabe |
| Risiko-Fit | Was kann schiefgehen, wenn das Modell selbstsicher handelt? | Juristische Unsicherheit muss markiert werden |
| Evaluations-Fit | Wie wird Erfolg geprüft? | JSON validiert, Tests laufen, Zitate stützen Claims |
Das erklärt auch, warum LLM-gestütztes Prompt-Schreiben nützlich sein kann. Wenn ich ein LLM bitte, einen Prompt zu verbessern, schlägt es oft Kategorien vor, die ich vergessen habe: Edge Cases, Bewertungsrubrics, Quellenpolitik, Negativbeispiele, Failure Modes, Tool-Berechtigungen.
Aber diese Vorschläge sind nicht automatisch richtig. Es sind Kandidaten. Sie müssen getestet werden.
Was das praktisch bedeutet
Wenn du eine Prompt-Bibliothek pflegst, speichere nicht nur den finalen Prompt. Speichere Aufgabentyp, Modell, Erfolgskriterien, bekannte Failure Modes und den Grund, warum bestimmte Details enthalten sind.
Wenn du ein LLM bittest, einen Prompt zu verbessern, frage nicht nur nach "einem besseren Prompt". Bitte es, die Detailkategorien zu identifizieren, die wahrscheinlich das Ergebnis beeinflussen.
Wenn ein Prompt scheitert, mach ihn nicht sofort länger. Frage, welche Art von Kontext gefehlt hat.
Manche Prompts brauchen Beispiele. Manche brauchen ein Schema. Manche brauchen eine Quellenhierarchie. Manche brauchen eine Tool-Policy. Manche brauchen eine stärkere Definition of Done. Manche brauchen weniger Instruktion, weil das Modell sich zu stark an Constraints klammert.
Das ist der etwas unbequeme Teil: Gutes Prompting ist nicht eine Fähigkeit. Es ist eine Familie kleiner diagnostischer Fähigkeiten.
Grenzen
Dieser Artikel ist im richtigen Sinne spekulativ: Er beginnt mit einer praktischen Beobachtung und prüft, ob die Literatur in dieselbe Richtung zeigt. Das tut sie. Aber das ist kein kontrolliertes Experiment.
Der nächste sinnvolle Schritt wäre, "Detail-Elemente" zu operationalisieren und über Aufgabenfamilien hinweg zu testen. Verbessert eine Zitierpolitik Literaturübersichten stärker als Tonvorgaben? Ist Schema-Detail für Extraktion wichtiger als Beispiele? Welche Prompt-Details übertragen sich zwischen Modellfamilien, und welche brechen?
Das wäre ein guter Benchmark. Und ein unordentlicher, weil echte Prompts voller interagierender Details sind.
Fazit
Die Literatur stützt die Hypothese: Prompting bewegt sich von universeller Checklistenberatung hin zu Kontextspezifikation.
Die Einsteiger-Checkliste bleibt hilfreich. Aufgabe, Zielgruppe, Ton, Beispiele und Ausgabeformat sind vernünftige Defaults. Aber fortgeschrittenes Prompting beginnt dort, wo wir nicht mehr fragen "Was braucht jeder Prompt?", sondern "Was muss das Modell für diese Aufgabe wissen, einschränken, nutzen, vermeiden und belegen?"
Das ist die Verschiebung.
Präzises Prompting bedeutet nicht, überall Details hinzuzufügen. Es bedeutet, die Details zu finden, die das Ergebnis verändern.
Referenzen
[1] OpenAI, Prompt engineering, OpenAI API documentation.
[2] OpenAI, Prompt generation, OpenAI API documentation.
[3] Anthropic, Prompt engineering overview, Claude API documentation.
[4] Anthropic, Prompting best practices, Claude API documentation.
[5] Microsoft, Prompt engineering techniques, Microsoft Learn.
[6] S. Schulhoff et al., The Prompt Report: A Systematic Survey of Prompting Techniques, arXiv:2406.06608, 2024.
[7] J. White et al., A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, arXiv:2302.11382, 2023.
[8] Y. Zhou et al., Large Language Models Are Human-Level Prompt Engineers, arXiv:2211.01910, 2022.
[9] J. Shin et al., Prompt Engineering or Fine Tuning: An Empirical Assessment of Large Language Models in Automated Software Engineering Tasks, arXiv:2310.10508, 2023.
[10] L. Mei et al., A Survey of Context Engineering for Large Language Models, arXiv:2507.13334, 2025.