AI სერიის ინტერვიუ 14: vibe coding-სა და spec coding-ს შორის განსხვავება?
ეს არის პრობლემა, რომელსაც პროგრამისტების უმეტესობა აწყდება. Vibe Coding და Spec Coding არის ორი სრულიად განსხვავებული სამუშაო პარადიგმა, როდესაც ვიყენებთ დიდი ენის მოდელებს (LLM) პროგრამირებისთვის. მათი ძირითადი განსხვავებაა: AI-სთვის მიცემული „ინპუტი“ არის გაურკვეველი გრძნობა თუ ზუსტი სპეციფიკაცია.
1. საჭმლის მომზადების მაგალითით vibe coding-სა და spec coding-ს შორის განსხვავების მარტივი აღწერა
- Vibe Coding = თქვენ ეუბნებით მეგობარს: „მე მინდა ცხარე საჭმელი“, მეგობარი გრძნობით ამზადებს კერძს, თქვენ გასინჯავთ და ამბობთ: „ცოტა მარილიანი იყოს“, ის კიდევ ამატებს მარილს. გემო შეიძლება გასაოცარი იყოს, მაგრამ სხვა მეგობარი სრულიად განსხვავებულს მოამზადებს.
- Spec Coding = თქვენ წერთ რეცეპტს: „20 გრამი Pixian Doubanjiang, 150 გრამი საქონლის ხორცი, 50 გრამი ნიახური, 2 წუთი მაღალ ცეცხლზე, 3 გრამი შაქარი ცეცხლიდან გადმოღებამდე“. სხვადასხვა მზარეულები რეცეპტის მიხედვით ამზადებენ, გემო მაღალი ხარისხით ერთნაირია.
2. ორივეს განმარტება
| განზომილება | Vibe Coding | Spec Coding |
|---|---|---|
| სხვა სახელი | გრძნობაზე დაფუძნებული პროგრამირება, იმპროვიზაცია prompt-ებით | სპეციფიკაციით მართული პროგრამირება, დოკუმენტაცია პირველ რიგში |
| შეყვანის ფორმა | „დამიმზადე ლამაზი შესვლის გვერდი, ტექნიკური ესთეტიკით“ | „შესვლის გვერდი უნდა შეიცავდეს ელ.ფოსტის/პაროლის შეყვანის ველს, „დამიმახსოვრე“ მონიშვნის ველს, გაგზავნის ღილაკს; ფრონტენდი React + Tailwind; ფორმის ვალიდაციის წესები: ელ.ფოსტის ფორმატი, პაროლის სიგრძე ≥8; წარუმატებლობისას წითელი შეტყობინება...“ |
| AI-ს გამოყენების ხერხი | დიალოგური, იტერაციული: მიეცით მიმართულება → ნახეთ შედეგი → შეასწორეთ | ინჟინერული: ჯერ დაწერეთ დეტალური PRD/ტექნიკური სპეციფიკაცია → AI აგენერირებს კოდს სპეციფიკაციის საფუძველზე |
| ადამიანის ჩართულობის ხარისხი | დაბალი: ეყრდნობა AI-ს კრეატიულობას, ადამიანი მხოლოდ ამოწმებს „სწორია თუ არა გრძნობა“ | მაღალი: ადამიანი ჯერ ასრულებს დიზაინს/არქიტექტურას, AI ძირითადად ასრულებს |
| ტიპური სცენარები | სწრაფი პროტოტიპი, პირადი ინსტრუმენტები, UI კვლევა, კრეატიული კოდირება | წარმოების დონის სისტემები, გუნდური თანამშრომლობა, კოდი, რომელიც საჭიროებს შენარჩუნებას/ტესტირებას |
3. ორივეს სამუშაო ნაკადის შედარება
Vibe Coding-ის ნაკადი
- ბუნდოვანი იდეა: „მინდა დავწერო crawler, რომელიც მოაგროვებს Zhihu-ს ცხელ თემებს.“
- დაწერეთ პირველი prompt: პირდაპირ სთხოვეთ AI-ს კოდის გენერაცია.
- გაშვება → შეცდომა → შეცდომის ჩასმა უკან → AI ასწორებს.
- ვგრძნობ, რომ ინტერფეისი მახინჯია → „ის ღილაკი მრგვალი გახადე, ფონი გრადიენტური ლურჯი გახადე“ → AI ცვლის.
- ფუნქციის ნაკლებობა → „დაამატე CSV-ში შენახვის ფუნქცია“ → AI ამატებს.
- გაიმეორეთ 3-5 სანამ „თითქმის კარგია“.
Spec Coding-ის ნაკადი
- სპეციფიკაციის დოკუმენტის დაწერა: ნათლად განსაზღვრეთ შეყვანა/გამომავალი, მონაცემთა სტრუქტურები, შეცდომების დამუშავება, შესრულების მოთხოვნები, არაფუნქციონალური მოთხოვნები (მაგ. ჟურნალი, ლიმიტირება).
- სპეციფიკაციის დაყოფა ამოცანებად: მაგ. ამოცანა 1: განახორციელეთ
fetch_hot_topics()ფუნქცია, spec-ში მითითებული API-ს ხელმოწერის დაცვით. - თითოეული ამოცანისთვის AI-ს მიერ განხორციელება: prompt უნდა შეიცავდეს ფუნქციის ხელმოწერას, კომენტარებს, ტესტის შემთხვევების მოლოდინებს.
- ადამიანური მიმოხილვა და ვალიდაცია: უზრუნველყოთ, რომ შეესაბამება spec-ს, გაუშვით ერთეულის ტესტები.
- ინტეგრაცია და რეგრესია.
4. უპირატესობებისა და ნაკლოვანებების შედარება
| მახასიათებელი | Vibe Coding | Spec Coding |
|---|---|---|
| სწავლის სიჩქარე | ძალიან სწრაფი, რამდენიმე წუთში იღებთ პროტოტიპს | ნელი, საჭიროა დოკუმენტაციის წერა, ამოცანების დაყოფა |
| კოდის ხარისხი | დაბალი (შესაძლოა ზედმეტი, არათანმიმდევრული, ფარული ხარვეზები) | მაღალი (კითხვადი, ტესტირებადი, არქიტექტურის შესაბამისი) |
| შენარჩუნებადობა | ცუდი, შემდგომი მომხმარებლები ვერ ხვდებიან "რატომ არის ასე დაწერილი" | კარგი, spec თავად არის დოკუმენტაცია |
| LLM-ზე დამოკიდებულება | ძალიან მაღალი, მოდელის შეცვლამ შეიძლება სრულიად განსხვავებული გამომავალი გამოიწვიოს | საშუალო, თუ spec ნათელია, სხვადასხვა მოდელებსაც შეუძლიათ მსგავსი სტრუქტურის გენერირება |
| გამართვის სირთულე | რთული, უცნობია, საიდან მოდის კოდის ლოგიკა | მარტივი, spec-ის მიხედვით თითოეული პუნქტის შემოწმება |
| გუნდური თანამშრომლობისთვის შესაფერისი | თითქმის შეუძლებელი | შესაძლებელი (spec, როგორც კომუნიკაციის ხელშეკრულება) |
| შედეგის განსაზღვრულობა | დაბალი, ყოველი დიალოგის შედეგი შეიძლება გადაიხრებოდეს | მაღალი, იგივე spec იძლევა სტაბილურ გამომავალს |
5. რეალური გამოყენების რეკომენდაციები
„სამსახურში vibe coding-სა და spec coding-ს შორის არ მოგიწევთ არჩევანის გაკეთება, არამედ შერეულად გამოიყენებთ, შესაფერის სცენარში შესაფერის მიდგომას:
- კვლევის ფაზაში (როდესაც გაურკვეველი ხართ ტექნოლოგიის ან UI-ის არჩევანში), გამოიყენეთ Vibe Coding სხვადასხვა ვარიანტების სწრაფი ვალიდაციისთვის, მაგ. „Tailwind-ით დაწერე ბარათის კომპონენტი, ვნახოთ როგორ გამოიყურება“.
- როგორც კი ვარიანტი განისაზღვრება, მაშინვე გადადით Spec Coding-ზე: წარმატებული პროტოტიპი გადააქციეთ ნათელ spec-ად (შეყვანა/გამომავალი, სასაზღვრო პირობები, შეცდომების დამუშავება), შემდეგ კი AI-ს ან ადამიანს მიეცით spec-ის მიხედვით წარმოების კოდის გადაწერა.
სუფთა Vibe რეჟიმი მხოლოდ ერთჯერადი სკრიპტების ან შიდა ინსტრუმენტებისთვისაა; სისტემებისთვის, რომლებიც გრძელვადიან მოვლასა და მრავალი მომხმარებლის მიერ გამოყენებას საჭიროებენ, Spec Coding არის მკაცრი მოთხოვნა.“
评论
暂无已展示的评论。
发表评论(匿名)