Wzorce promptów dla typowych zadań: refaktor, dokumentacja, testy

Czego się nauczysz

• Jak zbudować własne wzorce promptów do typowych zadań developerskich
• Jak dobierać prompt razem z trybem pracy, context itemem i narzędziem
• Jak unikać „uniwersalnych promptów”, które brzmią dobrze, ale są słabe w praktyce

Nie potrzebujesz jednego promptu do wszystkiego

To jest bardzo częsty etap dojrzewania pracy z Copilotem.

Na początku człowiek szuka jednego „master promptu”, który ma działać wszędzie: do refaktoru, do testów, do dokumentacji, do fixów i do review.

To zwykle zły kierunek.

Lepsze podejście polega na zbudowaniu małej biblioteki wzorców promptów dla powtarzalnych zadań. Nie chodzi o setki szablonów. Wystarczy kilka naprawdę praktycznych kategorii.

Wzorzec 1: wyjaśnij i zrozum

To najprostszy typ promptu. Zwykle najlepiej działa w Ask albo czasem w Inline Chat.

Przykłady robocze:

• wyjaśnij, co robi ten fragment #selection
• jak działa autoryzacja w #codebase
• wskaż, gdzie w projekcie konfigurowane jest połączenie z bazą

Co musi zawierać dobry prompt tego typu:

• zakres pytania
• właściwy kontekst
• oczekiwany poziom odpowiedzi, jeśli to ważne

Jeśli chcesz bardziej praktycznej odpowiedzi, możesz dopisać:

• wyjaśnij krok po kroku
• wskaż kluczowe pliki
• podaj ryzyka albo zależności

Wzorzec 2: refaktor lokalny

To idealny kandydat dla Inline Chat albo krótkiego chatu opartego na selection.

Przykład:

• przepisz ten fragment #selection na async/await, zachowując obecne API i styl projektu

Dobry prompt refaktoryzacyjny zwykle zawiera:

• konkretną transformację
• granice zmiany
• ewentualne ograniczenia stylu albo kompatybilności

To ważne, bo bez granic model potrafi przepisać za dużo. Przy refaktorze często nie chcesz „najładniejszego” kodu świata. Chcesz bezpiecznej, lokalnej zmiany.

Wzorzec 3: implementacja wieloetapowa

Jeśli zadanie obejmuje wiele plików, prompt powinien iść w stronę Agenta albo Plan + Agent.

Przykład:

• zaimplementuj logowanie end-to-end w tym projekcie. Najpierw rozpisz plan, potem wykonaj zmiany, a na końcu uruchom testy.

Tu ważne są trzy rzeczy:

• zakres funkcjonalny
• plan i etapy
• weryfikacja na końcu

To jest dokładnie ten typ zadania, w którym sam prompt tekstowy bez agentowego workflow często robi się za słaby.

Wzorzec 4: testy

Docs pokazują dwa bardzo praktyczne wejścia:

• add unit tests for the user service
• fix the failing tests #testFailure

Dobry prompt testowy zwykle warto rozbudować o:

• framework testowy
• zakres testów
• edge case’y
• oczekiwany sposób uruchomienia albo walidacji

Przykład roboczy:

• dodaj testy jednostkowe dla tej usługi #file w Vitest. Pokryj sukces, błąd walidacji i pusty input. Na końcu uruchom testy i pokaż wynik.

To jest dużo lepsze niż samo „napisz testy”, bo od razu ustawia jakość wyniku.

Wzorzec 5: fix błędów i problemów

Tutaj bardzo dobrze działają context items z dokumentacji i cheat sheeta:

• #problems
• #testFailure
• terminal output

Przykłady:

• napraw błędy z #problems
• wyjaśnij, dlaczego ten test pada #testFailure
• @terminal wyjaśnij ten błąd i zaproponuj najbezpieczniejszą naprawę

To jest świetny przykład promptów, które nie muszą być rozbudowane językowo, jeśli mają mocny materiał wejściowy.

Wzorzec 6: dokumentacja i wyjaśnienia

Docs przypominają o slash command /doc, ale warto też umieć napisać zwykły prompt dokumentacyjny.

Przykłady:

• wygeneruj komentarz dokumentacyjny dla tej funkcji #selection
• opisz publiczne API tego modułu i dodaj przykłady użycia
• przygotuj krótkie README dla tego katalogu na podstawie #codebase

Tu szczególnie ważne są:

• format wyjścia
• poziom szczegółu
• odbiorca dokumentacji

Bez tego model może wygenerować coś poprawnego, ale zupełnie nieprzydatnego dla Twojego zespołu.

Wzorzec 7: review i ocena zmian

To wzorzec, który wiele osób pomija, a jest bardzo praktyczny.

Przykłady:

• zrób review tego fragmentu #selection pod kątem edge case’ów i czytelności
• podsumuj #changes i wskaż największe ryzyka regresji
• oceń ten diff pod kątem błędów logicznych i brakujących testów

To bardzo dobry typ promptu, bo pomaga traktować Copilota nie tylko jako generator kodu, ale też jako drugą warstwę oceny.

Wzorzec 8: source control i release notes

#changes to jeden z najbardziej niedocenianych context items.

Przykłady:

• podsumuj #changes
• wygeneruj release notes na podstawie #changes
• zaproponuj commit message dla bieżących zmian

Tu bardzo dobrze widać zaletę dobrych context items. Zamiast ręcznie opisywać, co zrobiłeś, dajesz modelowi realny materiał wejściowy.

Gdzie wchodzą slash commands i smart actions

Cheat sheet dobrze pokazuje, że część zadań ma już krótszą drogę niż pełny prompt tekstowy.

Na przykład:

• /explain
• /fix
• /tests
• /doc

Do tego dochodzą editor context actions i smart actions.

To nie znaczy, że promptowanie przestaje być ważne. To znaczy tylko, że czasem najlepszy „prompt” jest już opakowany w gotową akcję narzędzia.

Dobry workflow polega na tym, żeby nie pisać ręcznie tego, co produkt już potrafi uruchomić szybciej i czyściej.

Jak budować własną bibliotekę promptów

Najlepiej nie kolekcjonować gotowców bez opisu. Lepsza struktura jest taka:

• nazwa zadania
• kiedy używać
• tryb pracy
• obowiązkowy kontekst
• przykładowy prompt bazowy

Na przykład:

• Refactor lokalny
• używaj przy zmianie jednego fragmentu bez wpływu na architekturę
• tryb: Inline Chat
• kontekst: #selection
• prompt bazowy: „Przepisz ten fragment #selection na … zachowując …”

Wtedy budujesz system pracy, a nie folder z losowymi promptami.

Mój praktyczny filtr wyboru wzorca

Zanim napiszesz prompt, odpowiedz sobie na trzy pytania:

1. Jaki jest typ zadania: explain, refactor, fix, tests, review?
2. Jaki tryb pracy najlepiej do niego pasuje?
3. Jaki context item jest obowiązkowy, żeby odpowiedź nie była ogólna?

To zwykle ustawia 80 procent jakości jeszcze przed napisaniem pierwszego zdania.

Ćwiczenie praktyczne

Zbuduj własny mini-zestaw pięciu promptów do codziennej pracy:

1. explain
2. refactor
3. tests
4. fix
5. review

Do każdego dopisz:

• tryb pracy
• obowiązkowy context item
• jedno ograniczenie
• expected output albo sposób weryfikacji

Po tym ćwiczeniu będziesz mieć nie teorię promptowania, tylko własny operacyjny zestaw startowy.

Kluczowe wnioski

• Nie istnieje jeden dobry prompt do wszystkiego; lepiej działa mała biblioteka wzorców zadań.
• Typ zadania powinien prowadzić wybór trybu pracy: Ask, Inline Chat, Agent albo smart action.
• Context items typu #selection, #changes, #problems i #testFailure są często ważniejsze niż dodatkowe akapity opisu.
• Slash commands i smart actions skracają drogę do wielu częstych zadań.
• Najlepsze wzorce promptów to te, które są powiązane z realnym workflow, a nie tylko ładnie brzmią.

Co dalej

Masz już fundament promptowania, więc następnym logicznym krokiem jest wejście w bardziej wyspecjalizowane powierzchnie i automatyzacje, gdzie prompt przestaje być tylko tekstem, a staje się częścią większego workflow narzędziowego.