როგორ დავწეროთ კარგი bug report (AI-სთვის ან დეველოპერისთვის)

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

უმეტეს ბაგს უფრო მეტი დრო სჭირდება გასაგებად, ვიდრე გამოსასწორებლად. კარგი report ამ გასაგებად ნაწილს აშორებს. ეს კიდევ უფრო მნიშვნელოვანია AI ინსტრუმენტებთან: AI ვერ დაგისვამს შემდგომ შეკითხვას, რას გულისხმობდით „checkout უცნაურია“-ში, ამიტომ გამოიცნობს — და არასწორი ვარაუდი სხვა რამეს შეიძლება გატეხოს.

შაბლონი

გადაიღეთ და შეავსეთ:

Title: [რა არის გატეხილი, სად] — მაგ. „Booking form rejects times after 6pm“

Steps to reproduce:
1. ...
2. ...
3. ...

Expected: [რა უნდა მოხდეს]
Actual: [რა მოხდა სანაცვლოდ]

Error message: [ზუსტი ტექსტი, თუ არის]
Where: [გვერდი/URL, ბრაუზერი, მოწყობილობა, რომელი მომხმარებლით შესული]
How often: [ყოველთვის / ზოგჯერ / ერთხელ]
Screenshot or recording: [მიმაგრებული]

სახელმძღვანელოს დანარჩენი ნაწილი თითოეულ პუნქტს ხსნის.

ნაბიჯი 1: ჯერ ხელახლა გამოიწვიეთ

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

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

ამის შესახებ მეტს იხილავთ როგორ გავმართოთ AI-ით აგებული აპი.

ნაბიჯი 2: დაწერეთ კონკრეტული სათაური

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

ნაბიჯი 3: ჩამოწერეთ ზუსტი ნაბიჯები

დაანომრეთ ისინი. იყავით პირდაპირი: რომელი გვერდი, რომელი ღილაკი, რა აკრიფეთ.

1. შედით როგორც მომხმარებელი (სატესტო ანგარიში: customer@example.com).
2. დაამატეთ „Starter kit“ კალათაში.
3. შეიყვანეთ ფასდაკლების კოდი WELCOME10 და დააწკაპუნეთ Apply.
4. დააწკაპუნეთ Checkout.

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

ნაბიჯი 4: მოსალოდნელი და ფაქტობრივი

ეს არის report-ის ბირთვი. თქვით ორივე, რადგან სხვაობა თავად ბაგია.

• მოსალოდნელი: checkout გვერდი იხსნება და ჯამში ჩანს 10%-იანი ფასდაკლება.
• ფაქტობრივი: ღილაკი ერთი წამით სპინერს აჩვენებს და შემდეგ არაფერი ხდება. კოდის გარეშე checkout მუშაობს.

„მოსალოდნელის“ გარეშე მკითხველმა შეიძლება არ იცოდეს, რომ ქცევა არასწორია. „ფაქტობრივის“ გარეშე არ იცის, რა უნდა ეძებოს.

ნაბიჯი 5: შეცდომები ზუსტად გადმოიტანეთ

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

სად მოძებნოთ:

• ეკრანზე: ნებისმიერი შეტყობინება, რომელსაც აპი აჩვენებს.
• ბრაუზერის კონსოლი: გახსენით developer tools (F12, ან მარჯვენა ღილაკი → Inspect) და ნახეთ Console ჩანართი წითელი ხაზებისთვის.
• Network ჩანართი: developer tools-ში იპოვეთ წარუმატებელი მოთხოვნა და ჩაწერეთ მისი URL და სტატუს-კოდი (მაგალითად POST /api/checkout → 500).
• სერვერის ლოგები, თუ გაქვთ წვდომა.

ხაზი, როგორიც არის TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48, ხშირად პირდაპირ პრობლემაზე მიგვანიშნებს.

ნაბიჯი 6: დაამატეთ კონტექსტი

• სად: გვერდის URL, გარემო (preview, staging ან live).
• ვინ: რომელი მომხმარებელი ან როლი — ადმინი, წევრი, გასული.
• მოწყობილობა და ბრაუზერი: „Safari iPhone-ზე“ და „Chrome Windows-ზე“ შეიძლება მნიშვნელოვანი იყოს.
• მონაცემები: ჩანაწერის რაიმე უჩვეულო თვისება — ძალიან გრძელი ტექსტი, სპეციალური სიმბოლოები, დიდი რაოდენობა ელემენტების.
• როდის დაიწყო: „გუშინდელი ცვლილების შემდეგ ფასდაკლების კოდებზე“ ოქროა.
• რამდენად ხშირად: ყოველთვის, ან ათიდან ერთხელ.

ნაბიჯი 7: აჩვენეთ

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

bug report-ის წერა AI ბილდერისთვის

იგივე სტრუქტურა მუშაობს როგორც პრომპტი. ორი დამატება ეხმარება:

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

შესული როგორც მომხმარებელი, „Starter kit“ კალათაში და გააქტიურებული კოდი WELCOME10, Checkout-ზე დაჭერა არაფერს არ აკეთებს. მოსალოდნელი: checkout გვერდი იხსნება 10%-იანი ფასდაკლებით. ფაქტობრივი: მოკლე სპინერი და შემდეგ არაფერი. Network ჩანართი აჩვენებს, რომ POST /api/checkout დააბრუნა 500. კოდის გარეშე checkout მუშაობს. იპოვე მიზეზი და გაასწორე ისე, რომ კოდის გარეშე შეკვეთების ფასების გამოთვლა არ შეიცვალოს. შემდეგ შეამოწმე checkout პროცენტული კოდით, ფიქსირებული თანხის კოდით და კოდის გარეშე.

თუ მიზეზი გაურკვეველია, ჯერ დიაგნოზი მოითხოვეთ:

ჯერ კოდი არ შეცვალო. ამ report-ის მიხედვით, რა არის სავარაუდო მიზეზები და რა დაადასტურებდა თითოეულს?

ხშირი შეცდომები

• „გატყდა.“ ნაბიჯები არ არის, მოსალოდნელი შედეგი არ არის — არაფერია სამოქმედო.
• რამდენიმე ბაგი ერთ report-ში. ზოგი გამოსწორდება, სხვები იკარგება.
• გადაფორმებული შეცდომები. „რაღაც undefined“ ფარავს სასარგებლო ნაწილს.
• მომხმარებლის ან როლის გამოტოვება. ბევრი ბაგი მხოლოდ ადმინებს ან მხოლოდ ახალ მომხმარებლებს ეხება.
• მხოლოდ სასურველი გამოსწორების აღწერა („დაამატე null შემოწმება“) პრობლემის აღწერის ნაცვლად.
• საიდუმლოების გაზიარება ეკრანის ანაბეჭდებში ან ჩასმულ ლოგებში.

ჩეკლისტი

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

ბაგების შეტყობინება Mythex-ის აგენტისთვის

Mythex-ის პროექტში report არის პრომპტი. რამდენიმე ფუნქცია ეხმარება:

• მიამაგრეთ ეკრანის ანაბეჭდი preview-ის ან შეცდომის ეკრანის — მაქსიმუმ 5 ფაილი ერთ შეტყობინებაში.
• /fix აგენტს ბაგის გამოსწორებაზე ამახვილებს; Plan რეჟიმი საშუალებას აძლევს, ჯერ გამოიკვლიოს და მხოლოდ შემდეგ შეცვალოს.
• /test აგენტს ათავებინებს ნაკადების ხელახლა გამოწვევას თავად preview-ში და მოხსენებას მის ნანახზე.
• Revert to this point აუქმებს გამოსწორებას, რომელმაც უარესი გახადა.

დოკუმენტაციის debugging with prompts გვერდი იგივე „ნაბიჯები / მოსალოდნელი / ფაქტობრივი“ სტრუქტურას იყენებს. გამოსწორება-და-შემოწმების ციკლისთვის იხილეთ როგორ ვიმეორეოთ AI-ით აგებული აპი.

კითხვები