Jak dostat AI prototyp do provozu

Při přechodu AI prototypu do provozu zavíráte mezeru mezi tím, že „to funguje, když to zkusím“, a tím, že „to funguje, i když to používají ostatní“. V praxi to znamená pět věcí: testovat hlavní toky pokaždé, když něco měníte, zamknout, kdo co smí vidět a měnit, zajistit, že se o chybách dozvíte dřív, než vám je řeknou uživatelé, zálohovat data a ověřit, že je umíte obnovit, a udržet aplikaci dostatečně rychlou i na telefonu. Nic z toho nevyžaduje přepsání od začátku – je to kontrolní seznam, který projdete se stejnou AI, která prototyp vytvořila.

Prototyp versus produkce: co se doopravdy mění

Prototyp má jednoho opatrného uživatele: vás. Víte, na která tlačítka klepnout, zadáváte rozumné vstupy a když se něco rozbije, pokrčíte rameny a požádáte AI o opravu. Produkce má mnoho nepozorných uživatelů, některé zvědavé a občas i nepřátelského. Kód nemusí být „podnikový“; musí zvládnout situace, se kterými se prototyp nikdy nesetká.

Zbytek tohoto průvodce prochází jednotlivé řádky.

Krok 1: Zmrazte rozsah a zapište hlavní toky

Než cokoli zpevníte, rozhodněte, co je verze jedna. Sepište tři až šest toků, které jsou nejdůležitější – například „registrace, vytvoření projektu, pozvání kolegy, platba“. Tyto toky se stanou vaším testovacím skriptem, cíli monitoringu a tím, co kontrolujete po každé změně.

Vše, co na seznamu není, buď vyřadíte, nebo jasně označíte jako beta. Čtyři spolehlivé toky se udělají mnohem snáz než čtrnáct.

Krok 2: Testujte jako cizí člověk, pak to udělejte opakovatelné

Nástroje pro tvorbu AI jsou dobré v kódu, který funguje v ideálním případě. Produkční problémy však žijí v neideálních situacích. Otestujte každý hlavní tok těmito způsoby:

• Špatný vstup: prázdná povinná pole, jméno o 5 000 znacích, e-mail bez zavináče, záporné množství, datum v minulosti.
• Obnovení a tlačítko zpět: obnovte stránku uprostřed platby; stiskněte zpět po odeslání formuláře. Vznikne něco dvakrát?
• Dvě karty, dva uživatelé: přihlaste se jako dva různé účty a zkuste otevřít stránky toho druhého změnou ID v adrese.
• Pomalé a malé: obrazovka velikosti telefonu a omezené připojení (vývojářské nástroje prohlížeče umějí simulovat pomalé připojení).
• Prázdné stavy: úplně nový účet bez dat. Prototypy se často tvoří se vzorovými daty a bez nich vypadají rozbitě.

Pak kontrolu zopakujte. Minimálně veďte písemný seznam a spusťte ho před každým vydáním. Lépe je požádat AI, aby napsala automatizované testy pro nejdůležitější toky:

Přidej automatizované end-to-end testy pro tyto toky: registrace e-mailem, vytvoření projektu, pozvání druhého uživatele a dokončení platby v testovacím režimu Stripe. Dále přidej testy, které potvrdí, že uživatel nemůže zobrazit ani upravit projekt jiného uživatele změnou adresy URL.

Testy, které dokazují, že uživatel něco nemůže, jsou přesně ty, které prototypům nejčastěji chybí.

Krok 3: Základy zabezpečení, které prototypy přeskakují

Většina bezpečnostních problémů u aplikací vytvořených AI není exotická. Chybí kontroly. Projděte tento seznam a podívejte se na širší bezpečnostní kontrolní seznam pro aplikace vytvořené AI:

• Autorizace na serveru. Skrytí tlačítka není zabezpečení. Každý požadavek, který čte nebo mění data, musí na serveru ověřit, že přihlášený uživatel k tomu má oprávnění. Pokud vaše aplikace používá databázi s pravidly na úrovni řádků, ověřte, že jsou zapnutá a otestovaná.
• Tajné klíče mimo prohlížeč. API klíče pro platby, e-mail nebo AI poskytovatele patří do proměnných prostředí na serveru, nikdy do kódu na frontendu. Pokud si nejste jisti, co to znamená, přečtěte si co jsou proměnné prostředí a tajné klíče.
• Validace na serveru. Prohlížeč lze obejít, takže každou kontrolu, na které záleží, zopakujte na serveru.
• Přihlášení provedené správně. Použijte dobře otestovanou knihovnu nebo službu pro autentizaci, ne vlastní ukládání hesel. Náš návod jak přidat přihlášení do aplikace popisuje možnosti.
• Omezení počtu požadavků na přihlášení, registraci, obnovu hesla a na cokoli, co posílá e-maily nebo volá placené API.
• Srozumitelné chybové hlášky. Uživatelé mají vidět „něco se pokazilo“; podrobnosti patří do logů, ne na obrazovku.
• Vyměňte cokoli, co uniklo. Pokud byl živý klíč kdy vložen do chatu, commitu nebo snímku obrazovky, nechte ho u poskytovatele nahradit novým.

Prompt, který pokryje hodně najednou:

Zkontroluj tuto aplikaci z hlediska bezpečnosti pro provoz. Ověř, že každá API trasa kontroluje, zda přihlášený uživatel vlastní záznam, který čte nebo mění, že se žádné tajné klíče neposílají do prohlížeče, že vstupy jsou validovány na serveru a že přihlášení a obnova hesla mají omezení počtu požadavků. Než cokoli změníš, vypiš, co jsi našel.

Nejdřív požádat o seznam vám umožní vidět problémy a rozhodnout o pořadí, místo abyste dostali jednu obří změnu.

Krok 4: Vědět, kdy se něco rozbije – logování a monitoring

V náhledu vidíte chyby ve chvíli, kdy vzniknou. V produkci potřebujete, aby vás aplikace upozornila. Tři vrstvy, od nejlevnější po nejužitečnější:

1. Serverové logy. Ujistěte se, že se chyby logují s dostatečným kontextem, aby šly reprodukovat: která trasa, ID uživatele (ne jeho heslo ani kartu), tvar vstupu. Pokud aplikace jen vypisuje do konzole, požádejte AI o strukturované logování.
2. Sledování chyb. Služba jako Sentry nebo podobný nástroj zachytává výjimky na frontendu i backendu, seskupuje je a posílá vám e-mail. U malé aplikace často stačí bezplatné úrovně těchto služeb; aktuální limity ověřte na jejich webech.
3. Kontroly dostupnosti. Externí služba, která každých několik minut načte vaši domovskou stránku a jednu klíčovou API trasu a upozorní vás, když selžou. Zachytí problémy, kvůli kterým aplikace vůbec nedokáže logovat.

Jeden návyk navíc: po každém vydání otevřete živou aplikaci a projděte kontrolní seznam hlavních toků na skutečné adrese, ne jen v náhledu.

Krok 5: Zálohy a cesta zpět

Chrání se dvě různé věci a snadno se pletou.

• Kód. Projekt držte ve správě verzí, aby šla každá změna vrátit zpět. Mnoho nástrojů pro tvorbu AI uchovává kontrolní body vašich souborů; synchronizace do Git repozitáře vám dá kopii i mimo nástroj.
• Data. Vrácení kódu nevrátí databázi. Špatná migrace nebo chybné tlačítko pro smazání může zničit řádky, které žádný kontrolní bod kódu nevrátí.

Pro data nastavte pravidelné zálohy uložené jinde než na hostingu aplikace – u databáze Postgres je běžným řešením naplánovaný pg_dump na oddělené úložiště, a mnoho spravovaných hostingů databází nabízí automatické zálohy nebo obnovení k určitému časovému bodu. Pak udělejte krok, který většina lidí přeskočí: obnovte zálohu do pomocné databáze a ověřte, že jsou data na místě.

Také požádejte AI, aby zabezpečila destruktivní akce: potvrzení před smazáním a „měkké smazání“ (označení řádků jako smazaných místo jejich odstranění) u všeho, co by uživatelé mohli chtít vrátit.

Krok 6: Výkon, který obstojí na telefonu

Prototypy působí rychle, protože jste jediný uživatel a datová sada je malá. Před spuštěním:

• Zatěžte reálným množstvím dat. Požádejte AI, aby naplnila několik tisíc řádků, a zjistěte, které stránky zpomalí. Seznamy obvykle potřebují stránkování a databáze obvykle potřebuje indexy na sloupcích, podle kterých filtrujete a třídíte.
• Zmenšete obrázky. Příliš velké obrázky jsou nejčastějším důvodem pomalé stránky. Požádejte o zmenšené a komprimované obrázky a líné načítání pod hranicí obrazovky.
• Měřte. Spusťte Lighthouse v nástrojích pro vývojáře Chrome na živé adrese v mobilním režimu. Rozumným cílem jsou Core Web Vitals od Googlu: Largest Contentful Paint do 2,5 sekundy, Interaction to Next Paint 200 ms nebo méně a Cumulative Layout Shift 0,1 nebo méně.
• Sledujte zpoždění při „probuzení“. Hosting, který při nečinnosti usíná, ušetří peníze, ale první návštěva po klidném období se načítá pomaleji. U nové aplikace je to často přijatelný kompromis; věďte, že k tomu dochází.

Stránka projektů je se 5 000 řádky pomalá. Přidej stránkování na straně serveru (25 na stránku), přidej indexy v databázi pro sloupce, podle kterých filtrujeme a třídíme, a při načítání další stránky ukaž stav načítání.

Krok 7: Provozní základy

Pár malých věcí odliší hobby aplikaci od té, které lidé důvěřují:

• Vlastní doména s HTTPS. Viz jak připojit vlastní doménu.
• Transakční e-mail z ověřené domény pro potvrzení registrace a obnovu hesla – popsáno v jak posílat e-maily z aplikace.
• Zásady ochrany osobních údajů a podmínky, které popisují, co skutečně sbíráte. Nekopírujte tvrzení o souladu s předpisy, která jste nesplnili.
• Kanál podpory – i jen sledovaná e-mailová adresa.
• Oddělené testovací a živé klíče pro platby a e-mail a jasný zápis, které prostředí používá který.

Krok 8: Čisté předání

Dříve nebo později bude na aplikaci pracovat někdo jiný: externista, nový spoluzakladatel nebo vy za šest měsíců. Usnadněte to:

• README, které popisuje, jak aplikaci spustit, které proměnné prostředí potřebuje (jen názvy, nikdy hodnoty) a jak ji nasadit.
• Kontrolní seznam hlavních toků a automatizované testy.
• Krátká poznámka k architektuře: frontend, backend, databáze, služby třetích stran a kde je každá hostovaná.
• Seznam přístupů: kdo má administrátorský přístup k doméně, hostingu, databázi, účtům pro platby a e-mail. Tyto účty veďte pod firemním e-mailem, ne osobním.
• Kód v Gitu, ideálně synchronizovaný s repozitářem, který vlastníte. Pokud možná později změníte hosting, přečtěte si jak exportovat aplikaci vytvořenou AI a provozovat ji vlastním serverem.

AI může většinu z toho připravit za vás:

Napiš README pro tento projekt pro vývojáře, který ho nikdy neviděl: co aplikace dělá, technologický základ, jak ji spustit lokálně, každou proměnnou prostředí, kterou čte (jen názvy a účel), jak je organizováno schéma databáze a jak ji nasadit.

Kontrolní seznam připravenosti na produkci

• Hlavní toky zapsané a otestované, včetně „nelze přistoupit k cizím datům“
• Autorizace a validace na serveru u každé trasy pracující s daty
• Žádné tajné klíče v kódu na frontendu; uniklé klíče vyměněny
• Omezení počtu požadavků na přihlášení a na cokoli, co stojí peníze
• Sledování chyb a kontroly dostupnosti směřující do schránky, kterou čtete
• Zálohy databáze mimo hosting aplikace s jednou úspěšnou zkušební obnovou
• Stránkování a indexy ověřené na realistických datech
• Vlastní doména, ověřená doména pro odesílání, zásady ochrany osobních údajů
• README a seznam přístupů pro dalšího člověka v řadě

Práce s Mythexem

Pokud jste prototyp vytvořili v Mythexu, většina těchto kroků je prompty ve stejném projektu. Napište /test a Mythex proklikne živý náhled jako uživatel a nahlásí rozbité toky – viz App Testing. Klíče patří do tajných proměnných projektu, ne do chatu; každý úspěšný tah agenta uloží kontrolní bod souborů, ke kterému se můžete vrátit, a publikování vám dá živou adresu s hostingem a databází účtovanými ze stejného kreditu (limity hostingu vysvětluje, jak aplikace a databáze usínají a probouzejí se). Kontrolní body pokrývají soubory, ne řádky databáze, takže zálohy dat stejně naplánujte. Na plánu Pro můžete připojit vlastní doménu a exportovat kód nebo ho synchronizovat s vlastním repozitářem na GitHubu pro předání.

Otázky