Jak przenieść prototyp AI do produkcji

Żeby przenieść prototyp AI do produkcji, zamykasz lukę między „działa, kiedy go wypróbuję” a „działa nadal, gdy korzystają z niego inni ludzie”. W praktyce oznacza to pięć rzeczy: testować główne ścieżki przy każdej zmianie, zabezpieczyć, kto może zobaczyć i zmienić co, upewnić się, że dowiesz się o błędach, zanim powiedzą ci o nich użytkownicy, wykonywać kopie zapasowe danych i sprawdzić, że da się je przywrócić, oraz utrzymać aplikację na tyle szybką, by działała na telefonie. Żadna z tych rzeczy nie wymaga przepisania od nowa — to lista kontrolna, którą przechodzisz z tym samym AI, które zbudowało prototyp.

Prototyp kontra produkcja: co naprawdę się zmienia

Prototyp ma jednego ostrożnego użytkownika: ciebie. Wiesz, które przyciski nacisnąć, wpisujesz sensowne dane, a gdy coś się zepsuje, wzruszasz ramionami i prosisz AI o naprawę. Produkcja ma wielu nieostrożnych użytkowników, kilku ciekawskich i od czasu do czasu wrogiego. Kod nie musi stać się „klasy enterprise”; musi obsłużyć sytuacje, których prototyp nigdy nie napotyka.

Reszta przewodnika omawia każdy z tych wierszy.

Krok 1: Zamroź zakres i spisz główne ścieżki

Zanim cokolwiek utwardzisz, zdecyduj, czym jest wersja pierwsza. Wypisz od trzech do sześciu ścieżek, które mają największe znaczenie — na przykład „rejestracja, utworzenie projektu, zaproszenie współpracownika, płatność”. Staną się one twoim skryptem testowym, celami monitoringu i tym, co sprawdzasz po każdej zmianie.

Wszystko, czego nie ma na liście, albo zostanie wycięte, albo wyraźnie oznaczone jako beta. Dużo łatwiej sprawić, by cztery ścieżki działały niezawodnie, niż czternaście.

Krok 2: Testuj jak obcy użytkownik, a potem uczyń to powtarzalnym

Narzędzia do budowy przez AI dobrze tworzą kod, który działa w sytuacji idealnej. Problemy produkcyjne żyją na niesprzyjających ścieżkach. Testuj każdą główną ścieżkę pod kątem:

• Błędnych danych wejściowych: puste wymagane pola, imię o długości 5000 znaków, e-mail bez @, ujemna ilość, data z przeszłości.
• Odświeżania i przycisku wstecz: przeładuj stronę w połowie płatności; naciśnij wstecz po wysłaniu formularza. Czy coś zostaje utworzone dwukrotnie?
• Dwóch kart, dwóch użytkowników: zaloguj się na dwa różne konta i spróbuj otworzyć strony drugiego użytkownika, zmieniając ID w adresie URL.
• Wolno i mało: ekran wielkości telefonu i ograniczone połączenie (narzędzia deweloperskie przeglądarki mogą je zasymulować).
• Stany puste: świeżo założone konto bez danych. Prototypy często są budowane na przykładowych danych i bez nich wyglądają na zepsute.

Następnie uczyń tę kontrolę powtarzalną. Co najmniej prowadź spisaną listę kontrolną i uruchamiaj ją przed każdym wydaniem. Lepiej poprosić AI o automatyczne testy dla najważniejszych ścieżek:

Dodaj automatyczne testy end-to-end dla tych ścieżek: rejestracja e-mailem, utworzenie projektu, zaproszenie drugiego użytkownika i dokończenie płatności w trybie testowym Stripe. Dodaj też testy potwierdzające, że użytkownik nie może zobaczyć ani edytować projektu innego użytkownika, zmieniając adres URL.

Testy, które dowodzą, że użytkownik nie może czegoś zrobić, to właśnie te, których prototypom najczęściej brakuje.

Krok 3: Podstawy bezpieczeństwa, które prototypy pomijają

Większość problemów z bezpieczeństwem w aplikacjach budowanych przez AI nie jest egzotyczna. To brakujące sprawdzenia. Przejdź przez tę listę i zobacz szerszą listę kontrolną bezpieczeństwa dla aplikacji budowanych przez AI:

• Autoryzacja po stronie serwera. Ukrycie przycisku to nie bezpieczeństwo. Każde żądanie, które odczytuje lub zmienia dane, musi sprawdzić po stronie serwera, czy zalogowany użytkownik ma do tego prawo. Jeśli twoja aplikacja używa bazy danych z regułami na poziomie wierszy, sprawdź, czy są włączone i przetestowane.
• Sekrety poza przeglądarką. Klucze API do płatności, e-maila lub dostawców AI należą do zmiennych środowiskowych po stronie serwera, nigdy do kodu frontendu. Jeśli nie wiesz, co to oznacza, przeczytaj czym są zmienne środowiskowe i sekrety.
• Walidacja po stronie serwera. Przeglądarkę można ominąć, więc powtórz na serwerze każde ważne sprawdzenie.
• Logowanie wykonane poprawnie. Użyj dobrze przetestowanej biblioteki lub usługi uwierzytelniania zamiast własnego przechowywania haseł. Nasz przewodnik jak dodać logowanie do aplikacji opisuje opcje.
• Limity żądań (rate limits) dla logowania, rejestracji, resetu hasła i wszystkiego, co wysyła e-mail lub wywołuje płatne API.
• Przyjazne błędy. Użytkownicy powinni widzieć „coś poszło nie tak”; szczegóły trafiają do twoich logów, a nie na ekran.
• Wymiana wszystkiego, co wyciekło. Jeśli żywy klucz został kiedykolwiek wklejony do czatu, commita lub zrzutu ekranu, wymień go u dostawcy.

Prompt, który obejmuje sporo naraz:

Sprawdź tę aplikację pod kątem bezpieczeństwa produkcyjnego. Upewnij się, że każda trasa API weryfikuje, czy zalogowany użytkownik jest właścicielem rekordu, który odczytuje lub zmienia, że żadne klucze sekretne nie są wysyłane do przeglądarki, że dane wejściowe są walidowane po stronie serwera i że logowanie oraz reset hasła mają limit żądań. Przed zmianami wypisz, co znalazłeś.

Poproszenie najpierw o listę pozwala zobaczyć problemy i zdecydować o kolejności, zamiast dostać jedną gigantyczną zmianę.

Krok 4: Wiedz, kiedy coś się psuje — logowanie i monitoring

W podglądzie widzisz błędy w chwili ich pojawienia się. Na produkcji aplikacja musi cię o nich informować. Trzy warstwy, od najtańszej do najbardziej użytecznej:

1. Logi serwera. Upewnij się, że błędy są zapisywane z wystarczającym kontekstem, by je odtworzyć: która trasa, identyfikator użytkownika (nie hasło ani dane karty), jaki kształt danych wejściowych. Jeśli aplikacja tylko wypisuje dane w konsoli, poproś AI o ustrukturyzowane logowanie.
2. Śledzenie błędów. Usługa taka jak Sentry lub podobne narzędzie wychwytuje wyjątki frontendu i backendu, grupuje je i wysyła ci e-mail. Przy małej aplikacji darmowe plany tych usług często wystarczają; sprawdź aktualne limity na ich stronach.
3. Kontrole dostępności. Zewnętrzna usługa, która co kilka minut ładuje twoją stronę główną i jedną kluczową trasę API i alarmuje, gdy się nie uda. Wychwytuje to problemy, które w ogóle uniemożliwiają logowanie.

Dodaj jeszcze jeden nawyk: po każdym wydaniu otwórz działającą aplikację i przejdź listę głównych ścieżek na prawdziwym adresie URL, a nie tylko w podglądzie.

Krok 5: Kopie zapasowe i droga powrotna

Trzeba chronić dwie różne rzeczy i łatwo je pomylić.

• Kod. Trzymaj projekt w systemie kontroli wersji, żeby każdą zmianę dało się cofnąć. Wiele narzędzi AI zapisuje punkty kontrolne twoich plików; synchronizacja z repozytorium Git daje ci kopię poza narzędziem.
• Dane. Cofnięcie kodu nie cofa bazy danych. Błędna migracja lub przycisk usuwania z błędem mogą zniszczyć wiersze, których żaden punkt kontrolny kodu nie przywróci.

W przypadku danych ustaw regularne kopie zapasowe przechowywane w innym miejscu niż hosting aplikacji — dla bazy Postgres typowym rozwiązaniem jest zaplanowany pg_dump do osobnego magazynu, a wiele zarządzanych hostów baz danych oferuje automatyczne kopie lub odzyskiwanie do wybranego punktu w czasie. Następnie wykonaj krok, który większość pomija: przywróć kopię do roboczej bazy danych i sprawdź, czy dane tam są.

Poproś też AI o zabezpieczenie destrukcyjnych operacji: krok potwierdzenia przy usuwaniu oraz „miękkie usuwanie” (oznaczanie wierszy jako usuniętych zamiast ich kasowania) dla wszystkiego, co użytkownicy mogliby chcieć odzyskać.

Krok 6: Wydajność, która wytrzymuje na telefonie

Prototypy wydają się szybkie, bo jesteś jedynym użytkownikiem, a zbiór danych jest mały. Przed startem:

• Załaduj dane w realnej skali. Poproś AI o wygenerowanie kilku tysięcy wierszy i sprawdź, które strony zwalniają. Listy zwykle potrzebują paginacji, a baza danych zwykle potrzebuje indeksów na kolumnach, po których filtrujesz i sortujesz.
• Zmniejsz obrazy. Zbyt duże obrazy to najczęstszy powód wolno ładującej się strony. Poproś o obrazy przeskalowane, skompresowane i ładowane leniwie (lazy loading) poniżej linii przewijania.
• Mierz. Uruchom Lighthouse w narzędziach deweloperskich Chrome na żywym adresie URL w trybie mobilnym. Rozsądnym celem są Core Web Vitals Google: Largest Contentful Paint poniżej 2,5 sekundy, Interaction to Next Paint na poziomie 200 ms lub mniej i Cumulative Layout Shift równy 0,1 lub mniej.
• Uważaj na opóźnienia „wybudzania”. Hosting, który usypia, gdy jest bezczynny, oszczędza pieniądze, ale sprawia, że pierwsza wizyta po cichym okresie jest wolniejsza. Dla nowej aplikacji to często rozsądny kompromis; wiedz, że tak się dzieje.

Strona projektów jest wolna przy 5000 wierszach. Dodaj paginację po stronie serwera (25 na stronę), dodaj indeksy bazy danych dla kolumn, po których filtrujemy i sortujemy, i pokaż stan ładowania, gdy ładuje się następna strona.

Krok 7: Podstawy operacyjne

Kilka drobnych rzeczy oddziela aplikację hobbystyczną od takiej, której ludzie ufają:

• Własna domena z HTTPS. Zobacz jak podłączyć własną domenę.
• E-mail transakcyjny z zweryfikowanej domeny do potwierdzeń rejestracji i resetów hasła — opisany w jak wysyłać e-maile z aplikacji.
• Polityka prywatności i regulamin, które opisują, co faktycznie zbierasz. Nie kopiuj deklaracji o zgodności, na które nie zasłużyłeś.
• Kanał wsparcia — nawet monitorowany adres e-mail.
• Oddzielne klucze testowe i produkcyjne do płatności i e-maila oraz jasna notatka, które środowisko używa których.

Krok 8: Czyste przekazanie projektu

Prędzej czy później nad aplikacją będzie pracować ktoś inny: freelancer, nowy współzałożyciel albo ty za pół roku. Ułatw to:

• README, które mówi, jak uruchomić aplikację, jakich zmiennych środowiskowych potrzebuje (tylko nazwy, nigdy wartości) i jak ją wdrożyć.
• Lista kontrolna głównych ścieżek oraz automatyczne testy.
• Krótka notatka o architekturze: frontend, backend, baza danych, usługi zewnętrzne i gdzie każda z nich jest hostowana.
• Lista dostępów: kto ma uprawnienia administratora do domeny, hostingu, bazy danych, kont płatności i e-maila. Trzymaj te konta pod firmowym adresem e-mail, a nie prywatnym.
• Kod w Git, najlepiej zsynchronizowany z repozytorium, które posiadasz. Jeśli możesz później zmienić hosting, przeczytaj jak wyeksportować aplikację zbudowaną przez AI i uruchomić ją samodzielnie.

AI może przygotować za ciebie większość tego:

Napisz README dla tego projektu dla dewelopera, który nigdy go nie widział: co robi aplikacja, stos technologiczny, jak uruchomić ją lokalnie, każda zmienna środowiskowa, którą odczytuje (tylko nazwy i przeznaczenie), jak zorganizowany jest schemat bazy danych i jak ją wdrożyć.

Lista kontrolna gotowości produkcyjnej

• Główne ścieżki spisane i przetestowane, w tym „nie można uzyskać dostępu do danych innej osoby”
• Autoryzacja i walidacja po stronie serwera na każdej trasie danych
• Brak kluczy sekretnych w kodzie frontendu; wyciekłe klucze wymienione
• Limity żądań na logowaniu i na wszystkim, co kosztuje pieniądze
• Śledzenie błędów i alerty dostępności kierowane do skrzynki, którą czytasz
• Kopie zapasowe bazy danych poza hostingiem aplikacji, z jednym udanym testowym przywróceniem
• Paginacja i indeksy sprawdzone na realistycznych danych
• Własna domena, zweryfikowana domena wysyłkowa, polityka prywatności
• README i lista dostępów dla następnej osoby

Robienie tego w Mythex

Jeśli zbudowałeś prototyp w Mythex, większość tych kroków to prompty w tym samym projekcie. Wpisz /test, a Mythex przeklika się przez podgląd na żywo jak użytkownik i zgłosi zepsute ścieżki — zobacz Testowanie aplikacji. Klucze trafiają do sekretów projektu, a nie do czatu; każda udana tura agenta zapisuje punkt kontrolny twoich plików, do którego możesz wrócić; publikacja daje ci żywy adres URL z hostingiem, a baza danych jest rozliczana z tego samego salda kredytów (limity hostingu wyjaśniają, jak aplikacje i bazy danych usypiają i budzą się). Punkty kontrolne obejmują pliki, a nie wiersze bazy danych, więc i tak zaplanuj kopie zapasowe danych. W planie Pro możesz podłączyć własną domenę i wyeksportować kod albo zsynchronizować go z własnym repozytorium GitHub przy przekazaniu projektu.

Pytania