รับเอาสามสัญชาตญาณของผู้ปฏิบัติงาน คือ ตรวจสอบเทียบกับเอกสารทางการ ทดสอบด้วยตัวเอง ล่าหาสัญญาณการเพ้อเจ้อ ก่อนจะนำอะไรไปรวมเข้ากับงาน
เปิดบทเรียนนี้ใน Kodokonการเพ้อเจ้อ (hallucination) ไม่ใช่คำตอบที่ไร้สาระ แต่คือคำตอบที่ดูน่าเชื่อถือแต่ผิด เมธอดที่น่าจะมีอยู่แต่ไม่มี ตัวเลือกที่ถูกเปลี่ยนชื่อไปเมื่อสองเวอร์ชันก่อน พฤติกรรมเริ่มต้นที่ถูกกลับด้าน นั่นแหละคือสิ่งที่ทำให้นักพัฒนาผู้มีฝีมือเปราะบาง: โค้ดที่เพ้อขึ้นมานั้นดูเป็นสำนวนที่ถูกต้อง ตั้งชื่อดี สอดคล้องกับระบบนิเวศ มันดูถูกต้อง สามสัญชาตญาณที่ต่อรองไม่ได้ก่อนจะนำอะไรไปรวมเข้ากับงาน: ตรวจสอบเทียบกับเอกสารทางการของเวอร์ชันที่คุณใช้ ทดสอบโค้ดด้วยตัวเองในบริบทขั้นต่ำ และให้ตรวจสอบคำตอบ รวมถึงโดยตัวโมเดลเอง
เอาคำตอบก่อนหน้าของคุณมาตรวจสอบเสมือนว่ามันมาจากคนอื่น
1. ระบุทุกข้อกล่าวอ้างทางเทคนิคที่พิสูจน์ได้: ชื่อ API หรือฟังก์ชัน, พฤติกรรมที่บรรยายไว้, ค่าเริ่มต้น, หมายเลขเวอร์ชัน
2. สำหรับแต่ละข้อ ให้ระดับความมั่นใจของคุณ: แน่นอน / น่าจะใช่ / ต้องพิสูจน์
3. สำหรับทุกข้อ "ต้องพิสูจน์" ให้ระบุให้ชัดว่าต้องไปค้นหาอะไรในเอกสารทางการ: ชื่อของหน้า, ฟังก์ชัน หรือโมดูลที่เกี่ยวข้อง
4. เตือนสิ่งใดก็ตามที่อาจขึ้นอยู่กับเวอร์ชันหรือแพลตฟอร์ม โดยระบุว่าใช้ได้ตั้งแต่เวอร์ชันไหนถ้าคุณรู้
จงเข้มงวดกับตัวเองมากกว่าที่ผมจะเป็น: ข้อกล่าวอ้างที่ประเมินเกินจริงว่า "แน่นอน" ทำให้ผมเสียหายมากกว่าข้อที่ประเมินต่ำไปการตรวจสอบตัวเองนี้ไม่ได้พิสูจน์อะไร โมเดลอาจมั่นใจแล้วผิดได้ แต่มันเปลี่ยนร้อยแก้วที่ลื่นไหลให้เป็นรายการข้อเท็จจริงที่พิสูจน์ได้ แต่ละข้อพร้อมจุดเข้าสู่เอกสาร คุณคือคนที่พิสูจน์ AI แค่เตรียมพื้นไว้ให้ จงเรียนรู้ที่จะจับธงแดงด้วย: API ที่ตัดมาพอดีกับความต้องการของคุณเป๊ะ ๆ (ดีเกินจริง) การผสมธรรมเนียมจากคนละเวอร์ชันในสนิปเพตเดียวกัน ความมั่นใจที่สม่ำเสมอเป็นเนื้อเดียวอย่างสมบูรณ์แบบ ความเชี่ยวชาญจริงจะพูดว่า "มันขึ้นอยู่กับ" ส่วนการเพ้อเจ้อไม่เคยพูดแบบนั้น และการไม่เอ่ยถึงข้อจำกัดหรือกรณีขอบใด ๆ เลย ไม่มีสัญญาณเดี่ยว ๆ อันไหนเป็นข้อพิสูจน์ แต่แต่ละอันควรกระตุ้นให้เกิดการพิสูจน์
คุณเพิ่งกล่าวอ้างว่า [ข้อกล่าวอ้างที่เจาะจงซึ่งต้องพิสูจน์].
1. ช่วยผมออกแบบการทดสอบที่สั้นที่สุดเท่าที่จะเป็นไปได้เพื่อพิสูจน์มันด้วยตัวเอง: ไฟล์ขั้นต่ำที่ต้องสร้าง, คำสั่งที่ต้องรันแบบเป๊ะ ๆ, ผลลัพธ์ที่ผมควรสังเกตเห็นถ้าคุณถูก และผมจะเห็นอะไรแทนถ้าคุณผิด
2. จากนั้นเล่นบททนายของฝ่ายมาร: ในกรณีใดที่ข้อกล่าวอ้างของคุณจะเป็นเท็จ? เวอร์ชัน, แพลตฟอร์ม, การตั้งค่า, strict mode หรือไม่ ให้ไล่ดูให้หมด
ผมจะรันการทดสอบเอง: อย่าขอให้ผมเชื่อคำพูดของคุณ ให้เครื่องมือที่ใช้แย้งคุณแก่ผมพรอมต์นี้นำหลักการทางวิทยาศาสตร์มาใช้กับงานประจำวัน: ข้อกล่าวอ้างมีค่าเมื่อมันพิสูจน์ผิดได้ เมื่อคุณรู้ว่าคุณจะสังเกตเห็นอะไรหากมันกลายเป็นเท็จ สิบบรรทัดในไฟล์ที่โยนทิ้งได้และการรันหนึ่งครั้งชนะทุกระดับความมั่นใจที่ประกาศไว้ สำหรับการตรวจสอบเทียบกับเอกสาร มีสามนิสัย: พิสูจน์ในเอกสารของเวอร์ชันของคุณ (โมเดลผสมยุคต่าง ๆ ของ API อย่างสบายใจ) ตรวจบันทึกการเปลี่ยนแปลง (changelog) เมื่อพฤติกรรมดูเหมือนเปลี่ยนไป และเปิด REPL หรือไฟล์ทดลองไว้ตลอดเวลา ต้นทุนของการพิสูจน์ควรต่ำจนคุณไม่มีข้ออ้างที่จะข้ามขั้นตอนนี้