AI สัมภาษณ์ตอนที่ 14: ความแตกต่างระหว่าง Vibe Coding และ Spec Coding?

นี่คือปัญหาที่โปรแกรมเมอร์ส่วนใหญ่ต้องเผชิญ Vibe Coding และ Spec Coding เป็นแนวทางการทำงานที่แตกต่างกันอย่างชัดเจนเมื่อใช้โมเดลภาษาใหญ่ (LLM) ในการเขียนโปรแกรม ความแตกต่างหลักคือ "อินพุต" ที่คุณให้ AI เป็นความรู้สึกที่คลุมเครือ หรือข้อกำหนดที่แม่นยำ

หนึ่ง อธิบายความแตกต่างระหว่าง vibe coding และ spec coding อย่างง่ายด้วยการทำอาหาร

Vibe Coding = คุณบอกเพื่อนว่า "อยากกินเผ็ด" เพื่อนก็ปรุงตามความรู้สึก คุณชิมแล้วบอกว่า "เค็มอีกหน่อย" เขาก็เติมเกลือ รสชาติอาจจะดี แต่ถ้าเปลี่ยนเพื่อนคนอื่นทำ รสชาติจะต่างออกไปโดยสิ้นเชิง
Spec Coding = คุณเขียนสูตรอาหาร: "เต้าซีถั่วเหลือง 20 กรัม, เนื้อวัวหั่นบาง 150 กรัม, คื่นช่าย 50 กรัม, ผัดด้วยไฟแรง 2 นาที, ใส่น้ำตาล 3 กรัมก่อนยก出锅" พ่อครัวคนไหนทำตามสูตรก็ได้รสชาติที่เหมือนกัน

สอง ความหมายของทั้งสอง

มิติ	Vibe Coding	Spec Coding
ชื่ออื่น	การเขียนโปรแกรมแบบใช้ความรู้สึก, การใช้ prompt แบบกะทันหัน	การเขียนโปรแกรมแบบใช้ข้อกำหนด, เอกสารมาก่อน
รูปแบบอินพุต	"ช่วยทำให้หน้า login ดูสวยงาม มีความไฮเทคหน่อย"	"หน้า login ต้องมีช่องกรอกอีเมล/รหัสผ่าน, ช่องทำเครื่องหมายจำฉัน, ปุ่มส่ง; frontend ใช้ React + Tailwind; เงื่อนไขตรวจสอบฟอร์ม: รูปแบบอีเมล, รหัสผ่านความยาว≥8; เมื่อล้มเหลวให้แสดงข้อความเตือนสีแดง..."
วิธีใช้ AI	แบบสนทนา, ทำซ้ำ: ให้ทิศทางคร่าวๆ → ดูผลลัพธ์ → ปรับแต่ง	แบบวิศวกรรม: เขียน PRD/ข้อกำหนดทางเทคนิคอย่างละเอียดก่อน → AI สร้างโค้ดตามข้อกำหนด
ระดับการมีส่วนร่วมของมนุษย์	ต่ำ: พึ่งพา AI ในการสร้างสรรค์ คนแค่ดูว่า "รู้สึกถูกต้องไหม"	สูง: คนออกแบบ/สถาปัตยกรรมก่อน AI ทำงานเป็นหลักในการปฏิบัติ
สถานการณ์ทั่วไป	ต้นแบบเร็ว, เครื่องมือส่วนตัว, สำรวจ UI, เขียนโค้ดเชิงสร้างสรรค์	ระบบระดับ production, การทำงานร่วมกันในทีม, โค้ดที่ต้องบำรุงรักษา/ทดสอบได้

สาม เปรียบเทียบขั้นตอนการทำงาน

ขั้นตอน Vibe Coding

ความคิดคลุมเครือ: "อยากเขียนเว็บ scraper ดึงกระทู้ยอดนิยมจาก Zhihu"
เขียน prompt แรก: ให้ AI สร้างโค้ดเลย
รัน → เจอ error → วาง error กลับไป → AI แก้ไข
รู้สึกว่า UI ไม่สวย → "ทำให้ปุ่มนั้นโค้งขึ้นอีก เปลี่ยนพื้นหลังเป็น gradiant สีฟ้า" → AI แก้
ขาดฟังก์ชัน → "เพิ่มฟังก์ชันบันทึกเป็น CSV" → AI เพิ่ม
ทำซ้ำข้อ 3-5 จนกว่า "รู้สึกว่าใช้ได้แล้ว"

ขั้นตอน Spec Coding

เขียนเอกสารข้อกำหนด: กำหนด input/output, โครงสร้างข้อมูล, การจัดการข้อผิดพลาด, ข้อกำหนดด้านประสิทธิภาพ, ข้อกำหนดที่ไม่ใช่ฟังก์ชัน (เช่น log, rate limit)
แบ่งข้อกำหนดเป็นงานย่อย: เช่น งานที่ 1: สร้างฟังก์ชัน fetch_hot_topics() ตาม signature ที่ระบุใน spec
ให้ AI ทำให้ทีละงาน: prompt มี function signature, comment, และ expected test case
ตรวจสอบและยืนยันโดยมนุษย์: ตรวจสอบว่าตรงตามข้อกำหนด และรัน unit test
รวมและ regression

สี่ เปรียบเทียบข้อดีข้อเสีย

คุณลักษณะ	Vibe Coding	Spec Coding
ความเร็วในการเริ่มต้น	เร็วมาก ใช้เวลาไม่กี่นาทีได้ต้นแบบ	ช้า ต้องเขียนเอกสารและแบ่งงาน
คุณภาพโค้ด	ต่ำ (อาจซ้ำซ้อน, ไม่สอดคล้อง, มีบั๊กซ่อนอยู่)	สูง (อ่านง่าย, ทดสอบได้, ตรงตามสถาปัตยกรรม)
การบำรุงรักษา	แย่ คนอื่นไม่เข้าใจ "ทำไมถึงเขียนแบบนั้น"	ดี ข้อกำหนดคือเอกสาร
การพึ่งพา LLM	สูงมาก ถ้าเปลี่ยนโมเดลอาจได้ผลลัพธ์ต่างกันโดยสิ้นเชิง	ปานกลาง ถ้าข้อกำหนดชัดเจน โมเดลต่างก็ให้โครงสร้างคล้ายกัน
ความยากในการดีบัก	ยาก ไม่รู้ว่าโค้ดมาจากตรรกะไหน	ง่าย ตรวจสอบตาม spec ทีละข้อ
เหมาะสำหรับการทำงานเป็นทีม	แทบเป็นไปไม่ได้	ได้ (spec เป็นสัญญาการสื่อสาร)
ความแน่นอนของผลลัพธ์	ต่ำ ผลลัพธ์จากการสนทนาแต่ละครั้งอาจเลื่อนไหล	สูง spec เดียวกันให้ผลลัพธ์ที่เสถียร

ห้า คำแนะนำในการใช้งานในชีวิตจริง

"ในที่ทำงาน เราไม่ต้องเลือกอย่างใดอย่างหนึ่งระหว่าง vibe coding และ spec coding แต่ใช้ ผสมผสานกัน โดยเลือกวิธีที่เหมาะสมกับสถานการณ์:
- ในช่วงสำรวจ (เมื่อยังไม่แน่ใจในเทคโนโลยีหรือสไตล์ UI) ใช้ Vibe Coding เพื่อทดสอบทางเลือกต่างๆ อย่างรวดเร็ว เช่น 'ลองเขียน component การ์ดด้วย Tailwind ดูว่าหน้าตาเป็นยังไง'
- เมื่อตัดสินใจได้แล้ว ให้เปลี่ยนมาใช้ Spec Coding ทันที: นำต้นแบบที่สำเร็จมาเขียนเป็นข้อกำหนดที่ชัดเจน (input/output, ขอบเขต, การจัดการข้อผิดพลาด) แล้วให้ AI หรือคนเขียนโค้ดระดับ production ตาม spec อย่างเคร่งครัด
โหมด Vibe ล้วนๆ เหมาะกับสคริปต์ครั้งเดียวหรือเครื่องมือภายในเท่านั้น; สำหรับระบบที่ต้องดูแลระยะยาวและมีผู้ใช้หลายคน Spec Coding เป็นข้อบังคับ"