როგორ გავმართოთ AI-ით აშენებული აპი: პრაქტიკული მეთოდი

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

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

გამართვის ციკლი

ყოველი შეცდომის გასწორება, იქნება ეს ადამიანი თუ AI, ერთსა და იმავე ციკლს მიჰყვება:

1. განმეორება — გამოიწვიეთ შეცდომა სანდოდ.
2. დაკვირვება — შეაგროვეთ შეცდომის შეტყობინება და ის, რასაც აპი აკეთებდა.
3. აღწერა — მიაწოდეთ AI-ს ზუსტი ნაბიჯები, მოსალოდნელი და რეალური შედეგი.
4. შესწორება — ათქმევინეთ AI-ს ერთი რამ შეცვალოს.
5. შემოწმება — გაიმეორეთ ზუსტი ნაბიჯები და დარწმუნდით, რომ გასწორდა და ახლომდებარე არაფერი გატყდა.
6. დაბრუნება, თუ საჭიროა — თუ გაუარესდა, გააუქმეთ და სცადეთ ხელახლა უკეთესი ინფორმაციით.

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

ნაბიჯი 1: შეცდომის განმეორება

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

კითხეთ საკუთარ თავს:

• ყოველთვის ხდება? თუ მხოლოდ ზოგჯერ, რა განსხვავდება მაშინ — კონკრეტული ჩანაწერი, ნელი კავშირი, გასვლა ანგარიშიდან?
• ყველა მომხმარებელს ხდება? შედით სხვა ანგარიშით. ბევრი შეცდომა მხოლოდ ახალ მომხმარებლებზე ჩანს, მონაცემების გარეშე, ან სხვა როლის მქონე მომხმარებელზე.
• ყველა მოწყობილობაზე ხდება? სცადეთ ტელეფონის სიგანის ეკრანი და სხვა ბრაუზერი.
• დაიწყო კონკრეტული ცვლილების შემდეგ? თუ გუშინ მუშაობდა, ბოლო რამდენიმე ცვლილება მთავარი ეჭვმიტანილია.

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

ნაბიჯი 2: შეცდომის შეტყობინების წაკითხვა

შეცდომის შეტყობინებები საშინლად გამოიყურება, მაგრამ მათგან რამდენიმე ნაწილი გჭირდებათ.

მისი გაგება არ გჭირდებათ; ზუსტად უნდა დააკოპიროთ. „Cannot read properties of undefined (reading 'name')“ ეუბნება AI-ს, რომ კოდს მოელოდა გარკვეული მონაცემი (ალბათ ჯავშანი ან მომხმარებელი), რომელიც არ იყო. გადმოცემა ტიპის „რაღაც undefined შეცდომა“ ამ ინფორმაციას კარგავს.

რამდენიმე გავრცელებული, მოკლედ თარგმნილი:

• undefined / null შეცდომები — კოდს მონაცემი მოელოდა და არ მოვიდა. ხშირად ჩატვირთვის მდგომარეობა ან ცარიელი სია, რომელსაც კოდი არ ამუშავებს.
• 404 Not Found — გვერდი ან API მისამართი არ არსებობს. ხშირად მარშრუტში შეცდომაა, ან ბმული გვერდზე, რომელიც გადაირქვა.
• 401 Unauthorized / 403 Forbidden — მოთხოვნა შესულ მომხმარებელს არ ჰქონდა, ან მომხმარებელს ამის უფლება არ აქვს.
• 500 Internal Server Error — სერვერის მხარის კოდი ჩაიშალა. ნამდვილი მიზეზი სერვერის ლოგებშია და არა ბრაუზერში.
• CORS შეცდომები — ბრაუზერმა სხვა დომენზე მოთხოვნა დაბლოკა. ჩვეულებრივ სერვერის მხარის კონფიგურაციის საკითხია.

ნაბიჯი 3: ბრაუზერის დეველოპერული ინსტრუმენტები

ყველა დესკტოპ ბრაუზერს აქვს ჩაშენებული დეველოპერული ინსტრუმენტები ("devtools"). ისინი გვიჩვენებენ, რას აკეთებს გვერდი ფარულად. Chrome-ში, Edge-სა და Firefox-ში დააწკაპუნეთ გვერდზე მარჯვენა ღილაკით და აირჩიეთ Inspect, ან დააჭირეთ F12-ს (Mac-ზე Cmd+Option+I). Safari-ში ჯერ ჩართეთ Develop მენიუ Safari-ის პარამეტრებში.

სამი ჩანართი გჭირდებათ.

Console

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

Network

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

• მოძებნეთ წითლად მონიშნული სტრიქონები ან სტატუსით 400 და მეტი.
• დააწკაპუნეთ ჩავარდნილ სტრიქონზე და ნახეთ მისი Response. სერვერის შეცდომა ხშირად იქ შეტყობინებას შეიცავს, რომელიც ეკრანზე ნაჩვენებზე უფრო სასარგებლოა.
• ჩაიწერეთ მოთხოვნის URL და სტატუსის კოდი — წინადადება „POST /api/bookings-ზე მოთხოვნამ 500 დააბრუნა“ ძალიან სასარგებლოა AI-სთვის.

ჩართეთ Preserve log, თუ შეცდომა გვერდის გადატვირთვას ან გადამისამართებას მოიცავს, რომ მოთხოვნები არ გაქრეს.

Elements

Elements (ან Inspector) ჩანართი გვერდის სტრუქტურასა და სტილებს აჩვენებს. ყველაზე სასარგებლოა განლაგების შეცდომებისთვის: ელემენტზე მაუსის გადატარებით ხედავთ მის ზომასა და დაშორებას. აქ არაფრის რედაქტირება არ გჭირდებათ; საკმარისია თქვათ „ქვედა კოლონტიტული მობილურზე 2000 პიქსელი სიგანისაა და გვერდს გვერდზე სწევს“.

ნაბიჯი 4: სერვერის ლოგების შემოწმება

ზოგი შეცდომა სერვერზე ხდება, სადაც ბრაუზერი მას ვერ ხედავს. ქსელის ჩანართში 500 შეცდომა კლასიკური ნიშანია. სერვერის ლოგები — თქვენი ბექენდის ტექსტური გამოტანა მუშაობის დროს — ჩვეულებრივ შეიცავს ნამდვილ შეცდომას სტეკ-ტრეისით (იმ ფუნქციების ჩამონათვალი, რომლებიც მუშაობდა შეცდომის მომენტში).

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

ნაბიჯი 5: შეცდომის აღწერა AI-სთვის

შეაგროვეთ ის, რაც მივიღეთ, ამ ფორმაში:

ჯავშნების გვერდზე, წევრად შესული: დავაჭირე Cancel-ს ხვალინდელ 9:00 გაკვეთილზე. მოსალოდნელი: ჯავშანი ქრება და გაკვეთილზე ერთი თავისუფალი ადგილი ემატება. რეალური: ეკრანზე არაფერი იცვლება. კონსოლში ჩანს TypeError: Cannot read properties of undefined (reading 'id') BookingCard.tsx:31-ზე, ქსელის ჩანართში კი DELETE /api/bookings/123 დააბრუნა 500. იპოვე მიზეზი, გაასწორე და შეამოწმე, მუშაობს თუ არა გაუქმება წევრისთვის ერთი ჯავშნით და რამდენიმე ჯავშნით.

რატომ მნიშვნელოვანია თითოეული ნაწილი:

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

თუ AI ორჯერ სცადა შესწორება და ვერ გაასწორა, სთხოვეთ, რომ რამის შეცვლამდე ახსნას:

ჯერ კოდი არ შეცვალო. რა ფიქრობ, რა იწვევს ამ შეცდომას და რა მტკიცებულება ამტკიცებს ამას?

არასწორი თეორია ადვილად შესამჩნევია, როცა დაწერილია, და მისი შესწორება გაცილებით იაფია, ვიდრე არასწორი შესწორება.

ნაბიჯი 6: შემოწმება და გარშემო ყურება

როცა AI ამბობს, რომ გასწორდა, გაიმეორეთ ნაბიჯი 1-ის ზუსტი ნაბიჯები. შემდეგ შეამოწმეთ მის გარშემო არსებული:

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

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

ნაბიჯი 7: დაბრუნება შესწორებების დაგროვების ნაცვლად

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

კარგი ჩვევები, რომლებიც დაბრუნებას ადვილს ხდის:

• ყოველი ცვლილების შემდეგ შეამოწმეთ, რომ იცოდეთ, რომელმა ცვლილებამ გატეხა.
• ცვლილებები მცირე დატოვეთ — ერთი ფუნქცია ან შესწორება თითო შეტყობინებაში.
• რისკიანი ნაბიჯის წინ ჩაინიშნეთ ბოლო კარგი ვერსია.
• თუ კოდი Git-ში გაქვთ, დააკომიტეთ მუშა ვერსიები, რომ მათ დაუბრუნდეთ.

გავრცელებული შეცდომების ნიმუშები AI-ით აშენებულ აპებში

როცა პრობლემა შეცდომა არ არის

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

გამართვა Mythex-ში

Mythex-ს ციკლის ყოველი ნაბიჯისთვის აქვს ინსტრუმენტები:

• Preview შეცდომის განსამეორებლად, მათ შორის ტელეფონის ზომის ჩარჩოთი.
• /test აგენტს ათვალიერებს თქვენს ცოცხალ გადახედვას როგორც მომხმარებელი და აბრუნებს გატეხილ ნაკადებს.
• /fix აგენტს კონკრეტულად გატეხილზე მიმართავს.
• Plan რეჟიმი აგენტს აძლევს შესაძლებლობას, რომ რედაქტირებამდე გამოიკვლიოს და ახსნას.
• Code → terminal აჩვენებს თქვენი აპის სერვერის ლოგებს.
• Revert to this point ნებისმიერ პასუხზე პროექტს ამ საკონტროლო წერტილამდე აბრუნებს.

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

კითხვები