Sådan tager du en AI-prototype til produktion

At tage en AI-prototype til produktion handler om at lukke kløften mellem „den virker, når jeg prøver den“ og „den bliver ved med at virke, når andre bruger den“. I praksis betyder det fem ting: test de vigtigste flows, hver gang du ændrer noget, lås fast, hvem der må se og ændre hvad, sørg for at høre om fejl, før dine brugere fortæller dig det, tag backup af data og bevis, at du kan gendanne dem, og hold appen hurtig nok på en telefon. Intet af det kræver en omskrivning — det er en tjekliste, du arbejder igennem sammen med den samme AI, der byggede prototypen.

Prototype vs. produktion: hvad der faktisk ændrer sig

En prototype har én omhyggelig bruger: dig. Du ved, hvilke knapper du skal trykke på, du skriver fornuftig input, og hvis noget går i stykker, trækker du på skuldrene og beder AI'en rette det. Produktion har mange skødesløse brugere, nogle nysgerrige og lejlighedsvis en fjendtlig. Koden behøver ikke blive „enterprise“; den skal håndtere de situationer, en prototype aldrig møder.

Resten af guiden gennemgår hver række.

Trin 1: Frys omfanget og skriv de vigtigste flows ned

Før du hærder noget, skal du beslutte, hvad version et er. List de tre til seks flows, der betyder mest — for eksempel „tilmeld dig, opret et projekt, inviter en kollega, betal“. Disse bliver din testplan, dine overvågningsmål og de ting, du tjekker efter hver ændring.

Alt, der ikke står på listen, skal enten skæres væk eller tydeligt markeres som beta. Det er langt nemmere at gøre fire flows pålidelige end fjorten.

Trin 2: Test som en fremmed, og gør det derefter gentageligt

AI-byggere er gode til at producere kode, der virker på den lykkelige sti. Produktionsproblemer findes på de ulykkelige stier. Test hvert vigtigt flow med:

• Dårlig input: tomme obligatoriske felter, et navn på 5.000 tegn, en e-mail uden @, et negativt antal, en dato i fortiden.
• Opdateringer og tilbageknappen: genindlæs midt i checkout; tryk tilbage efter at have sendt en formular. Bliver noget oprettet to gange?
• To faner, to brugere: log ind med to forskellige konti, og prøv at åbne hinandens sider ved at ændre ID'et i URL'en.
• Langsomt og småt: en skærm i telefonstørrelse og en begrænset forbindelse (browserens udviklerværktøjer kan simulere den).
• Tomme tilstande: en helt ny konto uden data. Prototyper bygges ofte med eksempeldata og ser ødelagte ud uden dem.

Gør derefter kontrollen gentagelig. Som minimum: hold en skriftlig tjekliste og kør den før hver udgivelse. Bedre er det at bede AI'en skrive automatiserede tests for de vigtigste flows:

Tilføj automatiserede end-to-end-tests for disse flows: tilmelding med e-mail, oprettelse af et projekt, invitation af en anden bruger og gennemførelse af checkout i Stripes testtilstand. Tilføj også tests, der bekræfter, at en bruger ikke kan se eller redigere en andens projekt ved at ændre URL'en.

Tests, der beviser, at en bruger ikke kan gøre noget, er dem prototyper oftest mangler.

Trin 3: Grundlæggende sikkerhed, som prototyper springer over

De fleste sikkerhedsproblemer i AI-byggede apps er ikke eksotiske. Der mangler kontroller. Gå denne liste igennem, og se den mere fuldstændige sikkerhedstjekliste for AI-byggede apps:

• Adgangskontrol på serveren. At skjule en knap er ikke sikkerhed. Hver forespørgsel, der læser eller ændrer data, skal på serveren kontrollere, at den indloggede bruger må gøre det. Hvis din app bruger en database med rækkeregler, så tjek at de er slået til og testet.
• Hemmeligheder væk fra browseren. API-nøgler til betalinger, e-mail eller AI-udbydere hører hjemme i serverens miljøvariabler, aldrig i frontend-kode. Hvis du er i tvivl om, hvad det betyder, så læs hvad miljøvariabler og hemmeligheder er.
• Validering på serveren. Browseren kan omgås, så gentag alle kontroller, der betyder noget, på serveren.
• Login gjort ordentligt. Brug et veltestet login-bibliotek eller en tjeneste i stedet for selvlavet opbevaring af adgangskoder. Vores guide til at tilføje login til din app gennemgår mulighederne.
• Hastighedsbegrænsning på login, tilmelding, nulstilling af adgangskode og alt, der sender e-mail eller kalder en betalt API.
• Venlige fejlbeskeder. Brugerne skal se „noget gik galt“; detaljerne går til dine logs, ikke til skærmen.
• Roter alt, der har lækket. Hvis en live-nøgle nogensinde er blevet indsat i en chat, en commit eller et skærmbillede, så udskift den hos udbyderen.

En prompt, der dækker meget på én gang:

Gennemgå denne app for produktionssikkerhed. Tjek at hver API-rute bekræfter, at den indloggede bruger ejer den post, den læser eller ændrer, at ingen hemmelige nøgler sendes til browseren, at input valideres på serveren, og at login og nulstilling af adgangskode har hastighedsbegrænsning. List det, du finder, før du ændrer noget.

Ved at bede om en liste først kan du se problemerne og beslutte rækkefølgen, i stedet for at få én kæmpe ændring.

Trin 4: Vid, når noget går i stykker — logning og overvågning

I forhåndsvisningen ser du fejl, mens de sker. I produktion skal appen fortælle dig det. Tre lag, fra billigst til mest nyttigt:

1. Serverlogs. Sørg for, at fejl logges med nok kontekst til at kunne genskabe dem: hvilken rute, hvilket bruger-ID (ikke adgangskoden eller kortoplysninger) og hvilken form input har. Bed AI'en om struktureret logning, hvis appen kun skriver til konsollen.
2. Fejlsporing. En tjeneste som Sentry eller et lignende værktøj fanger undtagelser i både frontend og backend, grupperer dem og sender dig e-mail. For en lille app er de gratis niveauer af disse tjenester ofte nok; tjek de aktuelle grænser på deres hjemmesider.
3. Oppetidstjek. En ekstern tjeneste, der indlæser din forside og en vigtig API-rute med få minutters mellemrum og alarmerer dig, hvis de fejler. Det fanger de problemer, der stopper appen fra at logge overhovedet.

Tilføj endnu en vane: efter hver udgivelse, åbn den live app og kør din tjekliste for vigtige flows på den rigtige URL, ikke kun i forhåndsvisningen.

Trin 5: Backups og en vej tilbage

To forskellige ting skal beskyttes, og de er nemme at forveksle.

• Kode. Hold projektet i versionskontrol, så enhver ændring kan fortrydes. Mange AI-byggere gemmer checkpoints af dine filer; synkronisering til et Git-repository giver dig en kopi uden for byggeren.
• Data. Tilbagerulning af kode ruller ikke databasen tilbage. En dårlig migrering eller en knap med en fejl i sletning kan ødelægge rækker, som intet kode-checkpoint bringer tilbage.

Til data skal du opsætte regelmæssige backups, der gemmes et andet sted end appens egen hosting — for en Postgres-database er en planlagt pg_dump til separat lagring den almindelige fremgangsmåde, og mange administrerede databasehosts tilbyder automatiske backups eller gendannelse til et bestemt tidspunkt. Gør derefter det trin, de fleste springer over: gendan en backup til en midlertidig database, og kontroller at dataene er der.

Bed også AI'en om at gøre destruktive handlinger mere sikre: et bekræftelsestrin for sletninger og „blød sletning“ (markér rækker som slettede i stedet for at fjerne dem) for alt, brugerne måske vil have tilbage.

Trin 6: Ydeevne, der holder på en telefon

Prototyper føles hurtige, fordi du er den eneste bruger, og datamængden er lille. Før lancering:

• Indlæs data i rigtig størrelse. Bed AI'en om at fylde nogle tusinde rækker ind og se, hvilke sider der bliver langsomme. Lister har normalt brug for paginering, og databasen har normalt brug for indekser på de kolonner, du filtrerer og sorterer efter.
• Formindsk billeder. For store billeder er den hyppigste årsag til en langsom side. Bed om billeder i mindre størrelse og komprimeret, og lazy loading under folden.
• Mål. Kør Lighthouse i Chromes udviklerværktøjer på den live URL i mobiltilstand. Googles Core Web Vitals er et fornuftigt mål: Largest Contentful Paint under 2,5 sekunder, Interaction to Next Paint på 200 ms eller mindre og Cumulative Layout Shift på 0,1 eller mindre.
• Hold øje med „vækketid“. Hosting, der sover, når den er inaktiv, sparer penge, men gør første besøg efter en stille periode langsommere. Det er ofte en fin afvejning for en ny app; vid bare, at det sker.

Projektsiden er langsom med 5.000 rækker. Tilføj paginering på serveren (25 pr. side), tilføj databaseindekser for de kolonner, vi filtrerer og sorterer efter, og vis en indlæsningstilstand, mens næste side hentes.

Trin 7: Driftsgrundlaget

Nogle få små ting skiller en hobbyapp fra en, folk stoler på:

• Et eget domæne med HTTPS. Se sådan forbinder du et eget domæne.
• Transaktionsmails fra et verificeret domæne til bekræftelser ved tilmelding og nulstilling af adgangskode — dækket i sådan sender du e-mails fra din app.
• Privatlivspolitik og vilkår, der beskriver, hvad du faktisk indsamler. Kopiér ikke overensstemmelsespåstande, du ikke har opnået.
• En supportkanal — selv en overvåget e-mailadresse.
• Adskilte test- og live-nøgler til betalinger og e-mail, og en klar note om, hvilket miljø der bruger hvilken.

Trin 8: En ren overdragelse

Før eller siden skal nogen andre arbejde på appen: en freelancer, en ny medstifter, eller dig selv om seks måneder. Gør det nemt:

• En README, der forklarer, hvordan den køres, hvilke miljøvariabler den har brug for (kun navne, aldrig værdier), og hvordan den udrulles.
• Tjeklisten for de vigtigste flows og de automatiserede tests.
• En kort arkitekturnote: frontend, backend, database, tredjepartstjenester og hvor hver er hostet.
• Adgangsliste: hvem der har adminadgang til domænet, hostingen, databasen, betalings- og e-mailkonti. Læg disse konti under en virksomhedsmail, ikke en personlig.
• Koden i Git, helst synkroniseret til et repository, du ejer. Hvis du måske flytter hosting senere, så læs sådan eksporterer og selv-hoster du en AI-bygget app.

AI'en kan udarbejde det meste af dette for dig:

Skriv en README for dette projekt til en udvikler, der aldrig har set det: hvad appen gør, teknologistakken, hvordan den køres lokalt, hver miljøvariabel den læser (kun navne og formål), hvordan databaseskemaet er organiseret, og hvordan den udrulles.

Tjekliste for produktionsklar

• Vigtigste flows skrevet ned og testet, inklusive „kan ikke få adgang til andres data“
• Adgangskontrol og validering på serveren for hver datarute
• Ingen hemmelige nøgler i frontend-kode; lækkede nøgler roteret
• Hastighedsbegrænsning på login og alt, der koster penge
• Fejlsporing og oppetidsalarmer, der peger på en indbakke, du læser
• Databasebackups uden for appens hosting, med mindst én vellykket testgendannelse
• Paginering og indekser kontrolleret med realistiske data
• Eget domæne, verificeret afsenderdomæne, privatlivspolitik
• README og adgangsliste til den, der kommer efter dig

Gør det med Mythex

Hvis du har bygget prototypen i Mythex, er de fleste af disse trin prompts i det samme projekt. Skriv /test, og Mythex klikker sig igennem den live forhåndsvisning som en bruger og rapporterer ødelagte flows — se App Testing. Nøgler lægges i projektets hemmeligheder og ikke i chatten. Hver vellykket agent-tur gemmer et checkpoint af dine filer, som du kan vende tilbage til, og udgivelse giver dig en live-URL med hosting og database faktureret fra samme kreditsaldo (grænser for hosting forklarer, hvordan apps og databaser går i dvale og vågner). Checkpoints dækker filer, ikke databaserækker, så planlæg stadig dine databackups. På Pro kan du forbinde et eget domæne og eksportere koden eller synkronisere den til dit eget GitHub-repository til overdragelse.

Spørgsmål