Hogyan vigyünk élesbe egy AI-prototípust

Az AI-prototípus élesbe vitelekor a „próbálgatva működik” és a „akkor is működik, ha mások használják” közötti szakadékot kell áthidalni. Gyakorlatban öt dolgot jelent: tesztelni a fő folyamatokat minden változtatás után, lezárni, ki láthat és módosíthat mit, időben észrevenni a hibákat, mielőtt a felhasználók jeleznék, mentéseket készíteni és bizonyítani, hogy vissza lehet állítani őket, és az appot elég gyorsan tartani telefonon is. Ehhez semmit nem kell újraírni — ez egy ellenőrző lista, amelyen ugyanazzal az AI-val dolgozol végig, amely a prototípust építette.

Prototípus vs. éles: mi változik valójában

A prototípusnak egy gondos felhasználója van: te. Tudod, melyik gombra kell nyomni, értelmes adatokat írsz be, és ha valami elromlik, megvonod a vállad, és megkéred az AI-t, hogy javítsa. Az élesben sok gondatlan felhasználó van, néhány kíváncsi, és néha egy rosszindulatú. A kódnak nem kell „vállalati” szintűvé válnia; azokat a helyzeteket kell kezelnie, amelyekkel a prototípus soha nem találkozik.

Az útmutató többi része ezt a táblázatot sorról sorra járja végig.

1. lépés: Rögzítsd a terjedelmet és írd le a fő folyamatokat

Mielőtt bármit megerősítenél, döntsd el, mi az első változat. Sorold fel a három-hat legfontosabb folyamatot — például „regisztráció, projekt létrehozása, munkatárs meghívása, fizetés”. Ezek lesznek a tesztforgatókönyved, a figyelés célpontjai és azok, amiket minden változtatás után ellenőrizel.

Ami nincs a listán, azt vagy kivágod, vagy egyértelműen béta jelöléssel látod el. Sokkal könnyebb négy folyamatot megbízhatóvá tenni, mint tizennégyet.

2. lépés: Teszteld úgy, mint egy idegen, aztán tedd megismételhetővé

Az AI-építők jók a működő útvonalra (happy path) írt kódban. Az éles problémák a nem működő útvonalakon élnek. Minden fő folyamatot teszteld:

• Hibás bemenettel: üres kötelező mezők, 5000 karakteres név, @ nélküli e-mail, negatív mennyiség, múltbeli dátum.
• Frissítésekkel és a vissza gombbal: töltsd újra a fizetés közepén; nyomd meg a vissza gombot egy űrlap beküldése után. Létrejön valami kétszer?
• Két lap, két felhasználó: jelentkezz be két különböző fiókkal, és próbáld megnyitni egymás oldalait az URL-ben lévő azonosító átírásával.
• Lassan és kicsiben: telefonméretű képernyő és lassított kapcsolat (a böngésző fejlesztői eszközei szimulálhatják).
• Üres állapotok: egy frissen létrehozott fiók adatok nélkül. A prototípusokat gyakran mintaadatokkal építik, és adatok nélkül hibásnak tűnnek.

Ezután tedd megismételhetővé az ellenőrzést. Legalább tarts írásos listát, és futtasd le minden kiadás előtt. Még jobb, ha kéred az AI-tól, hogy írjon automatizált teszteket a legfontosabb folyamatokhoz:

Adj automatizált végpontok közötti (end-to-end) teszteket ezekre a folyamatokra: regisztráció e-maillel, projekt létrehozása, második felhasználó meghívása, és fizetés befejezése a Stripe teszt módjában. Adj hozzá olyan teszteket is, amelyek megerősítik, hogy egy felhasználó nem tekintheti meg vagy szerkesztheti egy másik felhasználó projektjét az URL megváltoztatásával.

Az olyan tesztek, amelyek bizonyítják, hogy a felhasználó valamit nem tehet meg, azok hiányoznak a prototípusokból a leggyakrabban.

3. lépés: Biztonsági alapok, amelyeket a prototípusok kihagynak

Az AI-val épített appok biztonsági problémái ritkán egzotikusak. Hiányzó ellenőrzések. Menj végig ezen a listán, és nézd meg a teljesebb biztonsági ellenőrző listát AI-val épített appokhoz is:

• Jogosultság-ellenőrzés a szerveren. A gomb elrejtése nem biztonság. Minden kérésnek, amely adatot olvas vagy módosít, a szerveren kell ellenőriznie, hogy a bejelentkezett felhasználó jogosult-e rá. Ha az app soros szintű szabályokkal rendelkező adatbázist használ, ellenőrizd, hogy be vannak-e kapcsolva és tesztelve vannak-e.
• Titkok a böngészőn kívül. A fizetési, e-mail- vagy AI-szolgáltatók API-kulcsai szerveroldali környezeti változókba valók, soha nem a front-end kódba. Ha nem vagy biztos abban, mit jelent ez, olvasd el: mik a környezeti változók és titkok.
• Validáció a szerveren. A böngésző megkerülhető, ezért minden fontos ellenőrzést ismételj meg a szerveren.
• Bejelentkezés rendesen. Használj jól tesztelt hitelesítési könyvtárat vagy szolgáltatást, ne kézzel írt jelszótárolást. A bejelentkezés hozzáadása az appodhoz útmutató a lehetőségeket tárgyalja.
• Sebességkorlátok a bejelentkezésen, a regisztráción, a jelszó-visszaállításon és mindenen, ami e-mailt küld vagy fizetős API-t hív.
• Barátságos hibaüzenetek. A felhasználók lássák, hogy „valami hiba történt”; a részletek a naplódba kerüljenek, ne a képernyőre.
• Cseréld ki azt, ami kiszivárgott. Ha egy éles kulcsot valaha csevegésbe, commitba vagy képernyőképre másoltak be, cseréld le a szolgáltatónál.

Egy prompt, amely sok területet lefed egyszerre:

Nézd át ezt az appot éles biztonsági szempontból. Ellenőrizd, hogy minden API-útvonal megnézi, hogy a bejelentkezett felhasználó birtokolja-e a rekordot, amelyet olvas vagy módosít, hogy egyetlen titkos kulcs sem jut el a böngészőbe, hogy a bemenetek a szerveren validálva vannak, és hogy a bejelentkezés és a jelszó-visszaállítás sebességkorlátozott. Előbb sorold fel, mit találsz, mielőtt bármit megváltoztatnál.

A lista kérése először lehetővé teszi, hogy lásd a problémákat és eldöntsd a sorrendet, ahelyett, hogy egy hatalmas változtatást kapnál.

4. lépés: Tudd meg, mikor törik el — naplózás és figyelés

Az előnézetben látod a hibákat, amint történnek. Élesben az appnak kell szólnia neked. Három réteg, a legolcsóbbtól a leghasznosabbig:

1. Szervernaplók. Győződj meg róla, hogy a hibák elég kontextussal naplózódnak ahhoz, hogy újra lehessen őket állítani: melyik útvonal, melyik felhasználói azonosító (nem a jelszava vagy a kártyaadata), milyen bemeneti forma. Ha az app csak a konzolra ír, kérd meg az AI-t, hogy adjon strukturált naplózást.
2. Hibakövetés. Olyan szolgáltatás, mint a Sentry vagy hasonló eszköz, rögzíti a front-end és back-end kivételeket, csoportosítja őket, és e-mailt küld. Egy kis appnál ezek ingyenes csomagjai gyakran elegendők; az aktuális korlátokat a szolgáltatók oldalán ellenőrizd.
3. Elérhetőség-ellenőrzés. Külső szolgáltatás, amely néhány percenként betölti a főoldaladat és egy kulcs API-útvonalat, és riaszt, ha hibát kap. Ez azokat a problémákat fogja meg, amelyek miatt az app egyáltalán nem tud naplózni.

Egy további szokás: minden kiadás után nyisd meg az élő appot, és futtasd le a fő folyamatok ellenőrző listáját az éles URL-en, ne csak az előnézetben.

5. lépés: Mentések és visszaút

Két különböző dolgot kell védeni, és könnyű összekeverni őket.

• Kód. Tartsd a projektet verziókezelésben, hogy bármilyen változtatás visszavonható legyen. Sok AI-építő megőriz ellenőrzőpontokat a fájljaidról; a Git-tárolóval való szinkronizálás az építőn kívüli másolatot is ad.
• Adatok. A kód visszaállítása nem állítja vissza az adatbázist. Egy hibás migráció vagy egy hibás törlés gomb olyan sorokat pusztíthat el, amelyeket egyetlen kód-ellenőrzőpont sem hoz vissza.

Az adatokhoz állíts be rendszeres mentéseket az app saját tárhelyétől eltérő helyen — Postgres adatbázisnál az általános megoldás egy ütemezett pg_dump külön tárolóba, és sok felügyelt adatbázis-szolgáltató kínál automatikus mentést vagy pontos időpontra való visszaállítást. Ezután végezd el azt a lépést, amelyet a legtöbben kihagynak: állítsd vissza a mentést egy próbaadatbázisba, és ellenőrizd, hogy ott vannak az adatok.

Kérd meg az AI-t is, hogy tegye biztonságosabbá a visszafordíthatatlan műveleteket: megerősítő lépést a törlésekhez, és „puha törlést” (a sorok megjelölését töröltként a végleges eltávolítás helyett) mindenhez, amit a felhasználók később visszaszeretnének kapni.

6. lépés: Teljesítmény, amely telefonon is megáll

A prototípusok azért tűnnek gyorsnak, mert te vagy az egyetlen felhasználó, és az adathalmaz apró. Indulás előtt:

• Valós méretű adatok betöltése. Kérd meg az AI-t, hogy töltsön be néhány ezer sort, és nézd meg, mely oldalak lassulnak le. A listáknak általában lapozás kell, az adatbázisnak pedig indexek a szűrt és rendezett oszlopokon.
• Képek kicsinyítése. A túl nagy képek a leggyakoribb okai annak, hogy egy oldal lassan tölt be. Kérj átméretezett, tömörített képeket, és lusta betöltést a képernyő alatt.
• Mérés. Futtasd a Lighthouse-t a Chrome fejlesztői eszközeiben az élő URL-en mobil módban. A Google Core Web Vitals mutatói ésszerű célok: a legnagyobb tartalmi elem megjelenése 2,5 másodpercen belül, az interakció utáni következő festés (Interaction to Next Paint) legfeljebb 200 ms, és a kumulatív elrendezés-eltolódás (Cumulative Layout Shift) legfeljebb 0,1.
• Figyelj az „ébredési” késleltetésekre. Az üresjáratban elaltatott tárhely pénzt spórol, de a csendes időszak utáni első látogatás lassabb. Ez egy új appnál gyakran elfogadható csere; tudj róla, hogy történik.

A projektek oldal lassú 5000 sorral. Adj szerveroldali lapozást (oldalanként 25), adj adatbázis-indexeket a szűrt és rendezett oszlopokra, és mutass betöltési állapotot a következő oldal betöltése közben.

7. lépés: Működési alapok

Az ilyen apró dolgok választják el a hobbiappot attól, amelyben az emberek megbíznak:

• Egyedi domain HTTPS-sel. Lásd: hogyan kapcsolj egyedi domaint.
• Tranzakciós e-mail ellenőrzött domainről a regisztrációs megerősítésekhez és a jelszó-visszaállításokhoz — ezt a hogyan küldj e-mailt az appodból útmutató tárgyalja.
• Adatvédelmi szabályzat és feltételek, amelyek leírják, mit gyűjtesz valójában. Ne másolj olyan megfelelőségi állításokat, amelyeket nem teljesítesz.
• Támogatási csatorna — akár egy figyelt e-mail-cím is.
• Külön teszt és éles kulcsok a fizetéshez és az e-mailhez, és egyértelmű jegyzet arról, melyik környezet melyiket használja.

8. lépés: Rendezett átadás

Előbb-utóbb más is dolgozik majd az appon: egy szabadúszó, egy új társalapító, vagy te hat hónap múlva. Könnyítsd meg ezt:

• README, amely leírja, hogyan futtasd, mely környezeti változókra van szüksége (csak a nevek, soha az értékek), és hogyan telepítsd.
• A fő folyamatok ellenőrző listája és az automatizált tesztek.
• Rövid architektúra-jegyzet: front end, back end, adatbázis, harmadik féltől származó szolgáltatások, és hogy hol fut mindegyik.
• Hozzáférési lista: ki rendelkezik adminisztrátori hozzáféréssel a domainhez, a tárhelyhez, az adatbázishoz, a fizetési és e-mail-fiókokhoz. Ezek a fiókok üzleti e-mail-címhez tartozzanak, ne személyesekhez.
• A kód Gitben, lehetőleg egy általad birtokolt tárolóval szinkronizálva. Ha később hosztingot váltanál, olvasd el: hogyan exportáld és futtasd saját szerveren az AI-val épített appot.

Az AI ezek nagy részét meg tudja írni neked:

Írj README-t ehhez a projekthez egy fejlesztőnek, aki még sosem látta: mit csinál az app, milyen a technológiai verem, hogyan futtasd helyben, minden környezeti változót, amit olvas (csak nevek és szerep), hogyan van felépítve az adatbázis-séma, és hogyan telepítsd.

Élesítési ellenőrző lista

• A fő folyamatok leírva és tesztelve, beleértve a „nem férhet hozzá más adataihoz” esetet
• Szerveroldali jogosultság-ellenőrzés és validáció minden adatútvonalon
• Nincs titkos kulcs a front-end kódban; a kiszivárgott kulcsok cserélve
• Sebességkorlátok a hitelesítésen és mindenen, ami pénzbe kerül
• Hibakövetés és elérhetőség-riasztások egy olyan postafiókba, amelyet olvasol
• Adatbázis-mentések az app tárhelyén kívül, egy sikeres próbaszerű visszaállítással
• Lapozás és indexek ellenőrizve valósághű adatokkal
• Egyedi domain, ellenőrzött küldő domain, adatvédelmi szabályzat
• README és hozzáférési lista a következő embernek

Mindez a Mythexszel

Ha a prototípust Mythexben építetted, ezek a lépések többsége ugyanabban a projektben lévő prompt. Írd be a /test parancsot, és a Mythex úgy kattint végig az élő előnézeten, mint egy felhasználó, és jelenti a törött folyamatokat — lásd: App Testing. A kulcsok a projekt titkaiba kerülnek, nem a csevegésbe; minden sikeres ügynöki kör ellenőrzőpontot ment a fájljaidról, amelyre visszaállhatsz; a közzététel pedig élő URL-t ad hosztinggal, az adatbázissal együtt, ugyanabból a kreditegyenlegből számlázva (a tárhely-korlátok leírják, hogyan alszanak el és ébrednek az appok és adatbázisok). Az ellenőrzőpontok fájlokat fednek le, nem adatbázis-sorokat, ezért az adatmentésekről továbbra is gondoskodj. A Pro csomagban egyedi domaint kötsz, és a kódot exportálhatod vagy szinkronizálhatod a saját GitHub-tárolódba az átadáshoz.

Kérdések