วิธีปรับปรุงแอปที่สร้างด้วย AI โดยไม่ทำให้พัง

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

แอปเวอร์ชันแรกมักเสร็จในไม่กี่นาที ส่วนที่ยากคือการเปลี่ยนแปลงครั้งที่ห้าสิบ เมื่อพรอมต์ใหม่แต่ละครั้งมีความเสี่ยงทำให้สิ่งที่ใช้งานได้อยู่แล้วพังไป คู่มือนี้คือวงจรที่ช่วยป้องกันเรื่องนั้น

วงจรการปรับปรุง

1. เลือกการเปลี่ยนแปลงหนึ่งอย่าง ฟีเจอร์หนึ่งอย่าง บั๊กหนึ่งอย่าง หรือหน้าหนึ่งหน้า
2. อธิบาย ในแง่ของสิ่งที่ผู้ใช้เห็นและทำ
3. สำหรับการเปลี่ยนแปลงใหญ่ ให้วางแผนก่อน ขอแผน อ่าน แล้วจึงสร้าง
4. ตรวจผลลัพธ์ ในพรีวิว ทั้งการเปลี่ยนแปลงและขั้นตอนที่อยู่ใกล้เคียง
5. บันทึก จุดตรวจหรือคอมมิต
6. ทำซ้ำ

ทุกขั้นตอนมีไว้เพื่อให้การเปลี่ยนแปลงเล็กและย้อนกลับได้

ขั้นตอนที่ 1: มีรายการสั้น ๆ

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

ถ้าการเปลี่ยนแปลงใหญ่ ให้แบ่งย่อย "เพิ่มบัญชีทีม" จะกลายเป็น: สร้างทีม เชิญสมาชิก สลับระหว่างทีม และจำกัดข้อมูลให้อยู่ในทีมปัจจุบัน แต่ละข้อเป็นพรอมต์ของตัวเอง การเขียนเรื่องราวผู้ใช้ เป็นวิธีที่ดีในการทำแบบนี้

ขั้นตอนที่ 2: อธิบายสิ่งที่คุณเห็น

AI มองไม่เห็นหน้าจอของคุณ ถ้าคุณไม่บอก ให้ชี้ไปที่สิ่งเฉพาะเจาะจง และบอกว่าควรเกิดอะไรขึ้น:

บนหน้าราคาในมือถือ ปุ่มของการ์ด Pro ถูกตัดที่ขอบขวา คงเลย์เอาต์บนเดสก์ท็อปไว้เหมือนเดิม บนหน้าจอที่กว้างไม่ถึง 640px ให้เรียงการ์ดเป็นแนวตั้ง และทำให้ปุ่มกว้างเต็มความกว้าง

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

ภาพหน้าจอช่วยได้มาก ถ้าเครื่องมือของคุณรับรูปภาพ ให้แนบและวงรอบปัญหา

ขั้นตอนที่ 3: วางแผนก่อนการเปลี่ยนแปลงใหญ่

สำหรับทุกอย่างที่กระทบหลายส่วนของแอป เช่น โมเดลข้อมูลใหม่ การชำระเงิน หรือบทบาทผู้ใช้ ให้ขอแผนก่อนที่โค้ดจะเปลี่ยน:

ยังไม่ต้องเปลี่ยนโค้ด ฉันต้องการให้ผู้ใช้เป็นสมาชิกของทีม และเห็นเฉพาะโปรเจกต์ของทีมตัวเอง วางแผนการเปลี่ยนแปลง: ตาราง หน้า และ API route ไหนจะเปลี่ยน ข้อมูลของผู้ใช้เดิมจะเป็นอย่างไร และจะสร้างตามลำดับใด

อ่านแผน ถ้ามันผิด การแก้แผนถูกกว่าการย้อนการสร้างมาก

ขั้นตอนที่ 4: บอกว่าอะไรต้องไม่เปลี่ยน

เครื่องมือ AI บางครั้ง "จัดระเบียบ" สิ่งที่คุณไม่ได้ขอ ปกป้องสิ่งที่ใช้งานได้:

เพิ่มตัวกรองวันที่ในตารางคำสั่งซื้อ อย่าเปลี่ยนคอลัมน์ สไตล์ หรือปุ่มส่งออกของตาราง

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

ขั้นตอนที่ 5: ตรวจมากกว่าแค่การเปลี่ยนแปลง

หลังทุกพรอมต์ ให้ทดสอบ:

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

ถ้ามีอะไรผิดปกติ ให้รายงานอย่างแม่นยำ ดู วิธีเขียนรายงานบั๊กที่ดี

ขั้นตอนที่ 6: ย้อนกลับแทนการซ้อนการแก้ไข

เมื่อการเปลี่ยนแปลงทำให้บางอย่างพัง และการแก้ครั้งแรกไม่ได้ผล ให้หยุด การแก้เพิ่มทุกครั้งสร้างบนสถานะที่พังอยู่ และปัญหาจะซ้อนทับกัน

แทนที่จะทำแบบนั้น:

1. ย้อนกลับไปยังเวอร์ชันล่าสุดที่ใช้งานได้ (จุดตรวจหรือคอมมิตของ Git)
2. หาว่าพรอมต์ไหนไม่ชัดเจน
3. ลองใหม่ด้วยคำขอที่เล็กลงหรือชัดเจนขึ้น

การเปลี่ยนแปลงนั้นทำให้การบันทึกฉบับร่างพัง ฉันย้อนกลับแล้ว คราวนี้ให้เพิ่มตัวบ่งชี้การบันทึกอัตโนมัติเป็นข้อความในส่วนหัวเท่านั้น อย่าเปลี่ยนวิธีบันทึกฉบับร่าง

ขั้นตอนที่ 7: รู้ว่าเมื่อไหร่ควรสร้างใหม่

การสร้างใหม่ตั้งแต่ต้นทิ้งรายละเอียดที่ทำงานได้จำนวนมาก คุ้มค่าเฉพาะเมื่อ:

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

เมื่อสร้างใหม่ ให้ลิสต์สิ่งที่จะเก็บไว้: ชื่อ สี ข้อความ ส่วนที่ผู้ใช้ชอบ

ตัวอย่างพรอมต์

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

ฉันอยากเพิ่มการจองแบบเกิดซ้ำ เวอร์ชันที่เล็กที่สุดที่ยังใช้ประโยชน์ได้คืออะไร แนะนำมาเป็นการเปลี่ยนแปลงแยกกันสามอย่างที่เราทำทีละอย่างได้

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

ความผิดพลาดที่พบบ่อย

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

รายการตรวจสอบ

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

การปรับปรุงบน Mythex

Mythex สร้างขึ้นรอบวงจรนี้:

• โหมด Plan, Build และ Ask Plan หารือแนวทางก่อนแก้ไข Ask ตอบคำถามโดยไม่เปลี่ยนโค้ด Build ทำการเปลี่ยนแปลง ดู Chat
• จุดตรวจ หลังทุกเทิร์นที่สำเร็จ Mythex บันทึกจุดตรวจของ git และ Revert to this point ใช้ย้อนกลับได้ คุณยังแก้ข้อความก่อนหน้าแล้วใช้ Discard & resend เพื่อลองพรอมต์อื่นจากจุดนั้นได้ ดู ปรับปรุงโดยไม่ต้องสร้างใหม่
• ความรู้ Project settings → Knowledge เก็บบันทึกถาวรที่เอเจนต์ปฏิบัติตามในทุกข้อความ
• /test ให้เอเจนต์คลิกผ่านพรีวิวเหมือนผู้ใช้หลังการเปลี่ยนแปลงใหญ่

การขอที่เล็กกว่ายังใช้เครดิตน้อยกว่าด้วย เกี่ยวกับการเขียนพรอมต์เอง ดู วิธีเขียนพรอมต์สำหรับเครื่องมือสร้างแอป AI เมื่อบางอย่างพังจริง ดู วิธีดีบักแอปที่สร้างด้วย AI

คำถาม