> ## Content Index > Fetch the complete content index at: https://t01.li/llms.txt > Use this file to discover other available public pages before exploring further. # Prompt-Vorlagen zum Kopieren: fünf Bausteine für dein Team - URL: https://t01.li/ki-systemdesign/prompt-vorlagen-zum-kopieren/ - Published: 2026-08-12T05:15:05.000Z - Updated: 2026-08-12T18:08:13.000Z - Description: Fünf Prompt-Vorlagen für die Aufgaben, die im Arbeitsalltag ständig anfallen: Extraktion, Klassifikation, Analyse, Recherche und Texte. Zum Kopieren, Anpassen und Weitergeben ans Team – plus die zwei Querschnittsregeln, die jede Vorlage besser machen. - Author: Tobias Glawe - Tags: KI Systemdesign, KI Alltag Teil 1 hat [die Basis-Struktur](https://t01.li/ki-systemdesign/prompting-2026-vergiss-deine-frameworks/) geliefert, Teil 2 [die Modelltyp-Frage](https://t01.li/ki-systemdesign/reasoning-oder-nicht-prompts-nach-modelltyp/) geklärt. Jetzt kommt der Teil, den du am ehesten intern weiterreichst: fünf Prompt-Vorlagen für die Aufgaben, die in jedem Unternehmen ständig anfallen. Kopieren, Platzhalter füllen, loslegen – und bei Bedarf ans eigene Team anpassen. Vorlagen sind kein Widerspruch zur Framework-Kritik aus Teil 1\. Der Unterschied liegt im Customizing. Ein Akronym verspricht, für alles zu passen; eine Vorlage ist ehrlich auf eine Aufgabenklasse gebaut und darf bei anderen scheitern. ## TL;DR Fünf Kopiervorlagen für den Arbeitsalltag mit LLMs – jede auf eine Aufgabenklasse zugeschnitten statt auf alles gleichzeitig. - Extraktion, Klassifikation, Analyse, Recherche und Schreibaufgaben – je eine Vorlage zum Anpassen - Zwei Querschnittsregeln machen jede davon besser: Instruktionen von Daten trennen, Unsicherheit explizit regeln - Markdown strukturiert die Anweisung, XML-Tags kapseln die Daten – mehr Syntax-Regelwerk braucht kein Prompt - Vorlagen gehören ins Team-Wiki und unter Versionskontrolle, nicht in verstreute Chat-Verläufe ## Zwei Regeln, bevor du kopierst **Instruktionen von Daten trennen.** Der häufigste stille Fehler im Alltag ist der Prompt, in dem Auftrag, Regeln und eingefügter Text ineinanderfließen. Das Modell soll dann raten, wo deine Anweisung endet und das zu verarbeitende Material beginnt. Jede Vorlage hier hat deshalb einen klar abgetrennten Eingabe-Block – bei langen Dokumenten hilft zusätzlich eine simple Markierung wie `…` um den Inhalt. **Unsicherheit explizit regeln.** Aus Teil 1 bekannt und hier in jeder Vorlage eingebaut: Das Modell bekommt gesagt, was bei Lücken passieren soll. Fehlendes kennzeichnen, Fakten von Schlussfolgerungen trennen, im Zweifel „keine belastbare Aussage möglich“ schreiben. Diese drei Zeilen verhindern mehr [Konfabulationen](https://t01.li/glossar/#halluzination) als jedes Verbot (zu einhundert Prozent verhindern, lassen sie sich aber nicht). ## Markdown für die Anweisung, XML für die Daten Dir ist vielleicht aufgefallen, dass alle fünf Vorlagen mit Markdown-Überschriften arbeiten. Das ist kein Zufall und keine Deko. Markdown ist für Menschen lesbar, lässt sich im Team-Wiki pflegen, und jedes aktuelle LLM versteht `##`\-Abschnitte als das, was sie sind – Gliederung. Für manuell gepflegte Vorlagen ist Markdown meist die pragmatischste Lösung. XML-Tags sind das zweite Werkzeug, und sie lösen ein anderes Problem. Sobald Daten in den Prompt wandern – ein Vertrag, drei Quellen, ein Support-Verlauf – braucht das Modell eine eindeutige Grenze zwischen deiner Anweisung und dem Material. [Anthropic empfiehlt Tags dafür ausdrücklich](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags?ref=t01.li), OpenAI und Google verstehen sie genauso. Wichtig zu wissen: Das muss kein valides XML sein. Die Tags sind Markierungen, keine Schemata – sie brauchen weder Namespace noch Doctype, nur konsistente Namen und ein sauberes Öffnen und Schließen. So sieht das kombiniert aus, hier als Ausschnitt aus einem Quellenvergleich: ```markdown ## Aufgabe Vergleiche die beiden Quellen und benenne Widersprüche. ## Quellen [Text der ersten Quelle] [Text der zweiten Quelle] ``` Die Faustregel für den Alltag: Markdown strukturiert, was das Modell tun soll, XML kapselt, womit es arbeiten soll. Mehr Regelwerk braucht es nicht – wer anfängt, jede einzelne Anweisung in eigene Tags zu verpacken, baut sich nur das nächste Framework. ## Vorlage 1: Extraktion Der Klassiker für Non-Reasoning-Modelle – Rechnungen, Mails, Formulare, Verträge. Das Format ist hart definiert, Lücken werden zu `null` statt zu Erfindungen. ```markdown ## Aufgabe Extrahiere die angegebenen Informationen aus dem Eingabetext. ## Gesuchte Felder - Name - Organisation - Datum - Betrag - Handlungsbedarf ## Regeln - Verwende nur Informationen aus dem Eingabetext - Ergänze keine fehlenden Angaben - Verwende null, wenn ein Wert nicht vorhanden ist - Normalisiere Datumsangaben ins Format YYYY-MM-DD - Beträge als Dezimalzahl ohne Währungssymbol ## Ausgabeformat JSON mit exakt den oben genannten Feldern ohne Markdown-Codeblock ## Eingabetext {{TEXT}} ``` Läuft die Extraktion über eine API, gehört das JSON Schema als eigener Parameter in den Request – der Prompt wünscht sich das Format, das Schema erzwingt es per Structured Outputs (die Details dazu stehen in Teil 2). ## Vorlage 2: Klassifikation Hier zahlt sich [Few-Shot](https://t01.li/glossar/#few-shot) am deutlichsten aus. Die Beispiele folgen der Regel aus Teil 2 – ein typischer Fall, ein schwieriger, ein Grenzfall. ```markdown ## Aufgabe Ordne den Eingabetext genau einer Kategorie zu. ## Kategorien - Rechnung - technischer Fehler - Kündigung - Produktfrage - Sonstiges ## Entscheidungsregeln - Bei mehreren Themen wähle das dringlichste Anliegen - Sonstiges nur, wenn keine andere Kategorie eindeutig passt - Gib ausschließlich den Kategorienamen aus, keine Erklärung ## Beispiele Eingabe: „Meine Rechnung enthält eine unbekannte Position.“ Ausgabe: Rechnung Eingabe: „Ich möchte kündigen, weil meine Rechnung erneut falsch ist.“ Ausgabe: Kündigung Eingabe: „Welche Zahlungsarten unterstützt das Produkt?“ Ausgabe: Produktfrage ## Eingabe {{TEXT}} ``` Das zweite Beispiel ist absichtlich mehrdeutig. Genau solche Fälle entscheiden, ob die Klassifikation im Alltag hält oder bei der ersten wütenden Kundenmail kippt. ## Vorlage 3: Analyse und Entscheidung Die Reasoning-Disziplin. Gewichtete Kriterien, gebundene Evidenz, Prüfauftrag – das Modell bekommt das Problem, nicht den Lösungsweg. ```markdown ## Ziel [Entscheidung oder Problem, z. B.: Bewerte, ob Produkt A oder B für ein Unternehmen mit 50 Mitarbeitenden geeigneter ist] ## Ausgangsdaten Verwende ausschließlich die beigefügten Informationen. ## Bewertungskriterien - Datenschutz: 40 % - Funktionsumfang: 30 % - Integrationsaufwand: 20 % - Preis: 10 % ## Einschränkungen - Erfinde keine Produktmerkmale - Kennzeichne fehlende oder nicht vergleichbare Informationen - Trenne belegte Tatsachen von Annahmen - Benenne widersprüchliche Daten offen ## Ergebnis 1. Empfehlung 2. gewichtete Bewertung 3. tragende Gründe 4. Risiken 5. offene Fragen ## Kontrolle Prüfe abschließend, ob die Empfehlung mit den Gewichtungen und Ausgangsdaten übereinstimmt. ``` Die Gewichtungen sind der Hebel, den fast niemand nutzt. Sie zwingen vor dem Prompten zu einer Entscheidung darüber, was wirklich zählt – und machen das Ergebnis hinterher überprüfbar. ## Vorlage 4: Recherche Für alles, was mit Websuche oder Quellenarbeit zu tun hat. Der Quellenstandard ist das Herzstück, inklusive der Regel, Herstellerangaben als solche zu kennzeichnen – regelmäßige Leser dieses Blogs haben möglicherweise gerade eine sanfte Eingebung, warum mir diese wichtig ist. ```markdown ## Forschungsfrage [Präzise Frage] ## Geltungsbereich - Zeitraum: - Region: - ausgeschlossene Themen: ## Quellenstandard - Primärquellen bevorzugen - Veröffentlichungsdatum und Ereignisdatum unterscheiden - Zentrale Behauptungen mit Quellen belegen - Widersprüche zwischen Quellen benennen, nicht glätten - Herstellerangaben getrennt von unabhängigen Messungen kennzeichnen ## Ausgabe - Kurzfazit - zentrale Befunde mit Quellenangabe - Gegenargumente - offene Punkte ``` Das ist gelebtes [Grounding](https://t01.li/glossar/#grounding): Die Antwort wird an überprüfbare Quellen gebunden, statt aus dem Modellgedächtnis zu schöpfen. ## Vorlage 5: Schreibaufgaben Kleine Pointe zum Serienende – für Schreib- und Kommunikationsaufgaben lebt der CO-STAR-Gedanke weiter, nur ergänzt um das, was ihm immer gefehlt hat: Evidenz und Ausschlüsse. ```markdown ## Ziel [Was soll der Text bewirken?] ## Zielgruppe [Für wen ist der Text bestimmt?] ## Kernaussage [Die eine zentrale Aussage] ## Evidenz - [Beispiel, Datenpunkt oder Argument] - [Beispiel, Datenpunkt oder Argument] ## Ton und Stil [z. B. sachlich, direkt, nicht werblich] ## Ausschlüsse - [Formulierungen oder Muster, die nicht vorkommen sollen] - [Inhalte, die tabu sind] ## Ausgabe [Länge, Format und Sprache] ``` Der Ausschluss-Block ist der unterschätzte Teil. Wer dort einmal die eigenen Marketing-Unwörter einträgt, spart sich das Rausredigieren in jedem einzelnen Entwurf. ## Und jetzt ins Team damit Vorlagen entfalten ihren Wert erst, wenn sie nicht in einzelnen Chat-Verläufen versickern. Der pragmatische Weg führt über drei Stufen. Ins Team-Wiki legen (bzw. Slack, Confluence, Teams, oder was auch immer), damit alle dieselbe Ausgangsbasis haben. Anpassungen erlauben und Änderungen sammeln – die Grenzfälle aus dem echten Betrieb machen jede Vorlage besser als jeden Erstentwurf. Und sobald eine Vorlage in einem produktiven Workflow landet, gehört sie [unter Versionskontrolle](https://t01.li/ki-systemdesign/prompt-versionierung-mit-git-und-github/) wie jeder andere Code auch. Wenn ich mir das Fazit noch herausnehmen darf: Gutes Prompting ist 2026 keine Geheimwissenschaft mehr, sondern saubere Auftragsklärung – Ziel, Material, [Grenzen](https://t01.li/glossar/#constraints), Format, Prüfung. Die fünf Vorlagen hier sind nichts anderes als diese Klärung, einmal pro Aufgabenklasse durchdekliniert. Wer sie ans Team verteilt, verteilt keine Zauberformeln, sondern eine Arbeitsweise. Und das war von Anfang an der Punkt dieser ganzen Serie. ### Beiträge der Serie - [Prompting 2026: Vergiss deine Frameworks](https://t01.li/ki-systemdesign/prompting-2026-vergiss-deine-frameworks/) - [Reasoning oder nicht: Prompts nach Modelltyp](https://t01.li/ki-systemdesign/reasoning-oder-nicht-prompts-nach-modelltyp/)