30 praktycznych technik tworzenia promptów dla Claude z rzeczywistego codziennego użytku

Niezliczone przewodniki po „inżynierii promptów” są zaznaczane jako ulubione, ale nigdy nie są ponownie otwierane. Zbyt wiele z nich jest czytanych tak, jakby ktoś wysłał dwa prompty, zrobił zrzut ekranu i ogłosił to metodologią.

To, co następuje, różni się głównie ze względu na swoje pochodzenie: miesiące codziennych, czasem męczących rozmów z Claude’em, stosowanych w różnych projektach pobocznych i przy pracy jako freelancer, wraz z dużą ilością prób i błędów, aby ustalić, które często powtarzane „najlepsze praktyki” rzeczywiście przetrwają w kontakcie z prawdziwą pracą.

Część poniższych technik rzeczywiście zmienia sposób, w jaki programiści podchodzą do tworzenia promptów. Kilka z nich zostało przetestowanych, odrzuconych, ale nadal zachowano, ponieważ nadal skutecznie rozwiązują konkretne problemy. A kilka, które wyglądają jak chwyty marketingowe, okazuje się być jednymi z najcenniejszych pozycji na całej tej liście. Każdy rozdział wskazuje, do której kategorii należy.

Są one podzielone na cztery grupy w zależności od tego, co faktycznie osiąga każda technika, a nie od tego, jak skomplikowana brzmi na papierze:

Part 1 — Say What You Mean          (clarity & structure)
Part 2 — Put Up Guardrails          (constraints & format control)
Part 3 — Make It Reason Out Loud    (thinking & iteration)
Part 4 — Build a System, Not a Prompt (workflows & long context)

Część 1 — Mów, co masz na myśli

1. Bądź konkretny, nie ogólnikowy

To wciąż jeden z najczęstszych błędów popełnianych podczas formułowania zapytań. Prośba o „poprawienie tego” przyniesie coś ogólnego i łatwego do zapomnienia. Prośba o „przepisanie tego akapitu tak, aby założyciel bez wiedzy technicznej mógł zrozumieć kluczowe rozterki w dwóch zdaniach” przyniesie coś użytecznego.

Praktyczna zasada: jeśli napisanie zapytania zajęło mniej niż 10 sekund, prawdopodobnie nie było ono wystarczająco konkretne.

2. Używaj tagów strukturalnych do oddzielenia poszczególnych części zapytania

Tagi w stylu XML warto używać stale — nie z powodu twierdzenia, że jest to „język naturalny” Claude’a (twierdzenie trudne do zweryfikowania, które należy traktować sceptycznie, gdy jest przedstawiane z pełną pewnością), ale dlatego, że tagi rozwiązują rzeczywisty, praktyczny problem: gdy instrukcje, kontekst i przykłady mieszają się w jednym bloku tekstu, model musi zgadnąć, gdzie zaczyna się i kończy każda sekcja. Tagi całkowicie eliminują takie domysły.

<instructions>
Summarize the risks section only. Ignore financial projections.
</instructions>
<context>
[pasted document]
</context>
<output_format>
3 bullet points, no more than 15 words each
</output_format>

3. Najpierw kontekst, potem pytanie

To uporządkowanie ma większe znaczenie, niż się na pierwszy rzut oka wydaje. Wklejanie długiego dokumentu, a następnie zadawanie pytania po nim zazwyczaj skutkuje znacznie gorszymi odpowiedziami niż zadanie pytania po przedstawieniu całego materiału. Jednym z możliwych wyjaśnień, choć niepotwierdzonym naukowo, jest to, że takie uporządkowanie zapobiega temu, by model próbował sformułować odpowiedź, zanim faktycznie skończy przeczytać wszystko.

[long document]
---
Based on everything above, what's the single biggest
risk to the Q3 timeline?

4. Pokaż, a nie tylko opisuj (przykłady typu few-shot)

Przymiotniki opisowe są tanie i często niejasne. Jeden konkretny przykład pożądanego tonu, struktury lub formatu jest skuteczniejszy niż cały akapit opisu. W przypadku powtarzających się zadań — takich jak e-maile do klientów, opinie po przeglądzie kodu czy podobne rutyny — pomocne jest przechowywanie dwóch lub trzech przykładów „standardu złotego” w pliku notatek, gotowych do wklejenia za każdym razem, gdy pojawi się ten sam typ zadania.

5. Wyjaśnij dlaczego, a nie tylko zasadę

To jedna z bardziej zaskakujących technik na tej liście. Technicznie rzecz biorąc, polecenie Claude’owi „utrzymaj to poniżej 280 znaków” działa. Jednak gdy powiemy mu, że „to trafi prosto na tweet, a wszystko przekraczające 280 znaków zostanie obcięte w środku zdania”, wynik jest wyraźnie bardziej staranny. Wydaje się, że podanie powodu sprawia, iż model bierze pod uwagę to ograniczenie przez całą odpowiedź, zamiast po prostu liczyć znaki na samym końcu.

6. Wyraźnie zezwalaj na odpowiedź „Nie wiem”

Jedną linijkę warto dodać do niemal każdego promptu badawczego lub analitycznego:

If the available information isn't enough to draw a
conclusion, say so directly instead of guessing.

Jeśli pominie się tę linię, istnieje realne ryzyko otrzymania bezsensownych odpowiedzi brzmiących jak pewne stwierdzenia. Jeśli ją dodać, odpowiedź czasami brzmi „nie ma tu wystarczająco dużo informacji, by móc cokolwiek stwierdzić z pewnością” – co jest niezadowalające w momencie, ale lepsze niż odkrycie sfabrykowanego faktu kilka godzin później.

7. Określ format wyjściowy, nie zakładaj go

Istnieje znaczna różnica między prośbą o „tabelę” a prośbą o „tabelę w formacie tekstu prostego, tak sformatowaną, by mogła zostać bez problemów wklejona do bloku kodu, ponieważ Medium zwykle psuje tabele w formacie Markdown”. Precyzyjne opisanie dokładnego kształtu pożądanej odpowiedzi całkowicie unika takich niezgodności.

8. Zdefiniuj, jak powinno wyglądać „ukończenie zadania”, a nie tylko samo zadanie

Zamiast opisywać same zadanie, opisanie tego, jak powinien wyglądać udany wynik, zazwyczaj przynosi lepsze rezultaty:

I need a competitor comparison so my co-founder can
pick a pricing tier in under 5 minutes without asking
me follow-up questions.

To jedno zdanie ma większą wagę niż trzy akapity zasad formatowania razem wzięte.

Część 2 — Ustanowienie ograniczeń

9. Ograniczenia negatywne — określ, czego system NIE powinien robić

Czasami szybciej jest zdefiniować cel, wykluczając to, czego nie chcemy, niż próbując dokładnie określić to, czego faktycznie chcemy:

Do not sound like: a LinkedIn thought-leader post.
Do not include: "in today's fast-paced world," filler
caveats, or a summary that repeats the intro.

10. Wskazówka systemu w stylu „umowy”

Dla wszystkiego, co planujesz ponownie wykorzystać, napisz wskazówkę systemu jak krótką umowę prawną, a nie jak opis postaci:

Role: technical editor for a solo dev's blog
Goal: tighten prose without changing meaning
Constraints:
 - keep first-person voice
 - no invented statistics
 - flag anything that sounds AI-generated
If unsure: ask one clarifying question, don't guess
Output: plain markdown, no headers added

Unikaj udawania „doświadczonego eksperta”

To technika, której warto się pozbyć. Polecenie Claude’owi, by „działał jak 20-letni doświadczony inżynier”, nie wydaje się przynosić większych zmian, gdy instrukcje są już precyzyjne. Określenie roli ma znacznie mniejsze znaczenie niż faktyczne ograniczenia, które podajesz. Poleganie na roli w celu uzupełnienia brakujących szczegółów jest zazwyczaj oznaką, że same instrukcje wymagają udoskonalenia.

12. Samoocena według kryteriów

Zamiast ogólnego polecenia „sprawdź swoją pracę”, podaj rzeczywisty arkusz oceniania i zażądaj oceny samodzielnie ustalonej przed ostatecznym wynikiem:

Score your draft 1-10 on: technical accuracy, whether
a beginner could follow it, and whether it sounds
like a real person wrote it. Then revise based on
your own score. Show only the revised version.

Ten podejście już niejednokrotnie pomogło wykryć prawdziwe błędy w wyjaśnieniach kodu i podsumowaniach danych.

13. Dobieraj fragmenty długich dokumentów zamiast wrzucać wszystko naraz

Dodawanie większej ilości materiału nie poprawia automatycznie jakości odpowiedzi. Wklejanie całego kodu lub długiego pliku PDF bez uprzedniego filtrowania zwykle skutkuje odpowiedziami, które przeglądają tylko środkową część dokumentu, skupiając się na jego początku i końcu. Lepszym podejściem jest kierowanie Claude’a do najpierw wyodrębnienia odpowiednich fragmentów, a dopiero potem analizy ich — to wersja na małą skalę procesu typu „pobierz-następnie-analizuj”:

Step 1: extract the 5 passages most relevant to
[my question], quoting them exactly.
Step 2: analyze only those passages.

14. Oznaczanie kilku dokumentów podczas porównywania źródeł

Gdy porównuje się więcej niż jedno źródło, należy je wyraźnie oznaczyć i ponumerować zamiast po prostu oddzielać pustymi liniami. Ta niewielka modyfikacja znacznie zmniejsza ryzyko, że model przypisze dane twierdzenie niewłaściwemu dokumencie.

<document index="1" name="Q3_report.pdf">...</document>
<document index="2" name="Q2_report.pdf">...</document>

15. Sztywne granice dla ustrukturyzowanego wyjścia

Gdy wymagany jest ścisły format JSON lub określony schemat, należy to jasno指明 i wymienić dokładne klucze, zamiast opisywać strukturę w sposób ogólny i liczyć na to, że model prawidłowo ją odgadnie:

Return only a JSON object with keys: title, summary,
confidence (0-1), open_questions (array of strings).
No text before or after the JSON.

Część 3 — Proszę o wyjaśnienie na głos

16. Proszę o krok po kroku wyjaśnienie wszystkiego, co nie jest proste

Dodanie instrukcji nakazującej modelowi rozwiązywać problem etapami przed podaniem ostatecznej odpowiedzi oraz wskazywanie na wszelkie przypadki graniczne po drodze wymaga więcej wysiłku, niż się wydaje. Zasada ta jest przydatna we wszystkich sytuacjach związanych z matematyką, wieloetapową logiką lub decyzjami wymagającymi kompromisów. Pomijanie jej w zadaniach, które wydają się „oczywiście proste”, jest dokładnie tym momentem, gdy najczęściej pojawiają się błędy.

17. Łańcuchowanie zapytań zamiast jednego dużego pytania

Kuszące jest połączenie wszystkiego w jedną prośbę: przeczytać to, streszczać to, przerobić to na posty w mediach społecznościowych i zaproponować tytuł. Podzielenie tego na kolejne zadania daje lepsze wyniki na każdym etapie, ponieważ każdy pojedynczy krok musi dobrze wykonać tylko jedną czynność:

[1] extract key facts
      |
      v
[2] turn facts into a 3-paragraph summary
      |
      v
[3] turn summary into 5 short takeaways

18. Odwrotne brainstorming w przypadku trudnych decyzji

Ta technika początkowo wydawała się chwytem marketingowym, ale okazała się naprawdę przydatna. Zamiast bezpośrednio pytać, jak zapewnić sukces wdrożeniu, zacznij od pytania o coś przeciwnego:

Brainstorm 10 ways this launch could fail. For each
one, invert it into a concrete thing we'd do
differently. Flag the 3 inversions that are the least
obvious.

Ten podejście ujawnia słabe punkty, których zwykłe pytanie „Podaj mi strategię” często nie dostrzega.

19. Debata z udziałem kilku postaci w przypadku decyzji wymagających realnych kompromisów

To może być najsilniejsza technika na liście. W przypadku decyzji wymagających konkurujących się motywacji, poproś Claude’a, aby przed sformułowaniem rekomendacji rozważył sprawę z kilku różnych perspektyw:

Optimist            Skeptic           End user
      "ship faster"      "watch runway"    "don't care
           |                   |            about our
           v                   v             problems"
            \                 |                /
             \                |               /
              \               |              /
               v              v             v
                    synthesized recommendation

Zwykłe zapytanie typu „Proszę o rekomendację” skłania do wyboru odpowiedzi, która brzmi najprzyjemniej. Zmuszenie modelu do wewnętrznej dyskusji najpierw daje wynik o ostrzejszych, bardziej uzasadnionych argumentach.

20. Samokrytyka i poprawki w jednej rundzie

To rozwija ideę z wcześniejszego punktu, ale w lżejszej formie – poproś o pierwszy szkic, samokrytykę tego szkicu oraz poprawioną wersję końcową, wszystko w ramach jednego zapytania zamiast wielu wymian zdań:

Draft 1 -> list 3 weaknesses in Draft 1 -> Draft 2

21. Pozwól mu zadać pytania wyjaśniające przed rozpoczęciem pracy

W przypadku czegokolwiek niejednoznacznego lub mającego istotne konsekwencje, wyraźnie poinstruuj model, aby jeszcze nie zaczynał pracy i zadał wszystkie pytania, na które potrzebuje odpowiedzi. Działa to jako krótkie opóźnienie przed pierwszą rzeczywistą odpowiedzią, ale zazwyczaj pozwala uniknąć całej serii poprawek później.

22. Meta-prompting – poproś model o udoskonalenie twojego promptu

To mało wykorzystywana technika. Gdy prompt nadal generuje przeciętne wyniki, zamiast samemu go przerabiać, zapytaj bezpośrednio:

Here's the prompt I've been using: [paste]. Here's the
output it produces: [paste]. What's wrong with the
prompt, and rewrite it.

Często ujawnia to niejasne sformułowania, których sam byś nie dostrzegł, głównie dlatego, że już wiesz, co miałeś na myśli, i przechodzisz nad niejednoznacznościami.

23. Traktuj to jak rozmowę, a nie pojedynczy, doskonały prompt

To jest największa zmiana w sposobie myślenia, a raczej chodzi o porzucenie złego nawyku niż o zastosowanie jakiejś techniki: przestań szukać idealnego promptu. Poproś o wstępną, przybliżoną wersję, zareaguj na nią i dopracowuj dalej. Próba włożenia wszystkich wymagań do jednego, ogromnego promptu zawsze daje gorsze wyniki niż kilka krótkich rund iteracji i uzyskiwania informacji zwrotnej.

Część 4 — Stwórz system, a nie prompt

24. Używaj plików z regułami zamiast powtarzać to samo

To może być najcenniejsza zmiana nawykowa ze wszystkich. Zamiast wpisywać ponownie ton, odbiorców i ograniczenia do każdego nowego promptu, przechowuj je w osobnym pliku rules.md:

# Writing rules
- tone: direct, no fluff
- audience: builders, not consumers
- never use: "leverage", "in today's world"
- always: specific numbers, source links, one action item
- format: short paragraphs, 3 sentences max

Następnie na początku każdej sesji odwołuj się do niego: „Przeczytaj dokładnie rules.md przed rozpoczęciem. Jeśli zamierzasz złamać jedną z tych reguł, przestań i powiedz mi o tym.”

To zmienia podejście do formułowania zadań z coś, co trzeba robić na nowo za każdym razem, na konfigurację małego, trwałego narzędzia. To różnica między codziennym toczeniem tej samej bitwy a jej rozstrzygnięciem raz na zawsze.

25. Ustal jasno cykl planowania, działania, weryfikacji i iteracji

W przypadku zadań wymagających wielu kroków, w których Claude używa narzędzi, edytuje pliki lub uruchamia polecenia, nie zakładaj, że model sam zorganizuje proces. Opisz ten cykl wprost:

 ┌─────────┐    ┌────────┐    ┌────────┐    ┌────────┐
 │  PLAN   │ -> │  ACT   │ -> │ VERIFY │ -> │ ITERATE│
 │ max 5   │    │ use    │    │ against│    │  or    │
 │ steps   │    │ tools  │    │criteria│    │ done   │
 └─────────┘    └────────┘    └────────┘    └────────┘
                                  |  fail
                                  v
                             back to ACT

Instrukcja, która najskuteczniej zapobiega cichym, kaskadowym błędom, jest prosta: przechodź do następnego kroku tylko wtedy, gdy bieżący przeszedł weryfikację.

26. Opier twierdzenia na odzyskanych faktach, a nie pamięci

Dla informacji faktycznych należy wyraźnie poinstruować model, aby czerpał dane z materiału przed sobą, zamiast korzystać z pamięci treningowej. Prośba o „wskazanie konkretnej linii lub sekcji, z której pochodzi informacja” przekształca pozornie wiarygodną odpowiedź w taką, którą można rzeczywiście sprawdzić. Jeśli model nie może wskazać źródła, należy to potraktować jako sygnał do przerwy i weryfikacji ręcznej.

27. Wstawiaj ludzkie punkty kontrolne przed nieodwracalnymi działaniami

Każde zadanie polegające na wysyłaniu e-maila, zapisywaniu kodu lub wydawaniu pieniędzy powinno zawierać wyraźną instrukcję przerwy: „zatrzymaj się przed wykonaniem ostatecznego działania i pokaż mi, co zamierzasz zrobić”. Żaden system – ani żadne zaufanie do własnego osądu późną nocą – nie jest na tyle niezawodny, by pominąć ten krok.

28. Rozpoznawaj sytuacje, gdy długi prompt nie jest odpowiednim podejściem

Duże okna kontekstowe skłaniają do wrzucenia tam każdego dokumentu i liczenia na najlepszy wynik. Czasami to działa dobrze, ale często krótszy, ręcznie wybrany prompt zawierający tylko trzy istotne akapity daje lepsze rezultaty niż podanie całego dokumentu, ponieważ nie zmuszasz modelu do jednoczesnego sortowania i analizy. Zawsze najpierw dobieraj treść wejściową starannie, a do wklejania wszystkiego uciekaj się tylko wtedy, gdy naprawdę jeszcze nie wiesz, co jest istotne.

29. Kontroluj wersje swoich promptów tak samo, jak kontrolujesz wersje kodu

Gdy prompt zaczyna służyć do regularnej, powtarzającej się pracy – np. do tworzenia cotygodniowych raportów, materiałów dla klientów czy czegokolwiek ciągłego – przechowuj go w pliku z datą i krótkim wpisem do dziennika zmian. Może to wydawać się przesadą, dopóki jakaś „mała modyfikacja” potajemnie nie zepsuje funkcjonowania, od którego polegałeś, a ty nie będziesz miał żadnego zapisu tego, jak wyglądał prompt w poprzednim tygodniu.

30. Uruchomzij proces pracy lokalnie, jeśli wolisz uniknąć opłat za każdy token lub trzymać dane z dala od zewnętrznych serwerów

Żadna z tych technik nie wymaga koniecznie hostowanej API. W przypadku czegokolwiek, nad czym pracujesz wielokrotnie — testowania kryteriów oceny lub pętli plan/akcja/weryfikacja opisanej powyżej — często ma sens najpierw stworzyć prototyp przy użyciu lokalnego modelu z Ollamą, a następnie przenieść ostateczny prompt do Claude na końcową obróbkę. W ten sposób iteracje są tańsze, a nic nie opuszcza twojego komputera, dopóki nadal kształtujesz prompt.

Wersja hostowana, do szybkiego testowania z API Claude:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 500,
    "messages": [{"role": "user", "content": "Score this draft 1-10 on clarity, then revise it: [paste draft]"}]
  }'

Ekwiwalent lokalny, samodzielnie hostowany z użyciem Ollamy, bez klucza API i bez opłat za każdy token:

# one-time setup
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
docker exec -it ollama ollama pull llama3.1
# same self-evaluation prompt, run locally
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1",
  "prompt": "Score this draft 1-10 on clarity, then revise it: [paste draft]",
  "stream": false
}'

Miejscowy model nie będzie odpowiadał subtelnościom Claude’a, ale do iteracji nad strukturą zapytania — sprawdzania, czy rubryka jest poprawnie sformułowana, czy też ograniczenie rzeczywiście jest przestrzegane — jest on w pełni wystarczający i nie kosztuje nic po jego ustawieniu.

Szybki przegląd: wysiłek vs. efekt

Oto przybliżone rankowanie oparte na tym, które techniki faktycznie poprawiły jakość wyników, a które jedynie brzmiały imponująco:

TECHNIQUE                             EFFORT TO ADOPT   PAYOFF
----------------------------------    ----------------  --------
Rules/context file (#24)              low                very high
Multi-persona debate (#19)            low                high
Plan-act-verify loop (#25)            medium             high
Prompt chaining (#17)                 low                high
Permission to say "I don't know"(#6)  trivial            high
Explain the "why" (#5)                trivial            high
Reverse brainstorming (#18)           low                medium-high
Contract system prompt (#10)          medium             medium
"Act as an expert" persona (#11)      trivial            low

Jeśli chcesz z tego zestawienia zabrać tylko jedną rzecz, skup się na wierszu o niskim wysiłku i wysokim efekcie: dołącz powód do swoich ograniczeń oraz wyraźnie daj modelowi pozwolenie na przyznanie, że nie wie. Te dwie proste modyfikacje w cichy sposób rozwiązały więcej problemów z wynikami niż jakakolwiek skomplikowana struktura.

A jeśli nie zgadzasz się z jakąkolwiek częścią tego rankingu albo odkryłeś, że jedna z tych technik faktycznie szkodzi twojemu konkretnemu przypadkowi użycia, taki przypadek przeciwny jest o wiele bardziej przydatny niż kolejny ogólnikowy post typu „prompty, które zmienią twoje życie”.