สกิล 60 ตัว ไม่เคยถูกเรียกเลย เราเกือบตัดทิ้ง แล้ววัดก่อน

คุณลงเครื่องมือช่วย AI ไว้เต็มไปหมด ตัวไหนเห็นว่าดีก็เก็บไว้ก่อน ไม่เคยรื้อ แล้ววันหนึ่งก็เริ่มไม่แน่ใจว่าที่ลงไว้ทั้งหมดนั้น มีตัวไหนได้ใช้จริงบ้าง

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

เราเลยลองนับของตัวเองดู คืนหนึ่งเราเปิดตัวเลขคลังสกิลของตัวเองขึ้นมาดู ปลั๊กอินหลัก (ชุดสกิลที่ติดตั้งและโหลดมาด้วยกันเป็นก้อนเดียว) มีสกิลที่โมเดลมองเห็น 84 ตัว คำอธิบายของทั้ง 84 ตัวรวมกันเป็น 30,922 ตัวอักษร ที่ถูกโหลดเข้า context ทุกเทิร์น ไม่ว่าจะเรียกใช้หรือไม่ก็ตาม

แล้วเราไปนับต่อว่ามีตัวไหนถูกเรียกใช้จริงบ้าง ค้นในบันทึกเซสชันบนแมค 1,067 ไฟล์ ค้นซ้ำด้วยวิธีที่สองคือดูคำสั่งสแลช (คำสั่งที่พิมพ์ว่า /ชื่อสกิล เพื่อเรียกมันตรงๆ) ในไฟล์ชุดเดียวกัน แล้วค้นรอบสามบนเครื่องเซิร์ฟเวอร์อีก 5,680 ไฟล์ 60 ตัวไม่โผล่มาเลยสักครั้ง คิดเป็น 73% ของค่า context ที่จ่ายอยู่

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

โชคดีที่เราวัดก่อนตัด ผลออกมากลับข้างกับที่คิดไว้ทั้งหมด

บทความนี้คือวิธีที่ Productize วัด Claude skill library ของตัวเอง ทั้งคลัง 142 ตัว ตัวเลขทุกตัวมาจากการรันจริงในวันเดียว ไม่ได้ยืมใครมา ตัวเลข 84 ที่จะเห็นบ่อยในบทความนี้คือส่วนที่อยู่ในปลั๊กอินหลักตัวเดียว ซึ่งเป็นชุดที่เรายิงโมเดลใส่จริง ส่วนที่เหลือของคลังตรวจด้วยชั้นที่ราคาศูนย์

ช่วงที่ 1คืนที่เกือบตัดสกิลทิ้ง 60 ตัว

เรื่องเริ่มจากงานที่ควรจะเล็ก เราอยากรู้แค่ว่าสกิลในบ้านตัวไหนใช้งานได้จริงบ้าง แล้วพอเริ่มนับก็เจอว่าไม่มีใครเคยนับมาก่อน

ตัวเลขชุดแรกที่ได้มาน่าตกใจพอสมควร

คำว่า "ค้น 3 วิธี" สำคัญกว่าที่เห็น เพราะรอบแรกเราค้นแค่วิธีเดียวคือหาการเรียกเครื่องมือในบันทึกเซสชัน แล้วได้ตัวเลขว่า 65 ตัวไม่เคยถูกใช้ พอค้นรอบสองด้วยวิธีที่ต่างออกไปคือดูคำสั่งสแลช เจอเพิ่มอีก 4 ตัว แล้วค้นรอบสามบนเครื่องเซิร์ฟเวอร์เจออีก 1 ตัว

ถ้าเชื่อการค้นรอบเดียว เราจะเขียนลงรายงานว่ามี 65 ตัวที่ไม่เคยถูกใช้ ซึ่งผิดไป 5 ตัว และรายงานนั้นจะถูกเอาไปตัดสินใจตัดของทิ้ง

ช่วงที่ 2วัดคลังสกิลต้องวัด 4 ชั้น แต่ละชั้นราคาไม่เท่ากัน

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

สองชั้นบนราคาศูนย์เพราะมันแค่อ่านไฟล์ ไม่ต้องเรียกโมเดลเลย และมันจับอาการที่พบบ่อยที่สุดได้

ตัวอย่างที่เจอกับตัว สกิลเขียนภาษาไทยของเราประกาศกฎไว้ชัดว่าห้ามใช้เครื่องหมายขีดยาวคั่นกลางประโยค แต่พอเอาไปวัดที่ชั้นสี่กลับพบว่าโมเดลอ่านกฎนั้นแล้ว เปิดไฟล์อ้างอิงที่กฎอยู่จริงด้วย แล้วยังใส่ขีดยาวลงในงานทั้ง 3 รอบจาก 3 รอบ

สาเหตุอยู่ในตัวสกิลเอง ตัวอย่างที่มันติดป้ายว่า "ดี" มี 3 จุดที่ใช้ขีดยาวเสียเอง ตัวอย่างสอนแรงกว่าคำอธิบาย แก้ตัวอย่าง 4 บรรทัดแล้ววัดใหม่ ผลพลิกจาก 0 ใน 3 เป็น 3 ใน 3 ทันที

อาการชนิดนี้หาเจอได้จากไฟล์เฉยๆ ไม่ต้องยิงโมเดลสักครั้ง เราเลยเขียนตัวตรวจราคาศูนย์ที่ไล่ได้ทั้งคลัง 142 ตัวในไม่กี่วินาที แล้วต่อเข้าสายที่รันอัตโนมัติทุกครั้งที่ซิงก์สกิล

ลำดับที่ถูกคือไล่จากชั้นที่ราคาศูนย์ขึ้นก่อน ไม่ใช่กระโดดไปยิงโมเดลตั้งแต่แรก

ช่วงที่ 3โฟลเดอร์บนดิสก์คือจำนวนสกิลที่โมเดลเห็นหรือเปล่า

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

เราวัดกับคลังสกิลของ Matt Pocock (วิศวกร TypeScript ที่เปิดคลังสกิลของตัวเองให้คนอื่นติดตั้งใช้ เป็นคลังนอกบ้านที่เราติดตั้งไว้จริง) รุ่น 1.2.3

เลข 11 ตรงเป๊ะกับรายการที่เซสชันจริงมองเห็นตอนนั้น ซึ่งเป็นวิธีเดียวที่ทำให้เรารู้ว่าตัวนับของเราถูก เราจับได้เพราะเอาไปเทียบกับของจริง ไม่ใช่เพราะโค้ดฟ้อง ตัวนับรอบแรกรายงาน 35 แล้วมันก็ดูสมเหตุสมผลดี

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

ช่วงที่ 4สกิลที่ไม่เคยถูกเรียก แปลว่าพังหรือเปล่า

ส่วนใหญ่ไม่ใช่ เราเอาสกิลทั้ง 86 ตัวมายิงทีละตัว ด้วยโจทย์ที่สร้างจากวลีทริกเกอร์ที่ตัวสกิลประกาศไว้เอง แล้วดูจากบันทึกการรันว่าโมเดลหยิบมันขึ้นมาไหม 66 ตัวทริกเกอร์ติดปกติ

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

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

อีก 6 ตัวที่เหลือ probe ตัดสินไม่ได้ เพราะวลีที่มันประกาศไว้ไม่ใช่คำขอของคน เป็นโทเคนของผลลัพธ์ เช่นคำว่า "not found" โจทย์ที่สังเคราะห์จากวลีแบบนั้นจึงไม่มีความหมาย ต้องเขียนโจทย์มือแล้วยิงใหม่ รวมเป็น 66 ติด 14 ไม่ติด 6 ตัดสินไม่ได้ ครบ 86 พอดี

ที่เหลือ 14 ตัวที่ไม่ติดก็ยังต้องแยกอีกชั้น เพราะคำว่า "ไม่ติด" กลืน 3 ความหมายที่ต่างกันสิ้นเชิงไว้ในถังเดียว

1. ทริกเกอร์อ่อนจริง อันนี้เป็นบั๊ก สังเกตได้จากมีสกิลพี่น้องถูกหยิบไปแทน เราเจอ 4 คู่ที่แย่งกันเอง แก้ด้วยการเขียนขอบเขตในคำอธิบายให้ไม่ทับกัน ยิงซ้ำแล้วพลิกเป็นติดครบ
2. โมเดลทำเองได้อยู่แล้ว อันนี้ไม่ใช่บั๊ก เปิดบันทึกการรันดูแล้วพบว่าไม่มีการเรียกเครื่องมือใดเลย แต่คำตอบใช้ได้จริง
3. สนามทดสอบไม่มีของให้ทำงานด้วย อันนี้วัดไม่ได้ สังเกตจากโมเดลตอบว่ายังเริ่มไม่ได้ แล้วมักเอ่ยชื่อสกิลเองว่าจะใช้ ซึ่งแปลว่าทริกเกอร์ทำงานอยู่

เราเสียเวลาไป 1 รอบเพราะไม่ได้แยกสามอย่างนี้ เห็นสกิล 6 ตัวขึ้นว่าไม่ติดพร้อมกัน เลยสรุปว่าคำอธิบายเขียนอ่อน แล้วเขียนใหม่ทั้ง 6 ตัว ยิงซ้ำแล้วพลิกแค่ตัวเดียว ต้องถอยคืนอีก 5 ตัว

สิ่งที่ทำให้รู้คือการเปิดบันทึกการรันจริงมาอ่าน ไม่ใช่การเดารอบที่สาม

ช่วงที่ 5เกณฑ์ที่ถูก และวิธีเอาไปใช้กับคลังของคุณ

เกณฑ์ที่เราเริ่มด้วยคือ "เคยถูกใช้ไหม" ซึ่งผิด เกณฑ์ที่ถูกคือ "ควรถูกหยิบเองไหม"

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

ถ้าจะเริ่มกับคลังของคุณเอง ลำดับที่เราแนะนำจากการเดินผิดมาแล้ว

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

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

ตอนนี้เราเก็บวิธีอ่านผลไว้เป็นคู่มือของฝูงแยกจากตัวเครื่องมือ เพราะสิ่งที่ขาดไม่เคยเป็นเครื่องมือ

ตัวอย่างที่ชัดที่สุดของ "สกิลสาธิตสิ่งที่ตัวเองห้าม" เราแยกไปเล่าเต็มๆ ที่ สกิลห้ามใช้ขีดยาว แล้วตัวมันเองใช้ 54 จุด ส่วนถ้ายังไม่แน่ใจว่าสกิลต่างจากพรอมต์ยาวๆ ตรงไหน เราเล่าไว้ที่ skill ไม่ใช่แค่ prompt ที่ยาวขึ้น และถ้าคลังของคุณโตจนต้องแบ่งให้ agent หลายตัวถือคนละชุด ลองอ่าน ทีม AI ไม่ควรถือ skill เหมือนกันหมด ต่อ ส่วนบทความอื่นทั้งหมดรวมอยู่ที่ หน้ารวมบทความ

ที่มาและอ้างอิง

ตัวเลขทุกตัวในบทความนี้มาจากการรันจริงบนคลังสกิลของเราเองเมื่อ 13 สิงหาคม 2026 ไม่มีตัวเลขที่ยกมาจากที่อื่น

• จำนวนสกิลที่โมเดลเห็นและค่าเช่า context วัดด้วยตัวนับที่เขียนเอง อ่านจากไฟล์ตั้งค่าของเครื่องกับต้นไม้ของปลั๊กอินที่โปรแกรมอ่านจริง
• การค้นร่องรอยการใช้งาน ค้นในบันทึกเซสชัน 1,067 ไฟล์บนเครื่องหลัก และ 5,680 ไฟล์บนเครื่องเซิร์ฟเวอร์ ด้วยสองรูปแบบที่ต่างกัน
• ผลทริกเกอร์ 86 ตัว ยิงด้วยคำสั่งบรรทัดเดียวหนึ่งครั้งต่อสกิล อ่านผลจากบันทึกการรันแบบละเอียด
• ตัวเลข 35 กับ 25 กับ 11 อ่านจากโฟลเดอร์จริง ไฟล์รายการของปลั๊กอิน และหัวไฟล์ของแต่ละสกิล แล้วเทียบกับรายการที่เซสชันจริงมองเห็น