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

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

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

გაუმჯობესების ციკლი

1. აირჩიეთ ერთი ცვლილება. ერთი ფუნქცია, ერთი შეცდომა, ერთი გვერდი.
2. აღწერეთ იმის მიხედვით, რასაც მომხმარებელი ხედავს და აკეთებს.
3. დიდი ცვლილებებისთვის ჯერ დაგეგმეთ. ითხოვეთ გეგმა, წაიკითხეთ და შემდეგ ააშენეთ.
4. შეამოწმეთ შედეგი გადახედვაში — თავად ცვლილება და მის გვერდით მდებარე პროცესები.
5. შეინახეთ checkpoint ან commit.
6. გაიმეორეთ.

ყოველი ნაბიჯი იმისთვისაა, რომ ცვლილებები პატარა და შექცევადი იყოს.

ნაბიჯი 1: შეინახეთ მოკლე სია

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

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

ნაბიჯი 2: აღწერეთ, რასაც ხედავთ

AI ვერ ხედავს თქვენს ეკრანს, სანამ არ უთხრით. მიუთითეთ კონკრეტული რამ და თქვით, რა უნდა მოხდეს:

ფასების გვერდზე ტელეფონზე Pro ბარათის ღილაკი მარჯვენა კიდეზე იჭრება. დესკტოპის განლაგება დატოვე ისევე; 640px-ზე ნაკლები ეკრანებზე დააწყვე ბარათები ერთმანეთის ქვემოთ და გახადე ღილაკები მთელი სიგანის.

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

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

ნაბიჯი 3: დიდ ცვლილებამდე დაგეგმეთ

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

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

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

ნაბიჯი 4: თქვით, რა არ უნდა შეიცვალოს

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

შეკვეთების ცხრილს დაამატე თარიღის ფილტრი. ცხრილის სვეტები, სტილი და ექსპორტის ღილაკი არ შეცვალო.

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

ნაბიჯი 5: შეამოწმეთ მეტი, ვიდრე თავად ცვლილება

ყოველი მოთხოვნის შემდეგ შეამოწმეთ:

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

თუ რამე არ არის რიგზე, ზუსტად აღწერეთ — იხილეთ როგორ დავწეროთ კარგი შეცდომის აღწერა.

ნაბიჯი 6: დაბრუნდით, არა დაგროვდით

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

ამის ნაცვლად:

1. დაბრუნდით ბოლო ვერსიაზე, რომელიც მუშაობდა (checkpoint ან Git commit).
2. გაარკვიეთ, რა იყო გაუგებარი მოთხოვნაში.
3. სცადეთ თავიდან უფრო მცირე ან უფრო მკაფიო მოთხოვნით.

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

ნაბიჯი 7: იცოდეთ, როდის არის თავიდან აშენება სწორი

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

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

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

მაგალითი მოთხოვნები

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

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

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

გავრცელებული შეცდომები

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

ჩამონათვალი

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

გაუმჯობესება Mythex-ზე

Mythex ამ ციკლის გარშემოა აგებული:

• Plan, Build და Ask რეჟიმები. Plan მიდგომას განიხილავს რედაქტირებამდე; Ask პასუხობს კოდის შეცვლის გარეშე; Build ცვლილებას აკეთებს. იხილეთ Chat.
• Checkpoint-ები. ყოველი წარმატებული ჯერის შემდეგ Mythex Git checkpoint-ს ინახავს; Revert to this point აბრუნებს უკან. ასევე შეგიძლიათ ადრინდელი შეტყობინების რედაქტირება და Discard & resend, რათა იმ წერტილიდან სხვა მოთხოვნა სცადოთ. იხილეთ გაუმჯობესება თავიდან აშენების გარეშე.
• ცოდნა. პროექტის პარამეტრები → Knowledge ინახავს მუდმივ შენიშვნებს, რომელსაც აგენტი ყოველ შეტყობინებაზე მიჰყვება.
• /test აგენტს აძლევს საშუალებას, დიდი ცვლილების შემდეგ გადახედვაში მომხმარებელივით დააწკაპუნოს.

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

კითხვები