Ինչպես AI նախատիպը տանել արտադրության

AI նախատիպը արտադրության տանելու համար փակում եք բացը «երբ ես փորձում եմ՝ աշխատում է» և «երբ ուրիշներն օգտագործում են՝ շարունակում է աշխատել» միջև։ Գործնականում դա նշանակում է հինգ բան. թեստավորել հիմնական հոսքերը ամեն փոփոխությունից հետո, կողպել, թե ով կարող է տեսնել և փոխել ինչը, համոզվել, որ սխալների մասին իմանում եք, նախքան օգտատերերը կասեն, պահել տվյալները և ապացուցել, որ կարող եք վերականգնել, և հավելվածը պահել բավականաչափ արագ հեռախոսի վրա։ Ոչ մեկը չի պահանջում վերաշարադրում. սա ստուգաթերթ է, որն անցնում եք այն նույն AI-ի հետ, որը կառուցել է նախատիպը։

Նախատիպ և արտադրություն. ինչն է իրականում փոխվում

Նախատիպն ունի մեկ զգույշ օգտատեր՝ դուք։ Գիտեք, թե որ կոճակները սեղմել, մուտքագրում եք ողջամիտ տվյալներ, և եթե ինչ-որ բան կոտրվում է, թափահարում եք ուսերը և խնդրում AI-ին շտկել։ Արտադրությունն ունի շատ անզգույշ օգտատերեր, մի քանի հետաքրքրասեր և երբեմն թշնամական մեկը։ Կոդը պետք չէ դառնա «ձեռնարկության». այն պետք է կարողանա վարվել այն իրավիճակների հետ, որոնց նախատիպը երբեք չի հանդիպում։

Այս ուղեցույցի մնացած մասը անցնում է յուրաքանչյուր տողով։

Քայլ 1. Սահմանեք շրջանակը և գրեք հիմնական հոսքերը

Նախքան որևէ բան ամրապնդելը, որոշեք, թե ինչ է առաջին տարբերակը։ Ցուցակագրեք երեքից վեց հոսք, որոնք ամենակարևորն են, օրինակ՝ «գրանցվել, ստեղծել նախագիծ, հրավիրել գործընկեր, վճարել»։ Սրանք դառնում են ձեր թեստային սցենարը, ձեր մոնիտորինգի թիրախները և այն, ինչ ստուգում եք յուրաքանչյուր փոփոխությունից հետո։

Ցուցակում չգտնվող ցանկացած բան կա՛մ կտրվում է, կա՛մ հստակ նշվում որպես բետա։ Չորս հոսք հուսալի դարձնելը շատ ավելի հեշտ է, քան տասնչորսը։

Քայլ 2. Թեստավորեք որպես օտար, ապա դարձրեք կրկնվող

ԱI կառուցողները լավն են արտադրելու կոդ, որը աշխատում է «երջանիկ ուղու» վրա։ Արտադրության խնդիրները ապրում են «անբախտ» ուղիներում։ Թեստավորեք յուրաքանչյուր հիմնական հոսք հետևյալով.

• Սխալ մուտքագրում. պարտադիր դաշտեր դատարկ, 5000 նիշանոց անուն, էլփոստ առանց @-ի, բացասական քանակ, անցյալի ամսաթիվ։
• Թարմացումներ և հետ կոճակներ. վերբեռնեք էջը ճանապարհի կեսում. սեղմեք հետ ձևը ուղարկելուց հետո։ Ստեղծվում է ինչ-որ բան երկու անգամ։
• Երկու ներդիր, երկու օգտատեր. մուտք գործեք որպես երկու տարբեր հաշիվ և փորձեք բացել միմյանց էջերը՝ փոխելով ID-ն URL-ում։
• Դանդաղ և փոքր. հեռախոսի չափի էկրան և դանդաղեցված կապ (զննարկիչի գործիքները կարող են դա մոդելավորել)։
• Դատարկ վիճակներ. նոր հաշիվ առանց տվյալների։ Նախատիպերը հաճախ կառուցվում են նմուշային տվյալներով և թվում են կոտրված առանց դրանց։

Հետո դարձրեք ստուգումը կրկնվող. նվազագույնը պահեք գրավոր ստուգաթերթ և գործարկեք այն յուրաքանչյուր թողարկումից առաջ։ Ավելի լավ է՝ խնդրեք AI-ին գրել ավտոմատ թեստեր այն հոսքերի համար, որոնք ամենակարևորն են.

Ավելացրեք ավտոմատ ծայրից ծայր թեստեր այս հոսքերի համար. գրանցում էլփոստով, նախագծի ստեղծում, երկրորդ օգտատիրոջ հրավիրում և վճարում Stripe-ի թեստային ռեժիմում։ Ավելացրեք նաև թեստեր, որոնք հաստատում են, որ օգտատերը չի կարող դիտել կամ փոխել մեկ այլ օգտատիրոջ նախագիծը՝ URL-ը փոխելով։

Թեստերը, որոնք ապացուցում են, որ օգտատերը չի կարող ինչ-որ բան անել, այն են, որ նախատիպերից առավել հաճախ բացակայում են։

Քայլ 3. Անվտանգության հիմունքներ, որ նախատիպերը բաց են թողնում

AI-ով կառուցված հավելվածների անվտանգության խնդիրները սովորաբար էկզոտիկ չեն։ Դրանք բացակայող ստուգումներ են։ Անցեք այս ցուցակը, և տես ավելի ամբողջական անվտանգության ստուգաթերթը AI-ով կառուցված հավելվածների համար:

• Թույլտվություն սերվերի վրա։ Կոճակը թաքցնելը անվտանգություն չէ։ Յուրաքանչյուր հարցում, որ կարդում կամ փոխում է տվյալները, պետք է սերվերի վրա ստուգի, որ մուտք գործած օգտատերն իրավունք ունի։ Եթե ձեր հավելվածն օգտագործում է տվյալների բազա տողային կանոններով, ստուգեք, որ դրանք միացված են և փորձարկված։
• Գաղտնիքները դուրս բրաուզերից։ Վճարումների, էլփոստի կամ AI մատակարարների API բանալիները պետք է լինեն սերվերային միջավայրի փոփոխականներ, երբեք ոչ առջևի կոդում։ Եթե վստահ չեք, թե դա ինչ է նշանակում, կարդացեք ինչ են միջավայրի փոփոխականները և գաղտնիքները։
• Վավերացում սերվերի վրա։ Բրաուզերը կարող է շրջանցվել, ուստի կրկնեք յուրաքանչյուր կարևոր ստուգում սերվերի վրա։
• Մուտքը ճիշտ կատարված։ Օգտագործեք լավ փորձարկված նույնականացման գրադարան կամ ծառայություն, այլ ոչ թե ձեռքով գաղտնաբառերի պահում։ Մեր ուղեցույցը հավելվածին մուտք ավելացնելու մասին ներկայացնում է տարբերակները։
• Հաճախականության սահմանափակումներ մուտքի, գրանցման, գաղտնաբառի վերականգնման և ցանկացած էլփոստ ուղարկող կամ վճարովի API կանչող գործողությունների վրա։
• Հասկանալի սխալներ։ Օգտատերերը պետք է տեսնեն «ինչ-որ բան սխալ ընթացավ»․ մանրամասները գնում են ձեր գրանցամատյաններ, ոչ թե էկրան։
• Պտտեք ցանկացած արտահոսած բանալի։ Եթե կենդանի բանալի երբևէ տեղադրվել է զրույցում, commit-ում կամ սքրինշոթում, փոխեք այն մատակարարի մոտ։

Մեկ հուշում, որը ծածկում է շատ գետնից միանգամից.

Վերանայեք այս հավելվածը արտադրական անվտանգության համար։ Ստուգեք, որ յուրաքանչյուր API երթուղի հաստատում է, որ մուտք գործած օգտատերը սեփականատերն է գրառման, որը կարդում կամ փոխում է, որ գաղտնի բանալիները չեն ուղարկվում բրաուզեր, որ մուտքագրումը վավերացվում է սերվերի վրա և որ մուտքը և գաղտնաբառի վերականգնումը հաճախականությամբ սահմանափակված են։ Նախքան որևէ բան փոխելը, թվարկեք գտածները։

Ցուցակի առաջին ցուցադրումը թույլ է տալիս տեսնել խնդիրները և որոշել հերթականությունը, այլ ոչ թե ստանալ մեկ հսկա փոփոխություն։

Քայլ 4. Իմացեք, երբ է կոտրվում. գրանցում և մոնիտորինգ

Նախադիտման մեջ սխալները տեսնում եք, երբ դրանք տեղի են ունենում։ Արտադրության մեջ հավելվածը պետք է ասի ձեզ։ Երեք շերտ՝ ամենաէժանից մինչև ամենաօգտակարը.

1. Սերվերի գրանցամատյաններ. համոզվեք, որ սխալները գրանցվում են բավարար համատեքստով՝ վերարտադրելու համար. որ երթուղի, որ օգտատիրոջ ID (ոչ գաղտնաբառ կամ քարտ), ինչ մուտքի ձև։ Եթե հավելվածը միայն տպում է կոնսոլում, խնդրեք AI-ին ավելացնել կառուցվածքային գրանցում։
2. Սխալների հետևում. Sentry-ի կամ նմանատիպ գործիքը գրավում է առջևի և հետին մասի բացառությունները, խմբավորում դրանք և էլփոստ է ուղարկում ձեզ։ Փոքր հավելվածի համար դրանց անվճար պլանները հաճախ բավարար են. ստուգեք ընթացիկ սահմանաչափերը նրանց կայքերում։
3. Աշխատանքի ստուգումներ (uptime). Արտաքին ծառայություն, որը բեռնում է ձեր գլխավոր էջը և մեկ հիմնական API երթուղի յուրաքանչյուր մի քանի րոպեն մեկ և զգուշացնում է, եթե դրանք ձախողվում են։ Սա բռնում է այն խնդիրները, որոնք ընդհանրապես դադարեցնում են գրանցումը։

Ավելացրեք ևս մեկ սովորություն. յուրաքանչյուր թողարկումից հետո բացեք կենդանի հավելվածը և կատարեք հիմնական հոսքերի ստուգաթերթը իրական URL-ում, ոչ միայն նախադիտման։

Քայլ 5. Պահուստներ և հետդարձի ուղի

Պետք է պաշտպանել երկու տարբեր բան, և դրանք հեշտ է շփոթել.

• Կոդ. պահեք նախագիծը տարբերակների վերահսկողության մեջ, որպեսզի յուրաքանչյուր փոփոխություն կարողանա հետարկվել։ Շատ AI կառուցողներ պահում են ձեր ֆայլերի ստուգակետեր. համաժամեցումը Git-ի պահոցի հետ տալիս է պատճեն կառուցողից դուրս։
• Տվյալներ. կոդի ստուգակետերը տվյալների բազան չեն վերականգնում։ Վատ միգրացիան կամ սխալ ջնջման կոճակը կարող են ոչնչացնել տողեր, որոնք ոչ մի կոդի ստուգակետ չի վերադարձնի։

Տվյալների համար կարգավորեք կանոնավոր պահուստներ՝ պահված հավելվածի սեփական հոստինգից դուրս։ Postgres տվյալների բազայի համար սովորական մոտեցումը պլանավորված pg_dump-ն է առանձին պահեստում, և շատ կառավարվող տվյալների բազաների հոստեր առաջարկում են ավտոմատ պահուստներ կամ point-in-time վերականգնում։ Հետո արեք այն քայլը, որը շատերը բաց են թողնում. վերականգնեք պահուստը առանձին փորձնական տվյալների բազայի մեջ և ստուգեք, որ տվյալները կան։

Կարող եք նաև խնդրել AI-ին անվտանգ դարձնել կործանարար գործողությունները. հաստատման քայլ ջնջումների համար և «փափուկ ջնջում» (տողերը նշվում են որպես ջնջված, այլ ոչ թե հեռացվում) այն ամենի համար, ինչ օգտատերերը կարող են ուզել հետ բերել։

Քայլ 6. Արագություն, որը դիմանում է հեռախոսի վրա

Նախատիպերը արագ են թվում, որովհետև դուք միակ օգտատերն եք, և տվյալների հավաքածուն փոքր է։ Գործարկումից առաջ.

• Բեռնեք իրական չափի տվյալներ. խնդրեք AI-ին լրացնել մի քանի հազար տող և տեսնել, թե որ էջերն են դանդաղում։ Ցուցակները սովորաբար պահանջում են էջավորում, իսկ տվյալների բազան՝ ինդեքսներ այն սյունակների վրա, որոնցով ֆիլտրում և դասավորում եք։
• Փոքրացրեք պատկերները. Չափից մեծ պատկերները էջի դանդաղ բեռնման ամենատարածված պատճառն են։ Խնդրեք չափափոխված, սեղմված պատկերներ և lazy loading ծալքից ներքև։
• Չափեք. Գործարկեք Lighthouse Chrome-ի dev tools-ում կենդանի URL-ի վրա բջջային ռեժիմում։ Google-ի Core Web Vitals-ը խելամիտ նպատակ է. Largest Contentful Paint՝ 2,5 վայրկյանում կամ ավելի արագ, Interaction to Next Paint՝ 200 ms կամ պակաս, և Cumulative Layout Shift՝ 0,1 կամ պակաս։
• Նայեք «արթնացման» ուշացումներին. Հոստինգը, որը քնում է անգործության ժամանակ, խնայում է գումար, բայց դարձնում է առաջին այցը դանդաղ լռության երկար շրջանից հետո։ Նոր հավելվածի համար դա հաճախ ընդունելի փոխզիջում է, պարզապես իմացեք, որ այն տեղի է ունենում։

Նախագծերի էջը դանդաղ է 5000 տողով։ Ավելացրեք սերվերային էջավորում (25 մեկ էջում), ավելացրեք տվյալների բազայի ինդեքսներ այն սյունակների համար, որոնցով ֆիլտրում և դասավորում ենք, և ցուցադրեք բեռնման վիճակ, մինչև հաջորդ էջը բեռնվի։

Քայլ 7. Օպերացիոն հիմունքներ

Մի քանի փոքր բան տարբերում են հոբբի հավելվածը այն հավելվածից, որին մարդիկ վստահում են.

• Անհատական դոմեն HTTPS-ով։ Տես ինչպես միացնել հատուկ դոմեն։
• Գործարքային էլփոստ ստուգված դոմենից՝ գրանցման հաստատումների և գաղտնաբառի վերականգնման համար. ներառված է ինչպես ուղարկել էլփոստ ձեր հավելվածից ուղեցույցում։
• Գաղտնիության քաղաքականություն և պայմաններ, որոնք նկարագրում են, թե իրականում ինչ եք հավաքում։ Մի պատճենեք համապատասխանության պնդումներ, որոնք չեք ապահովել։
• Աջակցության ուղի. նույնիսկ վերահսկվող էլփոստի հասցե։
• Առանձին թեստային և կենդանի բանալիներ վճարումների և էլփոստի համար, և հստակ նշում, թե որ միջավայրն է օգտագործում որ բանալին։

Քայլ 8. Մաքուր հանձնում

Մի օր ինչ-որ մեկը կաշխատի հավելվածի վրա՝ ֆրիլանսեր, նոր համահիմնադիր կամ դուք վեց ամիս հետո։ Հեշտացրեք դա.

• README, որը ասում է, թե ինչպես գործարկել այն, ինչ միջավայրի փոփոխականներ է պահանջում (միայն անուններ, երբեք արժեքներ) և ինչպես տեղակայել։
• Հիմնական հոսքերի ստուգաթերթը և ավտոմատ թեստերը։
• Կարճ ճարտարապետական նշում. առջևի մաս, հետին մաս, տվյալների բազա, երրորդ կողմի ծառայություններ և յուրաքանչյուրը որտեղ է հոստված։
• Մուտքի ցուցակ. ով ունի ադմինի մուտք դոմենին, հոստինգին, տվյալների բազային, վճարումների և էլփոստի հաշիվներին։ Դրեք այս հաշիվները բիզնես էլփոստի տակ, ոչ թե անձնականի տակ։
• Կոդը Git-ում, ցանկալի է համաժամեցված ձեր սեփական պահոցի հետ։ Եթե հետագայում կարող եք փոխել հոստինգը, կարդացեք ինչպես արտահանել և ինքնուրույն հոստել AI-ով կառուցված հավելված։

AI-ն կարող է գրել սրա մեծ մասը ձեզ համար.

Գրեք README այս նախագծի համար մեկի համար, ով երբեք չի տեսել այն. ինչ է անում հավելվածը, տեխնոլոգիական կույտը, ինչպես գործարկել տեղում, յուրաքանչյուր միջավայրի փոփոխական, որը կարդում է (միայն անուններ և նշանակություն), ինչպես է կազմակերպված տվյալների բազայի սխեման և ինչպես տեղակայել այն։

Արտադրության պատրաստության ստուգաթերթ

• Հիմնական հոսքերը գրված և փորձարկված, ներառյալ «չի կարող մուտք գործել ուրիշի տվյալներ»
• Սերվերային թույլտվություն և վավերացում յուրաքանչյուր տվյալների երթուղու վրա
• Գաղտնի բանալիներ չկան առջևի կոդում. արտահոսած բանալիները պտտված են
• Հաճախականության սահմանափակումներ մուտքի և ցանկացած արժող գործողության վրա
• Սխալների հետևում և աշխատանքի ստուգումներ՝ ուղղված դեպի մեկ ստուգվող մուտքի արկղ
• Տվյալների բազայի պահուստներ՝ հավելվածի հոստինգից դուրս, մեկ հաջող փորձնական վերականգնումով
• Էջավորումը և ինդեքսները ստուգված իրական տվյալներով
• Հատուկ դոմեն, ստուգված ուղարկող դոմեն, գաղտնիության քաղաքականություն
• README և մուտքի ցուցակ հաջորդի համար

Mythex-ով

Եթե նախատիպը կառուցել եք Mythex-ում, այս քայլերից շատերը նույն նախագծի հուշումներ են. գրեք /test և Mythex-ը կենդանի նախադիտման վրա կանցնի՝ որպես օգտատեր, և կհաղորդի կոտրված հոսքերի մասին. տես App Testing։ Բանալիները մտնում են նախագծի գաղտնիքների մեջ, այլ ոչ թե զրույցի, և յուրաքանչյուր հաջող գործակալի քայլից հետո պահպանվում է ձեր ֆայլերի ստուգակետ, որին կարող եք վերադառնալ. հրապարակումը տալիս է կենդանի URL, իսկ հոստինգը և տվյալների բազան վճարվում են նույն կրեդիտների հաշվեկշռից. (հոստինգի սահմանաչափերը բացատրում է, թե ինչպես են հավելվածները և տվյալների բազաները քնում և արթնանում)։ Ստուգակետերը պահում են ֆայլեր, ոչ տվյալների բազայի տողեր, ուստի դեռ պլանավորեք տվյալների պահուստները։ Pro պլանում կարող եք միացնել հատուկ դոմեն և արտահանել կոդը կամ համաժամեցնել այն ձեր սեփական GitHub պահոցի հետ՝ հանձնման համար։

Հարցեր