Jak pisać prompty do ChatGPT bez myślenia jak programista?

Prompt to zlecenie dla modelu, który bez celu, danych i granic zaczyna sam dopowiadać brakującą część zadania.

Nie potrzebujesz tajnych formuł ani technicznego stylu. Opisz pracę tak, aby ChatGPT wiedział, co ma przygotować, na jakich danych pracuje, czego nie może wymyślać, co ma zrobić przy braku informacji i po czym poznasz, że wynik nadaje się do użycia.

Model nie zna Twojej sytuacji

Polecenie „napisz ofertę” brzmi dla człowieka całkiem normalnie. Dla modelu pozostawia jednak otwarte niemal wszystko.

Nie wiadomo, czy ma powstać e-mail, dokument sprzedażowy czy wiadomość prowadząca do rozmowy. Nie wiadomo, kto będzie odbiorcą, jakie informacje są pewne, jakiego tonu użyć ani czy wolno podawać cenę i termin.

Model nie zna Twojej oferty, aktualnego cennika, historii rozmowy z klientem ani granic, których handlowiec nie przekracza.

Słaba odpowiedź nie zawsze świadczy o słabym modelu. Czasem pokazuje, że zlecenie było zbyt niejasne, aby dało się je wykonać bez założeń.

Prompt jest zleceniem, nie opisem procedury

Programowanie polega na rozpisaniu działań tak, aby komputer wykonał dokładnie wskazane kroki. Komputer nie ma wyobraźni. Ma instrukcję.

Model językowy działa inaczej. Dostaje zadanie, materiały i ramy, a potem sam układa odpowiedź. Nie kontrolujesz każdego jego ruchu. Kontrolujesz warunki, w których pracuje.

Dlatego prompt przypomina dobre zlecenie dla człowieka:

• wiadomo, co ma powstać,
• wiadomo, dla kogo powstaje,
• wiadomo, na jakich materiałach należy pracować,
• wiadomo, czego nie wolno obiecać ani dopowiedzieć,
• wiadomo, po czym osoba zlecająca uzna wynik za użyteczny.

Nie trzeba pisać technicznie. Trzeba pisać tak, aby osoba wykonująca zadanie nie musiała zgadywać celu, danych ani granic odpowiedzialności.

Dobre zlecenie ma sześć części

Używalny prompt nie opisuje każdego ruchu modelu. Ustala, co model ma zrobić, na jakich danych pracuje, gdzie kończy się jego swoboda i po czym poznasz, że wynik nadaje się do użycia.

Składa się z sześciu części:

• Instrukcja: konkretna praca do wykonania, np. „przygotuj odpowiedź e-mailową na zapytanie klienta”.
• Kontekst: sytuacja, odbiorca, dane wejściowe i fakty, na których model może się oprzeć.
• Cel: efekt, który ma powstać w firmie, np. doprowadzenie do rozmowy zamiast przedwczesnej wyceny.
• Ograniczenia: rzeczy, których model nie może dopowiadać, zmieniać ani obiecywać.
• Zachowanie przy braku danych: sposób działania modelu, gdy nie otrzyma informacji potrzebnych do przygotowania odpowiedzi.
• Kryteria odbioru: format, długość, wymagane elementy i warunki, które wynik musi spełnić.

Instrukcja i cel to nie to samo. „Przygotuj e-mail” mówi, co model ma zrobić. „Doprowadź do rozmowy z klientem bez składania obietnicy ceny” mówi, po co ten e-mail powstaje.

Kontekst nie jest ozdobnikiem. To materiał, który ogranicza zgadywanie. Oficjalne wskazówki OpenAI dotyczące promptowania zalecają jasne instrukcje, istotny kontekst, określenie formatu odpowiedzi oraz poprawianie poleceń na podstawie obserwowanych wyników.

Sam zakaz wymyślania informacji nie wystarcza. Model musi wiedzieć, co zrobić, gdy brakuje danych. W prostym zadaniu może zadać pytanie. Przy większej liczbie spraw może oznaczyć lukę, aby człowiek uzupełnił ją przed wysłaniem odpowiedzi.

Ton i odbiorca nie zawsze są potrzebne

Jeśli model ma przygotować tabelę, streszczenie albo listę zadań dla zespołu, ton komunikacji nie ma większego znaczenia. Gdy wynik ma przeczytać klient, pracownik albo partner, warto wskazać, dla kogo powstaje tekst i jak ma brzmieć.

Odbiorca określa poziom wiedzy, język i zakres szczegółów. Ton komunikacji określa sposób przedstawienia odpowiedzi.

„Profesjonalnie” nie daje modelowi prawie żadnych granic. Może prowadzić do wiadomości sztywnej, nadętej albo pełnej formuł, których nikt nie chce czytać.

Lepiej opisać ton konkretnie:

Odbiorca:
Właściciel kancelarii, który nie musi znać technicznych szczegółów tworzenia stron internetowych.

Ton komunikacji:
Rzeczowy, spokojny i pomocny. Pisz prostym językiem. Nie używaj technicznego żargonu, presji sprzedażowej ani przesadnej poufałości.

Odbiorca i ton są dodatkami do zlecenia. Nie zastępują instrukcji, danych, celu ani ograniczeń. Mogą jednak uchronić przed odpowiedzią formalnie poprawną, ale brzmiącą jak wiadomość napisana przez dział prawny.

Rola jest dodatkiem, nie fundamentem

Rola może określać perspektywę pracy modelu, np. „działasz jako opiekun klienta firmy tworzącej strony internetowe” albo „pracujesz jako redaktor, który usuwa powtórzenia, ale nie dopisuje faktów”.

Nie trzeba dodawać jej do każdego promptu. Nie zastąpi brakującego kontekstu, nie ustali celu ani nie zatrzyma modelu przed wymyślaniem danych.

Prompt z pustym kontekstem nie staje się dobry tylko dlatego, że zaczyna się od zdania „Jesteś światowej klasy ekspertem”.

Kontekst to nie jedna rzecz

Gdy ktoś słyszy „dodaj kontekst”, łatwo kończy się to zdaniem: „Prowadzę firmę usługową”. To za mało, aby model wiedział, jaką pracę ma wykonać.

Kontekst składa się z kilku rodzajów informacji. Każdy chroni przed innym typem błędu.

Nie każdy prompt potrzebuje pełnego zestawu. Proste streszczenie e-maila wymaga głównie materiału źródłowego i formatu wyniku. Odpowiedź ofertowa potrzebuje także reguł firmy, odbiorcy, celu handlowego i granic odpowiedzialności.

Im bardziej kosztowna jest pomyłka, tym mniej miejsca można zostawić na domysły.

Jedna oferta, dwa różne wyniki

Załóżmy, że prowadzisz firmę usługową i chcesz szybciej odpowiadać na zapytania o stronę internetową.

Pierwsza wersja wygląda tak:

Napisz ofertę na nową stronę internetową dla kancelarii.

To jeszcze nie jest zlecenie.

Model nie wie, czy ma przygotować ofertę, e-mail, wycenę czy pytania do klienta. Nie zna wielkości kancelarii, celu wiadomości, granicy odpowiedzialności ani elementów, które odpowiedź ma zawierać.

Wersja używalna może wyglądać tak:

Przygotuj odpowiedź e-mailową na zapytanie klienta.

Kontekst:
Kancelaria licząca sześć osób chce nową stronę internetową i formularz kontaktowy.

Cel:
Doprowadzić do rozmowy doprecyzowującej potrzeby. Nie przygotowuj jeszcze wyceny.

Format:
E-mail do 180 słów.

Ma zawierać:
Krótkie podsumowanie potrzeb klienta, trzy pytania doprecyzowujące oraz propozycję rozmowy.

Ograniczenia:
Nie wymyślaj zakresu prac, terminu realizacji ani ceny.

Gdy brakuje danych:
Nie zakładaj brakujących informacji. Zadaj pytanie potrzebne do przygotowania następnego kroku.

Taki prompt nie zapewnia idealnej pierwszej wersji. Ogranicza jednak obszar, w którym model może uzupełniać brakujące fakty własnymi założeniami.

Wynik przechodzi kontrolę, gdy:

• ma formę e-maila,
• mieści się w limicie długości,
• podsumowuje podane potrzeby,
• zawiera trzy pytania,
• prowadzi do rozmowy,
• nie zawiera wymyślonej ceny, terminu ani zakresu,
• przy braku danych nie udaje, że je zna.

To nie jest programowanie. Model nadal sam układa zdania i wybiera kolejność argumentów. Różnica polega na tym, że porusza się po wyznaczonej drodze.

Prompt nie naprawi wadliwego procesu

Wyobraź sobie firmę, która chce automatycznie przygotowywać oferty. Handlowiec zapisuje rozmowę w notatniku, klient dosyła wymagania w trzech wiadomościach, cennik jest w starym arkuszu, a zakres usługi zmienia się po ustnym ustaleniu.

W takiej sytuacji problemem nie jest brak sprytnego polecenia. Brakuje jednego źródła danych, jasnych reguł i osoby, która zatwierdza wynik.

Najpierw ustal, co jest wejściem, jaki wynik ma powstać, które informacje są aktualne i kto odpowiada za zatwierdzenie odpowiedzi. Dopiero potem prompt ma się czego trzymać.

Czy psuje się prompt, czy proces?

Model jest wygodnym podejrzanym. Gdy odpowiedź jest zła, łatwo uznać, że trzeba „lepiej promptować”. Czasem tak jest. Czasem prompt działa poprawnie, ale otrzymuje złe dane albo ma obsłużyć proces, którego nikt wcześniej nie uporządkował.

Poniższa tabela pomaga odróżnić jedno od drugiego.

Ta diagnoza oszczędza czas. Zamiast poprawiać prompt po raz dziesiąty, możesz zobaczyć, że problem tkwi w starym cenniku, niejasnym zakresie usługi albo braku osoby, która ma prawo zatwierdzić odpowiedź.

Jeden dobry wynik jeszcze niczego nie dowodzi

Prompt warto sprawdzić w trzech realnych sytuacjach:

• Prosty przypadek: klient podał komplet danych, więc wynik powinien trzymać format i ograniczenia.
• Typowy przypadek: część informacji wymaga doprecyzowania, ale zadanie nadal ma znany kierunek.
• Niepełny przypadek: brakuje danych potrzebnych do odpowiedzi, więc model ma zadać pytanie albo oznaczyć lukę.

Prompt można uznać za gotowy do ponownego użycia dopiero wtedy, gdy:

• działa w kilku realnych przypadkach, nie tylko w jednym wygodnym przykładzie,
• zachowuje granice, nawet gdy dane są niepełne,
• nie udaje wiedzy, której nie otrzymał,
• daje wynik, który osoba odpowiedzialna sprawdza w krótkim czasie,
• korzysta ze stałego układu danych wejściowych.

Wystarczą trzy lub cztery rzeczywiste sprawy, które firma obsłużyła albo właśnie obsługuje.

Gdy odpowiedź się rozjeżdża, szukaj braku

Gdy odpowiedź jest słaba, łatwo wpisać: „napisz lepiej”. To zwykle prowadzi do kolejnej wersji, która jest inna, ale niekoniecznie użyteczna.

Skuteczniejsza poprawka wskazuje konkretny brak w zleceniu.

To podejście przypomina kontrolę jakości, a nie polowanie na „magiczne komendy”. Model ma wykonać określoną pracę. Twoim zadaniem jest sprawdzić, czy otrzymał warunki wystarczające do jej wykonania.

Od szkicu do procesu

Praca z AI ma trzy poziomy. Mieszanie ich prowadzi do rozczarowań.

Szkic może oszczędzić kilka minut. Szablon ogranicza liczbę poprawek w powtarzalnej pracy. Proces zmienia sposób działania firmy, ponieważ nie opiera się już na pamięci jednej osoby i przypadkowych wiadomościach.

Wróćmy do kancelarii. Na poziomie szkicu właściciel kopiuje dane z e-maila, wkleja je do promptu i ocenia wynik. To dobry początek.

Na poziomie szablonu handlowiec zawsze podaje te same informacje: liczbę osób, rodzaj usługi, cel odpowiedzi, dane potwierdzone, dane nieznane oraz etap rozmowy z klientem. Prompt otrzymuje stały układ wejściowy, więc wyniki przestają zależeć od tego, kto akurat pisał wiadomość.

Na poziomie procesu formularz zbiera dane o zapytaniu, aktualny zakres usługi i reguły są w jednym miejscu, model przygotowuje szkic odpowiedzi, a osoba odpowiedzialna zatwierdza ją przed wysłaniem. Model przyspiesza pracę, ale nie zastępuje decyzji handlowej.

Są sprawy, których nie oddajesz modelowi

Nie oddawaj modelowi samodzielnego podejmowania decyzji, gdy:

• odpowiedź tworzy wiążące zobowiązanie wobec klienta,
• błąd może wywołać problem prawny, finansowy albo wizerunkowy,
• dane wejściowe są niepełne i nikt nie potrafi ich szybko sprawdzić,
• sprawa wymaga negocjacji, oceny relacji albo świadomego wyjątku od reguły,
• firma nie ma aktualnego źródła danych,
• używane środowisko nie zostało właściwie ocenione pod kątem ochrony danych.

Zacznij od zadania pod kontrolą

Pierwsze zastosowanie AI w firmie powinno być łatwe do oceny.

Dobrze nadaje się do tego zadanie powtarzalne, o znanym wyniku, korzystające z dostępnych danych i pozwalające człowiekowi szybko wykryć błąd.

To może być:

• szkic odpowiedzi na zapytanie klienta,
• streszczenie długiego e-maila,
• uporządkowanie notatki ze spotkania,
• pierwsza wersja komunikatu,
• roboczy szkic oferty przygotowany do sprawdzenia.

Słabym początkiem jest decyzja oparta na niepełnych danych, wiążąca deklaracja wobec klienta albo zadanie, którego nikt w firmie nie potrafi ocenić.

Zamień powtarzalne zadanie w proces

Wybierz jeden fragment pracy, który powtarza się kilka razy w tygodniu i nie wymaga podejmowania decyzji za klienta lub firmę.

Zbierz dane, które dziś otrzymuje osoba wykonująca to zadanie. Rozdziel fakty o sprawie, reguły firmy, materiał źródłowy, informacje o odbiorcy i granice decyzji.

Potem opisz cel, ograniczenia, zachowanie przy braku danych oraz warunki, po których osoba odpowiedzialna zatwierdzi wynik.

Przetestuj szablon na prostym, typowym i niepełnym przypadku. Nie szukaj kolejnej „mocniejszej komendy”. Sprawdzaj, gdzie odpowiedź się rozjeżdża, i uzupełniaj brakujący warunek w zleceniu.

Gdy wynik pozostaje używalny w kilku sytuacjach, prompt przestaje być pojedynczym pytaniem do czatu. Staje się prostym szablonem pracy.

FAQ

Czy promptowanie to programowanie?

Nie. Programowanie opisuje komputerowi konkretne instrukcje wykonania. Prompt ustala cel, kontekst, granice i oczekiwany wynik, a model sam układa odpowiedź.

Czy trzeba pisać technicznie, aby dobrze korzystać z ChatGPT?

Nie. Przydaje się jasne opisanie zadania. Model nie potrzebuje technicznego języka, ale potrzebuje danych, celu, ograniczeń i informacji o tym, co zrobić przy braku danych.

Dlaczego ChatGPT podaje nieprawdziwe informacje, choć prompt był szczegółowy?

Szczegółowość nie pomaga, gdy w promptcie brakuje wiarygodnych danych albo gdy model ma zbyt dużo miejsca na założenia. W zadaniach opartych na faktach ogranicz model do materiałów, które podajesz, i wskaż, co ma zrobić, gdy nie znajdzie odpowiedzi.

Czy dobry prompt można używać wielokrotnie?

Tak, jeśli zadanie ma podobne dane wejściowe i podobny wynik. Zanim przekażesz go zespołowi, sprawdź go na kilku realnych przypadkach, także takim, w którym brakuje danych.

Kiedy sam prompt nie wystarcza?

Wtedy, gdy firma nie ma uporządkowanych danych, ustalonych etapów pracy, aktualnych zasad albo osoby odpowiedzialnej za akceptację wyniku. Najpierw porządkujesz proces. Dopiero potem przekazujesz jego część modelowi.