Pętla OODA w inżynierii promptów: czego nauczyło mnie pięć porażek

Pętla OODA pułkownika Johna Boyda została opracowana na potrzeby podejmowania decyzji przez pilotów myśliwców w latach 60. XX wieku — pilot, który szybciej kończył cykl obserwuj-orientuj-decyduj-działaj, zyskiwał decydującą przewagę, niezależnie od możliwości samolotu. Odkryłem, że ta sama zasada ma zastosowanie w inżynierii promptów — po pięciu kosztownych porażkach, które nauczyły mnie, że napisanie prompta to najmniej istotny etap.¹

TL;DR

Pętla OODA (Obserwuj, Orientuj, Decyduj, Działaj) stanowi systematyczne podejście do inżynierii promptów, które zapobiega najczęstszemu błędowi: działaniu (pisaniu prompta) przed obserwacją (zrozumieniem pełnego kontekstu). Po zbudowaniu 44 skilli — z których każdy jest ustrukturyzowanym promptem z logiką automatycznej aktywacji — nauczyłem się, że sam prompt odpowiada za mniej więcej 20% wyniku. Pozostałe 80% to obserwacja (jakiego kontekstu potrzebuje model?), orientacja (jaki to typ zadania?) i decyzja (jaki wzorzec prompta pasuje do danego typu zadania?). Poniższy interaktywny kreator przeprowadza przez pełny cykl OODA. Rezultat: prompty, które działają za pierwszym razem, zamiast wymagać iteracyjnego dopracowywania.

Prompt, który zawiódł pięć razy

Zanim nauczyłem się obserwować przed działaniem, pisałem prompty jak programista piszący kod: od razu przechodząc do rozwiązania.

Porażka 1: Ewaluator postów blogowych. Moja pierwsza próba prompta do oceny jakości postów blogowych: „Oceń ten post blogowy i przyznaj mu ocenę od 1 do 10.” Model zwrócił niejasny akapit z „7/10” i bez żadnych konkretnych wskazówek. Iterowałem cztery razy, zanim zdałem sobie sprawę, że problem nie tkwił w sformułowaniu prompta — problem polegał na tym, że nie zdefiniowałem, co oznacza „jakość”.

Rozwiązanie OODA: Poświęciłem 30 minut na obserwację własnego procesu oceniania. Zidentyfikowałem sześć konkretnych wymiarów, na których mi zależało: wartość dla czytelnika (25%), dokładność techniczna (20%), jakość edukacyjna (20%), jakość pisarska (15%), rzetelność merytoryczna (15%) i skuteczność SEO (5%). Ważona rubryka stała się skillem blog-evaluator i od tego czasu każda ocena daje spójne, praktyczne wyniki.²

Porażka 2: Recenzent kodu. Mój pierwszy prompt do recenzji: „Przejrzyj ten kod pod kątem błędów i problemów z bezpieczeństwem.” Model zwrócił 15 uwag, z których 12 dotyczyło stylistycznych drobiazgów. Stosunek sygnału do szumu sprawił, że recenzja była bezużyteczna.

Rozwiązanie OODA: Zorientowałem zadanie jako trzy oddzielne podzadania (poprawność, bezpieczeństwo, konwencje) i zbudowałem trzech dedykowanych subagentów-recenzentów, z których każdy miał ograniczony dostęp do narzędzi i konkretne kryteria oceny. Recenzent poprawności zgłasza wyłącznie błędy logiczne. Recenzent bezpieczeństwa zgłasza wyłącznie podatności OWASP. Recenzent konwencji zgłasza wyłącznie odchylenia od wzorców. Szum spadł niemal do zera, ponieważ każdy prompt jest ściśle ograniczony do jednego wymiaru.³

Porażka 3: Prompt do tłumaczenia. „Przetłumacz ten post blogowy na koreański.” Model przetłumaczył, ale utracił całe formatowanie markdown, usunął odnośniki do przypisów i przepisał terminy techniczne, które powinny pozostać po angielsku.

Rozwiązanie OODA: Zaobserwowałem, co „tłumaczenie” faktycznie oznacza w moim przypadku użycia: zachowanie struktury markdown, zachowanie numeracji przypisów, pozostawienie bloków kodu bez tłumaczenia, pozostawienie nazw własnych po angielsku, adaptacja idiomów zamiast dosłownej transliteracji. Lista ograniczeń stała się dłuższa niż sama instrukcja tłumaczenia. Każde ograniczenie eliminowało tryb awarii, który „przetłumacz to” by wygenerował.⁴

Pętla OODA w zastosowaniu do promptów

Faza 1: Obserwuj

Zanim napiszesz choćby jedno słowo prompta, zaobserwuj przestrzeń problemu:

Jakie jest faktyczne zadanie? Nie powierzchowne żądanie, ale rzeczywista potrzeba. „Podsumuj ten dokument” może w rzeczywistości oznaczać „wyodrębnij trzy decyzje podjęte na tym spotkaniu, abym mógł podjąć dalsze działania”.

Co model musi wiedzieć? Wymień kontekst wymagany do poprawnej odpowiedzi. Brakujący kontekst powoduje halucynacje. Nadmiarowy kontekst marnuje tokeny i może rozpraszać model.

Jak wygląda oczekiwany wynik? Zdefiniuj format, długość, ton i strukturę pożądanego wyniku przed napisaniem prompta. Niejasne oczekiwania co do wyniku generują niejasne wyniki.⁵

Lista kontrolna obserwacji: - [ ] Zidentyfikowano faktyczne zadanie (nie powierzchowne żądanie) - [ ] Wymieniono wymagany kontekst - [ ] Zdefiniowano format wyjściowy - [ ] Określono kryteria sukcesu - [ ] Przewidziano tryby awarii

Faza 2: Orientuj

Zorientuj zadanie w przestrzeni możliwości modelu:

Klasyfikacja typu zadania. Czy zadanie polega na ekstrakcji (wyciąganie informacji z dostarczonego tekstu), generowaniu (tworzenie nowej treści), transformacji (konwersja między formatami), analizie (ocenianie i rozumowanie o treści), czy klasyfikacji (kategoryzowanie danych wejściowych)?⁶

Każdy typ zadania ma ustalone wzorce promptów. Moje 44 skille odzwierciedlają ten wzorzec: skill blog-evaluator wykorzystuje wzorce analityczne (ważona rubryka, ustrukturyzowane ocenianie). Skill blog-writer-core wykorzystuje wzorce generatywne (reguły stylu, listy ograniczeń, przykładowe struktury). Skill citation-verifier wykorzystuje wzorce ekstrakcyjne (wyciąganie twierdzeń, dopasowywanie do źródeł).

Ocena złożoności. Czy zadanie można zrealizować jednym promptem, czy wymaga dekompozycji? Ogólna zasada: jeśli zadanie wymaga więcej niż trzech odrębnych operacji poznawczych, należy je rozłożyć.

Mój system deliberacji posuwa dekompozycję dalej: gdy poziom pewności jest niski (wynik poniżej 0,70), system uruchamia wielu agentów do niezależnej eksploracji problemu, a następnie ranguje ich odpowiedzi według jakości. Progi złożoności dla pojedynczego prompta są zmienne, ale dekomponuję każde zadanie, które łączy badanie, analizę i generowanie.

Mapowanie ograniczeń. Jakie ograniczenia obowiązują? Limity tokenów, wymagania dotyczące formatu wyjściowego, potrzeby dokładności merytorycznej, wymagania tonalne, specyfika odbiorców. Każde ograniczenie staje się jawną instrukcją w prompcie.

Faza 3: Decyduj

Na podstawie obserwacji i orientacji zdecyduj o architekturze prompta:

Wybór wzorca prompta:

Przypisanie roli. Role działają, gdy zadanie korzysta z określonej perspektywy. Mój subagent security-reviewer otrzymuje rolę „starszy inżynier bezpieczeństwa przeglądający kod pod kątem podatności OWASP Top 10” — rola skupia wynik na kwestiach bezpieczeństwa. Role zawodzą, gdy rola jest sprzeczna z zadaniem („Jesteś kreatywnym pisarzem” przy zadaniu analizy merytorycznej).⁷

Faza 4: Działaj

Napisz prompt na podstawie decyzji z Fazy 3. Prompt ma spójną 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)

Struktura nie jest szablonem do mechanicznego wypełniania. Struktura jest listą kontrolną: czy fazy obserwacji, orientacji i decyzji dostarczyły wystarczającej jasności, aby napisać każdą sekcję? Jeśli jakakolwiek sekcja jest niejasna, należy wrócić do odpowiedniej wcześniejszej fazy.⁸

Moja biblioteka promptów: 44 skille jako ustrukturyzowane prompty

Mój system skilli w Claude Code to w istocie biblioteka promptów zorganizowana według typu zadania. Każdy skill odpowiada strukturze OODA:

---
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]

Opis skilla obsługuje obserwację (kiedy skill powinien się aktywować?). Pole allowed-tools obsługuje orientację (jakich możliwości wymaga zadanie?). Treść obsługuje decyzję i działanie (jakie wzorce powinien stosować model?).⁹

Skill blog-writer-core koduje 14 obowiązkowych reguł stylu — ograniczeń odkrytych poprzez porażki:

1. Wyłącznie strona czynna („Inżynierowie zainstalowali”, a nie „zostało zainstalowane przez”)
2. Zakaz „to” jako podmiotu (zawsze określaj referent)
3. Każde twierdzenie opatrzone przypisem
4. Bloki kodu oznaczone identyfikatorami języka
5. Zakaz myślników typu em dash (używać przecinków lub średników)

Każda reguła istnieje, ponieważ opublikowałem post, który ją łamał. Reguła nr 1 powstała, gdy hook blog-quality-gate wykrył 7 zdań w stronie biernej. Reguła nr 3 powstała po opublikowaniu nieopatrzonego źródłem twierdzenia o statystyce McKinsey. Faza obserwacji OODA zidentyfikowała awarię; ograniczenie w prompcie zapobiega jej powtórzeniu.¹⁰

Pętla iteracyjna

Pętla OODA jest z natury iteracyjna. Po działaniu (wysłaniu prompta) i zaobserwowaniu wyniku:

1. Obserwuj wynik: co jest poprawne? Co jest błędne? Czego brakuje?
2. Orientuj lukę: czy problem dotyczy kontekstu (brakujące informacje), formatu (zła struktura), czy zdolności (zadanie zbyt złożone na pojedynczy prompt)?
3. Decyduj o poprawce: dodaj kontekst, skoryguj instrukcje formatowania lub rozłóż zadanie.
4. Działaj ze zrewidowanym promptem.

Każdy cykl iteracji powinien zmieniać dokładnie jedną zmienną. Zmiana wielu elementów prompta jednocześnie uniemożliwia identyfikację, która zmiana spowodowała jaki efekt.¹¹

Mój proces oceny postów blogowych realizuje pełną pętlę iteracyjną:

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

Każdy krok wykorzystuje inny prompt zoptymalizowany pod dany typ zadania. Krok lintowania wykorzystuje ekstrakcję (znajdź naruszenia). Krok ewaluacji wykorzystuje analizę (oceniaj według rubryki). Krok krytyki wykorzystuje generowanie (twórz sugestie usprawnień). Krok naprawy wykorzystuje transformację (zastosuj zmiany zachowując strukturę). Łańcuch daje lepsze wyniki niż pojedynczy monolityczny prompt „ulepsz ten post”.¹²

Kluczowe wnioski

Dla inżynierów budujących funkcje AI: - Należy przejść pełny cykl OODA przed napisaniem prompta; 5 minut obserwacji i orientacji oszczędza 30 minut iteracyjnego dopracowywania promptów - Należy sklasyfikować typ zadania (ekstrakcja, generowanie, transformacja, analiza, klasyfikacja) przed wyborem wzorca prompta; każdy typ ma ustalone wzorce, które przewyższają generyczne promptowanie - Warto zbudować bibliotekę promptów zorganizowaną według typu zadania; moje 44 skille reprezentują zwalidowane wzorce promptów, które wykorzystuję ponownie w różnych projektach

Dla zespołów produktowych korzystających z AI na co dzień: - Gdy wynik AI rozczarowuje, należy zdiagnozować, czy awaria dotyczy obserwacji (źle zidentyfikowane zadanie), orientacji (złe podejście), decyzji (zły wzorzec prompta) czy działania (złe sformułowanie prompta); naprawa jest inna dla każdej fazy - Ograniczenia zapobiegają większej liczbie awarii niż sprytne formułowanie promptów; 14 obowiązkowych reguł mojego autora blogowego daje bardziej spójną jakość niż jakiekolwiek „proszę, pisz dobrze”

Źródła