1. จัดทำและบังคับใช้เอกสาร Standard Operating Procedure (SOP) ก่อนเริ่มงานทุกครั้ง
ควรมีเอกสาร SOP ที่ระบุรูปแบบของการเขียนโค้ด กระบวนการ commit แนวทางการทดสอบ รวมถึงขอบเขตและข้อจำกัดของ LLM จากนั้นให้ LLM อ่านและรับทราบก่อนเริ่มทำงานในแต่ละเซสชัน เพื่อให้การทำงานเป็นไปตามมาตรฐานที่กำหนดอย่างสม่ำเสมอ
https://checkeagle.com/checklists/njr/sop-guidelines
.
2. ใช้ Plan Mode สำหรับงานที่มีความซับซ้อน
สำหรับงานที่ไม่ใช่การแก้ไขเล็กน้อย ควรให้ LLM เสนอแผนการทำงานเป็นลายลักษณ์อักษร พร้อมเปิดโอกาสให้ซักถามหรือขอคำชี้แจงก่อนลงมือแก้ไขโค้ด การอนุมัติแผนจากผู้ใช้ควรเป็นขั้นตอนบังคับก่อนเริ่มดำเนินการจริง
.
3. ควบคุมการใช้ token และบริหาร context อย่างเป็นระบบ
ควรกำหนดงบประมาณของ token ตรวจสอบสถานะด้วยคำสั่ง /context เป็นระยะ และป้องกันไม่ให้เกิด compactification โดยจัดเตรียมขั้นตอนสำรอง เช่น /dump และ /export เพื่อสามารถกู้กลับสู่สถานะเดิมได้หากจำเป็น
.
4. กำหนดขอบเขตสิทธิ์การทำงานของ LLM อย่างรัดกุม
ไม่ควรให้ LLM ทำงานในบัญชีที่มีสิทธิ์ระดับสูง หรือมีสิทธิ์เข้าถึงระบบ production ควรแยกบัญชีสำหรับการใช้งาน LLM โดยเฉพาะ รวมทั้งจำกัด environment variables และคีย์ต่าง ๆ เพื่อป้องกันความเสี่ยงด้านความปลอดภัย
.
5. บังคับใช้รูปแบบโค้ดด้วยตัวอย่างและมาตรฐานภายในโปรเจค (Pattern Patching)
ก่อนเริ่มงาน ให้ LLM อ่านตัวอย่างโค้ด โครงสร้างระบบ และเทสต์ที่มีคุณภาพในโปรเจค (เราเป็นคนเขียนเริ่มต้น) เพื่อช่วยปรับรูปแบบการเขียนโค้ดให้เป็นไปในทิศทางเดียวกัน ลดการเขียนโค้ดซ้ำซ้อนหรือผิดรูปแบบ
.
6. ห้ามให้ LLM แก้ไขเทสต์โดยพลการ
เมื่อเทสต์ล้มเหลว ควรตรวจสอบและแก้ไขสาเหตุที่เกิดจากโค้ดก่อน ไม่ใช่ให้ LLM ปรับเทสต์เพื่อให้ผ่าน การกำหนดนโยบายนี้จะช่วยให้เทสต์ยังคงตรวจสอบพฤติกรรมที่ถูกต้องของระบบได้อย่างมีประสิทธิภาพ
.
7. ตรวจสอบและทบทวนโค้ดอย่างละเอียดก่อน commit หรือ deploy
ทุกรายการแก้ไขต้องมีการแสดงผล diff หลักฐานการรันเทสต์ และผลการทดสอบที่ยืนยันความถูกต้อง โดยต้องได้รับการอนุมัติจากผู้ใช้ก่อน commit ห้ามให้ LLM ทำ commit อัตโนมัติโดยไม่ได้รับอนุญาต
.
8. จัดเตรียมกระบวนการสำหรับการ refactor และการแยกไฟล์อย่างมีระบบ
เมื่อมีงานปรับปรุงโครงสร้างไฟล์หรือแยกโมดูล ควรออกแบบกระบวนการเป็นขั้นตอนย่อย ๆ และให้ LLM ดำเนินการตามแผนทีละส่วน เพื่อป้องกันข้อผิดพลาดจากการแก้ไขไฟล์จำนวนมากในครั้งเดียว
.
9. ใช้ LLM เป็นผู้ช่วยด้านรายละเอียด ไม่ใช่ผู้ตัดสินใจหลักทางสถาปัตยกรรม
ควรให้มนุษย์เป็นผู้กำหนดโครงสร้างระบบ สถาปัตยกรรม และนโยบายทางเทคนิค แล้วให้ LLM ช่วยเติมเต็มรายละเอียด เขียนโค้ดตามแบบแผน หรือสร้างเทสต์เพิ่มเติม เพื่อให้คุณภาพของงานดีขึ้นและลดความผิดพลาด
.
10. เก็บบันทึกบทเรียนและปรับปรุง SOP อย่างต่อเนื่อง
ควรบันทึกปัญหาและข้อผิดพลาดที่เกิดขึ้นซ้ำ ๆ เพื่อปรับปรุง SOP และคำสั่งต่าง ๆ ให้มีความสมบูรณ์มากขึ้น ช่วยให้การทำงานร่วมกับ LLM มีความเสถียรและมีประสิทธิภาพในระยะยาว