Jak pisać prompty do kodu, żeby dostawać użyteczne wyniki
Model nie wie, czego chcesz, dopóki mu tego nie powiesz. Większość słabych wyników bierze się nie ze słabego modelu, tylko z niedopowiedzianego zadania.
1. Podaj kontekst i cel
Napisz, w jakim języku i frameworku pracujesz, co już istnieje w projekcie i po co ma powstać nowa funkcja. Cel jest ważniejszy niż sposób: „użytkownik ma móc zapisać się na newsletter” mówi więcej niż „dodaj formularz”.
2. Wskaż ograniczenia
Jeśli nie chcesz nowych zależności, nie zgadzasz się na zmianę struktury plików albo kod ma działać na starszej wersji środowiska, powiedz to wprost. Model chętnie dodaje biblioteki, o które nikt nie prosił.
3. Pracuj małymi krokami
Zamiast jednego wielkiego polecenia podziel pracę na etapy, które da się sprawdzić osobno. Łatwiej wtedy znaleźć moment, w którym coś się zepsuło.
4. Najpierw plan, potem kod
Przy większych zadaniach poproś o krótki plan zmian i zatwierdź go, zanim model zacznie pisać. Poprawienie planu jest tańsze niż poprawianie trzystu linii kodu.
5. Opisz, jak poznasz, że działa
Kryteria akceptacji, przykłady danych wejściowych i oczekiwanych wyników, a najlepiej poprosić o testy. Model, który wie, jak będzie oceniany, pisze dokładniej.
Przykład
Zamiast „zrób stronę z listą zadań” spróbuj czegoś takiego:
Gdy coś nie działa
Wklej pełny komunikat błędu, a nie jego streszczenie, i napisz, co zmieniło się tuż przed jego pojawieniem. Jeśli po trzech próbach model krąży w kółko, zacznij nową rozmowę z krótkim podsumowaniem problemu. Zagmatwany kontekst szkodzi tak samo jak jego brak.
