Skuteczne techniki promptowania agentów AI

Skuteczne techniki promptowania agentów AI to pięć wzorców, które zamieniają ogólnikową prośbę w sprawdzalną pracę: agent zadaje pytania, zanim zacznie pisać kod, prompt podaje ograniczenia i polecenie, które dowodzi poprawności wyniku, wskazuje istniejący plik jako wzorzec, planowanie poprzedza implementację, a przegląd obejmuje dowody zamiast każdej linijki.

Ta strona jest dla programistów, którzy codziennie pracują z Claude Code, Codeksem albo Cursorem, i dla tech leadów, którzy chcą, żeby cały zespół promptował w ten sam sposób. Prosisz o „uwierzytelnianie użytkowników z weryfikacją e-mail”. Agent wybiera strategię sesji, której nigdy byś nie wdrożył, podpina mailer, którego nie używasz, pisze testy mockujące wszystko i melduje sukces. Każda z tych decyzji to luka w prompcie, którą model wypełnił wartością domyślną.

Co dają te techniki promptowania przy prawdziwym zadaniu

• Prompt z pytaniami doprecyzowującymi, który wydobywa brakujące wymagania, zanim powstanie jakikolwiek kod
• Szablon „ograniczenia plus sprawdzenie”, który mówi agentowi, co znaczy „gotowe”, w postaci polecenia do uruchomienia
• Pętlę „najpierw plan, potem implementacja”, która zatrzymuje błędy architektoniczne, póki ich poprawka kosztuje jedno zdanie
• Prompty ratunkowe na zapętlone debugowanie, samodzielny przegląd i czystszą drugą wersję
• Raport z dowodami, który sprawdzisz w dwie minuty zamiast czytać diff na 600 linii
• Dźwignie w każdym narzędziu (instrukcje projektu, odwołania do plików, poziom rozumowania, higiena kontekstu), które poprawiają jakość, zanim zaczniesz zmieniać model

Dlaczego ten sam model pisze raz dobry, a raz zły kod?

Agent traktuje wszystko, czego nie powiesz, jako decyzję, którą wolno mu podjąć. Każda technika poniżej zamyka jeden rodzaj luki:

Luka w prompcie	Co robi agent	Technika, która ją zamyka
Wymagania, których nie podałeś	Zgaduje wiarygodną wartość domyślną	Najpierw pytania
Biblioteka, konfiguracja, obsługa błędów	Improwizuje	Podaj ograniczenia
Nieokreślone „gotowe”	Kończy, gdy kod wygląda na gotowy	Wskaż sprawdzenie do uruchomienia
Konwencje w twoim repozytorium	Wymyśla własne	Wskaż istniejący plik
Samo podejście	Trzyma się pierwszego pomysłu	Plan, potem jeden krok implementacji

Kolejność ma znaczenie. Pytania idą pierwsze, bo odpowiedzi zmieniają ograniczenia; sprawdzenie idzie przed planem, bo planu bez sprawdzenia nie da się ani przyjąć, ani odrzucić.

Każ agentowi zadać pytania, zanim napisze kod

Każdą prośbę większą niż jednolinijkowa poprawka zakończ pytaniem, czego agent potrzebuje się dowiedzieć. Agent ujawnia swoje założenia, póki ich zmiana jest tania, a ty odpowiadasz w jednej wiadomości, zamiast wyplątywać je z diffu.

Prompt do skopiowania: najpierw pytania

I need user authentication with email verification for this Express + PostgreSQL app.
Before writing any code, read the existing auth-related files, then ask me the questions
whose answers would change the design: session vs token strategy, which mailer we use,
token expiry, rate limiting, and anything you found in the code that conflicts.
Ask at most seven questions, most important first. Do not edit any file until I answer.

Limit pytań jest ważny. Bez niego część sesji zwraca dwadzieścia banalnych pytań, a to istotne ląduje na czternastym miejscu. Dobre praktyki Claude Code od Anthropic opisują dłuższy wariant dla dużych funkcji: agent przeprowadza z tobą wywiad narzędziem AskUserQuestion, zapisuje wynik do pliku ze specyfikacją, a implementację robisz w nowej sesji (Claude Code best practices, sprawdzone 2026-09-26). Spisana specyfikacja to wejście, na którym opiera się reszta łańcucha artefaktów.

To samo zakończenie działa w całym cyklu życia: „zapytaj o to, czego potrzebujesz do najlepszej specyfikacji”, „zapytaj o to, czego potrzebujesz do planu”, „zapytaj o kontekst, który pomoże zdiagnozować ten błąd”.

Podaj ograniczenia i sprawdzenie, które agent musi uruchomić

Ogólnikowe prośby dają generyczny kod. Nazwij bibliotekę, źródło konfiguracji, zachowanie przy błędzie i przede wszystkim polecenie, które rozstrzyga, czy praca jest skończona.

• Zamiast: „Dodaj połączenie z bazą danych”.
• Napisz: „Dodaj połączenie z PostgreSQL przez bibliotekę pg. Connection string czytaj z DATABASE_URL. Ponawiaj z wykładniczo rosnącym odstępem (exponential backoff), najwyżej pięć prób. Wyeksportuj typowaną funkcję healthCheck(). Gotowe, gdy npm test -- db przechodzi, a npm run typecheck nie zgłasza błędów”.

Kluczowe jest ostatnie zdanie. Dobre praktyki Anthropic mówią to wprost: bez sprawdzenia, które agent może uruchomić, jedynym sygnałem jest to, że kod „wygląda na gotowy”, a pętlą weryfikacji stajesz się ty (Claude Code best practices, sprawdzone 2026-09-26). Gdy sprawdzenie istnieje, agent je uruchamia, czyta błąd i sam poprawia.

Prompt do skopiowania: ograniczenia i warunek ukończenia

Add rate limiting to POST /api/login.
Constraints:
- Use the existing Redis client in src/lib/redis.ts; add no new dependency.
- 5 attempts per IP per 15 minutes; respond 429 with a Retry-After header.
- Do not change the login response shape for successful requests.
Done when:
- A new test in tests/api/login.test.ts proves the 6th attempt returns 429.
- `npm test` and `npm run lint` both pass.
Do not edit or delete existing tests. Run both commands and paste their final lines.

„Do not edit or delete existing tests” to nie ozdobnik. Agent, który nie umie przejść sprawdzenia, czasem osłabia samo sprawdzenie; jak wymusić to mechanicznie, opisuje strona o ochronie wyroczni. Jak zamienić historyjkę użytkownika w takie sprawdzenia, pokazuje strona o wykonywalnych kryteriach akceptacji.

Wskaż istniejący plik zamiast opisywać konwencję

Żeby agent dopasował się do twojego kodu, pokaż mu plik, który już trzyma się konwencji. Konkretny przykład to ściślejsza specyfikacja niż akapit prozy i niesie szczegóły, o których zapomniałbyś wspomnieć: typy błędów, wywołania logowania, nazewnictwo, styl eksportów.

• Zamiast: „Utwórz klasę serwisu z konstruktorem, prywatnym loggerem i JSDoc przy metodach publicznych”.
• Napisz: „Utwórz PaymentService według struktury src/services/AuthService.ts: to samo wstrzykiwanie przez konstruktor, te same klasy błędów, to samo logowanie. Nie kopiuj komentarzy TODO ani przestarzałej metody legacyLogin”.

Wybierz plik, który niedawno przeszedł code review, i powiedz, czego nie kopiować. Agent wiernie odtwarza przykład, łącznie z jego błędami. Każde narzędzie ma też sposób na bezpośrednie dołączenie pliku; znajdziesz go w sekcji o różnicach między narzędziami poniżej.

Najpierw plan, potem implementacja krok po kroku

Przy wszystkim większym niż drobna poprawka oddziel myślenie od działania. Agent proponuje plan bez kodu, ty poprawiasz plan, a potem agent implementuje jeden krok i się zatrzymuje.

1. Poproś o plan i zabroń edycji. Przełącz narzędzie w tryb planowania tylko do odczytu (dokładny przełącznik w każdym narzędziu opisuje strona tryb agenta czy tryb pytań), a potem wyślij:

   Prompt do skopiowania: tylko plan

   Plan a feature that lets users upload a profile picture (max 2 MB, JPEG or PNG,
   stored in our existing S3 bucket via src/lib/storage.ts).
   Produce a numbered plan: for each step, the files you will create or change,
   what changes, and the test that proves the step works.
   Flag every assumption you are making. Do not write or edit any code.

2. Poprawiaj plan, nie kod. Plan wraca jako numerowana lista. Popraw go, póki jest tekstem: „Użyj osobnego komponentu AvatarUpload zamiast edytować ProfilePage. Typ MIME waliduj na serwerze, nie tylko w przeglądarce”.

3. Zaimplementuj jeden krok i zatrzymaj się.

   Prompt do skopiowania: jeden zatwierdzony krok

   The plan is approved with my corrections. Implement step 1 only.
   Run the test you named for step 1 and paste the result.
   Then list any place where you deviated from the plan, and stop.

Ta pętla wyłapuje złe podejście, gdy jego poprawka kosztuje jedno zdanie, a nie diff w 30 plikach. Pełną dyscyplinę, od intencji przez specyfikację i plan po zadania, opisuje strona o łańcuchu artefaktów.

Czy persona poprawia trafność agenta?

Nadawanie modelowi roli („jesteś starszym inżynierem bezpieczeństwa”) to popularna rada, ale dowody nie wspierają jej jako sposobu na trafność. Zheng, Pei, Logeswaran, Lee i Jurgens („When ‘A Helpful Assistant’ Is Not Really Helpful”, arXiv, listopad 2023) przetestowali 162 role na 4 rodzinach modeli i 2410 pytaniach faktograficznych. Dodanie persony do promptu systemowego nie poprawiło wyników względem braku persony, a efekt pojedynczej persony był „w dużej mierze losowy” (artykuł arXiv 2311.10054, streszczenie w wersji z repozytorium autorów, odczyt 2026-09-26).

Rola nadal wpływa na to, na co model patrzy i jak formatuje odpowiedź. Używaj jej do skupienia uwagi, a ciężar niech niosą jawne kryteria:

• Słabo: „Jesteś ekspertem od bezpieczeństwa. Przejrzyj ten kod”.
• Mocno: „Przejrzyj src/api/upload.ts pod kątem path traversal, braku walidacji MIME, nieograniczonego rozmiaru pliku i SSRF przez opcję importu z URL. Dla każdego znaleziska: plik, linia, szkic exploita, poprawka”.

Więcej niż jedna persona daje kilka perspektyw naraz, a rozbieżności między nimi odsłaniają kompromisy, które pojedyncza odpowiedź ukrywa.

Prompt do skopiowania: przegląd z kilku perspektyw

Review the design in docs/plans/avatar-upload.md from four perspectives:
security, operations (on-call at 3 a.m.), performance, and the next developer
who has to change this code. For each, give the strongest criticism and the change
it would demand. Then list where the perspectives disagree and what you recommend.

Jakie prompty wyprowadzają agenta z impasu i domykają zadanie?

Trzy prompty zwracają się niemal przy każdym zadaniu.

Hipoteza przed poprawką. Gdy agent miota się przy błędzie (edycja, uruchomienie, cofnięcie, od nowa), zatrzymaj go i wymuś pomiar zamiast kolejnego zgadywania. Cały przepływ pracy zbudowany na tej zasadzie opisuje strona o error-driven development.

Prompt do skopiowania: zapętlone debugowanie

Stop changing application code. List 5-7 possible causes of this failure,
narrow them to the 1-2 most likely with your reasoning, then add logging or a
failing test that would confirm or rule out each one. Run it and show me the
output before you propose any fix.

Samodzielny przegląd względem prośby. Drugie przejście agenta po własnym diffie, porównane z tym, o co prosiłeś, wyłapuje rozrost zakresu i zapomniane wymagania. To filtr, nie dowód; o dowodach mówi następna sekcja.

Prompt do skopiowania: samodzielny przegląd

Go through every change you made in this session and check it against my original
request. For each requirement: implemented fully, partially, or not at all?
Then list every change I did not ask for, including formatting, renamed symbols and
edited tests. Report first; do not fix anything yet.

Druga wersja. Pierwsza działająca wersja to często eksploracja. Gdy testy przechodzą, agent wie dość, żeby napisać prostszą wersję za tymi samymi testami.

Prompt do skopiowania: czystsza wersja przy zielonych testach

This works and the tests pass. Knowing what you learned, rewrite the implementation
to be simpler: fewer moving parts, clearer names, less code, same behaviour.
Do not touch the tests. Run the full test suite and the linter after the rewrite
and paste their final lines.

Jak sprawdzić wynik bez czytania każdej linijki?

Dobre promptowanie przenosi pracę z czytania kodu na sprawdzanie dowodów. Wbuduj dowody w prompt, a czytanie zostaw maszynom i drugiemu recenzentowi.

1. Sprawdzenie jest w prompcie. Każdy prompt implementacyjny kończy się poleceniami „gotowe, gdy” (testy, typy, lint), a agent wkleja ich wynik. Brak wyniku albo czerwony wynik oznacza, że zadanie nie jest skończone, cokolwiek mówi podsumowanie.

2. Agent pisze raport z dowodami. Proś o niego na końcu każdego zadania:

   Prompt do skopiowania: raport z dowodami przed przekazaniem

   Before you hand this back, write an evidence report:
   1. Each requirement from my request and the test that proves it (file and test name).
   2. Every command you ran to verify the work, with its exit code.
   3. Every file you changed, one line each on why.
   4. Anything you changed that I did not ask for, and anything you could not verify.
   Keep it under 40 lines.

3. Diff czyta drugi recenzent, nie ty. Uruchom niezależny przegląd w świeżym kontekście: /code-review w Claude Code, /review albo codex review w Codeksie, Bugbot na pull requeście w Cursorze. Agent, który napisał kod, jest słabym sędzią własnej pracy.

4. Ty zatwierdzasz dowody, o merge’u decyduje CI. Czytasz raport, wyrywkowo sprawdzasz testy dowodzące najbardziej ryzykownego wymagania i czytasz tylko pliki wskazane przez recenzenta. CI uruchamia te same sprawdzenia jeszcze raz i blokuje merge przy czerwonym wyniku.

Co musi zawierać kompletny raport dla pull requesta, opisuje strona o pakiecie dowodów, a sam przegląd — strona o code review PR-a agenta. O kodzie, który przechodzi testy, a mimo to jest błędny, przeczytasz na stronie o wyłapywaniu kodu wiarygodnego, ale błędnego.

Czym różni się promptowanie w Claude Code, Codeksie i Cursorze?

Gdy jakość wyników spada, najpierw sprawdź konfigurację, dopiero potem model: brak instrukcji projektu, brak odwołania do pliku, za niski poziom rozumowania albo okno kontekstu pełne nieudanych prób. Techniki opisane wyżej są takie same we wszystkich trzech narzędziach; różnią się dźwignie. Polecenia sprawdzono 2026-09-26 w claude --help 2.1.283, codex --help 0.157.1 i w dokumentacji poleceń Claude Code.

Claude Code

• Instrukcje projektu: /init generuje CLAUDE.md; przycinaj go, gdy projekt się zmienia.

• Wskazywanie plików: wpisz w prompcie @ i ścieżkę, na przykład @src/services/AuthService.ts, żeby dołączyć plik bezpośrednio.

• Najpierw plan: /plan <opis> przełącza w plan mode dla tego zadania.

• Poziom rozumowania: /effort high (albo xhigh) przed trudnym projektem lub refaktoryzacją; claude --effort high ustawia go dla sesji. Od v2.1.280 (kanał latest) domyślnym modelem jest Claude Opus 5.5, który domyślnie pracuje na poziomie medium, więc podnieś effort, zanim zmienisz model.

• Higiena kontekstu: /context pokazuje, co wypełnia okno; /compact <instrukcje> streszcza rozmowę w trakcie zadania; /clear zaczyna od nowa między niepowiązanymi zadaniami.

• Aktualna dokumentacja bibliotek: zainstaluj wtyczkę Context7 z oficjalnego marketplace’u:

  claude plugin install context7@claude-plugins-official

  Potem dopisz „use context7” do promptu, który dotyka szybko zmieniającej się biblioteki.

Codex

• Instrukcje projektu: /init w TUI tworzy AGENTS.md; w monorepo trzymaj po jednym na pakiet.

• Wskazywanie plików: /mention dołącza plik; możesz też podać ścieżkę w prompcie.

• Najpierw plan: /plan przełącza TUI w Plan mode.

• Poziom rozumowania: /model wybiera model i poziom rozumowania. Dla całej sesji podaj go jako konfigurację: codex -c model_reasoning_effort="high". Wbudowany model domyślny, GPT-6 Astra, pracuje w Codeksie domyślnie na poziomie low, więc podnieś effort, zanim zmienisz model.

• Higiena kontekstu: /compact streszcza rozmowę; /new otwiera nowy czat.

• Aktualna dokumentacja bibliotek: dodaj hostowany serwer MCP Context7 (klucz API jest opcjonalny i tylko podnosi limity):

  codex mcp add context7 --url https://mcp.context7.com/mcp

Cursor

• Instrukcje projektu: używaj Rules, które Cursor opisuje jako „system-level instructions to Agent” (dokumentacja Rules, sprawdzone 2026-08-28).

• Wskazywanie plików: podawaj ścieżkę pliku w prompcie, żeby agent edytował istniejący kod zamiast tworzyć go od nowa.

• Najpierw plan: Plan Mode „creates detailed implementation plans before writing any code”.

• Aktualna dokumentacja bibliotek: dodaj Context7 do .cursor/mcp.json:

  { "mcpServers": { "context7": { "url": "https://mcp.context7.com/mcp" } } }

Dokumentacji Cursora nie dało się ponownie sprawdzić 2026-09-26, więc ta zakładka zawiera tylko to, co zweryfikowano 2026-08-28, i nie wymienia żadnego modelu ani ustawienia trybu Cursora.

Który model uruchomić i kiedy odejść od domyślnego, opisuje przegląd modeli. Zasada, której trzyma się ten serwis: zacznij od domyślnego modelu narzędzia, dostrój effort przed zmianą modelu, a model zmieniaj dopiero wtedy, gdy twoje własne ewaluacje to uzasadniają. Obszerniejsze katalogi promptów dla poszczególnych narzędzi znajdziesz na stronach prompt engineering w Claude Code, prompt engineering w Codeksie i szablony promptów w Cursorze.

Jeśli prowadzisz zespół: gdy prompt z tej strony sprawdzi się u was, przestań go wklejać. Zapisz go jako skill w repozytorium, żeby każdy programista i każde narzędzie uruchamiali tę samą wersję; zobacz stronę o agent skills.

Co psuje się w tych promptach i jak z tego wyjść?

• Agent powtarza ten sam błąd mimo poprawek. Kontekst jest pełen nieudanych prób. Anthropic zaleca zacząć od nowa, gdy ten sam problem poprawiałeś więcej niż dwa razy (best practices, sprawdzone 2026-09-26). Wyjście: /clear w Claude Code albo /new w Codeksie, a potem jeden prompt zawierający to, czego się nauczyłeś.
• Etap pytań zwraca banalne pytania. Wyjście: ogranicz ich liczbę, żądaj „pytań, których odpowiedzi zmienią projekt”, i każ najpierw przeczytać kod, żeby agent nie pytał o to, co repozytorium już mówi.
• Agent skopiował błędy z pliku-wzorca. Wyjście: wybierz plik niedawno przejrzany i dopisz linijki „nie kopiuj” dla znanego długu.
• Implementacja odpływa od zatwierdzonego planu. Wyjście: jeden krok na prompt i obowiązkowa lista „odstępstw od planu” na końcu każdego kroku.
• Samodzielny przegląd twierdzi, że wszystko jest w porządku. Samodzielny przegląd filtruje, ale niczego nie dowodzi. Wyjście: opieraj się na poleceniach sprawdzających i niezależnym recenzencie w świeżym kontekście, jak w krokach weryfikacji wyżej.
• Sprawdzenie przechodzi, bo agent je zmienił. Wyjście: zabroń edycji testów w prompcie, przed akceptacją zrób diff katalogu z testami i ustaw sprawdzenia jako tylko do odczytu dla agenta, jak opisuje strona o ochronie wyroczni.
• Kod używa starego API biblioteki. Wyjście: dodaj Context7 albo wklej aktualną stronę dokumentacji; zobacz dokumentację jako kontekst.
• Jakość spada pod koniec długiej sesji. Wyjście: sprawdź zużycie kontekstu (/context w Claude Code), a potem skompaktuj rozmowę albo zacznij od nowa; zobacz stronę o oknach kontekstu.

Dokąd dalej po technikach promptowania

• Łańcuch artefaktów: intencja, specyfikacja, plan i zadania, czyli struktura, którą zasilają te prompty
• Tryb agenta czy tryb pytań: kiedy agent może edytować, a kiedy tylko planować
• Wykonywalne kryteria akceptacji: jak zamienić „gotowe, gdy” w nieprzechodzące testy przed implementacją
• Error-driven development: pętla debugowania zaczynająca od hipotezy
• Pakiet dowodów: co musi udowodnić pull request agenta