สรุปและฝึกปฏิบัติ
สิ่งสำคัญที่ควรจำ
- สเปกคือบันทึกทำงานสั้น ๆ เขียนด้วยภาษาธรรมดา — สิ่งที่คุณกำลังสร้างและไม่ได้กำลังสร้าง — ไม่ใช่สัญญาที่ตรึงไว้ตายตัว หนึ่งหน้าก็เพียงพอแล้ว
- ทำความเข้าใจปัญหาและตัวคนก่อนพูดถึงฟีเจอร์ และเขียนสิ่งที่ไม่ทำลงไป: มันคือเกราะป้องกันที่คมที่สุดของคุณจาก AI ที่ชอบเพิ่มของแถม "ที่น่าจะมีประโยชน์"
- User story ที่มีส่วน
เพื่อที่จะและ PRD เล็ก ๆ ที่มีบรรทัด "Done When" ที่จับต้องได้ จะเปลี่ยนเจตนาให้กลายเป็นพฤติกรรมที่ทดสอบได้และสร้างได้จริง - ปักหมุดโมเดลข้อมูลไว้ตั้งแต่เนิ่น ๆ — ชื่อฟิลด์รั่วไหลไปทุกที่ — และแบ่งสเปกเป็นงานขนาดพอดีสำหรับ vibe coding ที่คุณตรวจสอบได้ทีละอย่าง
- อธิบายปัญหา ไม่ใช่ทางแก้ ผลลัพธ์ยังคงเปลี่ยนแปลงได้ง่ายในสเปกแต่แพงเมื่อต้องเปลี่ยนในโค้ด รักษาสเปกให้มีชีวิตอยู่ในขณะที่คุณเรียนรู้
ลองทำดู
หยิบไอเดียที่คุณเก็บไว้เฉย ๆ มาสักอันแล้วแปลงมันเป็นสเปกหนึ่งหน้าในเซสชัน AI เดียว ให้ AI สัมภาษณ์คุณด้วยคำถามคมคาย 5 ข้อก่อน จากนั้นเขียน — ด้วยคำพูดของคุณเอง — ปัญหา ผู้ใช้ user story สามข้อ (แต่ละข้อมีส่วน เพื่อที่จะ) ลิสต์สิ่งที่ไม่ทำอย่างชัดเจน โมเดลข้อมูลหกบรรทัด และบรรทัด "Done When" หนึ่งบรรทัดที่คุณลงมือทำได้จริง บันทึกไว้เป็น SPEC.md แบบทดสอบสเปกที่ดี: คุณควรแปะมันลงในแชทใหม่เอี่ยมได้ในวันพรุ่งนี้ และ AI จะรู้แน่ชัดว่าต้องสร้างอะไร
พรอมต์ประจำบท
I have a rough idea: <one-line description>.
Act as my product thinking partner. First, ask me 5 sharp questions,
one at a time, to clarify the problem, the target user, and what "done"
looks like. Don't propose features yet.
After I answer, draft a one-page spec with these sections:
- Problem - User - Goal
- In Scope (v1) - Non-Goals (v1)
- User stories (each "As a __, I want __, so that __")
- Data model (a short list of fields)
- Done When (a concrete, physically-performable acceptance test)
Keep it tight — under one page. If something is ambiguous, ask before
assuming. I'll edit the draft until I agree with every line.