Jak pisać prompty dla narzędzi do budowania aplikacji z AI (z przykładami przed i po)

Dobry prompt dla narzędzia AI do budowania aplikacji opisuje produkt, a nie kod: kto z niego korzysta, co robi krok po kroku, jakie dane przechowuje i kto może co zobaczyć. Gdy pierwsza wersja już istnieje, proś o jedną konkretną zmianę w wiadomości, mów, co ma pozostać takie samo, a problemy opisuj jako „zrobiłem X, spodziewałem się Y, dostałem Z”. Te trzy nawyki naprawiają większość rozczarowujących wyników.

Reszta tego przewodnika pokazuje te wzorce szczegółowo, z przykładami przed i po, które możesz dostosować.

Dlaczego promptowanie narzędzia do budowania aplikacji różni się od rozmowy z AI

Gdy zadajesz pytanie asystentowi czatu, mglisty prompt daje mglistą odpowiedź i idziesz dalej. Gdy promptujesz narzędzie AI do budowania aplikacji, odpowiedzią jest działający program. Każda luka w twoim opisie zostaje wypełniona zgadywaniem, a te zgadywania stają się kodem, tabelami bazy danych i ekranami, z którymi potem musisz żyć albo które musisz cofnąć.

Cel promptu nie polega więc na tym, by brzmieć mądrze. Chodzi o to, by zostawić mniej ważnych decyzji przypadkowi. Nie potrzebujesz do tego języka technicznego. Potrzebujesz być konkretny w sprawach, które wiesz tylko ty: o twoich użytkownikach, przepływie pracy i zasadach.

Co uwzględnić w pierwszym prompcie

Zanim cokolwiek napiszesz, odpowiedz na te pytania. Każde z nich zamyka lukę, którą AI inaczej by zgadywało.

Ostatni wiersz jest niedoceniany. Powiedzenie, czego nie chcesz, powstrzymuje AI przed dodaniem bloga, strony cennika i formularza zapisu do newslettera, o które nikt nie prosił.

Przed i po: pierwszy prompt

Przed:

Zrób mi aplikację dla mojej siłowni.

Narzędzie musi zgadywać wszystko: czy użytkownicy to członkowie, czy personel? Zajęcia grupowe czy indywidualne treningi? Płatności? Dostaniesz coś, co wygląda jak strona siłowni i nie robi tego, czego potrzebujesz.

Po:

Zbuduj aplikację do rezerwacji zajęć dla małego studia jogi. Członkowie widzą zajęcia z tego tygodnia (nazwa, instruktor, godzina, wolne miejsca), rezerwują miejsce i mogą je odwołać do dwóch godzin przed zajęciami. Członkowie rejestrują się e-mailem i hasłem. Właściciel studia loguje się, by dodawać zajęcia, widzieć, kto jest zapisany, i oznaczać obecność. Przechowuj zajęcia, członków i rezerwacje w bazie danych. Spokojny, jasny wygląd, który dobrze działa na telefonach. Na razie bez płatności.

Druga wersja jest nadal krótka. Po prostu odpowiada na pytania z tabeli powyżej.

Opisuj zachowanie, nie implementację

Często lepsze wyniki daje opisanie tego, co powinno się wydarzyć, zamiast tego, jak to zbudować.

Przed:

Dodaj useEffect, który pobiera rezerwacje, i komponent modala do edycji.

Po:

Gdy właściciel kliknie rezerwację, otwórz panel, w którym może zmienić godzinę lub ją anulować. Zmiany mają od razu pojawiać się na liście.

Pierwszy prompt zamyka AI w konkretnej technice, która może nie pasować do sposobu, w jaki zbudowano aplikację. Drugi mówi, jaki ma być efekt, i pozwala wybrać właściwe podejście dla kodu, który już istnieje. Jeśli jesteś programistą i masz silne preferencje, powiedz o nich, ale połącz je z efektem.

Bądź konkretny w zasadach

Zasady biznesowe to miejsce, w którym aplikacje budowane przez AI najczęściej się mylą, bo są oczywiste dla ciebie, a niewidoczne dla AI. Wypisz je wprost.

• Limity: „Członek może mieć najwyżej trzy przyszłe rezerwacje.”
• Terminy: „Anulowanie zamyka się na dwie godziny przed rozpoczęciem zajęć.”
• Przypadki brzegowe: „Jeśli zajęcia są pełne, pokaż przycisk listy oczekujących zamiast Zarezerwuj.”
• Uprawnienia: „Instruktorzy widzą obecność na swoich zajęciach, ale nie innych instruktorów.”

Każda z tych zasad to jedno zdanie. Pominięcie którejkolwiek oznacza, że aplikacja albo jej nie wyegzekwuje, albo wymyśli własną wersję.

Po pierwszej wersji: jedna zmiana w wiadomości

Gdy coś działa w podglądzie, przestań opisywać cały produkt i zacznij prosić o małe zmiany, które da się sprawdzić.

Przed:

Projekt jest nie taki, rezerwacja nie działa jak trzeba i chcę widok kalendarza oraz e-maile.

Po (jako cztery osobne wiadomości):

1. Gdy rezerwuję ostatnie miejsce na zajęciach, zajęcia nadal pokazują „1 miejsce wolne”. Powinny pokazywać „Pełne” i ukrywać przycisk Zarezerwuj.
2. Dodaj na stronie grafiku widok kalendarza tygodniowego, jedna kolumna na dzień. Zostaw obecny widok listy jako opcję.
3. Zrób kafelki zajęć bardziej zwarte na telefonach: mniejsze marginesy, imię instruktora w tej samej linii co godzina.
4. Wyślij członkowi e-mail z potwierdzeniem po rezerwacji.

Dlaczego to działa:

• Każda zmiana jest na tyle mała, że AI może ją poprawnie zrobić za jednym razem.
• Możesz przetestować każdą przed przejściem dalej.
• Jeśli jedna pójdzie źle, możesz cofnąć tylko ten krok, nie tracąc pozostałych.

Powiedz, co zachować

Gdy prosisz o zmianę czegoś, co już działa, powiedz AI, czego nie wolno zmieniać. To najprostszy sposób, by zapobiec regresjom, czyli sytuacjom, w których coś, co działało, przestaje działać po edycji.

Przeprojektuj sekcję główną strony, z większym nagłówkiem i zdjęciem po prawej. Zachowaj nawigację, kolory i wszystko poniżej sekcji głównej dokładnie tak, jak jest.

To samo dotyczy danych: „Dodaj pole numeru telefonu do członków. Nie usuwaj ani nie zmieniaj nazw żadnych istniejących pól.”

Używaj zrzutów ekranu i dokładnego tekstu

Słowa takie jak „ta rzecz na górze” są niejednoznaczne. Większość narzędzi do budowania aplikacji przyjmuje obrazy, a zrzut ekranu z krótką notatką jest szybszy niż akapit opisu.

• Dołącz zrzut ekranu i napisz „przycisk zaznaczony na czerwono nachodzi na menu na telefonach”.
• Wklej dokładny tekst każdego komunikatu o błędzie zamiast parafrazować go.
• Cytuj etykiety z ekranu dokładnie: „przycisk Zapisz zmiany na stronie Ustawienia”.

Przy błędach użyj tego schematu:

Na stronie rezerwacji kliknąłem Anuluj przy rezerwacji na jutro. Spodziewałem się, że zniknie z mojej listy. Zamiast tego nic się nie stało, a po odświeżeniu rezerwacja nadal tam jest. Napraw to i sprawdź, czy anulowanie działa.

Nasz przewodnik o debugowaniu aplikacji zbudowanej przez AI wchodzi w to głębiej.

Przy większych zmianach najpierw plan

Przy wszystkim, co dotyka wielu części aplikacji (dodawanie kont użytkowników do aplikacji, która ich nie miała, dodawanie płatności, zmiana struktury danych), poproś o plan, zanim cokolwiek zostanie zmienione.

Zanim cokolwiek zmienisz, wyjaśnij, jak dodałbyś konta zespołowe: jakie nowe tabele, które strony się zmienią i co stanie się z istniejącymi użytkownikami. Jeszcze nie edytuj kodu.

Przeczytaj plan. Jeśli coś źle zrozumie, poprawienie akapitu jest znacznie tańsze niż poprawianie gotowej funkcji. Wiele narzędzi ma do tego osobny tryb; w Mythex to tryb Plan, obok Build i Ask.

Czego unikać

Co do kluczy API: jeśli potrzebujesz usługi płatności lub e-maila, umieść jej klucze w sekretach projektu, a nie w prompcie. Jeśli to dla ciebie nowość, zobacz czym są zmienne środowiskowe i sekrety.

Wielokrotnego użytku szablony promptów

Dostosuj je, zastępując części w nawiasach.

Nowa aplikacja:

Zbuduj [typ aplikacji] dla [kogo]. Oni [główny przepływ, krok po kroku]. [Drugi typ użytkownika] loguje się, by [co robi]. Przechowuj [dane] w bazie danych. [Wygląd i styl]. Zostaw na później [rzeczy na później].

Nowa funkcja:

Dodaj [funkcję] do [strony]. Gdy [użytkownik] zrobi [działanie], [co ma się stać]. Tylko [kto] może [to zrobić]. Zachowaj [istniejące rzeczy] bez zmian.

Zmiana wyglądu:

Na [stronie] zmień [konkretny element] na [konkretna zmiana]. Zachowaj [co zostawić]. Sprawdź, czy wygląda dobrze na ekranie o szerokości telefonu.

Błąd:

Na [stronie] zrobiłem [kroki]. Spodziewałem się [oczekiwane]. Zamiast tego [faktyczne, plus dokładny tekst błędu]. Napraw to i sprawdź, czy przepływ działa.

Pytanie bez zmian:

Nie zmieniaj żadnego kodu. Wyjaśnij, jak działa [część aplikacji] i gdzie są przechowywane [dane].

Pisanie dłuższej specyfikacji

Przy większych projektach dobrze jest najpierw napisać jednostronicowy brief i wkleić go jako pierwszy prompt: użytkownicy, główne przepływy, dane, zasady i to, co jest poza zakresem. Możesz nawet poprosić AI o pomoc w jego napisaniu; nasz przewodnik jak napisać dokument wymagań produktu z AI pokazuje jak. Ogranicz tylko pierwsze żądanie budowy do podstawowego przepływu i dodawaj resztę krok po kroku.

Promptowanie w Mythex

Wszystko powyżej działa w Mythex. Kilka konkretnych wskazówek, które pomagają:

• Tryby Build, Plan i Ask. Używaj Plan przy dużych lub ryzykownych zmianach, a Ask, gdy chcesz wyjaśnienia bez edycji.
• Punkty kontrolne. Po każdej udanej zmianie Mythex zapisuje punkt kontrolny, a Przywróć do tego punktu przy odpowiedzi cofa projekt. Możesz też edytować wcześniejszą wiadomość i wysłać ją ponownie, aby wypróbować inny prompt od tego miejsca.
• Karta sekretów. Gdy agent potrzebuje klucza API, pyta o niego w karcie w czacie, więc wartość zostaje zapisana jako sekret projektu, a nie wpisana w twojej wiadomości.
• Obrazy. Dołącz zrzuty ekranu lub makiety, a agent je obejrzy.

Dokumentacja zawiera krótką stronę o skutecznych promptach i jedną o iterowaniu bez przebudowy. Jeśli zaczynasz od zera, jak zbudować aplikację z AI przechodzi przez pełny projekt, a jak zaprojektować dobrze wyglądającą aplikację z AI opisuje prompty do dopracowania wyglądu.

Pytania