Prompts für den Produktivbetrieb entwerfen: System-, Entwickler- und Nutzerebene

Ein Prototyp kann mit einer Zeichenfolge direkt im Code beginnen. Produktionsdruck entsteht, sobald ein Prompt Zuständigkeit, Prüfung, Rollback, Datenverarbeitung, mehrere Funktionen oder Sprachen oder messbares Verhalten benötigt. Das kann bereits vor der Einführung geschehen und folgt keinem allgemeingültigen Zeitplan.

Sie möchten einen Teil der Anweisungen ändern, ohne andere anzutasten. Sie benötigen unterschiedliches Verhalten für verschiedene Kundentarife, möchten Versionen per A/B-Test vergleichen und bei Fehlern ein Rollback durchführen. Zudem müssen Sie wissen, wann und warum sich ein Prompt zuletzt geändert hat.

Ein Produktionsprompt-Design macht diese Entscheidungen ausdrücklich. Der Prompttext ist ein Artefakt innerhalb eines gesteuerten Freigabe- und Laufzeitsystems.

Der Artikel nutzt eine dreistufige redaktionelle Architektur, um Verantwortlichkeit und Änderungstakt zu erklären, und zeigt dann die Abbildung auf Anbieter-APIs. Es ist ein Referenzdesign, kein universelles Wire-Format. Nutzen Sie die OWASP-Leitlinien zur Prompt-Injection für die Sicherheitsgrenze: Die Trennung von Anweisungen und Daten unterstützt Prüfung und Bewertung, aber keine Prompt-Vorlage schafft eine Autorisierungs- oder Isolationsgrenze.

Produktionsprompts bestehen aus zwei getrennten Artefakten: wiederverwendbaren Vorlagen und Daten je Anfrage. Versionieren Sie Vorlagen wie Code. Behandeln Sie gerenderte Prompts und Modellantworten als sensible Logs, sobald sie Nutzer-, Kunden- oder interne Daten enthalten.

Drei redaktionelle Ebenen, auf eine API abgebildet

Dieses Design trennt drei redaktionelle Zuständigkeiten:

Systemebene. Relativ stabiles Verhalten, Identität und Einschränkungen. Verantwortet vom Team, das für das funktionsübergreifende KI-Verhalten zuständig ist.

Entwicklerebene. Funktionsspezifische Anweisungen, Richtlinie zur Werkzeugnutzung und Ausgabeanforderungen. Verantwortet vom Feature-Team.

Nutzer- und Laufzeitebene. Nutzeranfrage plus dynamischer Kontext wie autorisierte Kundendaten, Gesprächsverlauf und abgerufenes Wissen. Für eine Anfrage oder Gesprächsrunde zusammengesetzt.

Das Vermischen von Zuständigkeit, stabiler Richtlinie, Feature-Anweisungen und Laufzeitdaten kann Änderungen schwerer prüfbar, bewertbar, cachebar und rücksetzbar machen. Trennen Sie die Bereiche, wo dies die Kontrolle verbessert; erzwingen Sie keine drei API-Felder, wenn Anbieter oder Anwendung eine andere Darstellung haben.

Anweisungsautorität und Datenplatzierung hängen zusammen, sind aber verschieden. Die Vertrauenshierarchie bestimmt, welche Anweisung bei einem Konflikt gewinnt. Die Datenplatzierung bestimmt, wo die Anwendung dynamische oder nicht vertrauenswürdige Inhalte transportiert. Abgerufener Text wird in einem Nutzer- oder Kontextfeld weder autorisiert noch richtig oder sicher. Erzwingen Sie Identität, Mandantenzugriff, Datenminimierung, Werkzeugberechtigungen und Ausgabevalidierung außerhalb des Modells.

Die Trennung ist grundlegend:

┌─────────────────────────────────────┐
│ Systemebene (relativ stabil)        │  Identität, Verhalten, Richtlinienabsicht
├─────────────────────────────────────┤
│ Entwickler-Prompt (je Funktion)     │  Funktionsanweisungen, Werkzeuge, Format
├─────────────────────────────────────┤
│ Nutzer-Prompt (je Aufruf)           │  Nutzeranfrage, Kontext, Gespräch
└─────────────────────────────────────┘

Modell-APIs drücken diese Unterschiede auf verschiedene Weise aus:

• OpenAI: Verwenden Sie in der Responses API den obersten Parameter instructions oder eine developer-Nachricht für Anweisungen der Anwendung und eine user-Nachricht für Nutzereingaben. Gehen Sie bei einem selbst verwalteten mehrstufigen Ablauf nicht davon aus, dass Anweisungen aus einer früheren Antwort übernommen werden.
• Anthropic: Bilden Sie das Design auf die Claude Messages API, ihren Systemanweisungsmechanismus, Nachrichtenrollen und Werkzeugdefinitionen ab; unterstützte Rollenplatzierung kann je Modell und Plattform variieren.
• Gemini: Bilden Sie es auf system_instruction und Anfrageinhalte sowie die separate Werkzeugkonfiguration der gewählten API ab.

Nutzen Sie einen anbieterspezifischen Adapter und Integrationstests. Übertragen Sie Rollennamen nicht zwischen APIs unter der Annahme gleicher Priorität, Persistenz oder Werkzeugwirkung.

Ebene 1: Der Systemprompt

In diesem redaktionellen Muster definiert die Systemebene funktionsübergreifende Rolle und Verhalten. Ändern Sie sie möglichst seltener als Feature-Anweisungen, versionieren und bewerten Sie aber jede Änderung.

Ein guter Systemprompt umfasst:

Identität. Wer die KI ist. „Du bist ein KI-Assistent für [Unternehmen], der sich auf [Bereich] spezialisiert.“

Stimme und Stil. Wie sie klingen soll. Spezifische Merkmale, nicht vage Beschreibungen.

Erforderliche Verhaltensgrenzen. Was das Modell ablehnen, eskalieren, offenlegen oder formatieren soll. Erzwingen Sie Sicherheit, Berechtigungen und Kontrollen irreversibler Aktionen in Anwendungscode und nachgelagerten Systemen, nicht allein in diesem Text.

Verhaltensmuster. Wie sie übliche Situationen behandelt. Ablehnungen, Eskalationen, Unsicherheit.

Sicherheit und Compliance. Erforderliche Offenlegungen, regulatorische Regeln, Inhaltsrichtlinien.

Was er nicht enthalten sollte:

• Funktionsspezifische Anweisungen („für Verkaufs-E-Mails, mache X“).
• Dynamischen Kontext („die Bestellgeschichte des Nutzers ist…“).
• Tool-Beschreibungen (diese gehen anderswo hin).
• Dinge, die häufig geändert werden.

Ein Systemprompt sollte nur so lang sein, wie das bewertete Verhalten verlangt. Ein kurzer Prompt kann genügen und ein langer kann weiterhin wesentliche Regeln auslassen. Messen Sie Anweisungskonflikte, Aufgabenqualität, Latenz und Tokenkosten, statt eine Wortzahl anzustreben.

Eine Referenzvorlage:

Sie sind [name], ein KI-Assistent für [company / context].

## Ihre Rolle
[2-3 sentences on what you do]

## Ton und Stil
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Vermeiden Sie [anti-pattern 1]
- Vermeiden Sie [anti-pattern 2]

## Feste Vorgaben
- Niemals [hard rule 1]
- Niemals [hard rule 2]
- Immer [hard rule 3]

## Umgang mit Unsicherheit
- Wenn Ihnen eine Tatsache nicht bekannt ist, sagen Sie das ausdrücklich.
- Wenn eine Nutzeranfrage außerhalb des Aufgabenbereichs liegt, bieten Sie die Hilfe an, die Sie leisten können.
- Wenn eine Anfrage Schaden verursachen könnte, lehnen Sie sie ab und begründen Sie dies.

## Formatanforderungen
- Standardmäßig Klartext
- Markdown für Code oder strukturierte Daten verwenden
- Prägnant antworten und keine Füllsätze ergänzen

Dies kann die stabile, richtlinientragende Komponente des Promptdesigns sein. Bestätigen Sie mit Bewertungen und Telemetrie, dass das gewünschte Verhalten Feature-Anweisungen, lange Kontexte, Werkzeugresultate und adversariale Eingaben übersteht.

Ebene 2: Der Entwicklerprompt

Der Entwicklerprompt ist funktionspezifisch. Unterschiedliche Funktionen haben unterschiedliche Entwicklerprompts.

Ein Entwicklerprompt für eine Zusammenfassungsfunktion:

Aufgabe: Fassen Sie das folgende Dokument zusammen.

Anforderungen:
- 3-5 Aufzählungspunkte
- Jeder Aufzählungspunkt besteht aus einem vollständigen Satz
- Fakten und konkrete Aussagen statt Eindrücken hervorheben
- Wenn das Dokument Zahlen enthält, die wichtigsten davon aufnehmen
- Keine Marketingsprache und keine Spekulationen
- Auf wichtige Mehrdeutigkeiten im Dokument hinweisen

Format: einfache Markdown-Aufzählung ohne Einleitung.

Ein Entwicklerprompt für eine Code-Überprüfungsfunktion:

Aufgabe: Prüfen Sie den folgenden Code-Diff.

Geben Sie ein JSON-Objekt mit folgenden Feldern aus:
- summary: Überblick über die Änderung in 1-2 Sätzen
- concerns: Liste konkreter Probleme (jeweils mit file, line, severity und description)
- suggestions: Liste von Verbesserungen (jeweils mit file, line und suggestion)
- approved: boolescher Wert (true, wenn keine blockierenden Probleme vorliegen)

Schweregrade:
- "blocker": muss vor dem Merge behoben werden
- "warning": sollte behoben werden, blockiert den Merge aber nicht
- "nit": stilistischer, optionaler Hinweis

Prüfen Sie insbesondere:
- Logikfehler
- Sicherheitsprobleme
- Leistungsprobleme
- Fehlende Testabdeckung
- Unklare Benennungen oder Strukturen

Nicht prüfen:
- Formatierung (übernimmt der Formatter)
- Subjektive Stilpräferenzen

Jede Funktion hat ihren eigenen Entwicklerprompt. Sie werden getrennt gespeichert, getrennt versioniert und getrennt bewertet.

Ebene 3: Der Nutzerprompt

Die Nutzerebene ist dynamisch. Sie enthält typischerweise:

Die tatsächliche Anfrage des Nutzers. „Fassen Sie dieses Dokument für mich zusammen.“

Der vom System abgerufene Kontext. Dokumente aus RAG, Kundenhistorie und Gesprächsverlauf.

Variablen je Aufruf. Nutzername, Zeitzone, Sprachpräferenz und Kontotarif.

Diese Ebene wird programmatisch zum Zeitpunkt des Aufrufs konstruiert. Die Struktur sieht in der Regel so aus:

{conversation_history_summary}

{retrieved_context}

Nutzeranfrage: {user_query}

Zusätzlicher Kontext:
- Nutzername: {name}
- Zeitzone des Nutzers: {timezone}
- Nutzertarif: {tier}

Die genaue Struktur hängt von Funktion und Anbieter ab. Halten Sie flüchtige, nutzerspezifische und abgerufene Daten aus wiederverwendbaren Anweisungsvorlagen heraus, sofern der API-Vertrag keine andere Platzierung verlangt. Bewahren Sie unabhängig vom Transport Herkunft und wenden Sie Autorisierung, Minimierung, Abgrenzung und Validierung an.

Konsequentes Templating

Die Prompt-Zusammensetzung im Produktivbetrieb profitiert häufig von Vorlagen. Inline-Verkettung wird mit wachsenden Verzweigungen, Datenfeldern und Features schwerer prüf- und testbar.

Ein einfaches Vorlagen-System:

from string import Template

SUMMARIZE_TEMPLATE = Template("""
$conversation_summary

Document to summarize:
$document

User's specific instructions: $user_instructions
""")

prompt = SUMMARIZE_TEMPLATE.substitute(
    conversation_summary=summarize_conversation(history),
    document=document_text,
    user_instructions=user_query,
)

Für komplexere Fälle eignet sich eine Template-Bibliothek wie Jinja2 oder Handlebars mit Bedingungen und Teilvorlagen.

{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}

{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}

User's request: {{ user_query }}

Vorlagen halten die Promptstruktur konsistent, ermöglichen bedingte Logik und erleichtern das Abgrenzen oder Escapen von Nutzereingaben. Sie stoppen Prompt-Injection nicht von selbst; behandeln Sie nicht vertrauenswürdigen Text als Daten, niemals als Anweisungen.

Eine gesteuerte maßgebliche Quelle wählen

Behandeln Sie Produktionsprompts als versionierte Freigabeartefakte. Die maßgebliche Quelle kann ein Repository, ein eigenes Register oder ein Dienst oder ein verwaltetes Produkt mit Bearbeitungsoberfläche sein. Wählen Sie nach Governance- und Betriebsbedarf, nicht nach der Annahme, ein Speichermuster passe jedem Team.

Für codeverwaltete Prompts ist ein prompts/-Verzeichnis mit einer Datei je Prompt ein klarer Ausgangspunkt:

prompts/
  system/
    main.txt
    customer-support.txt
    code-assistant.txt
  features/
    summarize.txt
    classify-ticket.txt
    generate-email.txt
  templates/
    base.j2

Jede Datei kann eine eigene Commit-Historie und PR-Prüfung haben, während Produktiv-Deployments eine bekannte Codeversion referenzieren.

Warum das wichtig ist:

• Diff-Sichtbarkeit. Wenn ein Prompt geändert wird, ist der Diff in der PR. Prüfer können genau sehen, was geändert wurde.
• Rollback. Wenn eine Änderung einen Fehler verursacht, können Sie zur vorherigen Version zurückkehren.
• Historie. „Wann haben wir die Rückerstattungsrichtlinie im Prompt geändert?“ „Warum ist dieser Absatz hier?“ – beides lässt sich mit git blame beantworten.
• Tools. Linter, Validatoren, Eval-Suiten integrieren sich mit dateibasierten Prompts.

Vergleichen Sie die Hauptoptionen ausdrücklich:

Inline-Zeichenfolgen funktionieren für kleine Prototypen, sind aber schwerer zu finden und unabhängig freizugeben. Eine Bearbeitungsoberfläche kann passen, wenn Berechtigungen, Prüfung, Herkunft, Deployment und Rollback dem Risiko entsprechen. Aus Chats kopierte Prompts müssen denselben Prüf-, Bereinigungs- und Bewertungspfad wie andere Kandidaten durchlaufen.

Committen Sie keine Produktivgespräche, Kundendatensätze, Supporttickets, internen Dokumente oder gerenderten Prompts mit sensiblen Variablen. Die Versionsverwaltung ist für wiederverwendbare Vorlagen, Fixtures und bereinigte Eval-Beispiele bestimmt. Reale Traces gehören in ein Observability-System mit Aufbewahrungsregeln, Zugriffskontrolle und Schwärzung.

Laufzeitregister und Dienste

Wenn Prompt-Freigaben eine andere Taktung als Anwendungsdeployments brauchen oder autorisierte Redakteure eine kontrollierte Oberfläche benötigen, reicht ein Repository allein möglicherweise nicht. Ein Register oder Dienst kann zur Laufzeit eine freigegebene Version auswählen.

Ein bewährtes Muster ist eine Datenbank oder ein Service, der Promptversionen samt Metadaten speichert.

prompt = prompt_service.get(
    name="summarize",
    version="v3",
    locale="en",
    user_tier="enterprise",
)

Der Dienst sollte verwalten:

• Aktuelle und historische Versionen jedes Prompts.
• Metadaten: wann hinzugefügt, von wem, warum.
• Eval-Scores, die jeder Version zugeordnet sind.
• Rollback-Funktion.

Die Speicherengine ist nur ein Teil des Designs. Vergleichen Sie rollenbasierten Zugriff, Audit-Verlauf, authentifizierten Laufzeitzugriff, Umgebungspromotion, konsistente Bereitstellung, Rollback, Export, Verschlüsselung, Datenverarbeitung, Verfügbarkeit und Betriebskosten. Eine kleine Datenbank genügt nur, wenn die umgebenden Kontrollen die Anforderungen erfüllen.

Definieren Sie, wer entwerfen, prüfen, freigeben, veröffentlichen, zurückrollen und gerenderte Prompts lesen darf. Bearbeitungszugriff bedeutet nicht Produktivfreigabe. Sensible Workflows können getrennte Rollen, geschwärzte Vorschauen, doppelte Freigabe oder eine Oberfläche verlangen, die nie reale Kundendaten zeigt.

Durch Evals abgesicherte Änderungen

Promptänderungen, die Nutzerresultate, Werkzeugnutzung, Datenverarbeitung, Richtlinientreue oder nachgelagerte Entscheidungen beeinflussen können, sollten vor der Bereitstellung geprüft und risikogerecht bewertet werden. Eine risikoarme Textänderung kann einen kleinen Regressionstest brauchen; eine Promptänderung mit Einfluss auf Zahlung, Konto oder regulierte Entscheidung benötigt stärkere Offline-Fälle, adversariale Tests, Freigabe und gestufte Einführung. Definieren Sie einen Notfallpfad mit begrenzter Einführung, Monitoring, Freigabe und Rollback, statt das Gate still zu umgehen.

Der Ablauf:

1. Ein Engineer oder ein Fachanwender entwirft eine Promptänderung.
2. Die Änderung wird gegen die Eval-Suite getestet.
3. Eval-Ergebnisse werden zusammen mit der Änderung geprüft.
4. Wenn die Evals bestehen – ohne Regressionen und idealerweise mit Verbesserungen –, kann die Änderung genehmigt werden.
5. Genehmigte Änderungen werden deployed.
6. Nach der Bereitstellung erfasst das Monitoring Probleme, die von den Evals übersehen wurden.

Halten Sie für wesentliche Prompts einen repräsentativen Bewertungssatz vor und führen Sie stabile automatisierbare Kontrollen in CI aus, wenn ihr Signal zuverlässig genug ist. Verwenden Sie fachliche oder menschliche Prüfung, wenn das Abnahmekriterium nicht auf einen automatischen Wert reduziert werden kann. Dokumentieren Sie Tests, Schwelle, prüfende Person und verbleibende Unsicherheit.

Dieses Gate beweist keine Korrektheit. Es macht die Freigabeentscheidung prüfbar und schafft eine Basis, um Regressionen nach der Bereitstellung zu erkennen.

Eine praktische Freigabecheckliste

Bevor eine Promptversion produktiv geht, sollte eine kurze Checkliste verbindlich sein:

Die begleitende Checkliste, die von diesem Artikel verlinkt wird, verwandelt diese Prüfungen in eine wiederholbare Freigabeprüfung.

A/B-Tests in der Produktion

Für online experimentierbare Prompts kann ein gestufter Vergleich mit der aktuellen Version reale Signale über Offline-Evals hinaus liefern. Nutzen Sie Produktivverkehr nicht als ersten Sicherheitstest und setzen Sie Menschen nicht allein zur Datenerhebung einer wesentlich riskanteren Behandlung aus.

Beispielmuster, keine Standardverteilung:

• 95 % des Datenverkehrs verwenden den produktiven Prompt v3.
• 5 % erhält den neuen Kandidaten v4.
• Modellzugriff, Werkzeugberechtigungen und Aktionsgrenzen bleiben innerhalb der freigegebenen Produktivgrenze.
• Messen Sie Aufgabenerfolg, Sicherheits- und Richtlinienfehler, Nutzerfeedback, nachgelagerte Kennzahlen und geprüfte Eval-Werte für geeigneten Datenverkehr.
• Definieren Sie Mindeststichprobe, Abbruchbedingungen, verantwortliche Person und Ein-Schritt-Rollback vor Beginn.
• Entscheiden Sie nach ausreichender Evidenz, ob der Kandidat erweitert, überarbeitet oder beendet wird.

Bereitstellungsmechanismen sind eigene Feature Flags, Deployment-Konfiguration, ein freigegebenes Prompt-Register oder individuelles Routing.

Hinweise:

• A/B-Tests erfassen nur gemessene Signale. Ohne Nutzerfeedback oder nachgelagerte Konversionskennzahlen liefert ein A/B-Test wenig Erkenntnis.
• Statistische Signifikanz erfordert Volumen. Für Features mit geringem Datenverkehr sind A/B-Tests schwierig.
• Gleichzeitige Experimente können interagieren und die Zuordnung verfälschen; steuern Sie Überschneidungen bewusst.
• Berücksichtigen Sie Informations-, Einwilligungs-, Ausschluss- und Prüfpflichten für Produkt, Personengruppe und Rechtsraum. Folgenreiche oder irreversible Aktionen benötigen meist stärkere Freigabe und Reversibilität, als eine Verkehrsaufteilung bieten kann.

Observability für Prompts

Definieren Sie datenschutzsichere Telemetrie für jeden Produktionsworkflow. Erfassen Sie bei Aufrufen mit wesentlichen Auswirkungen genug der folgenden Daten, um das bereitgestellte Verhalten zu bestimmen und Fehler zu rekonstruieren:

• Welche Promptvorlage verwendet wurde (Name, Version).
• Welche Variablen eingesetzt wurden – mit Namen aus einer Positivliste und bei Bedarf geschwärzten Werten.
• Den vollständig gerenderten Prompt nur, wenn die Richtlinien dies erlauben; andernfalls eine geschwärzte, stichprobenweise erfasste oder gehashte Darstellung.
• Die Modellantwort, bei sensiblen Workflows geschwärzt oder nur stichprobenweise erfasst.
• Latenz, Token, Kosten.
• Nachgelagerte Signale (Nutzerfeedback, Erfolgskennzahlen).

Ziel ist, beantworten zu können, welche Version lief, welche autorisierte Evidenz sie erhielt, welche validierte Ausgabe sie erzeugte, welche Werkzeuge oder Richtlinien beteiligt waren und was nachgelagert geschah. Protokollieren Sie verborgenes Reasoning nicht als Ersatz für diese Tatsachen.

Speichern Sie die Daten in einer Datenbanktabelle oder einem Observability-Tool. Wenn Sie alles protokollieren, entstehen reale Kosten (Aufrufvolumen × Tokenanzahl × Speicherbedarf) und reale Datenschutzrisiken. Legen Sie je Workflow fest, welche Felder sicher gespeichert werden dürfen. Schwärzen Sie Secrets und personenbezogene Daten standardmäßig und wählen Sie kurze Aufbewahrungsfristen, sofern keine Compliance-Vorgabe längere Traces verlangt. Einige Teams erfassen nur Stichproben.

Bestimmen Sie Prüftakt und Stichprobe aus Volumen, Risiko, Änderungsrate, Vorfällen und rechtlichen Grenzen. Prüfen Sie geschwärzte oder anderweitig freigegebene Traces, nehmen Sie bekannte Randfälle auf und führen Sie bestätigte Fehler in Evals zurück. Eine Wochenstichprobe kann für einen Workflow passen und für einen anderen unangemessen oder unzureichend sein.

Prompt-Antimuster

Einige Muster zu vermeiden:

Antimuster 1: Ein nicht verantworteter Mehrzweck-Prompt. Ein großer Systemprompt, der verschiedene Features, Richtlinien, Beispiele und Laufzeitannahmen vereint, kann schwer prüf-, bewert- und rücksetzbar sein. Nicht die Länge ist der Defekt, sondern ungemessene Komplexität.

Lösung: Trennen Sie Komponenten nach Verantwortung und Änderungsgrenze, wo es hilft, entfernen Sie doppelte oder veraltete Anweisungen und vergleichen Sie das überarbeitete Design in repräsentativen Evals.

Antimuster 2: Inline-Zeichenfolgenkonkatenation.

prompt = "You are helpful. " + (
    "The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...

Fragil und schwer lesbar. Zeichenfolgenverkettung macht die Grenze zwischen Anweisungen und Daten schwerer prüfbar; dieselben Werte in einer Vorlage werden dadurch aber nicht automatisch unschädlich.

Lösung: Vorlagen-System.

Antimuster 3: Derselbe Prompt für zu viele Anwendungsfälle.

Ein einziger Prompt für einen „allgemeinen Assistenten“, der für E-Mail-Entwürfe, Code-Reviews, Kundensupport und Recherche verwendet wird, kann aufgabenspezifische Abnahmekriterien und Verantwortung verbergen.

Lösung: funktionspezifische Entwicklerprompts über einem gemeinsamen Systemprompt.

Antimuster 4: Hart codierte Prompts.

response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "You are a helpful assistant..."},
        {"role": "user", "content": query}
    ]
)

Der Prompt ist im Code verborgen. Er lässt sich weder ohne Deployment bearbeiten noch per A/B-Test prüfen oder unabhängig versionieren.

Lösung: extrahieren Sie ihn in eine Promptdatei oder einen Dienst.

Antimuster 5: Keine Eval-Abdeckung.

Ein Feature wird mit einem Prompt ausgeliefert, der nie systematisch getestet wurde. Qualität wird nur nach Gefühl beurteilt; Drift bleibt unsichtbar.

Lösung: Ergänzen Sie risikogerechte Eval-Abdeckung für relevante Verhaltensweisen einschließlich Fehler- und Eskalationsfälle.

Antimuster 6: Daten in den Systemprompt mischen.

Sie sind ein Assistent für John, einen Premiumkunden, der seit 2023 dabei ist, in Tallinn lebt und 47 offene Tickets hat.

Nun ändert sich das wiederverwendbare Anweisungspräfix bei jedem Aufruf; das kann Cache-Nutzung reduzieren und die Grenze zwischen Richtlinie und Kundendaten verwischen.

Lösung: Transportieren Sie dynamische Daten im Laufzeiteingabe- oder Kontextmechanismus des Anbieters mit Herkunft, Autorisierung und Minimierung. Leiten Sie Vertrauen nicht aus der Nachrichtenrolle ab.

Antimuster 7: Anweisungen in der Mitte verstecken.

Helfen Sie dem Nutzer bei seiner Anfrage. Bleiben Sie höflich. Formatieren Sie die Ausgabe als JSON. Verwenden Sie kein Markdown. Die Anfrage betrifft Preise; geben Sie Zahlen daher mit Bedacht an. Die Ausgabe soll 1-2 Sätze umfassen. Helfen Sie dem Nutzer jetzt.

Kritische Anforderungen sind für Prüfer schwerer zu finden und können mit benachbarter Prosa kollidieren.

Lösung: Gruppieren Sie kritische Anweisungen in einem klar beschrifteten Block, nennen Sie jede Regel einmal und testen Sie, ob das gewählte Modell sie in repräsentativen langen und adversarialen Kontexten befolgt.

Spezifische Muster für gängige Funktionen

Einige funktionspezifische Muster:

Klassifizierung

Aufgabe: Ordnen Sie den folgenden Text einer dieser Kategorien zu:
- billing: Zahlung, Rückerstattung, Abonnement
- technical: Fehler, Störung, Integrationsproblem
- account: Anmeldung, Passwort, Profiländerungen
- feature_request: Anfragen nach neuen Funktionen
- complaint: allgemeine Unzufriedenheit ohne konkretes, lösbares Problem

Geben Sie ein JSON-Objekt aus: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Zu klassifizierender Text:
{text}

Muster: aufgelistete Kategorien mit Definitionen, strukturierte Ausgabe sowie Felder für Konfidenz und Begründung.

Extraktion

Aufgabe: Extrahieren Sie strukturierte Daten aus dem folgenden Dokument.

Schema:
- vendor_name: Unternehmen, das die Rechnung ausgestellt hat
- invoice_number: wie im Dokument angegeben
- date: Format ISO 8601
- line_items: Liste aus {description, quantity, unit_price, total}
- subtotal, tax, total: Zahlen

Regeln:
- Wenn ein Feld fehlt, null verwenden
- Zahlen als Zahlen und nicht als Zeichenfolgen ausgeben
- Bei mehrdeutigen Fällen "needs_review": true setzen und eine Erklärung ergänzen

Dokument:
{document}

Muster: explizites Schema, Typanforderungen, Umgang mit fehlenden Daten und Eskalation bei Mehrdeutigkeit.

Generierung mit Stil

Aufgabe: Verfassen Sie einen Text im Format {format} zum Thema {topic} für {audience}.

Stil:
- {Specific style trait 1}
- {Specific style trait 2}
- Vermeiden: {anti-pattern 1}, {anti-pattern 2}

Vorgaben:
- Länge: {N} Wörter
- Enthalten: {required elements}
- Ausschließen: {forbidden elements}

Stilreferenz:
[Provide a sample of the desired voice]

Ausgabe: ausschließlich {format}, ohne Einleitung oder Nachbemerkung.

Muster: spezifische Stilmerkmale (nicht generisch), explizite Einschränkungen, Stimme mit Referenzbeispiel verankert.

Agenten-Schleife

Sie haben Zugriff auf die folgenden Werkzeuge:
{tool_descriptions}

Bei jedem Durchlauf:
1. Bestimmen Sie, was zu tun ist.
2. Entscheiden Sie, ob Sie ein Werkzeug benötigen. Wenn ja, rufen Sie es auf.
3. Prüfen Sie nach dem Ergebnis, ob Sie weitere Werkzeuge benötigen oder antworten können.
4. Erstellen Sie die endgültige Antwort, sobald genügend Informationen vorliegen.

Vorgaben:
- Höchstens 5 Werkzeugaufrufe pro Anfrage.
- Wenn Sie die Aufgabe nach 5 Aufrufen nicht abschließen können, erklären Sie, was fehlt.
- Erfinden Sie niemals Werkzeugnamen oder Argumente.
- Prüfen Sie Werkzeugergebnisse, bevor Sie danach handeln.

Nutzeranfrage:
{user_query}

Muster: gestuftes Verfahren zur Werkzeugnutzung, Werkzeugbudget, ausdrückliche Validierung und begrenzte Fehlerbehandlung.

Zusammenarbeit im Team

Produktionsprompts betreffen in der Regel mehrere Personen:

• Engineers integrieren Prompts in das System, pflegen Vorlagen und verwalten Deployments.
• Produkt definiert, was die Prompts erreichen sollen.
• Content/Marketing verantwortet Stimme und Stilrichtlinien.
• Fachexperten kennen die korrekten Anforderungen spezifischer Anwendungsfälle, etwa juristische Formulierungen oder medizinische Begriffe.

Ein hilfreiches Muster ist ein Prompt-Review ähnlich einem Code-Review, mit den zuständigen Prüfern für jeden Bereich. Änderungen an Tonalität und Sprache prüft das Content-Team, Logikänderungen das Engineering und fachspezifische Inhalte der jeweilige Experte.

Für sensible juristische, medizinische oder finanzielle Anwendungsfälle können Prompts eine formale Prüfung und Freigabe erfordern. Gestalten Sie den Prozess entsprechend.

Ein phasengesteuerter Plan für Prompt-Reife

Für Teams, die von „Prompts sind Zeichenfolgen in Code“ zu „Prompts sind verwaltete Infrastruktur“ wechseln:

Phase 1: Grundlage.

• Inventarisieren Sie Prompts und Code zur Prompt-Zusammensetzung, die das Verhalten wesentlich beeinflussen.
• Definieren Sie Anweisungsautorität, Laufzeitdatengrenze, Verantwortliche und Anbieterabbildung.
• Wählen Sie eine gesteuerte maßgebliche Quelle und einen zur Freigabe passenden Vorlagenansatz.
• Richten Sie datenschutzsichere Telemetrie ein, die bereitgestellte Version und Ergebnis ohne unnötige sensible Inhalte identifiziert.

Phase 2: Bewertung.

• Bauen Sie Eval-Suiten zuerst für Prompts mit hohem Risiko und Volumen.
• Führen Sie repräsentative Evals bei wesentlichen Änderungen aus, mit Fachprüfung, wo nötig.
• Legen Sie stabile automatisierte Prüfungen in CI und halten Sie nicht automatisierbare Abnahmeentscheidungen im Prüfvermerk sichtbar.

Phase 3: Betrieb.

• Implementieren Sie Prompt-Versionierung im gewählten Repository, Register oder Dienst.
• Ergänzen Sie gestufte Einführung und Stoppmechanismus; verwenden Sie A/B-Tests nur für geeignete Workflows.
• Bauen Sie Monitoring für die benötigten Qualitäts-, Sicherheits-, Richtlinien-, Latenz-, Kosten- und nachgelagerten Signale.
• Etablieren Sie einen Review-Prozess für Promptänderungen.

Versprechen Sie dieses Ergebnis nicht nach Kalender. Beenden Sie die Folge erst, wenn Tests zeigen, dass die Prompt-Erfassung vollständig ist, kritische Änderungen versioniert und gated sind, Rollback funktioniert, Telemetrie die bereitgestellte Version erkennt und Verantwortliche eine Vorfallreaktion proben können.

Prompts als Infrastruktur

Produktionsprompts können als Zeichenfolgen gespeichert sein, wirken aber als versionierte Systemkomponenten mit Kontrollen für Zusammensetzung, Bewertung, Freigabe, Zugriff und Beobachtbarkeit.

Eine Anweisungshierarchie definiert Autorität; sie sichert weder Laufzeitdaten noch Werkzeugaktionen. Vorlagen können Zusammensetzungsfehler reduzieren, verhindern aber keine Prompt-Injection. Eine gesteuerte maßgebliche Quelle liefert Versionshistorie. Risikogerechte Evals informieren Freigabeentscheidungen, und Telemetrie prüft das Verhalten außerhalb des Eval-Satzes.

Die erforderliche Strenge hängt von Risiko und Umfang ab; jede ausgelassene Kontrolle benötigt aber eine dokumentierte Begründung. Aussagen zur Produktionsreife sollten die tatsächlich vorhandene Evidenz für Versionierung, Bewertung, Einführung, Rollback und Telemetrie zeigen.

Die gewünschte Steuerbarkeit bleibt eine Hypothese, bis Evals und Produktionstelemetrie zeigen, dass Modell, Prompt-Version, Datenpfad, Werkzeuge und Richtlinien innerhalb der Abnahmeschwellen arbeiten. Bewahren Sie diese Evidenz mit der Freigabe auf, untersuchen Sie Fehler nach Version und halten Sie Rollback nutzbar.

Beginnen Sie mit der kleinsten Architektur, die Verantwortung, Autorität, Datenbehandlung, Bewertung, Bereitstellung, Rollback und Evidenz ausdrücklich macht.