Lovable หรือ Bolt ติดลูปแก้บั๊กไม่จบ? วิธีทำ MVP ของคุณให้เสร็จ

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

ทำไมแอปที่สร้างด้วย AI ถึงติดลูปแก้บั๊ก?

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

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

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

พรีวิวของตัวสร้างแอปพัง หรือแอปของคุณพัง?

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

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

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

ควรบันทึกอะไรไว้ก่อนลองแก้ไขอีกครั้ง?

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

เอกสารประวัติเวอร์ชัน ของ Lovable อธิบายการพรีวิว การบุ๊กมาร์ก และการย้อนกลับเวอร์ชันโค้ด โดยระบุไว้ชัดเจนว่าการย้อนกลับโค้ดจะไม่ย้อนข้อมูลในฐานข้อมูล ก่อนกู้คืนเวอร์ชันใด ให้ตรวจสอบว่างานที่ทำหลังจากนั้นได้เปลี่ยนแปลงรายการข้อมูล สิทธิ์การเข้าถึง หรือสคีมาที่โค้ดเวอร์ชันเก่าต้องการหรือไม่

1. ระบุสถานะล่าสุดที่เส้นทางการใช้งานหลักยังทำงานได้ พร้อมเวลาหรือรหัส commit
2. บันทึกความล้มเหลวปัจจุบัน และบันทึกงานที่ยังไม่ได้ commit ซึ่งมีประโยชน์ผ่านเวิร์กโฟลว์ที่โปรเจกต์ของคุณรองรับ
3. สร้างการสำรองฐานข้อมูลที่เหมาะสมหรือสำเนาทดสอบที่ปลอดภัย ก่อนทำงานที่เปลี่ยนแปลงข้อมูลหรือสคีมา
4. จดไว้ว่าโปรเจกต์และสภาพแวดล้อมใดมีผู้ใช้จริงอยู่ เพื่อให้ทดสอบการแก้ไขแยกจากพวกเขาได้

พรอมต์สำหรับแก้ไขที่มีประโยชน์หน้าตาเป็นอย่างไร?

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

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

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

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

จะรู้ได้อย่างไรว่าการแก้ไขได้ผลจริง?

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

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

เมื่อไรควรดึงนักพัฒนาเข้ามาช่วย?

ดึงนักพัฒนาเข้ามาเมื่อคุณไม่สามารถอธิบายหรือยืนยันการเปลี่ยนแปลงในเส้นทางสำคัญได้อย่างมั่นใจ หรือเมื่อการตรวจสอบแบบเจาะจงแล้วยังแยกสาเหตุไม่ได้ การเข้าถึงระบบชำระเงิน การเปิดเผยข้อมูลข้ามบัญชี และการเปลี่ยนแปลงฐานข้อมูลซ้ำ ๆ เป็นเรื่องที่ต้องระมัดระวังเป็นพิเศษ

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

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

รีลีสถัดไปของคุณควรมีอะไรบ้าง?

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

ใช้ แผนเปิดตัว MVP แบบ 12 ข้อ เพื่อหาช่องโหว่ข้างเคียงหลังการแก้ไข หากแอปทำงานได้ในพรีวิวแต่พังเมื่อเผยแพร่บน Replit ให้ใช้ เช็กลิสต์การดีพลอย Replit หากต้องการความช่วยเหลือแบบลงมือทำ ให้เลือกจุดเริ่มต้นที่หน้า Lovable หรือ Bolt แล้วจองการคุย นำโฟลว์ที่ล้มเหลวมาด้วย การสนทนาครั้งแรกควรช่วยกำหนดขั้นตอนถัดไปที่มีประโยชน์