Jak pisać prompty, które działają — struktura, sekcje i czego nie robić

Problem

Piszesz prompt, wkładasz w API, dostajesz coś przeciętnego. Dorzucasz kolejne zdanie, kolejny zakaz, kolejną instrukcję — wynik się nie poprawia, a czasem psuje. Po godzinie masz ścianę tekstu, w której sam się gubisz, a model dalej halucynuje albo ignoruje połowę wymagań.

Problem nie leży w tym, że "AI jest głupie". Leży w tym, że prompt jest źle ustrukturyzowany — model dostaje sygnały, których nie umie rozdzielić na "to jest zadanie", "to są dane", "to są zasady".

Ten wpis to suma tego, co realnie działa w produkcji, kiedy prompt musi być wywoływany setki razy i dawać przewidywalny wynik.

Co model widzi, czego nie widzisz

Każdy LLM tnie tekst na tokeny — kawałki słów albo całe słowa. Model nie czyta promptu liniowo jak człowiek, tylko przetwarza wszystkie tokeny naraz przez mechanizm uwagi (attention). Uwaga decyduje, które tokeny są ze sobą powiązane.

Z tego wynika kilka praktycznych konsekwencji:

1. Początek i koniec promptu mają największą wagę. Klasyczne primacy/recency bias. To, co wstawisz w środku długiego promptu, ma szansę zostać przyćmione.
2. Struktura wizualna jest sygnałem semantycznym. Model był trenowany na masie Markdowna, XML-a, kodu i dokumentacji — rozpoznaje nagłówki, listy i tagi jako "to jest osobny blok znaczeniowy".
3. Powtórzenie wzmacnia. Jeśli zasada jest krytyczna, powtórz ją na początku i na końcu.
4. Im więcej tekstu, tym bardziej rozmyta uwaga. Krótki, konkretny prompt często bije długi i wyczerpujący.

Struktura która działa

Najprostszy szkielet, który skaluje się od jednorazowych zapytań do produkcyjnych pipeline'ów:

# Rola
Działaj jako [konkretna profesja].

# Zadanie
[Jedno zdanie - co model ma zrobić.]

# Dane wejściowe
[Konkretne dane do przetworzenia.]

# Wymagania
- [twardy warunek 1]
- [twardy warunek 2]
- [twardy warunek 3]

# Czego unikać
- [zakaz 1]
- [zakaz 2]

# Format wyjścia
[Dokładny format - JSON, Markdown, lista, cokolwiek.]

Każda sekcja oddzielona pustą linią i nagłówkiem # to wyraźny sygnał dla modelu, że zmienia się kontekst. To działa lepiej niż jeden zbity akapit, nawet jeśli zawiera te same informacje.

Markdown vs XML

Dwa popularne podejścia do strukturyzowania promptów.

Markdown — nagłówki #, listy -, bloki kodu. Czytelne dla człowieka i dobrze rozumiane przez model.

# Zadanie
Wygeneruj krótki opis produktu.

# Wymagania
- maksymalnie 200 znaków
- bez wykrzykników

XML — tagi opisowe. Preferowane w prompach do Claude (Anthropic wprost to rekomenduje w dokumentacji), bo model był specjalnie trenowany na takim formacie.

<zadanie>
Wygeneruj krótki opis produktu.
</zadanie>

<wymagania>
- maksymalnie 200 znaków
- bez wykrzykników
</wymagania>

W praktyce: dla GPT-4 i podobnych — Markdown. Dla Claude — XML. Dla innych modeli — sprawdź dokumentację, ale Markdown to zawsze bezpieczna baza.

Czego nie robić

1. Nie pakuj wszystkiego w jeden akapit

Najczęstszy błąd. Prompt typu:

Napisz tytuł produktu na podstawie nazwy i parametrów, długość 50-60 znaków,
nie używaj słów X Y Z, użyj jednego ze słów A B C, format JSON z polem title,
pamiętaj że to ma być w języku polskim, nie używaj nazw marek...

Model dostaje wszystko naraz, w jednej linii myślowej. Trudniej mu rozdzielić "to jest zadanie" od "to jest zakaz" od "to jest format". Rozbij to na sekcje.

2. Nie używaj negacji jako głównego narzędzia

"Nie pisz X, nie używaj Y, unikaj Z" — model dostaje listę zakazów, ale nie ma pozytywnego kierunku. Zamiast samych zakazów, dodaj pozytywne wytyczne: "pisz w stylu X", "używaj słów z listy Y", "trzymaj się formatu Z". Zakazy zostaw na końcu jako uzupełnienie.

3. Nie powtarzaj sprzecznych instrukcji

"Pisz krótko... rozwiń każdy punkt szczegółowo... maksymalnie 100 znaków... wyjaśnij dokładnie kontekst". Model próbuje pogodzić wszystko i wychodzi z tego nijaki kompromis. Każde wymaganie powinno być wewnętrznie spójne z resztą.

4. Nie buduj promptu z literalnymi placeholderami w cudzysłowach

Konstrukcje typu 'TEMPLATE_VAR' zostawione w prompcie po podstawieniu (bo zmienna była pusta) to klasyczna pułapka silników szablonów. Model widzi puste cudzysłowy '' albo dziwne literały i nie wie, co z tym zrobić. Waliduj, że wszystkie zmienne zostały podstawione przed wysłaniem promptu.

5. Nie ignoruj formatowania znaków kontrolnych

Jeśli budujesz prompt po stronie serwera (PHP, Python, Node) i potem go serializujesz do JSON, upewnij się że biblioteka serializująca poprawnie escape'uje znaki kontrolne. Surowy \n w stringu JSON to złamanie RFC 8259 i strict parsery to odrzucą. Używaj wbudowanych json.dumps() / json_encode() zamiast budowania JSON-a stringami.

6. Nie pisz "ważne" i "pamiętaj"

Słowa typu "WAŻNE", "PAMIĘTAJ", "KONIECZNIE" wielkimi literami nie działają tak, jakbyś chciał. Model nie ma emocji ani poczucia obowiązku. Lepiej: precyzyjnie sformułuj wymaganie i umieść je na początku albo końcu sekcji.

Co realnie poprawia jakość

W kolejności od najmocniejszego do najsłabszego efektu:

1. Konkretność zadania. "Napisz coś o psach" vs "Napisz 3-zdaniowy opis hodowli labradorów dla strony hodowcy". Drugie da o rząd wielkości lepszy wynik.

1. Przykłady (few-shot). Pokaż 2-3 przykłady tego, co chcesz dostać. To najsilniejsze narzędzie w prompcie — model uczy się formatu i stylu z przykładów lepiej niż z opisu słownego.

1. Konkretny format wyjścia. JSON ze schematem, dokładna struktura Markdowna, ścisła liczba punktów. Im konkretniej, tym mniej halucynacji.

1. Rola. "Działaj jako [profesja]" działa, bo aktywuje w modelu wzorce skojarzone z tą profesją. Tylko nie przesadzaj z teatralnością.

1. Łańcuch myślowy (chain of thought). "Najpierw przeanalizuj X, potem zrób Y, na koniec sformatuj Z" — daje lepsze wyniki niż "zrób Z" przy złożonych zadaniach.

1. Struktura wizualna (sekcje, listy). Mniejszy efekt niż wszystko powyżej, ale działa zwłaszcza przy długich promptach.

1. Entery i białe znaki. Najmniejszy efekt z tej listy — pomagają, ale to drobny tuning.

Iteracja, nie pierwszy strzał

Prompt który dobrze działa rzadko powstaje od razu. Realny proces:

1. Wersja 1. Najprostsza wersja zadania. Sprawdź, czy model w ogóle łapie temat.
2. Wersja 2. Dodaj wymagania formatu i jeden przykład. Przetestuj na 5-10 różnych inputach.
3. Wersja 3. Znajdź typowe błędy z poprzedniej wersji i dopisz konkretne wymagania, które je eliminują. Nie wymagania "ogólne, na wszelki wypadek".
4. Wersja 4. Jeśli prompt rośnie powyżej ~50 linii, zastanów się czy nie da się go uprościć. Często dodawanie zasad nie poprawia wyniku, tylko zwiększa szum.

Praktyczne wskazówki na koniec

• Wersjonuj prompty w gicie. Traktuj je jak kod, bo nim są.
• Trzymaj zestaw testowych inputów. Po każdej zmianie sprawdź, czy stary zestaw dalej daje akceptowalne wyniki.
• Loguj rzeczywiste prompty z produkcji. Często ich finalny kształt różni się od tego, co masz w szablonie — przez podstawione zmienne, escape'y, kodowanie.
• Temperatura ma znaczenie. Dla deterministycznych zadań (klasyfikacja, ekstrakcja danych) — 0 albo blisko zera. Dla generowania treści — 0.6-0.9. Wartości powyżej 1.0 to już ryzyko nonsensów.
• Krótszy prompt często wygrywa. Jeśli wynik jest gorszy po dodaniu nowej zasady, usuń ją. Mniej znaczy więcej.

Co się dzieje pod spodem

LLM nie "rozumie" Twoich instrukcji w sensie ludzkim. To statystyczny przewidywacz następnego tokenu, który nauczył się rozpoznawać wzorce z treningu. Kiedy widzi # Wymagania w prompcie, aktywuje wzorce skojarzone z dokumentacją techniczną i listami wymagań — bo widział ich miliony. Kiedy widzi spójną strukturę zadanie→dane→wymagania→format, idzie po torze który był wielokrotnie utrwalony.

Twój prompt to nie polecenie wydane człowiekowi. To kontekst, w którym model przewiduje najbardziej prawdopodobną odpowiedź. Im lepiej kontekst dopasujesz do wzorców z treningu, tym lepiej wyjdzie wynik. Cała sztuka pisania promptów sprowadza się do tego.