ทีมพัฒนาสิบคนสั่ง AI คนละแบบ จนโค้ดไม่เป็นมาตรฐานเดียวกัน แก้ยังไง

ลองนึกภาพทีมพัฒนาสิบคนที่ทุกคนใช้ Claude Code ในงานประจำวัน แต่ไม่มีใครคุยกันเรื่องวิธีสั่งงานเลย คนหนึ่งบอก Agent ให้เขียน commit message แบบหนึ่ง อีกคนใช้อีกแบบ บางคนให้ Agent เขียน test ทุกครั้งที่แก้โค้ด บางคนไม่เคยพูดเรื่องนี้เลย ผลที่ตามมาคือ Pull Request ในโปรเจกต์เดียวกันมีสไตล์ไม่เหมือนกันเลยสักฉบับ

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

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

ทำไมผลลัพธ์จาก Agent ถึงไม่สม่ำเสมอทั้งที่ใช้โมเดลตัวเดียวกัน

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

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

Skill คืออะไร ต่างจากการพิมพ์ Prompt ยาว ๆ ตรงไหน

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

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

เทียบ Skill กับวิธีสั่งงานแบบอื่นที่ทีมอาจคุ้นเคยอยู่แล้ว

ทีมที่เคยใช้ไฟล์คำแนะนำทั่วไปอย่าง README หรือ CLAUDE.md อาจสงสัยว่า Skill ต่างจากไฟล์พวกนี้ตรงไหน ตารางนี้เทียบให้เห็นบทบาทที่ต่างกัน:

ออกแบบ Skill ให้ใช้ได้จริง ไม่ใช่แค่เขียนกฎยาว ๆ ทิ้งไว้

Skill ที่ใช้งานได้ดีไม่ใช่เอกสารยาวเป็นหน้า ๆ ที่อธิบายทุกอย่างในโปรเจกต์ แต่เป็นชุดคำแนะนำที่โฟกัสงานเฉพาะเจาะจง เช่น 'ขั้นตอนเขียน API endpoint ใหม่' หรือ 'มาตรฐาน commit message ของทีม' แยกเป็นคนละ Skill กัน แทนที่จะรวมทุกอย่างไว้ในไฟล์เดียวจนยาวเกินไปจน Agent หยิบใช้ได้ไม่ตรงจุด

ขั้นตอนที่แนะนำให้ทำตามลำดับเมื่อเริ่มออกแบบ Skill แรกของทีม:

1. เลือกงานที่ทีมทำซ้ำบ่อยที่สุดและมีขั้นตอนชัดเจนอยู่แล้ว เช่นการเขียน test ก่อน merge ทุกครั้ง
2. เขียนขั้นตอนที่ต้องการให้ Agent ทำตามเป็นข้อ ๆ ไม่ใช่ประโยคยาวรวมกันจนแยกไม่ออก
3. ระบุตัวอย่างจริงจากโค้ดในโปรเจกต์ประกอบ เพื่อให้ Agent เห็นรูปแบบที่ต้องการชัดเจนกว่าคำอธิบายลอย ๆ
4. ทดสอบ Skill กับงานจริงสักสองสามครั้ง แล้วดูว่าผลลัพธ์ตรงกับที่ทีมต้องการหรือยัง
5. ปรับแก้ Skill ตามผลทดสอบ ก่อนประกาศให้ทั้งทีมใช้ร่วมกันเป็นมาตรฐาน

ใช้ Skill สร้างมาตรฐานทีมโดยไม่ต้องประชุมสอนกันทุกคน

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

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

สำหรับทีมที่เริ่มใช้ Claude Code เป็นครั้งแรก ควรอ่านพื้นฐานเรื่อง Claude Code คืออะไร ก่อน เพื่อให้เข้าใจว่า Agent ทำงานยังไงในระดับพื้นฐาน ก่อนจะมาออกแบบ Skill ให้ซับซ้อนขึ้น

ข้อผิดพลาดที่ทีมมักเจอตอนเริ่มเขียน Skill ชุดแรก

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

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

รู้ได้ยังไงว่า Skill ที่ออกแบบไว้ใช้ได้ผลจริง

วิธีที่ตรงที่สุดคือดูจาก Pull Request ที่เกิดขึ้นหลังเริ่มใช้ Skill ว่ามีความสม่ำเสมอมากขึ้นไหม เช่น commit message เป็นรูปแบบเดียวกันมากขึ้น หรือจำนวนรอบที่ reviewer ต้องขอแก้เรื่อง style ลดลงหรือไม่ ถ้าตัวเลขเหล่านี้ดีขึ้นแปลว่า Skill กำลังทำงานตามที่ตั้งใจไว้

อีกสัญญาณที่บอกได้ชัดคือเวลาที่คนเข้าทีมใหม่ใช้ในการปรับตัวให้เขียนโค้ดตรงสไตล์ทีม ถ้า Skill ออกแบบดี คนใหม่ควรใช้เวลาปรับตัวสั้นลงกว่าตอนที่ไม่มี Skill เพราะ Agent ช่วยรักษามาตรฐานให้แม้คนใหม่ยังไม่คุ้นกับ convention ของทีมทั้งหมด

ตัวอย่างสมมติ ทีมสิบคนแก้ปัญหาความไม่สม่ำเสมอด้วย Skill

สมมติทีมพัฒนาแอปจองคิวโรงพยาบาลมีนักพัฒนาสิบคนใช้ Claude Code ในงานประจำวัน ก่อนมี Skill พบว่า Pull Request แต่ละฉบับเขียน commit message คนละรูปแบบ บางคนเขียนภาษาไทยปนอังกฤษ บางคนเขียนยาวเกินความจำเป็น reviewer ต้องเสียเวลาขอแก้ format เกือบทุกครั้งก่อนจะ merge ได้จริง

หลังทีมตกลงเขียน Skill กำหนดรูปแบบ commit message ให้ชัดเจน พร้อมตัวอย่างจริงสามแบบสำหรับกรณี feature, fix และ refactor ผลลัพธ์ที่เห็นได้ชัดคือ Pull Request ใหม่ ๆ เริ่มมี commit message เป็นรูปแบบเดียวกันมากขึ้นโดยไม่ต้องมีใครคอยเตือน เพราะ Agent อ่าน Skill นั้นแล้วทำตามให้อัตโนมัติทุกครั้งที่ช่วยเขียนโค้ด

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

เมื่อทีมโตขึ้น ต้องปรับวิธีจัดการ Skill ยังไง

ทีมขนาดเล็กอาจจัดการ Skill ไม่กี่ชุดโดยไม่มีปัญหา แต่เมื่อทีมโตขึ้นและมี Skill สะสมมากขึ้นเรื่อย ๆ ควรมีการจัดหมวดหมู่ให้ชัดเจน เช่นแยกตามประเภทงาน (backend, frontend, testing) เพื่อให้ทั้ง Agent และคนในทีมหาเจอง่ายขึ้นเมื่อต้องปรับปรุงหรืออ้างอิง

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

สรุป

ปัญหาที่ Agent แต่ละคนในทีมใช้ให้ผลลัพธ์ไม่เหมือนกัน ไม่ได้แก้ด้วยการหาโมเดลที่ฉลาดขึ้น แต่แก้ด้วยการวางมาตรฐานให้ Agent ทำตามอย่างสม่ำเสมอผ่าน Skill ซึ่งเป็นการลงทุนเวลาครั้งเดียวที่ส่งผลต่อคุณภาพงานของทั้งทีมในระยะยาว

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

• Skill คือไฟล์คำแนะนำที่ Agent เรียกใช้ซ้ำได้ทุกครั้ง แก้ปัญหาการสั่งงานคนละแบบในทีม
• ควรแยก Skill ตามลักษณะงานเฉพาะเจาะจง ไม่ใช่รวมทุกอย่างไว้ในไฟล์เดียว
• ใช้ร่วมกับ Hooks ได้ Skill กำหนดวิธีเขียนโค้ด ส่วน Hooks บังคับขั้นตอนก่อนงานเสร็จจริง
• วัดผลได้จากความสม่ำเสมอของ Pull Request และเวลาที่คนเข้าทีมใหม่ใช้ปรับตัว

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