สกิล Claude SEO คือโฟลเดอร์ที่มีไฟล์ Markdown อยู่หนึ่งไฟล์ ไฟล์นั้นบอกเอเจนต์ว่าสกิลทำอะไร ใช้เมื่อไหร่ และรันงานอย่างไร Claude Code, Codex และเอเจนต์อื่นที่รองรับธรรมเนียมนี้อ่านรูปแบบเดียวกัน คือบล็อกเมทาดาทาสั้น ๆ ไว้ด้านบน แล้วตามด้วยคำสั่ง
คำถามที่ทุกทีมเจอราวสัปดาห์ที่สองคือ ในบรรดาสกิลเหล่านี้ควรติดตั้งอันไหน ติดตั้งทั้งหมดก็กังวลว่าจะถมหน้าต่างบริบทจนเต็ม ไม่ติดตั้งอะไรเลยก็กลับไปคัดลอกพรอมป์จากแอปจดโน้ตเหมือนเดิม
เราวัดคลังสกิลของเราเองเพื่อตอบคำถามนี้ และคำตอบแยกออกเป็นสองส่วนชัดเจน สกิลแทบไม่เสียค่าใช้จ่ายเลยขณะวางอยู่เฉย ๆ แต่กินบริบทจริงเมื่อถูกเรียกใช้ ค่ามัธยฐานในคลังของเราคือ 107 โทเคนของเมทาดาทาในโหมดรอ และ 1,851 โทเคนของคำสั่งสอน สองตัวเลขนี้ควรทำหน้าที่ต่างกันในการตัดสินใจของคุณ
การวัด
เราแยกวิเคราะห์ไฟล์ SKILL.md ทุกไฟล์ในรากสกิลสองแห่งบนเครื่องเดียว และผ่าแต่ละไฟล์ที่ขอบ frontmatter
ตัวชี้วัด | ค่า |
|---|---|
ไฟล์สกิลที่แยกวิเคราะห์ | 76 |
ชื่อสกิลที่ไม่ซ้ำกัน | 75 |
บล็อกเมทาดาทาทั้งหมด | 8,231 โทเคน (ประมาณ) |
เนื้อคำสั่งทั้งหมด | 222,952 โทเคน (ประมาณ) |
อัตราส่วนเนื้อต่อเมทาดาทา | 27 ต่อ 1 |
จำนวนโทเคนประมาณจากสี่ตัวอักษรต่อหนึ่งโทเคน ซึ่งเป็นค่าประมาณที่ดีสำหรับงานเขียนเทคนิคภาษาอังกฤษ แต่ไม่แม่นยำ ให้มองเป็นตัวเลขสำหรับเปรียบเทียบ ไม่ใช่ค่าจริง สิ่งที่ค้นพบคืออัตราส่วนและการกระจาย ส่วนค่าสัมบูรณ์จะขยับไปตามไฟล์ของคุณเอง
ทำไมค่าใช้จ่ายบนชั้นวางจึงยังน้อย
ระบบสกิลใช้การเปิดเผยแบบค่อยเป็นค่อยไป บล็อกเมทาดาทาถูกโหลดเพื่อให้เอเจนต์รู้ว่าสกิลมีอยู่และใช้เมื่อไหร่ ส่วนเนื้อหาจะอ่านก็ต่อเมื่อสกิลถูกเรียกใช้
การออกแบบนี้ให้การกระจายที่น่าดูสักครั้ง
เปอร์เซ็นไทล์ | ค่าใช้จ่ายตอนรอต่อสกิล | ค่าใช้จ่ายเนื้อหาต่อสกิล |
|---|---|---|
เล็กที่สุด | 43 โทเคน | 428 โทเคน |
มัธยฐาน | 107 โทเคน | 1,851 โทเคน |
เปอร์เซ็นไทล์ที่ 90 | 161 โทเคน | 7,125 โทเคน |
ใหญ่ที่สุด | 246 โทเคน | 21,702 โทเคน |
คลังทั้งหมด 76 ไฟล์ถือเมทาดาทาในโหมดรออยู่ 8,231 โทเคน คิดเป็นขนาดประมาณบทความยาวหนึ่งชิ้น และนั่นคือราคาที่เอเจนต์รู้ว่ามีสกิล 75 ตัวอยู่ก่อนจะทำอะไรเลย บล็อกเมทาดาทาที่ใหญ่ที่สุดในคลังคือ 246 โทเคน
ค่าสูงสุดคือจุดที่น่าสนใจ สกิลที่พูดมากที่สุดในคลังใช้เพียง 246 โทเคนเพื่อบอกเอเจนต์ว่าเมื่อไหร่ควรใช้ ซึ่งยังเล็กพอที่ชั้นวางสกิลทั้งชั้นจะไม่ทำให้เซสชันจม หากคุณกังวลว่าการติดตั้งสกิล SEO ห้าตัวจะไปแย่งที่ข้อมูล คำตอบจากการวัดคือชั้นวางไม่ใช่จุดที่เกิดความแออัด
ค่าใช้จ่ายอยู่ที่ไหนจริง ๆ
ตัวจริงคือเนื้อหา และการกระจายกว้างมาก 75 ตัวมี 15 ตัวที่โหลดต่ำกว่า 1,000 โทเคนเมื่อถูกเรียก อีก 11 ตัวโหลดเกิน 5,000 ส่วนที่ใหญ่ที่สุดโหลด 21,702
สำหรับงาน SEO ช่วงนี้คือสิ่งที่ต้องวางแผนล้อมไว้ เพราะมันสอดคล้องกับปริมาณงานที่สกิลทำ สกิลที่ตรวจหน้าเดียวราคาถูก สกิลที่กวาดทั้งไซต์ เทียบกับเส้นฐาน แล้วเขียนรายงาน ย่อมมีคำสั่งมากเพราะมีขั้นตอนมาก
ค่าใช้จ่ายในการเรียกกระจุกตัวที่ปลายล่าง แล้วลากยาวออกไป โดยมี 11 สกิลที่เกิน 5,000 โทเคน
นี่คือชุดสกิลด้านการค้นหาและการวัดของเรา วัดด้วยวิธีเดียวกัน
สกิล | ตอนรอ | เมื่อถูกเรียก |
|---|---|---|
tool-cluster-builder | 70 โทเคน | 428 โทเคน |
seo-tools-local | 102 โทเคน | 638 โทเคน |
geo-operator | 101 โทเคน | 665 โทเคน |
dataforseo-toolkit | 238 โทเคน | 849 โทเคน |
ahrefs-2026-content-refresh | 51 โทเคน | 958 โทเคน |
search-engine-visibility-audit | 49 โทเคน | 1,121 โทเคน |
codex-link-equity-audit | 96 โทเคน | 1,163 โทเคน |
gsc | 116 โทเคน | 1,309 โทเคน |
bing-webmaster | 135 โทเคน | 1,685 โทเคน |
seo-beginner-automation | 98 โทเคน | 1,836 โทเคน |
ทั้งสิบตัวรวมกัน | 1,055 โทเคน | 10,652 โทเคน |
สกิล SEO สิบตัวกินราว 1,000 โทเคนบนชั้นวาง และราว 10,000 โทเคนเมื่อถูกเรียกทั้งหมด
มีสองสิ่งหลุดออกมาจากตารางนี้
คอลัมน์ตอนรอเกือบแบนราบ สกิล SEO สิบตัวใช้ 1,055 โทเคนเพื่อให้พร้อมใช้ เทียบกับหน้าผลการค้นหาหรือไฟล์ส่งออกจากการกวาดแล้ว นี่คือความคลาดเคลื่อนระดับปัดเศษ และเป็นเหตุผลให้ติดตั้งชั้นวางที่คุณต้องการ ไม่ใช่ชั้นวางที่คุณคิดว่าจะจ่ายไหว
คอลัมน์เมื่อถูกเรียกไม่แบน ชุดนี้ตั้งแต่ 428 ถึง 1,836 โทเคน ต่างกันสี่เท่า ในทางปฏิบัติคุณแทบไม่เคยเรียกเกินหนึ่งหรือสองตัวต่อเซสชัน ตัวเลขที่ซื่อตรงสำหรับการวางแผนจึงไม่ใช่ 10,652 แต่เป็นโทเคนอีกไม่กี่พันตัวบนข้อมูลที่เซสชันถืออยู่แล้ว
ตัวเลขเหล่านี้หมายความว่าอะไรเมื่อคุณเลือกสกิล
กฎการเลือกสามข้อที่ตามมาจากการวัด
ตัดสินที่เนื้อหา ไม่ใช่คำอธิบาย บล็อกเมทาดาทาคือโฆษณาของสกิล สกิลหนึ่งมีคำอธิบาย 50 โทเคนและเนื้อหา 7,000 โทเคนได้ อ่านไฟล์ก่อนติดตั้ง และตรวจความยาวของทุกอย่างใต้ frontmatter ถ้าต้องการตัวกรองเร็ว ขนาดไฟล์และจำนวนบรรทัดเป็นตัวแทนที่ใช้ได้ของปริมาณที่สกิลจะดึงเข้าไป
เลือกสกิลที่อ่านข้อมูล มากกว่าสกิลที่ฝังข้อมูลไว้ สกิลที่เรียก API แล้วอ่านคำตอบมีค่าใช้จ่ายคงที่ ไม่ว่าคุณจะมีคีย์เวิร์ดกี่คำ ส่วนสกิลที่แบกตารางค้นหาหรือคลังเทมเพลตไว้ใน Markdown มีค่าเท่ากันไม่ว่าคุณจะได้ใช้ตารางนั้นหรือไม่ นี่คือเหตุผลที่ตัวห่อ DataForSEO ขนาด 849 โทเคนถูกกว่าที่ดูในทางปฏิบัติ และเป็นเหตุผลที่สกิลเนื้อหาขนาดใหญ่ที่ขับด้วยเทมเพลตแพงกว่าที่คำอธิบายบอก
ตั้งงบที่เซสชัน ไม่ใช่ที่ชั้นวาง ตัวเลขที่สำคัญคือโทเคนรวมในเซสชันที่กำลังทำงาน และสกิลเป็นเพียงหนึ่งในหลายอินพุต เซสชันที่วางไฟล์ส่งออกจากการกวาดไว้และโหลดสกิลสามตัวคือปัญหาเรื่องบริบท เซสชันที่มีสกิลยี่สิบตัวพร้อมใช้แต่โหลดเพียงตัวเดียวไม่ใช่ปัญหา
เมื่อไหร่สกิลคือคำตอบที่ถูก และเมื่อไหร่ไม่ใช่
สกิลและเซิร์ฟเวอร์ MCP แก้คนละครึ่งของปัญหาเดียวกัน และการเลือกใช้ผิดครึ่งคือเหตุผลที่ทีมลงเอยด้วยการไม่ได้ทั้งสองอย่าง
สกิลคือคำสั่งและไม่รู้อะไรเลย มันเป็นรูปแบบที่เหมาะกับวิจารณญาณที่เกิดซ้ำ เช่นจะคัดแยกอันดับที่ตกอย่างไร จะจัดโครงผลลัพธ์การตรวจสอบอย่างไร หรือการทบทวนโปรไฟล์ลิงก์ต้องใช้หลักฐานอะไร ค่าใช้จ่ายของมันคือบริบท และจ่ายเป็นรายเซสชัน
เซิร์ฟเวอร์ MCP คือการเชื่อมต่อที่มีชีวิต เป็นรูปแบบที่เหมาะกับข้อมูลที่เอเจนต์เข้าถึงไม่ได้ด้วยวิธีอื่น เช่น Search Console หรือดัชนีแบ็คลิงก์ ค่าใช้จ่ายคือการตั้งค่า ข้อมูลรับรอง และสิทธิ์ และจ่ายครั้งเดียว หากอยากรู้ว่าการเชื่อมต่อเหล่านี้เปิดเผยอะไรจริง ๆ ก่อนจะต่อสักอัน การเปรียบเทียบเซิร์ฟเวอร์ SEO MCP สี่ตัวของเราอยู่ในบททดสอบนี้
คู่ที่ได้ผลคือ การเชื่อมต่อหนึ่งเส้นต่อแหล่งข้อมูลหนึ่งแหล่ง และสกิลหนึ่งตัวต่อวิจารณญาณที่เกิดซ้ำหนึ่งเรื่อง ในเวิร์กโฟลว์ของเราเอง การเชื่อมต่อ Search Console เป็นเซิร์ฟเวอร์ ส่วนกิจวัตรการมอนิเตอร์รายวันเป็นสกิล เพราะส่วนที่ซ้ำคือวิจารณญาณ
สิ่งที่ต้องตรวจก่อนติดตั้งสักตัว
ขั้นตอนตรวจสอบสั้น ๆ เพราะรูปแบบนี้เขียนง่ายและเขียนแย่ก็ง่าย
- อ่าน frontmatter แล้วยืนยันว่าคำอธิบายระบุทริกเกอร์ที่เฉพาะเจาะจง คำอธิบายที่บอกว่า "ช่วยเรื่อง SEO" จะถูกโหลดในจังหวะที่ผิด
- นับบรรทัดใต้ frontmatter ต่ำกว่า 100 บรรทัดคือสกิลที่โฟกัสดี เกิน 500 บรรทัด ให้ตรวจว่ารายละเอียดเหล่านั้นเป็นเอกสารอ้างอิงที่ควรเป็นไฟล์แยกซึ่งสกิลอ่านเมื่อต้องการหรือไม่
- ค้นหาไฟล์หาข้อมูลรับรองและพาธที่ฝังตายไว้ สกิลควรอ่านการตั้งค่าจากสภาพแวดล้อม ไม่ใช่แบกโทเคนไว้เอง
- ตรวจว่ามันเขียนลงไซต์ของคุณหรือไม่ สกิลที่อ่านอย่างเดียวปลอดภัยที่จะลองบนพร็อพเพอร์ตี้จริง ส่วนสกิลที่แก้ไฟล์ควรมีขั้นตอนทบทวนก่อนที่อะไรจะเปลี่ยน
- รันมันหนึ่งครั้งบนพร็อพเพอร์ตี้ที่คุณไม่แคร์ แล้วอ่านผลลัพธ์ สกิลส่วนใหญ่ถูกตัดสินที่รูปแบบผลลัพธ์ ไม่ใช่ที่คำสั่ง
คำถามที่พบบ่อย
สกิลที่ติดตั้งไว้ทำให้ทุกเซสชันช้าลงไหม ช้าลงแค่ตามบล็อกเมทาดาทาของมัน ในคลังของเรา ค่ามัธยฐานคือ 107 โทเคน และรวมทั้ง 76 ไฟล์เป็น 8,231 โทเคน คำสั่งจะโหลดเมื่อใช้สกิล ไม่ใช่ก่อนหน้า
ควรติดตั้งสกิล SEO ไว้กี่ตัว ในชุดของเรา สกิลด้านการค้นหาและการวัดสิบตัวใช้เมทาดาทาตอนรอราว 1,000 โทเคน ขีดจำกัดแทบไม่เคยเป็นเรื่องบริบท ขีดจำกัดจริงคือความสามารถของคุณเองในการจำว่าตัวไหนมีไว้ทำอะไร
ไฟล์สกิลใหญ่เป็นสัญญาณแย่ไหม ไม่โดยอัตโนมัติ สกิลที่เน้นเอกสารอ้างอิงยาวโดยชอบธรรม แต่ความยาวควรมีเหตุผลจากสิ่งที่สกิลทำ ถ้าสกิล 500 บรรทัดเรียก API แค่ครั้งเดียวพร้อมคำอธิบายเยอะ นั่นคือปัญหาการทำเอกสาร ไม่ใช่ขีดความสามารถ
เขียนสกิล Claude SEO เองได้ไหม ได้ และเป็นตัวเลือกที่ผลตอบแทนสูงที่สุดเมื่อคุณมีกิจวัตรที่เกิดซ้ำแล้ว เริ่มจากรันงานนั้นด้วยมือสองครั้ง จดขั้นตอนที่ไม่ได้เปลี่ยน แล้วใส่ลงในเนื้อหา คุม frontmatter ให้ต่ำกว่า 150 โทเคน และอธิบายทริกเกอร์ให้แม่นยำ
ตัวเลขเหล่านี้ใช้กับ Claude Code โดยเฉพาะไหม รูปแบบและโมเดลการเปิดเผยแบบค่อยเป็นค่อยไปใช้ร่วมกันในเอเจนต์ที่รองรับ SKILL.md รวมถึง Claude Code และ Codex การวัดมาจากคลังของเราเอง ดังนั้นการกระจายของคุณจะต่างออกไปตามขนาดไฟล์ของคุณ
มุมมองของ Auspia: ติดตั้งชั้นวางที่คุณต้องการ แล้วตรวจว่าอะไรถูกเรียกใช้จริง ค่าใช้จ่ายตอนรอของคลังสกิลเล็กพอที่จะเลิกกังวลได้ และค่าใช้จ่ายตอนเรียกใช้คือจุดที่สกิลที่เขียนแย่สร้างความเจ็บจริง ๆ หากคุณยังไม่เคยวัดชุดของตัวเอง การนับบรรทัดใต้ frontmatter ในแต่ละไฟล์ใช้เวลาราวสิบนาทีและบอกได้ว่าน้ำหนักอยู่ตรงไหน การแบ่งระหว่างสกิลกับเซิร์ฟเวอร์อย่างละเอียดสำหรับงาน GEO อยู่ในบันทึกสกิล GEO ของเรา
ผู้เขียน: Alice Monroe, นักวิเคราะห์เครื่องมือ AI SEO ครอบคลุมเครื่องมือกว่า 150 รายการที่ Auspia เขียนเกี่ยวกับเครื่องมือ AI SEO สถาปัตยกรรมสกิลและเซิร์ฟเวอร์ และสิ่งที่แต่ละชั้นของเอเจนต์สแต็กต้องจ่ายจริง
