วิธีเขียน PRD ให้ AI สร้างได้ตามที่คิด เทมเพลต พร้อมตัวอย่าง

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

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

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

ช่วงที่ 1เทมเพลต PRD 8 หัวข้อ แต่ละช่องถามอะไร

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

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

ช่องที่ห้ามปล่อยว่าง: เกณฑ์ยอมรับ

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

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

ช่วงที่ 2เขียนจริงทีละหัวข้อ (ตัวอย่างแอปหารบิล)

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

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

ปรับความละเอียดตามขนาดงาน

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

ช่วงที่ 3ให้ AI ตรวจ spec ก่อนสั่งสร้าง

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

สั่งให้ AI ตีกลับ ไม่ใช่สั่งให้สร้าง

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

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

เทสต์กับเกณฑ์ยอมรับ ไม่ใช่กับความรู้สึก

พอ AI สร้างเสร็จ อย่าเพิ่งดูว่า "หน้าตาโอเคนะ" ให้เปิดเกณฑ์ยอมรับที่เขียนไว้มาไล่ทีละข้อ บิล 900 หาร 3 ได้ 300 ไหม ยอดรวมกลับมาเท่าบิลไหม คนจ่ายก่อนไม่ต้องโอนให้ตัวเองใช่ไหม ข้อไหนไม่ผ่าน กลับไปแก้ที่ spec ก่อน แล้วให้ AI สร้างใหม่ ไม่ใช่พิมพ์สั่งแก้โค้ดตรงๆ เพราะการแก้ที่ spec ทำให้ครั้งหน้าที่สร้างก็ยังถูก ส่วนการสั่งแก้โค้ดลอยๆ เดี๋ยวก็พังที่เดิม

เริ่มเลยวันนี้

ไม่ต้องรอ PRD สวยสมบูรณ์ ก๊อป 8 หัวข้อไปเป็นโครงเปล่า เขียนครึ่งหน้ากับไอเดียที่ค้างอยู่ในหัวสักอัน แล้วลองวงจรนี้ เขียน ให้ AI ตีกลับ อุดรู สร้าง เทสต์กับเกณฑ์ รอบเดียวก็จะเห็นว่ามันต่างจากการพิมพ์สั่งเปล่าๆ แค่ไหน ถ้าอยากได้ตัวช่วยเช็กว่าไอเดียพร้อมยัง แล้วตีกลับเป็นโครง PRD ให้เลย เราทำเครื่องมือฟรีไว้ที่ productize.life/services/prd