Agent เขียนโค้ดผิดสไตล์ทีมซ้ำทุกรอบ ทั้งที่บอกไปแล้วหลายครั้ง แก้ด้วย Agent Skills ยังไง

ทีมพัฒนาที่เริ่มใช้ Custom Instructions ไปสักพักมักเจอปัญหาเดียวกัน คือไฟล์ instructions เริ่มยาวขึ้นเรื่อย ๆ ตามจำนวนกฎที่อยากให้ Agent จำ จากที่เคยมีแค่ไม่กี่บรรทัดเรื่อง coding style กลายเป็นไฟล์ที่รวมทุกอย่างตั้งแต่วิธีเขียนเทสต์ วิธีตั้งชื่อตัวแปร ไปจนถึงขั้นตอนการทำ database migration แบบละเอียด

ปัญหาที่ตามมาคือ Agent ต้องอ่านบริบททั้งหมดนี้ทุกครั้งไม่ว่างานตรงหน้าจะเกี่ยวข้องกับส่วนไหนของไฟล์หรือไม่ ยิ่งไฟล์ยาว ยิ่งกินพื้นที่บริบทที่ควรเก็บไว้ให้โค้ดจริงที่กำลังทำงานอยู่ และบางครั้งกฎที่เขียนไว้เยอะเกินไปก็ทำให้ Agent 'หลงประเด็น' ทำตามกฎที่ไม่เกี่ยวกับงานตรงหน้าแทน

Agent Skills คือแนวทางที่เข้ามาตอบปัญหานี้ แทนที่จะยัดทุกอย่างไว้ในไฟล์เดียว ให้แยกความรู้เฉพาะทางออกเป็นชุดย่อยตามหัวข้อ แล้วให้ Agent เลือกดึงชุดที่เกี่ยวข้องมาใช้เฉพาะตอนที่งานตรงกับหัวข้อนั้นจริง บทความนี้จะพาดูว่าแนวคิดนี้ต่างจาก Custom Instructions ตรงไหน ควรออกแบบยังไง และใช้ตอนไหนถึงจะคุ้ม

ความต่างหลักของ Custom Instructions กับ Agent Skills

Custom Instructions (ไฟล์อย่าง `.github/copilot-instructions.md` หรือไฟล์ตั้งค่าระดับ repo ในลักษณะเดียวกัน) ทำงานแบบ 'โหลดเสมอ' คือทุกครั้งที่ Agent เริ่มงานในบริบทของ repo นั้น มันจะอ่านไฟล์นี้เป็นส่วนหนึ่งของบริบทตั้งต้นเสมอ ไม่ว่างานที่กำลังทำจะเกี่ยวอะไรกับเนื้อหาในไฟล์หรือไม่

Agent Skills ทำงานต่างออกไปคือแยกความรู้เป็นชุดที่มีชื่อและคำอธิบายของตัวเองชัดเจน (เช่น ชุด 'เขียน unit test สำหรับ API endpoint', ชุด 'ตรวจสอบ security ก่อน merge') แล้ว Agent จะพิจารณาจากคำอธิบายของแต่ละชุดว่างานตรงหน้าเกี่ยวข้องกับชุดไหน ก่อนจะดึงเนื้อหาเต็มของชุดนั้นเข้ามาในบริบทเฉพาะตอนที่จำเป็นเท่านั้น

ผลลัพธ์ที่ต่างกันชัดคือ Custom Instructions เหมาะกับกฎที่ 'ใช้ตลอด' เช่นภาษาที่ใช้เขียนโค้ด, รูปแบบการตั้งชื่อไฟล์, framework หลักที่ใช้ในโปรเจกต์ ส่วน Agent Skills เหมาะกับความรู้ที่ 'ใช้เฉพาะบางสถานการณ์' แต่ต้องการความละเอียดสูงตอนใช้จริง เช่นขั้นตอนการ migrate ฐานข้อมูลอย่างปลอดภัย หรือ checklist เฉพาะทางสำหรับ security review

ทำไม Agent ยังทำผิดสไตล์ทีมซ้ำ ทั้งที่เขียนกฎไว้ใน Instructions แล้ว

สาเหตุหลักที่พบบ่อยคือกฎที่เขียนไว้กว้างเกินไปและไม่มีตัวอย่างประกอบ เช่นเขียนแค่ว่า 'ใช้ functional component เท่านั้น' โดยไม่มีตัวอย่างโค้ดที่ถูกต้องให้ดู Agent ต้องตีความเองว่า 'functional component ที่ถูกต้องตามสไตล์ทีม' หน้าตาเป็นยังไง ซึ่งอาจตีความต่างจากที่ทีมตั้งใจ

อีกสาเหตุคือไฟล์ Instructions ยาวเกินไปจนกฎสำคัญถูกฝังอยู่กลางไฟล์ท่ามกลางกฎอื่นที่ไม่เกี่ยวข้องกับงานตรงหน้า ทำให้น้ำหนักความสำคัญของกฎแต่ละข้อไม่ชัดเจนพอในสายตาของโมเดล ยิ่งไฟล์ยาว ยิ่งมีความเสี่ยงที่กฎบางข้อจะถูกมองข้ามไปเมื่อบริบทของงานซับซ้อนขึ้น

การแก้ปัญหานี้ด้วย Agent Skills ทำได้โดยแยกกฎที่เจาะจงเรื่องสไตล์โค้ดออกมาเป็นชุดเฉพาะ พร้อมตัวอย่างโค้ดที่ถูกต้องและตัวอย่างที่ผิดเทียบกันชัดเจน แทนที่จะเขียนเป็นประโยคกว้าง ๆ ปนอยู่กับกฎอื่นเป็นสิบข้อในไฟล์เดียว เพราะเมื่อ Agent ดึงชุดนี้มาใช้เฉพาะตอนที่เกี่ยวข้อง มันจะโฟกัสกับตัวอย่างที่ชัดเจนแทนที่จะต้องแบ่งความสนใจไปกับกฎอื่นที่ไม่เกี่ยวกับงานตรงหน้า

โครงสร้างของชุด Skill หนึ่งชุดควรมีอะไรบ้าง

จุดที่ทีมมักพลาดตอนเริ่มเขียนชุด Skill ครั้งแรกคือเขียนคำอธิบายกว้างเกินไปจนซ้อนทับกับชุดอื่น เช่นมีทั้งชุด 'เขียนเทสต์' กับชุด 'เขียน unit test' ที่ความจริงคือเรื่องเดียวกัน ทำให้ Agent สับสนว่าควรดึงชุดไหนมาใช้ วิธีป้องกันคือตั้งชื่อและคำอธิบายให้เจาะจงและไม่ซ้ำซ้อนกันตั้งแต่แรก พร้อมทบทวนรายการชุดทั้งหมดเป็นระยะเมื่อทีมเพิ่มชุดใหม่

• ชื่อและคำอธิบายสั้น ๆ ที่บอกชัดว่าใช้ตอนไหน (ส่วนนี้สำคัญที่สุด เพราะ Agent ใช้ตัดสินใจว่าจะดึงชุดนี้มาใช้หรือไม่)
• บริบทหรือเงื่อนไขเบื้องต้นที่ต้องรู้ก่อนเริ่มงานตามชุดนี้
• ขั้นตอนหรือแนวทางที่ควรทำ เรียงลำดับชัดเจน
• ตัวอย่างที่ถูกต้องและตัวอย่างที่ผิดเทียบกัน (ถ้าเกี่ยวกับสไตล์โค้ด)
• ข้อยกเว้นหรือเงื่อนไขที่ไม่ควรใช้ชุดนี้
• ไฟล์หรือ script เสริมที่ Agent เรียกรันได้ถ้าจำเป็น (สำหรับงานที่มีขั้นตอนอัตโนมัติ)

เลือกใช้ Instructions หรือ Skills ตอนไหน ใช้กรอบนี้ตัดสินใจ

คำถามที่ช่วยตัดสินใจได้ตรงที่สุดคือ 'กฎนี้ต้องใช้ทุกงานในบริบทของ repo นี้ไหม' ถ้าคำตอบคือใช่ เช่น framework หลักที่ใช้, ภาษาโปรแกรม, กฎการตั้งชื่อไฟล์ทั่วไป ควรอยู่ใน Custom Instructions เพราะเป็นบริบทพื้นฐานที่ Agent ต้องรู้เสมอไม่ว่างานจะเป็นอะไร

แต่ถ้าคำตอบคือ 'เฉพาะบางประเภทงานเท่านั้น' เช่นเฉพาะตอนเขียนเทสต์, เฉพาะตอนแตะระบบ payment, เฉพาะตอนทำ migration ฐานข้อมูล ควรแยกออกมาเป็นชุด Skill เพราะความรู้พวกนี้มักต้องการรายละเอียดสูงกว่าที่ควรใส่ไว้ในบริบทตั้งต้นตลอดเวลา และถ้าใส่ไว้ใน Instructions รวมกันหมด ไฟล์จะยาวจนกินพื้นที่บริบทของงานอื่นที่ไม่เกี่ยวข้อง

ในทางปฏิบัติ ทีมส่วนใหญ่ใช้สองแนวทางนี้ร่วมกัน ไม่ใช่เลือกอย่างใดอย่างหนึ่ง Custom Instructions เป็นชั้นฐานที่ Agent รู้เสมอ ส่วน Agent Skills เป็นชั้นความรู้เฉพาะทางที่ดึงมาเสริมเฉพาะตอนงานต้องการ คล้ายกับการที่ GitHub MCP Server เปิดเฉพาะ toolset ที่จำเป็นแทนที่จะเปิดทุกอย่างพร้อมกัน หลักคิดเบื้องหลังคล้ายกันคือให้ Agent เห็นเฉพาะสิ่งที่จำเป็นต่องานตรงหน้า

ตารางเทียบ Custom Instructions กับ Agent Skills แบบเห็นภาพชัด

สรุปความต่างที่ใช้ตัดสินใจได้จริงในตารางนี้:

ดูแลชุด Skill ให้ไม่กลายเป็นขยะเก่าเหมือนไฟล์ Instructions ที่ไม่มีใครแก้

ปัญหาที่พบได้กับ Custom Instructions คือมีกฎเก่าที่ไม่ตรงกับโค้ดปัจจุบันแล้วแต่ไม่มีใครลบออก เพราะไฟล์เดียวยาวเกินจะไล่ทบทวนทั้งหมด Agent Skills ก็เจอปัญหาแบบเดียวกันได้ถ้าไม่มีเจ้าของดูแล เพราะยิ่งแยกเป็นหลายชุด ยิ่งง่ายที่จะลืมว่ามีชุดไหนอยู่บ้าง

แนวทางที่ช่วยได้คือกำหนดให้ทุกชุด Skill มีเจ้าของรับผิดชอบ (อาจเป็นทีมหรือคนที่เชี่ยวชาญเรื่องนั้นในทีม) และทบทวนพร้อมกับรอบรีวิวโค้ดใหญ่ ๆ เช่นตอนอัปเกรด framework หลักหรือเปลี่ยนแนวทางสถาปัตยกรรม เพราะจุดเหล่านี้มักเป็นจุดที่ทำให้ชุด Skill เก่าไม่ตรงกับความเป็นจริงของโค้ดฐานปัจจุบันอีกต่อไป

อีกวิธีที่ทีมที่มีชุด Skill จำนวนมากใช้คือตั้งชื่อไฟล์หรือโฟลเดอร์ให้จัดหมวดหมู่ชัดเจนตั้งแต่แรก เช่นแยกตามโดเมน (testing, security, database) แทนที่จะกองรวมกันไว้ในที่เดียวโดยไม่มีโครงสร้าง เพราะเมื่อจำนวนชุดเพิ่มขึ้นถึงหลักสิบ การจัดหมวดหมู่ที่ดีจะช่วยให้คนในทีมหาและแก้ไขชุดที่ต้องการได้เร็วกว่ามาก

ใช้ Skills ช่วยคนเข้าทีมใหม่เรียนรู้เร็วขึ้นได้ด้วย

ประโยชน์ที่มักถูกมองข้ามของการแยกความรู้เป็นชุด Skill คือมันไม่ได้มีค่าแค่กับ Agent เท่านั้น แต่คนที่เพิ่งเข้าทีมใหม่ก็อ่านชุดเหล่านี้เพื่อเข้าใจ 'วิธีทำงานแบบทีมนี้' ได้เร็วกว่าการไล่อ่านโค้ดเก่าเองทั้งหมด เพราะชุด Skill ถูกเขียนให้มีตัวอย่างและขั้นตอนชัดเจนอยู่แล้วโดยธรรมชาติ

บางทีมถึงกับตั้งเป็นขั้นตอนมาตรฐานว่าเมื่อพนักงานใหม่ต้องทำงานเกี่ยวกับหัวข้อไหนเป็นครั้งแรก เช่นแตะระบบ payment หรือเขียน migration ครั้งแรก ให้เปิดอ่านชุด Skill ของหัวข้อนั้นควบคู่กับการถามรุ่นพี่ในทีม แทนที่จะพึ่งการถามปากเปล่าอย่างเดียวซึ่งมักได้คำตอบไม่ครบทุกครั้งขึ้นอยู่กับว่าใครตอบ

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

ทำแบบนี้แล้วพัง เพราะออกแบบ Skill ให้กว้างเกินขอบเขตที่ตั้งใจไว้

เคสที่เจอบ่อยคือทีมเขียนชุด Skill สำหรับ 'การ deploy' ไว้กว้างมาก ครอบคลุมทั้งการ deploy frontend, backend และ infrastructure ในไฟล์เดียว พอ Agent ดึงชุดนี้มาใช้สำหรับงาน deploy frontend ธรรมดา มันกลับได้รับบริบทของขั้นตอน deploy infrastructure ที่ไม่เกี่ยวข้องมาด้วย ทำให้เสนอขั้นตอนที่ซับซ้อนเกินความจำเป็นสำหรับงานเล็ก ๆ ตรงหน้า

อีกเคสคือชุด Skill ที่เขียนขั้นตอนไว้ละเอียดมากแต่ไม่มีเงื่อนไขว่า 'เมื่อไรไม่ควรใช้' ทำให้ Agent พยายามใช้ชุดนี้กับงานที่ดูใกล้เคียงแต่จริง ๆ ไม่ตรงเงื่อนไข เช่นใช้ขั้นตอน migration ฐานข้อมูลปกติกับตารางที่มีข้อมูลอ่อนไหวที่ต้องมีกระบวนการอนุมัติพิเศษ เพราะชุด Skill ไม่ได้ระบุข้อยกเว้นนี้ไว้ตั้งแต่ต้น

บทเรียนร่วมคือชุด Skill ที่ดีต้องแคบพอที่จะโฟกัสงานเดียวให้ชัด แต่ก็ต้องระบุขอบเขตและข้อยกเว้นให้ครบ ไม่ใช่แค่บอกว่า 'ให้ทำแบบนี้' โดยไม่บอกว่า 'ห้ามใช้แนวทางนี้เมื่อไร' เพราะข้อยกเว้นที่ขาดหายไปมักเป็นจุดที่ทำให้เกิดปัญหาจริงในภายหลัง

สรุป

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

การแยกความรู้เฉพาะทางออกเป็นชุด Skill ที่มีขอบเขตชัดเจน พร้อมตัวอย่างที่ถูกและผิดเทียบกัน ช่วยให้ Agent โฟกัสกับสิ่งที่เกี่ยวข้องกับงานตรงหน้าได้ดีขึ้นจริง แต่ต้องมีคนดูแลต่อเนื่อง ไม่ใช่เขียนครั้งเดียวแล้วปล่อยทิ้งไว้เหมือนที่มักเกิดกับไฟล์ Instructions เก่า ๆ

• Custom Instructions = ชั้นฐานที่โหลดเสมอ, Agent Skills = ความรู้เฉพาะทางที่ดึงมาใช้ตามสถานการณ์
• ชุด Skill ที่ดีต้องแคบ โฟกัสงานเดียว มีตัวอย่างชัดเจน และระบุข้อยกเว้นว่าเมื่อไรไม่ควรใช้
• ต้องมีเจ้าของดูแลและทบทวนชุด Skill ต่อเนื่อง ไม่งั้นจะกลายเป็นข้อมูลล้าสมัยเหมือน Instructions เก่า

คำถามที่พบบ่อย