จาก PRD สู่แอป: Workflow Vibe Coding ที่ใช้ได้จริง
วิธีเขียน PRD หนึ่งหน้าให้ AI เข้าใจ และ workflow 6 ขั้นที่ทำให้แอปไม่เพี้ยนเมื่อสั่งแก้หลายรอบ พร้อมตัวอย่างร้านเค้กในขอนแก่น
หลายคนเริ่ม vibe coding ด้วยการพิมพ์ประโยคเดียวว่า "ทำแอปรับออเดอร์ให้หน่อย" แล้วได้หน้าตาสวยๆ มาในไม่กี่นาที แต่พอสั่งแก้ไปสิบรอบ แอปเริ่มเพี้ยน ปุ่มที่เคยใช้ได้กลับพัง ข้อมูลเก็บไม่ครบ สาเหตุส่วนใหญ่ไม่ได้อยู่ที่ AI แต่อยู่ที่เราไม่ได้บอกให้ชัดตั้งแต่แรกว่ากำลังสร้างอะไร ทางแก้คือมี PRD สั้นๆ และ workflow ที่เป็นขั้นตอน
PRD คืออะไร และทำไม Vibe Coding ต้องมี
PRD (Product Requirements Document) คือเอกสารที่บอกว่าผลิตภัณฑ์นี้แก้ปัญหาอะไร ให้ใคร ทำอะไรได้บ้าง และอะไรที่ยังไม่ทำ ในโลก vibe coding PRD ทำหน้าที่เป็น context หลักที่ AI จะกลับมาอ้างอิงทุกครั้ง เพราะ LLM ไม่ได้จำเจตนาของคุณได้สมบูรณ์ตลอดบทสนทนายาวๆ ยิ่งคุยนาน รายละเอียดช่วงต้นยิ่งเลือนไป การมีเอกสารกลางช่วยดึงทุกอย่างกลับมาที่เดิม
โครงสร้าง PRD หนึ่งหน้าที่ใช้ได้จริง
ส่วนที่ต้องมี
- ปัญหา: เกิดกับใคร บ่อยแค่ไหน ตอนนี้แก้ยังไง
- ผู้ใช้และบทบาท: เช่น ลูกค้า เจ้าของร้าน พนักงาน แต่ละบทบาทเห็นอะไรได้บ้าง
- User stories: เขียนแบบ "ในฐานะ... ฉันอยากทำ... เพื่อ..."
- ข้อมูลที่ต้องเก็บ: มีตารางอะไร แต่ละตารางมีฟิลด์อะไร เชื่อมกันยังไง
- หน้าจอหลัก: ระบุเป็นรายการ ไม่ต้องวาดก็ได้
- Out of scope: สิ่งที่ยังไม่ทำในรอบนี้ ช่วยกันไม่ให้ AI เพิ่มของเกินมา
- Acceptance criteria: เงื่อนไขที่บอกว่าฟีเจอร์นี้ "เสร็จ" แล้ว
ให้ AI ช่วยร่าง แต่คุณต้องเป็นคนตัดสิน
คุณเล่าปัญหาเป็นภาษาคนให้ AI แล้วขอให้ร่าง PRD ตามโครงข้างบน จากนั้นสั่งให้มัน "ตั้งคำถามกลับ 10 ข้อเกี่ยวกับสิ่งที่ยังไม่ชัด" ขั้นนี้มักเผยจุดที่คุณไม่เคยคิด เช่น ลูกค้ายกเลิกออเดอร์ได้ไหม หรือถ้าสินค้าหมดจะเกิดอะไรขึ้น
Workflow 6 ขั้น จาก PRD สู่แอป
ขั้นที่ 1: วางแผนก่อนลงมือ
ส่ง PRD ให้เครื่องมือ แล้วขอ "แผนการสร้าง" ก่อน ยังไม่ต้องเขียนโค้ด บางเครื่องมือมีโหมดคุยวางแผนแยกจากโหมดแก้โค้ด ถ้าไม่มี ก็สั่งตรงๆ ว่า "อย่าเพิ่งแก้ไฟล์ ขอแผนเป็นขั้นตอนก่อน"
ขั้นที่ 2: สร้างโครงและข้อมูล
เริ่มจาก layout หลัก การ login และโครงสร้างข้อมูล ก่อนลงรายละเอียดหน้าตา เพราะการแก้โครงสร้างข้อมูลทีหลังมักกระทบหลายหน้า
ขั้นที่ 3: ทำทีละ Vertical Slice
Vertical slice คือฟีเจอร์หนึ่งที่ทำครบตั้งแต่หน้าจอถึงการบันทึกข้อมูล เช่น "ลูกค้าสั่งเค้กได้และเจ้าของเห็นออเดอร์" ทำให้จบทีละ slice ดีกว่าสร้างทุกหน้าพร้อมกันแบบครึ่งๆ กลางๆ
ขั้นที่ 4: ทดสอบตาม Acceptance Criteria
หลังจบแต่ละ slice ไล่เช็กตามเงื่อนไขที่เขียนไว้ใน PRD ลองกรณีแปลกๆ ด้วย เช่น กรอกช่องว่าง กดปุ่มซ้ำสองครั้ง
ขั้นที่ 5: เก็บจุดย้อนกลับ
เมื่อ slice ทำงานถูกต้อง ให้บันทึกเวอร์ชันไว้ (เช่น เชื่อม GitHub หรือใช้ระบบ version history ของเครื่องมือ) ถ้ารอบถัดไปพัง คุณย้อนกลับมาจุดที่ดีได้ทันที
ขั้นที่ 6: อัปเดต PRD
ทุกครั้งที่ตัดสินใจเปลี่ยนอะไร ให้แก้ PRD ด้วย เอกสารจะได้ตรงกับแอปจริงเสมอ
ตัวอย่าง: ร้านเค้กโฮมเมดในขอนแก่น
เจ้าของร้านรับออเดอร์ผ่านแชตจนจดตกหล่นบ่อย เธอเขียน PRD หนึ่งหน้า: ลูกค้าเลือกแบบเค้ก ขนาด วันรับ และแนบรูปตัวอย่างได้ เจ้าของเห็นรายการออเดอร์เรียงตามวันรับ ส่วน out of scope คือยังไม่รับชำระเงินออนไลน์ เมื่อ AI ถามกลับว่า "รับออเดอร์ล่วงหน้าได้กี่วัน" เธอจึงนึกได้ว่าต้องปิดรับวันที่คิวเต็ม เลยเพิ่มเป็น user story ใหม่ ผลคือแอปที่ได้ตรงกับงานจริงตั้งแต่รอบแรก แทนที่จะต้องรื้อทีหลัง
สั่งให้ชัดหนึ่งหน้า ดีกว่าสั่งแก้สิบรอบ
ข้อควรระวัง
- อย่าใส่ข้อมูลลูกค้าจริง รหัสผ่าน หรือ API key ลงใน PRD เพราะเอกสารนี้จะถูกส่งเข้า AI ซ้ำหลายครั้ง
- ระบุใน PRD ให้ชัดว่าใครเห็นข้อมูลอะไร เช่น ลูกค้าเห็นเฉพาะออเดอร์ของตัวเอง ถ้าไม่เขียน AI อาจสร้างหน้าที่ทุกคนเห็นทุกอย่าง
- ฟีเจอร์ที่เกี่ยวกับเงินหรือข้อมูลส่วนบุคคล ควรแยกเป็น slice ของตัวเองและให้คนที่เข้าใจระบบช่วยรีวิว
ทำอะไรต่อ
- เลือกไอเดียหนึ่งเรื่อง แล้วเขียนปัญหาและผู้ใช้ให้ได้ใน 5 บรรทัด
- ให้ AI ร่าง PRD ตามโครง 7 ส่วน แล้วสั่งให้ถามกลับ
- ตัดฟีเจอร์ให้เหลือ 2 ถึง 3 slice สำหรับเวอร์ชันแรก
- สร้างทีละ slice ทดสอบ แล้วบันทึกเวอร์ชันทุกครั้ง
ถ้ายังไม่แน่ใจว่า vibe coding คืออะไร อ่านพื้นฐานได้ที่ Vibe Coding คืออะไร และถ้าอยากรู้ว่าทักษะการเขียน requirement แบบนี้ต่อยอดไปสายงานไหนได้บ้าง ลองคุยกับ AI Career Assistant ของ Plants.work เพื่อดูเส้นทางอาชีพที่เหมาะกับคุณ