ทำไม Planning Mode จึงสำคัญเมื่อไอเดียยังไม่ชัด\n\nไอเดียคลุมเครือพอสำหรับการฝันกลางวัน แต่ไม่ดีสำหรับการสร้าง\n\nเมื่อคุณขอให้ผู้สร้างด้วย AI ทำ “แอปสำหรับติดตามนิสัย” โดยไม่มีรายละเอียดเพิ่มเติม มันต้องเดาว่าคุณหมายถึงอะไร การเดาพวกนั้นเปลี่ยนไปตามแต่ละ prompt ผลคือแอปเปลี่ยนตามไปด้วย คุณจะได้หน้าจอที่ไม่สอดคล้อง ข้อมูลถูกเปลี่ยนชื่อกลางคัน และฟีเจอร์ที่โผล่หายแล้วโผล่อีกในรูปแบบต่างกัน\n\nความไม่สอดคล้องมักปรากฏในไม่กี่จุด:\n\n- สมมติฐานต่างกันเกี่ยวกับผู้ใช้ (ผู้ใช้เดี่ยว vs ทีม)\n- เวิร์กโฟลว์ขัดแย้งกัน (บันทึกก่อนแล้วสร้าง vs สร้างก่อนแล้วบันทึก)\n- การเปลี่ยนชื่อข้อมูล (habit vs routine vs goal)\n- กรณีขอบที่ขาด (จะเกิดอะไรขึ้นถ้าผู้ใช้ลบบางอย่าง)\n\n“Planning Mode” คือการหยุดสั้นๆ ก่อนการสร้าง คุณจดบันทึกการตัดสินใจที่ AI จะต้องคิดขึ้นเอง จุดประสงค์คือความสอดคล้อง: ชุดการตัดสินใจเดียวที่ UI, backend และฐานข้อมูลสามารถปฏิบัติตามได้\n\nเป้าหมายไม่ใช่ความสมบูรณ์แบบ แต่วิธีสร้างที่คุณสามารถปรับปรุงได้โดยไม่ต้องแพตช์จากการคาดเดาอยู่เรื่อยๆ ถ้าคุณเปลี่ยนใจทีหลังก็อัปเดตสเปคแค่หน้าเล็กๆ แล้วสร้างใหม่ด้วยตรรกะเดิม\n\nนั่นแหละเหตุผลที่เทมเพลตสเปคหน้าเดียวมีความหมาย มันไม่ใช่ PRD ยาวๆ และไม่ใช่หลายสัปดาห์ของไดอะแกรม มันคือหน้าเดียวที่ตอบคำถามสี่ข้อ: ใครคือผู้ใช้, พวกเขาต้องการทำอะไรให้สำเร็จ, ข้อมูลอะไรบ้างที่มี (ในภาษาง่ายๆ), และกรณีขอบหรือสิ่งที่ไม่เป็นเป้าหมายอะไรที่ช่วยกันไม่ให้เวอร์ชันแรกพัง\n\nตัวอย่าง: “แอปจอง” ชัดขึ้นมากเมื่อคุณตัดสินใจว่ามันสำหรับเจ้าของร้านเดียวหรือเป็นตลาด และว่าลูกค้าสามารถเปลี่ยนตาราง ยกเลิก หรือละทิ้งการมาได้หรือไม่\n\n## เทมเพลตสเปคหน้าเดียว อธิบายในหนึ่งนาที\n\nเทมเพลตสเปคหน้าเดียวคือบันทึกสั้นๆ ที่เปลี่ยนไอเดียคลุมเครือให้เป็นคำสั่งชัดเจน คุณไม่ได้ “ออกแบบทั้งผลิตภัณฑ์” แต่ให้ผู้สร้าง AI โครงสร้างพอที่เลือกแบบเดิมทุกครั้ง\n\nหน้าแบ่งเป็นสี่บล็อก ถ้าใส่ไม่พอในหน้าเดียว คุณมีฟีเจอร์มากเกินไปสำหรับการสร้างครั้งแรก\n\n- Users: ใครใช้ (2–3 ประเภท) และอะไรที่ทำให้พวกเขาต่างกัน\n- Jobs-to-be-done: แต่ละคนต้องการทำอะไรเป็นผลลัพธ์\n- Entities: สิ่งสำคัญที่คุณเก็บและติดตาม (คำนามข้อมูล)\n- Edge cases + non-goals: อะไรอาจพัง และอะไรที่คุณยังไม่สร้าง\n\nหน้าเดียวบังคับขอบเขตที่มีประโยชน์ มันผลักให้คุณเลือกผู้ใช้หลัก กำหนดโฟลว์ที่สำเร็จเล็กที่สุด และหลีกเลี่ยงคำสัญญาคลุมเครืออย่าง “รองรับทุกอย่าง” ขอบเขตเหล่านี้แหละที่ช่วยไม่ให้แอปที่สร้างโดย AI เปลี่ยนใจข้ามหน้าจอ\n\nรายละเอียดที่ “ดีพอ” จะเหมือนประโยคง่ายๆ ที่ทดสอบได้ หากใครสักคนอ่านและถามว่า “เรารู้ได้อย่างไรว่ามันทำงาน?” นั่นคือระดับที่เหมาะสม\n\nเกณฑ์สั้นๆ ให้มุ่งหวัง:\n\n- ผู้ใช้ใหม่สามารถทำงานหลักให้เสร็จภายใน 2 นาที\n- แต่ละงานมีจุดเริ่มและจบชัดเจน (ไม่ใช่ “จัดการของ” แบบไม่จบ)\n- แต่ละเอนทิตีมีฟิลด์ที่จำเป็นจริง 3–7 ฟิลด์\n- ระบุ 5 กรณีขอบบนสุด (ข้อมูลซ้ำ, สิทธิ์, สถานะว่าง, ล้มเหลว, ข้อมูลนำเข้าไม่ถูกต้อง)\n\nใช้ภาษาง่ายๆ เขียนบรรทัดที่คุณสามารถวางลงใน prompt ได้เลย เช่น “ผู้จัดการสามารถอนุมัติหรือปฏิเสธคำร้อง และผู้ขอจะได้รับอัปเดตสถานะ”\n\n## ทีละขั้น: เติมเทมเพลตใน 20 นาที\n\nตั้งตัวจับเวลา 20 นาทีและตั้งเป้าให้ “ชัดพอจะสร้าง” ไม่ใช่ “สมบูรณ์แบบ” จุดประสงค์คือกำจัดการคาดเดาเพื่อให้ผู้สร้าง AI เลือกแบบเดียวกันทุกครั้ง\n\nเริ่มด้วยประโยคเดียวที่ตอบ: ใครคือกลุ่มเป้าหมาย และผลลัพธ์ที่พวกเขาได้รับคืออะไร?\n\nตัวอย่าง: “แอปมือถือสำหรับเจ้าของสุนัขเพื่อติดตามการเดินและการไปหาสัตวแพทย์ในที่เดียว”\n\nถ้าพูดไม่ออกในหนึ่งประโยค ไอเดียนั้นอาจเป็นสองแอป\n\nต่อไป ตั้งชื่อประเภทผู้ใช้ 1–3 แบบเหมือนคนจริงๆ ไม่ใช่บทบาทนามธรรม “เจ้าของ” “สัตวแพทย์” และ “สมาชิกในครอบครัว” ดีกว่า “User A” สำหรับแต่ละคนเพิ่มบรรทัดสั้นๆ ว่าพวกเขาคิดถึงอะไรที่สุด\n\nแล้วเขียน 3–7 งานที่ต้องทำในรูปแบบ: “เมื่อ [สถานการณ์] ฉันต้องการ [การกระทำ] เพื่อที่ฉันจะได้ [ผลลัพธ์]” คงไว้ให้ทดสอบได้ “เมื่อฉันจบการเดิน ฉันต้องการบันทึกระยะทางและหมายเหตุ เพื่อที่ฉันจะได้เห็นรูปแบบ” ชัดกว่าคำว่า “ติดตามสุขภาพ”\n\nตอนนี้กำหนดเอนทิตีและฟิลด์สำคัญโดยไม่พูดถึงฐานข้อมูล คิดว่าเป็น “สิ่งที่แอปจำได้” สำหรับแอปสุนัข: Dog (name, age), Walk (date, duration, notes), Visit (date, clinic, cost). ถ้าฟิลด์ไม่ถูกใช้ในหน้าจอหรืองาน ให้ตัดออก\n\nจบด้วยสองบล็อกสั้นๆ: กรณีขอบและสิ่งที่ไม่เป็นเป้าหมาย กรณีขอบน่ารำคาญแต่เกิดบ่อย (“ไม่มีเน็ต” “สุนัขสองตัวชื่อเดียวกัน”) ส่วน non-goals คือสิ่งที่จะไม่สร้างตอนนี้ (“ไม่มีการชำระเงิน” “ไม่มีฟีดสังคม”)\n\nสุดท้าย แปลงแต่ละบล็อกเป็น prompt ที่ตัวสร้างทำตาม การรักษาโครงสร้างให้สม่ำเสมอ (วัตถุประสงค์, ผู้ใช้, งาน, เอนทิตี, กรณีขอบ) ช่วยให้ระบบสร้างหน้าจอ ข้อมูล และโฟลว์ที่สอดคล้องกัน\n\n## ผู้ใช้และงานที่ AI สามารถปฏิบัติตามได้จริง\n\nถ้าสเปคของคุณเขียนว่า “สำหรับทุกคน” ผู้สร้าง AI ต้องเดาว่าจะสร้างอะไรก่อน ในเทมเพลตสเปคหน้าเดียว ให้กำหนดผู้ใช้ตามเจตนา (สิ่งที่พวกเขามาทำ) ไม่ใช่ประชากรศาสตร์ เจตนาจะนำไปสู่การตัดสินใจที่ชัดเจนเกี่ยวกับหน้าจอ ข้อมูล และสิทธิ์\n\nตั้งชื่อผู้ใช้ 2–4 ประเภท โดยแต่ละประเภทมีเป้าหมายหลักหนึ่งอย่าง ตัวอย่างที่ดีเช่น “ลูกค้าที่สั่งสินค้า” “สมาชิกทีมที่จัดการคำสั่ง” และ “ผู้จัดการที่ทบทวนผลการทำงาน” ตัวอย่างที่คลุมเครือเช่น “18–35”, “ผู้เชี่ยวชาญที่ยุ่ง” หรือ “admins” (ถ้าคุณไม่บอกว่าพวกเขาดูแลอะไร) จะไม่ช่วย\n\n### เขียน JTBD ในรูปแบบเคร่งครัด\n\nใช้โครงสร้างประโยคเดียวกันทุกครั้ง: “เมื่อ..., ฉันต้องการ..., เพื่อที่ฉันจะได้...”. วิธีนี้ช่วยให้แอปมุ่งที่ผลลัพธ์ และให้ข้อกำหนดที่ตรวจสอบได้แก่ผู้สร้าง AI\n\nนี่คือตัวอย่าง JTBD ที่เป็นจริงและมีคำว่า “เสร็จ” ชัดเจน:\n\n- เมื่อฉันจบการโทรกับลูกค้า ฉันต้องการบันทึกขั้นตอนถัดไปในที่เดียว เพื่อที่ฉันจะได้ติดตามตรงเวลา เสร็จเมื่อ: บันทึกถูกบันทึก, กำหนดวันครบ, ตั้งเตือนแล้ว\n- เมื่อคำขอใหม่มาถึง ฉันต้องการอนุมัติหรือปฏิเสธอย่างรวดเร็ว เพื่อให้การทำงานเดินต่อ เสร็จเมื่อ: บันทึกการตัดสินใจ, ผู้ขอได้รับแจ้ง, สถานะอัปเดต\n- เมื่อฉันใช้งานบนมือถือ ฉันต้องการเห็นเฉพาะงานของวันนี้ เพื่อที่ฉันจะได้ทำโดยไม่ต้องค้นหา เสร็จเมื่อ: งานถูกกรองเป็นวันนี้, แตะครั้งเดียวทำเครื่องหมายว่าสำเร็จ\n- เมื่อฉันทำผิด ฉันต้องการเลิกการเปลี่ยนแปลงล่าสุด เพื่อกู้คืนโดยไม่ต้องติดต่อสนับสนุน เสร็จเมื่อ: สถานะก่อนหน้าได้รับการกู้คืน, บันทึก audit ถูกสร้าง\n\nเกณฑ์ความสำเร็จสำคัญเพราะมันกำจัดความกำกวมแบบ “ดูดี” มันบอกตัวสร้างว่า UI ต้องอนุญาตอะไรและ backend ต้องเก็บอะไรไว้\n\n### เพิ่มสิทธิ์ในระดับสูง\n\nไม่ต้องเขียนแผนความปลอดภัยเต็มรูปแบบ แค่บอกว่าใครทำอะไรได้บ้าง เป็นภาษาธรรมดา\n\nตัวอย่าง: “สมาชิกสามารถสร้างและแก้ไขรายการของตัวเอง ผู้จัดการสามารถแก้ไขรายการใดก็ได้และเปลี่ยนสถานะ เจ้าของจัดการผู้ใช้และการเรียกเก็บเงินได้”\n\nถ้าคุณใช้ขั้นตอนการวางแผนในเครื่องมือเช่น Koder.ai บทบาทผู้ใช้ เหล่า JTBD และสิทธิ์เหล่านี้จะกลายเป็นอินพุตที่เชื่อถือได้ และป้องกันไม่ให้ AI สร้างบทบาทเพิ่มหรือผสมความรับผิดชอบข้ามหน้าจอ\n\n## เอนทิตี: กำหนดข้อมูลโดยไม่ลงเทคนิค\n\nเอนทิตีคือ “สิ่ง” ที่แอปเก็บไว้ ถ้าคุณตั้งชื่อชัดเจน ผู้สร้าง AI จะสามารถสร้างหน้าจอ ฟอร์ม และฐานข้อมูลที่ตรงกันได้ นี่คือสิ่งที่ป้องกันฟิลด์ไม่ตรงกันและฟีเจอร์เพิ่มโดยไม่มีเหตุผล\n\nเริ่มจากการขึ้นรายการคำนามหลัก ถ้าแอปสำหรับ “จัดการโปรเจกต์” คำนามอาจเป็น Project, Task และ Comment ถ้าเป็น “จองรับตัดผม” ก็อาจมี Booking, Service, Customer, และ Staff\n\n### เลือก 5–10 ฟิลด์ที่ผู้คนพูดถึงจริงๆ\n\nสำหรับแต่ละเอนทิตี ให้เขียนฟิลด์เป็นคำพูดที่คนทั่วไปเข้าใจ ไม่ใช่คำฐานข้อมูล จินตนาการว่าคนจะพิมพ์อะไรในฟอร์ม\n\n- Task: title, description, status, due date, priority, assigned to, created by\n- Project: name, goal, start date, end date, owner, archived (yes/no)\n- Invoice: invoice number, client name, amount, currency, due date, paid (yes/no)\n\nถ้าคุณอธิบายฟิลด์ไม่ได้ในหนึ่งประโยค นั่นอาจละเอียดเกินไปสำหรับเวอร์ชันแรก\n\n### ความสัมพันธ์และกฎเป็นภาษาง่ายๆ\n\nอธิบายการเชื่อมต่อของเอนทิตีด้วยประโยคง่ายๆ:\n\n“ผู้ใช้หนึ่งคนมีโปรเจกต์หลายโปรเจกต์” “แต่ละงานเป็นของโปรเจกต์หนึ่ง” “ความคิดเห็นเป็นของงานและมีผู้เขียนหนึ่งคน”\n\nนี้ให้โครงสร้างเพียงพอให้ตัวสร้างสร้างรายการ หน้ารายละเอียด และตัวกรองที่สอดคล้องกัน\n\nเพิ่มกฎข้อมูลบางข้อที่ป้องกันพฤติกรรมยุ่งเหยิง:\n\n- บังคับ: “ชื่อเรื่องงานต้องใส่”\n- ไม่ซ้ำ: “หมายเลขใบแจ้งหนี้ต้องไม่ซ้ำ”\n- จำกัด: “คำอธิบายสูงสุด 500 ตัวอักษร”\n- ค่าเริ่มต้น: “งานใหม่เริ่มต้นด้วยสถานะ = Open”\n\nสุดท้าย ตัดขอบเขตโดยระบุสิ่งที่คุณจะยังไม่เก็บ ตัวอย่าง: “ไม่มีแนบไฟล์ใน v1” หรือ “ยังไม่ติดตามตารางเวลาพนักงาน แค่การจอง” การยกเว้นเหล่านี้สำคัญเพราะหยุดไม่ให้แอปเติบโตผิดทาง\n\n## หน้าจอและโฟลว์: ทำให้เรียบง่ายและคาดเดาได้\n\nเทมเพลตสเปคหน้าเดียวทำงานได้ดีที่สุดเมื่อเวอร์ชันแรกมีชุดหน้าจอเล็กและคงที่ ถ้าคุณพยายามออกแบบทุกหน้าจอที่แอปอาจต้องการในอนาคต ผู้สร้าง AI จะเดาตลอดเวลาและ UI จะเบี่ยงจากกันเมื่อสร้างใหม่\n\nเริ่มจากตั้งชื่อหน้าจอขั้นต่ำที่ให้ใครสักคนทำงานหลักให้เสร็จ สำหรับ MVP ส่วนใหญ่ 3–6 หน้าจอก็มากพอ:\n\n- เข้าสู่ระบบ\n- รายการ (รายการหลักของคุณ)\n- รายละเอียด (ดูรายการหนึ่ง)\n- สร้าง/แก้ไข (ฟอร์ม)\n- การตั้งค่า (ไม่บังคับ)\n\nแล้วเขียนเส้นทางในสภาพแวดล้อมที่ปกติเป็นเรื่องสั้นจากเริ่มถึงจบ\n\nตัวอย่าง: “ผู้ใช้ลงชื่อเข้าใช้, ไปที่รายการ, ค้นหา, เปิดรายการ, แก้ไขฟิลด์หนึ่ง, บันทึก, แล้วกลับไปที่รายการ”\n\nสำหรับแต่ละหน้าจอ ให้จดการกระทำสำคัญเป็นคำพูดง่ายๆ หลีกเลี่ยงหน้าจอที่ “ทำได้ทุกอย่าง” เลือก 2–4 การกระทำที่สำคัญที่สุด เช่น สร้าง แก้ไข ค้นหา ส่งออก หรือเก็บถาวร\n\nตัดสินใจด้วยว่าต้องทำอะไรให้เร็ว และอะไรพอใช้ได้ “เร็ว” มักหมายถึงรายการเปิดเร็ว ค้นหาตอบสนองเร็ว และการบันทึกรู้สึกทันที “พอใช้ได้” อาจเป็นการส่งออกที่ใช้เวลาสองสามวินาที, การวิเคราะห์เบื้องต้น, หรือการตั้งค่าที่เรียบง่าย\n\nสุดท้าย จับบทบาทและการเข้าถึงในหนึ่งบรรทัดต่อบทบาท:\n\n- Viewer: ดูและค้นหาได้\n- Editor: สร้างและแก้ไขได้\n- Admin (ถ้าจำเป็น): จัดการผู้ใช้และลบได้\n\nนี้ทำให้หน้าจอคาดเดาได้ ป้องกันปัญหาสิทธิ์ และลดการแก้ซ้ำภายหลัง\n\n## กรณีขอบและสิ่งที่ไม่เป็นเป้าหมายที่ป้องกันการแก้ใหม่\n\nงานแก้ใหม่ส่วนใหญ่เกิดจากเหตุผลเดียว: แอปทำงานได้ในเส้นทางปกติ แต่พังเมื่อเจอสถานการณ์จริง\n\nเทมเพลตสเปคหน้าเดียวที่ดีเผื่อพื้นที่สำหรับกรณีขอบและ non-goals พื้นที่เล็กๆ นั้นประหยัดเวลาได้หลายชั่วโมง\n\nเริ่มจากแต่ละงานและถาม: อะไรอาจพัง? เขียนเป็นภาษาง่ายๆ ไม่ใช่เทคนิค คุณกำลังลบความกำกวมเพื่อให้ตัวสร้างตัดสินใจแบบเดียวกันทุกครั้ง\n\nกรณีขอบที่ควรเขียนลงบ่อยๆ:\n\n- ข้อมูลหายหรือไม่ครบ (ฟิลด์ว่าง, ที่อยู่ไม่ทราบ, ไม่มีรูปโปรไฟล์)\n- ข้อมูลซ้ำ (ผู้ใช้เดียวสมัครสองครั้ง, รายการเดียวถูกเพิ่มสองครั้ง)\n- ความขัดแย้ง (สองคนแก้ไขระเบียนเดียวกันพร้อมกัน, สถานะเปลี่ยนขณะดู)\n- ข้อจำกัดและหมดเวลา (การเชื่อมต่อช้า, อัปโหลดล้มเหลว, คำขอใช้เวลานาน)\n- ปัญหาสิทธิ์ (ผู้ใช้พยายามดูหรือแก้ไขสิ่งที่เขาไม่ควร)\n\nแล้วกำหนดการตอบสนองเป็นข้อๆ ระบุชัดเจน: “บล็อกการกระทำแล้วแสดงข้อความชัดเจน”, “อนุญาตบันทึกเป็นร่าง”, หรือ “ลองใหม่หนึ่งครั้ง แล้วแสดงปุ่มให้ลองอีกครั้ง” กฎพวกนี้แปลตรงเป็นคำสั่งที่สอดคล้องได้\n\nเพิ่มความคาดหวังด้านความเป็นส่วนตัวและความปลอดภัยในหนึ่งหรือสองบรรทัด เช่น: “เก็บข้อมูลขั้นต่ำที่จำเป็น”, “ผู้ใช้ลบบัญชีและข้อมูลส่วนบุคคลทั้งหมดได้”, “ซ่อนรายการส่วนตัวโดยค่าเริ่มต้น” ถ้าแอปเกี่ยวข้องกับเนื้อหาที่ผู้ใช้สร้าง ให้ระบุว่าจะจัดการกับรายงานและสแปมอย่างไร แม้จะง่ายใน v1 ก็ตาม\n\nสุดท้าย เขียน non-goals เพื่อหยุดการพองตัวของสเปค จงเลือกฟีเจอร์ล่อใจที่ใหญ่ที่สุดที่คุณจะไม่ทำในตอนนี้\n\nตัวอย่าง non-goals ชัดเจน:\n\n- ไม่มีการชำระเงินหรือสมาชิกใน v1\n- ไม่มีการล็อกอินผ่านโซเชียล (ใช้แค่เมลในตอนนี้)\n- ไม่มีแดชบอร์ดแอดมินเกินรายการพื้นฐานและลบ\n- ไม่มีโหมดออฟไลน์\n\nตัวอย่างรวดเร็ว: ถ้างานคือ “สร้างกิจกรรม” ให้กำหนดว่าจะเกิดอะไรเมื่อวันที่เป็นอดีต ชื่อเรื่องว่าง หรือกิจกรรมเดียวกันถูกสร้างซ้ำ ความชัดเจนนั้นป้องกันการแก้ใหม่ครั้งต่อไป\n\n## แปลงสเปคหน้าเดียวเป็น prompt ที่ผู้สร้าง AI รันได้\n\nวิธีเร็วที่สุดในการได้ผลลัพธ์สอดคล้องคือการแปลงแต่ละบล็อกของสเปคหน้าเดียวเป็น prompt สั้นๆ ตรงไปตรงมาที่ตัวสร้างทำตาม จินตนาการว่าคุณให้การ์ดชุดหนึ่งมันทำตามทีละใบ แทนที่จะให้คำขอใหญ่ๆ และคลุมเครือใบเดียว\n\nแปลงแต่ละบล็อก (Users, Jobs, Entities, Screens, Edge cases, Non-goals) เป็นคำสั่งหนึ่งข้อที่มีคำนามและกริยาให้ชัด หลีกเลี่ยงความเห็นเช่น “ทำให้เรียบร้อย” เว้นแต่คุณจะบอกด้วยว่า “เรียบร้อย” หมายถึงอะไร\n\n### รูปแบบ prompt ง่ายๆ ที่ได้ผล\n\nใช้วงจรสองขั้นตอน: สร้างก่อน แล้วตรวจสอบเทียบกับสเปค\n\n1) สร้าง: “Create the data model and API for these Entities: [paste Entities]. Support these roles: [paste Users].”\n2) สร้าง: “Create screens and flows exactly for: [paste Screens/Flows].”\n3) ตรวจสอบ: “Now check your work against this spec. List any mismatches and fix them: [paste full one-page spec].”\n\nเพิ่มนิยามสั้นๆ ของคำว่าเสร็จเพื่อให้ตัวสร้างรู้ว่าเมื่อไหร่จะหยุด เก็บให้วัดผลได้:\n\n- บทบาททั้งหมดที่ระบุสามารถทำงานทุก JTBD ให้เสร็จจบได้\n- แต่ละเอนทิตีมีการสร้าง ดู แก้ไข และเก็บถาวร (ถ้าสเปคกำหนด)\n- หน้าจอตรงกับโฟลว์ที่ตั้งชื่อไว้ พร้อมป้ายฟิลด์ที่สอดคล้อง\n- กรณีขอบถูกจัดการด้วยข้อความชัดเจน (ไม่มีความล้มเหลวเงียบ)\n\nเพิ่มข้อจำกัดเฉพาะเมื่อจำเป็นจริงๆ: อุปกรณ์ที่ต้องการ (mobile-first), การพิสูจน์ตัวตนที่ต้องมี (การกระทำเฉพาะผู้ดูแล), หรือสแต็กที่ต้องการ (เช่น frontend React, backend Go, PostgreSQL) ถ้าแพลตฟอร์มคุณคาดหวังแบบนั้น\n\n### ขอเปลี่ยนโดยไม่ทำลายแผน\n\nเมื่อคุณต้องการแก้ ให้อ้างบล็อกในสเปค ไม่ใช่โค้ด\n\nตัวอย่าง: “อัปเดตบล็อก Entities: เพิ่ม ‘Subscription’ พร้อมฟิลด์ X และ Y แล้ว regenerate เฉพาะ API และหน้าจอที่ได้รับผลกระทบ และรันการตรวจสอบอีกครั้ง”\n\nวิธีนี้ทำให้แผนคงที่ในขณะที่ยังให้คุณวนรุ่นได้อย่างปลอดภัย\n\n## ตัวอย่างที่เป็นจริง: จากไอเดียสู่ prompt ใน Planning Mode\n\nสมมติว่าคุณต้องการตัวติดตามการเตือนนัดหมายง่ายๆ สำหรับซาลอนขนาดเล็ก เป้าหมายไม่ใช่ระบบจองเต็มรูปแบบ แต่เป็นที่เก็บน้ำหนักเบาสำหรับบันทึกนัดและส่งเตือน\n\nนี่คือตัวอย่างเมื่อเทมเพลตสเปคหน้าเดียวถูกเติมข้อมูลแล้ว\n\ntext\nAPP: Appointment Reminder Tracker\nGOAL: Track appointments and send reminders. No payments, no online booking.\n\nUSERS\n1) Owner/Staff: creates and manages appointments, wants fewer no-shows.\n2) Client: receives reminders, wants an easy way to confirm.\n\nJOBS TO BE DONE (JTBD)\n1) As staff, I add an appointment in under 30 seconds.\n2) As staff, I see today's schedule in time order.\n3) As staff, I mark a client as confirmed or no-show.\n4) As staff, I resend a reminder when asked.\n5) As a client, I confirm from a message without creating an account.\n\nENTITIES (DATA)\n- Client: id, name, phone, email (optional), notes\n- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)\n- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)\n- StaffUser: id, name, role (owner/staff)\nRelationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.\n\nEDGE CASES (WHAT BREAKS NAIVE BUILDS)\n1) Duplicate client (same phone, different name)\n2) Overlapping appointments for the same staff\n3) Time zone changes (travel, daylight saving)\n4) Client has no email, SMS only\n5) Reminder send fails, needs retry and visible status\n6) Appointment edited after reminder scheduled\n7) Client cancels after confirmation\n8) Same-day appointment created 10 minutes before start\n9) Phone number format varies (+1, spaces, dashes)\n10) Deleting a client with future appointments\n\n\nตอนนี้แปลงเป็นชุด prompt ที่คุณสามารถวางใน Planning Mode ได้ รักษาความเข้มงวดเพื่อให้ตัวสร้างเลือกแบบเดียวกันทุกครั้ง\n\ntext\nPLANNING MODE PROMPT BUNDLE\n1) Build an MVP web app with these entities and relationships exactly as written.\n2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.\n3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.\n4) Constraints: no payments, no public booking page, no client accounts.\n5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.\n6) Output: database schema, API endpoints, and UI behavior notes per screen.\n\n\n## กับดักทั่วไปที่ทำให้แอปที่สร้างด้วย AI ไม่สอดคล้อง\n\nผลลัพธ์ยุ่งเหยิงมักเริ่มจากสเปคคลุมเครือและรายการความต้องการฟีเจอร์ ผู้สร้าง AI จะทำตามที่คุณขอ แต่มันอ่านใจคุณไม่ได้ ช่องว่างเล็กๆ กลายเป็นความต่างข้ามหน้าจอและโฟลว์\n\nกับดักเหล่านี้ทำให้ความสอดคล้องเสียบ่อยที่สุด และเทมเพลตสเปคหน้าเดียวแก้ไขได้:\n\n- ฟีเจอร์แทนงาน: “เพิ่มรายการโปรด” คือฟีเจอร์ แต่จงานคือ “บันทึกรายการเพื่อนำมาดูทีหลัง” งานรวมเจตนาและความสำเร็จ ดังนั้น AI จะวางปุ่มที่เหมาะสม รู้ว่าต้องทำอะไรหลังการบันทึก และสถานะว่างควรแสดงอย่างไร\n- เอนทิตีมากเกินไปตั้งแต่แรก: ถ้าคุณนิยามตาราง 12 ตารางตั้งแต่วันแรก ตรรกะจะกระจาย ถ้า “Project, Task, Comment, Tag, Attachment” รู้สึกมาก เริ่มแค่ “Project” และ “Task” แล้วเพิ่มทีหลังเมื่อโฟลว์แกนกลางทำงานได้\n- สิทธิ์ขาดหาย: ถ้าคุณไม่เคยบอกว่าใครแก้หรือลบได้ ตัวสร้างจะเดา เขียนกฎง่ายๆ เช่น “เฉพาะเจ้าของลบได้”, “สมาชิกสร้างและแก้ได้”, “ผู้ดูดูได้เท่านั้น” นี่ช่วยลดการเปิดเผยข้อมูลโดยไม่ตั้งใจ\n- ไม่มีเกณฑ์ความสำเร็จชัดเจน: ไม่มีคำจำกัดความของคำว่าเสร็จ คุณจะได้การวนซ้ำไม่รู้จบ เพิ่ม 2–4 ข้อการยอมรับ เช่น “ผู้ใช้สร้างงานได้ภายใน 30 วินาที” หรือ “งานแสดงถูกต้องหลังรีเฟรช”\n- กรณีขอบโดยไม่มีพฤติกรรมที่คาดหวัง: ระบุแค่ “ออฟไลน์”, “อีเมลซ้ำ”, หรือ “รายการว่าง” ยังไม่พอ สำหรับแต่ละข้อระบุว่าจะให้แอปทำอะไร ตัวอย่าง: “ถ้าอีเมลมีอยู่แล้ว ให้แสดงข้อผิดพลาดเป็นมิตรและแนะนำให้ลงชื่อเข้าใช้”\n\nถ้าคุณใช้ Planning Mode ใน Koder.ai พื้นฐานเหล่านี้สำคัญยิ่งขึ้นเพราะแผนจะกลายเป็นแหล่งสำหรับ prompt ที่ใช้ซ้ำๆ งานชัดเจน โมเดลข้อมูลเล็ก สิทธิ์ชัด และกฎความสำเร็จที่ทดสอบได้จะช่วยให้แต่ละหน้าจอใหม่สอดคล้องกับส่วนอื่นๆ\n\n## เช็คลิสต์ด่วนและขั้นตอนต่อไป\n\nก่อนสร้าง ทำการตรวจสเปคหน้าเดียวอย่างเร็ว จุดประสงค์คือกำจัดช่องว่างที่บังคับให้ AI ต้องเดา การคาดเดาเหล่านั้นกลายเป็นการแก้ใหม่\n\nเช็คลิสต์ความครบถ้วนอย่างเร็ว:\n\n- Users: แต่ละประเภทผู้ใช้มีเป้าหมายชัดและโน้ต “ใครทำอะไรได้บ้าง” (สร้าง, ดู, แก้, ลบ)\n- Jobs-to-be-done: แต่ละงานเริ่มด้วยทริกเกอร์และจบด้วยผลลัพธ์ที่ตรวจสอบได้\n- Entities: ทุกคำนามในงานได้รับรองด้วยไอเท็มข้อมูล (แม้แต่ชื่อ สถานะ และ timestamps)\n- Screens and flows: แต่ละงานแมปไปยังเส้นทางง่ายๆ (หน้าจอเริ่ม, การกระทำหลัก, การยืนยัน)\n- Edge cases: คุณเขียนอย่างน้อย 5 เรื่องที่อาจพัง (สถานะว่าง, ข้อมูลไม่ถูกต้อง, ซ้ำ, สิทธิ์, ออฟไลน์หรือเครือข่ายช้า)\n\nถ้าคุณอยากได้ไอเดียการให้คะแนนง่ายๆ ให้ให้คะแนนแต่ละด้าน 0–2:\n\n- 0: ขาดหายหรือกำกวม\n- 1: มีแต่ไม่ชัดเจน\n- 2: ชัดพอจะสร้าง\n\nตั้งเป้าอย่างน้อย 7/10 ก่อนจะสร้าง หาก Entities หรือ Edge cases ต่ำกว่า 2 ให้แก้ก่อน พวกนี้เป็นสาเหตุของการเปลี่ยนแปลงมากที่สุด\n\nหลังการสร้างครั้งแรก ทบทวนแอปเทียบกับแต่ละ JTBD และมาร์กความไม่ตรงกัน ถ่ายสแนปชอตก่อนการเปลี่ยนแปลงแต่ละครั้ง ถ้าการวนรุ่นใหม่ทำให้แย่ลง ให้ย้อนกลับและลองแก้เล็กลง\n\nถ้าคุณใช้ Koder.ai (koder.ai), Planning Mode เป็นที่ที่ใช้งานได้จริงในการเก็บสเปคหน้าเดียวนี้เป็น “แหล่งความจริง” และ regenerate เฉพาะสิ่งที่เปลี่ยนแทนการเขียนใหม่ทุกอย่างด้วยมือตลอดเวลา\n\nอัปเดตสเปคทันทีเมื่อคุณยอมรับการเปลี่ยนแปลง และเมื่อคุณปฏิเสธการเปลี่ยน ให้เขียนลงว่าทำไม เพื่อให้ prompt ครั้งต่อไปยังคงสอดคล้อง
