Skuteczne techniki promptowania

Prosisz o „system uwierzytelniania użytkowników z weryfikacją e-mail”, a model wybiera strategię sesji, której nigdy byś nie wdrożył, na sztywno wpisuje mailer, którego nie używasz, i przez następne dwadzieścia minut odplątujesz decyzje, które podjął za ciebie, bo ty ich nie podjąłeś. Model się nie mylił — był niepokierowany. Przepaść między frustrującą sesją a świetną niemal nigdy nie leży w modelu. Leży w tym, jak formułujesz prośbę.

Oto wzorce promptowania, które konsekwentnie dają trafny, dobrze zaprojektowany kod w Cursorze, Claude Code i Codeksie.

Co z tego wyniesiesz

Wzorzec promptu zaczynającego od doprecyzowania, który dopiszesz do każdej złożonej prośby
Pętlę plan-potem-wykonanie, która powstrzymuje model przed rzuceniem się w wadliwą implementację
Przykłady few-shot oraz szczere spojrzenie na prompty z personą (kształtują ton, nie trafność)
Prompty o wysokiej dźwigni do zacinającego się debugowania, samodzielnego przeglądu i czystszych drugich wersji
Tabelę rozwiązywania problemów dla każdego narzędzia, gdy jakość wyników spada

Złota zasada: proś o doprecyzowanie

Najpewniejsza pojedyncza technika — kończ złożone prompty prośbą o doprecyzowanie, tak by model ujawnił brakujące wymagania, zanim zwiąże się z jakimś podejściem, zamiast zgadywać:

Create a user authentication system with email verification.
Ask for everything you need to prepare the best implementation
before writing any code.

Działa to, bo zmusza model do ujawnienia założeń, póki ich zmiana jest jeszcze tania. Stosuj ten sam wzorzec przez cały cykl życia:

PRD: “Ask for everything you need to prepare the best PRD”
Planowanie: “Ask for everything you need to prepare the best plan”
Implementacja: “Ask for any clarifications before starting”
Debugowanie: “Ask for any additional context that would help diagnose this issue”

Bądź konkretny i podawaj ograniczenia

Im więcej ograniczeń podasz, tym mniej model improwizuje. Ogólnikowe prośby dają generyczny kod; konkretne prośby dają kod, który da się wdrożyć.

Nie mów: „Dodaj połączenie z bazą danych.”
Mów: „Dodaj połączenie z naszą bazą PostgreSQL za pomocą biblioteki pg. Ładuj connection string ze zmiennej DATABASE_URL. Dołącz logikę ponawiania prób z wykładniczym wycofywaniem i typowaną funkcję health-check.”

Nazwanie biblioteki, zmiennej środowiskowej i zachowania przy błędach z góry kieruje model ku właściwej implementacji w jednym przebiegu, a nie w trzech.

Najpierw planuj, potem wykonuj

W przypadku czegokolwiek większego niż jednolinijkowa zmiana zmuś model do myślenia, zanim zacznie kodować.

Najpierw poproś o plan — i zabroń kodu.

I need a feature that lets users upload a profile picture. First,
produce a detailed, step-by-step plan: list the files you'll create
or modify and the order of changes. Do NOT write any code yet.

Przejrzyj i udoskonal plan. Model zwraca zarys („1. Dodaj /api/upload-avatar. 2. Dodaj pole pliku do ProfilePage…”). Popraw go, zanim powstanie jakikolwiek kod: „Użyj osobnego komponentu AvatarUpload zamiast edytować ProfilePage bezpośrednio.”

Wykonaj zatwierdzony plan.

The plan looks good. Implement step 1 only, then stop so I can review
the diff before we continue.

Ta dwufazowa pętla wyłapuje błędy architektoniczne, gdy ich poprawienie kosztuje jedno zdanie, a nie diff na 30 plików. Po pełną dyscyplinę zajrzyj do PRD → plan → todo.

Podawaj przykłady (few-shot prompting)

Żeby model dopasował się do konwencji twojej bazy kodu, pokaż mu istniejący plik, zamiast opisywać konwencję prozą.

Nie mów: „Stwórz klasę serwisu z konstruktorem, prywatnym loggerem i JSDoc na metodach publicznych.”
Mów: „Stwórz klasę PaymentService, która podąża dokładnie za wzorcem i strukturą pliku @/services/AuthService.ts.”

Modele doskonale rozpoznają wzorce. Konkretny przykład to ciaśniejsza specyfikacja niż jakikolwiek opis.

Przypisz personę — dla skupienia, nie dla trafności

Naładowanie modelu rolą — „jesteś starszym inżynierem ds. bezpieczeństwa” — jest powszechnie nauczane, ale bądź precyzyjny co do tego, co ci to daje. Kontrolowane badania (Mollick et al., Playing Pretend: Expert Personas Don’t Improve Factual Accuracy, 2026; oraz studium EMNLP 2024 „A Helpful Assistant” obejmujące cztery rodziny modeli i ponad 2400 pytań) wykazały, że eksperckie persony nie poprawiają niezawodnie poprawności — a niedopasowana persona może pogorszyć wyniki. To, co rola niezawodnie kształtuje, to ton, format i to, które kwestie model wysuwa na pierwszy plan. Używaj więc persony, by sterować tym, na co model patrzy, a właściwy ciężar przenieś na konkretne kryteria, nie na nazwę stanowiska:

Ekspert ds. bezpieczeństwa

„You are an expert security engineer. Review this code for XSS, CSRF, and SQL injection. List every issue with a concrete fix.”

Guru wydajności

„You are a senior performance engineer. Find bottlenecks in this function and suggest optimizations that reduce allocations and time complexity.”

Bardziej użyteczny ruch niż „wciel się w jednego eksperta” to poproszenie o kilka perspektyw naraz — przeformułowanie spopularyzowane przez Andreja Karpathy’ego: traktuj model jako symulator wielu punktów widzenia, a nie pojedynczy byt.

Instead of answering as one expert, imagine the panel of specialists who
would weigh in on this design — name them, then give each one's strongest
critique and what they'd change. Surface where they disagree.

Iteruj i udoskonalaj

Traktuj sesję jak dialog, a nie pojedynczy strzał. Pokieruj pierwszą próbą ku temu, czego naprawdę chcesz:

„Dobry początek, ale nie obsłużyłeś przypadku niezalogowanego użytkownika. Dodaj to sprawdzenie.”
„To działa, ale źle się czyta — zrefaktoryzuj zagnieżdżone if-y na switch.”
„Dodaj kompleksowy zestaw testów jednostkowych dla funkcji, którą właśnie napisałeś.”

Trzy prompty o wysokiej dźwigni

Kilka promptów zarabia na siebie niemal w każdym zadaniu. Trzymaj je pod ręką.

Postaw hipotezę, zanim naprawisz

Gdy model miota się przy błędzie — edytuje linie, uruchamia ponownie, cofa zmiany — zatrzymaj go i wymuś przebieg zaczynający się od hipotezy, zamiast pozwalać mu zgadywać:

Gotowy prompt do zacinającego się debugowania:

Reflect on 5-7 different possible sources of this bug, distill those down to
the 1-2 most likely, then add logs to validate your assumptions BEFORE writing
any fix. Show me the log output before you change application code.

To najczęściej powtarzany prompt do debugowania wśród praktyków, i nie bez powodu: powstrzymuje model przed związaniem się z pierwszą wiarygodną przyczyną i zamienia pętlę zgadywania w pomiar.

Każ modelowi przejrzeć własny diff

Najtańszy krok weryfikacji to drugi przebieg po własnej pracy modelu, skonfrontowany z tym, o co naprawdę poprosiłeś:

Gotowy prompt do przebiegu samodzielnego przeglądu:

Go through every change you just made and cross-check each one against my
original request. For each: did you implement it fully, and did you introduce
any mistakes, regressions, or changes I didn't ask for? List what you find
before fixing anything.

Poproś o drugą wersję

Pierwsza implementacja to często eksploracja. Gdy już działa, model wie wystarczająco dużo, by napisać czystszą wersję:

Gotowy prompt do czystszego przepisania:

This works. Now, knowing everything you learned implementing it, delete your
version and rewrite it to be simpler and more maintainable — fewer moving
parts, clearer names, less code — without changing behavior. Keep the tests green.

Gdy to zawodzi: rozwiązywanie problemów dla każdego narzędzia

Gdy jakość wyników spada, przyczyną niemal zawsze jest kontekst lub konfiguracja — nie model. Naprawy różnią się w zależności od narzędzia, więc tu trzy podejścia rozchodzą się najbardziej.

Model nie rozumie bazy kodu: stwórz regułę komendą New Cursor Rule (Cursor Settings > Rules, Commands) albo wygeneruj ją z czatu. Reguły utrwalają konwencje projektu w każdym żądaniu.
Model odtwarza istniejący kod: @-wskaż źródło — @auth.ts extend the login logic — żeby edytował, a nie wymyślał od nowa.
Dezorientacja co do biblioteki: dodaj Context7 MCP („use Context7 for docs”), żeby do kontekstu trafiła aktualna dokumentacja biblioteki.
Słaba jakość przy trudnych zadaniach: upewnij się, że wybrałeś topowy model w selektorze (Claude Fable 5, Opus 5 lub Sonnet 5) i włącz tryb MAX do pracy z dużym kontekstem. Fable 5 to najmocniejsza opcja do najtrudniejszych refaktoryzacji i złożonej pracy wieloplikowej; pełne zestawienie poziomów i cen znajdziesz w porównaniu modeli.

Model nie rozumie bazy kodu: uruchom /init, aby wygenerować CLAUDE.md, a potem dopracowuj go w miarę rozwoju projektu.
Sprawdź, co zjada kontekst: uruchom /context przed dużym zadaniem; /clear między niepowiązanymi zadaniami i /compact <instructions>, by przyciąć szum w trakcie wątku.
Potrzebujesz głębszego rozumowania: rozszerzone myślenie jest włączone domyślnie. Trwałą głębokością steruj przez poziom effort w /model lub /effort. ultrathink jest tylko wskazówką one-turn w kontekście; nie zmienia API effort ani nie rezerwuje stałego budżetu.
Dezorientacja co do biblioteki: dodaj Context7 MCP albo poproś o wyszukanie dokumentacji w sieci.

Model nie rozumie bazy kodu: uruchom /init wewnątrz TUI, aby utworzyć szkielet AGENTS.md, i trzymaj osobne pliki AGENTS.md dla każdego pakietu w monorepo.
Odtwarza istniejący kod: wskaż mu plik źródłowy i poproś o rozszerzenie zamiast budowania od nowa.
Dostrajaj autonomię, nie „słowa-klucze myślenia”: konfiguruj sandbox i zatwierdzenia osobno — do rutynowej pracy lokalnej użyj --sandbox workspace-write -c approval_policy=on-request; approval_policy=never rezerwuj dla zaufanych przebiegów unattended z jawnym sandboxem. Następnie wybierz właściwy model: rodzina GPT-5.6 napędza Codeksa na wszystkich powierzchniach; użyj gpt-5.6-sol do przepływów uwierzytelnianych kluczem API.
Dezorientacja co do biblioteki: dodaj Context7 MCP po aktualną dokumentację.

Formuła sukcesu

Skonfiguruj kontekst. Utrzymuj reguły projektu / CLAUDE.md / AGENTS.md; odświeżaj je w miarę zmian w bazie kodu.
Wykorzystaj właściwą możliwość. Wybierz topowy model; w Claude Code podnieś poziom wysiłku do pracy architektonicznej; w Cursorze włącz tryb MAX dla dużego kontekstu.
Bądź konkretny. Odwołuj się do konkretnych plików @-wskazaniami i pokazuj przykładowe wzorce.
Proś o doprecyzowanie. Kończ prompty pytaniem, czego model potrzebuje; używaj pętli PRD → plan → todo dla kontroli.
Skonfiguruj dostęp do dokumentacji. Dodaj Context7 MCP albo poleć wyszukanie aktualnej dokumentacji biblioteki w sieci.

Co dalej

PRD → plan → todo — pętla planowania stojąca za „planuj, potem wykonuj”
Tryb agenta vs tryb zapytania — kiedy planować, a kiedy puścić agenta luzem
Dokumentacja jako kontekst — podawanie modelowi aktualnej dokumentacji
Zarządzanie dużymi bazami kodu — te techniki w skali monorepo