როგორ გადავიყვანოთ AI პროტოტიპი წარმოებაში

AI პროტოტიპის წარმოებაში გასატანად ამოავსებთ უფსკრულს იმას შორის, რომ „როცა ვცდი, მუშაობს“, და იმას შორის, რომ „როცა სხვები იყენებენ, მუშაობს“. პრაქტიკაში ეს ხუთ რამეს ნიშნავს: ყოველი ცვლილების შემდეგ ტესტირება მთავარი პროცესებისა, შეზღუდვა იმისა, ვინ ხედავს და ცვლის რას, იმის უზრუნველყოფა, რომ შეცდომებს თქვენ მომხმარებლებამდე გაიგებთ, მონაცემების სარეზერვო ასლები და მათი აღდგენის დადასტურება, და აპის სისწრაფე ტელეფონზეც. არც ერთი ეს არ მოითხოვს გადაწერას — ეს არის ჩამონათვალი, რომელსაც იმავე AI-თან ერთად გაივლით, რომელმაც პროტოტიპი ააშენა.

პროტოტიპი და წარმოება: რა იცვლება სინამდვილეში

პროტოტიპს ერთი ფრთხილი მომხმარებელი ჰყავს: თქვენ. იცით, რომელ ღილაკებს დააჭიროთ, სწორ შეყვანას წერთ, და თუ რამე ირღვევა, მხრებს იჩეჩავთ და AI-ს ეუბნებით, გაასწოროს. წარმოებაში ბევრი უზრუნველყოფილი მომხმარებელია, ზოგი ცნობისმოყვარე, ხოლო ზოგჯერ — ერთი მტრული. კოდი არ უნდა გახდეს „საწარმოო“; მან უნდა გაუმკლავდეს სიტუაციებს, რომლებსაც პროტოტიპი არასდროს ხვდება.

გიდი დანარჩენ ნაწილში თითოეულ მწკრივს განიხილავს.

ნაბიჯი 1: შეაჩერეთ ფარგლები და ჩაწერეთ მთავარი პროცესები

მაგრამ სანამ რამეს გააძლიერებთ, გადაწყვიტეთ, რა არის პირველი ვერსია. ჩამოწერეთ სამიდან ექვს პროცესამდე, რომელიც ყველაზე მნიშვნელოვანია — მაგალითად „რეგისტრაცია, პროექტის შექმნა, თანამშრომლის მოწვევა, გადახდა“. ეს გახდება თქვენი ტესტირების სცენარი, თქვენი მონიტორინგის სამიზნეები და ის, რაც ყოველი ცვლილების შემდეგ უნდა შეამოწმოთ.

ყველაფერი, რაც სიაში არ არის, ან იჭრება, ან მკაფიოდ იწერება როგორც ბეტა. ოთხი საიმედო პროცესის გაკეთება ბევრად ადვილია, ვიდრე თოთხმეტის.

ნაბიჯი 2: ტესტირება როგორც უცნობი, შემდეგ განმეორებადად

AI შემქმნელები კარგად წერენ კოდს, რომელიც „ბედნიერ გზაზე“ მუშაობს. წარმოების პრობლემები კი არაბედნიერ გზებზე ჩნდება. თითოეული მთავარი პროცესი შეამოწმეთ შემდეგით:

• ცუდი შეყვანა: ცარიელი სავალდებულო ველები, 5,000-სიმბოლოიანი სახელი, ელფოსტა @-ნიშნის გარეშე, უარყოფითი რაოდენობა, წარსულში დატანილი თარიღი.
• განახლება და უკან დაბრუნება: გადატვირთეთ გვერდი ჩექაუთის შუაში; დააჭირეთ უკან ფორმის გაგზავნის შემდეგ. ხომ არ იქმნება რამე ორჯერ?
• ორი ჩანართი, ორი მომხმარებელი: შედით ორი სხვადასხვა ანგარიშით და სცადეთ, გახსნათ ერთმანეთის გვერდები URL-ში ID-ის შეცვლით.
• ნელი და პატარა: ტელეფონის ეკრანი და შეზღუდული კავშირი (ბრაუზერის დეველოპერის ხელსაწყოებით შეგიძლიათ სიმულაცია).
• ცარიელი მდგომარეობები: ახალი ანგარიში მონაცემების გარეშე. პროტოტიპები ხშირად ნიმუშის მონაცემებით აშენდება და მათ გარეშე გაუმართავად გამოიყურება.

შემდეგ გაიმეორეთ შემოწმება. მინიმუმ, შეინახეთ წერილობითი ჩამონათვალი და გაუშვით ყოველ გამოშვებამდე. უკეთესი, სთხოვეთ AI-ს დაწეროს ავტომატური ტესტები იმ პროცესებისთვის, რომლებიც ყველაზე მნიშვნელოვანია:

დაამატე ავტომატური ბოლო-ბოლომდე ტესტები ამ პროცესებისთვის: რეგისტრაცია ელფოსტით, პროექტის შექმნა, მეორე მომხმარებლის მოწვევა და შეძენა Stripe-ის ტესტურ რეჟიმში. ასევე დაამატე ტესტები, რომლებიც დაადასტურებენ, რომ მომხმარებელს არ შეუძლია სხვისი პროექტის ნახვა ან რედაქტირება URL-ის შეცვლით.

ტესტები, რომლებიც ამტკიცებს, რომ მომხმარებელს რაიმეს ვერ გააკეთებს, ყველაზე ხშირად სწორედ ის არის, რაც პროტოტიპებს აკლია.

ნაბიჯი 3: უსაფრთხოების საფუძვლები, რომლებსაც პროტოტიპები გამოტოვებს

AI-ით აშენებული აპების უსაფრთხოების პრობლემები იშვიათად ეგზოტიკურია. ისინი ხშირად აკლია შემოწმებები. გაიარეთ ეს სია და იხილეთ უფრო სრული უსაფრთხოების ჩეკლისტი AI-ით აშენებული აპებისთვის:

• ავტორიზაცია სერვერზე. ღილაკის დამალვა უსაფრთხოება არ არის. ყოველმა მოთხოვნამ, რომელიც მონაცემებს კითხულობს ან ცვლის, სერვერზე უნდა შეამოწმოს, რომ შესული მომხმარებელი უფლებამოსილია. თუ თქვენი აპი მონაცემთა ბაზას იყენებს მწკრივის დონის წესებით, შეამოწმეთ, რომ ისინი ჩართულია და გამოცდილია.
• საიდუმლოებები ბრაუზერის გარეთ. გადახდის, ელფოსტის ან AI მომწოდებლების API გასაღებები სერვერის გარემო ცვლადებში უნდა იყოს, არასდროს წინა მხარის კოდში. თუ არ ხართ დარწმუნებული, რას ნიშნავს ეს, წაიკითხეთ რა არის გარემო ცვლადები და საიდუმლოებები.
• ვალიდაცია სერვერზე. ბრაუზერის შემოწმება შეიძლება გვერდი აუაროთ, ამიტომ ყოველი მნიშვნელოვანი შემოწმება სერვერზეც გაიმეორეთ.
• შესვლა სწორად. გამოიყენეთ კარგად გამოცდილი ავთენტიფიკაციის ბიბლიოთეკა ან სერვისი, და არა ხელით დაწერილი პაროლის შენახვა. ჩვენი გზამკვლევი როგორ დავამატოთ შესვლა აპში ვარიანტებს აღწერს.
• სიხშირის ლიმიტები შესვლაზე, რეგისტრაციაზე, პაროლის აღდგენაზე და ყველაფერზე, რაც ელფოსტას აგზავნის ან ფასიან API-ს იძახებს.
• გასაგები შეცდომები. მომხმარებლებმა უნდა ნახონ „რაღაც არასწორად მოხდა“; დეტალები ლოგებში უნდა მიდიოდეს, არა ეკრანზე.
• გაჟონილის განახლება. თუ ცოცხალი გასაღები ოდესმე ჩატში, კომიტში ან ეკრანის ანაბეჭდში მოხვდა, შეცვალეთ მომწოდებელთან.

პრომპტი, რომელიც ბევრ საკითხს ერთდროულად ფარავს:

გადახედე ამ აპს წარმოების უსაფრთხოების თვალსაზრისით. შეამოწმე, რომ ყველა API მარშრუტი ადასტურებს, რომ შესული მომხმარებელი ფლობს იმ ჩანაწერს, რომელსაც კითხულობს ან ცვლის, რომ საიდუმლო გასაღებები არ იგზავნება ბრაუზერში, რომ შემავალი მონაცემები სერვერზე მოწმდება, და რომ შესვლა და პაროლის აღდგენა შეზღუდულია სიხშირით. ჩამოწერე რაც იპოვე, სანამ რამეს შეცვლი.

ჯერ სიის მოთხოვნა საშუალებას გაძლევთ დაინახოთ პრობლემები და გადაწყვიტოთ რიგი, იმის ნაცვლად, რომ მიიღოთ ერთი უზარმაზარი ცვლილება.

ნაბიჯი 4: იცოდეთ, როდის ირღვევა — ლოგირება და მონიტორინგი

გადახედვაში შეცდომებს მათი მოხდენისთანავე ხედავთ. წარმოებაში აპმა უნდა გითხრათ. სამი ფენა, ყველაზე იაფიდან ყველაზე სასარგებლომდე:

1. სერვერის ლოგები. დარწმუნდით, რომ შეცდომები ისე იწერება, რომ საკმარისი კონტექსტი იყოს მათ აღსადგენად: რომელი მარშრუტი, რომელი მომხმარებლის ID (არა მათი პაროლი ან ბარათი), რა ფორმის შეყვანა. თუ აპი მხოლოდ კონსოლში წერს, სთხოვეთ AI-ს სტრუქტურირებული ლოგირება დაამატოს.
2. შეცდომების თვალყურის დევნება. სერვისი, როგორიცაა Sentry ან მსგავსი ინსტრუმენტი, იჭერს წინა და უკანა მხარის გამონაკლისებს, აჯგუფებს მათ და გამოგიგზავნით ელფოსტას. პატარა აპისთვის ამ სერვისების უფასო გეგმები ხშირად საკმარისია; მიმდინარე ლიმიტები მათ საიტებზე შეამოწმეთ.
3. მუშაობის შემოწმება. გარე სერვისი, რომელიც რამდენიმე წუთში ერთხელ ტვირთავს თქვენს მთავარ გვერდს და ერთ მნიშვნელოვან API მარშრუტს და გაფრთხილებს, თუ ისინი ვერ იმუშავებენ. ეს იჭერს პრობლემებს, რომლებიც აპს საერთოდ არ აძლევს ლოგირების საშუალებას.

დაამატეთ ერთი კიდევ ჩვევა: ყოველი გამოშვების შემდეგ გახსენით ცოცხალი აპი და გაუშვით მთავარი პროცესების ჩეკლისტი რეალურ URL-ზე, არა მხოლოდ გადახედვაზე.

ნაბიჯი 5: სარეზერვო ასლები და უკან დაბრუნების გზა

ორი სხვადასხვა რამ საჭიროებს დაცვას, და მათი აღრევა ადვილია.

• კოდი. შეინახეთ პროექტი ვერსიების კონტროლში, რომ ნებისმიერი ცვლილება გაუქმდეს. ბევრი AI შემქმნელი ინახავს თქვენი ფაილების კონტროლ-წერტილებს; Git-ის რეპოზიტორიასთან სინქრონიზაცია კი შემქმნელის გარეთ კოპიას გაძლევთ.
• მონაცემები. კოდის უკან დაბრუნება მონაცემთა ბაზას არ აბრუნებს. ცუდმა მიგრაციამ ან დაზიანებულმა წაშლის ღილაკმა შეიძლება გაანადგუროს მწკრივები, რომელთაც არც ერთი კოდის კონტროლ-წერტილი ვერ დააბრუნებს.

მონაცემებისთვის დააყენეთ რეგულარული სარეზერვო ასლები, რომლებიც შეინახება აპის ჰოსტინგის გარეთ — Postgres-ისთვის ჩვეულებრივი გზაა დაგეგმილი pg_dump სხვა საცავში, ხოლო მრავალი მართული მონაცემთა ბაზის ჰოსტი გთავაზობთ ავტომატურ სარეზერვო ასლებს ან წერტილამდე აღდგენას. შემდეგ გააკეთეთ ის ნაბიჯი, რომელსაც უმეტესობა გამოტოვებს: აღადგინეთ სარეზერვო ასლი ცდის მონაცემთა ბაზაში და შეამოწმეთ, რომ მონაცემები იქ არის.

ასევე სთხოვეთ AI-ს, გაამყაროს დესტრუქციული მოქმედებები: დადასტურების ნაბიჯი წაშლებისთვის და „რბილი წაშლა“ (ჩანაწერის დამონიშვნა წაშლილად, ნაცვლად მისი მოშორებისა) იმისთვის, რაც მომხმარებლებს შეიძლება დასჭირდეთ.

ნაბიჯი 6: მუშაობა, რომელიც ტელეფონზე გაძლებს

პროტოტიპები სწრაფად გვეჩვენება, რადგან თქვენ ერთადერთი მომხმარებელი ხართ და მონაცემთა ნაკრები პატარაა. გაშვებამდე:

• ჩატვირთეთ რეალური ზომის მონაცემები. სთხოვეთ AI-ს, რამდენიმე ათასი მწკრივი ჩასვას და ნახოს, რომელი გვერდები ნელდება. სიები ჩვეულებრივ გვერდებად დაყოფას საჭიროებს, ხოლო მონაცემთა ბაზას — ინდექსებს იმ სვეტებზე, რომლითაც ფილტრავთ და ალაგებთ.
• პატარა გახადეთ სურათები. გადიდებული სურათები ყველაზე ხშირი მიზეზია, რის გამოც გვერდი ნელა იტვირთება. სთხოვეთ შემცირებული და შეკუმშული სურათები და ჩატვირთვა მხოლოდ მაშინ, როცა ისინი ჩანს.
• გაზომეთ. გაუშვით Lighthouse Chrome-ის დეველოპერის ხელსაწყოებში ცოცხალ URL-ზე მობილურ რეჟიმში. 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 ცოცხალ გადახედვაში მომხმარებლივით გაივლის და გატეხილ პროცესებს მოგახსენებთ — იხილეთ აპის ტესტირება. გასაღებები პროექტის საიდუმლოებებში შედის და არა ჩატში; ყოველი წარმატებული აგენტის ნაბიჯი ინახავს ფაილების კონტროლ-წერტილს, რომელზეც უკან დაბრუნება შეიძლება; გამოქვეყნება გაძლევთ ცოცხალ URL-ს, სადაც ჰოსტინგი და მონაცემთა ბაზა ერთი და იგივე კრედიტის ბალანსიდან იხდება (ჰოსტინგის ლიმიტები განმარტავს, როგორ იძინებენ და იღვიძებენ აპები და ბაზები). კონტროლ-წერტილები ფაილებს ფარავს, მონაცემთა ბაზის მწკრივებს — არა, ამიტომ მონაცემების სარეზერვო ასლებზეც იზრუნეთ. Pro გეგმაზე შეგიძლიათ მორგებული დომენის მიერთება და კოდის ექსპორტი ან სინქრონიზაცია თქვენს GitHub რეპოზიტორიაში გადაცემისთვის.

კითხვები