Како да го однесете AI прототипот во производство

За да го однесете AI прототипот во производство, го затворате јазот помеѓу „функционира кога ќе го пробам“ и „продолжува да работи кога другите го користат“. Во пракса тоа значи пет работи: тестирајте ги главните текови секој пат кога нешто менувате, заклучете кој може да види и менува што, осигурајте се дека дознавате за грешки пред корисниците да ви кажат, направете резервни копии на податоците и докажете дека можете да ги вратите, и одржувајте ја апликацијата доволно брза на телефон. Ништо од ова не бара пишување одново — тоа е список што го минувате заедно со истиот AI што го изгради прототипот.

Прототип наспроти производство: што навистина се менува

Прототипот има еден внимателен корисник: вас. Знаете на кои копчиња да притиснете, внесувате разумни податоци и, ако нешто се расипе, слегнете со рамена и побарате од AI да го поправи. Производството има многу непромислени корисници, некои љубопитни и повремено еден непријателски. Кодот не мора да стане „за големи претпријатија“; треба да се справи со ситуациите што прототипот никогаш не ги сретнува.

Останатиот дел од овој водич ги минува сите редови.

Чекор 1: Замрзнете го обемот и запишете ги главните текови

Пред да засилите што било, одлучете што е верзија еден. Наведете ги три до шест текови што најмногу се важни — на пример „регистрација, создавање проект, покана за соработник, плаќање“. Тие стануваат ваша тест скрипта, цели за следење и нешта што ги проверувате после секоја измена.

Секое нешто што не е на списокот или ќе се исече, или јасно ќе се означи како бета. Многу е полесно да се направат четири текови сигурни отколку четиринаесет.

Чекор 2: Тестирајте како непознат, па направете го повторливо

AI градителите се добри во производство на код што работи на среќниот пат. Проблемите во производството живеат на несреќните патишта. Тестирајте го секој главен тек со:

• Лоши внесувања: празни задолжителни полиња, име од 5.000 знаци, е-пошта без @, негативна количина, датум во минатото.
• Освежувања и копчето назад: освежете на половина од наплатата; притиснете назад по поднесување на формулар. Се создава ли нешто двапати?
• Два прозорци, два корисника: најавете се со две различни сметки и обидете се да ги отворите страниците на другиот со промена на ID во URL.
• Бавно и мало: екран со големина на телефон и ограничена врска (алатките за програмери во прелистувачот можат да симулираат таква).
• Празни состојби: сосема нова сметка без податоци. Прототипите често се градат со примерок податоци и изгледаат расипано без нив.

Потоа направете ја проверката повторлива. Најмалку, чувајте писмена листа и минувајте ја пред секое издание. Подобро е да побарате од AI да напише автоматски тестови за текови што најмногу се важни:

Додај автоматски end-to-end тестови за овие текови: регистрација со е-пошта, создавање проект, поканување втор корисник и завршување на наплата во тест-режимот на Stripe. Додај и тестови што потврдуваат дека корисник не може да види или уреди проект на друг корисник со промена на URL-от.

Тестовите што докажуваат дека корисникот не може да направи нешто се оние што најчесто им недостасуваат на прототипите.

Чекор 3: Основна безбедност што прототипите ја прескокнуваат

Најголемиот дел од безбедносните проблеми кај апликации изградени со AI не се егзотични. Тие се недостасувачки проверки. Минете низ овој список, а поцелосниот безбедносен список за апликации изградени со AI ќе го видите посебно:

• Овластување на серверот. Скривањето на копче не е безбедност. Секое барање што чита или менува податоци мора да провери, на серверот, дека најавениот корисник има дозвола за тоа. Ако вашата апликација користи база со правила на ниво на редови, проверете дали се вклучени и тестирани.
• Тајните надвор од прелистувачот. Клучевите за API за плаќања, е-пошта или AI провајдери припаѓаат во променливите на околината на серверот, никогаш во код на предниот дел. Ако не сте сигурни што значи тоа, прочитајте што се променливите на околината и тајните.
• Валидација на серверот. Прелистувачот може да се заобиколи, па повторете ја секоја проверка што е важна и на серверот.
• Најава направена правилно. Користете добро тестирана библиотека или услуга за автентикација наместо сопствено чување лозинки. Нашиот водич за додавање најава во вашата апликација ги опфаќа опциите.
• Ограничувања на бројот барања за најава, регистрација, враќање на лозинка и секое нешто што испраќа е-пошта или повикува платен API.
• Пријателски грешки. Корисниците треба да видат „нешто тргна наопаку“; деталите одат во вашите логови, не на екранот.
• Заменете секое нешто што процуртило. Ако жив клуч некогаш бил залепен во разговор, commit или слика од екранот, заменете го кај провајдерот.

Порака што покрива многу работи одеднаш:

Прегледај ја оваа апликација за безбедност при производство. Провери дали секој API маршрут потврдува дека најавениот корисник е сопственик на записот што го чита или менува, дека ниту еден тајен клуч не се испраќа до прелистувачот, дека внесувањата се валидираат на серверот и дека најавата и враќањето на лозинка имаат ограничување на барањата. Наведи што најде пред да менуваш што било.

Барањето прво список ви овозможува да ги видите проблемите и да одлучите редот, наместо да добиете една огромна измена.

Чекор 4: Знајте кога се расипува — евидентирање и следење

Во прегледот ги гледате грешките како се случуваат. Во производство, апликацијата треба да ве извести. Три слоеви, од најевтиниот до најкорисниот:

1. Логови на серверот. Осигурајте се дека грешките се евидентираат со доволно контекст за да може да се репродуцираат: кој маршрут, кој ID на корисник (не лозинката или картичката), каква форма има внесувањето. Побарајте од AI да додаде структурирано евидентирање ако апликацијата само печати во конзолата.
2. Следење на грешки. Услуга како Sentry или слична алатка фаќа исклучоци на предниот и задниот дел, ги групира и ви испраќа е-пошта. За мала апликација бесплатните нивоа на овие услуги често се доволни; проверете ги актуелните ограничувања на нивните страници.
3. Проверки на достапност. Надворешна услуга што ја вчитува вашата почетна страница и еден клучен API маршрут на секои неколку минути и ве известува ако не успеат. Ова ги открива проблемите што воопшто ја спречуваат апликацијата да евидентира.

Додајте уште една навика: по секое издание, отворете ја живата апликација и минете ја вашата листа на главни текови на вистинската URL-адреса, не само во прегледот.

Чекор 5: Резервни копии и начин за враќање

Два различни нешта треба да се заштитат, и лесно се мешаат.

• Кодот. Чувајте го проектот во контрола на верзии за секоја измена да може да се поништи. Многу AI градители чуваат контролни точки на вашите датотеки; синхронизацијата со Git репозиториум ви дава копија и надвор од градителот.
• Податоците. Враќањето на кодот не ја враќа базата на податоци. Лоша миграција или копче за бришење со бубачка може да уништи редови што ниедна контролна точка на кодот нема да ги врати.

За податоците, поставете редовни резервни копии чувани некаде надвор од хостингот на апликацијата — за база Postgres, вообичаен пристап е закажан pg_dump на посебно складиште; многу управувани хостови на бази нудат автоматски резервни копии или враќање до точка во времето. Потоа направете го чекорот што повеќето го прескокнуваат: вратете резервна копија во привремена база и проверете дали податоците се таму.

Исто така, побарајте од AI да ги направи деструктивните дејства поголемо безбедни: чекор за потврда при бришење и „меко бришење“ (означување редови како избришани наместо нивно отстранување) за нешто што корисниците можеби ќе сакаат назад.

Чекор 6: Перформанси што издржуваат на телефон

Прототипите изгледаат брзи затоа што сте единствениот корисник, а податочното множество е мало. Пред лансирање:

• Вчитајте податоци со реална големина. Побарајте од AI да засее неколку илјади редови и видете кои страници се забавуваат. Списоците обично бараат страничење, а базата обично бара индекси на колоните по кои филтрирате и сортирате.
• Намалете ги сликите. Преголемите слики се најчестата причина страницата да се вчитува бавно. Побарајте променета големина, компресирани слики и лениво вчитување под гушот на страницата.
• Измерете. Пуштете Lighthouse во алатките за програмери на Chrome на живата URL-адреса во мобилен режим. Core Web Vitals на Google се разумна цел: Largest Contentful Paint до 2,5 секунди, Interaction to Next Paint од 200 ms или помалку и Cumulative Layout Shift од 0,1 или помалку.
• Внимавајте на доцнења при „будење“. Хостингот што заспива кога е неактивен штеди пари, но ја прави првата посета по мирен период побавна. Тоа често е прифатливо чинење за нова апликација; знајте дека се случува.

Страницата со проекти е бавна со 5.000 редови. Додај страничење на серверот (по 25 на страница), додај индекси на базата за колоните по кои филтрираме и сортираме и прикажи состојба на вчитување додека се вчитува следната страница.

Чекор 7: Оперативни основи

Неколку мали работи ја одвојуваат апликацијата за хоби од онаа на која луѓето ѝ веруваат:

• Прилагоден домен со HTTPS. Погледнете како да поврзете прилагоден домен.
• Транзакциска е-пошта од верифициран домен за потврди при регистрација и враќање на лозинка — опфатено во како да испраќате е-пошта од вашата апликација.
• Политика за приватност и услови што ги опишуваат она што навистина го собирате. Не копирајте тврдења за усогласеност што не сте ги заслужиле.
• Канал за поддршка — дури и монитористичка адреса за е-пошта.
• Одвоени тест и живи клучеви за плаќања и е-пошта, и јасна белешка која околина користи кој.

Чекор 8: Чисто предавање

Пред или после, некој друг ќе работи на апликацијата: фриленсер, нов соосновач или вие за шест месеци. Направете го тоа едноставно:

• README што кажува како да се стартува, кои променливи на околината ѝ требаат (само имиња, никогаш вредности) и како се објавува.
• Листата на главни текови и автоматските тестови.
• Краток архитектонски опис: предниот дел, задниот дел, базата, надворешните услуги и каде е хостирано секое.
• Список за пристап: кој има администраторски пристап до доменот, хостингот, базата, плаќањата и сметките за е-пошта. Ставете ги овие сметки под деловна е-пошта, не лична.
• Кодот во Git, по можност синхронизиран со репозиториум што го поседувате. Ако подоцна ќе менувате хостинг, прочитајте како да извезете и самостојно хостирате апликација изградена со AI.

AI може да ви го напише најголемиот дел од ова:

Напиши README за овој проект за програмер што никогаш не го видел: што прави апликацијата, технолошкиот стек, како да се стартува локално, секоја променлива на околината што ја чита (само имиња и намена), како е организирана шемата на базата и како се објавува.

Список за подготвеност за производство

• Главните текови се запишани и тестирани, вклучително и „не може да пристапи до туѓи податоци“
• Овластување и валидација на серверот на секој маршрут за податоци
• Нема тајни клучеви во кодот на предниот дел; протечените клучеви се заменети
• Ограничување на барањата за автентикација и за сè што чини пари
• Следење на грешки и известувања за достапност што одат во инбоксот што го читате
• Резервни копии на базата надвор од хостингот на апликацијата, со еден успешен тест за враќање
• Страничење и индекси проверени со реални податоци
• Прилагоден домен, верифициран домен за испраќање, политика за приватност
• README и список за пристап за следниот што ќе работи на проектот

Да го направите ова со Mythex

Ако го изградивте прототипот во Mythex, повеќето од овие чекори се упатства во истиот проект. Напишете /test и Mythex ќе кликне низ живиот преглед како корисник и ќе ги пријави расипаните текови — видете App Testing. Клучевите одат во тајните на проектот, а не во разговорот; секој успешен чекор на агентот зачувува контролна точка на вашите датотеки на која можете да се вратите; а објавувањето ви дава жива URL-адреса со хостинг и базата наплатени од истиот кредитен баланс (ограничувањата на хостингот објаснуваат како апликациите и базите заспиваат и се будат). Контролните точки ги покриваат датотеките, не редовите во базата, па сепак планирајте резервни копии на податоците. На Pro можете да поврзете прилагоден домен и да го извезете кодот или да го синхронизирате со вашиот GitHub репозиториум за предавање.

Прашања