7 System-Prompt-Beispiele für die Produktion: Copy-Paste-Vorlagen (2026)

Die besten System-Prompt-Beispiele sind nicht die „Du bist ein hilfreicher Assistent"-Einzeiler aus Tutorials. Es sind die konkreten Anweisungsblöcke, die eine Produktivanwendung um 2 Uhr nachts vor dem Entgleisen bewahren. In unserer eigenen Content-Pipeline laufen mehr als ein Dutzend Claude-Subagenten, jeder gesteuert von einem System-Prompt, den wir immer wieder umgeschrieben haben, nachdem er einen Bug bei Claude Opus 4.8 oder GPT-5 verursacht hat. Dieser Beitrag verzichtet auf Spielzeug-Demos. Sie bekommen 7 echte, copy-paste-fertige System-Prompts, zwei davon direkt aus diesem Produktions-Stack, plus die 6-Block-Anatomie, die jedem verlässlichen System-Prompt zugrunde liegt.

Key Takeaways

• Ein System-Prompt besteht aus dauerhaften Anweisungen (Rolle, Einschränkungen, Ausgabeformat, Guardrails), die einmalig vor jeder Nutzernachricht festgelegt werden.
• Ist der Inhalt bei 1.000 Anfragen identisch, gehört er in den System-Prompt; alles, was sich pro Anfrage ändert, gehört in den User-Turn.
• Sechs Bausteine ergeben einen verlässlichen Prompt: Rolle, Kontext, Einschränkungen, Ausgabeformat, Guardrails, Beispiele.
• Reasoning-Modelle (o-Serie, GPT-5, Claude Opus 4.5+) wollen übergeordnete Ziele, keine aggressive „Du MUSST"-Formulierung.

Was gehört in einen System-Prompt? Die 6 Bausteine

Ein System-Prompt ist eine Reihe dauerhafter Anweisungen, die Rolle, Verhalten, Einschränkungen und Ausgabeformat eines Modells für eine ganze Sitzung festlegen – einmalig, bevor die erste Nutzernachricht eintrifft. Die verlässlichen Varianten teilen sich sechs Bausteine: Rolle, Kontext, Einschränkungen, Ausgabeformat, Guardrails und optional Beispiele. Bringen Sie diese in die richtige Reihenfolge, und Sie haben die Kurzfassung davon, wie man einen System-Prompt schreibt, der die Produktion übersteht.

Hier sehen Sie, was jeder Baustein leistet.

Der Rollen-Baustein ist wichtiger, als er aussieht. Anthropics Dokumentation sagt es unverblümt: Das Festlegen einer Rolle im System-Prompt schärft Verhalten und Ton des Modells, und "schon ein einziger Satz macht einen Unterschied". Für den Guardrails-Baustein verdienen Ablehnungs- und Sicherheitsregeln echte Sorgfalt; dazu gehen wir in unserem Guardrails-Leitfaden in die Tiefe. Und wenn Sie Claude anbinden: Anthropic empfiehlt XML-Tags (<instructions>, <context>, <input>), um jede Art von Inhalt zu trennen, damit das Modell sie nicht vermischt.

Hier ist ein copy-paste-fertiges Grundgerüst, das alle sechs Bausteine zu einer Vorlage zusammenfügt:

# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.

# CONTEXT
{Stable facts the model needs on every request.}

# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.

# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}

# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.

# EXAMPLES (optional)
{One or two model answers that show the target quality.}

Sechs Bausteine machen aus einem Bauchgefühl eine Spezifikation. Das betrifft ausschließlich die System-Prompt-Ebene. Für die umfassenderen Techniken (Few-Shot, Chain-of-Thought, Prompt Chaining) lesen Sie unseren Prompt-Engineering-Leitfaden – die gehören nicht in den System-Prompt selbst. Ein sitzungsbezogener System-Prompt unterscheidet sich außerdem von einer Repo-weiten Datei mit dauerhaften projektweiten Anweisungen wie einer CLAUDE.md, die eine gesamte Codebasis regelt statt nur einer einzelnen API-Sitzung.

7 System-Prompt-Beispiele für die Produktion (copy-paste-fertig)

Hier sind 7 System-Prompt-Beispiele, die Sie noch heute in Ihren system-Parameter oder Ihre developer-Message einfügen können. Jedes zielt auf eine reale Aufgabe (Agent, RAG, Support, Coding, JSON, Content-QA, Übersetzung) und zeigt, warum seine Kernbausteine existieren. Die letzten beiden laufen in unserer eigenen Pipeline. Die Repos, aus denen Cursor- und Devin-Prompts durchgesickert sind, beweisen die Nachfrage; was niemand mitliefert, ist die Annotation, die erklärt, warum jeder Baustein da ist.

1. Autonomer Agent

Grenzen Sie die Rolle eng ein, legen Sie die Tool-Regeln klar fest und geben Sie eine Abbruchbedingung vor, damit er nicht endlos weiterläuft.

You are a research agent. Your only job is to answer the user's
question using the provided tools.

TOOLS: web_search, read_url, calculator.

RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.

STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
  human and explain why.

Warum es funktioniert: Die eng gefasste Rolle plus eine explizite Abbruchbedingung machen den Unterschied zwischen einem Agenten, der fertig wird, und einem, der Tokens in einer Endlosschleife verbrennt. Das ist der Kern guter Best Practices für Agent-System-Prompts.

2. RAG / Retrieval-Q&A

Bei Retrieval geht es vor allem darum, das Modell davon abzuhalten, aus dem eigenen Gedächtnis zu antworten. Eine einzige Regel reicht dafür.

You answer questions using ONLY the context provided below.

CONTEXT
{retrieved_chunks}

RULES
- If the answer is not in the context, say: "I don't have that
  in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].

OUTPUT
Two to four sentences, plain text, with citations.

Warum es funktioniert: „Nur aus dem Kontext" plus ein Zitierformat ist der günstigste Halluzinationsschutz, den Sie für einen RAG-System-Prompt schreiben können.

3. Kundensupport-Bot

Tonalität, ein Eskalationspfad und eine harte Geld-Regel halten einen Support-Bot hilfreich, ohne dass er Dinge verspricht, die er nicht halten kann.

You are a support agent for Northwind's billing team. Be warm,
brief, and factual.

CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.

CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.

GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
  human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.

Warum es funktioniert: Der Rückerstattungs-Guardrail und der Eskalations-Fallback verhindern die zwei Fehlermodi, wegen derer Support-Bots aus der Produktion genommen werden.

4. Coding-Assistent

Schränken Sie Ausgabeformat und Versionen ein, und lassen Sie ihn erklären, bevor er etwas ändert.

You are a coding assistant for a Next.js 15 + TypeScript codebase.

RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.

If a request is ambiguous, ask one clarifying question before editing.

Warum es funktioniert: „Diff statt vollständiger Dateien" plus eine Versionsobergrenze hält den Assistenten innerhalb Ihres Stacks. Prompt-Design für Coding-Agenten ist tief genug für einen eigenen Leitfaden, deshalb halten wir dieses Beispiel knapp.

5. Strukturierte Daten / JSON-Extraktion

Packen Sie das Schema in den Ausgabeformat-Baustein und verbieten Sie Fließtext. Das ist das Muster für verlässliche strukturierte Ausgaben.

You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.

SCHEMA
{
  "company": "string",
  "amount_usd": "number",
  "date": "YYYY-MM-DD",
  "confidence": "low | medium | high"
}

RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.

Warum es funktioniert: Ein wörtliches Schema plus „nur gültiges JSON" schlägt ein nur beschriebenes Format jedes Mal. Für Enforcement-Muster jenseits des Prompts (JSON-Schema-Validierung, tool-basierte Extraktion) lesen Sie unseren Leitfaden zu strukturierten Ausgaben.

6. Content-QA / Validator-Agent (aus unserer Produktions-Pipeline)

Dieser läuft in unserem eigenen Stack. Der System-Prompt unseres Validators ist ein Beispiel für negative Einschränkungen: Er sagt dem Modell exakt, was es NICHT schreiben soll, und ein Skript prüft die Regeln anschließend wortwörtlich.

You are a content QA agent. You check one blog draft against a
fixed style contract.

BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"

FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
  per 500 words of body.

ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
  exits non-zero on any hit. If it fails, the post does not publish.

Warum es funktioniert: Eine aufgezählte Verbotsliste plus ein Grep lässt sich durchsetzen, wie es „Buzzwords vermeiden" nie könnte. Mit einem Gefühl kann das Modell diskutieren; mit einem Exit-Code ungleich null nicht.

7. Übersetzungs-Agent (aus unserer Produktions-Pipeline)

Auch dieser ist unserer. Der Prompt des Übersetzers ist ein Ausgabeformat- und Vollständigkeitsvertrag mit einer Selbstprüfung, die das Modell auf die eigene Ausgabe anwendet.

You are an expert translator. You translate ONE blog post into ONE
target language.

COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.

DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
  "karşılaştırma" (Turkish), or "developpement" instead of
  "développement" (French), the translation is WRONG. Re-do it.

If you cannot meet the contract, report the problem. Do not ship a
truncated post.

Warum es funktioniert: Ein Vollständigkeitsvertrag plus ein konkretes Falsch-Ausgabe-Beispiel fängt genau die stillen Fehler ab, die eine vage Anweisung wie „genau übersetzen" durchlässt.

Was wir beim Einsatz von System-Prompts in der Produktion gelernt haben

Drei System-Prompt-Bugs in unserer eigenen Pipeline haben uns mehr beigebracht als jede Dokumentationsseite. Alle drei kamen von Anweisungen, die vernünftig klangen, aber nicht konkret oder überprüfbar waren. Hier ist, was in unseren 16+ Claude-Subagenten kaputtging, und der genaue Fix, der jedes Mal hielt. Das Muster ist immer dasselbe: weiche Regeln werden ignoriert, konkrete und extern geprüfte Regeln bleiben bestehen.

Der Verbotsliste-Bug. Wochenlang schlich sich leverage und robust immer wieder in die Entwürfe zurück, egal wie freundlich wir das Modell darum baten. Eine weiche „Buzzwords vermeiden"-Zeile brachte nichts. Der Fix war Beispiel #6: eine aufgezählte Verbotsliste im Prompt plus ein Skript, das die Ausgabe grept und bei jedem Treffer einen Exit-Code ungleich null liefert, dazu eine Gedankenstrich-Obergrenze von 3 pro 1.000 Wörter. Die Lektion: Vage Einschränkungen werden ignoriert; aufgezählte, extern geprüfte Einschränkungen bleiben bestehen.

Der Diakritika-Bug. Unser Übersetzer gab bei Türkisch, Französisch und Spanisch stillschweigend ASCII statt der echten Zeichen aus. Aus karşılaştırma wurde karsilastirma, und niemand bemerkte es, bis ein Muttersprachler es meldete. Der Fix war eine Tabelle mit nativen Zeichen im Prompt, ein explizites Falsch-Ausgabe-Beispiel und ein Grep nach dem Lauf (null native Zeichen bedeutet: neu übersetzen). Die Lektion: Geben Sie dem Modell ein konkretes Beispiel für den Fehler, nicht nur eine Regel.

Der Stable-ID-Bug. Das ist der teure. Ein System-Prompt, der bei jeder Neuübersetzung den lokalisierten Slug neu ableitete, ließ den Publisher ein zweites Live-Dokument pro Beitrag anlegen. Am 2026-06-13 haben wir 54 doppelte Live-Dokumente veröffentlicht und sie erst am 2026-07-05 wieder offline genommen – drei Wochen aufgeteilte Linkkraft und Duplicate-Content-Flags. Der Fix: Identität explizit fixieren und die bestehende ID wörtlich wiederverwenden. Ein System-Prompt, der seine eigenen IDs nicht-deterministisch neu generiert, produziert Duplikate; unserer hat 54 Live-Dokumente angelegt, bevor wir die ID fixiert haben.

Was sind die häufigsten Fehler bei System-Prompts?

Die häufigsten Fehler bei System-Prompts sind Textwüsten als Anweisung, widersprüchliche Regeln, ausschließlich negative Formulierungen, das Hineinstopfen von anfragespezifischem Kontext in einen statischen Prompt und ein fehlender Fallback. Bei den 2026er-Modellen kommt ein neuer Fehler hinzu: aggressive Großschreibung und „Du MUSST"-Formulierungen lösen bei Claude Opus 4.5+ mittlerweile übermäßige Reaktionen aus.

Hier die Kurzfassung der Fixes:

• Textwüste. Fix: In die sechs Bausteine aufteilen und stabile Inhalte zuerst platzieren.
• Widersprüchliche Anweisungen. Fix: eine Regel pro Zeile; Konflikte vor dem Go-Live auflösen.
• Ausschließlich negative Formulierungen. Fix: sagen, was zu tun ist, nicht nur, was zu vermeiden ist.
• Großschreibung und „MUSS"-Überladung. Bei Anthropics neueren Modellen geht das nach hinten los. Deren Dokumentation sagt inzwischen: Wo Sie früher „KRITISCH: Du MUSST dieses Tool verwenden" geschrieben hätten, reicht heute eine normale Formulierung wie „Verwende dieses Tool, wenn ...". Der Rat von 2025 ist jetzt selbst der Fehler.
• Dynamischer Kontext in einem statischen Prompt. Anfragespezifische Daten gehören in den User-Turn. Was wohin gehört, ist eine eigene Disziplin; unser Context-Engineering-Leitfaden behandelt das.
• Fehlender Fallback. Immer einen Ablehnungs- und Eskalationspfad definieren.
• Länge und Kosten ignorieren. Längere Prompts erhöhen bei jedem Aufruf Latenz und Token-Kosten; kürzen Sie auf das, was seinen Platz verdient.

Für die reinen Grundlagen zur Anweisungsklarheit ist OpenAIs Best-Practices-Artikel nach wie vor eine solide Checkliste.

Wie testen und iterieren Sie einen System-Prompt?

Testen Sie einen System-Prompt genauso, wie Sie Code testen. Bauen Sie ein kleines Golden Set aus Eingaben mit erwarteten Ausgaben und prüfen Sie die Modellantwort bei jeder Änderung dagegen. Testen Sie zwei Prompt-Versionen per A/B-Test auf denselben Eingaben und behalten Sie die, die mehr Checks besteht. Assertions schlagen bloßes Draufschauen jedes Mal.

Eine minimale Eval-Schleife sieht so aus:

# pseudo eval loop
for case in golden_set:
    out = model(system=PROMPT, user=case.input)
    assert is_valid_json(out)              # format check
    assert case.expected_field in out      # content check
    if case.no_context:
        assert "I don't have that" in out  # refusal check
# ship the prompt version that passes the most cases

Der Grep in Beispiel #6 ist die billigste Assertion, die Sie ausführen können: Sie kostet nichts und wird nie müde. Sobald Ihre Prompt-Bibliothek über eine Handvoll Einträge hinauswächst, versionieren und testen Sie Ihre Prompts mit echten Prompt-Management-Tools, statt zwischen Dateien hin- und herzukopieren. Der Punkt bleibt in jeder Größenordnung derselbe: Ändern Sie nie einen Produktions-Prompt ohne eine Prüfung, die Ihnen sagt, ob er dadurch besser oder schlechter geworden ist.

System-Prompt vs. User-Prompt vs. Developer-Message

Ein System-Prompt legt das feste Verhalten fest; ein User-Prompt trägt die Aufgabe der jeweiligen Anfrage; eine Developer-Message ist OpenAIs Rolle für Reasoning-Modelle, die App-Ebene-Anweisungen enthält und in der Befehlskette über den Nutzernachrichten steht. Anthropic verwendet stattdessen einen übergeordneten system-Parameter statt einer role: "system"-Nachricht. Hier ist die Dreiteilung, die Wettbewerber meist übersehen.

OpenAI ist bei der Rangfolge eindeutig: „Developer-Messages sind Anweisungen des Anwendungsentwicklers, die gegenüber Nutzernachrichten priorisiert werden". Versucht ein Nutzer also, Ihre App-Regeln zu überschreiben, gewinnt die Developer-Message in der Befehlskette.

Brauchen Reasoning-Modelle andere System-Prompts? (2026)

Ja. Reasoning-Modelle wie OpenAIs o-Serie, GPT-5 und Claude Opus 4.5+ wollen übergeordnete Ziele, keine Schritt-für-Schritt-Skripte. OpenAI vergleicht ein Reasoning-Modell mit einer erfahrenen Kollegin, der Sie die Details anvertrauen, gegenüber einem GPT-Modell, das sich wie ein Junior verhält, der explizite Anweisungen braucht.

Dieser Rahmen verändert, wie Sie den Prompt schreiben. Nennen Sie bei einem Reasoning-Modell das Ziel und die Einschränkungen und „vertrauen Sie darauf, dass es die Details selbst herausfindet"; bei einem GPT-Modell schreiben Sie die Schritte aus. Ein Reasoning-Modell zu überspezifizieren macht es oft schlechter statt besser.

Auf der Claude-Seite gibt es eine eigene Verschiebung für 2026. Weil Opus 4.5+ stärker auf den System-Prompt reagiert, lösen die alte Gewohnheit, CRITICAL: und MUST zu stapeln, jetzt übermäßige Reaktionen aus. Nehmen Sie diese Sprache zurück auf normale Formulierungen. Ein Hinweis zu den Kosten: Platzieren Sie stabile, wiederverwendete Inhalte am Anfang des Prompts, damit Prompt-Caching greifen und die Latenz bei wiederholten Aufrufen senken kann. Und falls Ihr Reasoning-Modell Schritt-für-Schritt-Arbeit leistet: Chain-of-Thought-Prompting ist ein eigenes Thema mit eigenem Leitfaden, das wir hier nicht neu erklären.

Wie Techsy das angeht

Bei Techsy bauen wir Agentensysteme für B2B-Kunden, und die oben gezeigten Validator- und Übersetzer-Prompts laufen genau in diesem Produktions-Stack. Wir behandeln jeden System-Prompt wie Code: versionieren, gegen ein Golden Set testen und die nicht verhandelbaren Regeln mit einem Skript statt mit Hoffnung durchsetzen. Wenn Sie ein LLM-Feature von der Demo in die Produktion bringen wollen und dabei Unterstützung bei der KI-Integration brauchen, holen Sie sich eine kostenlose Beratung.

Häufig gestellte Fragen

Was ist ein System-Prompt?

Ein System-Prompt ist eine Reihe dauerhafter Anweisungen, die einmalig vor jeder Nutzernachricht festgelegt werden und Rolle, Verhalten, Einschränkungen und Ausgabeformat des Modells für die gesamte Sitzung definieren. Es ist die feste „so verhält es sich"-Ebene, die identisch bleibt, während sich die anfragespezifischen Nutzernachrichten bei jedem Turn ändern.

Was ist der Unterschied zwischen einem System-Prompt und einem User-Prompt?

Der System-Prompt ist das feste „so verhält es sich", identisch bei jeder Anfrage; der User-Prompt ist das anfragespezifische „was zu tun ist". Eine einfache Faustregel: Wäre der Inhalt bei 1.000 Anfragen identisch, gehört er in den System-Prompt; alles, was sich pro Aufruf ändert, gehört in den User-Turn.

Was ist eine Developer-Message im Vergleich zu einem System-Prompt?

OpenAIs Reasoning-Modelle (o-Serie, GPT-5) nehmen eine developer-Message statt einer system-Nachricht entgegen. Sie enthält App-Ebene-Anweisungen, die in der Befehlskette über Nutzernachrichten stehen, und gewinnt daher, wenn ein Nutzer versucht, Ihre Regeln zu überschreiben. Anthropic behält einen einzigen übergeordneten system-Parameter statt einer rollenbasierten Nachricht.

Wie lang sollte ein System-Prompt sein?

So kurz wie möglich, solange Rolle, Einschränkungen, Ausgabeformat und Guardrails abgedeckt sind. Überlange Prompts erhöhen bei jedem Aufruf Token-Kosten und Latenz und können bei Claude Opus 4.5+ zusätzliches Reasoning übermäßig auslösen. Muss ein stabiler Prompt lang sein, platzieren Sie wiederverwendete Inhalte zuerst, damit Prompt-Caching die Kosten ausgleicht.

Funktionieren System-Prompts in ChatGPT/GPT und Claude gleich?

Gleiches Konzept, andere Mechanik. OpenAI verwendet eine system- oder developer-Rolle innerhalb des Nachrichten-Arrays, während Anthropic einen separaten übergeordneten system-Parameter nutzt und XML-Tags bevorzugt, um Anweisungen, Kontext und Beispiele zu trennen. Die Anweisungen selbst lassen sich zwischen den Anbietern übertragen; die technische Verdrahtung und die Formatierungskonventionen nicht.

Können Sie den System-Prompt mitten in einer Konversation ändern?

Über die API senden Sie bei jedem Aufruf die vollständige Nachrichten-Payload erneut, technisch können Sie den System-Prompt also zwischen Turns austauschen. Ihn mitten in der Konversation zu ändern, kann aber die Kontinuität brechen und das Modell bei seinen eigenen Regeln verwirren. Legen Sie ihn bevorzugt einmalig fest, oder wechseln Sie bewusst zu einem eigenständigen, aufgabenspezifischen Prompt.

Sollte ich XML-Tags oder Markdown in einem System-Prompt verwenden?

Anthropic empfiehlt für Claude XML-Tags, um Anweisungen, Kontext und Beispiele zu trennen, damit das Modell sie nicht vermischt. OpenAI-Modelle kommen gut mit Markdown und einfachen Überschriften zurecht. Richten Sie sich nach der Konvention des jeweiligen Anbieters, statt einen Stil über beide zu zwingen, und bleiben Sie innerhalb eines einzelnen Prompts konsequent bei Ihrer Wahl.

Brauchen Reasoning-Modelle andere System-Prompts?

Ja. Reasoning-Modelle wollen übergeordnete Ziele, so als würden Sie eine erfahrene Kollegin briefen, kein Schritt-für-Schritt-Micromanagement. Lassen Sie die aggressive Großschreibung und „Du MUSST"-Sprache weg, die bei neueren Modellen wie Claude Opus 4.5+ übermäßige Reaktionen auslöst, nennen Sie Ziel und Guardrails, und lassen Sie das Modell selbst den Weg dorthin planen.

Was sind die Bestandteile eines guten System-Prompts?

Sechs Bausteine: Rolle, Kontext, Einschränkungen, Ausgabeformat, Guardrails oder Fallbacks und optional ein paar Beispiele. Rolle und Einschränkungen leisten den größten Teil der Arbeit; der Ausgabeformat-Baustein macht Antworten parsebar; Guardrails legen fest, was an den Rändern passiert. Beispiele lohnen sich nur, wenn sich die Zielqualität schwer in Worten beschreiben lässt.