สรุปจากคลิป ดูคลิปต้นฉบับ

วิธีทำ Claude Skills ให้เก่งขึ้น ไม่ใช่แค่สั่งดีแต่ต้องสอนเป็น

ปัญหาของคนที่เริ่มใช้ AI agents ไม่ใช่เรื่อง model ไม่เก่งพอ แต่เป็นเพราะเราคาดหวังว่าแค่เขียน prompt หรือสร้าง skill ขึ้นมาสักอัน แล้วมันจะทำงานได้ดีเองทันที ซึ่งคลิปของ Greg Isenberg ที่คุยกับ Ras Mic ชี้ชัดมากว่า จุดต่างระหว่างผลลัพธ์แบบ “พอใช้” กับ “เอาไปใช้งานจริงได้” อยู่ที่การออกแบบ context และวิธีปั้น skill มากกว่า

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

สารบัญ

• Step 1: เข้าใจก่อนว่าปัญหาไม่ได้อยู่ที่ AI แต่อยู่ที่ context ที่เราให้
• Step 2: แยกให้ออกระหว่าง prompt ทั่วไปกับ skill ที่ใช้งานซ้ำได้จริง
• Step 3: อย่าเริ่มจากการเขียน skill ให้สวย ให้เริ่มจากการทำงานจริงหนึ่งรอบก่อน
• Step 4: ให้ AI เขียน skill หลังจากมันเพิ่งทำสำเร็จ
• Step 5: ทดสอบ skill และปรับจากความล้มเหลว ไม่ใช่หวังให้สมบูรณ์ตั้งแต่ครั้งแรก
• Step 6: เริ่มจาก agent เดียวที่ทำงานได้จริง ก่อนคิดเรื่องระบบหลาย agent
• Step 7: แปลงแนวคิดนี้ให้ใช้กับธุรกิจไทยแบบจับต้องได้
• Actionable Insights
• Troubleshooting
• การต่อยอด
• สรุป Checklist ทั้งหมด

Step 1: เข้าใจก่อนว่าปัญหาไม่ได้อยู่ที่ AI แต่อยู่ที่ context ที่เราให้

Ras Mic อธิบายภาพใหญ่ง่ายมากว่า model รุ่นใหม่เก่งมากอยู่แล้ว ไม่ว่าจะเป็น Claude หรือ GPT ความต่างไม่ได้อยู่ที่ว่าใครฉลาดกว่าแบบทิ้งขาด แต่คือใครได้ context ที่ดีกว่า และถูกห่อด้วย workflow ที่ดีกว่า

แปลเป็นภาษาคนทำงานได้ว่า ถ้าเราสั่ง AI แบบกว้างๆ เช่น “ช่วยหาลีดที่น่าสนใจ” หรือ “ช่วยคัดสปอนเซอร์ที่ดี” เรากำลังโยนโจทย์ที่ยังไม่ชัดให้มันเดาเอง ผลลัพธ์เลยมักออกมากลางๆ ดูเหมือนตอบได้ แต่ไม่ได้ช่วยตัดสินใจจริง

นี่คือจุดที่หลายธุรกิจพลาด เราคิดว่า AI ต้องคิดแทนเรา แต่จริงๆ AI ต้องได้กรอบการคิดจากเราเสียก่อน ว่าอะไรคือดี อะไรคือไม่โอเค และอะไรคือเงื่อนไขที่ต้อง reject ทันที

ตัวอย่างจากคลิปชัดมาก เขายกกรณีสร้าง agent สำหรับ research lead โดยให้ไปเช็ก Twitter, YouTube และ Trustpilot ถ้าข้อมูลหายไป 2 ช่อง หรือภาพรวมดูแย่ ก็ให้ปัดตกทันที ตรงนี้ไม่ใช่แค่สั่งงาน แต่คือการใส่เกณฑ์ตัดสินลงไปในระบบ

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

• คัดร้านค้าที่จะรับเข้ามาใน marketplace
• คัด influencer สำหรับแคมเปญ
• คัด lead สำหรับทีมขาย B2B
• คัดใบสมัครงานรอบแรก
• คัด supplier เบื้องต้นก่อนส่งให้ทีมจัดซื้อดูต่อ

หัวใจคือ เราต้องนิยามก่อนว่า “ผ่าน” คืออะไร และ “ไม่ผ่าน” คืออะไร ถ้าไม่ทำตรงนี้ ต่อให้ model เก่งแค่ไหน ผลลัพธ์ก็ยังออกมาแบบเฉลี่ยๆ

Step 2: แยกให้ออกระหว่าง prompt ทั่วไปกับ skill ที่ใช้งานซ้ำได้จริง

ในคลิปมีอีกประเด็นที่น่าสนใจมาก คือเรื่อง token และ context window ซึ่งแม้จะดูเป็นเรื่องเทคนิค แต่จริงๆ กระทบคนใช้งานทั่วไปโดยตรง

หลายคนชอบยัดทุกอย่างไว้ในไฟล์คำสั่งหลัก หรือเขียน agent.md, claude.md ยาวๆ แล้วหวังว่า AI จะจำทุกอย่างตลอดเวลา ปัญหาคือไฟล์พวกนี้มักถูกโหลดเข้า context ทุก turn ทำให้กิน token ตลอด และเมื่อ context เริ่มแน่น ประสิทธิภาพจะตกลง

skill จึงสำคัญ เพราะมันใช้หลักการคล้าย progressive disclosure คือในรอบการสนทนาทั่วไป ระบบจะถือไว้แค่ชื่อกับคำอธิบายสั้นๆ ก่อน แล้วค่อยดึงรายละเอียดเต็มเมื่อจำเป็นจริง วิธีนี้ช่วยประหยัด token และทำให้ AI ไม่ต้องแบกข้อมูลที่ยังไม่เกี่ยว

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

มุมนี้มีผลมากถ้าเราเริ่มใช้ AI ในองค์กร เช่น

• ทีมขายมี skill สำหรับคัด lead, สรุปประชุม, เขียน follow-up email
• ทีมการตลาดมี skill สำหรับทำ competitor scan, สรุปรีวิวลูกค้า, แตก pain point จากคอมเมนต์
• ทีมผู้บริหารมี skill สำหรับสรุปรายงานประจำสัปดาห์ หรือเช็กสัญญาณเสี่ยงจากข้อมูลหลายแหล่ง

แทนที่จะมี prompt ยาวอันเดียวที่พยายามครอบจักรวาล เราควรแตกเป็น skill ย่อยที่มีหน้าที่ชัด ใช้ตอนจำเป็น และดูแลง่ายกว่า

Step 3: อย่าเริ่มจากการเขียน skill ให้สวย ให้เริ่มจากการทำงานจริงหนึ่งรอบก่อน

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

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

Ras Mic เสนอวิธีที่ฉลาดกว่า คือให้เดินงานนั้นกับ AI ทีละขั้นก่อน คอยแก้ คอยชี้ คอยบอกว่าอะไรดีหรือยังไม่ใช่ จนกว่าจะได้ผลลัพธ์ที่ “รันจบหนึ่งรอบแบบสะอาด” แล้วค่อยให้ AI สรุปสิ่งที่ทำสำเร็จออกมาเป็น skill

เหตุผลที่วิธีนี้ดีกว่า คือ skill จะถูกสร้างจากสิ่งที่พิสูจน์แล้วว่าใช้ได้จริง ไม่ใช่สิ่งที่เราคิดว่าน่าจะใช้ได้

ถ้าแปลงเป็นขั้นตอนสำหรับคนทำงาน จะออกมาแบบนี้

1. เลือกงานซ้ำๆ หนึ่งงานที่กินเวลา
2. สั่ง AI ให้ทำงานนั้นทีละขั้น
3. ใส่เกณฑ์ตัดสินให้ชัด เช่น ผ่าน ไม่ผ่าน ต้องถามเพิ่ม หรือหยุดทันที
4. ถ้ามันพลาด ให้แก้ตรงนั้นทันที
5. ทำซ้ำจนได้หนึ่งรอบที่ผลลัพธ์ดีจริง
6. ค่อยให้ AI เขียนออกมาเป็น skill สำหรับใช้รอบต่อๆ ไป

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

มุมมองส่วนตัวคือ วิธีนี้คล้ายการ train พนักงานใหม่มากกว่าการเขียนโปรแกรม เราไม่ได้บอกทุกอย่างตั้งแต่วันแรก แต่พาเขาทำงานจริง ให้ feedback หน้างาน แล้วค่อยกลั่นออกมาเป็นคู่มือ

Step 4: ให้ AI เขียน skill หลังจากมันเพิ่งทำสำเร็จ

ประโยคที่น่าสนใจมากจากคลิปคือ AI มักเขียน skill ได้ดีกว่ามนุษย์ หลังจากมันเพิ่งทำงานนั้นสำเร็จมา เพราะมันมี context สดๆ ว่าอะไรเวิร์กจริง

ประเด็นนี้ฟังดูขัดแย้งเล็กน้อย แต่มีเหตุผลมาก ถ้าเราเป็นคนเขียนเอง เรามักเขียนแบบนามธรรม เช่น “ตรวจสอบความน่าเชื่อถือของ lead” หรือ “พิจารณาคุณภาพของช่องทางออนไลน์” ซึ่งกว้างเกินไป แต่ถ้า AI เพิ่งรัน workflow จบ มันจะเขียนเป็นขั้นที่เฉพาะกว่า เช่น ต้องดู Twitter, YouTube, Trustpilot และถ้าหายไปเกินสองช่องให้ reject ทันที

นี่คือสิ่งที่ทำให้ skill มีคุณภาพต่างกันมาก ระหว่าง

• skill แบบเดา เขียนก่อนเจองานจริง
• skill แบบสกัดจากของจริง เขียนหลังทำงานสำเร็จแล้ว

สำหรับองค์กรที่เริ่มใช้ AI เราแนะนำให้เก็บวิธีทำงานแบบนี้เป็นมาตรฐานเลย คืออย่าเพิ่งรีบสร้างคลัง skill จำนวนมาก แต่ให้สร้างทีละอันจาก use case ที่ผ่านการพิสูจน์แล้ว

ถ้าอยากศึกษาหลักคิดเรื่องการออกแบบ workflow และระบบอัตโนมัติให้ชัดขึ้น แหล่งอย่าง Anthropic และ OpenAI Docs มีเอกสารที่ช่วยทำความเข้าใจวิธีคิดเรื่อง context, tools และการจัดระบบคำสั่งได้ดี แม้จะไม่ใช่สายเทคนิคจ๋าก็ตาม

Step 5: ทดสอบ skill และปรับจากความล้มเหลว ไม่ใช่หวังให้สมบูรณ์ตั้งแต่ครั้งแรก

อีกจุดที่คลิปนี้พูดได้ตรงมากคือ skill ที่สร้างเสร็จแล้ว ไม่ได้แปลว่าจบ งานจริงจะมี edge case เสมอ และ AI ก็ยังพลาดได้

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

วงจรนี้เรียบง่ายมาก

1. ทดสอบ skill กับเคสจริง
2. ถ้ามันพังหรือให้ผลลัพธ์แปลก ให้ถามว่าพลาดเพราะอะไร
3. ช่วยกันแก้ logic กับ AI
4. อัปเดต skill ให้จดจำบทเรียนนี้
5. ทดสอบอีกครั้ง

ในคลิปมีตัวอย่างว่า Ras Mic ทำลูปนี้หลายรอบกับงานสร้างรายงาน YouTube analytics จนสุดท้าย agent สามารถดึงข้อมูลจากหลายแหล่งและรันจบได้ในเวลาประมาณสิบนาที

มุมนี้สำคัญมากสำหรับธุรกิจ เพราะหลายทีมมักเลิกใช้ AI หลังจากเจอความผิดพลาด 2-3 ครั้ง แล้วสรุปว่า “มันยังใช้ไม่ได้” แต่ความจริงคือ ถ้างานนั้นมีมูลค่าและทำซ้ำบ่อย เราควรใช้ความผิดพลาดเหล่านั้นเป็นวัตถุดิบในการทำให้ระบบฉลาดขึ้น

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

Step 6: เริ่มจาก agent เดียวที่ทำงานได้จริง ก่อนคิดเรื่องระบบหลาย agent

คนจำนวนมากชอบภาพของ multi-agent system เพราะดูฉลาด ดูล้ำ และเหมือนองค์กรมีทีม AI เต็มรูปแบบ แต่ Ras Mic เตือนชัดว่า ถ้ายังไม่มี workflow ที่นิ่ง การเพิ่ม sub-agent จะยิ่งเพิ่มความซับซ้อน

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

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

ตัวอย่างสำหรับบริษัทไทยอาจเป็นแบบนี้

• เริ่มจาก agent กลางสำหรับทีมขาย ที่ทำได้ทั้งคัด lead, สรุปคอล, ร่างอีเมล
• พอใช้งานไปสักพัก เจอว่าการคัด lead ซับซ้อนมากและมีเกณฑ์เฉพาะเยอะ ค่อยแยกเป็น sub-agent สำหรับ lead scoring
• หรือถ้าทีมการตลาดใช้ AI ทำรีเสิร์ชคู่แข่งทุกสัปดาห์ จึงค่อยแยก agent สำหรับ competitor intelligence โดยเฉพาะ

หลักคิดนี้ลดความฟุ้ง และทำให้ทีมเห็น ROI เร็วกว่าการออกแบบสถาปัตยกรรมหรูตั้งแต่ต้น

Step 7: แปลงแนวคิดนี้ให้ใช้กับธุรกิจไทยแบบจับต้องได้

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

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

งานที่เหมาะกับการเริ่มต้นที่สุดคือ งานที่มี 3 คุณสมบัติพร้อมกัน

• ทำซ้ำบ่อย
• มีเกณฑ์ตัดสินพอสมควร
• ถ้าทำได้ดีจะคืนเวลาให้ทีมเยอะ

เช่น การคัด lead, การคัดร้านค้า, การสรุปรีวิวลูกค้า, การคัดคำถามที่ควร escalate, หรือการสรุปรายงานรายสัปดาห์จากหลายแหล่ง

ถ้าเราเริ่มจาก use case แบบนี้ โอกาสที่จะเห็นผลจริงจะสูงกว่าเริ่มจากงานที่กว้างและกำกวม เช่น “ทำการตลาดให้หน่อย” หรือ “วางกลยุทธ์ธุรกิจให้หน่อย”

Actionable Insights

• เริ่มจากงานซ้ำงานเดียว อย่ารีบทำ AI ให้ครอบทุกอย่าง เลือกงานที่กินเวลาและทำทุกสัปดาห์ก่อน
• นิยามเกณฑ์ผ่านและไม่ผ่านให้ชัด ถ้าเราอธิบายไม่ได้ว่าอะไรคือผลลัพธ์ที่ดี AI ก็ทำออกมาดีสม่ำเสมอไม่ได้
• ทำ one clean run ก่อนค่อยสร้าง skill ให้ AI ทำงานจริงจนสำเร็จหนึ่งรอบ แล้วค่อยสรุปออกมาเป็น skill
• เก็บความผิดพลาดเป็นทรัพย์สิน ทุกครั้งที่ AI พลาด ให้เพิ่มบทเรียนนั้นกลับเข้า skill แทนที่จะเริ่มใหม่ทุกครั้ง
• อย่าเพิ่งซับซ้อนเกินจำเป็น agent เดียวที่ใช้ได้จริง มีค่ามากกว่าหลาย agent ที่ดูดีแต่พังบ่อย

Troubleshooting

• ปัญหา: AI ตอบออกมาดูดีแต่ใช้ตัดสินใจไม่ได้

สาเหตุ: โจทย์กว้างเกินไป และไม่มีเกณฑ์ reject ที่ชัด

วิธีแก้: ระบุเงื่อนไขให้ชัดว่าอะไรคือผ่าน อะไรคือไม่ผ่าน และอะไรต้องหยุดทันที

• ปัญหา: สร้าง skill แล้วแต่ผลลัพธ์ยังไม่นิ่ง

สาเหตุ: skill ถูกเขียนจากการเดา ไม่ได้มาจาก workflow ที่พิสูจน์แล้ว

วิธีแก้: กลับไปทำงานจริงกับ AI ทีละขั้นจนได้รอบที่สำเร็จ แล้วค่อยให้มันเขียน skill ใหม่

• ปัญหา: AI เริ่มตอบแย่ลงเมื่อคุยนานขึ้น

สาเหตุ: context แน่นเกินไป เพราะยัดคำสั่งยาวๆ ไว้ตลอดทุก turn

วิธีแก้: แยกงานออกเป็น skill เฉพาะทาง และลดข้อมูลที่ไม่จำเป็นในคำสั่งหลัก

• ปัญหา: ทีมเริ่มสับสนเพราะมี agent หลายตัวเกินไป

สาเหตุ: ขยายระบบเร็วเกินก่อนมี workflow ที่นิ่ง

วิธีแก้: รวมกลับมาเริ่มที่ agent หลักตัวเดียว แล้วสร้าง skill ย่อยให้แข็งแรงก่อน

• ปัญหา: เจอข้อผิดพลาดเดิมซ้ำๆ

สาเหตุ: ไม่มีการอัปเดต skill หลังจากเจอเคสพลาด

วิธีแก้: ทุกครั้งที่พลาด ให้ถามหาสาเหตุ แก้ logic แล้วบันทึกลง skill ทันที

การต่อยอด

• สร้าง skill library สำหรับแต่ละทีม เช่น ขาย การตลาด HR และบริการลูกค้า โดยเริ่มจาก 1-2 งานที่ใช้จริงก่อน
• ทำ review loop รายสัปดาห์ ให้ทีมเก็บเคสที่ AI พลาด แล้วอัปเดต skill เป็นรอบๆ เหมือนอัปเดตคู่มือทำงาน
• เชื่อม skill เข้ากับข้อมูลของบริษัท เช่น CRM, spreadsheet หรือรีวิวลูกค้า เพื่อให้ AI ทำงานจากข้อมูลจริง ไม่ใช่เดา

สรุป Checklist ทั้งหมด

• ☐ เลือกงานที่ทำซ้ำบ่อยและมีมูลค่าสูงพอจะลงทุนทำ skill
• ☐ กำหนดให้ชัดว่าอะไรคือผลลัพธ์ที่ดี และอะไรคือเหตุผลที่ต้อง reject
• ☐ ลองทำ workflow นั้นกับ AI ทีละขั้นแบบงานจริง
• ☐ แก้จุดพลาดระหว่างทางจนได้ one clean run
• ☐ ให้ AI สรุปสิ่งที่ทำสำเร็จออกมาเป็น skill
• ☐ ทดสอบ skill กับเคสจริงหลายแบบ
• ☐ ถ้ามีพลาด ให้ถามหาสาเหตุและอัปเดต skill ทันที
• ☐ ลดคำสั่งถาวรที่ยาวเกินจำเป็น เพื่อไม่ให้กิน token ตลอดเวลา
• ☐ เริ่มจาก agent เดียวก่อน แล้วค่อยแตกเป็น sub-agent เมื่อจำเป็นจริง
• ☐ ตั้งรอบทบทวน skill เป็นประจำ เพื่อให้ระบบเก่งขึ้นเรื่อยๆ

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

สำหรับเจ้าของธุรกิจและคนทำงาน นี่เป็นมุมที่สำคัญมาก เพราะคนที่ได้ผลจาก AI ระยะยาว มักไม่ใช่คนที่ใช้ model ใหม่ที่สุด แต่เป็นคนที่สร้าง workflow และ skill ได้คมที่สุดต่างหาก