Jeśli wszyscy korzystają z tego samego modelu, to wszyscy mają też te same prompty i dostają podobne wyniki — bo model jest dla każdego dokładnie taki sam. Przewagą nie jest więc model. Przewagą jest kontekst, który mu podajesz: twój gust, twój sposób mówienia, twoje decyzje. Problem w tym, że ten kontekst siedzi w twojej głowie i tam zostaje. Pokażę ci metodę, która go stamtąd wyciąga — przez przesłuchanie, punkt po punkcie, do trwałego dokumentu, z którego model może korzystać później.
Dlaczego kontekst jest prawdziwą dźwignią
Najpierw słownik, bo cały tekst krąży wokół trzech pojęć.
Kontekst to wszystko, co podajesz modelowi razem z poleceniem: tło sprawy, twoje zasady, wcześniejsze decyzje, przykłady tego, jak coś ma wyglądać. To różnica między „napisz ofertę” a „napisz ofertę tak, jak robię to ja — w tym tonie, z tymi granicami, dla tego typu klienta”. Sam model jest powszechnie dostępny. Kontekst masz tylko ty.
Skill to mała, nazwana umiejętność, którą model uruchamia na żądanie. Brzmi technicznie, ale w najprostszej postaci skill to po prostu prompt, którego nie chcesz wpisywać za każdym razem od nowa. Nie musi być skomplikowaną automatyzacją. Może być pięcioma zdaniami, które raz dobrze sformułujesz i potem wywołujesz jednym poleceniem.
Okno kontekstu to ilość tekstu, jaką model „widzi” naraz podczas jednej rozmowy: instrukcje, pliki, całą dotychczasową wymianę zdań. Ma swój kres. Gdy się zapełnia, model zaczyna gubić to, co padło na początku — i to jest sednem jednego z problemów, który rozwiążemy niżej.
Z tego wynika prosta obserwacja. Skoro model to towar powszechny, to jakość twoich wyników zależy od jakości kontekstu, który mu dostarczasz. A najtrudniejsza, najbardziej żmudna część całej pracy to nie pisanie promptów. To wydobycie — przeniesienie tego, co wiesz, z głowy do systemu, żeby twoje skille i cała reszta mogły z tego korzystać.
Metoda przesłuchania: jedno pytanie naraz
Typowy odruch wygląda tak: siadasz, przez pięć minut wyrzucasz z siebie wszystko, co przychodzi do głowy, i liczysz, że to wystarczy. Nigdy nie wystarcza. Zrzut z pamięci pomija dziesiątki drobnych decyzji, których nawet nie zauważasz, bo dla ciebie są oczywiste — a to one stanowią twój kontekst.
Lepsza metoda odwraca kierunek: zamiast ty mówisz wszystko, model cię przesłuchuje. Nazywam to przesłuchaniem, bo dokładnie tak działa. Polecenie jest krótkie — kilka zdań — i każe modelowi:
- przepytywać cię wytrwale o każdy element planu czy procesu, aż dojdziecie do wspólnego rozumienia tematu;
- iść po kolei wzdłuż każdej gałęzi drzewa decyzji i rozwiązywać zależności między decyzjami jedna po drugiej, zamiast skakać chaotycznie;
- zadawać jedno pytanie naraz — nie zasypywać cię listą dziesięciu, na które odpowiadasz pobieżnie;
- do każdego pytania proponować swoją rekomendowaną odpowiedź, żebyś mógł ją przyjąć, poprawić albo odrzucić, zamiast za każdym razem zaczynać od czystej kartki;
- a jeśli na jakieś pytanie odpowiedź znajduje się w samych plikach projektu — sam ją tam sprawdzić, zamiast pytać o coś, co i tak może odczytać.
Ten ostatni punkt jest ważny. Dobre przesłuchanie nie marnuje twojego czasu na rzeczy, które system potrafi ustalić bez ciebie. Pyta tylko o to, co naprawdę masz wyłącznie w głowie.
Praktycznie wygląda to tak: zaczynasz od jednego zdania w stylu „przepytaj mnie o sposób, w jaki robię ten proces”. Dostajesz pierwsze pytanie i rekomendację. Odpowiadasz albo akceptujesz propozycję. Pada kolejne pytanie. I tak dalej — czasem pięć pytań, czasem trzydzieści, czasem rozmowa ciągnie się ponad godzinę. Długo to dobry znak. Kończysz dopiero, gdy w wiedzy nie ma już dziur.
To samo podejście sprawdza się szerzej niż przy pojedynczym skillu. Można w ten sam sposób przejść cały proces albo całą logikę działania firmy — krok po kroku, decyzja po decyzji — żeby system rzeczywiście rozumiał, jak coś działa, a nie tylko miał o tym ogólne pojęcie.
Punkty kontrolne: dlaczego model zapisuje na bieżąco
Tu dochodzimy do usprawnienia, które według mnie decyduje o tym, czy metoda jest tylko ciekawa, czy faktycznie niezawodna. Sama metoda przesłuchania ma jedną słabość: jeśli rozmowa trwa godzinę albo dłużej, okno kontekstu się zapełnia — a wtedy model zaczyna przekręcać twoje wcześniejsze odpowiedzi. To, co powiedziałeś na początku, rozmywa się pod naporem tego, co padło później.
Rozwiązaniem są punkty kontrolne. Po każdej odpowiedzi model nie tylko idzie dalej — najpierw zapisuje ją do dokumentu. Powstaje osobny plik tekstowy (najwygodniej w prostym formacie markdown, w jednym folderze, który możesz nazwać na przykład „brainstorms”), który rośnie wraz z rozmową. Dzięki temu wiedza nie żyje już tylko w ulotnym oknie kontekstu — ma trwały zapis na dysku. Nawet gdy okno się przepełni, decyzje z początku rozmowy są bezpieczne, bo zostały spisane, zanim model zdążył je zapomnieć.
Taki dokument warto, by porządkował kilka rzeczy:
- kluczowe decyzje — sedno tego, co ustaliliście, gotowe do szybkiego odczytania;
- dziennik pytań i odpowiedzi krok po kroku — pełny ślad rozmowy, do którego można wrócić;
- najważniejsze wnioski — to, co naprawdę trzeba zapamiętać o procesie;
- otwarte flagi — i to jest moim zdaniem najcenniejsza część.
Otwarte flagi to rzeczy, których ty sam dobrze nie wiesz. Czasem trafiasz na fragment procesu, którego nie potrafisz wyjaśnić tak dokładnie jak osoba, która naprawdę go prowadzi. Zamiast zmyślać albo udawać pewność, system to oznacza: „o to dopytaj właściwą osobę, przynieś odpowiedź i wtedy uzupełnimy dokument”. To uczciwe wobec rzeczywistości — przyznaje, że nie cała wiedza jest w twojej głowie, i mówi wprost, gdzie po nią pójść.
Gotowy dokument nie jest jednorazowy. Skoro to zwykły plik, możesz do niego wrócić w dowolnej chwili. Gdy proces się zmieni albo znajdziesz lepszy sposób działania, uruchamiasz przesłuchanie ponownie — „przepytaj mnie jeszcze raz, oto co się zmieniło” — i odświeżasz zapis. A skoro masz spisaną całą nuancję rozmowy, możesz tym samym ruchem poprosić o zaktualizowanie powiązanych skilli i instrukcji, w których tej wiedzy wcześniej brakowało.
Naostrz siekierę, zanim zetniesz drzewo
Po co ten cały wysiłek z góry? Bo decyduje o tym, jak blisko celu zaczynasz.
Nic nie jest dobre za pierwszym podejściem. Stary sposób budowania skilla wygląda tak: robisz pospieszny zrzut z pamięci, składasz pierwszą, mierną wersję i potem mozolnie ją poprawiasz — iteracja po iteracji, każda odrobinę lepsza, aż po wielu, wielu podejściach docierasz do czegoś solidnego. To może być kilkanaście rund. Może być znacznie więcej. I uczciwie mówiąc, do pełnej doskonałości nie dochodzisz nigdy, bo w miarę jak zmienia się firma i zmieniasz się ty, skill też musi się zmieniać.
Przesłuchanie przesuwa ten cały wysiłek na początek. Inwestujesz go z góry — w jedną dokładną rozmowę zamiast w setki drobnych poprawek później. Efekt jest taki, że już przy pierwszym podejściu zaczynasz dużo bliżej wiarygodnego wyniku, zamiast wspinać się tam przez kilkanaście iteracji. Nie jest idealnie i wciąż będziesz coś dopracowywać — ale jesteś na miejscu o wiele szybciej, co daje ci więcej przestrzeni, żeby szukać naprawdę lepszych ulepszeń, a nie łatać podstawy.
To w gruncie rzeczy stara zasada: gdybym miał sześć godzin na ścięcie drzewa, pierwsze cztery spędziłbym na ostrzeniu siekiery. Zebranie kontekstu z góry potrafi wydać się nudne i powtarzalne, bo nie widać po nim natychmiastowego efektu. Ale to właśnie ten etap zwraca się później wielokrotnie — w każdym kolejnym uruchomieniu skilla, który od początku wie, jak myślisz.
Moje przekonanie jest proste: skoro model masz ten sam co wszyscy, jedyne, co naprawdę możesz wyostrzyć, to kontekst. A najtańszy sposób, by go wyostrzyć, to pozwolić systemowi przesłuchać cię raz, porządnie, i spisać odpowiedzi, zanim zdąży je zapomnieć. Wybierz jeden proces, który masz wyłącznie w głowie, i poproś: „przepytaj mnie o to” — to dobry pierwszy zapis do twojego folderu z wiedzą.