Audyt jednego skilla — karta kontrolna · Zasób

Tę kartę otwierasz w drugim oknie, z plikiem jednego skilla przed sobą. Nie służy do czytania o skillach, tylko do przejścia audytu na pliku, którego naprawdę używasz. Siedem bloków idzie w kolejności realnej pracy: najpierw ustalasz poprzeczkę, potem schodzisz przez zapisany kod, opis, poprawki i weryfikację, a na końcu sprawdzasz, czy skill przeżyje zmianę agenta. Przy każdym bloku masz pola do odhaczenia i jedno zdanie do zapamiętania.

Przypomnę jedno pojęcie, bo cała karta się o nie opiera. Skill to spisany zwykłym tekstem przepis na jedno zadanie, po który asystent sięga wtedy, gdy jest potrzebny. Audytujesz więc tekst, nie program. Jeden przebieg kartą obejmuje jeden skill; przy następnym zaczynasz od góry.

1. Wybierz skill i nazwij, co znaczy „dobrze zrobione”

Audyt bez poprzeczki kończy się opinią, że skill działa nieźle. Zanim odhaczysz cokolwiek, zapisz, po czym poznasz dobry wynik akurat tego skilla — na tyle konkretnie, żeby ktoś obcy odrzucił zły wynik bez pytania ciebie.

[ ] Wybierz skill, którego używasz najczęściej, i otwórz jego plik instrukcji obok tej karty.
[ ] Zapisz w jednym zdaniu, jakie zadanie ten skill ma zdejmować ci z głowy.
[ ] Wypisz, co poprawiasz ręcznie po każdym jego uruchomieniu; to jest lista rzeczy do odzyskania.
[ ] Sformułuj od trzech do pięciu kryteriów odbioru: warunków, które wynik spełnia albo nie spełnia, bez miejsca na „w sumie w porządku”.
[ ] Przy każdym warunku dopisz, gdzie to widać: w pliku wynikowym, na zrzucie ekranu, w źródle.
[ ] Wklej te kryteria do pliku skilla; do końca audytu pracujesz na nich, a nie z pamięci.

Bez zapisanej poprzeczki audyt kończy się zdaniem „działa nieźle”. Kryteria odbioru wpisujesz do pliku na początku, nie na końcu.

2. Powtarzana robota: co asystent rozwiązuje od nowa przy każdym przebiegu

Programiści mają na to nazwę: DRY, od angielskiego don't repeat yourself, czyli nie powtarzaj się. Raz rozwiązany problem zapisujesz i używasz ponownie. Ten blok szuka miejsc, w których twój skill każe asystentowi pisać od zera coś, co już raz wyszło dobrze. Płacisz wtedy tokenami za rozwiązanie, które masz.

[ ] Uruchom skill raz i przeczytaj, co asystent robił po drodze, a nie tylko to, co oddał.
[ ] Zaznacz każdy moment, w którym pisał kod, przeliczenie albo formatowanie od zera.
[ ] Wskaż z tego jedną rzecz, której wynik naprawdę ci się spodobał, i każ ją zapisać jako plik w folderze skryptów tego skilla.
[ ] Dopisz w instrukcji zdanie, które wywołuje ten plik z nazwy, zamiast zostawiać asystentowi wybór.
[ ] Zrób test dwóch przebiegów: uruchom to samo zadanie dwa razy i porównaj te elementy, na których ci zależy.
[ ] Sprawdź w zapisie przebiegu, że skill sięgnął po zapisany plik, a nie napisał sobie nowego; sam podobny wynik tego nie dowodzi.
[ ] Wypisz, co w tym skillu ma prawo się różnić między przebiegami, żeby drobna zmiana w tekście nie wyglądała potem na awarię.

Podobny wynik dwóch przebiegów nie dowodzi niczego, dopóki nie zobaczysz w zapisie, że skill wywołał zapisany plik.

3. Opis: co skill robi i po czym poznać, że to ta sytuacja

Przy starcie asystent nie czyta pełnych instrukcji ze wszystkich twoich skilli. Czyta wyłącznie ich nazwy i opisy, a cały plik wczytuje dopiero wtedy, gdy twoje polecenie pasuje do opisu. Mechanizm nazywa się progresywnym ujawnianiem i opiera się na jednym elemencie, który piszesz ty.

[ ] Przeczytaj sam opis, bez reszty pliku, i sprawdź, czy mówi dwie rzeczy: co skill robi i kiedy ma się uruchomić.
[ ] Dopisz brakującą połowę zdaniem zaczynającym się od „Użyj go, gdy…”, z wypisanymi sytuacjami.
[ ] Wykreśl z opisu słowa, których nie użyłbyś, prosząc o tę robotę żywego człowieka.
[ ] Zestaw ten opis z opisami pozostałych skilli i zaznacz każde miejsce, w którym dwa z nich łapią to samo polecenie.
[ ] Test pierwszy: napisz polecenie oczywiste dla tego skilla i sprawdź, czy się uruchomił.
[ ] Test drugi: napisz to samo zupełnie innymi słowami, takimi, jakich użyłby ktoś z twojego zespołu.
[ ] Test trzeci: napisz polecenie z sąsiedniego tematu i sprawdź, czy skill milczy; uruchomienie się tutaj jest błędem tak samo jak milczenie w dwóch poprzednich testach.

Skill, którego asystent nie znajdzie, to skill, którego nie masz. Trzy polecenia — oczywiste, inaczej nazwane i cudze — mówią o opisie więcej niż kolejne jego przepisanie.

4. Poprawki: gdzie zostają lekcje z nieudanych przebiegów

Poprawiasz asystenta w oknie rozmowy, zamykasz okno i lekcja przepada. Poprawiłeś wynik, a zepsuty proces został bez zmian; jutro asystent zrobi dokładnie to samo. Skill trzyma wiedzę proceduralną, czyli sposób wykonania tej jednej roboty — i to jest miejsce, do którego każda poprawka ma trafić.

[ ] Wypisz trzy ostatnie poprawki, które podałeś temu skillowi w rozmowie, i sprawdź, czy któraś trafiła do pliku.
[ ] Zaklasyfikuj każdą z nich: czy zawiódł proces, czy zabrakło twojego głosu i przykładów, czy wrócił ten sam błąd.
[ ] Zawiódł proces → zmień instrukcję w samym skillu, w najmniejszym miejscu, które to naprawia.
[ ] Zabrakło głosu, marki albo wzorca → dołóż plik pomocniczy z przykładami i wskaż go z instrukcji.
[ ] Ten sam błąd wrócił po raz trzeci → dopisz jawną regułę, która go wprost zakazuje.
[ ] Gdy asystent twierdzi, że nie znajduje pliku, nie kończ sprawy podaniem ścieżki: każ mu pokazać, gdzie szukał, i poprawić ścieżkę wyszukiwania w instrukcji.
[ ] Po każdej poprawce uruchom to samo zadanie jeszcze raz i sprawdź, czy zadziałała; sama zmiana w pliku nie jest potwierdzeniem.

Poprawka wpisana w rozmowę naprawia jeden wynik. Poprawka wpisana w plik naprawia wszystkie następne przebiegi.

5. Weryfikacja: dowód spoza pierwszego szkicu

Z całego audytu ten blok wypada najczęściej. Skill tworzy rzecz, zapisuje plik i melduje, że skończył, a ty otwierasz i widzisz rozjechane formatowanie albo źródła, które nie potwierdzają tego, co napisano. Jeśli wiesz, jak sprawdziłbyś tę pracę osobiście, wpisz właśnie te kroki do pliku.

[ ] Nazwij rodzaj wyniku tego skilla: rzecz do oglądania, twierdzenia do potwierdzenia albo tekst oceniany subiektywnie.
[ ] Rzecz do oglądania → dopisz krok, w którym skill renderuje wynik jako obrazek, ogląda go i poprawia to, co ucięte, nieczytelne albo poza kadrem.
[ ] Twierdzenia do potwierdzenia → dopisz krok, w którym skill otwiera źródła, zestawia każde twierdzenie z dowodem i usuwa to, czego nie potwierdził.
[ ] Tekst oceniany subiektywnie → dopisz przegląd w kilku rolach: początkujący mówi, gdzie przestał rozumieć, sceptyczny kupujący mówi, w co nie wierzy, ktoś z twojej grupy odbiorców mówi, gdzie by się wyłączył.
[ ] Dopisz regułę wyboru uwag: skill wprowadza zastrzeżenia powtarzające się u kilku recenzentów, a nie wszystkie, bo przyjęcie wszystkich pogorszy wynik.
[ ] Wklej do pliku akapit odbioru: „Zanim zwrócisz wynik, zapisz kryteria odbioru. Zrób pierwszą wersję, obejrzyj ją metodą weryfikacji właściwą dla tego rodzaju pracy, popraw każdy znaleziony problem i zrób kolejne przejście. Zwróć wynik dopiero wtedy, gdy spełnia kryteria, i dołóż krótkie podsumowanie tego, co sprawdziłeś. Jeśli czegoś nie dało się zweryfikować, napisz wprost, co zostało otwarte”.
[ ] Wykreśl każde miejsce, w którym za weryfikację robi asystent czytający własny tekst i stwierdzający, że wygląda dobrze.

Weryfikacja potrzebuje dowodu spoza pierwszego szkicu: zrzutu ekranu, wyniku testu, źródła albo opinii z innej perspektywy niż ta, w której tekst powstał.

6. Przenośność: uruchom skill pod innym agentem

Krąży wokół skilli określenie „odporny na zmianę modelu” i chcę być co do niego precyzyjna. Żaden skill nie zmusi słabszego modelu, żeby pracował jak mocniejszy. Przenośny jest proces: skille są otwartym formatem, więc ten sam folder uruchomisz w innym zgodnym środowisku agenta, czyli w programie, który pozwala modelowi czytać pliki, uruchamiać narzędzia i prowadzić zadanie do końca.

[ ] Skopiuj folder skilla do drugiego zgodnego środowiska agenta i uruchom w nim to samo zadanie.
[ ] Oceń wynik kryteriami odbioru z bloku 1, bez taryfy ulgowej dla nowego środowiska.
[ ] Zaznacz każde miejsce, w którym instrukcja zakłada nazwę narzędzia, układ folderów albo skrót, którego drugi agent nie zna.
[ ] Wypisz sformułowania, które rozumie tylko jeden model, i zamień je na opis czynności.
[ ] Dołóż przykład tam, gdzie drugi agent zgadywał format wyniku.
[ ] Powtórz przebieg po poprawkach i zapisz, co nadal nie przechodzi; to jest lista założeń, których z tego skilla nie wyniesiesz.

Przenosi się proces, nie jakość. Gdy wynik rozpada się pod innym agentem, w instrukcji brakuje czegoś, co dotąd dopowiadał jeden model.

7. Stop: kiedy skill wycofać albo rozbić zamiast łatać

Nie każdy wynik audytu jest poprawką. Czasem karta mówi, że plik ma pęknąć na dwa albo zniknąć, a kolejna runda dopisków tylko przedłuży jego życie o miesiąc.

[ ] Policz poprawki z bloku 4, po których ten sam błąd wrócił; przy trzeciej nieudanej rundzie przestań łatać.
[ ] Sprawdź, czy skill nie obsługuje dwóch różnych zadań pod jednym opisem; jeśli tak, rozbij go na dwa pliki i wróć z każdym do bloku 3.
[ ] Sprawdź, czy dwa skille nadal walczą o to samo polecenie po poprawce opisów; jeśli tak, zostaw jeden, a drugi usuń.
[ ] Wyłącz skill, którego nie uruchomiłeś ani razu od poprzedniego audytu.
[ ] Zanim usuniesz plik, przenieś do innego skilla zapisane w nim skrypty, przykłady i reguły; to jest ta część, która ma wartość poza nim.
[ ] Zapisz jednym zdaniem, dlaczego ten skill odpadł; za pół roku odróżnisz zły pomysł od dobrego pomysłu w złym momencie.

Skill, który po trzech rundach poprawek wraca z tym samym błędem, nie potrzebuje kolejnej poprawki, tylko decyzji.

Po audycie

Pusta kratka w tej karcie rzadko zatrzymuje pracę dzisiaj. Wraca za dwa tygodnie: jako skill, który znowu napisał ten sam skrypt od zera, jako polecenie, które trafiło do sąsiedniego skilla, albo jako wynik wyglądający na skończony do momentu, w którym go otworzysz. Wróć wtedy do bloku, z którego pochodzi ta kratka.

Zasada, którą stąd zabieram, brzmi tak: ogólny agent staje się twoim agentem dopiero wtedy, gdy spiszesz mu własną robotę, a potem poprawiasz ten zapis po każdym nieudanym przebiegu. Jeśli z całej karty odhaczysz dziś tylko blok 1 i blok 5, twoje pierwsze spojrzenie na wynik przestanie być pierwszym spojrzeniem agenta.