Prompt to nie rozmowa, tylko wpisanie adresu w nawigacji

Wyobraź sobie, że wsiadasz do samochodu, włączasz nawigację i wpisujesz: „chcę pojechać na urlop”.

Nawigacja nie zapyta, czy wolisz morze, czy góry. Nie sprawdzi Twojego urlopu w kalendarzu ani budżetu. Wyznaczy jakąś trasę, bo do tego służy, i pojedziesz nią przez trzy godziny, zanim zorientujesz się, że jedziesz w złą stronę.

Dokładnie to dzieje się przy pierwszym kontakcie z modelem językowym. Człowiek pisze „napisz mi coś o naszej strategii AI”, dostaje trzy akapity ogólników i wyciąga wniosek, że narzędzie jest do niczego. Wniosek jest zrozumiały i błędny. Problemem nie było narzędzie, tylko wpisany adres.

Dlaczego model nie może się domyślić

Kuszące jest myślenie o czacie jako o rozmowie, bo interfejs wygląda jak komunikator. To jednak myląca metafora i warto ją porzucić od razu.

Model nie ma intencji ani wiedzy o Twojej sytuacji. Przewiduje najbardziej prawdopodobny ciąg dalszy tekstu, który dostał. Kiedy polecenie jest ogólne, najbardziej prawdopodobnym ciągiem dalszym jest tekst uśredniony: taki, jaki pasowałby do tysięcy podobnych zapytań. Stąd te trzy akapity, które brzmią sensownie i nie nadają się do niczego.

Człowiek w tej samej sytuacji zachowałby się inaczej. Dopytałby: „strategię dla kogo, na kiedy, co już macie?”. Model tego nie zrobi, bo nie ma z czego wyciągnąć wniosku, że informacji brakuje. Ta różnica jest całą trudnością pracy z AI i nie znika wraz z lepszymi modelami.

W ankiecie Stack Overflow 2025 największą bolączką deweloperów były odpowiedzi „prawie dobre, ale nie do końca”. Wskazało je 66% badanych. Sporą część tych „prawie” tworzy właśnie luka między tym, co miałeś na myśli, a tym, co napisałeś.

Pięć współrzędnych

Skoro nawigacja potrzebuje adresu, a nie nastroju, to warto wiedzieć, z czego ten adres się składa. Pięć elementów, w tej kolejności.

Rola. Z jakiej perspektywy model ma patrzeć. „Doświadczony audytor umów IT” daje inną odpowiedź niż „copywriter”. To nie jest przebieranka, tylko zawężenie obszaru, z którego model czerpie wzorce.

Zadanie. Jedno, jednoznaczne polecenie. Nie „przeanalizuj i podsumuj, a potem zaproponuj”, tylko jedna czynność. Trzy zadania w jednym poleceniu prawie zawsze dają trzy powierzchowne odpowiedzi zamiast jednej porządnej.

Kontekst. Materiał, na którym model ma pracować, i tło, którego nie zna. To jest miejsce, w którym wykonujesz najwięcej pracy i które najbardziej wpływa na wynik.

Format. Jak ma wyglądać odpowiedź: tabela, pięć punktów, akapit, plik JSON. Bez tego dostajesz format domyślny, czyli eseik.

Ograniczenia. Czego modelowi nie wolno. To najczęściej pomijany element, a często najskuteczniejszy. „Nie tłumacz podstaw”, „nie proponuj narzędzi spoza tej listy”, „jeśli czegoś brakuje w materiale, napisz czego, zamiast zgadywać”.

Jak to wygląda w praktyce

Zadanie: masz notatki ze spotkania i chcesz z nich zrobić coś użytecznego.

Wersja odruchowa:

Zrób podsumowanie tego spotkania.
[wklejone notatki]

Dostaniesz streszczenie. Prawdopodobnie wierne i prawdopodobnie bezużyteczne, bo streszczenie notatek to nadal notatki, tylko krótsze.

Wersja z adresem:

ROLA
Kierownik projektu przygotowujący materiał dla zarządu.

ZADANIE
Wyciągnij z notatek wyłącznie decyzje i zobowiązania.

KONTEKST
Spotkanie dotyczyło wyboru dostawcy hurtowni danych. W notatkach są też
wątki poboczne o rekrutacji, które można pominąć. Zarząd zna projekt,
nie trzeba go wprowadzać.

FORMAT
Tabela: decyzja lub zadanie | osoba odpowiedzialna | termin | status.
Osobno lista spraw nierozstrzygniętych.

OGRANICZENIA
Nie streszczaj dyskusji. Jeśli termin lub osoba nie padły wprost,
wpisz „brak w notatkach” zamiast zgadywać.

Różnica nie bierze się z długości polecenia, tylko z tego, że każda decyzja została podjęta przez Ciebie, a nie zrzucona na model. Który wątek pominąć, co jest wynikiem, a co dyskusją, co zrobić przy brakujących danych. Model jest w tym układzie wykonawcą, a nie współautorem planu.

Cztery nawyki, które psują wynik

Poza brakiem struktury są cztery zachowania, które widzę na każdym warsztacie. Każde ma tę samą przyczynę: przenoszenie odruchów z rozmowy z człowiekiem na narzędzie, które rozmową nie jest.

Trzy zadania w jednym poleceniu. „Przeanalizuj tę umowę, wypisz ryzyka i zaproponuj poprawki” wygląda na oszczędność czasu. W praktyce dostajesz trzy powierzchowne odpowiedzi zamiast jednej porządnej, bo model dzieli uwagę między cele. Rozbij na trzy kroki, przy czym wynik pierwszego wchodzi do drugiego.

Uprzejmości zamiast treści. „Czy mógłbyś mi pomóc, byłbym wdzięczny, to bardzo ważne dla mnie” nie wpływa na jakość, a zajmuje miejsce w kontekście. Nie chodzi o to, żeby być niegrzecznym. Chodzi o to, że grzeczność nie zastępuje specyfikacji.

Poprawianie w nieskończoność. Po trzeciej korekcie w tej samej rozmowie model widzi jednocześnie wszystkie poprzednie wersje wymagań i nie ma jak rozstrzygnąć, która obowiązuje. Objaw: „przecież przed chwilą mówiłem, żeby tego nie robić”. Taniej jest otworzyć nową rozmowę i napisać lepsze pierwsze polecenie.

Pytanie o opinię zamiast o kryteria. „Czy ta oferta jest dobra?” zwróci uprzejmy ogólnik. „Oceń tę ofertę według czterech kryteriów: cena, termin, zakres wsparcia, kary umowne. Przy każdym podaj cytat z dokumentu” zwróci coś, z czym da się iść na spotkanie.

Kiedy nie warto tego robić

Uczciwie: nie każde zapytanie zasługuje na pięć sekcji. Rozbudowany prompt do „przetłumacz to zdanie” jest stratą czasu i sprawia, że ludzie porzucają metodę jako przesadzoną.

Rozróżnienie jest proste. Struktura opłaca się wtedy, gdy zamierzasz użyć wyniku, a nie tylko sprawdzić, co model powie. Jeśli wynik ma trafić do dokumentu, do klienta albo do repozytorium, wart jest trzech minut na sformułowanie zadania. Jeśli jest jednorazową ciekawostką, pisz jednym zdaniem.

Druga zasada: przy zadaniu powtarzalnym prompt piszesz raz, a nie za każdym razem. Jeśli w zespole dziesięć osób co tydzień formułuje na nowo to samo polecenie do tego samego procesu, to jest błąd organizacyjny, nie kwestia umiejętności. Miejsce na taki prompt jest w instrukcji systemowej, GEM-ie albo pliku w repozytorium.

Co zrobić w tym tygodniu

1. Weź trzy ostatnie rozmowy z AI, które Cię rozczarowały. Sprawdź, ile z pięciu elementów w nich było. Zwykle jest jeden: zadanie. Częściej to wyjaśnia rozczarowanie niż jakość modelu.
2. Przepisz jeden z nich i porównaj wyniki obok siebie. To ćwiczenie działa lepiej niż jakiekolwiek wyjaśnienie, bo różnica jest widoczna od razu.
3. Znajdź w zespole jedno zadanie powtarzalne i zapisz do niego prompt w miejscu, do którego wszyscy mają dostęp. To pierwszy krok od indywidualnego kombinowania do wspólnego standardu.

W kolejnej części serii biorę na warsztat mapę, po której model się porusza: przestrzeń znaczeń, wyszukiwanie semantyczne i dwa mity o embeddingach, które krążą po materiałach szkoleniowych. Jeśli któreś z pojęć w tym tekście było niejasne, w słowniczku jest czternaście podstawowych haseł.