Kā no AI prototipa izveidot ražošanas lietotni

Lai no AI prototipa izveidotu ražošanas lietotni, tu aizver plaisu starp „darbojas, kad to pamēģinu” un „turpina darboties, kad to lieto citi cilvēki”. Praksē tas nozīmē piecas lietas: pārbaudīt galvenās plūsmas katru reizi, kad kaut ko maini; nodrošināt, kas var redzēt un mainīt ko; pārliecināties, ka kļūdas uzzini pirms lietotāji tev pasaka; dublēt datus un pierādīt, ka vari tos atjaunot; un nodrošināt, ka lietotne ir pietiekami ātra telefonā. Nekas no tā neprasa pārrakstīšanu — tas ir kontrolsaraksts, ko izpildi kopā ar to pašu AI, kas veidoja prototipu.

Prototips pret ražošanu: kas patiesībā mainās

Prototipam ir viens uzmanīgs lietotājs: tu. Tu zini, uz kurām pogām nospiest, ievadi saprātīgus datus, un, ja kaut kas salūst, tu paraustī plecus un lūdz AI to salabot. Ražošanā ir daudz nevērīgu lietotāju, daži ziņkārīgi un reizēm kāds naidīgs. Kodam nav jākļūst „korporatīvam”; tam jāspēj tikt galā ar situācijām, ar ko prototips nekad nesaskaras.

Pārējā šī ceļveža daļa iet cauri katrai rindai.

1. solis: iesaldē apjomu un uzraksti galvenās plūsmas

Pirms ko nostiprini, izlem, kas ir pirmā versija. Uzskaiti trīs līdz sešas plūsmas, kas ir vissvarīgākās — piemēram, „reģistrēties, izveidot projektu, uzaicināt kolēģi, samaksāt”. Tās kļūst par tavu testu skriptu, uzraudzības mērķiem un lietām, ko pārbauda pēc katras izmaiņas.

Jebkas, kas nav sarakstā, vai tiek izgriezts, vai skaidri atzīmēts kā beta. Ir daudz vieglāk padarīt četras plūsmas uzticamas nekā četrpadsmit.

2. solis: testē kā svešinieks, tad padari to atkārtojamu

AI veidotāji labi rada kodu, kas strādā laimīgajā ceļā. Ražošanas problēmas dzīvo nelaimīgajos ceļos. Testē katru galveno plūsmu ar:

• Nepareizu ievadi: tukši obligātie lauki, 5000 rakstzīmju vārds, e-pasts bez @, negatīvs daudzums, datums pagātnē.
• Atsvaidzināšanu un atpakaļ pogu: pārlādē lapu pusceļā maksājumā; nospied atpakaļ pēc formas iesniegšanas. Vai kaut kas tiek izveidots divreiz?
• Divas cilnes, divi lietotāji: pieraksties ar diviem dažādiem kontiem un mēģini atvērt otra lapas, mainot ID URL.
• Lēns un mazs: tālruņa ekrāns un ierobežots savienojums (pārlūka izstrādātāju rīki var to simulēt).
• Tukšie stāvokļi: jauns konts bez datiem. Prototipi bieži tiek veidoti ar paraugdatiem un izskatās salauzti bez tiem.

Pēc tam padari pārbaudi atkārtojamu. Vismaz glabā rakstītu kontrolsarakstu un izpildi to pirms katras izlaides. Labāk — lūdz AI uzrakstīt automatizētus testus plūsmām, kas ir vissvarīgākās:

Pievieno automatizētus gala-līdz-galam testus šīm plūsmām: reģistrēšanās ar e-pastu, projekta izveide, otra lietotāja uzaicināšana un maksājuma pabeigšana Stripe testa režīmā. Pievieno arī testus, kas apstiprina, ka lietotājs nevar skatīt vai rediģēt cita lietotāja projektu, mainot URL.

Testus, kas pierāda, ka lietotājs KO NEVAR izdarīt, prototipiem visbiežāk pietrūkst.

3. solis: drošības pamati, kurus prototipi izlaiž

Vairums drošības problēmu AI veidotās lietotnēs nav eksotiskas. Tās ir trūkstošas pārbaudes. Izej cauri šim sarakstam, un skati pilnīgāku drošības kontrolsarakstu AI veidotām lietotnēm:

• Autorizācija serverī. Poga, kas paslēpta, nav drošība. Katram pieprasījumam, kas lasa vai maina datus, serverī jāpārbauda, vai pieteicies lietotājs drīkst to darīt. Ja tava lietotne izmanto datubāzi ar rindu līmeņa noteikumiem, pārbaudi, vai tie ir ieslēgti un pārbaudīti.
• Noslēpumi ārpus pārlūka. Maksājumu, e-pasta vai AI pakalpojumu API atslēgas pieder serveru vides mainīgajos, nekad priekšgala kodā. Ja neesi pārliecināts, ko tas nozīmē, izlasi kas ir vides mainīgie un noslēpumi.
• Validācija serverī. Pārlūku var apiet, tāpēc atkārto katru svarīgu pārbaudi serverī.
• Pareizi veikta pieteikšanās. Izmanto labi pārbaudītu autentifikācijas bibliotēku vai pakalpojumu, nevis paroļu glabāšanu, kas veidota pašu rokām. Mūsu ceļvedis kā pievienot pieteikšanos lietotnei aptver iespējas.
• Pieprasījumu ierobežojumi pieteikšanās, reģistrēšanās, paroles atjaunošanas un visam, kas sūta e-pastu vai izsauc maksas API.
• Draudzīgas kļūdas. Lietotāji redz „kaut kas nogāja greizi”; detaļas iet uz tavām žurnālu ierakstu vietām, nevis uz ekrānu.
• Rotē visu, kas ir noplūdis. Ja dzīvā atslēga kādreiz tika ielīmēta čatā, commitā vai ekrānuzņēmumā, nomaini to pakalpojumu sniedzējā.

Uzvedne, kas aptver daudz uzreiz:

Pārskati šo lietotni ražošanas drošībai. Pārbaudi, ka katrs API maršruts pārbauda, vai pieteicies lietotājs pieder ierakstam, ko lasa vai maina, ka neviens noslēpums netiek sūtīts pārlūkam, ka ievades tiek validētas serverī un ka pieteikšanās un paroles atjaunošana ir ierobežota pēc pieprasījumu skaita. Vispirms uzskaiti, ko atradi, pirms ko maini.

Prasīt vispirms sarakstu ļauj redzēt problēmas un izlemt kārtību, nevis saņemt vienu milzīgu izmaiņu.

4. solis: zini, kad kaut kas salūst — žurnalēšana un uzraudzība

Priekšskatījumā kļūdas redzi, kad tās notiek. Ražošanā lietotnei jāpastāsta tev. Trīs slāņi, no lētākā līdz noderīgākajam:

1. Servera žurnāli. Pārliecinies, ka kļūdas tiek ierakstītas ar pietiekamu kontekstu, lai tās varētu atkārtot: kurš maršruts, kura lietotāja ID (ne paroli vai karti), kāda ievades struktūra. Lūdz AI pievienot strukturētu žurnalēšanu, ja lietotne tikai drukā konsolē.
2. Kļūdu izsekošana. Pakalpojums, piemēram, Sentry vai līdzīgs rīks, uztver priekšgala un servera izņēmumus, grupē tos un nosūta tev e-pastu. Maziem lietotnēm bezmaksas līmeņi bieži vien pietiek; pārbaudi pašreizējos limitus to vietnēs.
3. Darbspējas pārbaudes. Ārējs pakalpojums ielādē tavu sākumlapu un vienu galveno API maršrutu ik pēc dažām minūtēm un brīdina, ja tie neizdodas. Tas uztver problēmas, kas aptur lietotni no jebkādas žurnalēšanas.

Pievieno vēl vienu ieradumu: pēc katras izlaides atver dzīvo lietotni un izpildi galveno plūsmu kontrolsarakstu uz reālā URL, nevis tikai priekšskatījumā.

5. solis: dublējumi un ceļš atpakaļ

Jāaizsargā divas dažādas lietas, un tās ir viegli sajaukt.

• Kods. Glabā projektu versiju kontrolē, lai jebkuru izmaiņu varētu atsaukt. Daudzi AI veidotāji glabā failu kontrolpunktus; sinhronizēšana ar Git repozitoriju dod kopiju ārpus veidotāja.
• Dati. Koda atgriešana neatgriež datubāzi. Slikta migrācija vai kļūdaina dzēšanas poga var iznīcināt rindas, ko neviens koda kontrolpunkts neatgriezīs.

Datiem iestati regulārus dublējumus, kas glabājas citur, nevis lietotnes pašā hostingā — Postgres datubāzei parasta pieeja ir ieplānots pg_dump uz atsevišķu krātuvi, un daudzi pārvaldītie datubāzu hosti piedāvā automātiskus dublējumus vai punktveida atjaunošanu. Pēc tam izdari soli, ko vairums izlaiž: atjauno dublējumu testa datubāzē un pārbaudi, vai dati ir tur.

Tāpat lūdz AI padarīt destruktīvās darbības drošākas: apstiprināšanas soli dzēšanai un „mīkstu dzēšanu” (rindu atzīmēšanu kā dzēstas, nevis to noņemšanu) visam, ko lietotāji varētu vēlēties atgūt.

6. solis: ātrums, kas notur uz tālruņa

Prototipi šķiet ātri, jo tu esi vienīgais lietotājs un datu kopa ir maza. Pirms palaišanas:

• Ielādē reāla izmēra datus. Lūdz AI ievietot dažus tūkstošus rindu un redzi, kuras lapas palēninās. Sarakstiem parasti vajag lapošanu, un datubāzei parasti vajag indeksus kolonnām, pēc kurām filtrē un kārto.
• Samazini attēlus. Pārāk lieli attēli ir biežākais iemesls, kāpēc lapa ielādējas lēni. Lūdz izmērā samazinātus, saspiestus attēlus un slinko ielādi zem ekrāna apakšdaļas.
• Mēri. Palaid Lighthouse Chrome izstrādātāju rīkos dzīvajā URL mobilajā režīmā. Google Core Web Vitals ir saprātīgs mērķis: lielākais satura elements (LCP) 2,5 sekunžu robežās, mijiedarbības līdz nākamajai reakcijai (INP) 200 ms vai mazāk un kumulatīvā izkārtojuma nobīde (CLS) 0,1 vai mazāk.
• Uzmanies no „pamošanās” aizkavēm. Hostings, kas guļ, kad nav aktīvs, ietaupa naudu, bet padara pirmo apmeklējumu pēc klusa perioda lēnāku. Tas bieži vien ir pieņemams kompromiss jaunai lietotnei; zini, ka tas notiek.

Projektu lapa ir lēna ar 5000 rindām. Pievieno servera puses lapošanu (25 vienā lapā), pievieno datubāzes indeksus kolonnām, pēc kurām filtrējam un kārtojam, un parādi ielādes stāvokli, kamēr ielādējas nākamā lapa.

7. solis: operatīvie pamati

Dažas mazas lietas atdala hobiju lietotni no tādas, kurai cilvēki uzticas:

• Pielāgots domēns ar HTTPS. Skati kā pieslēgt pielāgotu domēnu.
• Transakcijas e-pasts no pārbaudīta domēna reģistrācijas apstiprinājumiem un paroļu atjaunošanai — aptverts kā sūtīt e-pastus no savas lietotnes.
• Privātuma politika un noteikumi, kas apraksta, ko faktiski vāc. Nekopē atbilstības apgalvojumus, ko neesi nopelnījis.
• Atbalsta kanāls — pat uzraudzīta e-pasta adrese.
• Atsevišķas testa un dzīvās atslēgas maksājumiem un e-pastam, un skaidra piezīme, kura vide izmanto kuras.

8. solis: tīra nodošana

Drīz vai vēlāk kāds cits strādās pie lietotnes: freelancers, jauns līdzdibinātājs vai tu pats pēc sešiem mēnešiem. Padari to vieglu:

• README, kas pasaka, kā to palaist, kuri vides mainīgie nepieciešami (tikai nosaukumi, nekad vērtības) un kā to izvietot.
• Galveno plūsmu kontrolsaraksts un automatizētie testi.
• Īsa arhitektūras piezīme: priekšgals, serveris, datubāze, trešo pušu pakalpojumi un kur katrs ir hostēts.
• Piekļuves saraksts: kam ir administratora piekļuve domēnam, hostingam, datubāzei, maksājumu un e-pasta kontiem. Glabā šos kontus zem biznesa e-pasta, nevis personīgā.
• Kods Git, ideāli sinhronizēts ar repozitoriju, kas tev pieder. Ja vēlāk plāno mainīt hostingu, izlasi kā eksportēt un pašu hostēt AI veidotu lietotni.

AI var izstrādāt lielāko daļu no tā:

Uzraksti README šim projektam cilvēkam, kas to nekad nav redzējis: ko lietotne dara, tehnoloģiju steks, kā to palaist lokāli, katrs vides mainīgais, ko tā nolasa (tikai nosaukumi un nozīme), kā organizēta datubāzes shēma un kā to izvietot.

Ražošanas gatavības kontrolsaraksts

• Galvenās plūsmas uzrakstītas un pārbaudītas, tostarp „nevar piekļūt cita datiem”
• Servera puses autorizācija un validācija katram datu maršrutam
• Nav noslēpumu priekšgala kodā; noplūdušās atslēgas rotētas
• Pieprasījumu ierobežojumi autentifikācijai un visam, kas maksā naudu
• Kļūdu izsekošana un darbspējas brīdinājumi, kas nosūta uz e-pastu, ko tu lasi
• Datubāzes dublējumi ārpus lietotnes hostinga, ar vienu veiksmīgu testa atjaunošanu
• Lapošana un indeksi pārbaudīti ar reāliem datiem
• Pielāgots domēns, pārbaudīts sūtīšanas domēns, privātuma politika
• README un piekļuves saraksts nākamajam cilvēkam

Darbs ar Mythex

Ja prototipu veidoji Mythex, lielākā daļa no šiem soļiem ir uzvednes tajā pašā projektā. Ieraksti /test, un Mythex noklikšķina cauri dzīvajam priekšskatījumam kā lietotājs un ziņo par salauztām plūsmām — skati Lietotņu testēšana. Atslēgas ievieto projekta noslēpumos, nevis čatā; katra veiksmīga aģenta darbība saglabā failu kontrolpunktu, kuram vari atgriezties, un publicēšana dod dzīvu URL ar hostingu un datubāzi, kas tiek norēķināta no tās pašas kredītu bilances (hostinga limiti izskaidro, kā lietotnes un datubāzes guļ un pamostas). Kontrolpunkti aptver failus, nevis datubāzes rindas, tāpēc joprojām plāno datu dublējumus. Pro plānā vari pieslēgt pielāgotu domēnu un eksportēt kodu vai sinhronizēt to ar savu GitHub repozitoriju nodošanai.

Jautājumi