การดีบักและการแก้ไขปัญหา

กำไร:

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

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

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

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

อธิบาย Bug ให้กับ AI

โอกาสที่ AI จะค้นหาสาเหตุที่แท้จริงนั้นแปรผันโดยตรงกับคุณภาพของข้อมูลที่คุณให้ คำอธิบายข้อผิดพลาดที่ดีประกอบด้วย: สิ่งที่คุณพยายามทำ สิ่งที่คุณคาดหวัง สิ่งที่เกิดขึ้น ข้อความแสดงข้อผิดพลาดและการติดตามสแต็ก โค้ดที่เกี่ยวข้อง สภาพแวดล้อม (ภาษา/เวอร์ชัน/ระบบปฏิบัติการ) และตัวอย่างที่น้อยที่สุดที่ทำให้เกิดข้อผิดพลาด

1. ชี้แจงอาการ. ในรูปแบบ "Expected X,actualized Y"
2. วางข้อความแสดงข้อผิดพลาดแบบเต็มและการติดตามสแต็ก อย่าย่อให้สั้น เซ็นเซอร์ แต่อย่าทำลายโครงสร้าง
3. ให้การสืบพันธุ์ที่เล็กที่สุด อินพุตและโค้ดขั้นต่ำที่ทำให้เกิดข้อผิดพลาด
4. ระบุสภาพแวดล้อม เวอร์ชันภาษา เวอร์ชันไลบรารี สภาพแวดล้อมรันไทม์

พร้อมท์คำอธิบายข้อผิดพลาดที่มีประสิทธิภาพ: "ฉันกำลังแก้ไขจุดบกพร่อง ข้อมูล: - สิ่งที่ฉันพยายามทำ: [X] - พฤติกรรมที่คาดหวัง: [Y] - พฤติกรรมจริง: [Z] - ข้อความแสดงข้อผิดพลาดแบบเต็มและการติดตามสแต็ก: [วาง] - สภาพแวดล้อม: [ภาษา/เวอร์ชัน, ไลบรารี/เวอร์ชัน] - รหัสขั้นต่ำที่เกี่ยวข้อง: [รหัส] อย่าให้การแก้ไขโดยตรงแก่ฉัน ขั้นแรกให้ระบุสาเหตุที่แท้จริง 3 ประการที่เป็นไปได้มากที่สุดตามลำดับความน่าจะเป็น และบอกฉันว่าการตรวจสอบใดเพื่อตรวจสอบสำหรับแต่ละรายการ"

การไหลที่แคบลงตามสมมติฐาน

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

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

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

เคล็ดลับ: หากคุณไม่สามารถแก้ไขข้อผิดพลาดได้ ปัญหาส่วนใหญ่อยู่ที่ที่คุณสันนิษฐานไว้อย่างไม่ถูกต้อง ถาม AI ว่า “สมมติฐานของฉันมีอะไรบ้างที่อาจผิด” การถามจะทำลายตาบอดของคุณ ข้อผิดพลาดที่ยากที่สุดซ่อนอยู่ในจุดที่คุณพูดว่า "ฉันแน่ใจว่านี่ได้ผล"

พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง

อ่อนแอ: "รหัสของฉันแสดงข้อผิดพลาด โปรดแก้ไข: [โค้ด 200 บรรทัด]" (ผลลัพธ์: AI ไม่ทราบว่ามีข้อผิดพลาดอะไร สิ่งที่คาดหวังไว้ มันให้คำแนะนำทั่วไปตามการคาดเดา ซึ่งส่วนใหญ่ไร้ประโยชน์) แข็งแกร่ง: "ฉันได้รับ NullPointerException คาดว่า: ควรส่งคืนรายชื่อผู้ใช้ จริง: ระเบิดเมื่อมีการเรียกไปยัง getUsers () การติดตามสแต็ก: [วาง] สภาพแวดล้อม: Java 17 การทำซ้ำขั้นต่ำ: มันเกิดขึ้นเมื่อรายชื่อผู้ใช้เป็น ว่างเปล่า แต่ไม่ใช่เมื่อเต็ม 15 บรรทัดที่เกี่ยวข้อง: [รหัส] อธิบายสาเหตุที่แท้จริงและเหตุใดจึงเรียกใช้รายการว่าง จากนั้นแนะนำการแก้ไข"

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

การตรวจสอบการแก้ไข

การแก้ไขจะเป็นการแก้ไขจริงเท่านั้นหากทำสามสิ่งต่อไปนี้:

การควบคุม

คำถาม

วิธีการตรวจสอบ

ข้อผิดพลาดหายไปแล้วเหรอ?

รายการเดียวกันใช้งานได้ตอนนี้หรือไม่

เรียกใช้การทำซ้ำขั้นต่ำอีกครั้ง

ไม่มีข้อผิดพลาดใหม่?

มีอะไรเสียหายอีกไหม?

เรียกใช้ชุดทดสอบทั้งหมด

มันจะไม่ทำซ้ำเหรอ?

ข้อผิดพลาดเดียวกันนี้จะเกิดขึ้นอีกหรือไม่?

เพิ่มการทดสอบการถดถอยสำหรับสถานการณ์นี้

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

เคสมินิ

กรณีที่ 1 — กับดักปราบปรามอาการ ทีมปิดเสียงข้อผิดพลาด null เป็นครั้งคราวด้วย try-catch ข้อผิดพลาดหายไปแต่หลังจากผ่านไป 2 สัปดาห์ข้อมูลก็หายไป เหตุผลที่แท้จริงก็คือบริการส่งคืนค่าว่างเมื่อหมดเวลา เมื่อคุณถาม AI ว่า "ทำไมมันถึงเป็นโมฆะ" สาเหตุที่แท้จริงก็จะปรากฏขึ้น การแก้ไขจริงใช้เวลา 1 ชั่วโมงแต่จะคงอยู่ถาวร

กรณีที่ 2 — กำลังการทำซ้ำน้อยที่สุด นักพัฒนาซอฟต์แวร์ไม่สามารถแก้ไขข้อบกพร่องที่ระบุว่า "ระบบขัดข้องเป็นครั้งคราว" จะช่วยลดข้อผิดพลาดให้เหลือน้อยที่สุดตามคำแนะนำของ AI: ปัญหาเกิดขึ้นกับชื่อไฟล์ที่มีอักขระภาษาตุรกีเท่านั้น (ข้อผิดพลาดในการเข้ารหัส) เมื่อความไม่แน่นอน 300 เส้นลดลงเหลือ 5 บรรทัดของการจำลองขั้นสุดท้าย วิธีแก้ปัญหาก็จะชัดเจน

กรณีที่ 3 — การทดสอบการต่อต้านการถดถอย AI แก้ไขข้อผิดพลาดในการคำนวณวันที่ วิศวกรไม่พอใจกับสิ่งนี้ เพิ่มการทดสอบการถดถอยสำหรับสถานการณ์ที่ผิดพลาด (สิ้นเดือน 31 มกราคม + 1 เดือน) เมื่อการเปลี่ยนแปลงอื่นสัมผัสพื้นที่เดียวกันในอีก 4 เดือนต่อมา การทดสอบจะเปลี่ยนเป็นสีแดงและตรวจพบข้อบกพร่องก่อนที่จะถึงการใช้งานจริง

ข้อผิดพลาดทั่วไป

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

โดยสรุป

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

งานสมัคร

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

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

• [ ] ฉันชี้แจงอาการว่า "คาดหวัง VS ตระหนัก"
• [ ] ฉันแจ้งข้อความแสดงข้อผิดพลาดทั้งหมดและ Stack Trace ให้กับ AI
• [ ] ฉันลดข้อผิดพลาดลงเหลือน้อยที่สุด
• [ ] โดยการทดสอบสมมติฐานทีละข้อ ฉันพบสาเหตุที่แท้จริง
• [ ] แทนที่จะระงับอาการ ฉันแก้ไขที่ต้นเหตุแทน
• [ ] ฉันได้เพิ่มและรันการทดสอบการถดถอยเพื่อหาข้อผิดพลาดเดียวกัน