Tę kartę trzymaj otwartą przy pracy, nie czytaj jej raz. Sześć bloków ustawiłam w kolejności, w jakiej wraca realna robota: najpierw to, czym się legitymujesz, potem sposób prowadzenia modelu, na końcu koszt. Przy każdym punkcie masz pola do odhaczenia i jedno zdanie do zapamiętania.
1. Wiarygodność i trwałe umiejętności
Udokumentuj efekt każdego wdrożenia
- [ ] Zmierz czas potrzebny na zadanie przed wdrożeniem i po nim, tą samą miarą.
- [ ] Policz, ile zapytań przepadało wcześniej, a ile zostaje obsłużonych teraz.
- [ ] Zapisz wynik nawet wtedy, gdy projekt jest mały albo zrobiony tylko dla siebie.
- [ ] Nagraj krótkie przejście, w którym widać, jak przepływ łączy się z tym wynikiem.
Portfolio mówi, co powstało. Dowód pokazuje, co się przez to zmieniło w firmie.
Sprawdź, co zostanie po zmianie narzędzia
- [ ] Wypisz, co ze swojego rozwiązania przeniesiesz do innego narzędzia: instrukcje, foldery, pliki tekstowe, opis procesu.
- [ ] Trzymaj rdzeń w zwykłych plikach i instrukcjach, nie w klikanej konfiguracji jednej platformy.
- [ ] Po każdej awarii dopisz jedno zdanie: co się zepsuło i jak to rozpoznać następnym razem.
- [ ] Zamiast uczyć się kolejnego panelu, przećwicz to, co przenosi się dalej: nazwanie celu i ograniczeń, podział dużego problemu na części, czytanie komunikatu o błędzie, szukanie innej drogi, gdy pierwsza nie działa.
Pułapka: uczysz się interfejsu, nie rzemiosła. Interfejs się zmieni, rzemiosło przeniesiesz ze sobą.
2. Odruch AI-native
Zaczynaj od pytania „na ile”
- [ ] Przy nowym zadaniu najpierw sprawdź, jaką jego część da się zdjąć z rąk, zanim zrobisz całość ręcznie.
- [ ] Rozbij zadanie na etapy i zaznacz te, które model wykona bez ciebie.
- [ ] Nie odrzucaj zadania dlatego, że model zrobi tylko jego część: fragment zdjęty z rąk już wyprzedza proces robiony całkowicie ręcznie.
- [ ] Wróć po kilku miesiącach do zadań odrzuconych jako niewykonalne, bo modele i narzędzia się zmieniają.
Reguła decyzyjna: nie pytaj, czy AI to zrobi. Pytaj, w jakiej części to zrobi.
Wpisz swoją wiedzę w ograniczenia i kontekst
- [ ] Wypisz miejsca, w których twój proces zwykle się psuje; bierz je z własnej praktyki, nie z ogólnej wiedzy o branży.
- [ ] Zamień każde z nich na negatywny prompt: „nie dodawaj funkcji, o które nie proszę”, „nie pisz obsługi błędów dla sytuacji, które nie mogą wystąpić”.
- [ ] Opisz, jak wygląda dobry efekt w twojej dziedzinie, zanim poprosisz o pierwszą wersję.
- [ ] Zbuduj kontekst wokół modelu: własne materiały, standardy, przykłady, gotowe instrukcje.
Model masz ten sam, co konkurencja. Różnicę robi to, co dokładasz wokół niego.
3. Zarządzanie AI jak zespołem
Każ pytać i podważać, zanim cokolwiek powstanie
- [ ] Podaj problem i cel zamiast gotowego rozwiązania, a potem poproś o propozycję podejścia.
- [ ] Wstrzymaj budowę, dopóki nie usłyszysz pytań o to, czego dokładnie oczekujesz.
- [ ] Poproś o krytykę z konkretnych perspektyw: nieufnego kupującego, konkurenta szukającego słabych punktów, inżyniera, który będzie to utrzymywał za rok.
- [ ] Zapisz, co znaczy „skończone”, zanim ruszy praca.
Ogólne „co o tym myślisz” tylko potwierdzi to, w co już wierzysz. Krytyka musi przyjść z konkretnej roli.
Zleć weryfikację razem z zadaniem
- [ ] Odpowiedz sobie najpierw, jak sprawdzasz gotową pracę, gdy oddaje ci ją człowiek.
- [ ] Zamień tę odpowiedź na kroki, które system wykona sam: zrzuty ekranu, testy, przejście formularza, analiza wyniku.
- [ ] Przy stronie sprawdź układ na telefonie, każdy ważny przycisk, przejście rejestracji i formularz trafiający tam, gdzie ma trafić.
- [ ] Wymagaj dowodu wykonania, nie meldunku „gotowe”.
Pułapka: pierwsza wersja wygląda na skończoną. Bez pętli weryfikacji resztę dociągniesz w kolejnych rundach uwag.
4. Ryzyko i uprawnienia
Odbierz narzędzia, których agent nie powinien mieć
- [ ] Wypisz wszystko, czego agent może dziś dotknąć: narzędzia, bazy, pliki, klucze.
- [ ] Rozdziel uprawnienie do przygotowania wersji roboczej od uprawnienia do wysłania.
- [ ] Zawęź klucze API do operacji, które są naprawdę potrzebne; klucz działa jak hasło do usługi.
- [ ] Zapytaj osobę, która to zbudowała, co system potrafi zrobić sam, bez pytania kogokolwiek.
Agent z działającym narzędziem do wysyłki w końcu wyśle, także wtedy, gdy nikt o to wprost nie poprosił. Prompt „tylko przygotuj wersję roboczą” jest wtedy sugestią, nie ograniczeniem. Ten sam przebieg powtórzony dwa razy może zachować się inaczej, więc projektuj dostęp pod najgorsze możliwe działanie, nie pod najbardziej prawdopodobne.
Zasada bezpieczeństwa: gdy odpowiedź jest niewygodna, zmień dostęp, a nie kolejne zdanie w prompcie.
Zmierz skuteczność na zestawie przypadków
- [ ] Zbierz zestaw realnych, dobrych odpowiedzi; na start wystarczy kilkadziesiąt.
- [ ] Zapisz kryteria sukcesu i sposób oceniania tak, jak zrobiłby to człowiek, który sprawdza tę pracę.
- [ ] Oceniaj kodem to, co obiektywne, a modelem w roli sędziego to, co wymaga rozumowania.
- [ ] Zmieniaj jedną rzecz naraz (prompt, ustawienie narzędzia, model) i porównuj wynik z poprzednim pomiarem, bo zmiana, która wydaje się lepsza, potrafi obniżyć skuteczność.
Udany przebieg dowodzi tylko tego, że zadziałało raz, na jednym wejściu.
5. Realne ograniczenie biznesu
Znajdź zator i przeciek przed budową
- [ ] Przejdź proces od pierwszego kontaktu do pieniędzy i zaznacz miejsce, w którym praca się zatrzymuje.
- [ ] Zaznacz drugie miejsce: to, w którym czas albo pieniądze wyciekają po drodze.
- [ ] Nie przyjmuj „potrzebujemy chatbota” jako diagnozy, tylko sprawdź, czy to naprawdę wąskie gardło.
- [ ] Nazwij ograniczenie jednym zdaniem i pokaż je zamawiającemu przed propozycją rozwiązania.
Pułapka: przyjmujesz zamówienie, zamiast postawić diagnozę. Zamawiający opisuje objaw, rzadko ograniczenie.
Ustaw jedną metrykę przed pierwszą godziną pracy
- [ ] Zapisz punkt wyjścia: ile ta liczba wynosi dzisiaj, zmierzona, nie oszacowana.
- [ ] Ustal cel i termin jego osiągnięcia.
- [ ] Potwierdź z zamawiającym, że taka zmiana ma dla niego realną wartość.
- [ ] Wracaj do tej jednej liczby przy każdej decyzji o zakresie.
Przykład hipotetyczny: dziś pięć zapytań tygodniowo, cel piętnaście zapytań tygodniowo w ciągu dwóch miesięcy.
Wzór: punkt wyjścia plus cel plus termin daje mierzalną metę.
6. Opłacalność
Dobierz model osobno do każdego etapu
- [ ] Rozpisz etapy przepływu i zaznacz przy każdym, czego wymaga: przeczytania dużej ilości tekstu czy podjęcia decyzji.
- [ ] Do przeglądania i streszczeń wstaw model szybki i tani, a drogi zostaw na końcową decyzję.
- [ ] Policz koszt jednego pełnego uruchomienia, nie jednego zapytania.
- [ ] Sprawdź, czy tańszy model przechodzi twoją ewaluację dla tego konkretnego etapu.
Reguła doboru: najtańszy model, który powtarzalnie przechodzi ewaluację dla danego zadania.
Pokaż dowód, zanim poprosisz o rolę
- [ ] Wybierz jedno powtarzalne zadanie, które wraca co tydzień i irytuje.
- [ ] Zautomatyzuj je i zmierz efekt tą samą miarą, którą potem podasz innym.
- [ ] Pokaż wynik zespołowi i przełożonemu, zanim w firmie pojawi się nazwa stanowiska.
- [ ] Zanim poszukasz pierwszego klienta, zbuduj coś dla siebie i wejdź w rozmowę z dowodem, nie z obietnicą.
Stara kolejność to dyplom, tytuł, praca. Tutaj jest odwrotna: praca, dowód, potem tytuł.
Zanim uznasz projekt za skończony
- [ ] Metryka nazwana przed startem ma zmierzoną wartość po wdrożeniu i obie liczby są zapisane.
- [ ] Agent ma dostęp tylko do narzędzi, których naprawdę potrzebuje, a przygotowanie jest oddzielone od wysyłki.
- [ ] Skuteczność jest sprawdzona na zestawie przypadków, nie na jednym udanym przebiegu.
- [ ] System sam pokazuje dowód wykonania, zamiast meldować „gotowe”.
- [ ] Koszt jednego uruchomienia jest znany, a każdy etap chodzi na najtańszym modelu, który przechodzi ewaluację.
- [ ] Rdzeń rozwiązania da się przenieść do innego narzędzia: instrukcje i pliki, nie klikana konfiguracja.
Każde puste pole to jedno miejsce, w którym system zawiedzie po wdrożeniu, a nie teraz. Wróć do bloku, z którego pochodzi, uzupełnij brakującą odpowiedź i dopiero wtedy uznaj projekt za zamknięty.