วิธีดีบักแอปที่สร้างด้วย AI: วิธีปฏิบัติจริง

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

คู่มือนี้ครอบคลุมทั้งลูป พร้อมทัวร์สั้น ๆ ของเครื่องมือนักพัฒนาของเบราว์เซอร์สำหรับคนที่ไม่ใช่นักพัฒนา

ลูปการดีบัก

การแก้บั๊กทุกครั้ง ไม่ว่าคนหรือ AI จะเป็นผู้ทำ ล้วนทำตามลูปเดียวกัน:

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

เวลาที่เสียไปกับแอปที่สร้างด้วย AI มักมาจากการข้ามขั้นตอนที่ 1, 2 และ 5 คือการพูดว่า “มันพัง” การยอมรับการเปลี่ยนแปลงโดยไม่ทดสอบ และแล้วขอแก้ไขอีกครั้งทับสิ่งที่พังอยู่แล้ว

ขั้นที่ 1: ทำให้บั๊กเกิดซ้ำ

บั๊กที่คุณกระตุ้นได้ตามต้องการคือการแก้ไปครึ่งหนึ่งแล้ว ลองหาขั้นตอนที่สั้นที่สุดที่ทำให้มันเกิดขึ้น

ถามตัวเอง:

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

เขียนขั้นตอนเป็นรายการลำดับเลขสั้น ๆ คุณจะวางมันลงในพรอมต์ภายหลัง

ขั้นที่ 2: อ่านข้อความ error

ข้อความ error ดูน่ากลัว แต่คุณต้องการแค่บางส่วนของมัน

คุณไม่จำเป็นต้องเข้าใจมัน คุณต้องคัดลอกมาให้ตรงทุกตัวอักษร “Cannot read properties of undefined (reading 'name')” บอก AI ว่าโค้ดคาดหวังข้อมูลบางอย่าง (น่าจะเป็นการจองหรือผู้ใช้) ที่ไม่มีอยู่ การเขียนใหม่เป็น “some undefined error” ทำให้สูญเสียข้อมูลนั้นไป

ข้อผิดพลาดทั่วไปบางตัวพร้อมคำอธิบายโดยประมาณ:

• ข้อผิดพลาด undefined / null โค้ดคาดหวังข้อมูลที่ไม่มาถึง มักเป็นสถานะกำลังโหลดหรือรายการว่างที่โค้ดไม่ได้จัดการ
• 404 Not Found หน้าหรือที่อยู่ API ไม่มีอยู่ มักเป็นการพิมพ์เส้นทางผิดหรือลิงก์ไปยังหน้าที่ถูกเปลี่ยนชื่อ
• 401 Unauthorized / 403 Forbidden คำขอไม่ได้ล็อกอิน หรือผู้ใช้ไม่มีสิทธิ์ทำสิ่งนั้น
• 500 Internal Server Error โค้ดฝั่งเซิร์ฟเวอร์ล่ม สาเหตุจริงอยู่ในล็อกของเซิร์ฟเวอร์ ไม่ใช่เบราว์เซอร์
• ข้อผิดพลาด CORS เบราว์เซอร์บล็อกคำขอไปยังโดเมนอื่น มักเป็นปัญหาการตั้งค่าฝั่งเซิร์ฟเวอร์

ขั้นที่ 3: ใช้เครื่องมือนักพัฒนาของเบราว์เซอร์

เบราว์เซอร์เดสก์ท็อปทุกตัวมีเครื่องมือนักพัฒนาในตัว ("devtools") แสดงสิ่งที่หน้าเว็บกำลังทำอยู่เบื้องหลัง ใน Chrome, Edge และ Firefox คลิกขวาที่ใดก็ได้ของหน้าแล้วเลือก Inspect (ตรวจสอบ) หรือกด F12 (Cmd+Option+I บน Mac) ใน Safari ให้เปิดเมนู Develop ในการตั้งค่า Safari ก่อน

คุณใช้แค่สามแท็บ

Console

แท็บ Console แสดงข้อผิดพลาดและข้อความจากโค้ดของหน้า ข้อผิดพลาดแสดงเป็นสีแดง หากปุ่มไม่ทำอะไรเมื่อคลิก คอนโซลมักจะแสดง error สีแดงตอนที่คุณคลิก คัดลอกข้อความ error ทั้งหมด (คลิกขวาเพื่อคัดลอกในเบราว์เซอร์ส่วนใหญ่)

Network

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

• มองหาแถวสีแดงหรือมีสถานะ 400 ขึ้นไป
• คลิกแถวที่ล้มเหลวเพื่อดู Response ข้อผิดพลาดของเซิร์ฟเวอร์มักมีข้อความที่มีประโยชน์กว่าสิ่งที่แสดงบนหน้าจอ
• จดบันทึก URL ของคำขอและรหัสสถานะ ประโยคอย่าง “POST ไปยัง /api/bookings คืนค่า 500” มีประโยชน์มากสำหรับ AI

ติ๊ก Preserve log หากบั๊กเกี่ยวข้องกับการรีโหลดหน้าหรือการ redirect เพื่อให้คำขอไม่หายไป

Elements

แท็บ Elements (หรือ Inspector) แสดงโครงสร้างและสไตล์ของหน้า มีประโยชน์ที่สุดสำหรับบั๊กเลย์เอาต์ วางเมาส์บนองค์ประกอบเพื่อดูขนาดและระยะห่างที่ถูกไฮไลต์ คุณไม่จำเป็นต้องแก้ไขที่นี่ การบอกว่า “ฟุตเตอร์กว้าง 2,000 พิกเซลบนมือถือและดันหน้าให้เลื่อนไปด้านข้าง” ก็เพียงพอแล้ว

ขั้นที่ 4: ตรวจล็อกของเซิร์ฟเวอร์

บั๊กบางอย่างเกิดขึ้นบนเซิร์ฟเวอร์ ที่เบราว์เซอร์มองไม่เห็น error 500 ในแท็บเครือข่ายเป็นสัญญาณคลาสสิก ล็อกของเซิร์ฟเวอร์ คือเอาต์พุตข้อความของแบ็กเอนด์ขณะที่มันทำงาน มักมี error จริงพร้อม stack trace (รายการฟังก์ชันที่กำลังทำงานอยู่ตอนล้มเหลว)

คุณจะพบมันได้ที่ไหนขึ้นอยู่กับเครื่องมือ ใน AI app builder ส่วนใหญ่คุณเปิดเทอร์มินัลหรือมุมมองล็อกของโปรเจกต์ได้ หรือเพียงขอให้ AI ว่า “ตรวจล็อกของเซิร์ฟเวอร์สำหรับ error จากคำขอล่าสุดและบอกว่าอะไรล้มเหลว”

ขั้นที่ 5: อธิบายบั๊กให้ AI ฟัง

ใส่สิ่งที่คุณรวบรวมได้ลงในรูปแบบนี้:

ในหน้า Bookings ล็อกอินเป็นสมาชิก: ฉันคลิก Cancel ที่คลาส 9:00 ของพรุ่งนี้ คาดหวัง: การจองหายไปและคลาสแสดงที่ว่างเพิ่มหนึ่งที่ ที่เกิดขึ้นจริง: ไม่มีอะไรเปลี่ยนบนหน้าจอ คอนโซลแสดง TypeError: Cannot read properties of undefined (reading 'id') ที่ BookingCard.tsx:31 และแท็บเครือข่ายแสดง DELETE /api/bookings/123 คืนค่า 500 หาสาเหตุ แก้ไข และตรวจว่าการยกเลิกใช้งานได้ทั้งสมาชิกที่มีหนึ่งการจองและหลายการจอง

แต่ละส่วนสำคัญอย่างไร:

• ที่ไหนและในฐานะใคร จำกัดให้แคบลงเป็นหน้าเดียวและบทบาทเดียว
• ขั้นตอนที่แม่นยำ ให้ AI ทำซ้ำได้
• คาดหวังกับที่เกิดขึ้นจริง กำหนดว่า “แก้แล้ว” หมายถึงอะไร
• ข้อความ error และคำขอที่ล้มเหลว ชี้ตรงไปยังสาเหตุ
• “ตรวจว่า…” ขอให้ AI ยืนยัน ไม่ใช่แค่แก้ไข

หาก AI พยายามแก้สองครั้งแล้วล้มเหลว ให้ขอให้มันอธิบายก่อนเปลี่ยนอะไร:

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

ทฤษฎีที่ผิดจะเห็นได้ง่ายเมื่อเขียนออกมา และแก้ไขได้ถูกกว่าการแก้ที่ผิดมาก

ขั้นที่ 6: ตรวจสอบ แล้วดูสิ่งรอบข้าง

เมื่อ AI บอกว่าแก้แล้ว ให้ทำขั้นตอนเดิมจากขั้นที่ 1 ซ้ำ จากนั้นตรวจสิ่งที่อยู่รอบ ๆ:

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

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

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

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

นิสัยดี ๆ ที่ทำให้การย้อนกลับง่าย:

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

รูปแบบบั๊กที่พบบ่อยในแอปที่สร้างด้วย AI

เมื่อปัญหาไม่ใช่บั๊ก

บาง “บั๊ก” คือ AI กำลังสร้างสิ่งที่มันถูกบอกจริง ๆ และคำอธิบายคลุมเครือ หากสิ่งที่คุณขอให้แก้จริง ๆ แล้วคือการเปลี่ยนพฤติกรรม ให้พูดออกมาตรง ๆ ว่า “เปลี่ยนให้…” หากคุณไม่แน่ใจว่าพฤติกรรมที่ถูกต้องคืออะไร ให้ตัดสินใจเรื่องนั้นก่อน และ คู่มือการเขียนพรอมต์สำหรับ AI app builder ครอบคลุมวิธีระบุกฎให้ชัดเจน และหากคุณกำลังเตรียมแอปสำหรับผู้ใช้จริง การนำต้นแบบ AI ไปใช้งานจริง ครอบคลุมการตรวจสอบที่ควรทำก่อนเปิดตัว

การดีบักใน Mythex

Mythex มีเครื่องมือสำหรับแต่ละขั้นตอนของลูป:

• Preview เพื่อทำให้บั๊กเกิดซ้ำ รวมถึงเฟรมขนาดมือถือ
• /test ให้เอเจนต์คลิกผ่านพรีวิวสดของคุณเหมือนผู้ใช้และรายงานขั้นตอนที่พัง
• /fix ชี้ให้เอเจนต์โฟกัสที่การพังโดยเฉพาะ
• โหมด Plan ให้เอเจนต์ตรวจสอบและอธิบายก่อนแก้ไขอะไรทั้งนั้น
• Code → terminal แสดงล็อกเซิร์ฟเวอร์ของแอปคุณ
• Revert to this point ในการตอบกลับใดก็ได้เพื่อย้อนโปรเจกต์กลับไปยังจุดตรวจนั้น

หากการเผยแพร่ล้มเหลว กล่องโต้ตอบการเผยแพร่มักมีตัวเลือก Fix with AI ซึ่งอ่านผลลัพธ์การ build หรือล็อกของแอป ดู Debug your app และ Publish troubleshooting ในเอกสาร

คำถาม