Prompts aufbauen: Aufgabe, Kontext, Beispiele und Grenzen

„Schreibe einen professionellen Text“ lässt viele Fragen offen. Für wen ist der Text gedacht? Welche Fakten sind freigegeben? Was soll nach dem Lesen geschehen? Welche Aussage wäre falsch? Ein umfangreicher Prompt wird nicht automatisch besser. Ein präziser Auftrag reduziert jedoch vermeidbare Missverständnisse.

Dieser Leitfaden entwickelt einen Auftrag für die fiktive Ankündigung einer Softwarewartung. Das Beispiel enthält bewusst bekannte Informationen und offene Fragen. Es zeigt, wie sich Ziel, Kontext, Beispiele und Grenzen verbinden lassen. Die Anbieterquellen wurden am 9. November 2026 geprüft. Die dargestellten Aufträge sind eigene Lehrbeispiele und keine dokumentierten Ergebnisse eines Kundentests.

1. Mit dem gewünschten Ergebnis anfangen

Der erste Satz sollte klären, welches Arbeitsergebnis benötigt wird. „Erstelle einen Entwurf für eine Wartungsankündigung an bestehende Geschäftskunden“ ist konkreter als „Hilf mir beim Marketing“. Der Satz legt Dokumentart, Reifegrad und Empfänger fest.

Ergänzen Sie den Zweck. Kunden sollen verstehen, welche Funktion betroffen ist und ob sie vorher etwas erledigen müssen. Dieser Zweck hilft bei der Auswahl der Informationen. Eine ausführliche Beschreibung der Unternehmensgeschichte trägt zu dieser Aufgabe wahrscheinlich wenig bei.

Die offizielle OpenAI-Einführung zum Prompting empfiehlt, Ergebnis und hilfreichen Kontext verständlich zu beschreiben. Sie verlangt keine starre Syntax. Für die Praxis bedeutet das: Verwenden Sie nur Bausteine, die eine Entscheidung über das Ergebnis tatsächlich beeinflussen.

Formulieren Sie einen einfachen Abnahmesatz. Nach der Bearbeitung soll beispielsweise ein überprüfbarer Entwurf vorliegen, der bekannte Fakten wiedergibt und fehlende Angaben separat auflistet. Damit lässt sich später genauer beurteilen, ob der Auftrag erfüllt wurde.

2. Zielgruppe und Verwendung konkret benennen

Ein Text für Administratoren darf andere Vorkenntnisse voraussetzen als eine Nachricht an Mitarbeitende ohne technischen Hintergrund. „Für alle“ ist deshalb selten eine hilfreiche Zielgruppenbeschreibung. Benennen Sie die konkrete Empfängergruppe und deren Situation.

Bei der Wartungsankündigung lesen vielleicht Verantwortliche in kleinen Unternehmen mit. Sie benötigen keine Erklärung interner Serverarchitektur. Relevant sind betroffene Funktionen, Zeitraum, Auswirkung und eine gegebenenfalls erforderliche Handlung.

Beschreiben Sie auch den Kanal. Eine Nachricht im Kundenportal kann auf weitere Details verweisen. Eine eigenständige E-Mail sollte wichtige Angaben ohne zusätzliche Suche verständlich machen. Eine kurze Statusmeldung wiederum verfolgt einen anderen Zweck als ein ausführliches Hilfedokument.

Statt nur „professionell“ zu verlangen, nennen Sie beobachtbare Eigenschaften. Der Text soll sachlich, verständlich und ohne unbelegte Beruhigung formuliert sein. Technische Begriffe werden erklärt, wenn sie für das Verständnis nötig sind. Solche Vorgaben lassen sich besser prüfen als ein allgemeines Qualitätswort.

3. Kontext nach Entscheidungsrelevanz auswählen

Geben Sie die Informationen, die das Ergebnis verändern können. Im Beispiel sind dies Wartungsfenster, betroffene Funktion, erwartete Auswirkung und Kontaktweg. Trennen Sie bestätigte Fakten von Annahmen und offenen Punkten.

Eine ältere Ankündigung kann die gewünschte Tonalität zeigen. Ihre Termine und Zusagen sind jedoch keine Fakten für den neuen Vorgang. Kennzeichnen Sie ihre Funktion ausdrücklich. Andernfalls kann ein sprachlich gutes Vorbild unbeabsichtigt veraltete Inhalte in den neuen Entwurf tragen.

Mehr Material ist nicht automatisch hilfreicher. Ein ungeordneter Anhang aus alten Protokollen und unterschiedlichen Planungsständen kann die Arbeit erschweren. Stellen Sie eine eindeutig bezeichnete aktuelle Grundlage bereit und erläutern Sie, wofür ergänzende Dateien verwendet werden dürfen.

Fehlt eine notwendige Quelle, sollte der Auftrag ein passendes Verhalten vorsehen. Für eine Entwurfsfassung können offene Fragen separat gesammelt werden. Wenn ein fehlender Termin den gesamten Inhalt bestimmt, kann zunächst eine gezielte Rückfrage erforderlich sein.

4. Fakten, Annahmen und Arbeitsanweisungen unterscheiden

Diese Einteilung ist eine redaktionelle Arbeitshilfe. Sie schafft keine technische Zugriffssperre. Insbesondere wird fremder Dokumentinhalt nicht allein durch eine Überschrift vertrauenswürdig. Die technische Absicherung eines angebundenen Systems ist eine zusätzliche Aufgabe.

Lesen Sie Ihren eigenen Auftrag aus Sicht einer neu hinzukommenden Person. Wenn dieselbe Aussage einmal als bestätigter Fakt und später als bloße Vermutung erscheint, muss dieser Widerspruch vor der Verwendung geklärt werden.

5. Grenzen als konkrete Entscheidungen formulieren

„Keine Fehler machen“ beschreibt einen Wunsch. „Keine Verfügbarkeit außerhalb des freigegebenen Wartungsfensters zusagen“ beschreibt eine konkrete Grenze. Die zweite Anweisung lässt sich am Ergebnis überprüfen.

Im Beispiel darf eine noch nicht bekannte Endzeit nicht erfunden werden. Ebenso soll keine Garantie über vollständig störungsfreien Betrieb entstehen. Solche Grenzen betreffen die inhaltliche Aussage und sind wichtiger als eine bevorzugte Grußformel.

Bei Werkzeugzugriff kommt eine weitere Ebene hinzu. Eine Nachricht entwerfen, im System speichern und an Kunden versenden sind unterschiedliche Handlungen. Beschreiben Sie den beauftragten Umfang eindeutig. Die technische Berechtigung muss dazu passen.

Eine Promptanweisung ersetzt dabei keine Zugangskontrolle. Ein angebundener Prozess benötigt geeignete Berechtigungen und eine nachvollziehbare Prüfung tatsächlich ausgeführter Aktionen. Für einen reinen Textentwurf kann der Auftrag schlicht festlegen, welches überprüfbare Dokument entstehen soll.

6. Das Ausgabeformat aus der Weiterverwendung ableiten

Wenn der Entwurf von einer Person gelesen und überarbeitet wird, ist ein klar gegliederter Text oft passend. Wenn ein nachgelagertes Programm Felder verarbeitet, braucht es eine definierte Datenstruktur und eine technische Prüfung.

Im Wartungsbeispiel kann die Ausgabe aus Betreff, Nachricht und offenen Fragen bestehen. Diese Trennung verhindert, dass ein interner Klärungspunkt versehentlich als Kundeninformation erscheint. Sie erleichtert außerdem die Abschlussprüfung.

Eine exakte Wortzahl ist nur sinnvoll, wenn sie einem tatsächlichen Bedarf dient. Häufig reicht ein sinnvoller Rahmen. Wesentliche Einschränkungen dürfen nicht entfallen, nur damit eine beliebig gewählte Länge eingehalten wird.

Verlangen Sie bei belegpflichtigen Aussagen geeignete Fundstellen. Die Angabe eines Links allein genügt nicht. Eine Person muss prüfen können, ob die angeführte Quelle gerade diese Aussage trägt und ob sie zum vorgesehenen Stand passt.

7. Eine vollständige eigene Beispielvorlage

Der folgende Auftrag ist bewusst kurz genug, um als Ganzes gelesen zu werden. Er benötigt keine spezielle Produktoberfläche. Vor einer echten Verwendung werden die fiktiven Angaben durch freigegebene Projektdaten ersetzt.

Ergebnis:
Erstelle einen Entwurf einer Wartungsankündigung für bestehende Geschäftskunden.

Zielgruppe:
Verantwortliche ohne technische Spezialkenntnisse.

Bestätigte Fakten:
- Betroffen ist die Berichtsfunktion im Kundenportal.
- Bereits gespeicherte Berichte bleiben erhalten.
- Die Endzeit ist noch nicht freigegeben.

Grenzen:
Keine Endzeit, Garantie oder weitere betroffene Funktion ergänzen.
Keine Nachricht versenden.

Ausgabe:
1. Betreff
2. Nachrichtentwurf in verständlicher Sprache
3. Offene Fragen für die interne Prüfung

Prüfung:
Kontrolliere den Entwurf gegen die bestätigten Fakten.
Kennzeichne fehlende Angaben im Abschnitt mit offenen Fragen.

Der Auftrag liefert noch keine öffentlich verwendbare Wartungsinformation. Beispielsweise fehlt ein bestätigter Zeitraum. Sein Zweck ist eine prüfbare Arbeitsfassung, in der diese Lücke sichtbar bleibt. Das spätere Freigabeverfahren muss zur tatsächlichen Kommunikation passen.

Eine gute Ausgabe würde den bekannten Umfang erhalten und die fehlende Zeitangabe nicht mit einer plausiblen Schätzung füllen. Diese Erwartung ist unabhängig davon prüfbar, ob einzelne Sätze bereits die endgültige Tonalität treffen.

8. Beispiele gezielt und mit klarer Funktion einsetzen

Ein Beispiel lohnt sich, wenn eine Anforderung schwer abstrakt zu erklären ist. Für eine knappe sachliche Tonalität kann ein freigegebener Musterabsatz hilfreich sein. Ergänzen Sie, welche Eigenschaften übernommen werden sollen.

Die Anthropic-Empfehlungen zum Prompting beschreiben relevante Beispiele und die erkennbare Trennung von Anweisung, Kontext und Beispiel. Für das eigene Briefing ist besonders wichtig, dass Beispiele nicht im Widerspruch zu den ausdrücklich genannten Regeln stehen.

Zeigen Sie bei Bedarf auch einen Ausnahmefall. Ein Musterdatensatz mit unbekannter Endzeit kann verdeutlichen, wie fehlende Informationen behandelt werden. Ein Beispiel, das immer sämtliche Felder enthält, erklärt diesen Fall nicht.

Vermeiden Sie eine große Sammlung nur geringfügig unterschiedlicher Vorbilder. Prüfen Sie zunächst, ob ein oder zwei sorgfältig ausgewählte Beispiele die Erwartung ausreichend verdeutlichen. Weitere Beispiele brauchen einen erkennbaren zusätzlichen Zweck.

9. Überschriften und Datenblöcke sinnvoll verwenden

Klare Überschriften helfen beim Lesen und Überarbeiten. Die Begriffe müssen nicht „Rolle“, „Kontext“ oder „Format“ heißen. Entscheidend ist, dass eine Information ihre Funktion erkennen lässt.

Die OpenAI-Dokumentation zum Prompt Engineering beschreibt Markdown und XML als Möglichkeiten, logische Bereiche zu kennzeichnen. Ein Datenblock kann beispielsweise Quelle und Inhalt zusammenhalten. Daraus folgt keine universelle optimale Reihenfolge für jede Aufgabe.

Für einen menschlich gepflegten Auftrag genügen oft normale Absätze. Für automatisiert eingesetzte Vorlagen können klar benannte Felder nützlich sein. Wählen Sie die Struktur so, dass fehlerhafte oder fehlende Eingaben rechtzeitig auffallen.

Beachten Sie außerdem die Grenze zwischen lesbarer Gliederung und Sicherheit. Eine Kennzeichnung als „Quelltext“ hilft bei der Interpretation. Sie garantiert jedoch nicht, dass beliebiger fremder Inhalt keine unerwünschte Wirkung auf einen angeschlossenen Ablauf hat.

10. Ein kleiner geprüfter Vorlagenbaustein

Das folgende JavaScript erstellt einen strukturierten Briefingtext aus zwei verpflichtenden Angaben. Die Daten werden als JSON dargestellt. Der Baustein ruft kein Modell auf und erteilt keine Berechtigungen. Seine Prüfung betrifft ausschließlich vorhandene Eingaben und die erzeugte Zeichenfolge.

function buildBrief({ audience, facts }) {
  if (typeof audience !== "string" || !audience.trim()) {
    throw new TypeError("audience required");
  }
  if (!Array.isArray(facts) || facts.length === 0 ||
      facts.some(v => typeof v !== "string" || !v.trim())) {
    throw new TypeError("non-empty facts required");
  }
  const data = { audience: audience.trim(), facts };
  return "Erstelle einen prüfbaren Entwurf. Fehlende Angaben offenlassen.\n" +
    "Datengrundlage als JSON:\n" + JSON.stringify(data, null, 2);
}

JSON-Kodierung verhindert hier, dass Anführungszeichen in einem Fakt die Datenstruktur syntaktisch zerstören. Sie ist kein Schutzversprechen gegen Prompt-Injection. Dafür braucht ein angebundener Arbeitsablauf weitere, zum tatsächlichen Risiko passende Maßnahmen.

Eine echte Integration sollte außerdem erwartete Ausgaben prüfen und Fehler verständlich behandeln. Wenn ein entscheidender Wert fehlt, ist ein definierter Abbruch oft besser als eine stillschweigend erzeugte Ersatzangabe.

11. Widersprüche im Auftrag zuerst beheben

„Sehr ausführlich“ und „höchstens drei kurze Sätze“ können gemeinsam unerfüllbar sein. Ähnliches gilt für „alle Details erhalten“ bei einer extrem kurzen Zusammenfassung. Ein längerer Prompt löst diesen Zielkonflikt nicht.

Ordnen Sie Anforderungen nach Bedeutung. Faktenbindung und erforderliche Einschränkungen können Vorrang vor Kürze haben. Wenn eine feste Länge unverzichtbar ist, muss der zulässige Umfang entsprechend begrenzt werden.

Achten Sie auf Konflikte zwischen Beispiel und Anweisung. Ein Vorbild mit werblicher Übertreibung passt nicht zu einer Regel gegen unbelegte Aussagen. Entfernen Sie den Konflikt, statt darauf zu hoffen, dass das Modell die gewünschte Priorität errät.

Auch hinterlegte Projektregeln gehören zur Betrachtung. Wenn eine Sitzung einen anderen Ton oder ein festes Ausgabeformat vorgibt, kann der neue Auftrag darauf treffen. Dokumentieren und bereinigen Sie die für die Aufgabe relevanten Vorgaben.

12. Nachfragen und selbstständige Entscheidungen abgrenzen

Nicht jede fehlende Information muss die Arbeit sofort stoppen. Für eine interne Arbeitsfassung können offene Punkte sichtbar gesammelt werden. Für eine verbindliche Zusage kann dieselbe Lücke entscheidend sein.

Beschreiben Sie daher, welche Entscheidungen selbstständig getroffen werden dürfen. Eine sinnvolle Zwischenüberschrift kann beispielsweise redaktionelles Ermessen sein. Eine noch nicht bestätigte Verfügbarkeit gehört nicht dazu.

Eine hilfreiche Regel lautet: Bei stilistischen Einzelheiten eine passende Entscheidung treffen. Bei fehlenden Tatsachen keine Ersatzbehauptung bilden. Wenn die Aufgabe ohne die Tatsache nicht sinnvoll bearbeitbar ist, die konkrete Lücke benennen.

Diese Regel entlastet beide Seiten. Die Bearbeitung bleibt handlungsfähig und wichtige Unklarheiten verschwinden nicht in glatt formulierter Prosa. Für wiederkehrende Abläufe sollten die typischen Lücken in der Vorlage ausdrücklich berücksichtigt werden.

13. Mit gezielter Rückmeldung verbessern

Nach dem ersten Ergebnis ist „noch professioneller“ meist wenig hilfreich. Benennen Sie, welche Anforderung verfehlt wurde. Beispielsweise kann eine offene Endzeit zu beiläufig wirken oder ein Fachbegriff unerklärt bleiben.

Geben Sie eine konkrete Korrekturrichtung. „Erhalte die offenen Fragen separat und vereinfache die Erklärung der Berichtsfunktion“ verändert zwei klar erkennbare Eigenschaften. Kontrollieren Sie anschließend, ob dabei die bestätigten Fakten erhalten bleiben.

Ändern Sie nicht bei jeder Runde sämtliche Vorgaben. Sonst lässt sich schwer erkennen, welcher Zusatz geholfen hat. Bewahren Sie funktionierende Bausteine auf und prüfen Sie neue Anforderungen anhand geeigneter Beispiele.

Für einen systematischen Vergleich hilft ein Überblick zu den verwendeten KI-Werkzeugen. Die wichtigste Verbesserung entsteht jedoch oft aus einem besseren Auftrag und einem nachvollziehbaren Prüfschritt im eigenen Ablauf.

14. Wiederkehrende Prompts wie Arbeitsmittel pflegen

Eine erfolgreich verwendete Vorlage braucht einen klaren Zweck und eine verantwortliche Person. Halten Sie fest, für welche Aufgaben und Quellen sie gedacht ist. Ein Prompt für Wartungsankündigungen ist kein universeller Kommunikationsstandard.

Versionieren Sie wesentliche Änderungen. Notieren Sie, welche Fehlerklasse eine Anpassung beheben soll. Eine neue Formulierung sollte an normalen Fällen und relevanten Ausnahmen geprüft werden, bevor sie regelmäßig eingesetzt wird.

Die folgende Tabelle verbindet typische Probleme mit einer passenden Änderung. Sie ist eine Diagnosehilfe und keine Garantie für ein bestimmtes Modellergebnis.

15. Quellenänderungen in der Vorlage berücksichtigen

Ein wiederkehrender Auftrag kann sprachlich unverändert bleiben, obwohl sich seine Datengrundlage geändert hat. Wenn ein Wartungsfenster verschoben wird, müssen verwendete Unterlagen und gespeicherte Projektinformationen dazu passen. Eine gute Formulierung schützt nicht vor einem veralteten Termin.

Benennen Sie deshalb die maßgebliche Quelle und ihren Stand. Bei widersprüchlichen Angaben sollte die Vorlage einen nachvollziehbaren Umgang vorsehen. Eine mögliche Regel lautet, die Abweichung zu benennen und die betroffene Aussage bis zur Klärung offen zu lassen. Welche Quelle tatsächlich Vorrang hat, muss der verantwortliche Fachbereich entscheiden.

Prüfen Sie bei jeder Änderung außerdem vorhandene Beispiele. Vielleicht enthält das Stilvorbild noch einen früher zugesagten Kontaktweg. Wird dieser unbemerkt übernommen, kann ein korrekt gepflegter Faktenblock trotzdem durch einen ungeeigneten Mustertext überlagert werden.

Für die Abnahme ist eine kurze Änderungsnotiz hilfreich. Halten Sie fest, welche Eingaben aktualisiert wurden und welche Aussagen deshalb erneut geprüft werden müssen. So lässt sich die Kontrolle auf den tatsächlich betroffenen Inhalt richten.

Bei mehreren Empfängergruppen kann eine gemeinsame Faktenbasis mit getrennten Ausgabeaufträgen sinnvoll sein. Die technische Situation bleibt dieselbe. Die Erklärung und die erforderliche Handlung können sich unterscheiden. Trennen Sie diese redaktionellen Varianten ausdrücklich von Änderungen an den bestätigten Tatsachen.

16. Checkliste vor der Verwendung

• Ist das gewünschte Ergebnis mit seinem Zweck beschrieben?
• Sind Zielgruppe und tatsächlicher Verwendungskontext klar?
• Ist die aktuelle Faktenbasis eindeutig bezeichnet?
• Bleiben Annahmen und offene Fragen erkennbar getrennt?
• Sind inhaltliche Grenzen konkret überprüfbar?
• Passt die Ausgabestruktur zur Weiterverwendung?
• Erklären Beispiele genau die beabsichtigte Eigenschaft?
• Widersprechen sich keine Regeln oder Vorbilder?
• Sind externe Handlungen und Berechtigungen passend begrenzt?
• Gibt es eine nachvollziehbare Prüfung des Ergebnisses?

17. Häufige Fragen

Muss jeder Prompt eine Rolle enthalten?

Nein. Eine Rolle ist hilfreich, wenn sie die Aufgabe sinnvoll fokussiert. „Du bist der beste Experte“ liefert noch keine Fakten und keine Abnahmekriterien. Für viele Aufgaben sind Zweck, Quellen und erwartetes Ergebnis aussagekräftiger.

Sind lange Prompts immer besser?

Nein. Unnötige Wiederholungen und widersprüchliche Vorgaben können die Arbeit erschweren. Fügen Sie Informationen hinzu, wenn sie eine konkrete Entscheidung beeinflussen oder einen beobachteten Fehler nachvollziehbar vermeiden helfen.

Kann die KI ihren Entwurf selbst prüfen?

Eine ausdrücklich verlangte Kontrolle kann nützlich sein. Sie ersetzt keine unabhängige Quellenprüfung und keine tatsächliche Funktionsprüfung. Vor allem ist die Aussage „geprüft“ ohne erkennbare Grundlage noch kein belastbarer Nachweis.

Kann dieselbe Vorlage mit ChatGPT und Claude verwendet werden?

Ein klar beschriebener Arbeitsauftrag lässt sich häufig in mehreren Produkten erproben. Einstellungen, Kontext und verfügbare Werkzeuge können sich dennoch unterscheiden. Prüfen Sie die Vorlage deshalb in der tatsächlich verwendeten Umgebung.