
Anthropic Skills: เลิกสั่ง AI ซ้ำ แล้วทำ SOP ให้ Agent ใช้เอง
หลายทีมเริ่มใช้ AI ทำงานจริงแล้วครับ
แต่ปัญหาที่ผมเห็นบ่อยมากคือ เรายังใช้ AI แบบ “สั่งซ้ำ” มากกว่า “ออกแบบระบบให้ทำซ้ำ”
วันนี้บอกให้ช่วยเขียนโพสต์ พรุ่งนี้บอกให้ช่วยเขียนแบบเดิม อาทิตย์หน้าบอกให้ช่วยทำ report format เดิม เดือนหน้าบอกให้ช่วย review งานแบบเดิมอีก
แล้วพอ AI เปลี่ยน session หรือคนในทีมใช้คนละ wording ผลลัพธ์ก็เริ่มไม่เหมือนกัน
นี่คือเหตุผลที่ผมว่า Anthropic Skills น่าสนใจมาก
ไม่ใช่เพราะมันเป็นฟีเจอร์ใหม่ของ Claude อย่างเดียว แต่เพราะมันสะท้อนทิศทางใหญ่ของ AI Agent:
AI ที่ทำงานจริงต้องมี SOP ของตัวเอง
1) Skills ไม่ใช่ prompt ยาว ๆ
จาก repo anthropics/skills และเอกสารของ Anthropic, skill คือ folder ที่มี SKILL.md เป็นแกนกลาง และอาจมี scripts, references, assets, templates, examples หรือ resources อื่น ๆ อยู่ด้วย
โครงสร้างง่าย ๆ คือ:
my-skill/
├── SKILL.md
├── scripts/
├── references/
├── assets/
└── templates/
SKILL.md จะมี metadata เช่น name และ description เพื่อให้ agent รู้ว่า skill นี้ควรถูกใช้เมื่อไหร่
ส่วนเนื้อหาด้านในคือขั้นตอน วิธีคิด checklist ตัวอย่าง และข้อควรระวังของงานนั้น
Anthropic เขียนไว้ชัดว่า misconception หนึ่งคือคนคิดว่า skills เป็น “แค่ markdown files” แต่จริง ๆ มันเป็น folder ที่ agent สามารถสำรวจ ใช้ script เปิด reference หรือดึง asset ได้ตามงาน
ถ้าเปรียบง่าย ๆ:
- Prompt คือคำสั่งที่เราพิมพ์ตอนนั้น
- Skill คือคู่มือทำงานที่ agent หยิบมาใช้ซ้ำได้
- MCP คือช่องทางเชื่อม tool หรือ data
- Subagent คือคนทำงานเฉพาะทางอีกคน
ดังนั้น Skill ไม่ได้มาแทน MCP แต่ Skill บอก AI ว่าเมื่อมี MCP หรือ tool แล้ว ควรใช้ยังไงให้ถูก workflow
2) Progressive disclosure คือหัวใจ
จุดที่ผมชอบมากคือแนวคิด progressive disclosure
AI ไม่ต้องโหลดคู่มือทุกหน้าเข้าหัวตั้งแต่ต้น แต่โหลดทีละชั้นตามความจำเป็น
Anthropic และ Agent Skills standard อธิบายเป็น 3 ชั้น:
- Metadata
โหลดแค่ชื่อและ description ก่อน เพื่อให้ model รู้ว่า skill นี้เกี่ยวกับอะไรและควรถูกเรียกเมื่อไหร่
- Main instructions
ถ้างานตรงกับ skill นั้นจริง ค่อยโหลด SKILL.md ทั้งไฟล์
- References / scripts / assets
ถ้างานต้องใช้รายละเอียดเพิ่ม ค่อยเปิดไฟล์ใน references/, ใช้ script, หรือหยิบ template จาก assets/
นี่คือวิธีคิดที่สำคัญมากสำหรับทีมที่อยากใช้ AI ในงานจริง
เพราะถ้าเอาทุก SOP, ทุก guideline, ทุก API doc, ทุก template ยัดเข้า system prompt ตลอดเวลา สุดท้าย context จะบวม agent จะช้า และคำสั่งหลายอย่างจะชนกันเอง
Skill ทำให้เราเก็บความรู้เยอะได้ แต่ให้ agent อ่านเฉพาะส่วนที่ต้องใช้จริง
3) Anthropic ใช้ skills ภายในหลายร้อยตัว
บทความ Lessons from building Claude Code: How we use skills วันที่ 2026-06-03 บอกว่า Anthropic ใช้ skills ใน Claude Code ภายในหลายร้อยตัว
และพบว่า skills แบ่งได้เป็น 9 กลุ่มใหญ่ เช่น:
- Library and API reference
เช่น คู่มือใช้ internal library, CLI, SDK, gotchas, ตัวอย่าง code
- Product verification
เช่น skill ที่ให้ AI ทดสอบ signup flow, checkout, CLI, browser, state assertion
- Data fetching and analysis
เช่น skill สำหรับ query funnel, cohort, Grafana, Datadog หรือ dashboard เฉพาะบริษัท
- Business process and team automation
เช่น standup post, weekly recap, create ticket, ping reviewer
- Code scaffolding and templates
เช่นสร้าง migration, handler, workflow, app skeleton ตาม template บริษัท
- Code quality and review
เช่น adversarial review, code style, testing practices
- CI/CD and deployment
เช่น babysit PR, deploy, smoke test, rollback, cherry-pick prod
- Runbooks
เช่น on-call runner, log correlator, incident debugging
- Infrastructure operations
เช่น cost investigation, dependency management, cleanup flow ที่ต้องมี guardrail
อ่านแล้วจะเห็นว่า Skills ไม่ได้เกิดมาเพื่อ “เขียน prompt ให้สวย” แต่มันเกิดมาเพื่อเก็บงานที่ทีมทำซ้ำ แล้วให้ agent ทำตาม playbook เดิมได้แม่นขึ้น
4) Verification skill คือจุดที่ธุรกิจควรเอาไปใช้ก่อน
ประโยคที่ผมว่าแรงที่สุดใน blog ของ Anthropic คือ:
Verification skills have had the most measurable impact on Claude’s output quality internally.
แปลแบบภาษาคนทำงาน: AI เก่งขึ้นชัดที่สุด เมื่อเราสอนมันว่าต้องตรวจงานยังไงก่อนบอกว่าเสร็จ
นี่ตรงกับ pain ของธุรกิจมาก
หลายทีมใช้ AI ทำงานได้แล้ว แต่ยังไม่มี proof loop
เช่น AI บอกว่า:
- หน้าเว็บแก้แล้ว
- report ทำแล้ว
- campaign วิเคราะห์แล้ว
- customer list สรุปแล้ว
- code test แล้ว
แต่ถามว่า “หลักฐานอยู่ไหน” หลายครั้งตอบไม่ได้
Verification skill แก้ตรงนี้โดยบังคับให้ agent ทำขั้นตรวจจริง เช่น:
- เปิด browser แล้ว capture proof
- เช็ค state หลัง submit form
- run test เฉพาะจุด
- ตรวจ invoice ว่า status ถูกจริง
- บันทึก video หรือ screenshot
- assert ว่า output ตรง schema
สำหรับผม นี่คือหัวใจของ AI Agent ที่ใช้ในธุรกิจ
AI ที่ดีไม่ใช่แค่ทำงานได้ แต่ต้องพิสูจน์ได้ว่าทำถูก
5) Gotchas สำคัญกว่า guideline สวย ๆ
Anthropic บอกว่า content ที่ high-signal ที่สุดใน skill คือ Gotchas section
ผมเห็นด้วยมากครับ
เพราะสิ่งที่ทำให้ AI พลาดในงานจริงมักไม่ใช่ข้อมูลพื้นฐาน แต่มันคือรายละเอียดเล็ก ๆ ที่คนในทีมรู้จากประสบการณ์
ตัวอย่าง:
- ตารางนี้เป็น append-only ต้องเลือก row version สูงสุด ไม่ใช่ created_at ล่าสุด
- staging ตอบ 200 แม้ webhook ยังไม่ process ต้องดู table อีกตัว
- field นี้ใน gateway เรียก
request_idแต่ใน billing service เรียกtrace_id - ถ้าจะ deploy service นี้ ต้อง smoke test route นี้ก่อนเสมอ
- ถ้า user เป็น legacy customer ต้องดู entitlement จากระบบเก่าด้วย
นี่คือความรู้แบบ “เคยเจ็บมาแล้ว”
ถ้าไม่เขียนลง skill, AI จะพลาดซ้ำ ถ้าเขียนลง skill, ครั้งหน้ามันมีโอกาสจำวิธีหลบหลุมมากขึ้น
สำหรับ Data-Espresso ผมมองว่าองค์กรไทยควรเริ่มเก็บ gotchas ของ AI workflow ตั้งแต่วันนี้ ไม่ใช่รอให้มี AI strategy ใหญ่โตแล้วค่อยทำ
6) Skills เป็น layer ระหว่าง prompt กับ platform ใหญ่
ในบทความ Skills explained, Anthropic แยกบทบาทไว้ค่อนข้างชัด:
- Prompt ใช้กับงานเฉพาะหน้าที่จบใน conversation เดียว
- Project ใช้เก็บบริบทของงานหรือ knowledge base ระยะยาว
- Skill ใช้เก็บ procedural expertise ที่ใช้ซ้ำได้
- Subagent ใช้เมื่อต้องการ agent แยกที่มีหน้าที่เฉพาะ
- MCP ใช้ต่อ tool และ data ภายนอก
มุมนี้สำคัญมากครับ
เพราะหลายคนตอนนี้เอาทุกอย่างไปใส่ใน prompt เดียว หรือไม่ก็รีบกระโดดไปทำ agent framework หนัก ๆ ตั้งแต่วันแรก
แต่สำหรับธุรกิจส่วนใหญ่ ทางที่ practical กว่าคือ:
- เริ่มจาก prompt เพื่อทดลอง
- ถ้าใช้ซ้ำเกิน 3 รอบ ให้แปลงเป็น skill
- ถ้าต้องแตะระบบภายนอก ให้ต่อ MCP หรือ API
- ถ้างานเริ่มยาวและต้องแยกหน้าที่ ให้ใช้ subagent
- ถ้ามีหลายทีม ใช้ marketplace หรือ repo เป็น distribution layer
พูดง่าย ๆ: Skill คือชั้นกลางที่ทำให้ AI ทำงานซ้ำได้ โดยยังไม่ต้องสร้าง platform ใหญ่เองทั้งหมด
7) Open standard ทำให้เรื่องนี้ไม่ใช่แค่ Claude
Agent Skills standard ที่ agentskills.io บอกชัดว่า goal คือ standardized way to give AI agents new capabilities and expertise
ในหน้า showcase มีหลาย client ที่รองรับหรืออ้างอิงแนวคิด skills เช่น Claude, Claude Code, OpenAI Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, OpenHands, Goose, Roo Code และอื่น ๆ
ตรงนี้เป็นสัญญาณใหญ่ครับ
ถ้า skills กลายเป็น format กลางจริง ความรู้การทำงานขององค์กรจะไม่ถูกผูกกับ chatbot ตัวเดียว
SOP ของ AI อาจกลายเป็น artifact ที่ย้ายข้าม agent ได้ เหมือน repo code หรือ runbook ที่ version control ได้
นี่คือเหตุผลที่ผมมองว่า Skills เป็นเรื่องใหญ่กว่า feature
มันคือรูปแบบใหม่ของการเก็บ operational knowledge ให้ AI ใช้
8) แต่ Skills ก็มีความเสี่ยง
อย่าเข้าใจผิดว่าแค่มี skill แล้วทุกอย่างจะปลอดภัยครับ
มีข้อควรระวังหลายจุด:
- Skill ที่กว้างเกินไปทำให้ routing งง
Anthropic บอกเองว่า skills ที่พยายามทำหลาย category พร้อมกันจะ confuse agent
- Description field สำคัญมาก
Description ไม่ใช่สรุปให้คนอ่าน แต่เป็น trigger ให้ model ตัดสินใจว่าจะโหลด skill เมื่อไหร่ ถ้าเขียนกว้างเกินไป skill จะถูกเรียกผิดงาน ถ้าเขียนแคบเกินไป skill จะไม่ถูกเรียกตอนควรใช้
- Tool compatibility ต้องทดสอบ
GitHub issue #1154 ใน repo anthropics/skills ชี้ปัญหาว่า skill ที่อ้าง tool ที่ไม่มีใน platform นั้น อาจ fail เงียบหรือถูกแทนด้วย tool อื่นที่ semantics ไม่เหมือนกัน
นี่คือเรื่องใหญ่สำหรับ cross-platform skill เพราะ Claude.ai, Claude Code, API, หรือ agent client อื่น ๆ อาจมี tool set ไม่เหมือนกัน
- API Skills มี data-retention caveat
Claude API docs ระบุว่า Agent Skills feature ไม่เข้า Zero Data Retention ดังนั้นถ้าทีมทำงานกับข้อมูลอ่อนไหว ต้องอ่าน policy และออกแบบ data boundary ให้ชัดก่อนใช้
- Scripts ใน skills ต้องมี security boundary
ถ้า skill มี script, dependency, credential, หรือ file access ก็ต้องคิดเรื่อง permission, sandbox, secret handling, approval และ audit proof
Skill ที่ดีจึงไม่ใช่แค่ “เขียนละเอียด” แต่ต้องถูกทดสอบ ถูกจำกัด scope และมี proof loop
9) ธุรกิจไทยควรเริ่มจากตรงไหน
ถ้าทีมคุณอยากเริ่มใช้แนวคิด Skills ผมแนะนำแบบนี้ครับ
ขั้นที่ 1: หา workflow ที่สั่ง AI ซ้ำบ่อย
ไม่ต้องเริ่มจากงานใหญ่สุด เริ่มจากงานที่เจอบ่อยและมี input/output ชัด เช่น:
- สรุปประชุมเป็น action items
- เขียนโพสต์ตาม brand voice
- ตรวจ sales proposal ก่อนส่ง
- วิเคราะห์ campaign รายสัปดาห์
- ทำ lead research
- QA หน้า landing page
- ตรวจเอกสาร policy
- สรุป customer conversation
ถ้างานนั้นถูกสั่งซ้ำเกิน 3 รอบ มีโอกาสสูงว่าควรถูกทำเป็น skill
ขั้นที่ 2: เขียน trigger ให้ชัด
Skill ต้องบอกว่าใช้เมื่อไหร่
ตัวอย่างไม่ดี:
description: ช่วยทำ marketing
ตัวอย่างที่ดีกว่า:
description: สร้าง Facebook post สำหรับ Data-Espresso Deep Dive จาก draft ที่มีแหล่งอ้างอิงแล้ว ใช้เมื่อผู้ใช้บอกว่าให้ทำ Facebook copy, social post, หรือ Deep Dive promo
ยิ่ง trigger ชัด agent ยิ่งเลือกใช้ skill ถูก
ขั้นที่ 3: ใส่ checklist และ gotchas ก่อนใส่ทฤษฎี
อย่าเริ่มจาก essay ยาว ๆ ให้เริ่มจากสิ่งที่ AI ต้องทำและต้องระวัง
เช่น:
- ต้องอ่านไฟล์ไหนก่อน
- ห้ามทำอะไร
- ต้องตรวจอะไรหลังทำเสร็จ
- error ไหนเจอบ่อย
- หลักฐานแบบไหนถึงเรียกว่า done
ขั้นที่ 4: ใส่ script เฉพาะงานที่ควร deterministic
งานบางอย่างให้ AI คิดเองได้ แต่งานบางอย่างควรใช้ code เช่น:
- validate JSON schema
- count hashtags
- scan secret pattern
- check URL status
- render screenshot
- compare CSV
- extract metadata
ถ้าทำด้วย script ได้แม่นกว่า ให้ skill เรียก script อย่าให้ LLM เดาทุกอย่างเอง
ขั้นที่ 5: สร้าง verification skill แยก
ผมแนะนำให้มี skill แยกสำหรับ “ตรวจว่างานเสร็จจริงไหม”
เช่น:
- web-page-verifier
- checkout-verifier
- draft-validator
- campaign-audit-checker
- customeros-response-checker
เพราะถ้า skill เดียวทั้งทำงานและตรวจงาน บางครั้ง agent จะ bias เข้าข้างงานตัวเอง การแยก checker ช่วยให้เห็นปัญหาชัดขึ้น
10) OPB Stack มุมมอง: Skills คือ playbook ของ AI Coworker
ถ้ามองจาก OPB Stack หรือ AI coworker sandbox, Skills คือส่วนที่ทำให้ agent ไม่ใช่แค่คนตอบคำถาม
แต่เป็นคนทำงานที่มีคู่มือ มีความจำเชิงกระบวนการ และมีวิธีตรวจผลงาน
ธุรกิจหนึ่งอาจมี skills เช่น:
sales-followupweekly-owner-reportlead-triagecustomer-reply-reviewlanding-page-qacourse-support-rescuepayment-slip-checkcontent-deep-dive-production
แต่ละ skill คือ playbook ย่อยของ AI worker
เมื่อรวมกับ sandbox, tools, MCP, approval gate และ proof log เราจะเริ่มเห็นภาพ AI coworker ที่ทำงานต่อเนื่องได้จริงมากขึ้น
ถ้าอยากเห็นภาพแบบ managed sandbox ที่มี AI coworker, skills, tools, memory, approval และ workflow อยู่ในที่เดียว ลองดู OPB Stack ได้ที่ https://opbstack.com/?ref=data-espresso ครับ
สรุป
ในความเห็นของผม Anthropic Skills ไม่ใช่ข่าวฟีเจอร์เล็ก ๆ
มันเป็นสัญญาณว่าโลก AI Agent กำลังเปลี่ยนจาก prompt engineering ไปสู่ workflow engineering
Prompt ยังสำคัญครับ แต่ถ้างานนั้นต้องทำซ้ำ ต้องมีคุณภาพสม่ำเสมอ ต้องมีเครื่องมือ ต้องมีข้อควรระวัง และต้องมีหลักฐานว่างานเสร็จจริง งานนั้นไม่ควรอยู่ใน prompt ชั่วคราวอีกต่อไป
มันควรถูกเขียนเป็น Skill
สำหรับธุรกิจไทย ผมจะจำง่าย ๆ แบบนี้:
ถ้าสั่ง AI เรื่องเดิมเกิน 3 รอบ ให้เริ่มทำเป็น SOP ถ้า AI ทำงานแล้วต้องมีหลักฐาน ให้ทำ verification skill ถ้า AI แตะข้อมูลหรือระบบจริง ให้มี sandbox, permission, approval และ audit log
สุดท้าย AI ที่ใช้ได้จริงในบริษัท ไม่ใช่ตัวที่ตอบเก่งที่สุดครับ แต่คือตัวที่ทำงานตาม playbook ได้ ตรวจงานตัวเองได้ และรู้ว่าอะไรต้องให้คนอนุมัติก่อน
