Wynik wychodzi płaski i ogólnikowy, jakby model odpowiadał obok tematu. Pierwszy odruch bywa taki: „słaby model, trzeba sięgnąć po mocniejszy”. Prawie zawsze to zły trop. Kiedy praca jest mierna, dźwignią jest zwykle to, jak poprosiłeś model — nie sam model.
Prompt to po prostu polecenie, które wpisujesz modelowi. Jest twoim interfejsem z nim: model odpowiada na to, co w poleceniu naprawdę zobaczył, a nie na to, co miałeś w głowie. Pokażę ci cztery nawyki, które wyciągają z nowoczesnego modelu rozumującego — takiego, który przed odpowiedzią potrafi przemyśleć zadanie, a nie tylko odruchowo dopisać dalszy ciąg — znacznie lepszą pracę, bez zmiany modelu. Moim punktem odniesienia jest Claude, ale nawyki działają na każdym z nich. Każdy z osobna jest drobny. Razem zmieniają to, co dostajesz na pierwszy rzut.
Daj kontekst i intencję — powiedz, po co to robisz
Model trafniej celuje, gdy rozumie zamiar. Kontekst to wszystko, co podajesz obok samego polecenia: tło sprawy, dla kogo jest efekt, z czym się wiąże, co jest naprawdę ważne. Bez tego model musi zgadywać, o co ci chodziło — i zgaduje przeciętnie.
Spójrz na zwykłe polecenie: „napisz maila do klienta o opóźnieniu”. Model napisze poprawnego, gładkiego maila — tyle że generycznego, bo nie wie nic o sytuacji. Ta sama prośba z tłem wygląda inaczej: „pracuję nad [projekt], to jest dla [klient], który czeka na [rzecz]; poślizg wynika z [powód], a nowy termin to [data]. Klient musi wynieść z tego jedno: [sedno]. Napisz na tej podstawie krótkiego, spokojnego maila”. Druga wersja daje wynik, który da się wysłać niemal bez poprawek — bo model wie, po co to robisz i co czytelnik ma z tego zapamiętać.
Jest tu dodatkowa korzyść. Jeśli masz dobrze poukładane pliki z kontekstem, dobra prośba sama pociągnie model do tych właściwych — sięgnie po informacje, których potrzebuje, zamiast pisać na oślep. To ta sama zasada, którą rozwijam osobno: Wszyscy mają ten sam model — wygrywa twój kontekst. Model jest dla każdego taki sam; twoją przewagą jest kontekst, który mu podajesz.
Mów, czego NIE robić — postaw granice
Model bywa „kreatywny” tam, gdzie wcale tego nie chcesz. U podstaw wciąż przewiduje kolejny sensowny krok i czasem dorzuci coś, o co nie prosiłeś. Bywa, że to pomaga. Częściej przeszkadza. Dlatego warto wprost powiedzieć, czego ma nie robić.
Myślę o tym jak o wprowadzaniu stażysty. Nowej osobie nie tłumaczysz tylko, co ma zrobić — mówisz też, czego ma nie ruszać, dopóki nie dasz sygnału, bo nie zna jeszcze procesu i łatwo o nieporozumienie. Z modelem jest tak samo.
Prosty przykład granicy. Zamiast „rzuć okiem na ten problem i się nim zajmij” — co otwiera pole do niechcianych poprawek — powiedz: „kiedy opisuję problem, twoim zadaniem jest ocena. Zrelacjonuj, co widzisz, i zatrzymaj się. Nie poprawiaj, nie wysyłaj, nie usuwaj niczego, dopóki nie powiem «działaj»”. Druga wersja odbiera modelowi prawo do samowolnego ruchu — dostajesz diagnozę, nie zaskakujące zmiany.
Ta sama logika działa przy budowaniu czegokolwiek: „rób najprostszą rzecz, która działa; nie dodawaj funkcji, o które nie prosiłem”. Jedno zdanie, a oszczędza ci rozdmuchanych, „ulepszonych” wyników, których potem trzeba się pozbywać.
Warto wiedzieć, że kiedyś takie negatywne wskazówki działały słabiej niż samo precyzyjne opisanie, czego chcesz. Nowsze modele czytają je znacznie wierniej — dlatego dziś to jeden z tańszych sposobów, żeby model przestał cię zaskakiwać.
Pozwól działać, gdy ma dość — i dawkuj wysiłek
Częsty odruch to kazać modelowi rozpisać wszystko z góry: „zbadaj temat i zrób pełny plan, zanim cokolwiek zrobisz”. Przy prostszych zadaniach to zbędny narzut. Lepiej zdjąć nadmiar planowania i pozwolić działać: „gdy masz dość, żeby ruszyć, ruszaj”. Model sam zbierze tyle kontekstu, ile potrzebuje, i przejdzie do roboty, zamiast produkować plan, którego nikt nie zamawiał.
Z tym wiąże się druga rzecz: dawkowanie wysiłku. Claude ma poziomy wysiłku — niski, średni, wysoki i bardzo wysoki. To jak pokrętło, które mówi modelowi, jak głęboko ma się zastanawiać, zanim odpowie. Wysoki to sensowny domyślny wybór do większości zadań. Bardzo wysoki zostaw na naprawdę trudne rzeczy. Do rutyny — niski albo średni w zupełności wystarczy, a przy okazji odpowiedź przychodzi szybciej.
Ta sama zasada dotyczy wyboru modelu. Po najmocniejszy — i zwykle najdroższy — sięgaj rzadko, tylko przy naprawdę trudnych zadaniach; do codziennej roboty prawie zawsze wystarczy coś lżejszego. Używanie najmocniejszego modelu do wszystkiego to niemal zawsze przesada: płacisz więcej i czekasz dłużej, nie zyskując na jakości tam, gdzie zadanie tego nie wymaga. Trafne dobranie wysiłku i modelu do zadania to osobna umiejętność, którą warto ćwiczyć. Rozwijam ją w dwóch miejscach: Jak realnie używać Claude Opus 4.8 oraz Tani wykonawca, drogi doradca — jak dobierać model AI do zadania.
Mów mniej, nie więcej — prowadź wynikiem
To zabrzmi jak zaprzeczenie pierwszego nawyku, ale nim nie jest. W dobrze przygotowanym środowisku — gdy model ma kontekst, właściwe pliki i narzędzia pod ręką — krótka instrukcja prowadzona wynikiem steruje tak samo dobrze jak rozpisywanie każdej reguły z osobna. Nadal dajesz „dlaczego”, tylko nie zaśmiecasz polecenia dziesiątkami drobnych nakazów.
Zamiast listy: „reguła 1: bądź zwięzły; reguła 2: nie lej wody; reguła 3: trzymaj się tematu…” — powiedz krótko: „prowadź wynikiem, trzymaj prostotę, pytaj tylko wtedy, gdy praca naprawdę tego wymaga”. Mniej słów, ten sam kierunek — a model nie grzęźnie w regulaminie zamiast pracować.
Takie nawyki najlepiej wpisać na stałe tam, gdzie model i tak zagląda: w pliki pamięci albo stałe instrukcje (w Claude to plik CLAUDE.md). Raz porządnie sformułowane, działają w tle przy każdym zadaniu — nie musisz doklejać ich na końcu każdego promptu.
Piąty nawyk ma własne miejsce
Jest jeszcze jeden nawyk, który waży najwięcej: każ modelowi udowodnić, że efekt naprawdę działa, zamiast wierzyć na słowo w jego „gotowe”. Jest na tyle ważny, że opisuję go osobno — Nie pytaj, czy skończył — każ agentowi udowodnić, że działa.
Prompt jest twoim interfejsem, nie zaklęciem
Wszystkie cztery nawyki sprowadzają się do jednej myśli: prompt jest tym, przez co rozmawiasz z modelem — nie loterią, w której raz się trafia, raz nie. Kontekst mówi, po co pracujesz. Granice mówią, czego unikać. Dawka wysiłku ustala, ile model ma w to włożyć. Zwięzłość pilnuje, żeby nie zagłuszyć sygnału szumem. Nie wykluczają się nawzajem — nakładają się i z każdym zadaniem procentują coraz mocniej.
Nie musisz wdrażać ich wszystkich naraz. Weź jeden prompt, który ostatnio dał ci mierny wynik, i dopisz do niego jedną rzecz — samo „dlaczego” to robisz. Zwykle to wystarczy, żeby zobaczyć różnicę.