Najskuteczniejszym i najbardziej niezawodnym przepływem pracy do budowania funkcji z asystentem AI jest metodologia PRD → Plan → Todo. To ustrukturyzowane podejście przekształca wysokopoziomowe wymaganie w szczegółowy plan inżynierski, zapewniając, że Ty i Twój partner AI jesteście doskonale zsynchronizowani przed napisaniem jednej linii kodu.
Ten przewodnik rozbija każdy krok tego podstawowego przepływu pracy, zapewniając powtarzalny proces radzenia sobie z każdym zadaniem programistycznym.
Przepływ pracy przechodzi od wysokopoziomowych potrzeb biznesowych do szczegółowych, wykonywalnych zadań.
1. PRD: źródło prawdy
Wszystko zaczyna się od jasnego wymagania. Może to być formalny dokument wymagań produktu (PRD), historia użytkownika, ticket, a nawet szczegółowy raport błędu. Ten dokument służy jako “źródło prawdy”, które definiuje co i dlaczego zadania.
2. Plan: plan architektoniczny
W tej fazie współpracujesz z AI, aby przełożyć PRD na techniczny plan implementacji. Działasz jako starszy architekt, kierując AI podczas eksploracji bazy kodu, sugerowania podejść architektonicznych i zarysowywania głównych komponentów do zbudowania lub zmodyfikowania.
3. Todo: wykonalna lista kontrolna
Na koniec Ty i AI konwertujecie wysokopoziomowy plan na szczegółową, krok po kroku listę todo. Każdy element tej listy to małe, konkretne zadanie, które można zaimplementować i zweryfikować niezależnie. Ta lista kontrolna staje się scenariuszem, którym AI będzie kierować się podczas fazy wykonania.
Oto jak zastosować przepływ pracy PRD → Plan → Todo w praktyce.
Udostępnij PRD.
Umieść swój PRD lub historię użytkownika w repozytorium projektu, zazwyczaj w katalogu /docs (np. docs/feature-x-prd.md). To ułatwia odwoływanie się do niego.
Dostarcz PRD jako kontekst. Rozpocznij rozmowę z AI, podając mu PRD jako główny kontekst.
I'm starting work on a new feature. Please read the requirements in @/docs/feature-x-prd.md.Najważniejsza zasada tej fazy: powstrzymaj AI od pisania kodu implementacji. Każde nowoczesne narzędzie ma teraz pełnoprawny tryb planowania, który z założenia jest tylko do odczytu, więc nie musisz już błagać modelu, żeby “jeszcze nie kodował”.
Przełącz agenta w tryb Plan (rozwijane menu trybu w polu czatu, lub tryb Ask, jeśli chcesz tylko dyskusji). Tryb Plan bada bazę kodu i proponuje edycje, nie stosując ich, dopóki nie zaakceptujesz. Odwołaj się do PRD przez @docs/feature-x-prd.md, aby plan był osadzony w wymaganiu.
Wpisz /plan, aby wejść w tryb planowania. Claude eksploruje repozytorium w trybie tylko do odczytu i przedstawia plan, który zatwierdzasz, zanim jakikolwiek plik zostanie dotknięty. Nie ma polecenia /think; rozszerzone rozumowanie to osobny przełącznik (Option+T na macOS, Alt+T na Windows/Linux, po uruchomieniu /terminal-setup) lub możesz podnieść poziom wysiłku w /model. Zwróć uwagę, że wpisywanie słów typu “think hard” czy “ultrathink” w promptcie nie przydziela już budżetu na rozumowanie — są traktowane jako zwykłe instrukcje.
Przełącz /plan-mode w TUI Codex dla planowania wieloetapowego, albo uruchom go z piaskownicą tylko do odczytu: codex --sandbox read-only. Umieść trwały kontekst projektu w AGENTS.md w katalogu głównym repozytorium, aby każda sesja Codex automatycznie ładowała Twoje konwencje.
AI wyprodukuje plan, prawdopodobnie sugerując nowe tabele bazy danych, endpointy API i komponenty UI. To najkrytyczniejsza część Twojej roli jako architekta: przejrzyj plan i poddaj go próbie wytrzymałości, zanim jakikolwiek kod zaistnieje.
Kontynuuj tę wymianę zdań, aż będziesz mieć techniczny plan, któremu ufasz. Przeniosłeś myślenie architektoniczne na początek, a to dokładnie to, co powstrzymuje AI przed pognaniem złą drogą podczas implementacji.
Gdy plan jest solidny, poproś AI o przekształcenie go w szczegółową listę kontrolną. Celem są zadania na tyle małe, aby implementować i weryfikować je po jednym na raz.
AI wygeneruje szczegółową listę kontrolną, która wygląda mniej więcej tak:
- [ ] **Database:** Add `is_active` boolean column to `widgets` table (migration + rollback).- [ ] **Backend:** Create a new `GET /api/widgets/:id` endpoint returning the widget with its status.- [ ] **Backend:** Modify `POST /api/widgets` to set `is_active` to `true` on creation.- [ ] **Frontend:** Create a `WidgetStatus` React component that renders the active/inactive badge.- [ ] **Frontend:** Mount `WidgetStatus` on `WidgetDetailsPage`.- [ ] **Tests:** Add an integration test covering the new endpoint and the status toggle.Każde narzędzie następnie inaczej śledzi tę listę, gdy ją wykonujesz:
Trzymaj listę kontrolną w pliku Markdown (na przykład docs/feature-x-todos.md) i odwołuj się do niej przez @. W trybie Agent poproś Cursor, aby przepracował listę z góry na dół i odhaczał elementy w miarę ich ukańczania, a Ty przeglądaj każdy diff, zanim go zaakceptujesz.
Claude Code utrzymuje własną listę todo w ramach sesji i aktualizuje ją, przepracowując zadania wieloetapowe. Wklej swoją listę kontrolną i powiedz “track these as your todos and implement them one at a time, pausing after each for review”.
Codex strumieniuje na żywo plan (turn/plan/updated), z każdym krokiem oznaczonym jako oczekujący, w trakcie lub ukończony, więc możesz obserwować, jak odhacza listę. Trzymaj kanoniczną listę kontrolną w repozytorium i pozwól Codeksowi aktualizować plik w trakcie pracy.
Mając tę szczegółową listę todo, jesteś gotowy, by przejść do faz wykonania i weryfikacji. Przekształciłeś niejasne wymaganie w precyzyjny, wykonalny plan inżynierski, przygotowując swojego partnera AI na płynną implementację.
Nawet z czystym planem trzy tryby awarii pojawiają się wielokrotnie. Każdy ma szybki sposób naprawy.