vibe ไม่ใช่ spec เขียน PRD ให้ AI สร้างของถูก

เดี๋ยวนี้ใครก็สร้างแอปได้ในบ่ายเดียว เปิด Cursor หรือ Lovable พิมพ์ว่าอยากได้อะไร AI ก็ต่อหน้าจอให้ กดไม่กี่ทีก็มีของรันได้จริง นี่คือสิ่งที่เรียกกันว่า vibe coding เขียนโปรแกรมตามความรู้สึก บอกไอเดียคร่าวๆ แล้วปล่อยให้ AI เติมที่เหลือ

ปัญหาไม่ได้อยู่ที่มันสร้างไม่ได้ มันสร้างได้เร็วจนน่าตกใจ ปัญหาคือมันสร้าง "ของที่ดูเหมือนใช่" เปิดดูครั้งแรกก็ว้าว แต่พอลองกดใช้จริงถึงรู้ว่ามันเข้าใจโจทย์คนละอย่างกับที่เราคิด เราก็พิมพ์สั่งแก้ AI แก้ตรงนั้นแต่ไปพังตรงอื่น วนแบบนี้จนเครดิตหมด ของก็ยังไม่ตรง

จุดที่พลาดคือเราให้ AI ทำสองอย่างพร้อมกัน ทั้ง "คิดว่าจะสร้างอะไร" และ "ลงมือสร้าง" ทั้งที่สองอย่างนี้ควรแยกกัน vibe บอกความรู้สึกได้ แต่ไม่ได้บอกว่าอะไรคือถูก สิ่งที่บอกได้คือ spec และ spec ที่เบาพอจะเขียนก่อนลงมือทุกครั้งก็คือ PRD ย่อๆ บทความนี้เล่าว่า vibe coding พังตรงไหน PRD ขั้นต่ำที่กันมันหน้าตาเป็นยังไง แล้วเช็กยังไงว่าไอเดียพร้อมให้ AI สร้าง

ช่วงที่ 1vibe coding พังตรงไหน

ก่อนจะแก้ ต้องเห็นก่อนว่ามันพังยังไง เพราะ vibe coding ไม่ได้พังแบบล้มครืนให้เห็นชัดๆ มันพังแบบเนียนๆ ที่ทำให้เราหลงคิดว่ากำลังไปได้สวย

มันไม่ได้สร้างไม่ได้ มันสร้างผิด

AI เก่งเรื่องเติมช่องว่าง เราบอกไม่หมด มันก็เดาส่วนที่เหลือให้ แต่มันเดาตามสิ่งที่ "น่าจะใช่" จากของที่มันเคยเห็นมา ซึ่งมักไม่ตรงกับบริบทเฉพาะของงานเรา ผลคือได้ของที่ถูกตามสูตรทั่วไป แต่ผิดสำหรับโจทย์จริงของเรา

ยิ่งแก้ยิ่งพัง

พอของออกมาไม่ตรง เราก็พิมพ์สั่งแก้ทีละจุด แต่ AI ไม่มีภาพรวมว่าอะไรห้ามพัง มันเห็นแค่คำสั่งล่าสุด เลยแก้ตรงที่บอกแล้วเผลอทำอย่างอื่นพังตาม ไม่มี spec ก็เท่ากับไม่มีนิยามของคำว่าถูก AI เลยเอาความมั่นใจมาแทนความถูก แล้วเราก็ไล่แก้ไม่จบ

เปิดดูครั้งแรกสวย ไม่ได้แปลว่าใช้ได้จริง

ของที่ AI สร้างมักดูดีตอนเปิดดูหน้าแรก ปุ่มครบ หน้าตาเรียบร้อย แต่พอกดเดินเส้นทางจริง ใส่ข้อมูลแปลกๆ หรือลองกรณีที่ไม่ปกติ ถึงเจอรูเต็มไปหมด เพราะ vibe จับได้แค่ผิว ส่วนกรณีขอบและกฎที่ไม่ได้พูดออกมา มันไม่รู้ว่าต้องมี

ช่วงที่ 2PRD ขั้นต่ำที่ทำให้ AI สร้างของถูก

ข่าวดีคือ spec ที่ AI ต้องการไม่ใช่เอกสาร requirement หนาเป็นเล่มแบบสมัยก่อน แค่ครึ่งหน้าที่ตอบให้ครบ 8 หัวข้อก็เปลี่ยนผลได้มาก เพราะแต่ละหัวข้อคือช่องว่างที่ถ้าไม่เขียน AI จะเดาแทน

8 หัวข้อที่ AI ต้องรู้ก่อนสร้าง

1. ปัญหาและผู้ใช้ แก้อะไร ให้ใคร เขาเจ็บปวดตรงไหน
2. ขอบเขต ทำอะไร และที่สำคัญกว่าคือ ไม่ทำอะไร
3. สิ่งที่ต้องทำได้ เขียนเป็นข้อๆ ไม่ใช่ย่อหน้าลอยๆ
4. เกณฑ์ยอมรับที่ตรวจได้ "ถือว่าเสร็จเมื่อ..." แบบที่ชี้ถูกผิดได้
5. ข้อมูลและสถานะ มีข้อมูลอะไร เก็บที่ไหน หน้าตาแบบไหน
6. ข้อจำกัดและสิ่งที่ห้าม กันไม่ให้ AI เตลิดไปไกลเกิน
7. กรณีขอบ ว่างเปล่า ผิดพลาด โหลดช้า ล้มเหลว จะให้ทำยังไง
8. เกณฑ์ว่าเสร็จ (definition of done) หน้าตาของงานที่ส่งได้จริง

ข้อที่ขาดไม่ได้คือเกณฑ์ยอมรับ เพราะมันเป็นที่เดียวที่เขียนคำว่า "ถูก" ให้เป็นรูปธรรม หัวข้ออื่นบอก AI ว่าจะสร้างอะไร แต่หัวข้อนี้บอกว่าสร้างเสร็จแล้วดูยังไงว่าใช่

เขียนเกณฑ์ยอมรับให้ AI เช็กตัวเองได้

เกณฑ์ที่ดีต้องตรวจได้ ไม่ใช่ "ใช้งานง่าย" หรือ "เร็ว" ซึ่งแปลได้ร้อยแบบ แต่เป็น "กดปุ่มบันทึกแล้วต้องเห็นรายการใหม่ในตารางภายใน 2 วินาที" หรือ "ถ้ากรอกอีเมลผิดรูปแบบ ต้องขึ้นข้อความเตือนใต้ช่อง ไม่ใช่ส่งฟอร์มไป" พอเป็นรูปธรรมแบบนี้ AI ตรวจงานตัวเองได้ และเราตรวจงาน AI ได้ด้วยตาเปล่า

PRD คือ spec, spec คือแหล่งความจริง

แนวคิดนี้มีชื่อเรียกว่า spec-driven development เก็บ spec ไว้เป็นหลัก เวลาจะแก้อะไรให้แก้ที่ spec ก่อน แล้วค่อยให้ AI สร้างตามใหม่ ต่างจาก vibe coding ที่สั่งแก้ตัวโค้ดตรงๆ ข้อดีคือผลซ้ำได้ กลับมาทำใหม่อีกรอบก็ได้ของที่ตรงกัน และมีที่เดียวให้ดูว่าตกลงจะสร้างอะไรกันแน่ ไม่ใช่ประวัติแชทยาวเหยียดที่ไม่มีใครไล่ย้อนไหว

ช่วงที่ 3เช็กว่าไอเดียพร้อมยัง แล้วเริ่มเลย

เช็กก่อนเผาเครดิต

ก่อนปล่อยให้ AI ลงมือสร้าง ลองถามตัวเองสั้นๆ ว่าตอบได้ครบไหม รู้ปัญหาและผู้ใช้หรือยัง ขอบเขตชัดไหมว่าอะไรอยู่ในอะไรอยู่นอก เขียนสิ่งที่ต้องทำได้เป็นข้อๆ ได้ไหม และที่สำคัญ เขียนเกณฑ์ยอมรับที่ตรวจได้ออกมาสักข้อได้หรือเปล่า ทุกข้อที่ตอบไม่ได้ คือช่องที่ AI จะเดาแทนเรา ยิ่งตอบไม่ได้เยอะ ยิ่งเผาเครดิตแก้ทีหลังเยอะ

กฎเดียวที่ต้องจำ

ถ้าจะหยิบไปใช้ข้อเดียว ขอให้เป็นข้อนี้ อย่าให้ AI คิดโจทย์และลงมือสร้างพร้อมกัน เขียน spec สั้นๆ ก่อนเสมอ แม้แค่ครึ่งหน้าก็ยังดีกว่าไม่มี แล้วให้ AI สร้างตามนั้น ไม่ใช่ให้มันเดาทั้งโจทย์และคำตอบในคราวเดียว

เริ่มยังไงดี

ไม่ต้องรอ PRD สวยสมบูรณ์ เริ่มจากครึ่งหน้าแล้วให้ AI ช่วยขัดก็ได้

1. เขียน PRD ครึ่งหน้าตาม 8 หัวข้อข้างบน เอาแค่ปัญหา ผู้ใช้ ขอบเขต สิ่งที่ต้องทำได้ และเกณฑ์ยอมรับก่อน
2. ให้ AI อ่าน spec แล้ว "ตีกลับ" ก่อนสร้าง ถามมันว่าตรงไหนยังกำกวม ตรงไหนที่มันจะต้องเดา จุดที่มันชี้คือช่องโหว่ของ spec
3. แก้ spec ให้ชัดตามที่มันถาม แล้วค่อยสั่งให้สร้าง
4. เทสต์กับเกณฑ์ยอมรับทีละข้อ ข้อไหนไม่ผ่าน กลับไปแก้ที่ spec ไม่ใช่สั่งแก้โค้ดลอยๆ

พอมี spec นำ vibe coding จะยังเร็วเหมือนเดิม แต่ได้ของที่ตรง ไม่ใช่ของที่ต้องมานั่งเดาใจ AI ทีหลัง ถ้าอยากได้ตัวช่วยเช็กความพร้อมของไอเดียและตีกลับเป็นโครง PRD ให้ เราทำเครื่องมือฟรีไว้ที่ productize.life/services/prd