Jak debugować aplikację zbudowaną z AI: sprawdzona metoda

Aby debugować aplikację zbudowaną z AI, najpierw celowo wywołaj błąd ponownie, potem zbierz dowody: dokładne kroki, komunikat o błędzie i to, co pokazują konsola przeglądarki i karta sieci, a następnie przekaż to AI w formie „zrobiłem X, spodziewałem się Y, dostałem Z”. Jeśli poprawka pogarsza sprawę, cofnij się do ostatniej działającej wersji zamiast nakładać kolejne poprawki. Żeby to dobrze zrobić, nie musisz czytać kodu.

Ten poradnik omawia całą pętlę, w tym krótki przegląd narzędzi deweloperskich przeglądarki dla osób niebędących programistami.

Pętla debugowania

Każda naprawa błędu, niezależnie od tego, czy robi ją człowiek, czy AI, przebiega według tej samej pętli:

1. Odtwórz — spraw, by błąd pojawiał się w niezawodny sposób.
2. Obserwuj — zbierz komunikat o błędzie i to, co aplikacja robiła.
3. Opisz — podaj AI precyzyjne kroki, oczekiwany wynik i rzeczywisty wynik.
4. Napraw — pozwól AI zmienić jedną rzecz.
5. Zweryfikuj — powtórz dokładnie te same kroki i potwierdź, że problem zniknął i że nic obok się nie zepsuło.
6. Cofnij, jeśli trzeba — jeśli sytuacja się pogorszyła, cofnij zmiany i spróbuj ponownie z lepszymi informacjami.

Większość czasu straconego przy aplikacjach zbudowanych z AI wynika z pominięcia kroków 1, 2 i 5: mówienia „to nie działa”, akceptowania zmiany bez testu, a potem proszenia o kolejną poprawkę na zepsutej już wersji.

Krok 1: Odtwórz błąd

Błąd, który możesz wywołać na życzenie, jest w połowie naprawiony. Spróbuj znaleźć najkrótszy zestaw kroków, który go powoduje.

Zapytaj siebie:

• Czy pojawia się za każdym razem? Jeśli tylko czasem, co jest inne, gdy się pojawia: konkretny rekord, wolne połączenie, wylogowanie?
• Czy dotyczy każdego użytkownika? Zaloguj się na inne konto. Wiele błędów pojawia się tylko u nowych użytkowników bez danych albo u użytkownika z inną rolą.
• Czy występuje na każdym urządzeniu? Wypróbuj ekran o szerokości telefonu i inną przeglądarkę.
• Czy zaczął się po konkretnej zmianie? Jeśli działało wczoraj, ostatnie zmiany są głównymi podejrzanymi.

Zapisz kroki jako krótką, ponumerowaną listę. Później wkleisz ją do promptu.

Krok 2: Przeczytaj komunikat o błędzie

Komunikaty o błędach wyglądają onieśmielająco, ale potrzebujesz tylko kilku ich części.

Nie musisz tego rozumieć; musisz to skopiować dokładnie. Komunikat „Cannot read properties of undefined (reading 'name')” mówi AI, że kod oczekiwał danych (prawdopodobnie rezerwacji lub użytkownika), które nie zostały dostarczone. Parafraza typu „jakiś błąd undefined” gubi tę informację.

Kilka częstych, w przybliżonym tłumaczeniu:

• Błędy undefined / null — kod oczekiwał danych, które nie dotarły. Często chodzi o stan ładowania albo pustą listę, której kod nie obsłużył.
• 404 Not Found — strona lub adres API nie istnieje. Często to literówka w ścieżce albo link do strony, która została przemianowana.
• 401 Unauthorized / 403 Forbidden — żądanie nie było zalogowane albo użytkownik nie ma prawa do tej operacji.
• 500 Internal Server Error — kod serwera się wywalił. Prawdziwy powód jest w logach serwera, a nie w przeglądarce.
• Błędy CORS — przeglądarka zablokowała żądanie do innej domeny. Zwykle to problem z konfiguracją po stronie serwera.

Krok 3: Użyj narzędzi deweloperskich przeglądarki

Każda desktopowa przeglądarka ma wbudowane narzędzia deweloperskie („devtools”). Pokazują, co strona robi za kulisami. W Chrome, Edge i Firefox kliknij prawym przyciskiem w dowolnym miejscu strony i wybierz Zbadaj (Inspect), albo naciśnij F12 (Cmd+Option+I na Macu). W Safari najpierw włącz menu Programowanie w ustawieniach Safari.

Potrzebujesz tylko trzech kart.

Konsola

Karta Konsola (Console) wyświetla błędy i komunikaty z kodu strony. Błędy są pokazywane na czerwono. Jeśli przycisk nic nie robi po kliknięciu, konsola bardzo często pokaże czerwony błąd dokładnie w momencie kliknięcia. Skopiuj pełny tekst błędu (w większości przeglądarek kliknij go prawym przyciskiem, aby znaleźć opcję kopiowania).

Sieć

Karta Sieć (Network) wyświetla każde żądanie, jakie strona wysyła: ładowanie danych, zapisywanie formularza, logowanie. Otwórz ją, a następnie powtórz kroki, które wywołują błąd.

• Szukaj wierszy na czerwono lub ze statusem 400 i wyższym.
• Kliknij nieudany wiersz, by zobaczyć jego Odpowiedź (Response). Błąd serwera często zawiera tam komunikat, bardziej użyteczny niż cokolwiek na ekranie.
• Zanotuj adres URL żądania i kod statusu — zdanie „POST do /api/bookings zwrócił 500” jest bardzo przydatne dla AI.

Zaznacz Preserve log (Zachowaj log), jeśli błąd dotyczy przeładowania strony lub przekierowania, żeby żądania nie zniknęły.

Elementy

Karta Elementy (Elements) lub Inspektor pokazuje strukturę strony i style. Jest najbardziej przydatna przy błędach układu: najechanie na element podświetla jego rozmiar i odstępy. Nie musisz tu niczego edytować; wystarczy napisać „stopka ma 2000 pikseli szerokości na telefonie i wypycha stronę w bok”.

Krok 4: Sprawdź logi serwera

Niektóre błędy dzieją się na serwerze, którego przeglądarka nie widzi. Klasyczny znak to błąd 500 w karcie sieci. Logi serwera, czyli tekstowy wynik działającego backendu, zwykle zawierają prawdziwy błąd wraz ze stack trace (listą funkcji, które działały w chwili awarii).

Gdzie je znaleźć, zależy od narzędzia. W większości narzędzi do budowy aplikacji z AI możesz otworzyć terminal lub widok logów projektu albo po prostu zapytać AI: „Sprawdź logi serwera pod kątem błędów z ostatniego żądania i powiedz, co się nie udało”.

Krok 5: Opisz błąd AI

Zgromadzone informacje ułóż w takim kształcie:

Na stronie Rezerwacje, zalogowany jako członek: kliknąłem Anuluj przy jutrzejszych zajęciach o 9:00. Oczekiwałem: rezerwacja znika, a na zajęciach jest o jedno wolne miejsce więcej. Rzeczywiście: na ekranie nic się nie zmienia. Konsola pokazuje TypeError: Cannot read properties of undefined (reading 'id') w BookingCard.tsx:31, a karta sieci pokazuje, że DELETE /api/bookings/123 zwrócił 500. Znajdź przyczynę, napraw ją i sprawdź, czy anulowanie działa dla członka z jedną rezerwacją i z kilkoma.

Dlaczego każda część ma znaczenie:

• Gdzie i jako kto zawęża problem do jednego ekranu i jednej roli.
• Dokładne kroki pozwalają AI odtworzyć błąd.
• Oczekiwane kontra rzeczywiste określa, co znaczy „naprawione”.
• Tekst błędu i nieudane żądanie wskazują bezpośrednio na przyczynę.
• „Sprawdź, czy…” prosi AI o weryfikację, a nie tylko o edycję.

Jeśli AI dwukrotnie próbowało naprawić błąd bez powodzenia, poproś je, by wyjaśniło przed zmianą czegokolwiek:

Jeszcze nie zmieniaj kodu. Co według Ciebie powoduje ten błąd i jakie dowody to potwierdzają?

Błędną teorię łatwo zauważyć, gdy zostanie zapisana, a skorygowanie jej jest dużo tańsze niż błędna poprawka.

Krok 6: Zweryfikuj i sprawdź sąsiedztwo

Kiedy AI mówi, że naprawiło błąd, powtórz dokładnie kroki z Kroku 1. Następnie sprawdź rzeczy wokół:

• Ta sama akcja dla innej roli użytkownika
• Ta sama akcja bez danych i z dużą ilością danych
• Strony, które współdzielą komponenty z naprawianą
• Ekran o szerokości telefonu, jeśli poprawka dotknęła układu

Zmiany wykonane przez AI czasem naprawiają jedną ścieżkę, a po cichu psują inną. Dwuminutowe sprawdzenie teraz oszczędzi godziny zamieszania później.

Krok 7: Cofnij zamiast nakładać

Jeśli poprawka pogorszyła sprawę albo po trzech rundach nie ma postępu, wróć. Cofnięcie do ostatniej działającej wersji i sformułowanie problemu na nowo z lepszymi dowodami niemal zawsze wygrywa z prośbą o czwartą poprawkę na trzy błędne. Każda nieudana próba zostawia kod, a ten kod myli kolejną próbę.

Dobre nawyki, które ułatwiają cofanie:

• Testuj po każdej zmianie, żebyś wiedział, która zmiana coś zepsuła.
• Utrzymuj małe zmiany: jedna funkcja lub poprawka w jednej wiadomości.
• Zanotuj ostatnią dobrą wersję przed zrobieniem czegoś ryzykownego.
• Jeśli kod jest w Gicie, commituj działające wersje, żebyś mógł do nich wrócić.

Typowe wzorce błędów w aplikacjach zbudowanych z AI

Gdy problem nie jest błędem

Niektóre „błędy” to AI, które buduje dokładnie to, o co je poproszono, a opis był niejednoznaczny. Jeśli poprawka, o którą prosisz, to w rzeczywistości zmiana zachowania, powiedz to wprost: „Zmień tak, żeby…”. Jeśli nie wiesz, jakie zachowanie jest w ogóle poprawne, najpierw to ustal. Nasz poradnik o pisaniu promptów dla narzędzi do budowy aplikacji z AI pokazuje, jak jasno określać reguły. A jeśli przygotowujesz aplikację dla prawdziwych użytkowników, przeniesienie prototypu AI na produkcję omawia sprawdzenia warte wykonania przed startem.

Debugowanie w Mythex

Mythex ma narzędzia do każdego kroku pętli:

• Podgląd do odtworzenia błędu, także w ramce o rozmiarze telefonu.
• /test: agent klika w Twój działający podgląd jak użytkownik i zgłasza zepsute przepływy.
• /fix kieruje agenta konkretnie na uszkodzenia.
• Tryb planu (Plan) pozwala agentowi zbadać sprawę i wyjaśnić ją, zanim cokolwiek zmieni.
• Kod → terminal pokazuje logi serwera Twojej aplikacji.
• Przywróć do tego punktu przy każdej odpowiedzi cofa projekt do tego punktu kontrolnego.

Jeśli publikacja się nie uda, okno publikacji zwykle oferuje Napraw z AI (Fix with AI), które czyta wynik budowania lub logi aplikacji. Zobacz Debug your app oraz Publish troubleshooting w dokumentacji.

Pytania