Użyj jednostronicowego szablonu specyfikacji, aby zamienić niejasny pomysł w klarowne polecenia dla Planning Mode — obejmuje użytkowników, jobs-to-be-done, encje i przypadki brzegowe.
Nieostry pomysł jest w porządku do marzeń. Do budowania — już nie za bardzo.
Jeśli poprosisz AI o „aplikację do śledzenia nawyków” bez dodatkowych szczegółów, będzie musiało zgadywać, co masz na myśli. Te domysły będą się zmieniać z promptu na prompt, więc i aplikacja będzie się zmieniać. Efekt: ekrany nie pasują do siebie, dane są przemianowywane w trakcie budowy, a funkcje pojawiają się, znikają i wracają w innej formie.
Ta niespójność zwykle objawia się w kilku miejscach:
„Planning Mode” to proste zatrzymanie przed budową. Zapisujesz decyzje, które AI inaczej by wymyśliło. Chodzi o spójność: jeden zestaw wyborów, których będą przestrzegać UI, backend i baza danych.
Celem nie jest perfekcja. Chodzi o budowę, którą można iterować bez ciągłego łatania stosu domysłów. Jeśli później zmienisz zdanie, aktualizujesz jedną małą specyfikację i przebudowujesz z tym samym zestawem zasad.
Dlatego jednostronicowy szablon specyfikacji jest ważny. To nie długi PRD ani tygodnie diagramów. To jedna strona, która odpowiada na cztery rzeczy: kim są użytkownicy, co próbują osiągnąć, jakie dane istnieją (prostym językiem) i które przypadki brzegowe lub non-goals powstrzymają pierwszą wersję przed eksplozją.
Przykład: „Aplikacja do rezerwacji” staje się dużo jaśniejsza, gdy zdecydujesz, czy jest dla jednego właściciela salonu, czy dla marketplace, oraz czy klienci mogą zmieniać termin, anulować lub nie pojawić się.
Jednostronicowy szablon specyfikacji to krótka notatka, która zamienia niejasny pomysł w jasne instrukcje. Nie „projektujesz całego produktu”. Dajesz AI wystarczająco dużo struktury, aby za każdym razem podejmować te same decyzje.
Strona ma cztery bloki. Jeśli nie da się zmieścić na jednej stronie, prawdopodobnie masz za dużo funkcji na pierwszą wersję.
Jedna strona wymusza użyteczne ograniczenia. Zmusza do wyboru głównego użytkownika, zdefiniowania najmniejszego udanego przepływu i uniknięcia niejasnych obietnic typu „obsługa wszystkiego”. To właśnie te ograniczenia zapobiegają temu, by aplikacja budowana przez AI zmieniała zdanie między ekranami.
„Wystarczająco dobre” szczegóły wyglądają jak proste, testowalne stwierdzenia. Jeśli ktoś może to przeczytać i zapytać: „Skąd wiemy, że to działa?” — jesteś na właściwym poziomie.
Szybkie kryteria do celowania:
Utrzymuj język prosty. Pisuj linie, które można wkleić bezpośrednio do promptów, np. „Manager może zatwierdzić lub odrzucić prośbę, a wnioskodawca otrzymuje aktualizację statusu.”
Ustaw timer na 20 minut i dąż do „na tyle jasne, aby zbudować”, a nie „doskonałe”. Chodzi o usunięcie domysłów, aby twój AI builder podejmował te same wybory za każdym razem.
Zacznij od jednego zdania odpowiadającego: dla kogo to jest i jaki rezultat uzyskują?
Przykład: „Mobilna aplikacja dla właścicieli psów do śledzenia spacerów i wizyt u weterynarza w jednym miejscu.”
Jeśli nie potrafisz tego ująć w jednym zdaniu, pomysł prawdopodobnie obejmuje dwie aplikacje.
Następnie nazwij 1–3 typy użytkowników jak prawdziwe osoby, nie abstrakcyjne role. „Owner”, „Vet” i „Family member” jest lepsze niż „User A”. Dla każdego dodaj jedną krótką linijkę o tym, na czym najbardziej im zależy.
Potem zapisz 3–7 jobs-to-be-done w formacie: „Kiedy [sytuacja], chcę [akcja], aby [rezultat].” Trzymaj je testowalnymi. „Kiedy kończę spacer, chcę zapisać dystans i notatki, aby zauważyć wzorce” jest jaśniejsze niż „śledzić zdrowie”.
Teraz zdefiniuj encje i kluczowe pola bez żargonu bazodanowego. Pomyśl „rzeczy, które aplikacja pamięta”. Dla aplikacji o psach: Dog (name, age), Walk (date, duration, notes), Visit (date, clinic, cost). Jeśli pole nie jest używane na ekranie lub w zadaniu — pomiń.
Zakończ dwoma krótkimi blokami: edge cases i non-goals. Edge cases są irytujące, ale powszechne („brak internetu”, „dwa psy o tym samym imieniu”). Non-goals to rzeczy, których nie zbudujesz jeszcze („brak płatności”, „brak feedu społecznościowego”).
Na koniec przekonwertuj każdy blok na prompty, które builder może wykonać. Trzymanie struktury (cel, użytkownicy, zadania, encje, edge cases) pomaga systemowi generować ekrany, dane i przepływy, które do siebie pasują.
Jeśli twoja specyfikacja mówi „dla wszystkich”, AI musi zgadnąć, co zbudować najpierw. W jednostronicowym szablonie zdefiniuj użytkowników według intencji (czego chcą dokonać), a nie demografii. Intencja prowadzi do jasnych wyborów dotyczących ekranów, danych i uprawnień.
Nazwij 2–4 typy użytkowników, każdy z jedną główną potrzebą. Dobre przykłady to „Klient składający zamówienie”, „Członek zespołu realizujący zamówienia” i „Manager przeglądający wyniki”. Vague przykłady to „18–35”, „zajęci profesjonaliści” czy „admini” (chyba że opiszesz, czym admini zarządzają).
Używaj tej samej struktury za każdym razem: „Kiedy..., chcę..., aby...”. To utrzymuje aplikację skupioną na rezultatach i daje builderowi stabilne, testowalne wymagania.
Oto realistyczne przykłady JTBD z wyraźnie zdefiniowanym “zrobione”:
Kryteria sukcesu mają znaczenie, bo usuwają dwuznaczność „wygląda dobrze”. Mówią builderowi, co UI musi pozwalać i co backend musi przechowywać.
Nie pisz pełnego planu bezpieczeństwa. Po prostu określ, kto może co robić zwykłym językiem.
Przykład: „Członkowie mogą tworzyć i edytować własne elementy. Managerowie mogą edytować dowolny element i zmieniać status. Właściciele mogą zarządzać użytkownikami i płatnościami.”
Jeśli używasz kroku planowania w narzędziu takim jak Koder.ai, te typy użytkowników, linie JTBD i uprawnienia stają się wiarygodnymi wejściami. Zapobiegają też temu, że AI wynajduje dodatkowe role albo miesza odpowiedzialności między ekranami.
Encje to „rzeczy”, które twoja aplikacja śledzi. Jeśli nazwiesz je jasno, AI builder może stworzyć ekrany, formularze i bazę, które do siebie pasują. To zapobiega niespójnym polom i przypadkowym dodatkom funkcji.
Zacznij od listy podstawowych rzeczowników. Jeśli aplikacja służy do „zarządzania projektami”, twoje rzeczowniki to Project, Task i Comment. Jeśli to „rezerwacja fryzur”, możesz mieć Booking, Service, Customer i Staff.
Dla każdej encji zapisz pola prostym językiem, nie terminami bazodanowymi. Wyobraź sobie, co ktoś wpisałby w formularzu.
Jeśli nie potrafisz wyjaśnić pola w jednym zdaniu, prawdopodobnie to za dużo szczegółów na pierwszą wersję.
Opisz, jak encje się łączą za pomocą prostych zdań:
„Jeden użytkownik może mieć wiele projektów.” „Każde zadanie należy do jednego projektu.” „Komentarz należy do zadania i ma jednego autora.”
To daje builderowi wystarczającą strukturę do generowania spójnych list, stron szczegółowych i filtrów.
Dodaj kilka zasad danych, które unikną bałaganu:
Na koniec ogranicz zakres, nazywając, czego nie będziesz jeszcze przechowywać. Przykład: „Brak załączników w v1” albo „Nie śledź grafików personelu jeszcze, tylko rezerwacje.” Te wyłączenia mają znaczenie, bo zatrzymują aplikację przed rozrastaniem się w złym kierunku.
Jednostronicowy szablon działa najlepiej, gdy pierwsza wersja ma niewielki, stabilny zestaw ekranów. Jeśli spróbujesz zaprojektować każdy ekran, którego aplikacja może potrzebować kiedyś, AI będzie ciągle zgadywać, a UI będzie dryfować między wersjami.
Zacznij od nazwania minimum ekranów, które pozwalają ukończyć główne zadanie. Dla większości MVP wystarczy 3–6 ekranów:
Następnie opisz happy path jako krótką historię od początku do końca.
Przykład: „Użytkownik loguje się, trafia na listę, wyszukuje, otwiera element, edytuje jedno pole, zapisuje i wraca do listy.”
Dla każdego ekranu zanotuj kluczowe akcje prostym językiem. Unikaj ekranów „rób wszystko”. Wybierz 2–4 akcje, które najbardziej się liczą, np. create, edit, search, export, archive.
Zdecyduj też, co musi być szybkie, a co może być „wystarczająco dobre”. „Szybkie” zwykle oznacza: lista otwiera się szybko, wyszukiwanie reaguje od razu, zapis wydaje się natychmiastowy. „Wystarczająco dobre” może być: eksport zajmujący kilka sekund, podstawowa analiza lub oszczędne ustawienia.
Na koniec przypisz role i dostęp w jednym zdaniu na rolę:
To utrzymuje ekrany przewidywalnymi, zapobiega niespodziankom z uprawnieniami i zmniejsza liczbę przeróbek później.
Większość przeróbek dzieje się z jednego powodu: aplikacja działa w happy path, a potem psuje się, gdy pojawia się prawdziwe życie.
Dobra jednostronicowa specyfikacja zostawia miejsce na edge cases i non-goals — ta mała przestrzeń oszczędza godziny pracy.
Zacznij od każdego job-to-be-done i zapytaj: co może pójść nie tak? Trzymaj opis prosty, nie techniczny. Usuwasz w ten sposób niejednoznaczność, więc builder podejmie te same decyzje za każdym razem.
Typowe przypadki brzegowe warte zapisania:
Potem określ reakcję. Bądź konkretny: „Zablokuj akcję i pokaż jasny komunikat”, „Pozwól zapisać jako szkic” albo „Ponów raz, potem pokaż przycisk spróbuj ponownie”. Te reguły przekładają się bezpośrednio na spójne prompt
Dodaj oczekiwania dotyczące prywatności i bezpieczeństwa w jednej lub dwóch linijkach. Na przykład: „Zbieraj minimalne dane potrzebne”, „Użytkownicy mogą usunąć konto i wszystkie dane osobowe”, „Elementy prywatne domyślnie ukryte”. Jeśli aplikacja zawiera treści tworzone przez użytkowników, zapisz, co robić ze zgłoszeniami i spamem, nawet jeśli w v1 będzie to proste.
Na koniec wypisz non-goals, aby zatrzymać rozrost zakresu.
Przykłady jasnych non-goals:
Szybki przykład: jeśli zadaniem jest „Utwórz wydarzenie”, zdefiniuj, co się dzieje, gdy data jest w przeszłości, tytuł jest pusty lub to samo wydarzenie zostanie utworzone dwa razy. Ta jasność zapobiega następnej przebudowie.
Najszybszy sposób na spójne wyniki to przekształcenie każdego bloku specyfikacji w mały, bezpośredni prompt. Traktuj to jak zestaw kart, które builder wykonuje kolejno, zamiast jednego dużego, niejasnego żądania.
Przekonwertuj każdy blok (Users, Jobs, Entities, Screens, Edge cases, Non-goals) na jedną instrukcję z wyraźnymi rzeczownikami i czasownikami. Unikaj opinii typu „zrób to czytelne”, chyba że dodasz, co to znaczy „czytelne”.
Użyj cyklu dwukrokowego: najpierw zbuduj, potem zweryfikuj względem specyfikacji.
Dodaj krótką definicję ukończenia, aby builder wiedział, kiedy przestać. Trzymaj ją mierzalną:
Dodawaj ograniczenia tylko wtedy, gdy naprawdę mają znaczenie: wymagane urządzenia (mobile-first), wymagane uwierzytelnienie (akcje tylko dla admina) lub wymagany stack (np. frontend w React, backend w Go, PostgreSQL), jeśli twoja platforma tego oczekuje.
Gdy chcesz edycji, odwołuj się do bloku specyfikacji, nie do kodu.
Przykład: „Zaktualizuj blok Entities: dodaj ‘Subscription’ z polami X i Y. Potem wygeneruj ponownie tylko dotknięte API i ekrany oraz uruchom krok walidacji.”
Takie podejście utrzymuje plan stabilnym, pozwalając jednocześnie na bezpieczne iteracje.
Wyobraź sobie, że chcesz prosty tracker przypomnień o wizytach dla małego salonu. Celem nie jest pełen system rezerwacji. To lekkie miejsce do przechowywania wizyt i wysyłania przypomnień.
Oto jak wygląda wypełniony jednostronicowy szablon specyfikacji.
APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.
USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.
JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.
ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.
EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments
Teraz przekształć to w pakiet promptów, który możesz wkleić do Planning Mode. Trzymaj się ścisłości, aby builder podejmował te same wybory za każdym razem.
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.
Niechlujne wyniki zwykle zaczynają się od niejasnej specyfikacji i listy życzeń funkcji. AI zrobi to, o co poprosisz, ale nie przeczyta ci w myślach. Małe luki rosną w duże różnice między ekranami i przepływami.
Pułapki, które najczęściej psują spójność — i które naprawia jednostronicowy szablon:
Jeśli używasz Planning Mode w Koder.ai, te podstawy mają jeszcze większe znaczenie, bo plan staje się źródłem powtarzanych promptów. Jasne zadania, mały model danych, wyraźne uprawnienia i testowalne kryteria ukończenia utrzymują wszystkie nowe ekrany zgodne z resztą.
Zanim zaczniesz budować, przejrzyj swoją jednostronicową specyfikację. Celem jest usunięcie dziur, które zmuszają AI do zgadywania. Te domysły prowadzą do przeróbek.
Szybki check:
Jeśli chcesz prosty scoring, oceń każdą sekcję 0–2:
Celuj w co najmniej 7/10 zanim cokolwiek wygenerujesz. Jeśli Entities lub Edge cases są poniżej 2, napraw je najpierw. One powodują najwięcej churnu.
Po pierwszym buildzie sprawdź aplikację względem każdego job-to-be-done i oznacz niezgodności. Rób snapshot przed każdą zmianą. Jeśli nowa iteracja pogarsza sytuację, przywróć i spróbuj mniejszej poprawki.
Jeśli używasz Koder.ai (koder.ai), Planning Mode to praktyczne miejsce, by trzymać tę jednostronicową specyfikację jako „źródło prawdy” i regenerować tylko to, co się zmieniło, zamiast przepisywać wszystko ręcznie.
Aktualizuj spec na bieżąco. Kiedy akceptujesz zmianę w aplikacji, zaktualizuj spec tego samego dnia. Kiedy odrzucasz zmianę, zapisz dlaczego, aby kolejny prompt był spójny.
Planning Mode to krótka przerwa, podczas której zapisujesz kluczowe decyzje przed wygenerowaniem ekranów i kodu. Celem jest spójność: ci sami użytkownicy, te same przepływy i nazwy danych w UI, backendzie i bazie danych, aby nie przebudowywać wszystkiego z powodu nowych domysłów.
Zacznij od jednego zdania z celem, potem wypełnij cztery bloki:
Jeśli nie mieści się na jednej stronie — wytnij funkcje dla v1.
Pozostań praktyczny i opisz według intencji. Nazwij kilka typów użytkowników i to, co chcą osiągnąć.
Przykład: „Owner/Staff, który tworzy wizyty” jest jaśniejsze niż „Admin”. Jeśli nie potrafisz w jednym zdaniu wyjaśnić tej roli, jest prawdopodobnie zbyt ogólna.
Użyj ścisłego wzorca, aby każde zadanie było testowalne:
Dodaj krótką definicję ukończenia (co musi być zapisane/aktualizowane/widoczne). To powstrzymuje buildera przed wymyślaniem dodatkowych kroków lub losowych ekranów.
Wypisz „rzeczy, które aplikacja zapamiętuje” prostym językiem, a każdej daj 3–7 pól, które faktycznie wykorzystasz na ekranach.
Przykład: Appointment: start time, duration, status, service, client. Jeśli pole nie jest używane przez zadanie ani ekran — pomiń je w v1.
Opisz relacje prostymi zdaniami:
Dodaj kilka podstawowych zasad (pola obowiązkowe, unikalne, domyślne). To wystarczy, by utrzymać spójność list, formularzy i filtrów.
Dobrym domyślnym zakresem jest 3–6 ekranów, które pozwolą wykonać główne zadanie end-to-end:
Napisz też jedną „happy path” historię (start → akcja → zapis → potwierdzenie), żeby przepływ nie dryfował.
To właśnie tam realne użycie łamie ścieżkę szczęścia. Wypisz 5–10 najczęstszych:
Dla każdego opisz oczekiwaną reakcję (zablokuj + komunikat, zapisz jako szkic, ponów raz, potem pokaż przycisk).
Przekonwertuj każdy blok na krótką instrukcję, którą builder może wykonać i zweryfikować.
Prosta sekwencja:
Dzięki temu nie polegasz na jednym wielkim, łatwym do źle zrozumienia promptcie.
Zaktualizuj najpierw specyfikację, potem regeneruj tylko zmienione elementy.
Przykład: „Dodaj encję Subscription z polami X i Y; zaktualizuj powiązane ekrany i API; ponownie uruchom walidację.” Utrzymywanie specyfikacji jako źródła prawdy zapobiega rozsianym, niespójnym zmianom.