สร้าง Skill สำหรับเอเจนต์ AI ในเวิร์กโฟลว์ธุรกิจเฉพาะด้าน

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

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

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

Skill คืออะไรกันแน่

Skill ไม่ใช่คุณสมบัติของโมเดลหรือความสามารถของ API แต่เป็นไฟล์ Markdown ที่วางไว้ในไดเรกทอรีซึ่งเอเจนต์ตรวจเมื่อเริ่มเซสชัน (เช่น ใน Claude Code คือไฟล์ SKILL.md ในโฟลเดอร์ภายใต้ ~/.claude/skills/ หรือ .claude/skills/ ของโครงการ ส่วนสภาพแวดล้อมการทำงานของเอเจนต์อื่นจะใช้ตำแหน่งของตนเอง) เมื่อพบคำขอที่ตรงกับคำอธิบายของ Skill เอเจนต์จะโหลดและทำตามคำสั่งในไฟล์ แทนที่จะคิดวิธีทำงานใหม่ตั้งแต่ต้น

ไฟล์นี้มีองค์ประกอบสี่อย่าง: ส่วนคำอธิบายที่บอกเอเจนต์ว่าเมื่อใดควรเรียกใช้ Skill ชุดคำสั่งสำหรับจัดการงานประเภทนั้น ข้อกำหนดการเข้าถึงเครื่องมือที่อาจระบุเพื่ออนุมัติล่วงหน้าหรือจำกัดเครื่องมือที่เอเจนต์ใช้ได้ขณะทำงาน ขึ้นอยู่กับสภาพแวดล้อมการทำงาน (ใน Claude Code นั้น allowed-tools อนุมัติเครื่องมือล่วงหน้าโดยไม่จำกัดเครื่องมืออื่น) และตัวอย่างที่อาจเพิ่มเพื่อแสดงพฤติกรรมที่ถูกต้องกับข้อมูลนำเข้าที่สมจริง

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

เมื่อใดควรบันทึกความรู้เฉพาะด้าน และเมื่อใดไม่ควร

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

หลักปฏิบัติคือบันทึกสิ่งที่เปลี่ยนช้าไว้ใน Skill และให้เอเจนต์จัดการสิ่งที่เปลี่ยนบ่อย

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

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

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

โครงสร้างของ SKILL.md

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

---
name: import-document-processor
description: Use when processing import declarations, ACP applications,
  or customs documentation for Singapore, Japan, or EU markets
---

## Context
Background on the domain: what this class of documents is, why it
exists, what the agent needs to know to interpret one intelligently.

## Approach
Step-by-step instructions for handling the task: what to look for,
how to handle ambiguous cases, what to escalate to human review.

## Output Format
Exactly what the output should contain, in what structure.

## Edge Cases
Known failure modes and how to handle them.

ในทางปฏิบัติ ส่วนคำอธิบายสำคัญที่สุด เพราะกำหนดว่าเอเจนต์จะเรียกใช้ Skill หรือไม่ คำอธิบายกว้าง ๆ อย่าง “ใช้กับเอกสาร” ทำให้การเรียกใช้ไม่แน่นอน ส่วนคำอธิบายที่ระบุประเภทเอกสาร บริบทธุรกิจ และตลาดที่เกี่ยวข้องอย่างชัดเจนทำให้พฤติกรรมเชื่อถือได้

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

รูปแบบ /loop สำหรับงานที่ทำซ้ำ

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

ใน Claude Code คำสั่ง /loop เปลี่ยนการโต้ตอบที่ใช้ Skill ให้เป็นงานที่ทำซ้ำตามกำหนด:

/loop 24h /process-supplier-reports

คำสั่งนี้เรียก Skill ที่ระบุซ้ำตามช่วงเวลาที่กำหนดภายในเซสชันปัจจุบัน ซึ่งเป็นแหล่งบริบทสำหรับการเรียกใช้แต่ละครั้ง Skill รับผิดชอบงาน ส่วน loop รับผิดชอบการกำหนดเวลา ณ เดือนตุลาคม 2026 เอกสารของ Claude Code ระบุว่า /loop มีผลเฉพาะในเซสชัน: งานจะเริ่มทำงานเฉพาะขณะที่เซสชันยังทำงานอยู่ และงานที่ทำซ้ำจะหมดอายุหลังจากเจ็ดวัน ดังนั้น การตั้งเวลาระยะยาวสำหรับระบบใช้งานจริงควรใช้ cron job, CI pipeline หรืองานที่ตั้งเวลาไว้บนคลาวด์เพื่อเรียก Skill เดียวกัน

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

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

หลักประเมินง่าย ๆ คือ หากอธิบายพฤติกรรมทั้งหมดที่คาดหวังจาก Skill รวมถึงกรณีข้อผิดพลาดไม่ได้ภายในสิบนาที ขอบเขตของ Skill น่าจะกว้างเกินไปสำหรับการทำงานตามกำหนดเวลาที่เชื่อถือได้

ตัวอย่างจากการใช้งานจริง

รูปแบบสามอย่างที่เราใช้ในการดำเนินงานจริง:

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

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

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

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

สิ่งที่ Skill ไม่ได้แก้ปัญหา

Skill บันทึกความสามารถในงานเฉพาะด้าน ไม่ได้สร้างความสามารถทั่วไป

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

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

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