คุณเคยพบหรือไม่ว่าในระหว่างกระบวนการพัฒนา Vibe Coding โค้ดที่สร้างโดย AI นั้นเต็มไปด้วยช่องโหว่ทางตรรกะ ทำให้คุณต้องสงสัยในชีวิตขณะแก้ไขมัน?
ในการพัฒนาแบบดั้งเดิม Spec คือความยุติธรรม แต่เมื่อร่วมมือกับ AI เราเปรียบเสมือน “ผู้กำกับ” มากกว่า
การทำให้นักแสดง AI ที่มีความสามารถแต่บางครั้งก็ “บ้าคลั่ง” แสดงได้ดี คุณต้องมีเครื่องมือที่ทรงพลังสองอย่าง: EARS (ตรรกะบทละคร) และ BDD (ภาพนิ่งการยอมรับ)
EARS: เปลี่ยนความต้องการให้เป็น “บล็อกตรรกะ”
คุณต้องเคยเจอ PM แบบนี้ ที่เขียนความต้องการเช่น: “ระบบต้องใช้งานง่ายขึ้น”, “ความเร็วในการประมวลผลต้องเร็ว” นี่คือหายนะเมื่อเขียนโค้ด
EARS (Easy Approach to Requirements Syntax) พูดง่ายๆ ก็คือการเปลี่ยน “คำคุณศัพท์ที่คลุมเครือ” เหล่านี้ให้เป็น “คำสั่งที่แม่นยำ”
EARS เปรียบเสมือน Prompt Engineering ระดับท็อป ที่บังคับให้คุณพูดด้วยตรรกะแบบปิด รูปแบบประโยคหลัก 5 แบบช่วยให้คุณ “ล็อค” ขอบเขตความต้องการได้ตลอดเวลา:
| ประเภท | คำอธิบาย |
|---|---|
| Ubiquitous (แบบทั่วไป) | ระบบต้อง... (เหมือนการหายใจ ต้องปฏิบัติตามตลอดเวลา) |
| Event-driven (ขับเคลื่อนด้วยเหตุการณ์) | เมื่อ [เหตุการณ์เกิดขึ้น] ระบบต้อง... |
| Unwanted Behavior (พฤติกรรมที่ไม่ต้องการ) | หาก [สิ่งเลวร้ายเกิดขึ้น] ระบบต้อง... (นี่คือจิตวิญญาณของ Error Handling) |
| State-driven (ขับเคลื่อนด้วยสถานะ) | ขณะ [อยู่ในสถานะเฉพาะ] ระบบต้อง... |
| Optional Feature (ฟีเจอร์เสริม) | เมื่อ [มีฟีเจอร์รวมอยู่] ระบบต้อง... |
EARS ช่วยให้คุณตั้งกฎที่เข้มงวด
ทำให้ AI ไม่สามารถ “พูดเรื่องไร้สาระด้วยหน้าตาจริงจัง” ในทางตรรกะได้
BDD: เปลี่ยนการทดสอบให้เป็น “บทภาพยนตร์”
หาก EARS คือสัญญาทีรัดกุม BDD (Behavior Driven Development) ก็คือ “เรื่องราวที่มีเลือดเนื้อ” มันไม่ได้ทดสอบ a == b แต่ทดสอบ “สิ่งที่ผู้ใช้รู้สึกว่าเกิดขึ้น”
ไวยากรณ์ที่ใช้ใน BDD เรียกว่า Gherkin (แตงกวาดอง ต้องกรอบและสดชื่น!) และไตรภาคหลักมีดังนี้:
| ไวยากรณ์ | คำอธิบาย |
|---|---|
| 🎬 Given (พื้นหลัง) | การตั้งฉากก่อนถ่ายทำ (เช่น: มีเงิน 100 ดอลลาร์ในกระเป๋า) |
| ⚡ When (การกระทำ) | จังหวะที่ผู้กำกับตะโกน Action (เช่น: สั่งปลาหมึกเผ็ดมาก) |
| ✅ Then (ผลลัพธ์) | ตอนจบที่ผู้ชมเห็น (เช่น: ได้รับปลาหมึกหอมกรุ่น กระเป๋าเงินลดลง 60 ดอลลาร์) |
ด้วยวิธีการ “เล่าเรื่อง” นี้ แม้แต่ผู้ที่ไม่ใช่วิศวกรก็สามารถสื่อสารกับเราได้ และ AI ก็สามารถเข้าใจความตั้งใจจริงของคุณผ่าน “ตัวอย่างจริง” เหล่านี้ได้เช่นกัน
ความแตกต่างระหว่าง EARS vs BDD คืออะไร?
ทั้งสองนี้ทำหน้าที่ของตนเอง และการรวมกันคือ “ไร้เทียมทาน” อย่างแท้จริง
| คุณสมบัติ | EARS (ไวยากรณ์ความต้องการ) | BDD (ขับเคลื่อนด้วยพฤติกรรม) |
|---|---|---|
| จิตวิญญาณหลัก | นิยามที่แม่นยำ (ขจัดความคลุมเครือ) | ฉันทามติและการตรวจสอบ (การเล่าเรื่อง) |
| เหมือนกับการเขียน… | ข้อกฎหมาย | บทภาพยนตร์ |
| ผู้ชมหลัก | PM, สถาปนิก, ผู้สร้างกฎ | วิศวกร, QA, ผู้ช่วย AI |
| แก้ปัญหาความเจ็บปวด | “สิ่งที่คุณทำไม่ใช่สิ่งที่ฉันคิด!” | “ตรรกะถูกต้อง แต่ใช้งานไม่ได้!” |
พูดง่ายๆ: EARS ช่วยคุณตั้งกฎ, BDD ช่วยคุณตรวจสอบผลลัพธ์
การประยุกต์ใช้ขั้นสูงของ EARS: Vibe Coding ในทางปฏิบัติ
เราใส่กฎ EARS และบท BDD ลงใน Prompt โดยตรงเพื่อให้ AI พัฒนา
คุณสามารถลองสั่งงานแบบนี้เมื่อพัฒนา “การหักเงินใน E-wallet”:
# งาน: โปรดช่วยฉันใช้ API การหักเงิน
## ตรรกะ EARS (โปรดปฏิบัติตามอย่างเคร่งครัด):
- [Event-driven]: เมื่อได้รับคำขอ ต้องตรวจสอบยอดเงินคงเหลือ
- [Unwanted]: หากยอดเงินไม่เพียงพอ ให้ส่งคืนรหัสข้อผิดพลาด 400 'INSUFFICIENT_FUNDS'
- [State-driven]: ขณะที่กระเป๋าเงินอยู่ในสถานะ 'Frozen' ให้ปฏิเสธการหักเงินทั้งหมด
## บทการยอมรับ BDD (สำหรับการทดสอบ Jest):
Scenario: การหักเงินล้มเหลวเนื่องจากยอดเงินไม่เพียงพอ
Given ยอดเงินของผู้ใช้คือ 50 ดอลลาร์
When ได้รับคำขอหักเงิน 100 ดอลลาร์
Then API ควรส่งคืน HTTP 400
And รหัสข้อผิดพลาดควรเป็น 'INSUFFICIENT_FUNDS'
ลองโยนสิ่งนี้ให้ AI แล้ว Code ที่สร้างขึ้นจะไม่เบี่ยงเบนไปจากเป้าหมายมากนัก!
บทสรุป
ไม่ว่าจะเป็นในการพัฒนาประจำวันหรือ Vibe Coding, EARS และ BDD คือสิ่งประดิษฐ์สำหรับเพิ่มประสิทธิภาพ
EARS ช่วยคุณตั้งกฎที่เข้มงวด, BDD ช่วยคุณยืนยันผลลัพธ์การแสดง