O czym jest ten film
- Jedno udane wykonanie zadania przez AI nie dowodzi niczego — potrzebny jest systematyczny sposób sprawdzania jakości.
- Skille i prompty systemowe należy traktować jak nowego pracownika: dawać zadanie, sprawdzać, korygować, iterować, dopiero potem oddawać samodzielnie.
- Skill buduje się najpierw wykonując zadanie na żywo w rozmowie z AI, a dopiero na końcu prosząc o „zakapsułkowanie” całego procesu.
- Prompt budujący skill musi zawierać dwa ograniczenia: skill ma być minimalny oraz niezależny od konkretnego przykładu.
- Dwa najczęstsze złe sposoby testowania: ocena „na oko” oraz testowanie na tym samym przykładzie, na którym skill powstał.
- Właściwe testowanie wymaga dwóch rozdzielnych zbiorów przykładów: budującego i testowego, ukrytego przed AI.
- W teście podaje się AI wyłącznie dane wejściowe, a jego wynik porównuje się z własnym, wykonanym wcześniej ręcznie.
- Kryteria oceny muszą być binarne — siedem do dziesięciu pytań tak/nie, wygenerowanych przez AI na podstawie trzech dobrych własnych próbek.
- Ocenę wykonuje osobny subagent z własnym oknem kontekstu, żeby uniknąć stronniczości modelu wobec własnej pracy.
- Pętla doskonalenia: każde „nie” w raporcie prowadzi do najmniejszej możliwej, systemowej poprawki w skillu — a proces wraca przy nowych modelach i przy podniesieniu własnych standardów.
Redakcyjne tłumaczenie
Jedna udana próba niczego nie dowodzi
Pewnie znasz tę sytuację: patrzysz, jak twój skill AI perfekcyjnie wykonuje zadanie, i uznajesz, że sprawa załatwiona. Rzecz w tym, że to jedno zwycięstwo nie dowodzi praktycznie niczego.
Nazywam się Dylan, prowadzę firmę doradczą zajmującą się AI. Ocena tego, czy czyjeś skille i projekty AI faktycznie są dobre, to większość mojej pracy. Pokażę ci, jak naprawdę przetestować skill na tle twojej własnej roboty, a potem jak uruchomić pętlę, która doprowadzi go od stanu „w porządku” do poziomu, na którym pracujesz ty. Po tym materiale będziesz umiał udowodnić, że skill jest dobry — a nie tylko mieć taką nadzieję.
(Informacja dodatkowa: „skill” w ekosystemie Claude’a to zapisany zestaw instrukcji i kontekstu, który model wczytuje na żądanie przy określonym typie zadania. W praktyce ta sama logika dotyczy promptów systemowych w projektach ChatGPT czy Claude.)
Trenuj AI tak, jak trenujesz pracownika
Zastanów się przez chwilę, jak wygląda wdrażanie nowej osoby w zespole. Zwykle proces wygląda tak: dajesz jej małe zadanie. Potem sprawdzasz, co z tego wyszło. Następnie korygujesz. Osoba iteruje — próbuje ponownie na tym samym zadaniu albo na innym o podobnej skali i złożoności. Po kilku takich rundach budujesz zaufanie, że poradzi sobie bez twojej kontroli, i przekazujesz zadanie w całości.
Pytanie, które regularnie zadaję sobie i klientom, brzmi: dlaczego z AI postępujemy inaczej? Powinno być dokładnie tak samo — zwłaszcza przy zadaniach o wysokiej krytyczności albo takich, które wykonujemy często.
To, co widzę najczęściej, wygląda inaczej. Ktoś tworzy projekt albo skill, korzysta z niego, wprowadza jedną–dwie drobne poprawki, a potem po prostu godzi się z tym, że AI jest „w miarę okej, ale nie idealne”. Zamiast tego trzeba ten skill wytrenować — iterować z nim tak długo, aż stale spełnia twoje standardy.
Faza pierwsza: najpierw udowodnij, że działa
Będę mówił o skillach, ale ta sama logika dotyczy promptów systemowych w projektach.
Proces, który polecam wszystkim klientom, zaczyna się od dowodu. Najpierw wybierasz zadanie, które chcesz zautomatyzować lub wspomóc skillem — coś, co wykonujesz regularnie. Potem wykonujesz to zadanie razem z AI: otwierasz nową rozmowę w Claude Cowork, Codeksie, ChatGPT albo Claudzie i przeprowadzasz zadanie na żywo w tej konwersacji. Pracujesz nad nim raz za razem, dopracowując wynik, aż spełni twoje standardy. Dopiero gdy to osiągniesz, prosisz AI, żeby zakapsułkowało cały ten proces w skill.
Jest wiele powodów, dla których akurat to podejście działa najlepiej, ale najważniejszy jest ten: AI samo wykonało tę pracę, a praca jest pełna niuansów i subtelności. Musimy mieć pewność, że model zrozumiał je wszystkie przez wykonanie, zanim zacznie tworzyć prompt systemowy albo skill.
Prompt budujący skill i jego dwa ograniczenia
Na sam koniec tamtej rozmowy wklejasz prosty prompt. Mówisz w nim AI: „Chcę, żebyś zamienił to, co przed chwilą zrobiliśmy w tej rozmowie, w skill — użyj do tego swojego kreatora skilli”. To jedna z pięknych właściwości skilli: AI potrafi je tworzyć samo.
Dokładamy jednak dwa istotne ograniczenia.
Pierwsze: skill ma być oszczędny i minimalny — każda linijka musi zasłużyć na swoje miejsce. To kluczowe, bo AI bywa bardzo rozwlekłe. Zostawione samo sobie stworzy rozdęty skill albo prompt. A im bardziej rozdęty skill, tym mniejsza szansa, że model wykona zadanie zgodnie z instrukcją.
Drugie ograniczenie, szczególnie ważne przy skillach: skill ma być niezależny od tematu. Mówimy modelowi wprost, żeby uchwycił osąd i niuanse, których użyliśmy w procesie, tak by skill dał się stosować ogólnie. W przykładzie, na którym pracuję, tworzymy ofertę handlową. Kiedy więc mówię, że to skill do ofert, chodzi mi o pisanie ofert w ogóle — a nie tej jednej, nad którą właśnie pracowaliśmy.
Najprościej ujmując to drugie ograniczenie: właśnie zbudowaliśmy tę ofertę i jestem zadowolony z wyniku, więc zamknij cały proces w skillu tak, aby każda przyszła oferta spełniała te same standardy, bez przywiązania do treści tej konkretnej.
Jak większość ludzi źle testuje
W tym momencie zrobiliśmy to, co robi większość: mamy skill albo prompt systemowy. Kolejna faza to miejsce, w którym wiele osób odpada — nie trenują AI, tylko po prostu go używają. To najważniejsza część materiału.
Niektórzy próbują testować, ale robią to słabo. Widzę dwa najczęstsze podejścia.
Pierwsze: czytają wynik i robią „vibe check”. „No, jest w miarę okej, wystarczy, idę dalej”. To ocena na oko — nie jest systematyczna.
Drugie: otwierają nową rozmowę i wywołują skill z tym samym wejściem, na którym go budowali. To też jest złe podejście. Jeśli testujesz skill na tym samym przykładzie, z którego powstał, jest spora szansa, że model zapisał część tych niuansów we własnej pamięci. Dostaniesz coś idealnego, ale na innym przykładzie wynik może już nie spełniać twoich standardów.
(Informacja dodatkowa: chodzi o mechanizm pamięci między rozmowami, obecny dziś w ChatGPT i Claudzie — model może przenieść szczegóły z wcześniejszej sesji, co zafałszowuje test.)
Dwa zbiory przykładów: budujący i testowy
Tak testowanie polecam klientom — zwłaszcza przy skillach krytycznych albo używanych bardzo często.
Tworzymy dwa zbiory przykładów. Pierwszy to zbiór budujący: przykłady, na których powstaje skill lub prompt systemowy. Drugi to zbiór testowy: na nim sprawdzamy jakość AI bez możliwości „ściągania”. Musisz mieć pewność, że model w ogóle nie zobaczy zbioru testowego w fazie budowania. Trzeba go przed nim ukryć.
W fazie budowania pracujesz na danych wejściowych i wyjściowych. Niezależnie od zadania AI zawsze coś przyjmuje i coś zwraca — wnioski, decyzję, raport, prezentację, cokolwiek. W tej fazie model musi zobaczyć jedno i drugie: to, na co patrzysz, oraz to, co z tego wytwarzasz. Dopiero widząc obie strony, jest w stanie trafić w twoje standardy i oczekiwania jakościowe.
W fazie testowej dajemy modelowi wyłącznie wejście. Zakładamy, że wyjścia nie ma, bo to model ma je stworzyć. Podajemy wejście, uruchamiamy skill, dostajemy wynik.
Ważne, żeby testować na sprawach, które już wcześniej wykonałeś ręcznie. Dzięki temu możesz porównać wynik AI z własnym i ocenić, jak blisko twojego standardu jest model w tym konkretnym przypadku.
Kryteria muszą być binarne
Tu znowu wiele osób odpada. Porównanie wyniku AI z własnym musi być obiektywne, a kryteria oceny — binarne.
W tworzeniu kryteriów pomoże samo AI. Używasz do tego kolejnego promptu, już po stworzeniu skilla — bo najpierw jest skill, a potem kryteria, które w nim osadzimy. Zaczynasz świeżą rozmowę i mówisz: „Chcę, żebyś stworzył checklistę, która powie mi, czy mój szkic oferty jest dobry”. Podstawiasz tu własne zadanie.
Następnie podajesz AI trzy próbki: „Oto trzy oferty, które napisałem i które skutecznie wygrały”. Analogicznie — trzy próbki tego, czym się zajmujesz. Potem dodajesz: „A oto skill, który będzie pisał nowe oferty w przyszłości”.
Model ma teraz dostęp do skilla i do trzech dobrych, twoich własnych próbek. Najpierw przygląda się ofertom, systematycznie je analizuje i ustala, co czyni je dobrymi. Następnie destyluje to do listy — najlepiej od siedmiu do dziesięciu pytań binarnych, z odpowiedzią tak/nie.
Binarność jest obowiązkowa, bo za chwilę każemy AI oceniać własną pracę podczas pisania oferty.
Gotowe kryteria wyglądają mniej więcej tak — same pytania rozstrzygalne. Czy oferta zaczyna się od problemu klienta? Tak/nie. Czy cena jest na pierwszej stronie? Czy oferta mieści się na dwóch stronach? Każde pytanie ma odpowiedź tak/nie, zaliczone/niezaliczone.
Ocenia subagent, nie model rodzic
Gdy kryteria nam odpowiadają, chcemy, żeby AI wbudowało je w skill. Jest jednak bardzo konkretny sposób, w jaki mają być używane.
Załóżmy, że mamy skill piszący ofertę. AI, z którym rozmawiamy — model rodzic — pisze ofertę. Następnie powołuje subagenta, „małe AI”, którego zadaniem jest ocena. Ten subagent ocenia pracę rodzica względem stworzonych przez nas kryteriów.
Dlaczego subagent, a nie samoocena rodzica? Bo model oceniający własną pracę jest wobec niej stronniczy. Powie: „tak, wszystko zaliczone, bo jestem świetny”. Tego nie chcemy. Subagent ma własne okno kontekstu i mniejsze przywiązanie do tego wyniku. Przeprowadza ocenę względem checklisty i zwraca rodzicowi raport z ustaleniami. Rodzic przekazuje nam finalny raport wraz z gotowym szkicem oferty.
Prompt, który to konfiguruje, jest prosty. Mówisz: dodaj do naszego istniejącego skilla krok oceniający. Po tym, jak skill napisze ofertę, powołaj osobnego subagenta w roli oceniającego. Ma patrzeć świeżym okiem, wyłącznie na gotową ofertę i na dostarczoną checklistę tak/nie. Ma zwrócić raport pokazujący każde pytanie, odpowiedź tak/nie, wynik zaliczony/niezaliczony, a przy niezaliczeniu — jednozdaniowe uzasadnienie lub dowód, dlaczego nie przeszło.
Ten ostatni element jest naprawdę ważny: uzasadnienie porażki uruchamia kolejny etap procesu — pętlę, czyli stopniowe doprowadzanie skilla do twojego poziomu jakości.
Pętla doskonalenia
Mamy więc skill z wbudowanymi kryteriami i instrukcją, by AI oceniało własną pracę przy pomocy subagenta. Kiedy dostajemy wynik, sprawdzamy: czy wszystkie punkty są na „tak”, czy pojawiły się „nie”? Jeśli są „nie” — trzeba poprawić skill.
Kopiujesz kolejny prompt do tego samego wątku, w którym otrzymałeś raport i ofertę. Podajesz w nim ofertę, którą napisałeś sam. To jest właśnie ślepy test: mamy próbki ofert napisanych wcześniej i sprawdzamy, czy AI potrafi napisać tę samą ofertę z tych samych danych wejściowych. Mówimy więc: oto oferta napisana przez skill (model już ją ma), oto oferta, którą napisałem ręcznie (to dla niego nowa informacja) oraz checklista pytań, które nie przeszły (to również już jest w rozmowie).
Teraz prosimy: przeanalizuj metodycznie instrukcje skilla i ustal dokładnie, w którym miejscu skill nas zawiódł i dlaczego AI nie zbliżyło się wystarczająco do naszych standardów dla tego typu oferty. Gdy już zidentyfikujesz te miejsca, wprowadź najmniejsze możliwe zmiany w skillu, które naprawią problem systemowy — taki, który powtórzy się przy przyszłych ofertach, a nie tylko przy tej jednej. Potem pokaż mi dokładnie, co zmieniłeś.
Dwie uwagi. Prośba o najmniejszą możliwą zmianę wraca do wcześniejszego punktu: AI bywa rozwlekłe i rozdęłoby nam skill poprawkami. Zmiana ma być celna i minimalna. Poza tym chcemy wiedzieć, co dokładnie zostało zmienione — żeby mieć świadomość ulepszeń i móc cofnąć te, z którymi się nie zgadzamy.
To cały proces: budujesz skill, testujesz go na ślepych zbiorach danych, a potem uruchamiasz pętlę. Prawdopodobnie trzeba będzie ją powtórzyć wielokrotnie, zanim AI trafi w twoje standardy.
Kiedy wrócić do procesu, mimo że wszystko działa
Nawet gdy skill już stale spełnia twoje oczekiwania, są powody, by przejść ten proces ponownie.
Po pierwsze, wychodzą nowe modele. Za każdym razem warto sprawdzić nowy model na swoim procesie i zobaczyć, czy wypada lepiej, czy gorzej. Jeśli gorzej, najczęściej znaczy to, że wokół inteligentnego modelu owinięto zbyt dużo promptu — trzeba go przyciąć. Mówiłem o tym w wielu wcześniejszych materiałach, ale w skrócie: gdy pojawia się naprawdę zdolny model, a ty masz ogromny prompt napisany pod starszy, słabszy model, ten prompt zwykle działa jak zestaw ograniczeń, które nie pozwalają nowemu modelowi rozwinąć pełni możliwości.
Drugi powód to zmiana twoich własnych standardów. Jeśli podniosły się jeszcze wyżej, musisz zaktualizować proces: uruchomić pętlę, poprawić skill i powiązane z nim kryteria, żeby AI też podniosło poziom.
Podsumowanie
Trzy najważniejsze rzeczy.
Po pierwsze: nie używaj AI — trenuj je, tak jak trenowałbyś pracownika.
Po drugie: kluczowym elementem tego procesu jest udowodnienie, że skill lub prompt systemowy jest dobry w twoim zastosowaniu. Jedyny sposób to ślepy test — testujesz na zbiorze, którego model nie widział, podajesz mu wyłącznie wejścia, a wynik porównujesz ze swoimi wcześniejszymi rezultatami.
Po trzecie: gdy masz już binarne kryteria oceny, uruchamiasz pętlę na stałe. Za każdym razem, gdy w raporcie pojawia się seria „nie” zamiast „tak”, dostajesz gotową listę obszarów do poprawy — to są twoje celowane naprawy i to od nich zaczyna się pętla.
Na koniec jeszcze jedno: zanim zaczniesz trenować skill, trzeba wybrać właściwy skill. Ta pętla opłaca się tylko wtedy, gdy skill w ogóle pasuje do twojej pracy. Skill, który zbudowałeś sam, niesie twój kontekst. Pobrany, zbudowany przez kogoś innego — nie niesie.
(Informacja dodatkowa: autor odsyła tu do osobnego materiału o wyborze między zbudowaniem skilla od zera, pożyczeniem cudzego a sklonowaniem i przerobieniem go pod siebie.)
10 najważniejszych takeaways — z kontekstem zastosowania
1.Jeden udany przebieg to nie dowód jakości
Na czym polega: Pojedyncze poprawne wykonanie zadania przez skill nie mówi nic o jego powtarzalności. Może to być trafienie losowe albo efekt tego, że akurat ten przykład był łatwy.
Jak stosować: Zanim uznasz skill za gotowy, zaplanuj minimum kilka niezależnych przebiegów na różnych przykładach i dopiero z ich rozkładu wnioskuj o jakości.
Na co uważać: Pokusa „działa, idę dalej” jest najsilniejsza przy zadaniach, które robisz najczęściej — a to właśnie one najbardziej zasługują na rzetelny test.
2.Traktuj skill jak nowego pracownika
Na czym polega: Ten sam cykl, który stosujesz przy wdrażaniu człowieka — małe zadanie, sprawdzenie, korekta, iteracja, przekazanie samodzielności — jest właściwym modelem pracy ze skillem.
Jak stosować: Nie przekazuj skillowi pełnej odpowiedzialności za proces, dopóki nie przeszedł kilku rund korekty pod twoim nadzorem.
Na co uważać: Autor rezerwuje ten wysiłek dla zadań krytycznych albo bardzo częstych. Trenowanie skilla do czegoś, co robisz raz na kwartał, to marnowanie czasu.
3.Buduj skill z wykonanej pracy, nie z opisu
Na czym polega: Najpierw wykonujesz zadanie na żywo w rozmowie z AI, dopracowując wynik do swojego standardu, a dopiero na końcu prosisz o zamknięcie tego procesu w skill.
Jak stosować: Nie zaczynaj od pisania instrukcji skilla. Zacznij od jednej sesji roboczej i dopiero jej finał zamień w prompt „zamknij to, co zrobiliśmy, w skill”.
Na co uważać: Skill przejmuje jakość tej sesji. Jeśli wynik rozmowy był tylko „w porządku”, skill utrwali właśnie ten poziom.
4.Dwa ograniczenia w prompcie budującym skill
Na czym polega: Skill ma być minimalny (każda linijka zasłużyła na swoje miejsce) i niezależny od tematu (uchwycony osąd, nie treść konkretnego przykładu).
Jak stosować: Wpisz oba warunki wprost do promptu tworzącego skill. Sformułuj drugi tak: „ma spełniać te standardy przy każdej przyszłej ofercie tego rodzaju, bez przywiązania do treści tej jednej”.
Na co uważać: Domyślna skłonność modelu do rozwlekłości wraca przy każdej późniejszej poprawce — ograniczenie trzeba powtarzać, nie ustawiać raz.
5.Rozdziel zbiór budujący i testowy
Na czym polega: Przykłady, na których powstaje skill, i przykłady, na których go sprawdzasz, muszą być rozłączne, a te testowe ukryte przed modelem w fazie budowania.
Jak stosować: Zanim zaczniesz budować, odłóż kilka wykonanych ręcznie przypadków na bok i nie pokazuj ich modelowi aż do testu.
Na co uważać: Test na tym samym przykładzie, na którym skill powstał, daje fałszywie idealny wynik — model może pamiętać niuanse z wcześniejszej rozmowy przez pamięć między sesjami.
6.W teście podajesz wyłącznie wejście
Na czym polega: Ślepy test polega na tym, że AI dostaje same dane wejściowe, generuje wynik, a ty porównujesz go ze swoim wcześniejszym, ręcznie wykonanym rezultatem.
Jak stosować: Testuj tylko na sprawach, które już zrobiłeś sam — bez własnego punktu odniesienia porównanie nie ma sensu.
Na co uważać: Nie przemyć modelowi żadnej wskazówki o oczekiwanym wyniku przy podawaniu wejścia; jedno zdanie kontekstu potrafi unieważnić cały test.
7.Kryteria oceny muszą być binarne
Na czym polega: Siedem do dziesięciu pytań z odpowiedzią wyłącznie tak/nie, wygenerowanych przez AI na podstawie trzech dobrych, skutecznych próbek twojej pracy plus samego skilla.
Jak stosować: Formułuj pytania rozstrzygalne przez spojrzenie na dokument: „czy zaczyna się od problemu klienta?”, „czy cena jest na pierwszej stronie?”, „czy mieści się na dwóch stronach?”.
Na co uważać: Binarność nie jest kosmetyką — na tych pytaniach model będzie oceniał sam siebie, a kryterium stopniowalne („czy jest przekonująca?”) zawsze dostanie odpowiedź wygodną.
8.Ocenę zleca się subagentowi
Na czym polega: Po napisaniu tekstu model rodzic powołuje osobnego subagenta z własnym oknem kontekstu, który ocenia wynik świeżym okiem — widząc wyłącznie gotowy dokument i checklistę.
Jak stosować: Wbuduj krok oceniający w sam skill i zażądaj raportu: pytanie, odpowiedź tak/nie, zaliczone/niezaliczone, a przy porażce jednozdaniowe uzasadnienie.
Na co uważać: Samoocena rodzica jest stronnicza — zwykle zalicza wszystko. Subagent musi też dostać naprawdę ograniczony wsad, bo im więcej z kontekstu rodzica zobaczy, tym mniej „świeże” są jego oczy.
9.Poprawiaj skill najmniejszą możliwą zmianą
Na czym polega: Pętla: dajesz modelowi wynik skilla, swój własny wynik i listę niezaliczonych pytań, prosisz o wskazanie miejsca w instrukcjach, które zawiodło, i o minimalną, systemową poprawkę plus raport z tego, co zmienił.
Jak stosować: Wymuszaj w prompcie naprawę problemu, który powtórzy się w przyszłości, a nie łatanie tego jednego przypadku. Zawsze żądaj wykazu zmian.
Na co uważać: Bez ograniczenia „najmniejsza możliwa zmiana” skill puchnie z każdą iteracją, a rozdęty skill jest gorzej wykonywany. Zmiany, z którymi się nie zgadzasz, cofaj od razu.
10.Wracaj do pętli przy nowych modelach i wyższych standardach
Na czym polega: Dwa powody rewizji gotowego skilla: premiera nowego modelu oraz podniesienie własnych standardów jakości.
Jak stosować: Przy nowym modelu przepuść przez niego swój proces i porównaj. Jeśli wypadnie gorzej, przycinaj prompt — duży prompt pisany pod słabszy model działa na mocniejszy jak kaftan. Przy zmianie standardów aktualizuj też kryteria, nie tylko skill.
Na co uważać: Skill zbudowany przez ciebie niesie twój kontekst; pobrany od kogoś innego nie niesie go wcale — pętla opłaca się tylko wtedy, gdy skill w ogóle pasuje do twojej pracy.