ทุกวันนี้ Agent Skill (ชุดขั้นตอนสำเร็จรูปที่เขียนใส่ไฟล์ไว้ให้ AI agent อย่าง Claude Code หยิบไปทำตาม) มีให้ดาวน์โหลดกันเป็นร้อยตัว หลายคนติดตั้งไว้จนลืมว่ามีอะไรบ้าง แต่พอถึงเวลาทำงานจริง กลับไม่มีใครตอบได้ว่าตัวไหนดี ตัวไหนควรลบทิ้ง เพราะ skill เขียนง่ายจนใครก็เขียนได้ แต่ไม่มีเกณฑ์กลางว่าเขียนแบบไหนถึงเรียกว่าดี

ทอล์กชื่อ Building Great Agent Skills: The Missing Manual ของช่อง AI Engineer เสนอทางออกของเรื่องนี้ไว้ โดยเรียกอาการข้างต้นว่า skill hell แล้วแซวเสียงในหัวของคนชอบสะสม skill ว่า "Just one more skill, bro" หรือขออีกตัวเดียวน่า ผู้พูดเองก็ดูแล skill set ด้าน engineering ที่ได้รับความนิยมสูงชุดหนึ่งอยู่ เกณฑ์ 4 ข้อนี้จึงมาจากการตรวจ skill ของตัวเองจริง

หลักของเกณฑ์ชุดนี้เรียบง่าย skill ที่ดีไม่ใช่กองคำสั่งยาวๆ แต่คือการตัดสินใจเรื่องการออกแบบ 4 อย่าง ได้แก่ จะให้เรียกใช้ตอนไหน จะจัดของข้างในยังไง จะบังคับให้ agent ทำตามยังไง และจะตัดอะไรทิ้งบ้าง ทั้งสี่ข้อนี้คือ Trigger, Structure, Steering และ Pruning

Trigger ปล่อยให้ agent เลือกเรียกเอง หรือเรากดเรียก

skill ทุกตัวเรียกใช้ได้ 2 แบบ แบบแรกคือ user-invoked ที่ผู้ใช้สั่งเรียกเองโดยตรง อีกแบบคือ model-invoked ที่ตัว agent อ่านคำอธิบายของ skill แล้วตัดสินใจเรียกเอง ความต่างของสองแบบนี้ไม่ได้อยู่ที่ความสะดวก แต่อยู่ที่ว่าใครเป็นฝ่ายรับต้นทุน

แบบ model-invoked ต้องเอาคำอธิบายของ skill ไปฝากไว้ใน context ของ agent (พื้นที่ข้อมูลที่ agent มองเห็นระหว่างทำงาน) ตลอดเวลา พอคำอธิบายอยู่ตรงนั้น agent ถึงจะรู้ว่ามี skill นี้ แล้วหยิบมาเรียกได้เมื่อเข้าเงื่อนไข ต้นทุนคือมันเปลืองโทเคน (หน่วยที่ใช้วัดปริมาณข้อความที่โมเดลต้องอ่าน) ทุกครั้งที่ทำงาน และเพิ่มภาระให้ agent ต้องคอยพิจารณา ถ้ามี model-invoked 100 ตัว ก็เท่ากับมีคำอธิบาย 100 ชิ้นค้างอยู่ใน context ตลอดเวลา ยิ่งมีเยอะ context ยิ่งบวม จนบางครั้ง agent ทำงานช้าลงและเริ่มเลือกผิดจังหวะ อาการ agent บวมจนพัง แบบนี้เป็นปัญหาที่เจอกันบ่อย

ส่วนแบบ user-invoked ตรงกันข้าม agent จะไม่เห็นคำอธิบายของ skill นี้ (เพราะตั้งค่าปิดการเรียกโดยโมเดลไว้) จึงไม่กิน context แต่ต้นทุนย้ายมาตกที่คน ยิ่งมี user-invoked เยอะ ผู้ใช้ยิ่งต้องจำเองว่ามี skill อะไรให้เรียกตอนไหน ต้นทุนสองแบบนี้มีชื่อเรียกชัดเจน ฝั่ง model-invoked คือ context load ที่เครื่องต้องรับ ส่วนฝั่ง user-invoked คือ cognitive load ที่ผู้ใช้ต้องรับเอง

model-invoked ยังมีต้นทุนซ่อนอีกอย่างคือความไม่แน่นอน บางครั้ง agent เลือกไม่เรียก skill ทั้งที่ตัว skill เหมาะกับงานนั้นพอดี ทางแก้คือต้องใช้ eval หรือชุดทดสอบเพื่อตรวจว่า agent เรียก skill ถูกจังหวะหรือเปล่า เพราะฉะนั้นการตัดสินใจที่ควรทำเป็นข้อแรกคือ skill ตัวนี้ควรเป็น user-invoked หรือ model-invoked โดยชั่งน้ำหนักว่าจะยอมรับต้นทุนฝั่งไหนมากกว่ากัน

Structure มีแค่ steps กับ reference

พอเปิดไฟล์ skill เข้าไปข้างใน มันมีแค่ 2 ส่วนเท่านั้น ส่วนแรกคือ steps หรือขั้นตอนการทำงานที่ทำเรียงตามลำดับ อีกส่วนคือ reference หรือข้อมูลอ้างอิงที่ใช้ประกอบขั้นตอนนั้น บาง skill มีแค่ reference อย่างเดียว บาง skill มีแค่ steps ก็ได้เหมือนกัน

ตัวอย่างหนึ่งคือ skill ชื่อ 2 PRD ซึ่งใช้สร้างเอกสารสรุปความต้องการของโปรดักต์ หรือ PRD จาก context ของงานที่กำลังทำอยู่ skill นี้มี 3 ขั้นตอนคือ หา context ที่เกี่ยวข้อง ยืนยันขอบเขตกับผู้ใช้ แล้วค่อยเขียน PRD ออกมา ส่วน reference มี 2 ชิ้น ได้แก่คำอธิบายศัพท์เฉพาะและเทมเพลตของ PRD เท่านี้ก็เป็น skill ที่ใช้งานได้จริงแล้ว

เกณฑ์สำคัญของหมวดนี้คือทำไฟล์ skill.md ให้เล็กที่สุดเท่าที่จะทำได้ ไฟล์เล็กดูแลง่ายกว่า ตรวจทานง่ายกว่า และทุกคำที่ตัดออกจะช่วยประหยัดโทเคนได้ทุกครั้งที่เรียกใช้ skill นั้น เทคนิคย่อไฟล์คือมองหา branch ของ skill หรือวิธีใช้งานที่แตกต่างกันหลายแบบ ถ้า reference ชิ้นไหนเกี่ยวกับ branch เดียวเท่านั้น ให้ย้ายมันออกจาก skill.md หลักไปไว้อีกไฟล์ แล้วชี้ไปหาด้วย context pointer หรือตัวชี้ไปไฟล์อื่น พอ agent ทำงานตาม branch นั้น มันค่อยดึงไฟล์แยกมาอ่าน

skill ชื่อ domain modeling เป็นตัวอย่างที่ชัด มันทำได้หลายอย่างในตัวเดียว จะอัปเดตอภิธานศัพท์ในไฟล์ context.md ก็ได้ หรือจะสร้าง ADR หรือบันทึกการตัดสินใจด้านสถาปัตยกรรมก็ได้ พอมันมีหลาย branch แบบนี้ เทมเพลตของ ADR กับเทมเพลต context.md จึงแยกออกจากไฟล์หลักเป็นไฟล์อ้างอิง แล้วใช้ context pointer ชี้ไปหาแทน ไฟล์หลักเลยเหลือแค่ส่วนที่ทุก branch ใช้ร่วมกัน

Steering คำชี้นำเพียงคำเดียวก็เปลี่ยนพฤติกรรม agent ได้

หมวดที่ผู้พูดเน้นมากที่สุดคือ steering หรือการกำกับพฤติกรรมของ agent เครื่องมือหลักคือสิ่งที่เรียกว่า leading words หรือคำชี้นำ หมายถึงคำหรือวลีสั้นๆ ที่สื่อความหมายได้มาก เมื่อใส่ไว้ในเนื้อ skill แล้ว agent จะนำคำนั้นไปใช้ซ้ำทั้งใน reasoning trace หรือข้อความที่แสดงลำดับการคิดก่อนตอบ และในผลงานของมัน พฤติกรรมจึงเปลี่ยนไปตามความหมายของคำนั้น

ตัวอย่างคลาสสิกคือเวลา agent เขียนโค้ด มันชอบไล่ทำทีละชั้น ทำส่วนฐานข้อมูล (database) ทั้งก้อนให้เสร็จก่อน แล้วค่อยทำส่วนที่ส่งข้อมูลออกไปให้โปรแกรมอื่นเรียกใช้ แล้วค่อยทำหน้าเว็บที่ผู้ใช้เห็น กว่าจะได้ของที่ใช้งานได้จริงก็ปาไปท้ายสุด แทนที่จะเขียนคำอธิบายยาวๆ ว่าอย่าทำแบบนั้น ผู้พูดใช้คำชี้นำเพียงคำเดียวคือ vertical slice ซึ่งหมายถึงการทำงานให้ครบวงจรทีละชิ้นเล็กๆ แทนการไล่ทำทีละชั้น คำนี้เป็นศัพท์ที่โปรแกรมเมอร์รู้จักกันดีอยู่แล้ว agent จึงนำความรู้เดิมมาใช้ได้ทันที ไม่ต้องอธิบายกันยืดยาว

วิธีเช็คว่าคำชี้นำได้ผลไหมก็ตรงไปตรงมา ลองดูใน reasoning trace ว่า agent พูดคำนั้นซ้ำหรือเปล่า ถ้าเห็นมันพิมพ์ทำนองว่าจะทำงานนี้เป็น thin vertical slice ก็แปลว่าคำนั้นเปลี่ยนวิธีคิดของมันได้จริง

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

Pruning ลองลบทิ้งแล้วดูว่าอะไรหาย

หมวดสุดท้ายคือ pruning หรือการตัดส่วนเกิน เป้าหมายคือหลีกเลี่ยง skill ที่ใหญ่เทอะทะ เพราะไฟล์ที่บวมมักไม่ได้เป็นต้นตอของปัญหา แต่เป็นสัญญาณว่ามีปัญหาอื่นซ่อนอยู่ ผู้พูดแยกความผิดพลาดที่ทำให้ skill บวมออกเป็น 3 แบบ

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

แบบที่สามคือ no-op หรือคำสั่งที่ดูเหมือนสั่งงานแต่ไม่มีผลอะไรเลย เช่น ย่อหน้าที่สั่งให้ agent เขียน commit message (ข้อความสรุปการแก้โค้ดแต่ละครั้ง) ให้ยาวและละเอียด ทั้งที่ agent จะเขียนแบบนั้นอยู่แล้วแม้ไม่มีคำสั่งนี้ เนื้อหาแบบนี้กินที่ กินโทเคน แต่ไม่ได้เปลี่ยนพฤติกรรมอะไร วิธีตรวจคือสิ่งที่ผู้พูดเรียกว่า deletion test ลองลบย่อหน้านั้นแล้วสังเกตว่าพฤติกรรมของ agent เปลี่ยนไปไหม ถ้าไม่เปลี่ยน แปลว่าย่อหน้านั้นไม่เคยส่งผลต่อพฤติกรรมตั้งแต่แรก

เขียน skill ให้น้อยลง แต่ให้แม่นขึ้น

ผู้พูดรวบเกณฑ์ทั้ง 4 ข้อนี้ไว้ใน skill ชื่อ writing great skills ที่อยู่ในคลังโค้ด Matt Pocock skills บน GitHub ดาวน์โหลดไปใช้ตรวจ skill ที่เขียนเองได้ทันที ตัว skill จะไล่ถามทีละหมวดว่า skill ตัวนี้ควรเรียกแบบไหน โครงสร้างข้างในแยก steps กับ reference ชัดหรือยัง มีคำชี้นำที่บังคับพฤติกรรมได้จริงไหม และมีอะไรที่ลบทิ้งได้บ้าง

ทั้งสี่หมวดนี้ไม่ได้มีไว้สอนให้เขียน skill เก่งขึ้นเท่านั้น ครึ่งหนึ่งยังเป็นเครื่องมือที่เน้นการลบมากกว่าการเพิ่ม เสียงในหัวที่บอกว่า "Just one more skill, bro" ทำให้คลังของเราบวมขึ้นเรื่อยๆ แต่ skill ที่ดีจริงมักต้องทำตรงกันข้าม สุดท้ายจะเหลือเพียงไฟล์เล็กๆ จนไม่มีอะไรให้ตัดออกอีกแล้ว

---

ที่มา: คลิป Building Great Agent Skills: The Missing Manual จากช่อง AI Engineer