บทความนี้ใช้กรณีศึกษาจริง — กระบวนการกำเนิดทักษะ "SEO ตรวจสุขภาพ" — เพื่อสรุปงานที่ต้องทำ คำสั่งที่ใช้ และข้อผิดพลาดที่เคยเจอ เหมาะสำหรับผู้ที่ต้องการทำให้เวิร์กโฟลว์ที่ทำซ้ำ ๆ ของตนกลายเป็นทักษะที่นำกลับมาใช้ซ้ำได้
หนึ่ง、SKILL คืออะไร และทำไมต้องสร้าง
SKILL คือการนำชุดเวิร์กโฟลว์หลายขั้นตอนมาทำให้เป็นแพ็กเกจความสามารถที่นำกลับมาใช้ซ้ำได้ ทำครั้งเดียวเสร็จ หลังจากนั้นเพียงประโยคเดียวก็เรียกใช้ทั้งกระบวนการได้ ไม่ต้องอธิบายใหม่ทุกครั้ง
SKILL หนึ่งตัวโดยพื้นฐานแล้วคือโฟลเดอร์หนึ่งโฟลเดอร์:
skill-name/
├── SKILL.md ← 核心:流程说明 + 触发词 + 输入 + 经验
├── scripts/ ← 可选:可复用的代码脚本
│ └── *.py
└── evals/ ← 可选:测试用例
└── evals.json
สัญญาณที่บ่งบอกว่าเหมาะทำเป็น SKILL: สิ่งนี้คุณจะทำซ้ำ มีขั้นตอน ≥2 มีผลลัพธ์ที่ชัดเจน และเปลี่ยนวัตถุ (URL/ลูกค้า/โปรเจกต์) แล้วยังใช้ได้
สอง、กระบวนการโดยรวมในการสร้าง SKILL (5 ขั้นตอน)
การสร้างทักษะเองก็มี "เมตาทักษะ" มาคอยแนะนำ แกนหลักคือ 5 ขั้นตอนนี้:
| ขั้นตอน | ทำอะไร | คำสั่ง/เครื่องมือที่ใช้ |
|---|---|---|
| 1. ทำให้เวิร์กโฟลว์ทำงานได้จริงหนึ่งรอบก่อน | ทำภารกิจจริงให้เสร็จสมบูรณ์หนึ่งครั้ง ได้ผลลัพธ์จริง | สนทนาตามปกติก็ได้ |
| 2. ยืนยันโครงกระดูกของทักษะ | ตั้งชื่อสกิล ชื่อที่แสดง คำทริกเกอร์ รายการอินพุต ไอคอน | ยืนยันกับ AI |
| 3. ดึงข้อมูลเซสชัน | ดึงเครื่องมือที่ใช้แล้วโดยอัตโนมัติ สร้างโครงร่าง | extract_session_data |
| 4. เขียน SKILL.md | เติมขั้นตอน ประสบการณ์ สคริปต์ให้ครบ | AI สร้าง คนตรวจสอบ |
| 5. บันทึก + ทดสอบ | จัดเก็บในคลังสกิล สร้างกรณีทดสอบ | save_skill + generate_skill_evals |
สาม、แยกย่อยทีละขั้น: แต่ละขั้นทำอะไรบ้าง
ขั้นที่ 1: รันเวิร์กโฟลว์ให้ผ่านก่อน (สำคัญที่สุด)
อย่าเพิ่งรีบสร้างสกิล เริ่มจากหยิบความต้องการจริงมาทำให้ครบหนึ่งรอบ เช่น: "ช่วยตรวจ SEO ของหน้าเว็บนี้ให้หน่อย" ในระหว่างนี้:
- ระบุให้ชัดอินพุตคืออะไร (หนึ่ง URL? หลาย URL?)
- ระบุให้ชัดผลลัพธ์คืออะไร (รายงานหนึ่งฉบับ? รูปแบบใด?)
- บันทึกว่าแต่ละขั้นใช้ความสามารถอะไร (เปิดหน้าเว็บ รันโค้ด สร้าง Excel……)
บทเรียนจากการปฏิบัติจริง: สกิล SEO ของเราเกิดขึ้นหลังตรวจหน้าเว็บหลายหน้าของเว็บไซต์ทางการของบริษัทแห่งหนึ่งอย่างจริงจัง และปรับรูปแบบรายงานซ้ำหลายรอบ แล้วจึงกลั่นเป็นสกิล ระหว่างนั้นผู้ใช้เรียกร้องเพิ่มตลอด (เพิ่มมาตรฐาน Bing ตรวจสอบแหล่งที่มาทางการ เปลี่ยนเป็นเมทริกซ์การดำเนินการ แยกเป็นสองระยะ……) สิ่งเหล่านี้กลายเป็นส่วนที่มีค่าที่สุดในสกิล
ขั้นที่ 2: ยืนยันโครงร่างสกิล
บอก AI ให้ชัด (หรือให้มันเสนอ):
| โครงการ | คำอธิบาย | ตัวอย่าง |
|---|---|---|
| ชื่อสกิล | ตัวพิมพ์เล็กคั่นด้วยขีดกลาง ตัวระบุภายใน | seo-audit-skill |
| ชื่อที่แสดง | ชื่อที่คนอ่าน | 「ตรวจสุขภาพ SEO」 |
| คำทริกเกอร์ | คำพูดแบบใดที่ควรกระตุ้นมัน | "ตรวจสุขภาพ SEO / ปรับแต่งเว็บไซต์ / ตรวจ SEO หน้าเว็บ" |
| รายการอินพุต | สิ่งที่เปลี่ยนแปลงทุกครั้ง | page_url、audit_scope |
| ไอคอน | emoji หนึ่งตัว | 🔍 |
ขั้นตอนที่ 3: ดึงข้อมูลเซสชัน
ขั้นตอนนี้เครื่องมือทำให้อัตโนมัติ: สแกนเซสชันที่เพิ่งรันผ่าน ดึงรายการเครื่องมือที่ใช้ สร้างโครง SKILL.md ที่มี YAML frontmatter คุณเพียงแค่ระบุสิ่งที่กำหนดไว้ในขั้นตอนที่ 2: ชื่อสกิล คำทริกเกอร์ รายการอินพุต ชื่อที่แสดง ไอคอน
คำสั่ง:extract_session_data
ขั้นตอนที่ 4: เขียน SKILL.md (การสร้างสรรค์หลัก)
เติมส่วนต่อไปนี้บนพื้นฐานของโครง:
① frontmatter (ส่วนหัวไฟล์)
---
name: seo-audit-skill
display_name: 「SEO 体检」
description: "一句话说清楚它做什么、什么时候该触发"
icon: "🔍"
trigger: SEO体检 audit 网站优化 网站SEO
inputs:
- name: page_url
description: "要体检的页面网址"
required: true
scripts: [seo_audit.py, seo_matrix.py]
---
② Overview
อธิบาย 2–3 ประโยคว่าทำอะไร ใช้เมื่อไหร่
③ Workflow (แบ่งขั้นตอน)
แต่ละขั้นระบุโหมด (deterministic การกระทำคงที่ / agentic ต้องตัดสินใจ), อินพุต, เอาต์พุต, วิธีตรวจสอบ, หากล้มเหลวทำอย่างไรอธิบาย "ทำไม" ให้มาก ลดการเขียน "ต้อง/ห้าม" แบบแข็งทื่อ—— AI ที่รันสกิลเข้าใจ "การอธิบายเหตุผล" ได้ดีกว่า
④ Output
ผลลัพธ์สุดท้ายหน้าตาเป็นอย่างไร กำหนดรูปแบบให้ชัดเจน
⑤ Lessons Learned (บทเรียน)
นี่คือจุดแบ่งคุณภาพของสกิล แบ่งเป็นสี่ส่วน:
- Do: วิธีใดได้ผล
- Don't: หลุมไหนอย่าเหยียบ
- Common Failures: ข้อผิดพลาดที่พบบ่อย + การรับมือ
- When to Ask the User: เมื่อไหร่ควรหยุดถามคน
บทเรียนจริง: Lessons ของสกิลนี้เต็มไปด้วยหลุมที่เหยียบจริง——ภาษาจีนอย่าใช้\uXXXXescape, เขียน CSV ใช้utf-8-sigป้องกัน Excel อ่านเพี้ยน, อัตรา alt รูปภาพขาดสูงผิดปกติส่วนใหญ่เป็นการรายงานผิดจากการ lazy load (ต้องทำเครื่องหมาย "รอตรวจ" ไม่ใช่ตัดสินว่าขาดทันที), บางโดเมนบล็อกการดึงข้อมูลแบบกลุ่ม ต้องใช้เบราว์เซอร์ตรวจสอบ…… "น้ำตานองเลือด" เหล่านี้ทำให้สกิลรันครั้งต่อไปเสถียรขึ้น
⑥ สคริปต์ (ไม่บังคับแต่แนะนำอย่างยิ่ง)
หากในโฟลว์มีโค้ดที่เขียนซ้ำ ให้แยกเป็นสคริปต์วางไว้ scripts/,อ้างอิงใน SKILL.md เราได้ทำ "JS เก็บสัญญาณหน้าเว็บ" และ "สร้างเมทริกซ์หลายหน้า" เป็นสองสคริปต์ เพื่อให้รูปแบบเอาต์พุตสอดคล้องกันทุกครั้ง
ขั้นตอนที่ 5: บันทึก + ทดสอบ
- คำสั่งบันทึก:
save_skill(ชื่อสกิล + SKILL.md ฉบับเต็ม + สคริปต์) - สร้างการทดสอบ:
generate_skill_evals(สร้างกรณีทดสอบอัตโนมัติหลายรายการ) - จากนั้นรันจริงหนึ่งครั้งเพื่อตรวจสอบ——เราใช้สถานการณ์แบบหน้าเดียวและหลายหน้าทดสอบจริงแยกกัน ยืนยันว่าสามารถระบุปัญหาจริงได้ (เช่น ตรวจจับลิงก์เสีย 404 หลายรายการ พบว่าชื่อเรื่องแชร์โซเชียลไม่ตรงกับชื่อเรื่องหน้าเว็บ)
สี่ วิธีวนซ้ำและเผยแพร่หลังสร้างเสร็จ
ปรับปรุงแบบวนซ้ำ
คำสั่ง:load_skill_for_improvementสกิลไม่ได้สร้างเสร็จในครั้งเดียว หลังใช้หลายครั้งจึงปรับปรุงตามต้องการ:
- แก้กระบวนการ เพิ่มรูปแบบเอาต์พุต ปรับคำทริกเกอร์
- เมื่อบันทึกใช้ชื่อสกิลเดิมก็เขียนทับในตำแหน่งเดิมได้ (จะสำรองเวอร์ชันเก่าโดยอัตโนมัติ)
ภาคปฏิบัติ: สกิลนี้ของเราวนซ้ำหลายรอบมาก——เพิ่มมาตรฐาน Bing เปลี่ยนรูปแบบเมทริกซ์การดำเนินการ แยกเป็นสองระยะ เพิ่มเอาต์พุตคู่ Excel+Markdown แก้การจัดแนวชื่อคอลัมน์กับตัวอย่าง สุดท้ายเปลี่ยนชื่อ ทุกรอบคือload_skill_for_improvement→ แก้ →save_skillเขียนทับ
เปลี่ยนชื่อ
แก้ใน frontmatter name และ display_nameใช้ชื่อใหม่ save_skillแล้วลบโฟลเดอร์สกิลเก่า
แพ็กและเผยแพร่
บีบอัดโฟลเดอร์สกิลทั้งหมดเป็น zip เพื่อสำรอง ย้ายไปคอมพิวเตอร์เครื่องอื่น หรือแชร์ให้เพื่อนร่วมงาน (วางในไดเรกทอรี skills ของฝ่ายนั้น)
ย้ายข้ามเครื่องมือ
หากต้องการใช้ในเครื่องมือ AI อื่น (ChatGPT/Claude/Gemini) ต้อง "ลดความเป็นแพลตฟอร์ม": เขียนชื่อเครื่องมือเฉพาะเป็นคำอธิบายความสามารถทั่วไป ("เปิดหน้าเว็บ" "รันโค้ด") และฝังสคริปต์เป็น Markdown แบบครบในตัวเอง ก็วางทั้งบล็อกเป็น system prompt/คำสั่งกำหนดเองได้
ห้า คำสั่งที่ใช้บ่อยแบบเร็ว
| คำสั่ง | หน้าที่ | ใช้ใน |
|---|---|---|
extract_session_data | ดึงโครงกระดูกจากบทสนทนา | สร้าง·ขั้นตอนที่ 3 |
save_skill | บันทึก/เขียนทับสกิล | สร้าง·ขั้นตอนที่ 5 / การทำซ้ำ |
generate_skill_evals | สร้างกรณีทดสอบ | สร้าง·ขั้นตอนที่ 5 |
load_skill_for_improvement | โหลดสกิลเพื่อปรับปรุง | ทำซ้ำ |
หก、รายการข้อควรระวัง (จากประสบการณ์จริง)
- ทำให้ทำงานได้ก่อนแล้วจึงทำให้เป็นมาตรฐาน——อย่าเขียนสกิลขึ้นมาจากอากาศ
- ใส่อินพุตเฉพาะสิ่งที่จะเปลี่ยนแปลง——ค่าคงที่ให้เขียนตายตัวในโฟลว์
- Lessons Learned ต้องเต็มไปด้วยประสบการณ์จริง——นี่คือกุญแจว่าสกิลจะ "ยิ่งใช้ยิ่งเสถียร" ได้หรือไม่
- แยกโค้ดที่ซ้ำออกเป็นสคริปต์——รับประกันรูปแบบเอาต์พุตที่สม่ำเสมอและประหยัด token
- หลังบันทึกต้องทดสอบเสมอ——รันจริงหนึ่งหน้าครั้งเดียว + หลายหน้า เพื่อยืนยันว่ามันระบุปัญหาจริงได้
- ข้อควรระวังด้านการเข้ารหัส(หากเกี่ยวข้องกับภาษาจีน/การสร้างโค้ด):เขียนไฟล์ด้วย
encoding="utf-8",CSV ใช้utf-8-sig,อย่าใช้\uXXXXการ escape,PDF ภาษาจีนใช้ฟอนต์ CID ที่มีในตัว - การทำซ้ำใช้การเขียนทับชื่อเดิม——
nameไม่เปลี่ยนแปลง ระบบสำรองเวอร์ชันเก่าโดยอัตโนมัติ
บทส่งท้าย
แก่นแท้ของการสร้าง SKILL คือ:การห่อหุ้มเวิร์กโฟลว์ที่ประสบความสำเร็จครั้งหนึ่ง พร้อมด้วยการตัดสินใจและบทเรียนภายใน ให้กลายเป็นความสามารถที่ "ครั้งหน้าพูดประโยคเดียวก็เริ่มใหม่ได้" สกิลที่ดีไม่เพียงบันทึกขั้นตอน แต่ยังบันทึกประสบการณ์ว่า "จะทำสิ่งนี้ให้ถูกต้องได้อย่างไร"
ทำสิ่งต่างๆ ให้ดีเสียก่อน แล้วจึงทำให้มันนำกลับมาใช้ซ้ำได้——นี่คือหัวใจทั้งหมดของการสร้าง SKILL