ทำไมกติกาการโต้ตอบถึงสำคัญเมื่อใช้ AI coding assistant
การใช้เครื่องมือ AI สำหรับการเขียนโค้ดคือการบอกผลลัพธ์ที่ต้องการให้ระบบช่วยเขียนและแก้โค้ดแทนเรา โดยเราต้องออกแบบคำสั่ง โครงสร้างขั้นตอน และวงจรการตรวจสอบให้ชัดเจน เครื่องมือจะทำงานเหมือนผู้ช่วยนักออกแบบที่ต้องได้รับบรีฟละเอียด มีขอบเขตหน้าที่ วิธีตรวจสอบ และช่องทางรับฟีดแบ็ก การกำหนดกติกาการโต้ตอบที่ดีช่วยให้โค้ดที่ได้มีความสม่ำเสมอ ลดข้อผิดพลาด และทำให้การทำงานร่วมกับ AI เป็นกระบวนการที่เชื่อถือได้ในโปรเจกต์จริง
ถ้าคุณกำลังทดลองใช้ AI coding assistant แก้บั๊ก ทำเลย์เอาต์ หรือออกแบบแต่ละฟีเจอร์ สิ่งที่ต้องเข้าใจก่อนคือ AI ไม่อ่านใจเรา มันอ่านคำอธิบายกับขั้นตอนที่เราเขียนเท่านั้น เครื่องมืออย่าง AI coding editor สามารถให้คุณบรรยายผลลัพธ์ที่ต้องการแล้วปล่อยให้มันจัดการเขียนและแก้ไขไฟล์ให้ แต่คุณต้องรักษาบทบาทของตัวเองให้เป็นเหมือนหัวหน้าทีม คือกำหนดกติกา ตรวจงาน และบันทึกความผิดพลาดรอบก่อน เพื่อไม่ให้ปัญหาเดิมกลับมาอีก
โครงสร้างบรีฟและขั้นตอนการเขียน AI agent ให้แม่นขึ้น
หัวใจของการใช้เครื่องมือ AI สำหรับการเขียนโค้ดให้แม่นคือการออกแบบขั้นตอนการเขียน AI agent ให้ชัดเจน ว่ามีสกิลอะไร ใช้เมื่อไร และรันอย่างไร สกิลหนึ่งสกิลคือโฟลเดอร์ที่มีไฟล์ SKILL.md อยู่ที่ราก ซึ่งบรรทัดส่วนหัวจะเก็บชื่อและคำอธิบาย ส่วนเนื้อไฟล์จะเก็บลำดับขั้นตอนของกระบวนการ คำอธิบายไม่ได้เขียนเอาสวย แต่มันทำหน้าที่เหมือนเครื่องคัดเลือกงาน เป็นตัวกำหนดว่าทาสก์แบบไหนถึงควรโหลดสกิลนี้มาใช้ เพราะเป็นส่วนเดียวที่ agent เห็นก่อนตัดสินใจ
ข้อผิดพลาดที่เจอบ่อยคือคำอธิบายบอกแค่สกิลคืออะไร แต่ไม่บอกคำที่ผู้ใช้จะพิมพ์จริงๆ ทำให้สกิลไม่ถูกเรียกใช้ อีกอย่างคือการเขียน SKILL.md ยืดเยื้อเต็มไปด้วยบทนำ สถาปัตยกรรม เหตุผล และรายการอ่านเพิ่ม ทั้งหมดนี้กินคอนเท็กซ์โดยไม่ช่วยให้รันงานได้ดีขึ้น ผู้เขียนที่มีประสบการณ์จะจัดเนื้อหาให้เหลือแค่ขั้นตอน เงื่อนไข และคำสั่งที่ทุกครั้งต้องใช้เท่านั้น เพราะ SKILL.md ถูกโหลดทุกครั้งที่สกิลทำงาน จึงต้องถือข้อมูลที่จำเป็นต่อทุกการรันและไม่มีส่วนเกิน
ขั้นตอนทีละข้อ วิธีคุยกับ AI coding assistant ให้ได้ผลผลิตระดับโปรดักชัน
ตัวอย่างจากการใช้ AI coding editor แก้เลย์เอาต์เว็บไซต์เล็กๆ ชี้ให้เห็นว่า การขอให้แก้ทีละบั๊กแยกกันทำให้เกิดอาการแพตช์ซ้อน เช่นหัวข้อไม่กระดิกแล้ว แต่หน้ากลับกระโดดอีกครั้ง Breadcrumb จากการเลื่อนนุ่มนวลกลับกลายเป็นการเด้งแข็งๆ จุดเปลี่ยนเกิดขึ้นเมื่อหยุดขอให้แก้เฉพาะจุด และเริ่มเขียนการเคลื่อนไหวที่ต้องการแบบภาษาธรรมดา พร้อมกำหนดสัญญาว่าหน้าเว็บควรลงจอดตรงไหน เคลื่อนอย่างไร และอะไรห้ามขยับ
- นิยามอินเทอร์แอ็กชันเป็นภาษาธรรมดา เช่น ต้องลงจอดที่ขอบบนของเซกชัน ชดเชยความสูงของ sticky header เคลื่อนแบบเลื่อนครั้งเดียว และไม่มีการกระโดดรอบสอง
- ระบุชัดเจนว่าห้ามพยายามพาผู้ใช้กลับไปที่พิกเซลเดิมที่เคยอยู่ เพื่อหลีกเลี่ยงอาการหน้าเด้งหรือการเคลื่อนที่ซ้ำ
- กำชับให้ตรวจผลงานในเบราว์เซอร์จริง ไม่พอใจแค่พรีวิวในเอดิเตอร์ และยืนยันว่าจะใช้แนวทางที่เคยพิสูจน์แล้วว่าใช้งานได้ดีในเบราว์เซอร์
- เลือกโมเดลที่เหมาะกับงานเชิงพื้นที่ และเก็บลิสต์ข้อผิดพลาดรอบก่อนเอาไว้ เพื่อให้รอบถัดไปหลีกเลี่ยงการทำผิดแบบเดิม
- เขียนบันทึกข้อกำหนดเหล่านี้ไว้ในโน้ตของโปรเจกต์ แล้วกำหนดว่าผู้ช่วยต้องอ่านก่อนเริ่มแก้ เพื่อให้ทุกการรันใช้กติกาเดียวกัน
เมื่อมีกรอบนี้แล้ว ผู้ช่วยหยุดการแก้ด้วยแพตช์สะสม และหน้าเริ่มทำตัวเหมือนเว็บพร้อมใช้งานในโปรดักชัน หากคุณเพิ่งเริ่มใช้ AI coding assistant หลักสำคัญคือบรีฟเหมือนบรีฟนักออกแบบ ระบุว่าตาและเคอร์เซอร์ควรหยุดที่ไหน อะไรต้องอยู่กับที่ และคุณจะแยกแยะความล้มเหลวยังไง เช่นการกระโดดช้า หัวข้อหลบเข้าใต้แถบนำทาง หรือปุ่มย้อนกลับที่พาผู้ใช้ไปไพ่การ์ดแบบสุ่ม
ออกแบบสคริปต์และวงจรการตรวจสอบโค้ด AI ให้เชื่อถือได้
ในขั้นตอนการเขียน AI agent สิ่งสำคัญคือแยกสิ่งที่เป็นลำดับแน่นอนออกจากสิ่งที่ต้องใช้การตัดสินใจ สคริปต์ควรรับหน้าที่ทำงานที่เป็นขั้นตอนตายตัว เช่นการยืนยันตัวตนหรือเรียก API ส่วน agent รับงานที่ต้องใช้วิจารณญาณ เช่นตัดสินว่าเมื่อไหร่ควรยกเลิกรีลีส หรือเขียนโน้ตในน้ำเสียงของโปรเจกต์ ตัวอย่างลำดับที่ดีคือ 1 รันสคริปต์ตรวจพร้อมใช้งาน และถ้าล้มเหลวให้เปิดอ่านคู่มือแก้ไข 2 ปรับเวอร์ชัน แท็กคอมมิต และดันแท็กขึ้น 3 เฝ้าดูระบบ CI หากเช็คข้อใดแดงให้ตัดสินใจว่าควรหยุดการรีลีสหรือไม่
การออกแบบให้มีขั้นตรวจสอบตั้งแต่ต้น มีการตรวจอินพุตก่อนทำงานแพง มีเกตเช็กพรรีเควสิต และคำสั่งเดียวที่โค้ดออกจากคำสั่งตัดสินใจว่าขั้นตอนถัดไปจะรันหรือไม่ ช่วยให้สกิลทำงานได้สม่ำเสมอ นอกจากนี้ SKILL.md ควรเก็บเฉพาะขั้นตอน เงื่อนไข และคำสั่งที่ทุกครั้งต้องใช้ เพราะไฟล์นี้ถูกโหลดทุกครั้งและกินคอนเท็กซ์ก่อน agent จะได้อ่านไฟล์งานจริง การออกแบบแบบนี้ทำให้สกิลที่ใช้ทุกวัน เช่นสกิลรีลีสโค้ดหรือสกิลจัดการพีอาร์ ขับเคลื่อนเป็นชุดคำสั่งที่ชัดเจน และปล่อยให้ agent เติมการตัดสินใจในจุดที่จำเป็น
สร้างวงจรฟีดแบ็กและการตรวจสอบโค้ด AI ก่อนนำขึ้นโปรดักชัน
การตรวจสอบโค้ด AI ไม่ควรจบแค่การรันครั้งเดียวแล้วเชื่อผลลัพธ์ วงจรที่ดีจะรวมทั้งการทดสอบบนเบราว์เซอร์จริง การจดจำข้อผิดพลาดเก่า และการส่งฟีดแบ็กกลับเข้าโครงสร้างสกิลเสมอ ผู้ใช้ที่ทำเลย์เอาต์เว็บด้วย AI coding assistant พบว่าการยืนยันให้ตรวจงานบนเบราว์เซอร์จริงแทนการดูพรีวิวในเอดิเตอร์ ทำให้เห็นปัญหาการเคลื่อนไหวและการกระโดดของหน้าได้ชัดขึ้น และควรเลือกรูปแบบที่พิสูจน์แล้วว่าใช้งานได้ดีในเบราว์เซอร์ พร้อมปฏิเสธการแก้ไขที่ไม่จำเป็น
ในระดับสกิลของ AI agent หลักการหนึ่งที่น่าใช้คือการสร้าง human feedback loop โดยให้สกิลจบงานด้วยการรายงานแรงเสียดทานหรือข้อขัดข้องย้อนกลับขึ้นไป เมื่อใช้งานได้ผล สกิลจะเปลี่ยนจากลูปธรรมดาไปเป็น flywheel คือทุกการรันสร้างฟีดแบ็ก ฟีดแบ็กกลายเป็นพีอาร์หรืออีชชู่ และสกิลดีขึ้นแม้ผู้เขียนยังไม่ได้กลับมาปรับแก้ด้วยตัวเอง การพัฒนาสกิลซ้ำแบบนี้ รวมกับการจดลิสต์ข้อผิดพลาดที่ผ่านมาเพื่อไม่ให้ทำผิดซ้ำ ทำให้เครื่องมือ AI สำหรับการเขียนโค้ดเรียนรู้จากความล้มเหลว และสร้างโค้ดที่เสถียรกว่าเดิมเรื่อยๆ
