Ako dostať prototyp vytvorený s AI do produkcie

Ak chcete dostať prototyp vytvorený s AI do produkcie, zatvoríte medzeru medzi „funguje, keď to skúsim“ a „funguje, aj keď to používajú ďalší ľudia“. V praxi to znamená päť vecí: testovať hlavné toky pri každej zmene, zabezpečiť, kto môže vidieť a meniť čo, uistiť sa, že sa o chybách dozviete skôr, než vám to povedia používatelia, zálohovať dáta a overiť, že ich viete obnoviť, a udržať aplikáciu dostatočne rýchlu aj na telefóne. Nič z toho nevyžaduje prepísanie – je to kontrolný zoznam, ktorý prejdete s rovnakou AI, ktorá prototyp vytvorila.

Prototyp vs produkcia: čo sa naozaj mení

Prototyp má jedného opatrného používateľa: vás. Viete, ktoré tlačidlá stlačiť, zadávate rozumný vstup a ak sa niečo pokazí, pokrčíte plecami a požiadate AI o opravu. Produkcia má mnoho nedbanlivých používateľov, niekoľkých zvedavých a občas nepriateľského. Kód nemusí byť „enterprise“; musí zvládnuť situácie, s ktorými sa prototyp nikdy nestretne.

Zvyšok tohto návodu prechádza každý riadok.

Krok 1: Zmrazte rozsah a zapíšte hlavné toky

Pred akýmkoľvek spevňovaním rozhodnite, čo je verzia jedna. Zoznam troch až šiestich tokov, ktoré sú najdôležitejšie – napríklad „registrácia, vytvorenie projektu, pozvanie člena tímu, platba“. Tieto sa stanú vaším testovacím skriptom, cieľmi monitoringu a vecami, ktoré kontrolujete po každej zmene.

Všetko, čo nie je na zozname, sa buď vypustí, alebo jasne označí ako beta. Je omnoho ľahšie spoľahlivo zvládnuť štyri toky ako štrnásť.

Krok 2: Testujte ako cudzinec, potom to urobte opakovateľné

Tvorcovia aplikácií s AI sú dobrí v kóde, ktorý funguje na šťastnej ceste. Produkčné problémy žijú na nešťastných cestách. Testujte každý hlavný tok s:

• Zlým vstupom: prázdne povinné polia, meno s 5 000 znakmi, e-mail bez @, záporné množstvo, dátum v minulosti.
• Obnovením a tlačidlom späť: obnovte stránku uprostred pokladne; stlačte späť po odoslaní formulára. Vytvorí sa niečo dvakrát?
• Dva panely, dvaja používatelia: prihláste sa ako dvaja rôzni používatelia a skúste otvoriť stránky toho druhého zmenou ID v URL.
• Pomaly a na malom: obrazovka veľkosti telefónu a obmedzené pripojenie (vývojárske nástroje prehliadača ho dokážu simulovať).
• Prázdne stavy: úplne nový účet bez dát. Prototypy sa často stavajú s ukážkovými dátami a bez nich vyzerajú rozbité.

Potom urobte kontrolu opakovateľnou. Minimálne si nechajte písaný kontrolný zoznam a spúšťajte ho pred každým vydaním. Lepšie je požiadať AI, aby napísala automatizované testy pre najdôležitejšie toky:

Pridaj automatizované end-to-end testy pre tieto toky: registrácia e-mailom, vytvorenie projektu, pozvanie druhého používateľa a dokončenie platby v testovacom režime Stripe. Pridaj aj testy, ktoré potvrdia, že používateľ nemôže zobraziť ani upraviť projekt iného používateľa zmenou URL.

Testy, ktoré dokazujú, že používateľ nemôže niečo urobiť, sú presne tie, ktoré prototypy najčastejšie chýbajú.

Krok 3: Základy bezpečnosti, ktoré prototypy preskakujú

Väčšina bezpečnostných problémov v aplikáciách vytvorených s AI nie je exotická. Ide o chýbajúce kontroly. Prejdite tento zoznam a pozrite si podrobnejší bezpečnostný kontrolný zoznam pre aplikácie vytvorené s AI:

• Autorizácia na serveri. Skrytie tlačidla nie je bezpečnosť. Každá požiadavka, ktorá číta alebo mení dáta, musí na serveri overiť, že prihlásený používateľ na to má právo. Ak vaša aplikácia používa databázu s pravidlami na úrovni riadkov, overte, že sú zapnuté a otestované.
• Tajomstvá mimo prehliadača. API kľúče pre platby, e-mail alebo AI poskytovateľov patria do premenných prostredia na serveri, nikdy do frontend kódu. Ak si nie ste istí, čo to znamená, prečítajte si čo sú premenné prostredia a tajomstvá.
• Validácia na serveri. Prehliadač sa dá obísť, takže každú dôležitú kontrolu zopakujte na serveri.
• Prihlasovanie urobené správne. Použite dobre otestovanú autentifikačnú knižnicu alebo službu namiesto vlastného ukladania hesiel. Náš návod ako pridať prihlasovanie do aplikácie pokrýva možnosti.
• Limity požiadaviek na prihlasovanie, registráciu, obnovu hesla a na všetko, čo posiela e-maily alebo volá platené API.
• Priateľské chybové hlášky. Používatelia majú vidieť „niečo sa pokazilo“; podrobnosti idú do logov, nie na obrazovku.
• Vymeňte všetko, čo uniklo. Ak bol živý kľúč niekedy vložený do chatu, commitu alebo screenshotu, vymeňte ho u poskytovateľa.

Prompt, ktorý pokryje veľa naraz:

Skontroluj túto aplikáciu z pohľadu bezpečnosti pre produkciu. Over, že každá API trasa overuje, že prihlásený používateľ vlastní záznam, ktorý číta alebo mení, že žiadne tajné kľúče sa neposielajú do prehliadača, že vstupy sa validujú na serveri a že prihlásenie a obnova hesla majú limit požiadaviek. Pred akoukoľvek zmenou vypíš, čo si našiel.

Žiadosť o zoznam najprv vám umožní vidieť problémy a rozhodnúť o poradí, namiesto jednej obrovskej zmeny.

Krok 4: Vedzte, kedy sa to rozbije – logovanie a monitoring

V náhľade vidíte chyby hneď, ako nastanú. V produkcii potrebujete, aby vám ich aplikácia oznámila. Tri vrstvy od najlacnejšej po najužitočnejšiu:

1. Serverové logy. Uistite sa, že chyby sa logujú s dostatočným kontextom na reprodukciu: ktorá trasa, ID používateľa (nie jeho heslo ani kartu), tvar vstupu. Ak aplikácia iba vypisuje do konzoly, požiadajte AI o štruktúrované logovanie.
2. Sledovanie chýb. Služba ako Sentry alebo podobný nástroj zachytáva výnimky na frontende aj backende, zoskupuje ich a posiela vám e-maily. Pre malú aplikáciu často stačia bezplatné úrovne týchto služieb; aktuálne limity si overte na ich stránkach.
3. Kontroly dostupnosti. Externá služba, ktorá každých pár minút načíta vašu domovskú stránku a jednu kľúčovú API trasu a upozorní vás, ak zlyhá. Zachytí problémy, kvôli ktorým aplikácia vôbec nelogu je.

Pridajte ešte jeden návyk: po každom vydaní otvorte živú aplikáciu a spustite kontrolný zoznam hlavných tokov na skutočnej URL, nielen v náhľade.

Krok 5: Zálohy a cesta späť

Chránia sa dve rôzne veci a ľahko sa zamieňajú.

• Kód. Držte projekt vo verzionovaní, aby sa dala každá zmena vrátiť späť. Mnohí tvorcovia s AI uchovávajú checkpointy vašich súborov; synchronizácia do Git repozitára vám dá kópiu aj mimo nástroja.
• Dáta. Vrátenie kódu nevráti databázu. Zlá migrácia alebo chybné tlačidlo na mazanie môže zničiť riadky, ktoré žiadny checkpoint kódu nevráti.

Pre dáta nastavte pravidelné zálohy uložené mimo hostingu aplikácie – pri databáze Postgres je bežným prístupom naplánovaný pg_dump do samostatného úložiska a mnohí spravované hostitelia databáz ponúkajú automatické zálohy alebo obnovu do bodu v čase. Potom urobte krok, ktorý väčšina ľudí preskočí: obnovte zálohu do pracovnej databázy a overte, že dáta sú tam.

Tiež požiadajte AI, aby deštruktívne akcie urobila bezpečnejšie: potvrdzovací krok pri mazaní a „mäkké mazanie“ (označenie riadkov ako zmazaných namiesto ich odstránenia) pre všetko, čo by si používatelia mohli chcieť vrátiť.

Krok 6: Výkon, ktorý obstojí na telefóne

Prototypy pôsobia rýchlo, pretože ste jediný používateľ a dát je málo. Pred spustením:

• Načítajte dáta reálnej veľkosti. Požiadajte AI, aby naplnila niekoľko tisíc riadkov a zistite, ktoré stránky spomaľujú. Zoznamy zvyčajne potrebujú stránkovanie a databáza zvyčajne indexy na stĺpcoch, podľa ktorých filtrujete a radíte.
• Zmenšite obrázky. Preveľké obrázky sú najčastejším dôvodom pomalého načítania stránky. Požiadajte o zmenšené, skomprimované obrázky a lenivé načítanie pod hranicou obrazovky.
• Merajte. Spustite Lighthouse vo vývojárskych nástrojoch Chrome na živej URL v mobilnom režime. Rozumným cieľom sú Core Web Vitals od Googlu: Largest Contentful Paint do 2,5 sekundy, Interaction to Next Paint 200 ms alebo menej a Cumulative Layout Shift 0,1 alebo menej.
• Sledujte oneskorenia pri „prebudení“. Hosting, ktorý pri nečinnosti zaspí, šetrí peniaze, ale prvá návšteva po tichom období je pomalšia. Pre novú aplikáciu je to často rozumný kompromis; vedzte, že sa to deje.

Stránka projektov je pri 5 000 riadkoch pomalá. Pridaj stránkovanie na strane servera (25 na stránku), pridaj indexy databázy pre stĺpce, podľa ktorých filtrujeme a radíme, a zobraz stav načítavania, kým sa načíta ďalšia stránka.

Krok 7: Základy prevádzky

Niekoľko malých vecí oddeľuje hobby aplikáciu od tej, ktorej ľudia dôverujú:

• Vlastná doména s HTTPS. Pozrite si ako pripojiť vlastnú doménu.
• Transakčný e-mail z overenej domény pre potvrdenia registrácie a obnovu hesla – pokrýva to ako posielať e-maily z aplikácie.
• Zásady ochrany súkromia a podmienky, ktoré popisujú, čo skutočne zbierate. Nekopírujte tvrdenia o súlade, ktoré ste si nezaslúžili.
• Kanál podpory – aspoň sledovaná e-mailová adresa.
• Oddelené testovacie a živé kľúče pre platby a e-mail a jasná poznámka, ktoré prostredie používa ktoré.

Krok 8: Čisté odovzdanie

Skôr či neskôr bude na aplikácii pracovať niekto iný: freelancer, nový spoluzakladateľ alebo vy o šesť mesiacov. Uľahčite to:

• README, ktoré vysvetľuje, ako ju spustiť, ktoré premenné prostredia potrebuje (iba názvy, nikdy hodnoty) a ako ju nasadiť.
• Kontrolný zoznam hlavných tokov a automatizované testy.
• Krátka poznámka o architektúre: frontend, backend, databáza, služby tretích strán a kde je každá hostovaná.
• Zoznam prístupov: kto má administrátorský prístup k doméne, hostingu, databáze, účtom platieb a e-mailu. Tieto účty majte pod firemným e-mailom, nie osobným.
• Kód v Gite, ideálne synchronizovaný do repozitára, ktorý vlastníte. Ak môžete hosting neskôr zmeniť, prečítajte si ako exportovať aplikáciu vytvorenú s AI a hostovať ju vlastnými silami.

AI môže väčšinu z toho napísať za vás:

Napíš README pre tento projekt pre vývojára, ktorý ho nikdy nevidel: čo aplikácia robí, technológie, ako ju spustiť lokálne, každú premennú prostredia, ktorú číta (iba názvy a účel), ako je organizovaná schéma databázy a ako ju nasadiť.

Kontrolný zoznam pripravenosti na produkciu

• Hlavné toky zapísané a otestované vrátane „nemá prístup k dátam iného používateľa“
• Autorizácia a validácia na serveri pri každej trase pracujúcej s dátami
• Žiadne tajné kľúče vo frontend kóde; uniknuté kľúče vymenené
• Limity požiadaviek na autentifikáciu a na všetko, čo stojí peniaze
• Sledovanie chýb a upozornenia na dostupnosť smerujúce do schránky, ktorú čítate
• Zálohy databázy mimo hostingu aplikácie s jednou úspešne otestovanou obnovou
• Stránkovanie a indexy overené s reálnymi dátami
• Vlastná doména, overená odosielacia doména, zásady ochrany súkromia
• README a zoznam prístupov pre toho, kto príde ďalší

Práca s Mythexom

Ak ste prototyp vytvorili v Mythexe, väčšina týchto krokov sú prompty v tom istom projekte. Napíšte /test a Mythex prekliká živý náhľad ako používateľ a nahlási rozbité toky – pozrite si App Testing. Kľúče idú do tajomstiev projektu, nie do chatu, každý úspešný krok agenta uloží checkpoint vašich súborov, ku ktorému sa môžete vrátiť, a publikovanie vám dá živú URL s hostingom a databázou účtovanými z rovnakého kreditného zostatku (limity hostingu vysvetľujú, ako aplikácie a databázy zaspávajú a budia sa). Checkpointy pokrývajú súbory, nie riadky databázy, takže si aj tak naplánujte zálohy dát. Na pláne Pro môžete pripojiť vlastnú doménu a exportovať kód alebo ho synchronizovať do vášho vlastného repozitára GitHub pre odovzdanie.

Otázky