Większość ludzi pisze ten sam typ polecenia do asystenta AI po raz dziesiąty w tygodniu i za każdym razem dostaje trochę inny wynik. Da się to zamknąć raz: spisujesz swoją procedurę jako skill, asystent sięga po nią, gdy jest potrzebna, i odtąd robi rzecz tak samo dobrze za każdym razem. Pokażę ci, czym jest skill w prostych słowach, jakie są jego dwa rodzaje, jak napisać go tak, by faktycznie się uruchamiał, i — to najważniejsze — jak testami sprawiać, że z czasem działa coraz lepiej.
Skill, czyli przepis dla asystenta
Zacznę od pojęcia, bo wraca w całym tekście. Skill (po polsku umiejętność) to po prostu przepis: zestaw instrukcji zapisanych zwykłym tekstem, który mówi asystentowi, jak wykonać jedno konkretne zadanie. Nic technicznego — to plik, który przeczytałby stażysta i zrozumiałby, o co chodzi. Kiedy poprosisz asystenta na przykład o post na LinkedIn, on wczytuje odpowiedni przepis i trafia za każdym razem.
Kluczowa cecha skilla jest taka: asystent nie wczytuje go zawsze, tylko wtedy, gdy jest potrzebny. Trzymasz w projekcie kilkanaście różnych skilli, a asystent sięga po właściwy dopiero w chwili, gdy twoje polecenie do niego pasuje. Dzięki temu nie obciąża się w kółko wszystkimi instrukcjami naraz, a ty nie musisz pamiętać, który plik podać — wystarczy, że poprosisz o efekt zwykłym językiem.
Skille pisze się dziś dużo łatwiej, bo dostawca tego narzędzia udostępnił osobny, oficjalny skill, którego jedynym zadaniem jest tworzenie, testowanie, mierzenie i poprawianie innych skilli. To w praktyce spakowana wiedza o tym, jak budować je dobrze: zamiast ślęczeć nad wielostronicowym poradnikiem, dajesz tę wiedzę asystentowi i to on prowadzi cię przez proces. W dalszej części będę go nazywać po prostu kreatorem skilli.
Dwa rodzaje skilli — i dlaczego to rozróżnienie ma znaczenie
Zanim zaczniesz pisać, musisz wiedzieć, że skille dzielą się na dwa rodzaje. Brzmią podobnie, ale robią coś zupełnie innego — i mają inny okres przydatności.
Pierwszy to skill podnoszący umiejętność (po angielsku capability uplift). Uczy asystenta robić lepiej coś, w czym sam z siebie radzi sobie przeciętnie — na przykład projektować estetyczne strony, składać dokumenty albo budować formuły w arkuszu. To w gruncie rzeczy dobrze napisana podpowiedź. Klasyczny przykład: poproś asystenta o stronę bez takiego skilla, a dostaniesz coś poprawnego, ale generycznego — „wyprodukowanego przez AI”. Dodaj skill, który podpowiada dobre kroje pisma, dobre zestawy kolorów i sensowne układy, i ten sam projekt nagle wygląda znacznie lepiej.
Drugi to skill kodujący twoje preferencje (po angielsku encoded preference). Tu asystent zna już każdy pojedynczy element — problem w tym, że ma je wykonać w twojej kolejności i po twojemu. To bardziej przepis krok po kroku, prawdziwy przepływ pracy. Przykład: skill, który najpierw przegląda komentarze pod twoimi treściami, potem sprawdza trendy w sieci, następnie zleca dwóm pomocniczym agentom analizę tych danych równolegle, a na końcu zbiera wszystko i podsuwa ci gotowe wnioski. Bez skilla mógłbyś to opisać za każdym razem od nowa i dostawać inny wynik. Ze skillem mówisz jedno słowo i dostajesz to, co lubisz.
Dlaczego to rozróżnienie jest ważne? Bo decyduje o trwałości. Skille podnoszące umiejętność z czasem mogą się zdezaktualizować — jeśli kolejna, mocniejsza wersja modelu sama z siebie projektuje strony lepiej niż starszy model ze skillem, to taki skill po prostu wycofujesz. Natomiast skille kodujące twoje preferencje są zwykle trwałe, bo opisują proces specyficzny dla ciebie — a tego żaden model nie zgadnie z góry. To pierwsza rzecz, którą warto wiedzieć, zanim cokolwiek napiszesz: budujesz coś jednorazowego czy coś, co ma zostać.
Jak napisać skill, który się uruchomi
Teraz część praktyczna. Najwygodniej zacząć w trybie planowania: opisujesz zwykłym językiem, czego chcesz, a asystent dopytuje o szczegóły i układa plan, zanim cokolwiek zbuduje. Powiedz mu na przykład: „chcę skill, który na koniec każdego tygodnia zbiera dane z mojego kanału, analizuje je i przygotowuje mi raport w PDF z mocnymi i słabymi stronami oraz szansami i zagrożeniami”. On dopyta o okno czasowe, o sekcje raportu, o styl — a potem rozpisze, co dokładnie zrobi.
Tu uwaga, która tłumaczy, dlaczego dziś to wciąż twoje zadanie, a nie asystenta. Większość osób używających skilli to menedżerowie i operatorzy, nie inżynierowie. Świetnie potrafią powiedzieć, czego chcą i jaki wynik ma paść — gorzej z technicznymi detalami. To w porządku, bo skill piszesz w zwykłym języku. Ale im jaśniej opiszesz, czego oczekujesz, tym lepszy skill dostaniesz. Zostawisz coś domyślności — asystent to coś zgadnie po swojemu.
Każdy gotowy skill to jeden plik tekstowy o przejrzystej budowie. Na górze, w krótkim nagłówku, są dwie kluczowe rzeczy: nazwa i opis — czyli jak skill się nazywa i, co ważniejsze, kiedy go uruchomić. Pod nagłówkiem opisujesz resztę: co skill robi i kroki po kolei, czasem z odwołaniem do gotowego skryptu albo danych.
Sercem całej rzeczy jest ten opis w nagłówku. Asystent, gdy dostaje polecenie, nie czyta wszystkich skilli w całości — przegląda tylko ich krótkie nagłówki i po opisie dobiera ten pasujący. Dlatego najczęstsza przyczyna porażki skilla nie leży w samej procedurze, tylko w mglistym opisie warunku uruchomienia. Jeśli opis jest niejasny, asystent albo sięgnie po niewłaściwy skill, albo nie sięgnie po żaden. Pisz więc opis tak, by jednoznacznie mówił, w jakiej sytuacji ten skill ma wejść do gry.
Pętla ewaluacji: jak sprawić, by skill robił się lepszy
Tu zaczyna się rzecz, która odróżnia skill napisany raz od skilla, który z czasem dojrzewa. Ewaluacja (po angielsku eval) to po prostu test: dajesz asystentowi zestaw realnych przykładów dobrego wyniku i sprawdzasz, czy skill faktycznie się uruchamia w odpowiednim momencie i czy dowozi to, czego chcesz. Z nowym kreatorem skilli asystent potrafi tę ocenę przeprowadzić sam i na jej podstawie poprawić skill.
Działa to tak. Powiedzmy, że masz skill do pisania opisów stanowisk. Dajesz asystentowi sporo przykładów świetnych opisów — takich, jakie chcesz dostawać. On bierze twój skill, testuje na nim kilka poleceń, porównuje wyniki z twoimi wzorcami i na tej podstawie dostraja instrukcje. To skraca proces, który dawniej szedł powoli: im częściej używasz skilla i im więcej dajesz informacji zwrotnej, co ci się podoba, a co nie, tym lepiej działa. Ewaluacja robi część tej pracy za ciebie, od razu.
Są dwa powody, by sięgać po ewaluacje — brzmią podobnie, a są swoim przeciwieństwem:
- Wyłapywanie regresji. Gdy model się zmienia, może zacząć korzystać z twojego skilla gorzej niż wcześniej, bo „myśli” trochę inaczej. Regularny test jest wtedy wczesnym sygnałem, że trzeba skill dostroić do nowej wersji.
- Wychwytywanie wzrostu. Ta sama zmiana modelu może sprawić, że asystent wykonuje zadanie lepiej bez żadnego skilla. Ewaluacja to pokaże — i wtedy spokojnie taki skill usuwasz albo archiwizujesz, bo przestał być potrzebny.
Do tego dochodzą benchmarki, czyli pomiar porównawczy. Gdy zmieniasz skill albo aktualizuje się model, uruchamiasz wszystkie ewaluacje i dostajesz twarde liczby: jaki jest odsetek udanych przebiegów, ile to trwa i ile zużywa tokenów (token to fragment tekstu, którym model operuje — im więcej ich zużyjesz, tym drożej). Możesz wprost poprosić: „porównaj zadanie z włączonym skillem i bez niego, pokaż wyniki obok siebie”. Zobaczysz wtedy czarno na białym, czy skill realnie podnosi jakość, czy tylko ci się tak wydaje.
Strojenie wyzwalacza: gdy skill uruchamia się nie wtedy, kiedy trzeba
Jest jeszcze jeden rodzaj testu, który docenisz dopiero przy większej liczbie skilli. Kiedy w projekcie uzbiera się ich kilkanaście, zaczynają się fałszywe uruchomienia: chciałeś jeden skill, asystent odpalił inny — albo nie odpalił żadnego. Można to obejść, wywołując skill ręcznie poleceniem, ale wygodniej mówić zwykłym językiem i mieć pewność, że asystent dobrze cię zrozumie.
Tu pomaga strojenie wyzwalacza (po angielsku trigger tuning). Kreator skilli analizuje twój skill, sam testuje różne sformułowania, jakimi mógłbyś go wywołać, a następnie przepisuje opis w nagłówku tak, by skill uruchamiał się trafniej. To wraca do tego, co napisałam wyżej: cała trafność rozpoznania siedzi w opisie. Po takim strojeniu rozpoznanie nie staje się idealne, ale wyraźnie się poprawia — a to różnica między narzędziem, któremu trzeba wszystko dyktować, a takim, które po prostu rozumie, o co prosisz.
Skill, który piszesz raz i testujesz dalej, staje się aktywem
Dokąd to wszystko zmierza? Dziś, budując skill, podajesz asystentowi kroki, reguły i format. Pojawia się jednak sygnał, że z czasem sam opis tego, co skill ma robić, może wystarczyć — a resztę model dopowie sobie z wysokopoziomowego, naturalnego polecenia. Moim zdaniem to „może” prędzej czy później zmieni się w „na pewno”: coraz więcej szczegółów zejdzie z twoich barków, a ty będziesz po prostu mówić, czego chcesz.
Ale nie czekaj na tę przyszłość, żeby zacząć. Mechanizm, który warto zapamiętać, jest prosty i działa już teraz: opisz swoją powtarzalną pracę raz, a potem nie zostawiaj skilla w spokoju — testuj go na realnych przykładach, sprawdzaj, czy uruchamia się we właściwym momencie i czy dowozi, a po każdej zmianie modelu przepuść go przez ewaluację. Skill napisany raz to wygoda. Skill, który stale testujesz i poprawiasz, to aktywo, które pracuje na ciebie tym mocniej, im dłużej je masz.
Najprostszy pierwszy krok jest pod ręką: wybierz jedną rzecz, którą robisz w kółko i za każdym razem trochę inaczej, opisz ją zwykłym językiem jako skill — i od razu zadbaj o jedno jasne zdanie, które mówi, kiedy ma się uruchomić.