ชุมชน AI ขณะนี้แตกออกเป็นสองฝ่ายเกี่ยวกับคุณสมบัติ Claude Skills ที่เพิ่งประกาศโดย Anthropic โดยนักพัฒนาหลายคนกำลังตั้งคำถามว่าวิธีการที่เรียบง่ายกว่าอาจจะมาแทนที่ Model Context Protocol (MCP) ที่เคยได้รับการพูดถึงอย่างมากก่อนหน้านี้หรือไม่ ณ วันที่ UTC+0 2025-10-18T07:14:46Z การอภิปรายเผยให้เห็นถึงความรู้สึกที่เพิ่มขึ้นว่าเครื่องมือ AI ที่เรียบง่ายและเข้าถึงได้ง่ายกว่าอาจจะชนะโซลูชันที่ซับซ้อนและอิงตามโปรโตคอล
ช่องว่างระหว่าง Skills กับ MCP
นักพัฒนากำลังเปรียบเทียบ Claude Skills กับ MCP อย่างจริงจังในหลายมิติ โดยมีประสิทธิภาพด้านโทเคนที่โผล่ขึ้นมาเป็นข้อแตกต่างที่สำคัญ Skills ทำงานผ่านการเปิดเผยข้อมูลแบบค่อยเป็นค่อยไป - Claude จะสแกน Skills ที่มีได้เมื่อเริ่มเซสชัน แต่จะโหลดรายละเอียดเต็มต่อเมื่อเกี่ยวข้องกับงานปัจจุบัน วิธีการนี้แตกต่างอย่างชัดเจนจากการใช้งาน MCP ซึ่งเซิร์ฟเวอร์บางตัวอย่างเช่น MCP อย่างเป็นทางการของ GitHub รายงานว่ากินโทเคนไปหลายหมื่นตัวก่อนที่จะเริ่มทำงานที่มีประโยชน์ใดๆ สังคมสังเกตว่าประสิทธิภาพโทเคนแบบนี้ทำให้ Skills มีคุณค่าอย่างยิ่งสำหรับเวิร์กโฟลว์ที่ซับซ้อนซึ่งการจัดการหน้าต่างบริบทมีความสำคัญอย่างยิ่ง
เกือบทุกอย่างที่ผมอาจจะทำได้ด้วย MCP สามารถจัดการด้วยเครื่องมือ CLI แทนได้ LLMs รู้วิธีเรียกใช้ --help ซึ่งหมายความว่าคุณไม่ต้องใช้โทเคนจำนวนมากเพื่ออธิบายวิธีการใช้งาน
การเปรียบเทียบการใช้ Token
- GitHub MCP: ~30,000 tokens
- Linear MCP: ~12,935 tokens
- JetBrains MCP: ~12,252 tokens
- Playwright MCP: ~9,804 tokens
- Typical Skill: ใช้เพียงไม่กี่สิบ tokens สำหรับ metadata เท่านั้น โดยเนื้อหาทั้งหมดจะถูกโหลดก็ต่อเมื่อจำเป็นเท่านั้น
ความซับซ้อนในการใช้งานและประสบการณ์ของนักพัฒนา
ประสบการณ์ของนักพัฒนาระหว่างสองวิธีนี้เผยให้เห็นความแตกต่างอย่างมากในเรื่องอุปสรรคการนำไปใช้ MCP ต้องการความเข้าใจในข้อกำหนดโปรโตคอลที่ครอบคลุมซึ่งรวมถึงโฮสต์, ไคลเอนต์, เซิร์ฟเวอร์, ทรัพยากร, พรอมต์, เครื่องมือ, การสุ่มตัวอย่าง, และหลายเลเยอร์การขนส่ง ในทางตรงกันข้าม Skills เป็นเพียงแค่ไฟล์ Markdown ที่มีเมตาดาต้า YAML และสคริปต์เสริม (ถ้ามี) ความเรียบง่ายนี้ทำให้นักพัฒนาจำนวนมากรายงานว่าพวกเขาใช้รูปแบบที่คล้ายกันแบบไม่เป็นทางการมาหลายเดือนแล้ว โดย Skills เป็นการทำให้แนวปฏิบัติที่ดีที่มีอยู่แล้วเป็นทางการมากกว่าที่จะแนะนำความสามารถใหม่ขั้นพื้นฐาน
สมาชิกในชุมชนตั้งข้อสังเกตว่าการเขียนและดีบักเซิร์ฟเวอร์ MCP สามารถเป็นเรื่องยุ่งยากได้ โดยเฉพาะเมื่อต้องจัดการกับหลายเซิร์ฟเวอร์หรือจัดการกับการเปลี่ยนแปลงสคีมา ประสบการณ์การดีบักเมื่อ MCP ล้มเหลวมักเกี่ยวข้องกับการเดาว่าปัญหาอยู่ที่แมนิเฟสต์, เลเยอร์การขนส่ง, หรือตรรกะของเครื่องมือ Skills ข้ามความซับซ้อนเหล่านี้ไปหมดโดยใช้ประโยชน์จากเครื่องมือ command-line ที่มีอยู่แล้วและรูปแบบการเขียนเอกสารที่ตรงไปตรงมาซึ่งนักพัฒนาเข้าใจอยู่แล้ว
ความซับซ้อนในการพัฒนา
- MCP: ข้อกำหนดโปรโตคอลที่ครอบคลุม hosts, clients, servers, resources, prompts, tools, sampling, roots, elicitation และ transport layers ทั้งสามชั้น
- Skills: ไฟล์ Markdown พร้อม metadata แบบ YAML, scripts เสริม, โครงสร้างโฟลเดอร์
การใช้งานจริงและข้อจำกัด
กรณีใช้จริงในโลกแห่งความจริงเน้นย้ำว่าวิธีใดดีเด่นในด้านไหน Skills แสดงให้เห็นความแข็งแกร่งเป็นพิเศษในเวิร์กโฟลว์การเขียนโค้ดและงานประมวลผลข้อมูล เช่น การทำงานกับไฟล์ Excel, การจัดการ PDF, หรือการปฏิบัติตามแนวทางแบรนด์ขององค์กร ตัวอย่างการทำข่าวข้อมูลที่ถูกกล่าวถึงในการอภิปราย - ซึ่ง Skills สามารถแนะนำการวิเคราะห์ข้อมูลสำมะโนประชากร, การผนวกรวม SQLite, และการสร้างภาพข้อมูล - แสดงให้เห็นว่า Skills สามารถสร้างเอเจนต์เฉพาะทางได้อย่างไรผ่านโครงสร้างโฟลเดอร์ของไฟล์ Markdown และสคริปต์
อย่างไรก็ตาม MCP ยังคงมีความได้เปรียบในสถานการณ์ระดับองค์กรที่ต้องการการผนวกรวม OAuth, การประมวลผลฝั่งเซิร์ฟเวอร์, และความเข้ากันได้ข้ามแพลตฟอร์ม ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุ MCPs มีผลกระทบที่ใหญ่กว่าการใช้งานในเทอร์มินัล - คุณสามารถใช้มันกับ ChatGPT, Claude Web, n8n, LibreChat และมันมาพร้อมกับข้อพิจารณาด้านการยืนยันตัวตน, ทรัพยากร, และตอนนี้แม้แต่ UI สิ่งนี้ทำให้ MCP เหมาะสมกว่าสำหรับงาน CRM, การขาย, การสนับสนุนลูกค้า, และการดำเนินการ ซึ่งผู้ใช้ไม่ต้องการจัดการสภาพแวดล้อมการพัฒนาท้องถิ่น
จุดแข็งของกรณีการใช้งาน
- Skills: เวิร์กโฟลว์การเขียนโค้ด การประมวลผลข้อมูล การสร้างเอกสาร ระบบอัตโนมัติส่วนบุคคล
- MCP: การผสานรวมระดับองค์กร สถานการณ์ OAuth เครื่องมือข้ามแพลตฟอร์ม API ของบริการต่างๆ
ข้อโต้แย้งด้านความเรียบง่ายได้รับความสนใจ
ชุมชนดูเหมือนจะโน้มเอียงไปทางโซลูชันที่เรียบง่ายกว่า โดยวาดเส้นขนานไปสู่การต่อสู้ทางเทคโนโลยีในอดีต ผู้แสดงความคิดเห็นหลายคนเปรียบเทียบพลวัตของ Skills กับ MCP ว่าเหมือนกับ JSON กับ XML หรือ REST กับ SOAP ซึ่งโซลูชันที่เรียบง่ายและยืดหยุ่นกว่ามักจะชนะแม้ทางเลือกที่ซับซ้อนกว่าจะมีข้อได้เปรียบในทางทฤษฎี ความจริงที่ว่า Skills สามารถทำงานกับเครื่องมือ AI อื่นๆ เช่น Codex CLI หรือ Gemini CLI โดยไม่ต้องมีการสนับสนุนเฉพาะผู้ขาย เสริมสร้างข้อได้เปรียบด้านความเรียบง่ายนี้
นักพัฒนาจำนวนมากรายงานว่าพวกเขาเลิกใช้ MCP สำหรับงานทั่วไปไปแล้ว และหันมาใช้เครื่องมือ CLI ที่มีเอกสาร --help ที่เขียนได้ดีแทน ความสามารถของ LLMs ในการค้นพบความสามารถของเครื่องมือแบบไดนามิกผ่านอินเทอร์เฟซ command-line ที่มีอยู่แล้ว ลดความจำเป็นสำหรับข้อกำหนดโปรโตคอลที่กำหนดไว้ล่วงหน้า รูปแบบนี้สอดคล้องกับวิธีที่นักพัฒนาที่มีประสบการณ์หลายคนชอบทำงาน - การใช้เครื่องมือที่คุ้นเคยแทนการเรียนรู้โปรโตคอลใหม่
มองไปข้างหน้า: การอยู่ร่วมกันหรือการแทนที่?
การอภิปรายชี้ให้เห็นว่าทั้งสองแนวทางมีแนวโน้มที่จะอยู่ร่วมกันมากกว่าที่วิธีหนึ่งจะมาแทนที่อีกวิธีหนึ่งโดยสมบูรณ์ Skills เด่นชัดสำหรับเวิร์กโฟลว์ที่ผู้ใช้ควบคุมและอิงตามระบบไฟล์ ซึ่งนักพัฒนาต้องการการจัดการบริบทแบบน้ำหนักเบา MCP ยังคงมีความเกี่ยวข้องสำหรับการผนวกรวมบริการ, เครื่องมือข้ามแพลตฟอร์ม, และสถานการณ์ที่ต้องการการจัดการแบบรวมศูนย์หรือการยืนยันตัวตนที่ซับซ้อน ผู้แสดงความคิดเห็นบางคน甚至แนะนำแนวทางแบบไฮบริดซึ่ง Skills สามารถอ้างอิงถึงเครื่องมือ MCP เมื่อจำเป็น โดยรวมประสิทธิภาพโทเคนของ Skills เข้ากับความสามารถในการผนวกรวมบริการของ MCP
การตอบสนองอย่างรวดเร็วของชุมชนต่อ Skills - โดยนักพัฒนาได้แบ่งปันกรณีใช้และรูปแบบการใช้งานทันที - บ่งชี้ว่าแนวทางที่เรียบง่ายกว่ากระตุ้นความต้องการในทางปฏิบัติของนักพัฒนา AI ที่ทำงานกับปัญหาประจำวัน ในขณะที่ MCP จะยังคงตอบสนองความต้องการระดับองค์กรและการผนวกรวมบริการ Skills ดูเหมือนจะถูกกำหนดตำแหน่งให้กลายเป็นโซลูชันหลักสำหรับการเพิ่มผลผลิตส่วนบุคคลและระบบอัตโนมัติเวิร์กโฟลว์เฉพาะทาง
อ้างอิง: Claude Skills are awesome, maybe a bigger deal than MCP