როგორ დავწეროთ მოთხოვნები AI აპის ბილდერებისთვის (მაგალითებით მანამდე და მერე)

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

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

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

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

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

რა უნდა შეიცავდეს პირველი მოთხოვნა

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

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

მანამდე და მერე: პირველი მოთხოვნა

მანამდე:

გააკეთე ჩემი სპორტდარბაზისთვის აპი.

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

მერე:

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

მეორე ვერსიაც მოკლეა. ის უბრალოდ პასუხობს ზემოთ ცხრილის კითხვებს.

აღწერე ქცევა და არა იმპლემენტაცია

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

მანამდე:

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

მერე:

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

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

იყავი კონკრეტული წესების შესახებ

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

• ლიმიტები: «წევრს მაქსიმუმ სამი მომავალი ჯავშანი შეუძლია ჰქონდეს».
• დროის წესები: «გაუქმება იხურება ვარჯიშის დაწყებამდე ორი საათით ადრე».
• კიდურა შემთხვევები: «თუ ვარჯიში გავსებულია, აჩვენე ღილაკი სიაში ჩაწერა ჯავშნის ნაცვლად».
• უფლებები: «ინსტრუქტორებს შეუძლიათ ნახონ საკუთარი ვარჯიშების დასწრება, მაგრამ არა სხვა ინსტრუქტორებისა».

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

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

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

მანამდე:

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

მერე (ოთხ ცალკე შეტყობინებად):

1. როცა ვარჯიშის ბოლო ადგილს დავჯავშნი, ის მაინც წერს «დარჩა 1 ადგილი». უნდა წერდეს «შევსებულია» და მაშინ დაიმალოს ჯავშნის ღილაკი.
2. დაამატე კვირის ხედის კალენდარი გრაფიკის გვერდზე, თითო დღე ერთ სვეტად. მიმდინარე სიის ხედი დატოვე როგორც ვარიანტი.
3. ტელეფონზე გახადე ვარჯიშის ბარათები უფრო კომპაქტური: ნაკლები შიდა დაშორება, ინსტრუქტორის სახელი იმავე ხაზზე დროსთან ერთად.
4. როცა წევრი დაჯავშნის, გაუგზავნე დადასტურების ელფოსტა.

რატომ მუშაობს ეს:

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

თქვი, რა უნდა დარჩეს

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

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

იგივე ეხება მონაცემებსაც: «დაამატე ტელეფონის ველი წევრებს. არცერთი არსებული ველი არ წაშალო და არ გადაასახელო».

გამოიყენე ეკრანის ანაბეჭდები და ზუსტი ტექსტი

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

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

კონკრეტულად შეცდომებისთვის გამოიყენე ეს ფორმა:

ჯავშნების გვერდზე დავაჭირე Cancel-ს ხვალინდელ ჯავშანზე. ველოდი, რომ ის ჩემი სიიდან გაქრებოდა. ამის ნაცვლად არაფერი მოხდა და ჯავშანი გვერდის განახლების შემდეგაც იქ არის. გაასწორე და შეამოწმე, რომ გაუქმება მუშაობს.

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

დიდი ცვლილებებისთვის ჯერ გეგმა

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

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

წაიკითხე გეგმა. თუ რაღაც არასწორად გაიგო, ერთი პარაგრაფის გასწორება გაცილებით იაფია, ვიდრე მზა ფუნქციის გასწორება. ბევრ ბილდერს ამისთვის ცალკე რეჟიმი აქვს; Mythex-ზე ეს არის Plan რეჟიმი, Build-თან და Ask-თან ერთად.

რისი თავიდან აცილება ღირს

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

მრავალჯერადი მოთხოვნის შაბლონები

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

ახალი აპი:

ააშენე [აპის ტიპი] [ვისთვის]. ისინი [მთავარი ნაკადი, ნაბიჯ-ნაბიჯ]. [მეორე ტიპის მომხმარებელი] შედის, რომ [რას აკეთებს]. შეინახე [მონაცემები] მონაცემთა ბაზაში. [იერ-სახე]. [რა გამოვრიცხოთ მოგვიანებით].

ახალი ფუნქცია:

დაამატე [ფუნქცია] [გვერდზე]. როცა [ვინმე] გააკეთებს [მოქმედებას], [რა უნდა მოხდეს]. მხოლოდ [ვინ] შეძლებს [ამის გაკეთებას]. შეინარჩუნე [არსებული რამეები] უცვლელად.

დიზაინის ცვლილება:

[გვერდზე] შეცვალე [კონკრეტული ელემენტი] [კონკრეტულად რა]. დატოვე [რაც უნდა დარჩეს]. შეამოწმე, რომ ტელეფონის ეკრანზე კარგად გამოიყურება.

ბაგი:

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

შეკითხვა ცვლილებების გარეშე:

კოდი არ შეცვალო. ამიხსენი, როგორ მუშაობს [აპის ნაწილი] და სად ინახება [მონაცემები].

გრძელი სპეციფიკაციის წერა

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

მოთხოვნები Mythex-ში

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

• Build, Plan და Ask რეჟიმები. Plan გამოიყენე დიდი ან რისკიანი ცვლილებებისთვის, ხოლო Ask — როცა ახსნა გინდა, რედაქტირების გარეშე.
• Checkpoints. ყოველი წარმატებული ცვლილების შემდეგ Mythex ინახავს checkpoint-ს, ხოლო პასუხზე Revert to this point აბრუნებს პროექტს. ასევე შეგიძლია წინა შეტყობინება შეცვალო და ხელახლა გაგზავნო, რომ იმ წერტილიდან სხვა მოთხოვნა სცადო.
• საიდუმლოების ბარათი. როცა აგენტს API გასაღები სჭირდება, ის ჩატში ბარათის მეშვეობით კითხულობს, რათა მნიშვნელობა პროექტის საიდუმლოდ შეინახოს და არა შენს შეტყობინებაში ჩაიწეროს.
• სურათები. მიამაგრე ეკრანის ანაბეჭდები ან მაკეტები და აგენტი მათ ნახავს.

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

კითხვები