Prompt Examples z dokumentacji VS Code - analiza wzorców

Czego się nauczysz

• Jak czytać oficjalne prompt examples jako wzorce intencji, a nie gotowce do ślepego kopiowania
• Co wspólnego mają dobre prompty z różnych kategorii z dokumentacji VS Code
• Jak adaptować official examples do własnego repo i własnego workflow

Oficjalne examples są ciekawe nie dlatego, że są „magiczne”

Najlepszy sposób czytania oficjalnych prompt examples nie brzmi: „o, skopiuję to słowo w słowo”.

Lepsze pytanie brzmi: jaki problem ten prompt rozwiązuje, w jakim trybie działa i które jego elementy naprawdę niosą jakość.

Bo w docsach VS Code bardzo wyraźnie widać jedno: dobre prompty są krótkie, ale stoją za nimi dobre decyzje o intencji, trybie i kontekście.

Kategoria 1: pytania ogólne i technologiczne

Examples typu:

• What is a linked list?
• Provide 3 ways to implement a search feature in React.
• Explain the difference between async/await and promises.

są przypisane do Ask i dobrze pokazują najprostszą intencję: zrozumienie, porównanie, szybkie wyjaśnienie.

Co robią dobrze?

• są proste
• mają jasny cel
• nie udają większego kontekstu, niż faktycznie potrzeba

To ważne, bo nie każdy prompt musi być rozbudowany. Jeśli pytasz o wiedzę ogólną, czasem wystarczy naprawdę krótka forma.

Kategoria 2: eksploracja własnego codebase

Tu examples robią się już ciekawsze:

• Explain how authentication works in #codebase
• Where is the database connection string configured? #codebase
• How do I build this #codebase?

To są świetne przykłady, bo pokazują pierwszy realny skok jakości: to nadal krótkie prompty, ale są osadzone w Twoim repo.

Najważniejszy nośnik jakości nie leży tu w rozbudowanej frazie, tylko w tym, że prompt jest repo-centric i dokłada #codebase.

To warto zapamiętać: czasem jedna dobra referencja do kontekstu robi więcej niż trzy dodatkowe zdania opisu.

Kategoria 3: generowanie i edycja kodu

Docs zestawiają tu ciekawe trio:

• Add a login button and style it based on #styles.css
• Create a meal-planning web app using React and Node.js
• Refactor this code to use async/await

Te przykłady są wartościowe, bo pokazują, że prompt trzeba czytać razem z trybem pracy.

Pierwszy prompt jest dobry, bo:

• ma konkretny cel
• ma kontekst pliku
• sugeruje lokalny zakres zmiany

Drugi jest szerszy i naturalnie prosi się o Agent. Trzeci pasuje do Inline Chat, bo dotyczy konkretnej transformacji kodu w miejscu.

To właśnie jest sedno: ten sam styl promptu może działać lepiej albo gorzej zależnie od powierzchni, na której go odpalasz.

Kategoria 4: testy i jakość

Examples typu:

• Add unit tests for the user service.
• Fix the failing tests #testFailure

pokazują dwie ważne rzeczy.

Po pierwsze, prompt nie musi zawierać całego świata, jeśli ma dobry context item. #testFailure od razu daje materiał wejściowy mocniej zakotwiczony w realnym stanie projektu.

Po drugie, intencja jest bardzo konkretna. Nie ma tu akademickiego opisu jakości kodu. Jest konkretne zadanie z wyraźnym rezultatem.

To świetny przykład promptu, który nie jest długi, ale jest bardzo użyteczny.

Kategoria 5: debugging i fixing issues

Prompt examples rozdzielają tu dwa scenariusze:

• Fix the issues in #problems
• Why is this function returning undefined?

To dobry kontrast.

Pierwszy prompt jest bardziej wykonawczy i prosi się o Agent albo przynajmniej workflow z narzędziami. Drugi jest diagnostyczny i lepiej pasuje do Ask albo Inline Chat, gdy chcesz zrozumieć root cause, zanim zaczniesz naprawę.

Czyli znowu: oficjalne examples uczą nie tylko promptów, ale też doboru trybu pracy.

Kategoria 6: source control i zmiany

Examples z #changes są bardzo nośne praktycznie:

• Summarize the #changes
• Generate release notes based on the #changes

To pokazuje, że dobry prompt często nie opisuje problemu od zera. On korzysta z gotowego context item, który już zawiera właściwy materiał.

To bardzo dobra lekcja dla codziennej pracy. Zamiast pisać długi opis „co zmieniłem”, lepiej czasem po prostu dać Copilotowi #changes.

Kategoria 7: web i zasoby zewnętrzne

Prompt z #fetch do React 18 jest bardzo dobrym przykładem promptu opartego o aktualne źródło.

To ważne, bo pokazuje praktyczny nawyk: jeśli temat dotyczy aktualnej dokumentacji, nie pytaj modelu z pamięci treningowej, tylko dołącz źródło z webu.

Tu jakość promptu bierze się z dwóch rzeczy:

• jasny cel
• aktualny materiał wejściowy

Kategoria 8: multi-turn conversations

To jedna z najciekawszych sekcji docsów, bo dobrze rozbraja mit „idealnego promptu jednorazowego”.

Example REST API pokazuje workflow:

1. stwórz API
2. dodaj walidację i error handling
3. dodaj testy

To nie jest przypadek. To demonstracja sensownego rozbijania problemu na etapy.

Zamiast wciskać wszystko do jednego promptu, budujesz rozmowę krokami. Dzięki temu:

• łatwiej kontrolujesz kierunek
• łatwiej korygujesz błędy wcześnie
• łatwiej oceniasz wynik po każdym etapie

To jest dużo bardziej dojrzały wzorzec niż próba napisania jednego mega-promptu.

Co wszystkie dobre examples mają wspólnego

Jeśli spojrzysz na nie całościowo, powtarza się kilka rzeczy:

• jasna intencja
• właściwy tryb pracy
• dobry context item tam, gdzie jest potrzebny
• prosty język bez ozdobników
• gotowość do follow-upów zamiast próby rozwiązania wszystkiego w jednym strzale

To właśnie trzeba z nich wyciągnąć. Nie konkretne słowa, tylko wzorce decyzji.

Jak adaptować official examples do swojego repo

Najlepszy sposób jest bardzo prosty:

1. zachowaj intencję promptu
2. podmień kontekst na swój realny artefakt
3. dopisz ograniczenia specyficzne dla repo
4. wybierz właściwy tryb: Ask, Inline Chat, Agent

Na przykład:

• zamiast „Explain how authentication works in #codebase” zadaj pytanie o realny obszar swojego repo
• zamiast „Add unit tests for the user service” wskaż konkretny serwis, framework testowy i oczekiwany zakres
• zamiast „Fix the issues in #problems” doprecyzuj, czy chodzi o wszystkie problemy, czy tylko jeden typ błędu

To jest właśnie adaptacja. Nie tłumaczenie jeden do jednego, tylko przeniesienie wzorca na własny projekt.

Ćwiczenie praktyczne

Wybierz trzy oficjalne prompt examples z różnych kategorii:

1. jedno pytanie eksploracyjne
2. jeden prompt do zmiany kodu
3. jeden prompt do testów albo fixów

Przepisz je pod własny projekt i dla każdego zanotuj:

• jaki jest cel
• jaki context item jest kluczowy
• jaki tryb pracy wybrałeś
• czy prompt wymaga follow-upu, czy może działać samodzielnie

Kluczowe wnioski

• Oficjalne prompt examples warto czytać jak bibliotekę intencji, nie jak zestaw zaklęć do kopiowania.
• Najlepsze examples są krótkie, ale dobrze zakotwiczone w trybie pracy i kontekście.
• #codebase, #changes, #problems i #testFailure pokazują, że context item często niesie większą wartość niż dodatkowe akapity opisu.
• Multi-turn conversation to świadomy wzorzec pracy, a nie plan B po nieudanym pierwszym promptcie.
• Adaptowanie examples do własnego repo polega na zachowaniu wzorca, nie na kopiowaniu słów jeden do jednego.

Co dalej

Teraz przechodzimy od analizy wzorców do czegoś jeszcze bardziej praktycznego: własnej biblioteki promptów dla typowych zadań developerskich.