Jak rozwijać aplikację zbudowaną przez AI, nie psując jej

Aby rozwijać aplikację zbudowaną przez AI bez jej psucia, zmieniaj jedną rzecz na prompt, sprawdzaj ją w podglądzie i zapisuj punkt kontrolny przed przejściem dalej. Opisuj, co widzisz, zamiast tego, co według Ciebie robi kod, planuj duże zmiany, zanim je zbudujesz, a gdy zmiana pójdzie źle, wróć do ostatniej dobrej wersji zamiast prosić AI o naprawienie własnej poprawki.

Pierwsza wersja aplikacji często powstaje w ciągu minut. Trudna jest pięćdziesiąta zmiana, gdy każdy nowy prompt grozi zepsuciem czegoś, co już działało. Ten przewodnik opisuje pętlę, która temu zapobiega.

Pętla iteracji

1. Wybierz jedną zmianę. Jedna funkcja, jeden błąd, jedna strona.
2. Opisz ją w kategoriach tego, co użytkownik widzi i robi.
3. Przy dużych zmianach najpierw zaplanuj. Poproś o plan, przeczytaj go, a potem buduj.
4. Sprawdź wynik w podglądzie — zmianę i przepływy w jej pobliżu.
5. Zapisz punkt kontrolny lub commit.
6. Powtórz.

Każdy krok ma na celu utrzymanie zmian małych i odwracalnych.

Krok 1: Prowadź krótką listę

Zanim wyślesz prompt, zapisz, co chcesz zmienić, w kolejności ważności. Dzięki temu nie wysyłasz jednej wiadomości z dziesięcioma życzeniami naraz, a masz sposób, by powiedzieć „nie teraz" pomysłom, które pojawią się w połowie pracy.

Jeśli zmiana jest duża, rozbij ją. „Dodaj konta zespołowe" staje się: utwórz zespoły, zaproś członka, przełączaj się między zespołami, ogranicz dane do bieżącego zespołu. Każda z tych rzeczy to osobny prompt. Dobrym sposobem na to jest pisanie historyjek użytkownika.

Krok 2: Opisz, co widzisz

AI nie widzi Twojego ekranu, dopóki mu tego nie opiszesz. Wskazuj konkretne rzeczy i mów, co powinno się dziać:

Na stronie cennika w telefonie przycisk karty Pro jest ucięty przy prawej krawędzi. Zachowaj układ na komputerze bez zmian; na ekranach poniżej 640 px ułóż karty jedna pod drugą i ustaw przyciski na pełną szerokość.

Porównaj to z „strona cennika źle wygląda na telefonie". Pierwszy opis można zrealizować i sprawdzić za jednym razem; drugi zaprasza do przeprojektowania, o które nie prosiłeś.

Zrzuty ekranu pomagają. Jeśli Twoje narzędzie przyjmuje obrazy, dołącz jeden i zaznacz problem.

Krok 3: Planuj przed dużymi zmianami

Przy wszystkim, co dotyka kilku części aplikacji — nowy model danych, płatności, role użytkowników — poproś o plan, zanim kod się zmieni:

Nie zmieniaj jeszcze kodu. Chcę, żeby użytkownicy należeli do zespołów i widzieli tylko projekty swojego zespołu. Zaplanuj zmianę: które tabele, strony i trasy API się zmienią, co stanie się z danymi obecnych użytkowników i w jakiej kolejności to zbudować.

Przeczytaj plan. Jeśli jest błędny, poprawienie planu jest znacznie tańsze niż cofanie zbudowanej zmiany.

Krok 4: Powiedz, czego nie wolno zmieniać

Narzędzia AI czasem „porządkują" rzeczy, o które nie prosiłeś. Chroń to, co działa:

Dodaj filtr dat do tabeli zamówień. Nie zmieniaj kolumn tabeli, stylów ani przycisku eksportu.

Reguły obowiązujące wszędzie — kolory marki, ton komunikacji, „nigdy nie usuwaj danych bez potwierdzenia" — zapisz w pliku notatek projektu lub w ustawieniu wiedzy, które AI czyta za każdym razem, zamiast powtarzać je w każdym prompcie.

Krok 5: Sprawdzaj więcej niż samą zmianę

Po każdym prompcie sprawdź:

• Samą zmianę. Czy robi to, o co prosiłeś, na komputerze i w telefonie?
• Sąsiadów. Rzeczy na tej samej stronie oraz przepływy korzystające z tych samych danych.
• Ścieżkę krytyczną. Rejestracja, logowanie, główna akcja, płatność. Trzydziestosekundowe sprawdzenie po każdej dużej zmianie wychwytuje większość uszkodzeń na wczesnym etapie.

Jeśli coś jest nie tak, zgłoś to precyzyjnie — zobacz jak napisać dobry raport o błędzie.

Krok 6: Cofaj się zamiast dokładać

Gdy zmiana coś psuje, a pierwsza poprawka nie działa, zatrzymaj się. Każda kolejna „poprawka" jest budowana na zepsutym stanie, a problemy się piętrzą.

Zamiast tego:

1. Cofnij się do ostatniej wersji, która działała (punkt kontrolny lub commit w Git).
2. Ustal, co było niejasne w prompcie.
3. Spróbuj ponownie z mniejszą lub jaśniejszą prośbą.

Ta zmiana zepsuła zapisywanie szkiców. Cofnąłem się. Tym razem: dodaj tylko wskaźnik automatycznego zapisu jako tekst w nagłówku. Nie zmieniaj sposobu zapisywania szkiców.

Krok 7: Wiedz, kiedy przebudowa jest słuszna

Budowanie od zera wyrzuca wiele działających szczegółów. Warto to zrobić tylko wtedy, gdy:

• Idea produktu całkowicie się zmieniła.
• Podstawowa struktura nie udźwignie tego, czego teraz potrzebujesz — na przykład została zbudowana jako statyczna strona, a teraz potrzebuje kont i bazy danych.
• Projekt jest wciąż blisko pustego.

Jeśli przebudowujesz, wypisz, co zachować: nazwę, kolory, teksty, części, które użytkownikom się podobały.

Przykładowe prompty

Zanim przejdziemy dalej, podsumuj, jak aplikacja działa teraz: strony, dane, które przechowuje, i to, co Twoim zdaniem jest kruche.

Chcę dodać powtarzające się rezerwacje. Jaka jest najmniejsza wersja, która byłaby użyteczna? Zaproponuj ją jako trzy osobne zmiany, które wprowadzimy jedna po drugiej.

Przejrzyj ostatnie trzy zmiany pod kątem tego, czy mogły zepsuć przepływ płatności. Na razie nic nie edytuj.

Częste błędy

• Dziesięć próśb w jednym prompcie. Część zostanie zrobiona, część w połowie, a Ty nie będziesz wiedzieć, która.
• Niejasne uwagi. „Jest zepsute" albo „zrób to lepiej" daje zgadywanie.
• Nigdy nie sprawdzanie sąsiadów. Zmiana we wspólnym komponencie psuje trzy inne strony.
• Poprawianie poprawek. Gdy jesteś cztery prompty w głąb błędu, cofnij się.
• Powtarzanie kontekstu za każdym razem zamiast trzymania stałych zasad w notatkach projektu.
• Przebudowa, gdy utkniesz. Większość momentów „zacznij od nowa" to tak naprawdę „cofnij się o dwa kroki".

Lista kontrolna

• Jeden cel na prompt.
• Opisuję, co widzę i co powinno się dziać.
• Duże zmiany mają plan przed jakimkolwiek kodem.
• Mówię, czego nie wolno zmieniać.
• Po każdej zmianie sprawdzam ją, jej sąsiadów i ścieżkę krytyczną.
• Zapisuję punkt kontrolny lub commit po każdej działającej zmianie.
• Gdy poprawka się nie udaje, cofam się zamiast nakładać poprawki.
• Stałe zasady są w notatkach projektu, które AI czyta za każdym razem.

Rozwijanie aplikacji w Mythex

Mythex jest zbudowany wokół tej pętli:

• Tryby Plan, Build i Ask. Plan omawia podejście przed edycją; Ask odpowiada bez zmiany kodu; Build wprowadza zmianę. Zobacz Czat.
• Punkty kontrolne. Po każdej udanej turze Mythex zapisuje punkt kontrolny Git; Przywróć do tego punktu cofa zmiany. Możesz też edytować wcześniejszą wiadomość i użyć Odrzuć i wyślij ponownie, by wypróbować inny prompt od tego miejsca. Zobacz Rozwijanie bez przebudowy.
• Wiedza. Ustawienia projektu → Wiedza przechowują stałe notatki, których agent przestrzega przy każdej wiadomości.
• /test każe agentowi kliknąć przez podgląd jak użytkownik po dużej zmianie.

Mniejsze prośby kosztują też mniej kredytów. Jak pisać same prompty, zobacz jak pisać prompty dla narzędzi do budowy aplikacji AI; gdy coś się zepsuje, jak debugować aplikację zbudowaną przez AI.

Pytania