Lovable lub Bolt utknął w pętli poprawiania błędów? Jak dokończyć MVP

Prosisz narzędzie o naprawę logowania. Działa, ale teraz pulpit jest pusty. Kolejny prompt przywraca pulpit i znowu psuje logowanie. Jeśli Lovable lub Bolt w kółko poprawia te same błędy, następnym sensownym krokiem jest zebranie lepszych dowodów dotyczących jednej awarii. Więcej zmian nie oznacza automatycznie większego postępu.

Dlaczego aplikacja tworzona przez AI utyka w pętli poprawek?

Pętla poprawek powstaje, gdy zmiany usuwają widoczny objaw, ale nie ustalają ani nie testują przyczyny źródłowej. Kilka różnych usterek może dawać ten sam ekran, więc ogólna prośba daje narzędziu zbyt wiele prawdopodobnych rzeczy do zmiany.

Pusty pulpit może oznaczać nieudane żądanie, politykę uprawnień, niewłaściwą bazę danych albo faktycznie brakujące dane. Zmiana komponentu może ukryć komunikat, pozostawiając nieudane żądanie bez zmian. Twoim celem jest ustalenie, która granica zawiodła: przeglądarka, serwer, dostawca uwierzytelniania, baza danych czy zewnętrzna integracja.

Ustal praktyczną zasadę zatrzymania: jeśli ten sam objaw wraca po konkretnej próbie naprawy, przestań powtarzać prompt i zbierz inny rodzaj dowodów. To nawyk roboczy, a nie udokumentowany limit platformy. Chroni mały projekt przed gromadzeniem niepowiązanych zmian, gdy nikt nie potrafi wyjaśnić, co nie działa.

Czy zepsuty jest podgląd w narzędziu, czy Twoja aplikacja?

Zanim zaczniesz przepisywać kod, sprawdź środowisko narzędzia niezależnie od aplikacji. Awaria platformy lub problem z połączeniem podglądu nie dowodzi, że architekturę produktu trzeba wymienić.

Aktualny poradnik Bolt dotyczący problemów z podglądem zaleca sprawdzenie statusu usługi, zebranie błędów z konsoli przeglądarki, wypróbowanie buildu produkcyjnego i przejrzenie brakujących zmiennych środowiskowych. Wyjaśnia też, że wielokrotne wysyłanie tego samego promptu naprawiającego podgląd raczej nie pomoże po pierwszej nieudanej próbie.

Używaj tej tabeli do wyboru kolejnego kroku dochodzenia, a nie do stawiania diagnozy. Nieudane żądanie sieciowe nadal może wynikać z kodu aplikacji, a pusty ekran może mieć kilka przyczyn. Zapisz pierwszy istotny błąd, zanim przykryją go kolejne awarie.

Co zapisać przed kolejną próbą naprawy?

Zachowaj ostatni użyteczny stan kodu i określ, na które dane może wpłynąć naprawa. Historia kodu i kopie zapasowe bazy danych rozwiązują różne problemy z odzyskiwaniem.

Dokumentacja historii wersji Lovable opisuje podgląd, oznaczanie zakładkami i przywracanie wersji kodu. Wprost stwierdza, że przywrócenie kodu nie cofa danych w bazie. Zanim przywrócisz wersję, sprawdź, czy późniejsze prace zmieniły rekordy, uprawnienia lub schemat, którego oczekuje starszy kod.

1. Nazwij ostatni stan, w którym główna ścieżka działała, ze znacznikiem czasu lub identyfikatorem commita.
2. Zapisz obecny błąd i zachowaj przydatne niezatwierdzone zmiany zgodnie z obsługiwanym w projekcie sposobem pracy.
3. Przed pracami zmieniającymi dane lub schemat utwórz odpowiednią kopię zapasową bazy lub bezpieczną kopię testową.
4. Zanotuj, który projekt i które środowisko obsługują prawdziwych użytkowników, aby naprawę można było testować z dala od nich.

Jak wygląda przydatny prompt naprawczy?

Przydatny prompt naprawczy wskazuje jeden powtarzalny błąd, dostarcza odpowiednich dowodów i ogranicza zakres proponowanej zmiany. Poproś o wyjaśnienie przyczyny, zanim zatwierdzisz implementację, której nie potrafisz ocenić.

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

Ten przykład jest hipotetyczny. Zastąp jego szczegóły tym, co faktycznie zaobserwowałeś. Odpowiedź 403 jest wskazówką, że zawiodła kontrola dostępu; nie jest pozwoleniem na usunięcie autoryzacji. Nie umieszczaj haseł, tokenów, connection stringów ani danych klientów w promptach i na zrzutach ekranu.

W projektach Lovable poradnik dotyczący logów backendu wyjaśnia, jak przeglądać żądania i błędy w usługach dostępnych dla projektu. Dopasuj błąd do czasu i środowiska danej akcji. Jeden istotny, oczyszczony wpis jest cenniejszy niż duży, niefiltrowany zrzut logów.

Skąd wiadomo, że naprawa naprawdę zadziałała?

Naprawa działa, gdy pierwotne kroki dają oczekiwany wynik, a ważne sąsiednie ścieżki nadal zachowują się poprawnie. Testuj zapisany stan po odświeżeniu, a nie tylko tymczasowy komunikat o sukcesie.

1. Powtórz pierwotny błąd na nowym koncie i z tymi samymi danymi wejściowymi.
2. Odśwież lub ponownie otwórz aplikację i potwierdź, że wynik został poprawnie zapisany.
3. Powtórz test na drugim zwykłym koncie i sprawdź zamierzone granice własności danych.
4. W bezpiecznym środowisku testowym wypróbuj jeden przypadek błędu, np. nieprawidłowe dane lub przerwane żądanie.
5. Sprawdź sąsiednie ścieżki korzystające ze zmienionego kodu, a następnie uruchom odpowiednie testy projektu i build produkcyjny.

Kiedy zaangażować programistę?

Zaangażuj programistę, gdy nie potrafisz z przekonaniem wyjaśnić ani zweryfikować zmiany w krytycznej ścieżce albo gdy konkretne dochodzenie wciąż nie pozwala wyizolować przyczyny. Szczególnej ostrożności wymagają dostęp do płatności, ujawnianie danych między kontami i powtarzające się zmiany w bazie danych.

Ograniczony przegląd może odpowiedzieć, czy problem dotyczy konfiguracji, drobnej usterki implementacyjnej, czy większego problemu projektowego. Poproś o diagnozę, wskazanie plików lub usług do zmiany, testy akceptacyjne i sposób wycofania zmian. Taki przegląd możesz zlecić, zanim zgodzisz się na przebudowę.

Dobre przekazanie obejmuje adres URL aplikacji, obsługiwany dostęp do projektu lub repozytorium, kroki odtworzenia błędu, krótkie nagranie ekranu, oczyszczony komunikat błędu i ostatnią działającą wersję. Dodaj najbliższy kamień milowy związany z klientami oraz funkcje, których nie wolno ruszać. Dane logowania udostępniaj wyłącznie przez odpowiedni proces udostępniania sekretów lub dostępu do kont.

Co powinno znaleźć się w kolejnym wydaniu?

Kolejne wydanie powinno naprawić mały, mierzalny zestaw niedziałających ścieżek. Prośby o nowe funkcje trzymaj osobno, dopóki te ścieżki nie zostaną przetestowane w opublikowanej aplikacji.

Po naprawie skorzystaj z planu wdrożenia MVP w 12 punktach, aby znaleźć sąsiednie luki. Jeśli aplikacja działa w podglądzie, ale psuje się po publikacji na Replit, użyj checklisty wdrożenia na Replit. Jeśli potrzebujesz praktycznej pomocy, wybierz punkt startowy na stronie Lovable lub Bolt i umów rozmowę. Przynieś niedziałającą ścieżkę; pierwsza rozmowa powinna pomóc określić sensowny następny krok.