อย่าเปลี่ยนรูปแบบพรอมต์สำหรับการวนซ้ำเล็กๆ ที่ปลอดภัย

ทำไมการเปลี่ยนแปลงเล็กๆ มักจะทำให้ส่วนอื่นพัง\n\nการเปลี่ยนแปลงที่ “เล็ก” มักไม่คงอยู่เป็นเรื่องเล็กเสมอไป คุณขอแก้ป้ายปุ่มเล็กน้อย แล้วอยู่ดีๆ เลย์เอาต์ของหน้าเปลี่ยน ฟอร์มไม่ตรวจสอบความถูกต้องอีกต่อไป หรือขั้นตอนการชำระเงินทำงานต่างออกไป แอปคือระบบที่เชื่อมโยงกัน UI, โลจิก, ข้อมูล และการผนวกรวมต่างพึ่งพากัน\n\nสาเหตุที่พบบ่อยคือขอบเขตไม่ชัดเจน หากคำขอบอกว่า “ทำให้การลงทะเบียนง่ายขึ้น” ผู้พัฒนา (มนุษย์หรือ AI) ต้องเดาว่า “ง่ายขึ้น” คืออะไร การเดานำไปสู่การแก้ไขเพิ่มเติม: ลบฟิลด์ เปลี่ยนขั้นตอน ปรับข้อความ หรือเขียนตรรกะใหม่ สาเหตุอีกประการคือการพึ่งพาแบบซ่อนเร้น การเปลี่ยน UI เล็กน้อยอาจใช้คอมโพเนนต์ที่ปรากฏในห้าจออื่น\n\nการวนซ้ำอย่างปลอดภัยหมายถึงคุณได้การปรับปรุงที่ตั้งใจไว้เพียงอย่างเดียว ในขณะที่ทุกอย่างอื่นยังเหมือนเดิม สำหรับทีมที่ไม่ใช่เทคนิค นั่นหมายถึงเวิร์กโฟลว์ยังคงรู้สึกเหมือนเดิมต่อผู้ใช้ สคริปต์ซัพพอร์ตยังตรงกับผลิตภัณฑ์ และรายงานยังอ่านได้ สำหรับทีมเทคนิค นั่นหมายถึงไม่มีการเปลี่ยนแปลงเส้นทาง รูปร่างข้อมูล สัญญา API หรือพฤติกรรมขอบเขตที่ไม่คาดคิด\n\nเพื่อให้เป็นไปได้ คุณต้องล็อกสิ่งที่ต้องไม่ขยับ ในทางปฏิบัติ โดยปกติจะรวมถึงฟลูว์ที่สำคัญ (ขั้นตอนที่ผู้ใช้ทำจริง), รายละเอียด UI/UX (เลย์เอาต์ ระยะห่าง พฤติกรรมการโต้ตอบ), กฎทางธุรกิจ (การตั้งราคา สิทธิ์ การตรวจสอบความถูกต้อง), พฤติกรรมข้อมูล (อะไรถูกเก็บและเมื่อใด) และการผนวกรวม (เหตุการณ์วิเคราะห์ อีเมล การชำระเงิน API ภายนอก)\n\nรูปแบบ “อย่าเปลี่ยน” นี้ลดความเสี่ยงโดยการตัดช่องว่างในการคาดเดาและทำให้การเปลี่ยนแปลงอยู่ในขอบเขต มันไม่ใช่การรับประกัน คุณยังอาจเจอ drift ถ้าพฤติกรรมต้นฉบับนิยามไม่ชัด หากการเปลี่ยนแปลงสัมผัสคอมโพเนนต์ที่ใช้ร่วมกัน หรือถ้าคุณไม่ยืนยันผล เป้าหมายคือความประหลาดใจน้อยลงและการอนุมัติที่เร็วขึ้น\n\n## รูปแบบ “อย่าเปลี่ยน” คืออะไร\n\nรูปแบบนี้คือวิธีเรียบง่ายในการขอการอัปเดตเพียงอย่างเดียวขณะที่ล็อกทุกอย่างที่เหลือ คุณระบุการเปลี่ยนแปลงเดียวที่ต้องการ แล้วเขียนรายการ freeze สั้นๆ ของส่วนที่ต้องคงไว้เหมือนเดิมหลังการอัปเดต\n\nเรื่องนี้สำคัญเพราะโมเดลมักพยายามช่วยโดยการรีแฟคเตอร์ เปลี่ยนชื่อ จัดระเบียบไฟล์ หรือ “ทำความสะอาด” ตรรกะในขณะที่แตะโค้ด แม้ว่าผลลัพธ์ยังคงทำงาน การเปลี่ยนแปลงเพิ่มเติมเหล่านั้นสามารถนำไปสู่บั๊ก เปลี่ยนพฤติกรรม หรือทำให้การรีวิวยากขึ้น\n\nเปรียบเทียบคำขอสองแบบ:\n\n“ทำให้หน้าการตั้งค่าให้ดีกว่า” คำนี้เชื้อเชิญให้เปลี่ยนดีไซน์ ข้อความ เลย์เอาต์ และตรรกะ\n\n“เปลี่ยนเฉพาะข้อความป้ายจาก ‘Phone’ เป็น ‘Mobile phone’ อย่าเปลี่ยนเลย์เอาต์ การตรวจสอบความถูกต้อง หรือพฤติกรรมการบันทึก” คำขอนี้แคบ ทดสอบได้ และปลอดภัยกว่า\n\nรายการ freeze ที่เข้มแข็งมักครอบคลุมสามด้าน:\n\n- Flows (เส้นทางผู้ใช้): ขั้นตอนที่ผู้ใช้ทำและหน้าจอที่ปรากฏ\n- UI และ UX: เลย์เอาต์ ระยะห่าง ลำดับฟิลด์ ตำแหน่งปุ่ม และการโต้ตอบ\n- กฎธุรกิจและพฤติกรรมข้อมูล: กฎการตรวจสอบความถูกต้อง สูตรการคำนวณราคา สิทธิ์ การเขียนฐานข้อมูล และการตอบกลับ API\n\nเมื่อใช้รูปแบบนี้ในเครื่องมือสร้างแบบแชทอย่าง Koder.ai การวนซ้ำมักเดินหน้าได้เร็วขึ้นเพราะโมเดลจะมุ่งที่การแก้ไขเดียวแทนที่จะทำ “ปรับปรุง” กว้างๆ ที่คุณไม่ได้ขอ\n\n## เทมเพลตพื้นฐานที่ใช้ซ้ำได้\n\nรูปแบบนี้ได้ผลดีที่สุดเมื่อคำขอของคุณอ่านเหมือนสัญญาเล็กๆ: เป้าหมายชัดเจนหนึ่งข้อ รายการ freeze ที่ล็อกสิ่งที่ต้องไม่เปลี่ยน และการตรวจสอบผลอีกเล็กน้อย\n\nคัดลอกเทมเพลตนี้แล้วกรอกในวงเล็บ ให้สั้นแต่เฉพาะเจาะจง\n\ntext\nGoal (one sentence):\n- Change: [describe the one small change you want]\n\nContext (1-3 sentences):\n- Current behavior: [what happens today]\n- Desired behavior: [what should happen after]\n\nDO NOT CHANGE (must remain identical):\n- Critical flows: [e.g., sign up -\u003e checkout -\u003e receipt stays the same]\n- UI/UX that must not move: [e.g., button location, labels, navigation order]\n- Business rules: [e.g., pricing, permissions, validation rules]\n- Data behavior: [e.g., database schema, stored fields, migration rules]\n\nConstraints (limit drift):\n- Scope: [only this screen / only this endpoint / only this component]\n- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]\n- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines\n\nAcceptance checks (how I will verify):\n1) [a simple before/after check]\n2) [a user path that must still work]\n3) [a rule that must still hold]\n\nOutput requested:\n- Provide a brief diff-style summary: what changed, where, and why\n- Call out any risk or unclear requirement before implementing\n\n\nตัวอย่างที่เป็นรูปธรรม: ถ้าคุณต้องการเปลี่ยนสีปุ่มชำระเงิน เป้าหมายของคุณคือ “อัปเดตสีปุ่มหลักของการชำระเงินเป็น #1A73E8” รายการ DO NOT CHANGE ควรล็อกทั้ง flow การชำระเงิน ข้อความปุ่ม และการคำนวณราคา\n\nถ้าคุณใช้ Koder.ai รูปแบบนี้ยังทำให้การรีวิวเร็วขึ้นเพราะคุณสามารถเปรียบเทียบการตรวจสอบการยอมรับกับตัวอย่างก่อนการอนุมัติได้\n\n## วิธีล็อกฟลูว์สำคัญโดยไม่กำกวม\n\nเมื่อขอการเปลี่ยนแปลงเล็กๆ อย่าเขียนแค่ว่า “อย่าให้เกิดการพัง” ให้ระบุเส้นทางผู้ใช้ที่ต้องเหมือนเดิมตั้งแต่คลิกแรกถึงผลลัพธ์สุดท้าย คุณไม่ได้ล็อกทั้งแอป แต่ล็อกส่วนที่การถดถอยสร้างปัญหาจริง\n\nเริ่มจากการระบุฟลูว์สำคัญด้วยภาษาง่ายๆ: การเข้าสู่ระบบ (รวมรีเซ็ตรหัสผ่าน), การเริ่มใช้งาน, การชำระเงิน, การตั้งค่า สำหรับแต่ละฟลูว์ ให้บอกว่าเมื่อถือว่า “เสร็จ” คืออะไร ตัวอย่าง: “ผู้ใช้สามารถล็อกอินด้วยอีเมล+รหัสผ่าน ไปยังแดชบอร์ด และคงสถานะล็อกอินหลังรีเฟรช”\n\nแล้วล็อกเคสขอบที่คนมักลืม พฤติกรรมปุ่มย้อนกลับเป็นแหล่งปัญหาคลาสสิก: “ย้อนกลับจากหน้าชำระเงิน กลับไปที่ตะกร้า (ไม่ใช่หน้าแรก) และของในตะกร้าต้องยังอยู่” ระบุข้อความข้อผิดพลาด (“รหัสผ่านไม่ถูกต้อง จะแสดงข้อความเดิม”), สถานะว่าง (“ไม่มีโปรเจกต์ แสดงข้อความว่างเดิม”), และสถานะโหลด (“สปินเนอร์ปรากฏภายใน 200ms ไม่มีการกระโดดของเลย์เอาต์”)\n\nถ้าคาดหวังด้านประสิทธิภาพและความปลอดภัย ให้ล็อกสิ่งเหล่านั้นด้วย ถ้าคุณไม่พูด โมเดลอาจ “ปรับปรุง” โดยเพิ่มคำขอใหม่ การบันทึก หรือเปลี่ยนการตรวจสอบสิทธิ์\n\nวิธีระบุแบบกระชับโดยไม่เขียนสเปกระดับนวนิยาย:\n\n- Flows ที่ต้องล็อก: Login, Signup, Checkout, Settings (ห้ามเพิ่มขั้นตอนหรือสลับลำดับหน้าจอ)\n- เคสขอบที่ต้องล็อก: พฤติกรรมปุ่มย้อนกลับ ข้อความผิดพลาด สถานะว่าง พฤติกรรมหลังรีเฟรช\n- พฤติกรรมข้อมูลที่ต้องล็อก: อะไรถูกบันทึก เมื่อไหร่ และจะแสดงที่ไหนหลังรีโหลด\n- ความปลอดภัยที่ต้องล็อก: สิทธิ์การเข้าถึง การตรวจสอบสิทธิ์ อัตราจำกัด ห้ามเพิ่ม endpoint สาธารณะ\n- ประสิทธิภาพที่ต้องล็อก: ห้ามเพิ่ม API call ในฟลูว์เหล่านี้ เวลาในการตอบไม่แย่กว่าปัจจุบัน\n\nระบุพฤติกรรมการไหลของข้อมูลทีละประโยค เช่น: “ที่อยู่จะถูกบันทึกก็ต่อเมื่อกด Save เท่านั้น เก็บใน record โปรไฟล์ผู้ใช้ และต้องคงอยู่หลัง logout/login” รายละเอียดระดับนี้ป้องกัน autosave ฟิลด์ใหม่ หรือการเปลี่ยนแปลงเวลา (timing) ที่ทำให้ผู้ใช้เสียหาย\n\n## วิธีล็อกรายละเอียด UI และ UX\n\nการเปลี่ยนแปลง UI มักเกิดขึ้นเพราะโมเดล “ช่วย” โดยทำความสะอาดสไตล์ ระยะห่าง หรือโครงสร้างคอมโพเนนต์ การแก้คือเหมือนกับกฎทางธุรกิจ: ระบุสิ่งที่ต้องคงไว้ และบอกสิ่งเดียวที่อนุญาตให้เปลี่ยน\n\nล็อกโครงสร้างที่มองเห็นได้ ระบุเลย์เอาต์ (คอลัมน์/แถว ตำแหน่ง header/footer), กฎระยะห่าง (padding, gaps, alignment), และพฤติกรรมของคอมโพเนนต์ (hover, disabled, loading spinners, ข้อความแสดงความผิดพลาด) ถ้าคอมโพเนนต์มีความรู้สึกเฉพาะ ให้บอกตรงๆ: “ขนาดปุ่ม รัศมี และสีต้องคงเดิม”\n\nพฤติกรรมแบบ responsive ต้องมีกฎชัดเจน หากไม่พูดถึงมือถือ เครื่องมืออาจ “ปรับปรุง” ให้แตกต่าง ระบุ breakpoints ที่คุณใส่ใจและบอกว่าต้องเกิดอะไรขึ้นในแต่ละ breakpoint: ลำดับการสแตก องค์ประกอบที่ซ่อน แถบคงที่ และขนาดเป้ากด (tap targets)\n\nนอกจากนี้ล็อกคำพูดด้วย บอกให้โมเดลว่าทุกข้อความ ป้ายคำ ช่วยข้อความ และ placeholder ต้องคงไว้ทั้งหมด ยกเว้นสตริงเดียวที่คุณต้องการแก้ไข วิธีนี้ป้องกันการเขียนทับเงียบๆ ที่เปลี่ยนความหมาย\n\nพรอมต์กระชับที่คุณสามารถวางในคำขอการเปลี่ยนแปลง:\n\n- รักษาให้เหมือนเดิม: routes/screens, ลำดับการนำทาง, และพฤติกรรมปุ่มย้อนกลับ\n- รักษาให้เหมือนเดิม: กริดเลย์เอาต์, ระยะห่าง, ฟอนต์, สี, และสถานะคอมโพเนนต์\n- รักษาให้เหมือนเดิม: ข้อความทั้งหมดยกเว้น: \u003cthe one string\u003e\n- กฎมือถือ: เก็บพฤติกรรมปัจจุบันที่ \u003cbreakpoints\u003e, ห้าม reflow ส่วนอื่น\n- เอาต์พุต: อธิบายการเปลี่ยนแปลง UI แต่ละอย่างที่ทำ และรายการไฟล์/คอมโพเนนต์ที่แก้ไข\n\nถ้าเป็นไปได้ ให้ขอภาพหน้าจอก่อน/หลัง ถ้าไม่มีภาพ ให้ขอคำอธิบาย “UI diff” สั้นๆ (อะไรย้าย อะไรขนาดเปลี่ยน อะไรเปลี่ยนสี) เพื่อให้คุณอนุมัติด้วยความมั่นใจ\n\n## วิธีล็อกกฎธุรกิจและพฤติกรรมข้อมูล\n\nกฎธุรกิจเป็นหนึ่งในจุดที่การเปลี่ยนแปลง UI เล็กๆ ทำให้เกิดรีเกรชชั่นอย่างเงียบๆ ได้ง่าย ป้ายข้อความอาจไปกระทบการคำนวณ การเปลี่ยนสถานะ หรือว่าใครเห็นระเบียน จัดการกฎและพฤติกรรมข้อมูลเป็นสัญญาที่ต้องคงไว้\n\nเริ่มจากการระบุไม่กี่กฎที่จะสร้างความเสียหายมากที่สุดหากเปลี่ยน เขียนเหมือนเป็นการทดสอบ: อินพุต เอาต์พุต และใครทำได้บ้าง\n\n### ระบุให้ชัดว่ากฎใดต้องไม่เปลี่ยน\n\nแทนที่จะบอกว่า “เก็บการตั้งราคาเหมือนเดิม” ให้กำหนด:\n\n- การตั้งราคา: สูตรที่แน่นอน การปัดเศษ (ขึ้น/ลง), สกุลเงิน, พฤติกรรมภาษี/VAT, และเมื่อใดที่ส่วนลดใช้ได้\n- สิทธิ์: บทบาทใดสร้าง แก้ไข ลบ อนุมัติ คืนเงิน ส่งออก หรือเห็นฟิลด์ที่ละเอียดอ่อน\n- สถานะ: สถานะที่อนุญาตและการเปลี่ยนสถานะที่ถูกต้อง (และทริกเกอร์ที่ทำให้เปลี่ยน)\n- การคำนวณ: ยอดรวม คอมมิชชั่น เครดิต ขีดจำกัด และเพดาน/ขั้นต่ำ\n- การเขียนข้อมูล: ตาราง/ระเบียนใดถูกสร้างหรืออัปเดต และอะไรต้องไม่เปลี่ยนแปลง\n\nเพิ่มตัวอย่างตัวเลขหนึ่งกรณีเพื่อลดการตีความ เช่น: “ยอดย่อยคำสั่งซื้อ $120 ส่วนลด 10% (ใช้ก่อนภาษี) ภาษี 8.25% จากยอดหลังหักส่วนลด ยอดรวมที่คาดหวัง = (120 - 12) * 1.0825 = $116.91 ปัดเศษทศนิยม 2 ตำแหน่งเฉพาะที่ยอดรวมสุดท้ายเท่านั้น”\n\nระบุการมองเห็นตามบทบาท ไม่ใช่แค่การดำเนินการ เช่น: “เจ้าหน้าที่ซัพพอร์ตเห็นสถานะคำสั่งซื้อและอีเมลลูกค้า แต่ต้องไม่เห็นรายละเอียดบัตรเต็ม มีเฉพาะแอดมินที่คืนเงินได้”\n\nถ้าการตรวจสอบความถูกต้องสำคัญ ให้ล็อกข้อความและทริกเกอร์อย่างชัดเจน: “ถ้าวันเริ่มมากกว่าวันสิ้นสุด ให้บล็อกการบันทึกและแสดง: ‘End date must be after start date.’ อย่าเปลี่ยนข้อความนี้”\n\nอย่าลืมผลข้างเคียงนอกแอป หากคุณส่งอีเมล เว็บฮุก หรือเรียก API ภายนอก ให้ล็อกสิ่งที่ต้องคงไว้: ชื่อเหตุการณ์ ฟิลด์ payload เวลา (ทันทีหรือหน่วง), และพฤติกรรม idempotency (ห้ามส่งซ้ำเมื่อ retry)\n\n## ทีละขั้นตอน: ขอการเปลี่ยนแปลงเล็ก ๆ อย่างปลอดภัย\n\nปฏิบัติต่อการอัปเดตเล็ก ๆ เหมือนสัญญาขนาดย่อ รูปแบบนี้ได้ผลที่สุดเมื่อการเปลี่ยนแปลงแคบ และทุกอย่างอื่นถูกล็อกอย่างชัดเจน\n\n1) เขียนการเปลี่ยนแปลงเป็นประโยคเดียวที่ทดสอบได้ “บนหน้าการตั้งค่า ให้เพิ่มสวิตช์สำหรับเปิดโหมดมืด” ทดสอบได้ ในขณะที่ “ปรับปรุง UI การตั้งค่า” ไม่ทดสอบได้ หากคุณทดสอบไม่ได้ใน 30 วินาที มันยังกว้างเกินไป\n\n2) เขียนรายการ freeze สำหรับส่วนที่จะเกิดปัญหาหากเปลี่ยน: ฟลูว์ผู้ใช้, องค์ประกอบ UI สำคัญ, กฎธุรกิจ, พฤติกรรมข้อมูล, และ API/ตารางฐานข้อมูลที่ต้องคงไว้\n\n3) เพิ่มการตรวจสอบยอมรับและแผนทดสอบสั้นๆ นี่คือที่ป้องกันปัญหา “มันทำงานบนเครื่องฉัน” รวมการตรวจสอบเช่น: สวิตช์ใหม่โผล่ขึ้นมา การตั้งค่าที่มีอยู่ยังบันทึกได้ และไม่มีอะไรบนหน้านั้นเคลื่อนที่\n\n4) ก่อนเริ่มแก้ไข ให้ขอให้ผู้ช่วยทวนข้อจำกัดกลับมาหาคุณ ให้ยืนยันว่าจะเปลี่ยนอะไรและอะไรต้องคงไว้ ถ้าการสรุปไม่ตรง ให้แก้พรอมต์ก่อนอนุญาตการเปลี่ยนแปลง\n\n5) ขอการดำเนินการที่เล็กที่สุดเท่าที่จะเป็นไปได้: ห้ามรีแฟคเตอร์ ห้ามเปลี่ยนชื่อ ห้ามจัดโครงโฟลเดอร์ ห้ามเปลี่ยนฟอร์แมตอื่นนอกจากบรรทัดที่แตะจริง ๆ คุณกำลังจ่ายเพื่อการเปลี่ยนแปลงหนึ่งอย่าง ไม่ใช่การปรับโฉม\n\nรายการสั้นๆ สำหรับการรีวิว:\n\n- มีเพียงพฤติกรรมที่ร้องขอเท่านั้นที่เปลี่ยน\n- ฟลูว์และหน้าจอที่ล็อกยังเหมือนเดิม\n- กฎธุรกิจและการเขียนข้อมูลไม่เปลี่ยน\n- การทดสอบหรือลำดับมือทำผ่านตามที่เขียน\n- ไม่มีคอมมิต cleanup หลุดเข้ามา\n\nวิธีนี้ได้ผลดีเป็นพิเศษใน Koder.ai: วางรายการ freeze ลงในโหมด Planning ให้มันสะท้อนข้อจำกัด แล้วสร้างแพตช์เล็กที่สุด\n\n## ข้อผิดพลาดทั่วไปที่ยังทำให้เกิด drift\n\nการแก้ไขเล็กๆ มักพังด้วยเหตุผลเดียวกัน: คำขอปกป้องเป้าหมาย แต่ไม่ปกป้องพฤติกรรม โมเดลอาจบรรลุเป้าหมายในวิธีใหม่ที่เงียบๆ เปลี่ยนหน้าจอ ตรรกะ หรือข้อมูล\n\nกับดักทั่วไปคือการล็อกผลลัพธ์ (“ทำให้องค์กรเข้าร่วมง่ายขึ้น”) แทนที่จะล็อกขั้นตอนทีละคลิก อีกกับดักคือการเขียนว่า “รักษาทุกอย่างให้เหมือนเดิม” แล้วคิดว่าระบบรู้ความหมาย\n\nข้อผิดพลาดที่มักทำให้เกิด drift มากที่สุด:\n\n- คำอธิบายกว้าง: ปกป้องเจตนา แต่ไม่ปกป้อง flow ทีละคลิก\n- ลืมเคสขอบ: สถานะว่าง, สถานะโหลด, ข้อผิดพลาดการตรวจสอบความถูกต้อง, การปฏิเสธสิทธิ์, พฤติกรรมออฟไลน์\n- รวมการเปลี่ยน: ขอหลายอย่างพร้อมกันทำให้เกิดการตัดสินใจและรีเกรชชั่นได้ง่าย\n- ไม่กำหนดคำว่า “เหมือนเดิม”: ต้องหมายถึง same UI layout, same API calls, same database writes, same emails/analytics\n- อนุมัติโดยความรู้สึก: มัน “ดูโอเค” โดยไม่ยืนยันเส้นทางสำคัญ\n\nตัวอย่างเล็กๆ: คุณขอให้ “ทำให้ปุ่มเด่นขึ้น” แล้วล็อกสี แต่ลืมล็อกสถานะ disabled การอัปเดตอาจเผลอเปิดปุ่มตลอดเวลา เปลี่ยนพฤติกรรมโดยที่คุณสังเกตเห็นทีหลัง\n\nสิ่งที่ช่วยได้คือการระบุชัดเจนว่าห้ามเปลี่ยนอะไร ก่อนยอมรับการแก้ไข ให้ทำการรีเกรชชั่นสั้นๆ:\n\n- รันฟลูว์หลักแบบ end-to-end (ฟลูว์ที่คุณล็อก)\n- กระตุ้นอย่างน้อยหนึ่งเคสผิดพลาดและหนึ่งสถานะว่าง\n- ตรวจสอบสิทธิ์ (แอดมิน vs ผู้ใช้ปกติ) ถ้าจำเป็น\n- ยืนยันผลข้างเคียง: ระเบียนที่สร้าง/อัปเดต การแจ้งเตือนที่ส่ง และเมตริก/ล็อกยังเหมือนเดิม\n\nถ้าสิ่งใดต่าง ให้ถือว่าคำขอขาดรายละเอียด freeze ไม่ใช่โค้ดไม่ดี\n\n## ตัวอย่าง: ปรับ UI เล็กๆ โดยไม่เปลี่ยนเวิร์กโฟลว์\n\nการวนซ้ำที่ปลอดภัยทั่วไปคือปรับแต่ง UI เล็กน้อยที่เวิร์กโฟลว์ห้ามเปลี่ยน\n\nสถานการณ์: ผู้ก่อตั้งมีหน้าลงทะเบียนง่ายๆ มีฟอร์มสั้น (Name, Email, Company size) และปุ่มหลักที่ส่งฟอร์มแล้วนำผู้ใช้ไปแดชบอร์ด\n\nคำขอการเปลี่ยนแปลงที่ชัดเจน (ประโยคเดียว): “เปลี่ยนป้ายปุ่มหลักจาก 'Create account' เป็น 'Continue' และเปลี่ยนฟิลด์ 'Company size' จาก input ข้อความเป็น dropdown”\n\nนำรูปแบบมาประยุกต์โดยล็อกสิ่งที่ต้องคงไว้:\n\n- ล็อกฟลูว์: การส่งยังคงสร้างบัญชี แสดงข้อความการตรวจสอบความถูกต้องเหมือนเดิม และนำผู้ใช้ไปหน้าถัดไปเดิม\n- ล็อก UI: เลย์เอาต์ของหน้า ระยะห่าง สี และตำแหน่งปุ่มต้องเหมือนเดิม\n- ล็อกข้อมูล: คีย์ payload และชนิดข้อมูลของ backend ห้ามเปลี่ยน; ค่าที่เก็บของ company size ต้องคงรูปแบบเดิม\n- ล็อกกฎธุรกิจ: ฟิลด์ที่จำเป็นยังคงจำเป็น และปุ่มยังคงถูกปิดจนกว่าฟอร์มจะถูกต้อง\n- ล็อกการวิเคราะห์: เหตุการณ์ tracking เดิมยังคงยิงเมื่อส่งและเมื่อเกิดข้อผิดพลาดการตรวจสอบความถูกต้อง\n\nการตรวจยอมรับที่ทำได้ในไม่กี่นาที:\n\n- ข้อความปุ่มแสดง “Continue” ทุกที่ (สถานะปกติ, กำลังโหลด, ถูกปิด)\n- Company size เป็น dropdown โดยมีค่าเริ่มต้นเหมือนเดิม\n- การส่งยังไปแดชบอร์ดและบัญชีถูกสร้าง\n- ผู้ใช้เดิมที่แก้ไขโปรไฟล์ยังเห็นค่าที่บันทึกของ company size ถูกต้อง\n- ไม่มีคำเตือนใหม่หรือการทดสอบล้มเหลวในพื้นที่ลงทะเบียน\n\nผู้ช่วยที่ดีควรทวนรายการล็อกยืนยันความคลุมเครือง กำหนดความไม่ชัดเจน (เช่น: ตัวเลือก dropdown ที่ต้องมีและค่าที่เก็บ) แล้วทำเพียงการเปลี่ยนแปลงเล็กที่สุดที่ต้องทำ พร้อมระบุสิ่งที่ไม่ได้แตะ (routing, validation logic, payload shape)\n\n## เช็คลิสต์ด่วนก่อนยอมรับการอัปเดต\n\nก่อนยอมรับการเปลี่ยนแปลงเล็กๆ ให้ทำการตรวจสอบรวดเร็วเพื่อหา drift เงียบ เป้าหมายไม่ใช่ QA เต็มรูปแบบ แต่ยืนยันว่าแอปยังทำงานในจุดที่คุณบอกว่า “อย่าเปลี่ยน” ยกเว้นการแก้ไขเดียวที่ตั้งใจไว้\n\n### 5 การตรวจสอบด่วน (10 นาที)\n\nทำตามลำดับนี้เสมอ มันช่วยให้การรีวิวเป็นระบบและจับการเปลี่ยนแปลงได้ง่ายขึ้น\n\n- ฟลูว์สำคัญยังเสร็จสมบูรณ์: เริ่มจากจุดเข้าใช้งานจริงของผู้ใช้ (login, หน้าแลนดิ้ง, แดชบอร์ด) และทำงานให้เสร็จ\n- UI เหมือนเดิมยกเว้นการเปลี่ยนที่ตั้งใจ: เปิดหน้าจอสำคัญที่ล็อกไว้ ตรวจดูเลย์เอาต์ ป้ายปุ่ม ระยะห่าง และการนำทาง\n- กฎธุรกิจยังตรงกับความเป็นจริง: ตรวจตัวอย่าง 2-3 กรณีที่มักพัง เช่น การคำนวณส่วนลด สิทธิ์บทบาท หรือการเปลี่ยนสถานะ\n- รูปร่างข้อมูลไม่เปลี่ยน: ยืนยันว่าไม่มีฟิลด์ใหม่ เปลี่ยนชื่อ หรือย้ายฟิลด์ และไม่มีการมิเกรตที่ไม่พึงประสงค์\n- การผนวกรวมไม่ถูกแตะต้อง: ยืนยันว่าไม่มีการเปลี่ยน endpoint และไม่มีการเปลี่ยน payload (ชื่อฟิลด์ ฟิลด์ที่บังคับ รหัสสถานะ)\n\n### เมื่อไหร่ควรย้อนกลับและออกพรอมต์ใหม่\n\nย้อนกลับถ้าสิ่งที่ล็อกไว้เปลี่ยน แม้มันจะทำงานได้อยู่ การเปลี่ยนป้ายข้อความ ฟิลด์ใหม่ หรือกฎที่เปลี่ยนเป็นสัญญาณว่าโมเดลทำเกินสิ่งที่ขอ\n\nออกพรอมต์ใหม่ด้วยข้อจำกัดที่เข้มงวดขึ้น: สรุปการเปลี่ยนเดียวในประโยคเดียว ลิสต์ฟลูว์และหน้าจอที่ล็อกตามชื่อ และเพิ่ม "no schema changes, no endpoint changes, no behavior changes outside X." ถ้าใช้ Koder.ai การจับ snapshot ก่อนทดสอบทำให้การย้อนกลับทำได้เร็วเมื่อพบ drift\n\n## ขั้นตอนต่อไป: นำไปใช้ใน Koder.ai เพื่อการวนซ้ำที่ปลอดภัยขึ้น\n\nถ้าคุณสร้างใน Koder.ai รูปแบบนี้ได้ผลดีที่สุดเป็นนิสัย: การเปลี่ยนหนึ่งอย่าง ล็อกทุกอย่างที่เหลือ และมีทางกลับชัดเจนถ้าเกิด drift\n\n### เริ่มด้วยการวางแผนสั้นๆ\n\nก่อนขอการเปลี่ยน ให้สลับไปโหมด Planning และให้ผู้ช่วยสรุปขอบเขตด้วยคำง่ายๆ ขอให้มันทวนสองอย่าง: (1) การเปลี่ยนที่ชัดเจน และ (2) รายการ freeze ชัดเจน (flows, รายละเอียด UI, และกฎธุรกิจที่ห้ามขยับ)\n\nพรอมต์การวางแผนที่ได้ผล: “ทวนคำขอของฉัน แล้วลิสต์สิ่งที่ห้ามเปลี่ยน ถ้ามีความไม่ชัดเจน ให้ถามก่อนแก้ไข”\n\n### ปกป้องแต่ละครั้งด้วย snapshot\n\nปฏิบัติต่อทุกคำขอเป็นจุดตรวจ สร้าง snapshot ก่อนอัปเดต แล้วอีก snapshot หลังยืนยัน หากมีปัญหา rollback จะเร็วกว่าการพยายามแพตช์ทับการเปลี่ยนแย่ๆ\n\nตัวอย่าง workflow ง่ายๆ:\n\n- สร้าง snapshot: “Before - change button label only”\n- รันการวางแผนและยืนยันรายการ freeze\n- ขอการเปลี่ยนแปลงเดียวและขอสรุปแบบ diff สั้นๆ ว่าอะไรเปลี่ยน\n- ยืนยันด้วยเช็คลิสต์ (UI, flows, กฎ, ข้อมูล)\n- สร้าง snapshot: “After - verified”\n\n### ใช้รูปแบบนี้ข้ามสแต็กทั้งหมด\n\nKoder.ai สามารถสร้างเว็บ (React), backend (Go + PostgreSQL), และมือถือ (Flutter) รูปแบบนี้ยังใช้ได้แม้โค้ดจะแตกต่าง กันล็อกส่วนที่นิยามพฤติกรรม ไม่ใช่แค่ชื่อไฟล์\n\nถ้าคุณเปลี่ยน endpoint backend ให้ล็อกรูปร่าง request/response, กฎการตรวจสอบความถูกต้อง, และการเขียนข้อมูล ถ้าเปลี่ยนหน้าจอมือถือ ให้ล็อกลำดับนำทาง ค่าเริ่มต้นของฟิลด์ และข้อความผิดพลาด ถ้าเปลี่ยนตรรกะฐานข้อมูล ให้ล็อกความหมายของแถวเดิมและทำให้มิเกรชันปลอดภัย\n\nคัดลอกเทมเพลตของคุณ ใช้การเปลี่ยนเล็กๆ วันนี้ และยืนยันด้วยเช็คลิสต์ก่อนยอมรับการอัปเดต เก็บเทมเพลตไว้แล้วสลับคำขอครั้งต่อไปทีละรายการ