Гарын авлагууд

AI прототипоос продакшн хүртэл хэрхэн авч явах вэ

AI прототипийг продакшн руу шилжүүлэхийн тулд «миний туршихад ажилладаг» ба «бусад хүн ашиглахад ажилладаг» хоорондох зайг арилгана. Практикт энэ нь таван зүйл гэсэн үг: өөрчлөлт бүрийн дараа гол урсгалуудаа шалгах, хэн юуг харах, өөрчлөх эрхтэйг хатуу хязгаарлах, алдааг хэрэглэгч хэлэхээс өмнө мэдэх, өгөгдлөө нөөцлөөд сэргээж чадна гэдгээ батлах, мөн утсан дээр хурдан ажиллуулах. Эдгээрийн аль нь ч дахин бичих шаардлагагүй — энэ бол прототипийг бүтээсэн AI-тай хамт давж гарах шалгах жагсаалт юм.

Прототип ба продакшн: юу жинхэнэ өөрчлөгддөг вэ

Прототипд нэг болгомжтой хэрэглэгч байдаг: та. Та аль товчийг дарахаа мэддэг, оруулгаа зохистой өгдөг, алдаа гарвал мөрийг хавьж AI-аас засах хүсэлт тавьдаг. Продакшнд олон хайнга, сониуч, заримдаа дайсагнасан хэрэглэгчид байдаг. Код «корпорацийн» болох ёсгүй; прототип хэзээ ч тулгардаггүй нөхцөл байдлуудад бэлтгэгдсэн байх ёстой.

ТалбарПрототипПродакшн
ӨгөгдөлЖишээ мөрүүд, амархан шинэчлэхАлдаж болшгүй жинхэнэ үйлчлүүлэгчийн өгөгдөл
ХэрэглэгчТа, админаар нэвтэрсэнӨөр эрхтэй олон бүртгэл
ОруулгаТаны бичсэн зүйлХоосон талбар, асар том файл, хачин тэмдэгт, скрипт
АлдааУрьдчилан харагдах цонхонд харагддагТаныг унтаж байхад гардаг
ӨөрчлөлтЗасаад харХэрэглэгчид найдаж буй зүйлээ эвдэхгүйгээр өөрчлө
НууцлалТуршилтын түлхүүрт ямар ч зүйл болноМөнгө алдагдах эрсдэлтэй жинхэнэ түлхүүрүүд

Энэ гарын авлагын үлдсэн хэсэг нь мөр бүрийг дэлгэрэнгүй тайлбарлана.

Алхам 1: Хамрах хүрээгээ тогтоож, гол урсгалуудаа бичээрэй

Хатууруулахаасаа өмнө эхний хувилбар юу байхыг шийд. Хамгийн чухал гурваас зургаан урсгалыг жагсаа, жишээ нь «бүртгүүлэх, төсөл үүсгэх, хамтрагч урих, төлөх». Эдгээр нь таны туршилтын скрипт, хяналтын зорилт, өөрчлөлт бүрийн дараа шалгах зүйлс болно.

Жагсаалтад байхгүй зүйл бүр аль нь хасагдах эсвэл бета гэж тодорхой тэмдэглэгдэх ёстой. Арван дөрвөн урсгалыг найдвартай болгохоос дөрвөн урсгалыг найдвартай болгох нь хамаагүй хялбар.

Алхам 2: Шинээр орсон хэрэглэгч шиг туршаад, дараа нь давтагдах болго

AI бүтээгчид зөв замд ажилладаг код бичихэд сайн. Продакшны асуудлууд буруу замд байдаг. Гол урсгал бүрийг дараахаар туршаарай:

  • Буруу оруулга: хоосон шаардлагатай талбар, 5,000 тэмдэгтийн нэр, @-гүй имэйл, сөрөг тоо, өнгөрсөн огноо.
  • Дахин ачаалалт ба буцах товч: төлбөрийн хуудсын дундуур дахин ачаалах; маягт илгээсний дараа буцах товч дарах. Юу хоёр удаа үүсэж байна вэ?
  • Хоёр таб, хоёр хэрэглэгч: хоёр өөр бүртгэлээр нэвтэрч, URL дэх ID-г солиод нөгөөгийнхөө хуудсыг нээж үзэх.
  • Жижиг ба удаан: утасны хэмжээний дэлгэц, удаашруулсан холбоос (браузерийн dev tools-д дуурайж болно).
  • Хоосон төлөв: шинэ хэрэглэгч, ямар ч өгөгдөлгүй. Прототипүүд ихэвчлэн жишээ өгөгдөлтэй бүтээгддэг тул өгөгдөлгүй байхад эвдэрсэн мэт харагддаг.

Дараа нь шалгалтаа давтагдах болго. Хамгийн багадаа бичгэн жагсаалт барьж, хувилбар гаргахаасаа өмнө ажиллуул. Илүү сайн нь, хамгийн чухал урсгалуудад автомат туршилт бичихийг AI-д хүс:

Дараах урсгалуудад автомат end-to-end тест нэм: имэйлээр бүртгүүлэх, төсөл үүсгэх, хоёр дахь хэрэглэгч урих, Stripe-ийн туршилтын горимд төлбөр хийх. Мөн URL-ийг өөрчлөн хэрэглэгч өөр хэрэглэгчийн төслийг харах эсвэл засаж чадахгүй гэдгийг баталдаг тест нэм.

Хэрэглэгч ямар нэг зүйлийг хийж чадахгүй гэдгийг баталдаг тестүүд нь прототипүүдэд ихэвчлэн дутагддаг.

Алхам 3: Прототипүүдийн орхидог аюулгүй байдлын үндэс

AI-аар бүтээсэн аппликейшнүүдийн аюулгүй байдлын асуудлууд ихэвчлэн онцгой биш. Тэд дутуу шалгалтууд юм. Энэ жагсаалтыг судлаарай, мөн AI-аар бүтээсэн аппликейшний аюулгүй байдлын шалгах жагсаалт-ийг дэлгэрэнгүй үзээрэй:

  • Серверт эрхийн шалгалт. Товчлуурыг нуух нь аюулгүй байдал биш. Өгөгдөл унших эсвэл өөрчлөх хүсэлт бүр нэвтэрсэн хэрэглэгч тэр зүйлд эрхтэй эсэхийг серверт шалгах ёстой. Хэрэв таны аппликейшн мөрийн түвшний дүрэмтэй өгөгдлийн сан ашигладаг бол тэдгээр асаалттай, туршигдсан эсэхийг шалга.
  • Нууц түлхүүрүүд браузераас гадуур. Төлбөр, имэйл эсвэл AI үйлчилгээ үзүүлэгчийн API түлхүүрүүд серверийн орчны хувьсагчид байх ёстой, урд талын кодонд хэзээ ч байж болохгүй. Хэрэв энэ юу гэсэнийг мэдэхгүй бол орчны хувьсагч ба нууц түлхүүр гэж юу вэ гэдгийг унш.
  • Серверт баталгаажуулалт. Браузер тойрч гарч болно тул чухал шалгалт бүрийг серверт давтан хий.
  • Найдвартай нэвтрэлт. Нууц үг хадгалах өөрөө бичсэн системийн оронд сайн туршигдсан баталгаажуулалтын сан эсвэл үйлчилгээ ашигла. Аппликейшндаа нэвтрэлт нэмэх нь гарын авлага сонголтуудыг тайлбарласан.
  • Хурдны хязгаар нэвтрэх, бүртгүүлэх, нууц үг сэргээх болон имэйл илгээдэг эсвэл төлбөртэй API дууддаг бүх зүйлд.
  • Найрсаг алдаа. Хэрэглэгч «ямар нэг зүйл буруу боллоо» гэж харах ёстой; дэлгэрэнгүйг лог руу, дэлгэцэд биш илгээ.
  • Задарсан бүх зүйлийг солих. Амьд түлхүүр чатанд, коммитод эсвэл дэлгэцийн зурагт хуулагдсан бол үйлчилгээ үзүүлэгчдээр солиулаарай.

Нэг дор олон зүйлийг хамарсан промпт:

Энэ аппликейшныг продакшн аюулгүй байдлын хувьд шалга. Бүх API маршрут нь унших эсвэл өөрчлөх бичлэгийнхээ эзэнийг нэвтэрсэн хэрэглэгч мөн эсэхийг шалгаж байгаа, нууц түлхүүр браузерт илгээгдэхгүй байгаа, оруулгыг серверт баталгаажуулж байгаа, нэвтрэх болон нууц үг сэргээхийг хурдны хязгаартай болгосон эсэхийг шалга. Юу олсноо өөрчлөхөөсөө өмнө жагсаа.

Эхлээд жагсаалт авах нь асуудлуудыг харж, дарааллыг шийдэх боломж олгодог, нэг том өөрчлөлт хүлээн авахаас илүү.

Алхам 4: Юу эвдэрч байгааг мэдэх — лог ба хяналт

Урьдчилан харах цонхонд та алдааг тэр даруй харна. Продакшнд аппликейшн таныг мэдэгдэх ёстой. Гурван давхарга, хамгийн хямдаас хамгийн ашигтай хүртэл:

  1. Серверийн лог. Алдаа дахин үүсгэхэд хангалттай мэдээлэлтэй лог болсон эсэхийг шалга: аль маршрут, аль хэрэглэгчийн ID (нууц үг, картын мэдээлэл биш), оруулгын хэлбэр. Аппликейшн зөвхөн консол руу хэвлэдэг бол бүтэцтэй лог нэмэхийг AI-д хүс.
  2. Алдаа хянах. Sentry эсвэл төстэй үйлчилгээ урд болон хойд талын алдааг барьж, бүлэглэж, танд имэйлээр илгээдэг. Жижиг аппликейшний хувьд эдгээр үйлчилгээний үнэгүй төлөвлөгөө ихэвчлэн хангалттай; одоогийн хязгаарыг тэдний сайтаас шалга.
  3. Ажиллаж байгаа эсэхийг шалгах. Гадаад үйлчилгээ таны нүүр хуудас болон гол API маршрутыг хэдэн минут тутамд ачаалж, алдаа гарвал дохио өгдөг. Энэ нь аппликейшн лог хийж чадахгүй болгох асуудлуудыг барьдаг.

Нэг зуршил нэмээрэй: шинэ хувилбар гаргасан бүрийн дараа амьд аппликейшнээ нээж, гол урсгалын шалгах жагсаалтаа зөвхөн урьдчилан харалт дээр биш, жинхэнэ URL дээр ажиллуул.

Алхам 5: Нөөцлөлт болон буцах зам

Хоёр өөр зүйлийг хамгаалах хэрэгтэй бөгөөд тэдгээрийг андуурах хялбар.

  • Код. Аливаа өөрчлөлтийг буцаах боломжтой байхын тулд төслөө хувилбарын удирдлагад байлгаарай. Олон AI бүтээгч таны файлуудын checkpoint хадгалдаг; Git репозиторт синк хийх нь бүтээгчээс гадуур хуулбар өгдөг.
  • Өгөгдөл. Кодыг буцаах нь өгөгдлийн санг буцаадаггүй. Буруу миграци эсвэл буруу устгах товч нь ямар ч кодын checkpoint сэргээж чадахгүй мөрүүдийг устгаж болно.

Өгөгдлийн хувьд аппликейшний хостингоос бусад газар хадгалагдсан байнгын нөөцлөлтийг тохируул — Postgres өгөгдлийн сангийн хувьд тогтоосон pg_dump-ыг тусдаа хадгалах зай руу явуулах нь түгээмэл арга, мөн олон удирдлагатай өгөгдлийн сангийн хост автомат нөөцлөлт эсвэл цэг хүртэлх сэргээлт санал болгодог. Дараа нь хүмүүсийн ихэвчлэн алгасдаг алхмыг хий: нөөцлөлтөө туршилтын өгөгдлийн санд сэргээж, өгөгдөл байгаа эсэхийг шалга.

Мөн устгах үйлдлийг аюулгүй болгохыг AI-д хүс: устгахад баталгаажуулах алхам, хэрэглэгчид буцааж авахыг хүсэж болох зүйлд «зөөлөн устгал» (мөрийг устгахгүй, устсан гэж тэмдэглэх).

Алхам 6: Утсан дээр хурдан ажиллах гүйцэтгэл

Прототипүүд хурдан мэт санагддаг, учир нь та ганцаараа хэрэглэгч, өгөгдлийн багц бага. Нээхээсээ өмнө:

  • Жинхэнэ хэмжээтэй өгөгдөл ачаал. AI-аас хэдэн мянган мөр оруулахыг хүсэж, аль хуудас удаашрахыг хар. Жагсаалтад ихэвчлэн хуудаслалт (pagination), өгөгдлийн санд шүүж эрэмбэлдэг баганууд дээр индекс хэрэгтэй.
  • Зургийг багасга. Хэт том зураг хуудас удаан ачаалах хамгийн түгээмэл шалтгаан. Хэмжээ нь багасгасан, шахсан зураг болон доод хэсэгт ачаалах (lazy loading) хийхийг хүс.
  • Хэмж. Амьд URL дээр Chrome-ийн dev tools-ийн Lighthouse-ыг утасны горимд ажилуул. Google-ийн Core Web Vitals нь ухаалаг зорилт: 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-ийг үзээрэй. Түлхүүрүүд чатанд биш төслийн нууцад орно, агентын амжилттай ажиллагаа бүр таны файлуудын checkpoint хадгалж, буцааж болно, нийтлэх нь хостинг болон өгөгдлийн сангийн хэрэглээтэй амьд URL өгдөг бөгөөд нэг кредитийн баланснаас тооцогддог (хостингийн хязгаарлалт аппликейшн болон өгөгдлийн санг хэрхэн унтаж, сэрдгийг тайлбарлана). Checkpoint нь файлуудыг хамгаална, өгөгдлийн сангийн мөрүүдийг биш, тиймээс өгөгдлийн нөөцлөлтөө хийхээ мартаж болохгүй. Pro-д захиалгат домэйн холбож, кодоо экспортлох эсвэл өөрийн GitHub репозиторт синк хийж хүлээлгэн өгч болно.

Асуултууд

Прототип болон продакшн аппликейшний ялгаа юу вэ?

Прототип нь таныг анхаарлтай ашиглахад санаа ажилладгийг батлана. Продакшн аппликейшн нь хайнгүй хэрэглэгчид хайнга ашиглахад ажилладаг байх ёстой: тэдний өгөгдлийг хамгаалж, буруу оруулгад тэсвэртэй байж, эвдрэхэд чинь мэдэгдэж, буцааж сэргээгдэх боломжтой байна.

AI-аар бүтээсэн аппликейшнийг продакшнд ашиглаж болох уу?

Тийм, хэрэв бусад аппликейшнийг шалгадаг шиг шалгавал. AI-ийн бичсэн код бол энгийн код; харин ихэвчлэн хүсэхгүй бол орхигддог зүйл бол хэрэглэгчийн эрхийн шалгалт, оруулгын баталгаажуулалт, алдааны боловсруулалт, бүртгэл болон нөөцлөлт юм.

Нээхээсээ өмнө автомат тест хэрэгтэй юу?

Хувилбар гаргах бүрийн өмнө гол урсгалуудаа дахин давтагдах аргаар шалгах хэрэгтэй. Жижиг аппликейшний хувьд энэ нь бичсэн дараалсан шалгах жагсаалт байж болно; аппликейшн өсөх тусам мөнгө үүсгэдэг эсвэл алддаг урсгалуудад автомат тест бичихийг AI-д хүс.

Аппликейшний өгөгдлийн санг хэрхэн нөөцлөх вэ?

Өгөгдлийн санг байнга экспортлож (Postgres-ийн хувьд pg_dump), аппликейшний хостингоос бусад газарт хадгал. Дараа нь дор хаяж нэг удаа сэргээлт хийж туршаарай, учир нь туршаагүй нөөцлөлт бол зүгээр л найдлага.

Mythex · Pricing · AI-аар юуг ч бүтээ · Вэбсайт болон аппын загварууд · Mythex-ийн харьцуулалт · AI-аар апп бүтээх тайлбар толь · AI-аар апп бүтээх үнэгүй хэрэгслүүд · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)