← Alle Beitrage

Die OODA-Schleife für Prompt Engineering: Was mich fünf Fehlschläge gelehrt haben

Colonel John Boyds OODA-Schleife wurde in den 1960er-Jahren für die Entscheidungsfindung von Kampfpiloten entwickelt. Der Pilot, der den Zyklus aus Beobachten-Orientieren-Entscheiden-Handeln schneller durchlief, erlangte einen entscheidenden Vorteil — unabhängig von den Fähigkeiten des Flugzeugs. Ich habe entdeckt, dass dasselbe Prinzip auf Prompt Engineering zutrifft — nachdem mich fünf kostspielige Fehlschläge gelehrt hatten, dass das Schreiben des Prompts der unwichtigste Schritt ist.1

TL;DR

Die OODA-Schleife (Observe, Orient, Decide, Act — Beobachten, Orientieren, Entscheiden, Handeln) bietet ein systematisches Framework für Prompt Engineering, das den häufigsten Fehlermodus verhindert: Handeln (einen Prompt schreiben), bevor man beobachtet hat (den vollständigen Kontext verstehen). Nachdem ich 44 Skills erstellt habe — jeweils ein strukturierter Prompt mit automatischer Aktivierungslogik — habe ich gelernt, dass der Prompt selbst nur etwa 20 % des Ergebnisses ausmacht. Die übrigen 80 % entfallen auf Beobachtung (welchen Kontext braucht das Modell?), Orientierung (welcher Aufgabentyp liegt vor?) und Entscheidung (welches Prompt-Muster passt zum Aufgabentyp?). Der interaktive Builder unten führt durch den vollständigen OODA-Zyklus. Das Ergebnis: Prompts, die beim ersten Versuch erfolgreich sind, statt iterative Verfeinerung zu erfordern.



Der Prompt, der fünfmal scheiterte

Bevor ich gelernt habe, vor dem Handeln zu beobachten, schrieb ich Prompts wie ein Entwickler Code schreibt: direkt zur Lösung springen.

Fehlschlag 1: Der Blog-Evaluator. Mein erster Versuch eines Prompts zur Bewertung der Blog-Qualität: „Bewerte diesen Blogbeitrag und gib ihm eine Note von 1-10.” Das Modell lieferte einen vagen Absatz mit „7/10” und keinerlei umsetzbares Feedback. Ich überarbeitete den Prompt viermal, bevor ich erkannte, dass das Problem nicht in der Formulierung lag — das Problem war, dass ich nicht definiert hatte, was „Qualität” bedeutet.

Die OODA-Lösung: Ich verbrachte 30 Minuten damit, meinen eigenen Bewertungsprozess zu beobachten. Ich identifizierte sechs spezifische Dimensionen, die mir wichtig waren: Mehrwert für den Leser (25 %), technische Genauigkeit (20 %), didaktische Qualität (20 %), Schreibqualität (15 %), faktische Integrität (15 %) und SEO-Effektivität (5 %). Die gewichtete Bewertungsmatrix wurde zum blog-evaluator Skill, und jede Bewertung seitdem hat konsistente, umsetzbare Ergebnisse geliefert.2

Fehlschlag 2: Der Code-Reviewer. Mein erster Review-Prompt: „Überprüfe diesen Code auf Fehler und Sicherheitsprobleme.” Das Modell lieferte 15 Befunde, von denen 12 stilistische Kleinigkeiten waren. Das Signal-Rausch-Verhältnis machte das Review unbrauchbar.

Die OODA-Lösung: Ich ordnete die Aufgabe als drei separate Teilaufgaben ein (Korrektheit, Sicherheit, Konventionen) und erstellte drei dedizierte Reviewer-Subagenten, jeweils mit eingeschränktem Tool-Zugriff und spezifischen Bewertungskriterien. Der Korrektheitsprüfer meldet nur Logikfehler. Der Sicherheitsprüfer meldet nur OWASP-Schwachstellen. Der Konventionsprüfer meldet nur Musterabweichungen. Das Rauschen sank auf nahezu null, weil jeder Prompt eng auf eine Dimension zugeschnitten ist.3

Fehlschlag 3: Der Übersetzungsprompt. „Übersetze diesen Blogbeitrag ins Koreanische.” Das Modell übersetzte, verlor dabei aber die gesamte Markdown-Formatierung, entfernte Fußnotenverweise und schrieb technische Begriffe um, die auf Englisch hätten bleiben sollen.

Die OODA-Lösung: Ich beobachtete, was „übersetzen” für meinen Anwendungsfall tatsächlich bedeutete: Markdown-Struktur beibehalten, Fußnotennummerierung beibehalten, Codeblöcke nicht übersetzen, Eigennamen auf Englisch belassen, Redewendungen adaptieren statt sie wörtlich zu übertragen. Die Liste der Einschränkungen wurde länger als die Übersetzungsanweisung. Jede Einschränkung eliminierte einen Fehlermodus, den „übersetze das” produziert hätte.4


Die OODA-Schleife angewandt auf Prompting

Phase 1: Beobachten

Bevor Sie ein einziges Wort des Prompts schreiben, beobachten Sie den Problemraum:

Was ist die tatsächliche Aufgabe? Nicht die oberflächliche Anfrage, sondern das zugrundeliegende Bedürfnis. „Fasse dieses Dokument zusammen” könnte tatsächlich bedeuten: „Extrahiere die drei Entscheidungen, die in diesem Meeting getroffen wurden, damit ich die Aufgabenpunkte weiterverfolgen kann.”

Was muss das Modell wissen? Zählen Sie den Kontext auf, der für eine korrekte Antwort erforderlich ist. Fehlender Kontext führt zu Halluzinationen. Übermäßiger Kontext verschwendet Token und kann das Modell ablenken.

Wie sieht die Ausgabe aus? Definieren Sie Format, Länge, Tonalität und Struktur der gewünschten Ausgabe, bevor Sie den Prompt schreiben. Vage Erwartungen an die Ausgabe erzeugen vage Ausgaben.5

Checkliste für die Beobachtung: - [ ] Tatsächliche Aufgabe (nicht die oberflächliche Anfrage) identifiziert - [ ] Erforderlicher Kontext aufgezählt - [ ] Ausgabeformat definiert - [ ] Erfolgskriterien festgelegt - [ ] Fehlermodi antizipiert

Phase 2: Orientieren

Ordnen Sie die Aufgabe im Fähigkeitsraum des Modells ein:

Klassifikation des Aufgabentyps. Handelt es sich um Extraktion (Informationen aus bereitgestelltem Text ziehen), Generierung (neue Inhalte erstellen), Transformation (zwischen Formaten konvertieren), Analyse (Inhalte bewerten und darüber schlussfolgern) oder Klassifikation (Eingaben kategorisieren)?6

Jeder Aufgabentyp hat etablierte Prompt-Muster. Meine 44 Skills spiegeln das Muster wider: Der blog-evaluator Skill nutzt Analysemuster (gewichtete Bewertungsmatrix, strukturierte Punktevergabe). Der blog-writer-core Skill nutzt Generierungsmuster (Stilregeln, Einschränkungslisten, Beispielstrukturen). Der citation-verifier Skill nutzt Extraktionsmuster (Behauptungen extrahieren, mit Quellen abgleichen).

Komplexitätsbewertung. Kann die Aufgabe mit einem einzigen Prompt erledigt werden, oder erfordert sie Zerlegung? Eine Faustregel: Wenn die Aufgabe mehr als drei verschiedene kognitive Operationen erfordert, zerlegen Sie sie.

Mein Deliberation-System treibt die Zerlegung weiter: Wenn das Konfidenzniveau niedrig ist (Wert unter 0,70), erzeugt das System mehrere Agenten, die das Problem unabhängig voneinander untersuchen, und rankt dann ihre Antworten nach Qualität. Schwellenwerte für die Komplexität einzelner Prompts variieren, aber ich zerlege jede Aufgabe, die Recherche, Analyse und Generierung vermischt.

Einschränkungs-Mapping. Welche Einschränkungen gelten? Token-Limits, Anforderungen an das Ausgabeformat, Anforderungen an die faktische Genauigkeit, Tonalitätsanforderungen, Zielgruppenüberlegungen. Jede Einschränkung wird zu einer expliziten Anweisung im Prompt.

Phase 3: Entscheiden

Treffen Sie basierend auf Beobachtung und Orientierung eine Entscheidung über die Prompt-Architektur:

Auswahl des Prompt-Musters:

Aufgabentyp Empfohlenes Muster Mein reales Beispiel
Extraktion Schema-gesteuerte Extraktion Citation Verifier: Behauptungen extrahieren, Fußnoten zuordnen
Generierung Einschränkungsliste + Beispiele Blog Writer: 14 obligatorische Stilregeln, Tonalitätsanleitung
Transformation Eingabe-Ausgabe-Paare + Beibehaltungsliste i18n-Übersetzer: Markdown, Code, Fußnoten beibehalten
Analyse Gewichtete Bewertungsmatrix + strukturierte Ausgabe Blog Evaluator: 6 Kategorien, gewichtete Punktevergabe
Klassifikation Beschriftete Beispiele + Entscheidungsbaum Content Depth Checker: 5 Originalitätssignale, Bewertung 0-5

Rollenzuweisung. Rollen funktionieren, wenn die Aufgabe von einer bestimmten Perspektive profitiert. Mein security-reviewer Subagent erhält die Rolle „Senior Security Engineer, der Code auf OWASP Top 10 Schwachstellen prüft” — die Rolle fokussiert die Ausgabe auf Sicherheitsaspekte. Rollen scheitern, wenn die Rolle der Aufgabe widerspricht („Sie sind ein kreativer Autor” für eine faktische Analyseaufgabe).7

Phase 4: Handeln

Schreiben Sie den Prompt unter Verwendung der Entscheidungen aus Phase 3. Der Prompt folgt einer konsistenten Struktur:

[ROLE] (if applicable)
[CONTEXT] (the information the model needs)
[TASK] (the specific instruction)
[FORMAT] (the expected output structure)
[CONSTRAINTS] (restrictions and requirements)
[EXAMPLES] (if using few-shot)

Die Struktur ist keine Vorlage, die mechanisch ausgefüllt wird. Die Struktur ist eine Checkliste: Haben die Phasen Beobachtung, Orientierung und Entscheidung genügend Klarheit geschaffen, um jeden Abschnitt zu schreiben? Wenn ein Abschnitt unklar ist, kehren Sie zur entsprechenden früheren Phase zurück.8


Meine Prompt-Bibliothek: 44 Skills als strukturierte Prompts

Mein Claude Code Skills-System ist im Wesentlichen eine Prompt-Bibliothek, organisiert nach Aufgabentyp. Jeder Skill folgt der OODA-Struktur:

---
description: FastAPI backend development patterns and conventions
allowed-tools: [Read, Grep, Glob, Edit, Write, Bash]
---
# FastAPI Development Expertise

## Project Structure
[CONTEXT: expected file layout, naming conventions]

## Route Patterns
[CONSTRAINTS: response format, error handling, dependency injection]

## Database Patterns
[CONSTRAINTS: SQLAlchemy 2.0+ async, Pydantic v2 models]

Die Skill-Beschreibung übernimmt die Beobachtung (wann soll der Skill aktiviert werden?). Das allowed-tools-Feld übernimmt die Orientierung (welche Fähigkeiten braucht die Aufgabe?). Der Inhalt übernimmt Entscheidung und Handlung (welchen Mustern soll das Modell folgen?).9

Der blog-writer-core Skill kodiert 14 obligatorische Stilregeln — Einschränkungen, die ich durch Fehlschläge entdeckt habe:

  1. Nur Aktiv („Ingenieure installierten” statt „wurde installiert von”)
  2. Kein „dies” als Subjekt (immer das Bezugswort angeben)
  3. Jede Behauptung mit einer Fußnote belegt
  4. Codeblöcke mit Sprachkennzeichnungen versehen
  5. Keine Gedankenstriche (Kommas oder Semikolons verwenden)

Jede Regel existiert, weil ich einen Beitrag veröffentlicht habe, der sie verletzte. Regel Nr. 1 entstand, weil der blog-quality-gate Hook 7 Passivkonstruktionen entdeckte. Regel Nr. 3 entstand, weil ich eine unbelegte Behauptung über eine McKinsey-Statistik veröffentlichte. Die OODA-Beobachtungsphase identifizierte den Fehler; die Einschränkung im Prompt verhindert das Wiederauftreten.10


Die Iterationsschleife

Die OODA-Schleife ist von Natur aus iterativ. Nach dem Handeln (den Prompt absenden) und dem Beobachten des Ergebnisses:

  1. Beobachten Sie die Ausgabe: Was ist korrekt? Was ist falsch? Was fehlt?
  2. Orientieren Sie die Lücke: Liegt das Problem beim Kontext (fehlende Informationen), beim Format (falsche Struktur) oder bei der Fähigkeit (Aufgabe zu komplex für einen einzelnen Prompt)?
  3. Entscheiden Sie über die Lösung: Kontext hinzufügen, Formatanweisungen anpassen oder die Aufgabe zerlegen.
  4. Handeln Sie mit dem überarbeiteten Prompt.

Jeder Iterationszyklus sollte genau eine Variable ändern. Wenn Sie mehrere Prompt-Elemente gleichzeitig ändern, ist es unmöglich festzustellen, welche Änderung welchen Effekt hervorgerufen hat.11

Mein Workflow zur Blog-Bewertung durchläuft die vollständige Iterationsschleife:

1. Lint (deterministic) → fix structural issues
2. Evaluate (LLM) → score on 6 dimensions
3. Critique (LLM) → identify specific improvements
4. Fix (LLM) → apply surgical improvements
5. Re-evaluate → verify score improved

Jeder Schritt verwendet einen anderen Prompt, der für seinen Aufgabentyp optimiert ist. Der Lint-Schritt nutzt Extraktion (Verstöße finden). Der Evaluate-Schritt nutzt Analyse (anhand der Bewertungsmatrix bewerten). Der Critique-Schritt nutzt Generierung (Verbesserungsvorschläge erstellen). Der Fix-Schritt nutzt Transformation (Änderungen unter Beibehaltung der Struktur anwenden). Die Kette erzeugt bessere Ergebnisse als ein einzelner monolithischer Prompt „verbessere diesen Beitrag”.12


Zentrale Erkenntnisse

Für Ingenieure, die KI-Funktionen entwickeln: - Durchlaufen Sie den vollständigen OODA-Zyklus, bevor Sie Prompts schreiben; 5 Minuten Beobachtung und Orientierung sparen 30 Minuten iterativer Prompt-Verfeinerung - Klassifizieren Sie den Aufgabentyp (Extraktion, Generierung, Transformation, Analyse, Klassifikation), bevor Sie ein Prompt-Muster auswählen; jeder Typ hat etablierte Muster, die generisches Prompting übertreffen - Bauen Sie eine Prompt-Bibliothek auf, organisiert nach Aufgabentyp; meine 44 Skills repräsentieren validierte Prompt-Muster, die ich projektübergreifend wiederverwende

Für Produktteams, die täglich KI nutzen: - Wenn eine KI-Ausgabe enttäuscht, diagnostizieren Sie, ob der Fehler in der Beobachtung (falsche Aufgabe identifiziert), der Orientierung (falscher Ansatz), der Entscheidung (falsches Prompt-Muster) oder der Handlung (falsche Prompt-Formulierung) liegt; die Lösung unterscheidet sich für jede Phase - Einschränkungen verhindern mehr Fehlschläge als clevere Prompt-Formulierungen; die 14 obligatorischen Regeln meines Blog-Writers erzeugen konsistentere Qualität als jede noch so ausgefeilte Anweisung „bitte schreiben Sie gut”


Referenzen


  1. Boyd, John R., „Destruction and Creation,” unveröffentlichtes Paper, 1976. 

  2. Evaluator Skill des Autors. Gewichtete Bewertungsmatrix mit 6 Kategorien, entwickelt durch iterative Prompt-Fehlschläge. Gespeichert unter ~/.claude/skills/

  3. Reviewer-Subagenten-Architektur des Autors. Drei spezialisierte Reviewer (Korrektheit, Sicherheit, Konventionen) mit eingeschränktem Tool-Zugriff und eng gefassten Bewertungskriterien. 

  4. i18n-Übersetzungssystem des Autors. Einschränkungsgesteuerte Übersetzung unter Beibehaltung von Markdown-Struktur, Fußnoten, Codeblöcken und Eigennamen in 6 Sprachen. 

  5. Anthropic, „Prompt Engineering Guide,” 2025. 

  6. Wei, Jason et al., „Chain-of-Thought Prompting Elicits Reasoning in Large Language Models,” NeurIPS 2022

  7. Shanahan, Murray et al., „Role Play with Large Language Models,” Nature, 623, 493-498, 2023. 

  8. Anthropic, „Prompt Engineering Guide,” 2025. Best Practices für Prompt-Struktur. 

  9. Skills-System des Autors für Claude Code. 44 Skills als strukturierte Prompt-Bibliothek mit OODA-orientierter Struktur. 

  10. writer-core Skill des Autors. 14 obligatorische Stilregeln, jede abgeleitet aus einem veröffentlichten Qualitätsmangel. 

  11. Zamfirescu-Pereira, J.D. et al., „Why Johnny Can’t Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts,” CHI 2023

  12. Qualitäts-Pipeline des Autors. 5-stufige Bewerten-Korrigieren-Neubewerten-Schleife mit aufgabenspezifischen Prompts in jeder Stufe.