Playbook วิศวกรรมพรอมป์สำหรับโปรแกรมเมอร์

• ผู้ช่วยเขียนโค้ด AI ไม่สามารถรู้เจตนาของโปรเจกต์ได้เอง ดังนั้นคุณภาพของผลลัพธ์จึงขึ้นอยู่กับว่านักพัฒนาให้ บริบท·เป้าหมาย·ตัวอย่าง ได้ดีเพียงใดเป็นอย่างมาก
• ในการดีบัก แทนที่จะโยนแค่โค้ดกับข้อผิดพลาดให้ ควรให้พฤติกรรมที่คาดหวัง พฤติกรรมจริง และสภาพแวดล้อมการรันไปพร้อมกัน และต้องจำกัดขอบเขตปัญหาด้วย การไล่ติดตามทีละบรรทัด หรือตัวอย่างที่ทำให้เกิดซ้ำได้ขั้นต่ำ
• การรีแฟกเตอร์และการปรับแต่งประสิทธิภาพไม่ควรบอกแค่ว่า “ทำให้ดีขึ้น” แต่ต้องระบุ เกณฑ์ความสำเร็จ ให้ชัดเจน เช่น การลบโค้ดซ้ำ การประมวลผลแบบขนาน การคงการจัดการข้อผิดพลาดไว้ หรือข้อจำกัดด้านเวอร์ชัน
• การพัฒนาฟีเจอร์ใหม่ ปลอดภัยกว่าหากไม่มอบหมายทั้งหมดในครั้งเดียว แต่แบ่งเป็น ขั้นตอนเล็กๆ เช่น แผน โครงร่าง การจัดการสถานะ การเชื่อมต่อ API และ edge case แล้วตรวจทานพร้อมขยายต่อไป
• คำถามที่กำกวม ความต้องการที่มากเกินไป การ dump โค้ดโดยไม่มีคำถาม และการอ้างอิงที่ไม่ชัดเจนทำให้ผลลัพธ์ไม่นิ่ง และควรปฏิบัติกับ AI ในฐานะ pair programmer แบบสนทนาซ้ำไปมา มากกว่าเครื่องสร้างคำตอบครั้งเดียว

---

หลักการพื้นฐานในการใช้ผู้ช่วยเขียนโค้ด AI ให้ได้ผลดี

• ผู้ช่วยเขียนโค้ด AI สามารถช่วยได้ตั้งแต่การเติมฟังก์ชันอัตโนมัติ การเสนอวิธีแก้บั๊ก ไปจนถึงการสร้างโมดูลหรือ MVP แต่เจตนาเฉพาะของโปรเจกต์ขึ้นอยู่กับข้อมูลที่ผู้ใช้ให้มา
• พรอมป์ที่ดีควรมอง AI เป็นเหมือน “ผู้ร่วมงานที่ตีความตามตัวอักษร” และชี้แนะผลลัพธ์กับรูปแบบที่ต้องการอย่างชัดเจน
• หลักการพื้นฐานมีดังนี้
  • ให้บริบทอย่างครบถ้วน: รวมภาษา เฟรมเวิร์ก ไลบรารี ฟังก์ชันหรือชิ้นโค้ดที่เกี่ยวข้อง ข้อความข้อผิดพลาดที่ถูกต้อง และพฤติกรรมที่คาดหวัง
  • ทำเป้าหมายให้เฉพาะเจาะจง: จำกัดคำถามให้แคบลง เช่น แทนที่จะถามว่า “ทำไมใช้ไม่ได้?” ให้ถามว่า “เหตุใดฟังก์ชัน JavaScript นี้จึงคืนค่า undefined แทนค่าที่คาดไว้ และจะแก้อย่างไร”
  • แยกงานซับซ้อนออกเป็นส่วนย่อย: ไม่ขอฟีเจอร์ใหญ่ทั้งหมดในครั้งเดียว แต่ดำเนินการตามลำดับ เช่น สร้างโครงร่าง React component เพิ่มการจัดการสถานะ และรวมการเรียก API
  • ให้ตัวอย่างอินพุต/เอาต์พุต: ตัวอย่างอย่างอินพุต [3,1,4] ต้องคืนค่า [1,3,4] ช่วยลดความกำกวมของข้อกำหนด
  • กำหนดบทบาท: หากให้บทบาท เช่น “senior React developer”, “JavaScript performance expert”, “code reviewer” จะช่วยปรับความลึกและสไตล์ของคำตอบได้
  • ทำซ้ำและแก้ไข: หากคำตอบแรกยังไม่ถูกต้อง ให้ปรับทิศทางด้วยคำขอต่อเนื่อง เช่น ใช้ลูปแทน recursion ปรับปรุงชื่อ变量 หรือเพิ่มคอมเมนต์
  • รักษาความชัดเจนของโค้ด: ชื่อฟังก์ชันและชื่อตัวแปรที่มีความหมาย รูปแบบที่สม่ำเสมอ คอมเมนต์และ docstring เป็นเบาะแสให้ AI เข้าใจเจตนาของโค้ด

รูปแบบพรอมป์สำหรับการดีบัก

• คำขอดีบักควรมีทั้งโค้ดนั้นควรทำอะไร สิ่งที่ผิดพลาดจริงคืออะไร และเกิดข้อผิดพลาดใดขึ้น
• พรอมป์ดีบักที่ดีมักประกอบด้วยข้อมูลต่อไปนี้
  • ภาษาที่ใช้และสภาพแวดล้อมการรัน
  • โค้ดที่มีปัญหา
  • ข้อความข้อผิดพลาดที่ถูกต้อง หรือเอาต์พุตที่ผิด
  • เอาต์พุตที่คาดหวัง
  • อินพุตตัวอย่าง
  • วิธีที่ลองไปแล้ว
• สำหรับบั๊กในลอจิกที่ซับซ้อน สามารถขอให้ AI ไล่ติดตามการทำงานทีละบรรทัด เพื่อให้ติดตามการเปลี่ยนแปลงของสถานะได้
  • ตัวอย่าง: “ช่วยติดตามว่าค่า total ในฟังก์ชันนี้เปลี่ยนไปอย่างไรในแต่ละขั้นตอน และหาว่าการสะสมค่าผิดตรงไหน”
• แม้ codebase จะใหญ่ หากสามารถทำชิ้นโค้ดเล็กๆ ที่ทำให้เกิดบั๊กซ้ำได้ ก็ควรนำเสนอเป็น ตัวอย่างที่ทำให้เกิดซ้ำได้ขั้นต่ำ
• หากคำตอบแรกมีประโยชน์เพียงบางส่วน สามารถถามต่อได้ เช่น “แสดงโค้ดที่แก้แล้วให้ดูหน่อย”, “อธิบายว่าการเปลี่ยนแปลงนี้แก้ปัญหาได้อย่างไร”

ตัวอย่างการดีบัก: คำถามกำกวมและคำถามที่ปรับปรุงแล้ว

• โค้ดตัวอย่างคือฟังก์ชัน Node.js/JavaScript mapUsersById(users) ที่พยายามแปลงอาร์เรย์ผู้ใช้ให้เป็นอ็อบเจ็กต์ตาม ID
• บั๊กคือ `for (let i = 0; i