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ę
Prompty few-shot i z personą, które przykuwają model do konwencji twojej bazy kodu
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ę

Przygotowanie modelu rolą skupia go na właściwej dziedzinie wiedzy.

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.”

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ś.”

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 4.8 lub Sonnet 4.6) 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. Na Opus 4.6+ steruj głębią przez poziom wysiłku (ustawiany w /model lub CLAUDE_CODE_EFFORT_LEVEL: low / medium / high) — a nie przez wpisywanie „ultrathink”, które jest teraz traktowane jako zwykła instrukcja i nie przydziela dodatkowego myślenia.
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”: ustaw poziom zatwierdzania przez --ask-for-approval (untrusted / on-failure / on-request / never) i wybierz właściwy model — GPT-5.5 domyślnie napędza Codeksa na wszystkich powierzchniach; użyj gpt-5.2-codex 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