การดีบักและการวิเคราะห์สาเหตุที่แท้จริง

กำไร:

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

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

ในหน่วยนี้ เราสร้างขั้นตอนที่มีระเบียบวินัยตั้งแต่การสร้างข้อผิดพลาดไปจนถึงสาเหตุที่แท้จริง: การชี้แจงอาการ การรวบรวมหลักฐาน (ข้อความแสดงข้อผิดพลาด การติดตามสแต็ก บันทึก การป้อนข้อมูล) การสร้างสมมติฐาน การทดสอบสมมติฐาน และตรวจสอบความถูกต้องของการแก้ไข AI ช่วยในทุกขั้นตอน แต่การตัดสินใจแบบ "คงที่" นั้นเกิดจากการเห็นว่าจุดบกพร่องนั้นหายไปแล้วจริงๆ

ทำไมหลักฐานจึงเป็นทุกสิ่งทุกอย่าง?

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

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

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

ทีละขั้นตอน: ขั้นตอนการวิเคราะห์สาเหตุที่แท้จริง

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

มินิเคสสามอัน

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

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

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

เทมเพลตที่คัดลอกได้สี่แบบ

การสร้างสมมติฐานตามหลักฐาน:

ฉันกำลังแก้ไขจุดบกพร่อง หลักฐานด้านล่าง- ลักษณะการทำงานที่คาดไว้: {{expected}}- ลักษณะการทำงานที่สังเกตได้: {{observed}}- ข้อความแสดงข้อผิดพลาด / การติดตามสแต็ก: {{trace}}- อินพุตที่ทริกเกอร์: {{input}}- สภาพแวดล้อม/เวอร์ชัน: {{version}}แสดงรายการสาเหตุหลัก 3 ประการที่ LIKELY มากที่สุดที่อธิบายอาการนี้ สำหรับแต่ละข้อ: ฉันจะทดสอบได้อย่างไร (ตรวจสอบที่ถูกที่สุด) และจะแก้ไขอย่างไรหากเป็นจริง หากหลักฐานไม่เพียงพอ โปรดบอกฉันว่าคุณต้องการข้อมูลเพิ่มเติมอะไรบ้าง

การตีความการติดตามสแต็ก:

อ่านการติดตามสแต็กนี้ แยกแยะระหว่างบรรทัดที่ข้อผิดพลาดน่าจะเริ่มต้นที่ (รูท) และบรรทัดใดที่เป็นเพียงความต่อเนื่องของห่วงโซ่ แนะนำสถานที่ดูก่อน 1-2 แห่ง รหัสที่เกี่ยวข้อง:{{code}}การติดตาม:{{trace}}

การลบการทำซ้ำขั้นต่ำ:

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

การตรวจสอบหลังการแก้ไขและการทดสอบการถดถอย:

สมมติว่าสาเหตุที่แท้จริงคือ {{cause}} และฉันทำการแก้ไขต่อไปนี้: {{fix}}.1) การแก้ไขนี้ช่วยแก้ไขอาการได้จริงหรือไม่ และจะมีผลข้างเคียงหรือไม่2) เขียนการทดสอบการถดถอยที่จะตรวจพบจุดบกพร่องนี้ในอนาคต

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

อ่อนแอ: "รหัสใช้งานไม่ได้ เพราะเหตุใด"

Strong: "Node 20 / Express POST /orders ส่งคืน 500 เมื่อรายการเป็นสตริงว่างในร่างกาย ควรส่งคืน 400 การติดตามสแต็ก: TypeError: ไม่สามารถอ่านคุณสมบัติของที่ไม่ได้กำหนด (อ่าน '0') - สิ่งที่แนบมาคือการติดตามแบบเต็มและตัวจัดการที่เกี่ยวข้อง ให้ฉัน 3 สาเหตุที่เป็นไปได้มากที่สุดที่อธิบายอาการนี้และวิธีการทดสอบแต่ละรายการ [ติดตาม + รหัส]"

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

ขั้นตอน

การมีส่วนร่วมของ AI

การควบคุมของคุณ

การรวบรวมหลักฐาน

ต้องใช้หลักฐานอะไรเตือนใจ

รวบรวมหลักฐานจริงๆ

การสร้างสมมติฐาน

ระบุเหตุผลที่เป็นไปได้

จัดลำดับความสำคัญตามบริบท

การทดสอบสมมติฐาน

แนะนำวิธีทดสอบ

ดำเนินการและสังเกตเป็นการส่วนตัว

การแก้ไข

แพทช์แนะนำ

มันแก้ปัญหาที่ต้นเหตุได้หรือไม่? มันเป็นเรื่องจริง

การถดถอย

เขียนแบบทดสอบ

ตรวจสอบว่าการทดสอบเสียหาย

การแก้ปัญหาที่ต้นเหตุ ไม่ใช่ที่อาการ

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

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

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

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

โดยสรุป

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

งานสมัคร

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

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

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