Inżynieria promptów, czyli jak rozmawiać z AI
Jakość odpowiedzi z Large Language Models zależy bezpośrednio od jakości zadanego pytania. Zasada „garbage in, garbage out” nigdy nie była bardziej aktualna niż w kontekście pracy z AI. Dla analityka i architekta, których praca opiera się na precyzyjnym definiowaniu wymagań i projektowaniu systemów, umiejętność skutecznej komunikacji z AI staje się kluczową kompetencją.
Dobry prompt składa się z czterech elementów:
Persona (Kim jesteś?) – nakazanie AI przyjęcia roli eksperta w danej dziedzinie.
Kontekst (Gdzie jesteśmy?) – dostarczenie niezbędnego tła biznesowego i technicznego.
Zadanie (Co masz zrobić?) – jasne i jednoznaczne polecenie.
Format (Jak ma to wyglądać?) – określenie oczekiwanej struktury odpowiedzi, czy to tabela, lista, User Story czy diagram.
Te cztery filary pozwalają przekształcić ogólne zapytanie w precyzyjne narzędzie pracy.
Prompty dla Analityka Systemowego/Biznesowego
Prompt 1: Generowanie User Story z kryteriami akceptacji
Problem: Szybkie tworzenie dobrze zdefiniowanych historyjek użytkownika na podstawie ogólnego wymagania.
Jesteś doświadczonym Product Ownerem w firmie e-commerce. Na podstawie podanego opisu funkcjonalności stwórz User Story w formacie: "Jako [rola] chcę [cel], aby [korzyść]".
Następnie dodaj kryteria akceptacji w formacie Gherkin (Given/When/Then), uwzględniając:
- Scenariusz pozytywny (happy path)
- Co najmniej 2 scenariusze negatywne
- Scenariusz brzegowy
Dodatkowo określ Definition of Done dla tej historyjki.
Opis funkcjonalności: [WSTAW TUTAJ OPIS]Prompt 2: Identyfikacja pytań do interesariuszy
Problem: Przygotowanie się do warsztatów i upewnienie się, że wszystkie niejasności zostaną wyjaśnione.
Jesteś analitykiem biznesowym przygotowującym się do warsztatu z interesariuszami. Na podstawie opisu funkcjonalności wygeneruj listę pytań pogrupowanych według ról:
1. Product Owner / Biznes (cele biznesowe, metryki sukcesu)
2. Deweloper (szczegóły techniczne, integracje)
3. Tester (przypadki brzegowe, walidacja)
4. UX Designer (przepływ użytkownika, interfejs)
5. DevOps (infrastruktura, bezpieczeństwo)
Każda kategoria powinna zawierać 3-5 konkretnych pytań. Unikaj pytań, na które można odpowiedzieć tak/nie.
Opis funkcjonalności: [WSTAW TUTAJ OPIS]Prompt 3: Generowanie scenariuszy testowych dla przypadku użycia
Problem: Przyspieszenie pracy nad dokumentacją testową poprzez wygenerowanie scenariuszy pozytywnych, negatywnych i brzegowych.
Jesteś test managerem tworzącym plan testów. Na podstawie opisu przypadku użycia stwórz tabelę scenariuszy testowych z kolumnami:
| ID | Typ scenariusza | Opis scenariusza | Dane wejściowe | Oczekiwany rezultat | Priorytet |
Uwzględnij:
- 3-5 scenariuszy pozytywnych (happy path)
- 3-5 scenariuszy negatywnych (błędne dane, brak uprawnień)
- 2-3 scenariusze brzegowe (limity, edge cases)
Priorytet: Wysoki/Średni/Niski
Opis przypadku użycia: [WSTAW TUTAJ OPIS]Prompty dla Architekta Oprogramowania
Prompt 4: Porównanie technologii i rekomendacja
Problem: Szybka analiza i wybór odpowiedniego stosu technologicznego do rozwiązania konkretnego problemu.
Jesteś architektem oprogramowania z 10-letnim doświadczeniem. Porównaj następujące technologie w kontekście podanych wymagań: [TECHNOLOGIA1] vs [TECHNOLOGIA2] vs [TECHNOLOGIA3].
Wymagania niefunkcjonalne:
[WSTAW TUTAJ WYMAGANIA]
Stwórz porównanie w formie tabeli uwzględniającej:
- Wydajność
- Skalowalność
- Łatwość rozwoju (Developer Experience)
- Wsparcie społeczności
- Koszty licencyjne/infrastrukturalne
- Krzywą uczenia dla zespołu
Na końcu wydaj rekomendację z uzasadnieniem biznesowym i technicznym. Wskaż też potencjalne ryzyka wybranej opcji.Prompt 5: Projektowanie kontraktu API (OpenAPI)
Problem: Wstępne zdefiniowanie endpointów i struktur danych dla nowego mikroserwisu.
Jesteś architektem API projektującym RESTowy mikroserwis. Na podstawie opisu logiki biznesowej stwórz fragment specyfikacji OpenAPI 3.0 w formacie YAML.
Uwzględnij:
- Kluczowe endpointy (GET, POST, PUT, DELETE)
- Struktury danych (schemas)
- Kody odpowiedzi HTTP z opisami
- Podstawowe walidacje (required fields, formaty)
- Przykłady request/response
Zastosuj najlepsze praktyki REST API i konwencje nazewnictwa.
Opis logiki biznesowej: [WSTAW TUTAJ OPIS]Prompt 6: Identyfikacja wymagań niefunkcjonalnych (NFR)
Problem: Zapewnienie, że projekt uwzględnia kluczowe aspekty jakościowe, takie jak wydajność, bezpieczeństwo czy skalowalność.
Jesteś architektem systemów z doświadczeniem w projektach enterprise. Na podstawie opisu systemu zidentyfikuj potencjalne wymagania niefunkcjonalne (NFR) pogrupowane według kategorii:
1. Wydajność (response time, throughput, resource usage)
2. Skalowalność (concurrent users, data volume growth)
3. Bezpieczeństwo (authentication, authorization, data protection)
4. Niezawodność (availability, recovery time, fault tolerance)
5. Użyteczność (user experience, accessibility)
6. Utrzymywalność (monitoring, logging, deployment)
Dla każdej kategorii podaj 2-3 konkretne, mierzalne wymagania z przykładowymi wartościami.
Opis systemu: [WSTAW TUTAJ OPIS]Przykład w praktyce: Od promptu do wyniku
Zobaczmy, jak działa w praktyce pierwszy prompt dotyczący User Story:
Krok 1: Gotowy prompt
Jesteś doświadczonym Product Ownerem w firmie e-commerce. Na podstawie podanego opisu funkcjonalności stwórz User Story w formacie: "Jako [rola] chcę [cel], aby [korzyść]".
Opis funkcjonalności: System powiadomień o dostępności produktu - użytkownik może zapisać się na listę oczekujących na produkt, który jest aktualnie niedostępny.Krok 2: Przykładowa odpowiedź AI
User Story:
Jako klient sklepu internetowego chcę otrzymać powiadomienie o dostępności produktu, aby móc go kupić, gdy tylko wróci do sprzedaży.
Kryteria akceptacji:
Scenario: Pomyślne zapisanie się na listę oczekujących
Given jestem zalogowanym użytkownikiem
When kliknę "Powiadom o dostępności" na stronie niedostępnego produktu
Then zostanę dodany do listy oczekujących
And otrzymam potwierdzenie na email
Scenario: Powiadomienie o dostępności
Given jestem na liście oczekujących na produkt
When produkt stanie się dostępny
Then otrzymam email z linkiem do produktu w ciągu 5 minutPodsumowanie
Kluczem jest traktowanie LLM jako partnera w procesie analitycznym i projektowym, a nie jako wyroczni. Przedstawione techniki są uniwersalne i działają równie dobrze z modelami uruchamianymi lokalnie, co jest istotne ze względu na bezpieczeństwo danych firmowych. Warto rozważyć modele open-source jak Llama 3 od Meta za świetną wydajność ogólną, czy Mixtral 8x7B z rodziny Mistral za doskonały stosunek wydajności do zasobów.
Czy w takim razie modele LLM zastąpią analityka bądź architekta. Nie. Podane przykłady, jak i odpowiedzi to wiedza ogólnodostępna. Modele LLM nie napiszą bardzo szczegółowej analizy, nie zaplanują integracji między systemami, o których nic nie widzą. Nawet jak wstawimy opis jakiejś funkcjonalności to pomoc modeli LLM będzie spora ale tak dobra jak nasz opis. LLM to narzędzie. Jego skuteczność zależy od Twojej umiejętności precyzyjnego formułowania myśli i szczegółowej wiedzy dziedzinowej. Naszych głów, pomysłów nic nie zastąpi 🙂
