Workflow PRD w Cursor

Twój PM rzuca wiadomość na Slacku: “Potrzebujemy systemu powiadomień. Email, push, SMS. Preferencje użytkownika. Śledzenie dostarczenia. Możesz to oszacować?” Otwierasz Cursor i zaczynasz pisać kod. Trzy godziny później masz pół serwisu emailowego, brak testów i rosnącą świadomość, że nigdy nie przemyślałeś, jak będą działać potwierdzenia dostarczenia SMS. Workflow PRD-Plan-Todo istnieje właśnie po to, aby temu zapobiec. Zmusza cię do myślenia przed kodowaniem i wykorzystuje tryb Plan w Cursor, aby uczynić to myślenie szybkim i ustrukturyzowanym.

Notatka

Aby zobaczyć pełne omówienie tej metodologii we wszystkich narzędziach, zobacz nasz Kompletny Przewodnik PRD-Plan-Todo. Ten artykuł skupia się na konfiguracji specyficznej dla Cursor i skrótach klawiszowych.

Co Wyniesiesz

• Powtarzalny 3-fazowy workflow: PRD, następnie Plan, następnie Todo — każdy korzysta z innego trybu Cursor
• Skróty specyficzne dla Cursor do przełączania się między trybem Plan a trybem Agent we właściwych momentach
• Szablon PRD, który możesz wkleić do dowolnej nowej rozmowy o funkcji
• Możliwość zapisywania planów do .cursor/plans/ jako referencję dla zespołu i przyszły kontekst

Faza 1: Napisz PRD w Agent Chat

PRD nie musi być 20-stronicowym dokumentem. Musi być na tyle konkretny, aby ty (i AI) zgadzali się co oznacza “gotowe” zanim zostanie napisany jakikolwiek kod.

Otwórz tryb Agent (Cmd+I) i zacznij od poproszenia AI o pomoc w przygotowaniu wymagań.

Prompt do skopiowania do wygenerowania PRD

Muszę zbudować system powiadomień użytkownika z następującymi możliwościami:
- Powiadomienia email przez SendGrid
- Powiadomienia push przez Firebase Cloud Messaging
- SMS przez Twilio
- Zarządzanie preferencjami użytkownika (które kanały są włączone dla każdego typu powiadomienia)
- Śledzenie statusu dostarczenia z callbackami webhook

Pomóż mi napisać PRD dla tej funkcji. Uwzględnij:
1. Historie użytkownika
2. Wymagania funkcjonalne z kryteriami akceptacji
3. Wymagania niefunkcjonalne (wydajność, bezpieczeństwo, skalowalność)
4. Przypadki brzegowe i scenariusze błędów
5. Elementy poza zakresem

Zadaj mi pytania wyjaśniające przed sporządzeniem szkicu, jeśli cokolwiek jest niejednoznaczne.

Kluczowa instrukcja na końcu — “Zadaj mi pytania wyjaśniające” — zapobiega robieniu założeń przez AI. Zapyta o twoją istniejącą infrastrukturę, model uwierzytelniania, konfigurację bazy danych i oczekiwania co do wolumenu. Odpowiedz na te pytania. Każda odpowiedź, którą tu podasz, to kontekst wykorzystywany przez AI do generowania lepszego kodu później.

Lista Kontrolna Jakości PRD

Przed przejściem do Fazy 2 upewnij się, że twoje PRD zawiera:

• Konkretne kryteria akceptacji, nie mgliste cele. “Użytkownicy mogą przełączać email/SMS/push dla każdego typu powiadomienia” nie “użytkownicy zarządzają preferencjami”
• Scenariusze błędów. Co się dzieje, gdy SendGrid nie działa? Gdy numer telefonu jest nieprawidłowy?
• Wymagania niefunkcjonalne. Ile powiadomień na sekundę? Jaka jest akceptowalna opóźnienie dostarczenia?
• Poza zakresem. Wyraźne określenie tego, czego nie budujesz, zapobiega rozszerzaniu zakresu podczas implementacji

Faza 2: Planuj z Trybem Plan

Teraz przełącz się z trybu Agent na tryb Plan. Naciśnij Shift+Tab w polu agenta, aby przełączyć na tryb Plan. Cursor również automatycznie sugeruje tryb Plan, gdy wykryje złożone zadania.

W trybie Plan agent:

1. Zbada twoją bazę kodu, aby zrozumieć istniejące wzorce
2. Zada pytania wyjaśniające o szczegóły implementacji
3. Wygeneruje szczegółowy plan techniczny
4. Poczeka na twoją akceptację przed napisaniem jakiegokolwiek kodu

Prompt do skopiowania do wygenerowania planu implementacji

Na podstawie PRD systemu powiadomień, który właśnie stworzyliśmy, wygeneruj szczegółowy
techniczny plan implementacji. Uwzględnij:

1. Projekt schematu bazy danych (jakie tabele, kolumny, indeksy)
2. Projekt endpointów API (ścieżki, kształty request/response, walidacja)
3. Architektura serwisów (które serwisy, jak się komunikują)
4. Projekt zadań w tle (workery, kolejki, logika ponownych prób)
5. Rozbicie komponentów frontendowych (jeśli dotyczy)
6. Kolejność implementacji z zależnościami między zadaniami
7. Strategia testowania dla każdego komponentu

Odwołaj się do istniejących wzorców w tej bazie kodu, gdzie jest to istotne.

Zapisz Plan

Gdy plan wygląda dobrze, zapisz go w swoim workspace. Kliknij “Save to workspace” w wynikach planu. To zapisuje plan w .cursor/plans/, co służy dwóm celom:

1. Dokumentacja zespołowa — inni programiści mogą przeczytać plan przed sprawdzaniem twojego PR
2. Przyszły kontekst — możesz odwołać się do planu za pomocą @ w późniejszych rozmowach, jeśli musisz wznowić pracę

Iteruj Plan Przed Budowaniem

To jest najbardziej niedoceniany krok. Przejrzyj plan krytycznie:

• Czy kolejność implementacji ma sens? Czy możesz zacząć frontend przed gotowością API, czy istnieje twarda zależność?
• Czy są prostsze alternatywy, które AI pominęło?
• Czy plan jest zgodny z twoją istniejącą architekturą, czy wprowadza nowe wzorce niepotrzebnie?

Edytuj plan w czacie. Powiedz agentowi, co zmienić. Przejdź do Fazy 3 dopiero wtedy, gdy plan jest czymś, co z pewnością przekazałbyś współpracownikowi.

Notatka

Poświęcenie 15 minut na dopracowanie planu oszczędza godziny przeróbek podczas implementacji. Najtrudniejszą częścią jest ustalenie co budować — gdy plan jest solidny, AI sprawnie obsługuje implementację.

Faza 3: Buduj z Listy Todo

Przełącz się z powrotem do trybu Agent (naciśnij Shift+Tab lub wybierz z wybieraka trybów za pomocą Cmd+.). Teraz systematycznie pracuj nad planem.

1. Poproś agenta o utworzenie listy todo z planu

   Przekształć plan implementacji w listę todo w formacie markdown z checkboxami.
   Pogrupuj zadania według fazy. Każde zadanie powinno dać się ukończyć w 1-4 godziny.
   Uwzględnij kryteria akceptacji dla każdego zadania.

2. Zacznij od pierwszego zadania

   Zaimplementujmy pierwsze zadanie: Utwórz migracje bazy danych dla tabel
   powiadomień. Postępuj zgodnie z naszymi istniejącymi wzorcami migracji w src/db/migrations/.

3. Zweryfikuj przed przejściem dalej

   Uruchom migrację i pokaż mi wynikowy schemat.
   Następnie uruchom nasze istniejące testy, aby upewnić się, że nic nie jest zepsute.

4. Commituj przy kamieniach milowych

   Po ukończeniu każdej fazy commituj swoje zmiany. Cursor tworzy checkpointy automatycznie, ale git commity dają ci nazwany, współdzielny punkt przywracania.

5. Odwołuj się do planu dla kontekstu

   Jeśli agent traci z oczu szerszy obraz w długiej rozmowie, rozpocznij nowy czat i odwołaj się do planu:

   @.cursor/plans/notification-system.md
   Ukończyliśmy fazy 1 i 2. Zacznijmy fazę 3: implementację workerów
   dostarczenia. Zacznij od EmailWorker.

Używanie Checkpointów dla Bezpieczeństwa

Cursor tworzy checkpoint przed każdym zestawem zmian, które agent wykonuje. Jeśli zadanie wymyka się spod kontroli:

1. Naciśnij Escape, aby zatrzymać agenta w trakcie wykonywania
2. Kliknij przycisk Restore obok checkpointu w rozmowie
3. Dopracuj swój prompt i spróbuj ponownie

To jest szybsze niż ręczne cofanie plików. Używaj tego agresywnie — nie ma kary za przywracanie checkpointu.

Workflow w Praktyce

Oto jak wygląda prawdziwa sesja, skompresowana:

[Tryb Plan] "Muszę dodać obsługę webhooków Stripe dla zdarzeń subskrypcji.
Nasz istniejący kod płatności jest w src/services/billing/. Wygeneruj plan."

[Tryb Plan] Agent pyta: "Czy chcesz idempotentną obsługę webhooków?
Czy masz już tabelę webhook_logs?"

[Tryb Plan] Odpowiadasz: "Tak dla obsługi idempotentnej. Nie dla tabeli
webhook_logs -- uwzględnij to w planie."

[Tryb Plan] Agent generuje plan z 4 fazami, 12 zadaniami.

Przeglądasz, dostosowujesz kolejność dwóch zadań, zatwierdzasz.

[Tryb Agent] "Zacznij od zadania 1: utwórz migrację webhook_logs."
Agent tworzy migrację, uruchamia ją, pokazuje schemat.

[Tryb Agent] "Zadanie 2: utwórz endpoint webhooka z weryfikacją sygnatury."
Agent implementuje, pisze testy, uruchamia je. Dwa testy nie przechodzą.
Agent naprawia implementację, uruchamia ponownie. Wszystkie zielone.

[Tryb Agent] Powtórz dla pozostałych zadań...

Prompt do skopiowania dla szybkiej sesji PRD-do-budowania

Muszę dodać [opis funkcji]. Przed napisaniem jakiegokolwiek kodu:

1. Zadaj mi 3-5 pytań wyjaśniających o wymagania
2. Gdy odpowiem, utwórz krótkie PRD z kryteriami akceptacji
3. Wygeneruj techniczny plan implementacji
4. Rozbij plan na listę todo

Następnie implementuj każde zadanie jedno po drugim, uruchamiając testy po każdym.
Commituj checkpointy między fazami.

Kiedy To Nie Działa

Plan jest zbyt ogólny: To zwykle oznacza, że twoje PRD brakowało konkretów. Wróć do Fazy 1 i dodaj konkretne kryteria akceptacji, wybory technologiczne i ograniczenia.

Agent odbiega od planu podczas implementacji: Rozpocznij nowy czat, odwołaj się do planu za pomocą @ i daj mu konkretne zadanie z listy todo. Długie rozmowy powodują dryft — krótkie, skoncentrowane rozmowy z wyraźnym kontekstem przynoszą lepsze rezultaty.

Plan nie pasuje do twojej architektury: Agent może dopasować tylko wzorce, które widział. Jeśli twoja architektura jest nietypowa, dodaj regułę projektu ją opisującą (zobacz Reguły Projektu) i wygeneruj plan ponownie.

Zadania trwają dłużej niż szacowano: Lista todo jest przewodnikiem, nie kontraktem. Jeśli zadanie jest większe niż oczekiwano, poproś agenta o rozbicie go na pod-zadania.

Co Dalej

Konfiguracja MCP Połącz Cursor z bazą danych, przeglądarką, GitHub i zewnętrznymi API używając serwerów Model Context Protocol.