Kodokon kodokon.com

การดีบักด้วย AI: เข้าใจก่อนแล้วค่อยแก้

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

8 นาที · 3 คำถาม

เปิดบทเรียนนี้ใน Kodokon

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

PROMPT
คุณคือนักพัฒนาระดับซีเนียร์ที่ช่วยให้ผมเก่งขึ้นในการดีบัก หน้าที่ของคุณคืออธิบาย ไม่ใช่แก้ปัญหาแทนผม

บริบท: [ภาษา + เวอร์ชัน, เฟรมเวิร์ก, โค้ดนี้ควรจะทำอะไร].
ข้อความแสดงข้อผิดพลาดฉบับเต็ม รวมถึงกองซ้อนการเรียก (call stack):
[วางข้อความแสดงข้อผิดพลาด]
โค้ดส่วนที่เกี่ยวข้อง (10 ถึง 30 บรรทัด):
[วางโค้ด]

งานของคุณ:
1. อธิบายข้อความแสดงข้อผิดพลาดทีละส่วน: มันกำลังบอกอะไรกันแน่ และมันไม่ได้บอกอะไร?
2. ระบุสาเหตุที่เป็นไปได้มากที่สุด 2 หรือ 3 ข้อในบริบทของผม เรียงจากที่เป็นไปได้มากที่สุดไปน้อยที่สุด
3. สำหรับแต่ละสาเหตุ เสนอวิธีตรวจสอบที่เป็นรูปธรรมที่ผมลงมือทำเองได้ (log เจาะจง, breakpoint, การทดสอบแบบแยกส่วน).

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

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

PROMPT
คุณคือโค้ชการดีบักของผม ใช้วิธีการแบบโสเครติสอย่างเคร่งครัด: คุณไม่ให้คำตอบเด็ดขาด คุณตั้งคำถาม

บั๊กของผม: [อาการที่สังเกตเห็น] ทั้งที่ผมคาดหวัง [พฤติกรรมที่คาดหวัง].
สิ่งที่ผมตรวจสอบไปแล้ว: [รายการ].

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

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

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

ทดสอบความรู้

ตรวจสอบว่าคุณจำประเด็นสำคัญของบทเรียนนี้ได้ครบถ้วน

  1. เมื่อเผชิญกับข้อความแสดงข้อผิดพลาด คำขอแบบใดที่เพิ่มการเรียนรู้ของคุณให้สูงสุด?
    • "แก้บั๊กนี้แล้วส่งโค้ดฉบับเต็มกลับมาให้ฉัน"
    • "อธิบายข้อความนี้ จัดอันดับสาเหตุที่เป็นไปได้ และเสนอวิธีตรวจสอบ โดยไม่ต้องแก้ให้"
    • "เขียนโมดูลนี้ใหม่ให้แข็งแกร่งขึ้น"
  2. ทำไมคุณจึงต้องห้ามการให้วิธีแก้อย่างชัดเจนในพรอมต์?
    • เพราะ AI คิดค่าบริการแพงกว่าสำหรับการแก้ปัญหา
    • เพราะโมเดลที่ถูกฝึกมาให้ช่วยเหลือจะไถลไปหาทางออกโดยอัตโนมัติ
    • เพราะ AI ไม่สามารถเขียนวิธีแก้ที่ถูกต้องได้
    • เพราะวิธีแก้ที่สร้างขึ้นมานั้นผิดเสมอ
  3. AI เสนอสาเหตุที่เป็นไปได้สำหรับบั๊กของคุณ คุณจะทำอย่างไร?
    • นำการเปลี่ยนแปลงที่เสนอมาใช้ตรง ๆ เลย
    • ขอสาเหตุที่สองมาเปรียบเทียบ
    • พิสูจน์สมมติฐานด้วยตัวเองด้วย log, breakpoint หรือการทดสอบแบบแยกส่วน