← 返回列表

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-ის ნაკადი

  1. ბუნდოვანი იდეა: „მინდა დავწერო crawler, რომელიც მოაგროვებს Zhihu-ს ცხელ თემებს.“
  2. დაწერეთ პირველი prompt: პირდაპირ სთხოვეთ AI-ს კოდის გენერაცია.
  3. გაშვება → შეცდომა → შეცდომის ჩასმა უკან → AI ასწორებს.
  4. ვგრძნობ, რომ ინტერფეისი მახინჯია → „ის ღილაკი მრგვალი გახადე, ფონი გრადიენტური ლურჯი გახადე“ → AI ცვლის.
  5. ფუნქციის ნაკლებობა → „დაამატე CSV-ში შენახვის ფუნქცია“ → AI ამატებს.
  6. გაიმეორეთ 3-5 სანამ „თითქმის კარგია“.

Spec Coding-ის ნაკადი

  1. სპეციფიკაციის დოკუმენტის დაწერა: ნათლად განსაზღვრეთ შეყვანა/გამომავალი, მონაცემთა სტრუქტურები, შეცდომების დამუშავება, შესრულების მოთხოვნები, არაფუნქციონალური მოთხოვნები (მაგ. ჟურნალი, ლიმიტირება).
  2. სპეციფიკაციის დაყოფა ამოცანებად: მაგ. ამოცანა 1: განახორციელეთ fetch_hot_topics() ფუნქცია, spec-ში მითითებული API-ს ხელმოწერის დაცვით.
  3. თითოეული ამოცანისთვის AI-ს მიერ განხორციელება: prompt უნდა შეიცავდეს ფუნქციის ხელმოწერას, კომენტარებს, ტესტის შემთხვევების მოლოდინებს.
  4. ადამიანური მიმოხილვა და ვალიდაცია: უზრუნველყოთ, რომ შეესაბამება spec-ს, გაუშვით ერთეულის ტესტები.
  5. ინტეგრაცია და რეგრესია.

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 არის მკაცრი მოთხოვნა.“

评论

暂无已展示的评论。

发表评论(匿名)