Pętla oceny i iteracji: doprowadź każdy artefakt do 10/10

Czteroetapowy pipeline działa tylko wtedy, gdy każde przekazanie jest naprawdę dobre. Słaby artefakt na etapie 1 nie zostanie uratowany przez silnego agenta na etapie 4 — zostanie wiernie przetłumaczony na słaby kod. Ta strona to bramka jakości, która działa przy każdym przekazaniu.

Co z tego wyniesiesz

• Wielokrotnego użytku prompt krytyki w roli wrogiego recenzenta, który uruchamiasz w tym samym wątku, w którym powstał artefakt.
• Follow-up “doprowadź do 10”, który automatycznie iteruje i ponownie ocenia, dopóki nie utknie albo nie trafi na realny bloker.
• Wagi per etap (Wierność, Spójność, Kompletność, Rzemiosło), byś oceniał każde przekazanie wedle tego, co naprawdę się tam liczy.
• Jasne kryteria stopu, byś dostarczał, zamiast iterować w nieskończoność na lukach na poziomie smaku.

Dlaczego oceniać przed przekazaniem

Błędy kumulują się przez pipeline. Makieta 6/10 daje prototyp 6/10, daje system projektowy 6/10, daje kod 6/10. Koszt naprawy problemu rośnie na każdym etapie:

• Naprawa błędu typografii na etapie 1: re-prompt, 30 sekund.
• Naprawa go na etapie 2: re-prompt, regeneracja HTML, 2 minuty.
• Naprawa go na etapie 3: re-ekstrakcja tokenów, regeneracja systemu na 6 ekranach, 10 minut.
• Naprawa go na etapie 4: tropienie każdego komponentu używającego błędnego tokena, refaktor, re-test, godziny.

Ocena + iteracja na bramce zapobiega downstream’owej pracy do powtórki. Sednem nie jest perfekcjonizm — sednem jest to, że model, który właśnie wyprodukował artefakt, jest jego najtańszym recenzentem.

Cztery wymiary oceny

Stosuj je na każdym etapie. Wymiary są stałe; zmieniają się tylko wagi.

Wierność

Czy artefakt odpowiada briefowi i referencjom? Na etapie 1 — czy makieta odzwierciedla referencje i brand guide? Na etapie 4 — czy kod odpowiada tokenom i komponentom z pakietu przekazania?

Spójność

Czy artefakt trzyma się wewnętrznie? Skale typografii używane konsekwentnie. Rytm odstępów. Jeden głos w tekście. Stany rozwiązywane wedle reguły, nie na czuja.

Kompletność

Czy edge case’y, stany i tekst są wypełnione? Bez ???, bez lorem ipsum, bez “Cecha 1 / Cecha 2”, każdy komponent ma każdy stan z macierzy.

Rzemiosło

Czy jest dopracowane na tyle, że obcy założyłby, że zrobił to projektant lub starszy inżynier? Odczyt na poziomie smaku.

Oceń każdy 0–10. Wynik artefaktu to minimum z czterech, nie średnia — 10/10 w trzech wymiarach i 4/10 w czwartym to artefakt 4/10. Najsłabszy wymiar to to, co odziedziczą Twoje etapy w dół.

Prompt samokrytyki

Uruchom go w tej samej sesji, która wyprodukowała artefakt. Model, który go zbudował, ma najwięcej kontekstu do recenzji — a poproszenie go, by zagrał wrogiego recenzenta, wydobywa tryby porażki, które tryb pochwał wygładza.

Do skopiowania: wroga samokrytyka

You produced {ARTEFACT}. Now act as a hostile senior reviewer.
Rate it 0-10 on Fidelity, Coherence, Completeness, and Craft.
For every dimension scored below 10, list every specific issue
that is keeping it from 10. Cite concrete locations
(component name, region of the mockup, line of code).
Do not be polite. Do not summarize. Do not say "overall it's good".

Zastąp {ARTEFACT} dosłowną nazwą: “the mockup”, “index.html”, “the design system handoff bundle”, “the tokens.css and component skeletons you just produced”.

Utrzymanie artefaktu w kontekście — per narzędzie

Pętla jest wszędzie taka sama; różni się to, jak każde narzędzie utrzymuje świeżo zbudowany artefakt w zasięgu, by krytyka recenzowała rzecz prawdziwą, a nie jej streszczenie.

Cursor

Trzymaj plik artefaktu otwarty (np. index.html, tokens.css) i uruchom krytykę w czacie trybu agenta, by ponownie wczytał otwarty edytor. Dodaj plik @-wzmianką, jeśli agent odpływa do innego kontekstu. Użyj checkpointa przed follow-upem “doprowadź do 10”, byś mógł cofnąć złą iterację.

Claude Code

Uruchom krytykę w tej samej sesji terminala, która wygenerowała artefakt — plik jest już w kontekście, a Claude Code wczyta go z dysku przed recenzją. Wskaż ścieżkę wprost (Re-read tokens.css, then critique it), by oceniał zapisany plik, a nie własne wspomnienie.

Codex

Uruchom na tym samym tasku/worktree, który wyprodukował artefakt (App, IDE lub CLI), by diff pozostał w zasięgu. W powierzchni IDE trzymaj plik w working secie; w aplikacji kontynuuj ten sam task, zamiast zaczynać nowy, by oceniany artefakt był tym, który dopiero co napisał.

Follow-up “doprowadź do 10/10”

Do skopiowania: doprowadź do 10/10

Now fix every issue you listed. Produce the revised {ARTEFACT}.
Then re-rate it on the same four dimensions and list any
remaining gaps with concrete locations. Repeat until all four
dimensions are 10/10, or you hit a constraint you can't resolve
without me — in which case stop and tell me exactly what you need.

Klauzula “stop and tell me what you need” jest ważna. W przeciwnym razie model będzie iterował w kółko, gdy prawdziwym blokerem jest decyzja, którą musisz podjąć Ty (decyzja brandowa, kompromis produktowy, brakujące wymaganie).

Wagi specyficzne dla etapu

Wymiary są te same; wagi nie.

Etap	Najcięższe wagi	Dlaczego
1 — Makieta	Wierność, Rzemiosło	Makieta ustawia sufit wizualny. Niech referencje są odzwierciedlone, a polish wysoki; kompletność wypełni etap 2.
2 — Prototyp HTML	Kompletność, Spójność	To tu są implementowane stany. Każdy przycisk potrzebuje każdego stanu. Spójność łapie odchyły od makiety.
3 — System projektowy	Spójność, Kompletność	System jest zdefiniowany przez swoją spójność między ekranami i stanami. Oba wymiary ważą tyle samo.
4 — Kod + dokumentacja	Wierność, Rzemiosło	Wierność wobec pakietu przekazania (bez wymyślonych tokenów). Rzemiosło w kodzie (dopasowanie do istniejących konwencji, brak martwego kodu, prawdziwe typy).

Kryteria stopu — kiedy wyjść poniżej 10/10

Nie iteruj w nieskończoność. Trzy powody, by dostarczyć przy mniej niż 10/10:

1. Ograniczenie wymagające ludzkiej decyzji. Brand, prawne, kompromis produktowy lub brakujący kawałek kontekstu, który masz tylko Ty. Zatrzymaj i zdecyduj.
2. Dwie iteracje z rzędu bez poprawy. To nie jest problem polishu, to problem architektoniczny — artefakt ma zły kształt i musisz wrócić do promptu lub wyniku poprzedniego etapu, zamiast iterować dalej na tym.
3. Jesteś przy 9/10+, a pozostała luka to smak, nie jakość. Dostarczaj. Etapy w dół wyłapią to, co naprawdę istotne.

Antywzorce

• Nie ufaj samoocenie modelu bez sprawdzenia oczami. Framing wrogiego recenzenta pomaga, ale model wciąż może przegapić rzeczy, które projektant złapałby w trzy sekundy. Otwórz artefakt i spójrz na niego.
• Nie oceniaj, zanim artefakt jest sensownie kompletny. Krytyka niedokończonej makiety to teatr — model wymienia problemy, które za chwilę i tak naprawi następna iteracja. Poczekaj na pierwszy kompletny przebieg, a potem oceń.
• Nie uruchamiaj pętli na artefakcie etapu N+1 i nie nazywaj tego naprawą artefaktu etapu N. Jeśli prototyp ma złą typografię, naprawą jest ponowna ocena makiety, nie łatanie prototypu. Naprawiaj zawsze na najwcześniejszym etapie, gdzie problem się pojawia.
• Nie pomijaj pętli, gdy jesteś zmęczony. To wtedy najbardziej jej potrzebujesz. Sednem jawnej bramki jest to, że nie zależy ona od Twojego osądu w momencie przekazania.

Jeden recenzent to nie dwóch

Model oceniający siebie to jedna perspektywa. Dla pracy o wysokiej stawce — prawdziwy launch, flow widziany przez klienta, strona definiująca markę — zdobądź drugą parę oczu (członek zespołu lub inny model), by uruchomił ten sam prompt krytyki niezależnie. Dwa niezależne 10/10 to silniejszy sygnał niż 10/10 jednego modelu powiedziane dwa razy.

Powrót do pipeline’u

Każdy etap pipeline’u linkuje tutaj przy swoim przekazaniu. W razie wątpliwości — oceniaj. Koszt jednorazowego uruchomienia pętli to minuta. Koszt kumulujących się błędów przez cztery etapy to powtórka.

Wróć do czteroetapowego pipeline’u →