Anatomia dobrego promptu w GitHub Copilot | Kurs GitHub Copilot

Czego się nauczysz

Z jakich elementów składa się skuteczny prompt w Copilot
Dlaczego cel, kontekst, ograniczenia i expected output dają większy zysk niż „sprytne” sformułowania
Jak poprawiać prompty iteracyjnie zamiast pisać od zera coraz dłuższe akapity

Dobry prompt nie musi być długi. Musi być użyteczny

Wokół promptowania łatwo zbudować zły obraz.

Ludzie szukają magicznych formułek, specjalnych zaklęć i egzotycznych tricków językowych. Tymczasem aktualne docs VS Code pokazują coś dużo prostszego: najlepsze wyniki zwykle biorą się z jasności zadania, dobrego kontekstu i rozsądnych kryteriów weryfikacji.

Czyli nie chodzi o to, żeby prompt brzmiał efektownie. Chodzi o to, żeby model wiedział:

co ma zrobić
na czym ma pracować
czego ma nie robić
po czym poznać, że wynik jest dobry

To jest właśnie praktyczna anatomia promptu.

Element 1: jasny cel

Najczęstszy błąd to prompt, który nie mówi, jaki problem naprawdę rozwiązujesz.

Przykład zły:

popraw to
zrób to lepiej
ogarnij ten kod

Takie prompty nie mówią praktycznie nic. „Lepiej” może oznaczać wydajniej, czytelniej, bezpieczniej, z mniejszą złożonością albo po prostu z innym formatowaniem.

Docs mówią wprost: avoid vague prompts.

Lepsza wersja celu brzmi raczej tak:

zredukuj złożoność czasową tej funkcji
dodaj walidację nulli i pustych wejść
przepisz ten fragment na async/await

To jest pierwsza rzecz, która robi różnicę.

Element 2: właściwy kontekst

Sam cel nie wystarcza, jeśli model nie widzi materiału roboczego.

W poprzednim module było już jasno: context is everything the model can see. Dlatego dobry prompt bardzo często potrzebuje jawnego kontekstu przez:

#file
#selection
#codebase
#changes
#problems
#testFailure
URL albo #fetch

Najlepszy prompt bez kontekstu nadal może dać odpowiedź ogólną. Przeciętny prompt z właściwym kontekstem bardzo często daje wynik o wiele lepszy.

To ważne, bo wiele osób przecenia warstwę językową, a niedocenia danych wejściowych.

Element 3: ograniczenia

To jest rzecz, którą bardzo warto przejąć z docs best-practices.

Prompt powinien umieć powiedzieć nie tylko „co zrób”, ale też „w jakich granicach to zrób”.

Na przykład:

użyj TypeScriptu
nie używaj regexu
zachowaj obecne API publiczne
nie zmieniaj nazw klas
nie dotykaj testów integracyjnych

To właśnie ograniczenia pomagają modelowi nie rozlewać się w złym kierunku.

Jeśli ich nie podasz, Copilot może zaproponować technicznie sensowne rozwiązanie, które po prostu nie pasuje do Twojego repo albo Twojego celu.

Element 4: expected output i kryteria weryfikacji

To jest jedna z najmocniejszych porad w oficjalnych docsach.

Jeśli tylko możesz, podaj expected output, acceptance criteria albo testy wprost w promptcie.

Przykłady:

ta funkcja ma zwracać true dla takich danych i false dla takich
po zmianie testy X i Y mają przejść
wygeneruj wynik w formie listy kroków, a nie kodu
na końcu uruchom testy i potwierdź wynik

To ogromnie poprawia jakość, bo model nie tylko generuje rozwiązanie, ale ma też punkt odniesienia do oceny, czy faktycznie dowiózł zadanie.

W praktyce to jeden z najwyżej opłacalnych elementów promptu.

Element 5: wybór właściwego trybu pracy

Best practices przypominają o czymś bardzo ważnym: prompt nie istnieje w próżni. Ten sam prompt zadziała inaczej zależnie od trybu.

Ask do pytań i eksploracji
Inline Chat do lokalnych zmian
Agent do zadań wieloetapowych
Plan do rozpisania implementacji

To oznacza, że dobry prompt zawiera nie tylko treść, ale też dobrą decyzję: gdzie go uruchomić.

Prompt „refactor this code to use async/await” ma sens w Inline Chat. Prompt „implement feature end-to-end and run tests” prosi się już o Agent. Prompt „how does authentication work in this project?” naturalnie pasuje do Ask.

Zły wybór trybu potrafi zepsuć nawet całkiem dobry prompt.

Dobra robocza rama promptu

Jeśli chcesz mieć prosty szablon, zapamiętaj tę kolejność:

Cel
Kontekst
Ograniczenia
Expected output albo kryteria weryfikacji

Na przykład:

„Dodaj walidację wejścia do tej funkcji #selection. Zachowaj obecne API i nie używaj zewnętrznych bibliotek. Na końcu pokaż finalny kod i opisz dwa edge case’y, które obsługujesz.”

To nie jest literacko piękny prompt. Ale jest bardzo użyteczny.

Nie próbuj rozwiązywać wszystkiego w jednym strzale

Docs bardzo słusznie podkreślają: break down complex tasks.

To znaczy, że przy większych zadaniach lepiej rozbić pracę na etapy:

najpierw zrozumienie problemu
potem plan
potem implementacja
potem testy i review

To daje lepszą kontrolę i zmniejsza ryzyko, że model rozwiąże nie ten problem, który naprawdę masz.

W praktyce wiele słabych wyników wynika nie z kiepskiego modelu, tylko z promptu, który próbuje upchnąć pięć różnych intencji naraz.

Follow-up jest częścią promptowania, nie ratunkiem po porażce

To ważna zmiana myślenia.

Wiele osób zakłada, że dobry prompt powinien załatwić wszystko jednym strzałem. Oficjalne docs pokazują jednak coś innego: iterate with follow-up prompts.

Czyli dobry workflow wygląda często tak:

dajesz sensowny pierwszy prompt
oceniasz kierunek odpowiedzi
doprecyzowujesz ograniczenia albo expected output
korygujesz wcześnie, zanim model pojedzie za daleko

To jest dojrzalszy sposób pracy niż próba napisania jednego gigantycznego promptu idealnego.

Powiedz modelowi, żeby zadał pytania

To jedna z najmocniejszych porad z best-practices i jednocześnie jedna z najrzadziej używanych.

Jeśli zadanie jest niejednoznaczne, napisz wprost:

jeśli czegoś brakuje, zadaj pytania przed implementacją
nie zgaduj wymagań, tylko dopytaj

To jest znacznie lepsze niż potem poprawianie rozwiązania zbudowanego na złych założeniach.

Mój praktyczny filtr dobrego promptu

Zanim wyślesz prompt, sprawdź cztery rzeczy:

czy cel jest jednoznaczny
czy model widzi właściwy kontekst
czy ograniczenia są jasne
czy wiadomo, jak zweryfikować wynik

Jeśli na któreś z tych pytań odpowiadasz „w sumie nie”, prompt zwykle jeszcze warto poprawić.

Ćwiczenie praktyczne

Weź słaby prompt w stylu:

„make this better”

I przepisz go do wersji roboczej z czterema elementami:

doprecyzuj cel
dołącz kontekst przez #selection albo #file
dodaj ograniczenia
dopisz expected output albo kryteria weryfikacji

Potem porównaj obie odpowiedzi i oceń:

która szybciej przechodzi do konkretu
która mniej zgaduje
która daje wynik łatwiejszy do zaakceptowania albo odrzucenia

Kluczowe wnioski

Dobry prompt nie musi być długi, ale musi jasno określać cel.
Kontekst jest równie ważny jak sama treść promptu.
Ograniczenia chronią przed odpowiedzią technicznie poprawną, ale niepasującą do zadania.
Expected output i kryteria weryfikacji dają modelowi punkt odniesienia.
Follow-up i doprecyzowanie to normalna część promptowania, nie oznaka porażki.

Co dalej

Skoro znasz już anatomie skutecznego promptu, pora zobaczyć, jak te zasady wyglądają w oficjalnych examples z dokumentacji VS Code i co dokładnie robią dobrze.