Product Requirement Document (PRD) สำหรับ Vibe Coding

การสร้าง Application ในยุคปัจจุบันที่ใช้ AI เข้ามาช่วยเขียนโค้ด หรือที่เรียกว่า Vibe Coding นั้น หัวใจสำคัญไม่ใช่การเขียนโค้ด แต่คือการสื่อสารความต้องการให้ชัดเจนที่สุดโดยเน้นไปที่ Feature ว่ามีใครทำอะไรได้บ้าง และ Database Schema มีการเก็บข้อมูลอย่างไร ส่วนนี้จะแนะนำวิธีการเขียน Product Requirement Document (PRD) เพื่อเป็นแบบแปลนให้ AI เข้าใจและสร้างระบบที่ทำงานได้จริง

หมายเหตุ: ในบทความเน้นออกแบบ PRD สำหรับสร้าง Web Application ที่สามารถบันทึกข้อมูลได้ แต่สามารถประยุกต์ใช้กับ Project แบบอื่นได้

ความสำคัญของ PRD ในการพัฒนา Application

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

การเขียน PRD ที่ดีจะช่วยให้ AI เข้าใจโครงสร้างของข้อมูลและสิทธิ์การใช้งาน ซึ่งเป็นรากฐานสำคัญของทุก Application หากโครงสร้างเหล่านี้ไม่แข็งแรงแต่แรก การปรับแก้ในภายหลังจะทำได้ยากและซับซ้อ

องค์ประกอบหลักที่ต้องระบุใน PRD

การเขียน PRD ที่ครอบคลุมช่วยให้ AI มองเห็นภาพรวมและรายละเอียดเชิงลึกของระบบ โดยควรแบ่งเนื้อหาออกเป็น 3 ส่วนหลัก ดังนี้

1. ภาพรวมของ Application (Application Overview)

ส่วนนี้คือการระบุตัวตนของ Application เพื่อให้ AI ทราบบริบทและวัตถุประสงค์หลักของการทำงาน

• ชื่อ Application: ชื่อที่ใช้เรียกขาน
• วัตถุประสงค์: ทำขึ้นเพื่อแก้ปัญหาอะไร หรือช่วยอำนวยความสะดวกด้านใด
• ลักษณะการทำงาน: คำอธิบายรูปแบบการใช้งานเบื้องต้น

การระบุส่วนนี้ช่วยให้ AI สามารถเลือกใช้เครื่องมือหรือ Library ที่เหมาะสมกับบริบทของงานได้ดียิ่งขึ้น

2. โครงสร้างการจัดเก็บข้อมูล (Data Structure)

การออกแบบการจัดเก็บข้อมูลเปรียบเสมือนการออกแบบ “ตู้เก็บเอกสาร” ของระบบ คุณต้องบอก AI ว่าตู้ใบนี้ต้องมีลิ้นชักอะไรบ้าง และแต่ละลิ้นชักเก็บข้อมูลอะไร

• แยกกลุ่มข้อมูล: ระบุว่ามีเรื่องอะไรบ้างที่ต้องเก็บ เช่น “ข้อมูลลูกค้า”, “ข้อมูลสินค้า”, “ข้อมูลใบสั่งซื้อ”
• รายละเอียดข้างใน: ในแต่ละกลุ่มต้องมีข้อมูลอะไรบ้าง เช่น “ข้อมูลลูกค้า” ต้องจด ชื่อ, เบอร์โทร, ที่อยู่ ควรระบุรายละเอียดของข้อมูลย่อย (Attributes) ให้ครบถ้วน เช่น ข้อมูลผู้ซื้อต้องประกอบด้วย รหัสผู้ซื้อ, ชื่อ-นามสกุล และอีเมล การละเลยจุดนี้อาจทำให้ AI สร้างฐานข้อมูลที่ไม่รองรับการใช้งานจริง
• ความสัมพันธ์ของข้อมูล: อธิบายว่าข้อมูลเกี่ยวข้องกันอย่างไร
  • ตัวอย่างระบบใบสั่งซื้อ: ใบสั่งซื้อ 1 ใบ จะมีชื่อลูกค้าได้เพียง 1 คน แต่ในใบนั้นสามารถมีรายการสินค้าได้หลายชิ้น และต้องระบุว่าใครเป็นคนออกใบสั่งซื้อนี้

เคล็ดลับ: ลองจินตนาการว่าถ้าคุณต้องจดลงสมุด คุณจะตีตารางอย่างไร และต้องโยงข้อมูลจากหน้าไหนไปหน้าไหน บอก AI แบบนั้นได้เลย

ตัวอย่างการระบุโครงสร้างข้อมูล

ตัวอย่างที่ 1: ระบบสร้างใบเสนอราคา

ข้อมูลที่ต้องเก็บ

• ข้อมูลผู้ซื้อ
• ข้อมูลสินค้า
• ข้อมูลผู้ทำรายการ

คำถามสำคัญที่ต้องตอบก่อนออกแบบ

• หนึ่งใบเสนอราคามีผู้ซื้อได้กี่คน?
• หนึ่งใบเสนอราคามีสินค้าได้กี่รายการ?
• หนึ่งใบเสนอราคามีผู้ทำรายการได้กี่คน?

ตัวอย่างที่ 2: ระบบจองรถออนไลน์

ข้อมูลที่ต้องเก็บ

• ข้อมูลการจองรถ
• ข้อมูลรถ
• ข้อมูลคนจอง
• ข้อมูลผู้รับจอง
• ข้อมูลศูนย์บริการ

ความสัมพันธ์ของข้อมูล

• รถ 1 คัน
• คนจอง 1 คน
• ผู้รับจอง 1 คน
• ศูนย์บริการ 1 แห่ง

3. สิทธิ์และการกระทำของผู้ใช้งาน (User Roles & Actions)

การกำหนดบทบาทผู้ใช้งานช่วยรักษาความปลอดภัยและความเป็นระเบียบของระบบ โดยใช้หลักการ Given-When-Then เพื่ออธิบายเงื่อนไขอย่างเป็นตรรกะ

บทบาทพื้นฐานที่ในระบบมีอยู่แล้ว:

• Unverified: ผู้ใช้งานใหม่ที่ยังไม่ยืนยันตัวตน (ทำได้เพียงดูข้อมูลเบื้องต้น)
• User: สมาชิกที่ยืนยันตัวตนแล้ว (เข้าถึง Dashboard และใช้งานฟีเจอร์หลัก)
• Admin: ผู้ดูแลระบบ (จัดการข้อมูลผู้ใช้งานและแก้ไขการตั้งค่าระบบ)

การใช้ภาษาแบบ Given-When-Then: ภาษาลักษณะนี้ช่วยให้ AI เข้าใจเงื่อนไขการทำงานได้ทันทีโดยไม่ต้องตีความซับซ้อน

• Given (กำหนดให้): สถานะเริ่มต้น หรือบทบาทของผู้ใช้ (เช่น กำหนดให้ผู้ใช้เป็น Admin)
• When (เมื่อ): การกระทำที่เกิดขึ้น (เช่น เมื่อกดปุ่มลบผู้ใช้งาน)
• Then (ดังนั้น): ผลลัพธ์ที่ระบบต้องทำ (เช่น ระบบจะลบข้อมูลออกจากฐานข้อมูลทันที)

4. องค์ประกอบอื่น ๆ ถ้ามี

ส่วนนี้ไม่บังคับในเอกสาร PRD เบื้องต้น สามารถเพิ่มภายหลังได้ เนื่องจาก:

• เปลี่ยนแปลงบ่อย ตามการทดสอบและ feedback การใช้งาน
• สามารถปรับเปลี่ยนได้ง่ายโดยไม่จำเป็นต้องกำหนดใน PRD เช่นการสร้าง UI หรือการเพิ่มข้อความ
• รายละเอียดเชิงเทคนิคอื่น ๆ ที่ต้องการความเชี่ยวชาญในการตัดสินใจ จึงอาจจะยังไม่จำเป็นสำหรับโปรเจค Vibe Coding

รายละเอียดอื่น ๆ เช่น

• UX/UI
• Non-Functional Requirements (หากไม่ใช้ VibeKit จำต้องกำหนดเพิ่มเอง)
• Technical Specifications (หากไม่ใช้ VibeKit จำต้องกำหนดเพิ่มเอง)

ขั้นตอนการสร้างและใช้งาน PRD กับ AI

กระบวนการนี้จะช่วยเปลี่ยนไอเดียร่าง ให้เป็นเอกสารทางการ และนำไปสู่การเขียนโค้ดจริง

ขั้นตอนที่ 1: ใช้ AI ช่วยร่างและสรุป PRD

หากคุณมีเพียงไอเดียคร่าวๆ สามารถใช้ Prompt ด้านล่างนี้เพื่อให้ AI ช่วยเรียบเรียงเป็นภาษา PRD ที่ถูกต้อง

Prompt สำหรับให้ AI ช่วยสรุป PRD ฉบับเต็ม:

คุณคือ Product Manager และ System Analyst มืออาชีพที่มีทักษะในการอธิบายเรื่องเทคนิคให้เป็นภาษาธุรกิจที่เข้าใจง่าย (Non-tech friendly) 

ภารกิจของคุณคือ: สร้างเอกสาร PRD (Product Requirement Document) สำหรับแอปพลิเคชันตาม Idea ที่ฉันจะระบุ โดยต้องใช้โครงสร้างและกฎเกณฑ์ดังต่อไปนี้:

---
### 1. โครงสร้างเนื้อหาที่ต้องมี:
- **บทบาทผู้ใช้งาน (Roles):** โดยในระบบมีการกำหนดสิทธิ์พื้นฐานคือ Unverified, User, และ Admin (ระบุขอบเขตสิ่งที่แต่ละ Role ทำได้)
- **ความต้องการของระบบ (Requirements):** - เขียนในรูปแบบ "Given... When... Then..."
- **โครงสร้างข้อมูลและกรณีใช้งาน (Data Schema & Use Case):** อธิบายความสัมพันธ์ของข้อมูลในเชิงตรรกะ (เช่น 1 ต่อ Many หรือ Many to Many) และ Field ข้อมูลที่มี
  
- **ลำดับการพัฒนาและทดสอบ (Milestones & Manual Test):** แบ่งเป็น 4 ขั้นตอนเสมอ:
    1. Read Operation (การแสดงผล) โดยเน้นการ Mock ข้อมูลจริงลง Database ผ่าน mock script เพื่อทดสอบ
    2. Write Operation (การจัดการข้อมูล เพิ่ม/แก้ไข/ลบ) สามารถแบ่งเป็น Milestone ย่อยลงไปอีกตาม Module ของระบบได้ เพื่อให้ง่ายต่อการพัฒนา
    3. RBAC (การควบคุมสิทธิ์ตามบทบาท)
    *ทุกขั้นตอนต้องเขียนวิธี Manual Test ให้ผู้ใช้งานลองเล่นเองได้*
    4. รายละเอียดอื่น ๆ เช่นฟีเจอร์ Automation ต่าง ๆ และฟีเจอร์ขั้นสุดจะถูกระบุที่นี่
- **สรุปข้อตัดสินใจสำคัญ (Final Decisions):** รวบรวมเงื่อนไขที่ตกลงกันแล้วมาเขียนเป็นข้อๆ เพื่อความชัดเจน

---
### 2. กฎการจัดรูปแบบ (Formatting Rules):
- ใช้ภาษาไทยที่เข้าใจง่าย ไม่ใช้ศัพท์เทคนิคที่ซับซ้อนเกินไป
- นำเสนอ PRD โดยใช้ Bullet points และการ Bolding เพื่อแยกแยะเนื้อหาเป็นหลัก
- ใช้ Markdown (Headings, Horizontal Rules, Blockquotes) เพื่อให้โครงสร้างอ่านง่าย
- เริ่มต้นคำตอบด้วย ``` และจบด้วย ``` เพื่อให้ Copy ไปใช้งานต่อได้ง่าย
  

รายละเอียด Application
[รายละเอียด Application]

เมื่อได้ข้อความที่ AI เรียบเรียงแล้ว ให้นำเนื้อหาทั้งหมดไปบันทึกในไฟล์ชื่อ PRD.md ไฟล์นี้จะเปรียบเสมือนคู่มือหลักที่ใช้แนบไปกับทุกคำสั่งเมื่อต้องให้ AI เขียนโค้ด

(ส่วนเสริม) ขั้นตอนที่ 3: ลองให้ AI Agent สร้าง Application ทดลองตามโจทย์

เมื่อมี PRD ที่ชัดเจน เราสามารถสั่งงานให้ AI ลองสร้าง Web App อย่างง่ายขึ้นมาได้ ในตัวอย่างนี้ใช้ Claude ที่มีฟีเจอร์ Artifact แต่ใน Product อื่นก็มีเช่น ChatGPT Canvas ของ ChatGPT หรือ Gemini Canvas ของ Gemini เพื่อสร้างตัวอย่าง Application ได้เช่นกัน

Prompt สำหรับให้ AI ช่วยสร้างตัวอย่าง Application:

จาก PRD ที่กำหนดให้ ลองสร้างหน้า Frontend ที่มีฐานข้อมูลเป็น Local storage อย่างง่ายเพื่อทดสอบ Concept นี้ ขอเป็นเวอร์ชั่นง่ายที่สุดไม่ต้องสวย แต่ควรทำงานได้จริง เพิ่ม ลบ แก้ไข พร้อมตัวอย่างข้อมูล โดยยังไม่ต้องทำระบบ Access control

Avoid this error
- Blocked form submission to '' because the form's frame is sandboxed and the 'allow-forms' permission is not set.

รายละเอียด PRD
[รายละเอียด PRD]

ตัวอย่างการสร้าง PRD ฉบับเต็ม

ตัวอย่างการพัฒนา PRD เพื่อใช้สร้าง Application ด้วย Vibe coding โดยยกตัวอย่างเป็น Feature Voting Application

Idea เริ่มต้น

Idea เริ่มต้นที่ผู้ใช้กำหนดคร่าว ๆ อาจจะยังมีข้อมูลที่ไม่สมบูรณ์

## **Application Feature Voting**

ระบบเปิดโอกาสให้ผู้ใช้งานเข้ามาโหวตฟีเจอร์ที่ต้องการ โดยผู้ใช้งานทุกคนสามารถสร้าง Post Feature ได้หลายอัน, 1 Feature มีได้แค่ 1 หมวดหมู่หลัก และมีคน Vote Feature ได้หลายอัน

### **รายละเอียด Post Feature**
ใน 1 Post Feature จะประกอบไปด้วยข้อมูลดังนี้:

- **ชื่อ Feature**
- **หมวดหมู่หลัก:** 1 อย่าง
- **รายละเอียด:** เกี่ยวกับ Feature นั้นๆ
- **Impact:** (High, Medium, Low)
- **created date and time**
- **Feature Status:** (Unverified, Verified, Archive)
- **Implement Status:** (Backlog, Todo, In-progress, Done)
- **Release Version:** (unset, 1.0.0)
> **เงื่อนไข:** ในแต่ละ Post Feature จะมีผู้สร้าง Feature คนเดียว (ต้องเป็นคนที่สร้าง Post เท่านั้น)

---

### **สิทธิผู้ใช้งาน (User Roles)**

#### **1. Unverified**
ผู้ที่ลงทะเบียนใหม่แต่ยังไม่ได้รับการอนุมัติ (สิทธิ์เริ่มต้น)
- สามารถเข้าถึง Dashboard ได้
- สามารถโหวตฟีเจอร์ได้
- สามารถสร้าง และแก้ไข Feature ที่ตัวเองสร้างได้
    
- **ข้อจำกัด:**
- Feature Status จะสามารถปรับเป็น Unverified หรือ Arhive เท่านั้น
- สามารถสร้างและแก้ไข Feature ของตัวเองได้
- ไม่สามารถแก้ไข Implement Status, Feature Status และ Release Version

#### **2. User**
ผู้ใช้งานปกติ
- สามารถเข้าถึง Dashboard ได้
- สามารถโหวตฟีเจอร์ได้
- สามารถสร้างและแก้ไข Feature ของตัวเองได้
- Feature Status จะเป็น Verified หรือ Arhive เท่านั้น
- ไม่สามารถแก้ไข Implement Status, Feature Status และ Release Version

#### **3. Admin**
ผู้ดูแลระบบ
- มีสิทธิ์เหมือน User ทุกประการ
- มีความสามารถจัดการผู้ใช้งานได้
- สามารถเพิ่ม หรือแก้ไข Feature แต่ละอันได้อย่างอิสระ โดยเป็น Role เดียวที่สามารถเพิ่มหรือแก้ไข Release Version,Implement Status, Feature Status ได้

ตัวอย่าง PRD ฉบับเต็ม

PRD ที่ถูกปรับปรุงฉบับสมบูรณ์

# Product Requirement Document (PRD): Feature Voting Application

Feature Voting เป็นระบบที่เปิดโอกาสให้ผู้ใช้งานเข้ามาโหวตฟีเจอร์ใน VibeKit ที่ต้องการ โดยผู้ใช้งานทุกคนสามารถสร้าง Post Feature ได้หลายอัน, 1 Feature มีได้แค่ 1 หมวดหมู่หลัก และมีคน Vote Feature ได้หลายอัน

## 1. บทบาทผู้ใช้งาน (User Roles)
ระบบแบ่งสิทธิ์การใช้งานออกเป็น 3 ระดับ เพื่อควบคุมความปลอดภัยและความถูกต้องของข้อมูลดังนี้:

### **1.1 Unverified (ผู้ใช้งานใหม่)**
คือผู้ใช้งานที่เพิ่งสมัครสมาชิกเข้ามาและยังไม่ผ่านการตรวจสอบ
* **สิ่งที่ทำได้:**
    * เข้าดู Dashboard รายการฟีเจอร์ทั้งหมดได้
    * กดโหวตฟีเจอร์ที่สนใจได้
    * **สร้างฟีเจอร์ใหม่:** สถานะเริ่มต้นจะเป็น `Unverified` เสมอ
    * **แก้ไขฟีเจอร์ของตัวเอง:** สามารถเปลี่ยนสถานะได้แค่ `Unverified` หรือ `Archive` (ปิดการใช้งาน)
* **ข้อจำกัด:**
    * ไม่สามารถเปลี่ยนสถานะเป็น `Verified` ได้
    * ห้ามแก้ไขข้อมูลเชิงลึก (Implement Status, Release Version)

### **1.2 User (ผู้ใช้งานทั่วไป)**
คือผู้ใช้งานที่ผ่านการยืนยันตัวตนแล้ว (Trusted User)
* **สิ่งที่ทำได้:**
    * สิทธิ์พื้นฐานเหมือน Unverified ทุกประการ
    * **สร้างฟีเจอร์ใหม่:** สถานะเริ่มต้นจะเป็น `Verified` ทันที (ระบบเชื่อถือข้อมูล)
    * **แก้ไขฟีเจอร์ของตัวเอง:** สามารถเปลี่ยนสถานะได้ระหว่าง `Verified` หรือ `Archive`
* **ข้อจำกัด:**
    * ห้ามแก้ไขข้อมูลเชิงลึก (Implement Status, Release Version)

### **1.3 Admin (ผู้ดูแลระบบ)**
คือผู้มีอำนาจตัดสินใจทิศทางของ Product
* **สิ่งที่ทำได้:**
    * ทำได้ทุกอย่างเหมือน User
    * จัดการบัญชีผู้ใช้งานคนอื่นได้
    * **สิทธิ์พิเศษ (Super Power):** เป็นคนเดียวที่สามารถแก้ไข `Implement Status` (สถานะการพัฒนา) และ `Release Version` (เวอร์ชันที่ปล่อย) รวมถึงเปลี่ยน `Feature Status` ได้อย่างอิสระเพื่อคัดกรองคุณภาพ

---

## 2. ความต้องการของระบบ (Requirements)
เขียนในรูปแบบ "Given (สถานการณ์)... When (เมื่อทำอะไร)... Then (จะเกิดผลลัพธ์อะไร)..."

* **REQ-01 การแสดงผล (Dashboard Viewing)**
    * **Given:** ผู้ใช้งานเข้ามาที่หน้าแรก (Dashboard)
    * **When:** ไม่มีการกระทำใดๆ (Load หน้าเว็บ)
    * **Then:** ระบบต้องแสดงรายการ "Feature Post" ทั้งหมด โดยเรียงลำดับตามจำนวน Vote หรือ วันที่ล่าสุด และแสดงสถานะปัจจุบันให้ชัดเจน

* **REQ-02 การเสนอไอเดีย (Create Feature)**
    * **Given:** ผู้ใช้งาน (Unverified หรือ User) ต้องการเสนอไอเดียใหม่
    * **When:** กรอกข้อมูลครบถ้วนและกด "สร้าง Post"
    * **Then:** ระบบบันทึกข้อมูล โดยกำหนด "ผู้สร้าง" เป็น User คนนั้น และกำหนดค่าเริ่มต้นของสถานะการพัฒนา (Implement Status) เป็น `Backlog` เสมอ

* **REQ-03 การโหวต (Voting)**
    * **Given:** ผู้ใช้งานเจอ Feature ที่ถูกใจ
    * **When:** กดปุ่ม "Vote" ที่ Feature นั้น
    * **Then:** ระบบจะเพิ่มคะแนนโหวตให้ Feature นั้น (และควรป้องกันไม่ให้ User คนเดิมกดซ้ำใน Feature เดิม)

* **REQ-04 การอัปเดตสถานะโดย Admin (Admin Update)**
    * **Given:** ทีมพัฒนาทำ Feature นั้นเสร็จแล้ว
    * **When:** Admin เข้าไปแก้ไข Post Feature นั้นและเปลี่ยน Implement Status เป็น `Done`
    * **Then:** หน้า Dashboard ต้องแสดงสถานะใหม่ เพื่อให้ผู้ใช้รู้ว่าฟีเจอร์นี้ทำเสร็จแล้ว

---

## 3. โครงสร้างข้อมูลและกรณีใช้งาน (Data Schema & Use Case)

### **ความสัมพันธ์ของข้อมูล (Relationships)**
เพื่อให้เห็นภาพว่าข้อมูลเชื่อมโยงกันอย่างไร:
1.  **User 1 คน : สร้างได้ Many Features** (1-to-Many)
2.  **User 1 คน : โหวตได้ Many Features** (Many-to-Many) *แต่ 1 Feature โหวตได้แค่ 1 ครั้งต่อคน*
3. ** Feature 1 อย่าง** มีได้แค่ หมวดหมู่หลักอันเดียว

### **รายละเอียดข้อมูล (Data Fields)**

| Field Name | Data Type | รายละเอียด |
| :--- | :--- | :--- |
| **Title** | Text | ชื่อของ Feature |
| **Category** | Select | หมวดหมู่ (เลือกได้ 1 อย่าง) |
| **Description** | Text Area | รายละเอียดความเป็นมา |
| **Impact** | Select | ระดับความสำคัญ (High, Medium, Low) |
| **Created Date** | DateTime | วันเวลาที่สร้าง (ระบบ Auto) |
| **Created By** | Relation | เชื่อมโยงกับ ID ของผู้สร้าง |
| **Feature Status** | Select | สถานะความน่าเชื่อถือ (Unverified, Verified, Archive) |
| **Implement Status** | Select | สถานะการพัฒนา (Backlog, Todo, In-progress, Done) |
| **Release Version** | Text | เลขเวอร์ชันที่ปล่อย (เช่น 1.0.0) หรือ unset |

---

## 4. ลำดับการพัฒนาและทดสอบ (Milestones & Manual Test)

### **Milestone 1: Read Operation (การแสดงผล)**
เน้นให้หน้าบ้านแสดงข้อมูลได้ถูกต้อง โดยยังไม่ต้องทำระบบ Login หรือ Form สร้างข้อมูล
* **Dev Task:** สร้างตารางใน Database และหน้า Dashboard
* **Seeding Data:** ทีมงานจะทำการ "ยัดข้อมูลจำลอง (Mock Data)" ลงใน Database โดยตรง ประกอบด้วย:
    * User จำลอง 3 คน (A, B, C)
    * Feature Post จำลอง 5 อัน (ที่มีสถานะคละกัน เช่น Done, Backlog)
* **Manual Test (วิธีทดสอบ):**
    1.  เปิดหน้าเว็บขึ้นมา
    2.  ต้องเห็นรายการ Feature ทั้ง 5 อัน
    3.  ต้องเห็นรายละเอียดครบ (ชื่อ, หมวดหมู่, สถานะ)

### **Milestone 2: Write Operation (การจัดการข้อมูล)**
เน้นให้ผู้ใช้งานสร้างข้อมูลได้จริง
* **Dev Task:** สร้างฟอร์ม "Create Feature" และปุ่ม "Edit"
* **Manual Test (วิธีทดสอบ):**
    1.  กดปุ่ม "สร้าง Feature ใหม่"
    2.  กรอกชื่อ, รายละเอียด, เลือก Impact แล้วกดบันทึก
    3.  กลับมาดูหน้า Dashboard รายการใหม่ต้องโผล่ขึ้นมา
    4.  ลองกดแก้ไข Feature เดิม เปลี่ยนชื่อ แล้วกดบันทึก -> ชื่อต้องเปลี่ยนตาม

### **Milestone 3: RBAC (ระบบจัดการสิทธิ์)**
เน้นการจำกัดสิทธิ์ตาม Role (Unverified, User, Admin)
* **Dev Task:** เชื่อมต่อระบบ Login และเขียนเงื่อนไขปิด/เปิด Field ตาม Role
* **Manual Test (วิธีทดสอบ):**
    1.  **Login เป็น Unverified:** ลองสร้าง Feature -> ต้องเห็นสถานะเป็น `Unverified` และ **ต้องไม่เห็น** ช่องแก้ Release Version
    2.  **Login เป็น Admin:** เข้าไปแก้ Feature ของคนอื่น -> ลองเปลี่ยน Implement Status เป็น `Done` และใส่ Version `1.0.0` -> กดบันทึกต้องทำได้สำเร็จ

### **Milestone 4: Automation & Final Features**
การทำงานขั้นสูงและระบบอัตโนมัติ
* **Details:**
    * ระบบนับคะแนนโหวตแบบ Real-time (หรือแสดงผลเมื่อ Refresh)
    * **Automation:** เมื่อ Admin เปลี่ยน Implement Status เป็น `Done` ระบบอาจจะ Auto-Archive ฟีเจอร์ที่ซ้ำกัน (Optional ในอนาคต)
    * การ Filter หรือ Search หา Feature บน Dashboard
* **Manual Test (วิธีทดสอบ):**
    1.  ลองกดโหวต แล้วดูว่าตัวเลขคะแนนขึ้นหรือไม่
    2.  ลองค้นหาชื่อ Feature ในช่อง Search

---

## 5. สรุปข้อตัดสินใจสำคัญ (Final Decisions)
เพื่อให้ทีมงานเข้าใจตรงกันและไม่สับสนหน้างาน:

1.  **เจ้าของ Post เท่านั้น** ที่มีสิทธิ์แก้ไขเนื้อหา (Title, Description) ของตัวเอง (Admin ก็แก้ได้ แต่ User อื่นห้ามแตะ)
2.  **Implement Status (สถานะการพัฒนา)** และ **Release Version** เป็นเขตหวงห้ามสำหรับ User ทั่วไป มีเพียง Admin เท่านั้นที่แตะต้องได้
3.  **ค่าเริ่มต้น (Default Value):**
    * Implement Status เริ่มต้นที่ `Backlog` เสมอ
    * Release Version เริ่มต้นที่ `unset` (ว่าง)
4.  **ความแตกต่างของ Role:** หัวใจสำคัญอยู่ที่ `Feature Status` (Unverified vs User) และ `Admin Powers` ในการจัดการสถานะงานพัฒนา

ตัวอย่าง Working Prototype

ตัวอย่าง Application ที่จำลองสร้างจากโครงสร้างข้อมูลที่กำหนดให้

สร้าง PRD เสร็จแล้วนำไปใช้ใน Vibe Coding อย่างไร

หลังจากที่สร้าง PRD เสร็จเรียบร้อยแล้ว เราจะให้ AI Agent ทำงาน โดยหลักการคือทำทีละ Milestone และบันทึกสิ่งที่ทำลงไปเป็น Change Log เพื่อให้ง่ายต่อการควบคุม โดยหากระบบทำงานไม่ตรงตามความต้องการก็ปรับแก้จนพอใจแล้วค่อยไปทำ Milestone ต่อไป โดยเราสามารถมาอัปเดตรายละเอียดเพิ่มเติมในภายหลังได้

สำหรับ VibeKit ให้สร้างไฟล์ชื่อ addons.md และใส่ข้อมูล PRD ทั้งหมดลงในนั้น

Prompt สำหรับให้ AI Agent ทำงานทีละ Milestone:

สร้างระบบตาม PRD (addons.md) โดยทำใน Milestone x เท่านั้น โดยทุกครั้งที่มีการสร้าง Page ต้องสร้าง Link ให้กดได้จากหน้า Page หลัก

อ่าน docs และ codebase ก่อนเริ่มทำ
เริ่มจากวางแผนก่อน อย่าเพิ่งเขียนโค้ด และให้ถามคำถามกลับมา หากมีอะไรที่ต้องต้องตัดสินใจ
เมื่อทำเสร็จแล้ว ให้บันทึกสิ่งที่ทำลงใน PRD

FAQ: คำถามที่พบบ่อยเกี่ยวกับการทำ PRD