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.

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, że model, który właśnie wyprodukował artefakt, jest 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 tym samym wątku ChatGPT lub Claude, który wyprodukował 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.

Wyprodukowałeś {ARTEFAKT}. Teraz zagraj wrogiego starszego recenzenta.
Oceń go 0-10 w wymiarach: Wierność, Spójność, Kompletność, Rzemiosło.
Dla każdego wymiaru ocenionego poniżej 10, wymień każdy konkretny
problem, który trzyma go z dala od 10. Cytuj konkretne lokalizacje
(nazwa komponentu, region makiety, linia kodu).
Nie bądź uprzejmy. Nie podsumowuj. Nie mów "ogólnie jest dobrze".

Zastąp {ARTEFAKT} dosłowną nazwą: “makieta”, “index.html”, “pakiet przekazania systemu projektowego”, “tokens.css i szkielety komponentów, które właśnie wyprodukowałeś”.

Follow-up “doprowadź do 10/10”

Teraz napraw każdy problem, który wymieniłeś. Wyprodukuj zrewidowany
{ARTEFAKT}. Następnie ponownie oceń go w tych samych czterech
wymiarach i wymień pozostałe luki z konkretnymi lokalizacjami.
Powtarzaj, aż wszystkie cztery wymiary będą 10/10, lub trafisz
na ograniczenie, którego nie jesteś w stanie rozwiązać beze mnie —
w takim wypadku zatrzymaj się i powiedz mi dokładnie, czego
potrzebujesz.

Klauzula “zatrzymaj się i powiedz mi czego potrzebujesz” 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:

Ograniczenie wymagające ludzkiej decyzji. Brand, prawne, kompromis produktowy lub brakujący kawałek kontekstu, który masz tylko Ty. Zatrzymaj i zdecyduj.
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.
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.

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 →