Wichtigste Erkenntnisse
- Entwickeln Sie ein eigenes Framework, wenn Sie dieselben 3+ Komponenten bei jedem Prompt in einem Workflow hinzufügen
- Verwenden Sie 3–6 Komponenten: weniger ist eine Technik, mehr erzeugt Reibung
- Testen Sie an 10 realen Prompts, bevor Sie dokumentieren
- Überprüfen Sie die modellübergreifende Zuverlässigkeit auf GPT-4o und Claude 4.6 Sonnet
- Speichern Sie die Framework-Spezifikation in der Versionskontrolle mit einer Vorlage und 3 kommentierten Beispielen
Framework vs. Technik: Was ist der Unterschied?
📍 In One Sentence
Ein Prompt-Framework ist eine strukturelle Vorlage, die festlegt, welche Komponenten in jeden Prompt gehören; eine Technik ist ein Muster, das innerhalb einer dieser Komponenten angewendet wird.
💬 In Plain Terms
Das Framework ist das Gerüst für jeden Prompt — es legt die Abschnitte fest. Eine Technik ist, was Sie innerhalb eines Abschnitts tun, zum Beispiel das Modell schrittweise denken lassen.
Ein Prompt-Framework ist eine strukturelle Vorlage, die festlegt, welche Komponenten in jeden Prompt gehören; eine Technik ist ein Muster, das innerhalb einer dieser Komponenten angewendet wird. Chain-of-Thought-Prompting ist eine Technik — Sie wenden sie innerhalb der „Aufgabe"-Komponente eines Frameworks an. CO-STAR ist ein Framework — es definiert 6 Komponenten, die den gesamten Prompt strukturieren.
Die Unterscheidung ist wichtig, weil Frameworks und Techniken verschiedene Probleme lösen. Ein Framework löst Konsistenz: Alle in Ihrem Team erstellen Prompts mit derselben Struktur. Eine Technik löst Fähigkeit: Sie ändert, wie das Modell einen bestimmten Schritt im Denkprozess angeht.
Verwenden Sie ein vorhandenes Framework (CO-STAR, CRAFT, RISEN, RTF), wenn Ihr Aufgabentyp zu dem passt, wofür das Framework entwickelt wurde. Entwickeln Sie ein eigenes, wenn Sie immer wieder dieselben domänenspezifischen Komponenten hinzufügen, die vorhandene Frameworks nicht enthalten.
📌 Kernunterschied
Frameworks lösen Konsistenz im Team. Techniken lösen Fähigkeit in einem einzelnen Prompt-Schritt. Beides ist notwendig; keines ersetzt das andere.
Wann sollten Sie ein eigenes Prompt-Framework entwickeln?
Entwickeln Sie ein eigenes Framework, wenn Sie für jeden Prompt in einem Workflow dieselben 3+ Modifikationen an einem Standardframework vornehmen. Wenn Sie immer einen Compliance-Anker ergänzen, eine Zitierpflicht anhängen und ein Fachvokabular einpflegen — sind das Komponenten, keine Ad-hoc-Ergänzungen.
Anzeichen, dass Sie ein eigenes Framework benötigen:
- Sie fügen jedem Prompt dieselben Felder hinzu, die kein Standardframework enthält
- Ihr Team produziert inkonsistente Prompts, obwohl CO-STAR oder CRAFT verwendet wird
- Neue Teammitglieder benötigen mehr als eine Woche, um akzeptable Prompts zu schreiben
- Ihre Prompts umfassen im Schnitt mehr als 600 Wörter, weil Sie immer wieder denselben Kontext erklären
- Sie haben einen „Basis-Prompt" erstellt, den jeder kopiert und manuell anpasst
Eigenes Prompt-Framework in 5 Schritten entwickeln
Der 5-Schritte-Prozess: Ziel definieren → Komponenten identifizieren → an 10 Prompts testen → verfeinern → dokumentieren. Jeder Schritt hat ein klares Abschlusskriterium. Überspringen Sie nicht zu Schritt 5 — die Dokumentation eines ungetesteten Frameworks erzeugt falsches Vertrauen.
- 1Ziel in einem Satz definieren
Why it matters: Schreiben Sie genau auf, welche Ausgabe dieses Framework zuverlässig erzeugen soll. Dieser Satz bestimmt jede Komponentenentscheidung. - 23–6 erforderliche Komponenten identifizieren
Why it matters: Listen Sie die Eingabeelemente auf, die jeder Prompt in diesem Workflow benötigt. Schreiben Sie zunächst 5 Prompts aus dem Gedächtnis und extrahieren Sie, was sie gemeinsam haben. - 3An 10 realen Prompts anwenden
Why it matters: Verwenden Sie tatsächliche Prompts aus Ihrem Workflow — keine erfundenen Beispiele. Bewerten Sie jede Ausgabe: Erfüllt sie das Ziel? Welche Komponenten fehlten? Testen Sie mit PromptQuorum auf GPT-4o und Claude 4.6 Sonnet. - 4Komponentenliste verfeinern
Why it matters: Entfernen Sie Komponenten, die in weniger als 7 von 10 Prompts vorkamen. Fügen Sie Komponenten hinzu, die Sie in 5+ Fällen ad hoc ergänzt haben. Führen Sie den 10-Prompt-Test mit dem überarbeiteten Framework erneut durch. - 5Dokumentieren und standardisieren
Why it matters: Schreiben Sie eine einseitige Spezifikation: Framework-Name, Definition jeder Komponente, Ausfüllvorlage mit Platzhaltern und 3 kommentierte Beispiel-Prompts. Speichern Sie diese in der Versionskontrolle (Git oder PromptHub).
⚠️ Schritt 3 nicht überspringen
Ohne den Test an 10 realen Prompts enthält das Framework fast immer Komponenten, die unter Zeitdruck übersprungen werden. Erst testen, dann dokumentieren.
Häufige Fehler beim Entwickeln eigener Frameworks
Der häufigste Fehler ist, ein Framework zu entwickeln, bevor 20+ reale Prompts manuell getestet wurden. Frameworks, die aus der Theorie heraus entwickelt werden, enthalten Komponenten, die wichtig klingen, in der Praxis aber übersprungen werden.
❌ Zu viele Komponenten (7+)
Why it hurts: Autoren überspringen Abschnitte unter Zeitdruck und brechen die Konsistenz.
Fix: Begrenzen Sie auf 6 Komponenten. Verschieben Sie domänenspezifische Felder in Erweiterungen, nicht in das Kern-Framework.
❌ Ein Standardframework kopieren und umbenennen
Why it hurts: Ein umbenanntes CO-STAR ist kein eigenes Framework — es ist CO-STAR mit zusätzlichem Branding-Aufwand.
Fix: Formalisieren Sie ein Framework nur, wenn Sie mindestens 2 Komponenten haben, die in keinem Standardframework existieren.
❌ Kein Testset vor der Dokumentation
Why it hurts: Sie dokumentieren ein Framework, das echten Prompts nicht standhält.
Fix: Führen Sie 10 reale Prompts durch den Entwurf, bevor Sie die Spezifikation schreiben.
Häufig gestellte Fragen
Was ist ein Prompt-Framework?
Ein Prompt-Framework ist eine strukturierte Vorlage, die festlegt, welche Komponenten ein Prompt enthalten soll und in welcher Reihenfolge. Beispiele sind CO-STAR und CRAFT. Frameworks verbessern die Konsistenz und reduzieren den Aufwand beim Erstellen neuer Prompts.
Wann sollte ich ein eigenes Framework entwickeln?
Entwickeln Sie ein eigenes Framework, wenn Sie für jeden Prompt in einem Workflow dieselben 3+ Modifikationen an einem Standardframework vornehmen.
Wie viele Komponenten sollte ein Framework haben?
Verwenden Sie 3–6 Komponenten. Weniger als 3 ist eine Technik. Mehr als 6 erzeugt Reibung.
Wie benenne ich ein eigenes Prompt-Framework?
Ein Akronym (wie REPAIR) macht das Framework einprägsam. Wählen Sie Buchstaben, die den Komponenten in der richtigen Reihenfolge zugeordnet sind. Test: Kann ein neues Teammitglied alle Komponenten allein aus dem Namen ableiten?
Wie versioniere ich ein eigenes Framework?
Speichern Sie jede Version in einer datierten Datei (z. B. repair-v1-2026-05.md). Grundlegende Änderungen = Hauptversion, Verfeinerungen = Nebenversion. Dokumentieren Sie den Änderungsgrund.
Kann ich mehrere Frameworks kombinieren?
Ja, behandeln Sie das Ergebnis aber als neues eigenes Framework. Benennen, dokumentieren und testen Sie es wie ein Original. Kombination ohne Formalisierung erzeugt nur ein undokumentiertes Ad-hoc-Muster.
Weiterführende Artikel
Quellen
Häufig gestellte Fragen
Was ist der Unterschied zwischen einer Prompt-Technik und einem Prompt-Framework?
Eine Technik ist eine einzelne Anweisung oder Methode (z. B. „denke Schritt für Schritt"). Ein Framework ist eine wiederverwendbare Struktur mit 3+ Komponenten, die definiert, wie Prompts aufgebaut sein sollten. Frameworks sind wiederholbar; Techniken sind ad hoc.
Wann sollte ich ein eigenes Framework statt CO-STAR, CRAFT oder RISEN verwenden?
Erstellen Sie eines, wenn Sie wiederholt die gleichen 3+ Modifikationen an einem existierenden Framework für jeden Prompt in einem Workflow vornehmen. Wenn Sie immer eine Compliance-Einschränkung, Domain-Terminologie und Output-Schema zu CO-STAR hinzufügen, sollten diese Komponenten Ihres eigenen Frameworks werden.
Kann ein eigenes Framework über verschiedene KI-Modelle hinweg funktionieren?
Ja, wenn es richtig gestaltet ist. Vermeiden Sie modellspezifische Syntax und bauen Sie auf universelle Komponenten (Aufgabe, Einschränkungen, Output-Format). Testen Sie auf GPT-4o und Claude, bevor Sie finalisieren. Wenn das Framework pro Modell Umformulierungen benötigt, vereinfachen Sie es.
Wie viele Komponenten sollte mein eigenes Framework haben?
Verwenden Sie 3–6 Komponenten. Weniger als 3 ist eine Technik, kein Framework. Mehr als 6 erzeugt Reibung und Autoren überspringen Abschnitte. Wenn Sie mehr brauchen, teilen Sie in zwei spezialisierte Frameworks für verschiedene Aufgabentypen auf.
Wie teste ich, ob mein eigenes Framework tatsächlich funktioniert?
Wenden Sie es auf 10 repräsentative Prompts aus Ihrem Workflow an. Bewerten Sie Ausgaben nach drei Kriterien: (1) Aufgabenerledigung, (2) Format-Einhaltung, (3) Qualitätskonsistenz. Ein funktionierendes Framework erzielte 8/10 oder besser bei allen drei. Testen Sie über mehrere Modelle mit PromptQuorum.
Wie sollte ich mein eigenes Framework benennen?
Verwenden Sie ein Akronym, das Ihren Komponenten in Reihenfolge zugeordnet ist (wie REPAIR). Der Akronym-Test: Kann ein neues Teammitglied alle Komponenten allein aus dem Namen abrufen? Wenn nicht, vereinfachen Sie Ihre Komponentenliste.
Kann ich Komponenten von CO-STAR, CRAFT und RISEN kombinieren?
Ja, behandeln Sie es aber als neues Framework, nicht als Hybrid. Benennen Sie es, dokumentieren Sie es, testen Sie es und speichern Sie es in Versionskontrolle. Kombinieren ohne Formalisierung schafft nur ein undokumentiertes ad-hoc-Muster.
Wie versioniere ich ein eigenes Framework?
Speichern Sie jede Version in einer datierten Datei (z. B. repair-v1-2026-05.md) in Ihrer Prompt-Bibliothek. Markieren Sie Breaking Changes (Komponente hinzugefügt/entfernt) als Hauptversionen. Markieren Sie Verfeinerungen (Definitionen aktualisiert) als Nebenversionen. Dokumentieren Sie den Grund für jede Änderung.
Was sollte ich für mein eigenes Framework dokumentieren?
Schreiben Sie eine einseitige Spezifikation: (1) Framework-Name und Ziel, (2) 3–6 Komponentendefinitionen mit Beispielen, (3) eine Ausfüllvorlage, (4) 3 annotierte vollständige Beispielprompts mit dem Framework. Halten Sie es in Versionskontrolle neben Ihrer Prompt-Bibliothek.
Wie bekomme ich mein Team, mein eigenes Framework zu verwenden?
Beginnen Sie mit einer 30-Minuten-Anleitung mit echten Aufgabenbeispielen. Testen Sie zusammen an 2–3 Prompts. Erstellen Sie eine teilbare einseitige Spezifikation. Verfolgen Sie Compliance und Impact Metrics (Task-Erfolgsrate, Output-Konsistenz) für den ersten Monat. Iterieren Sie basierend auf Feedback.