Claude Skills น่าทึ่งมาก อาจเป็นนวัตกรรมที่ใหญ่กว่า MCP เสียอีก

• Claude Skills ที่ Anthropic เปิดตัว คือรูปแบบใหม่ที่จัดเตรียมคำแนะนำ สคริปต์ และทรัพยากรที่จำเป็นต่อการให้โมเดลทำงานเฉพาะด้านในรูปแบบโฟลเดอร์ โดยเป็นวิธี โหลดความเชี่ยวชาญเฉพาะงานแบบไดนามิก
• Skills ประกอบด้วยไฟล์ Markdown และสคริปต์เสริมแบบเลือกใช้ โดยเมื่อเริ่มเซสชันจะโหลดเฉพาะเมทาดาทาของแต่ละสกิลด้วยโทเคนเพียง ไม่กี่สิบโทเคน แล้วค่อยดึงเนื้อหาทั้งหมดมาเมื่อจำเป็นจริงเท่านั้น ทำให้มี ประสิทธิภาพด้านโทเคน สูงมาก
• ผ่าน Claude Code, Skills ขยายจากเครื่องมือเขียนโค้ดธรรมดาไปสู่ เอเจนต์อัตโนมัติแบบอเนกประสงค์ และหากมีเพียงระบบไฟล์กับสภาพแวดล้อมสำหรับรันคำสั่ง ก็สามารถทำงานอัตโนมัติได้หลากหลายประเภท
• ต่างจาก MCP ตรงที่ Skills ไม่ใช่โปรโตคอล แต่เป็น โครงสร้างเรียบง่ายบนพื้นฐานของ Markdown และ YAML จึงนำไปใช้กับโมเดลหรือเครื่องมืออื่นได้ทันที และแชร์หรือเผยแพร่ต่อได้ง่าย
• ด้วยความเรียบง่ายและมีประสิทธิภาพนี้ คาดว่า Skills จะ ขยายระบบนิเวศได้เร็วกว่ามากเมื่อเทียบกับ MCP และสามารถสร้างเอเจนต์เฉพาะทางได้ในหลายสาขา ตั้งแต่งาน data journalism ไปจนถึงแนวทางแบรนด์ โดยหลีกเลี่ยงปัญหาการใช้โทเคนสูงและสเปกที่ซับซ้อนของ MCP ได้

---

แนวคิดและโครงสร้างของ Skills

• Anthropic ประกาศเปิดตัว Claude Skills อย่างเป็นทางการเมื่อวันที่ 16 ตุลาคม 2025
  • เป็นระบบขยายความสามารถแบบหน่วยโฟลเดอร์ ที่บรรจุคำแนะนำ สคริปต์ และทรัพยากรซึ่งจำเป็นต่อการให้โมเดลทำงานเฉพาะอย่าง เช่น งาน Excel หรือการปฏิบัติตามแนวทางแบรนด์ขององค์กร
  • Claude จะเข้าถึงสกิลนั้นเฉพาะเมื่อเกี่ยวข้องกับงาน เพื่อเพิ่มความสามารถในการทำงานเฉพาะทาง
• มีตัวอย่างสกิลอย่างเป็นทางการใน GitHub repository anthropic/skills
• ในเชิงแนวคิด Skills เรียบง่ายอย่างมาก
  • แกนหลักคือไฟล์ Markdown ที่บอกโมเดลว่าควรทำงานนั้นอย่างไร
  • สามารถใส่เอกสารเพิ่มเติมและสคริปต์ที่เตรียมไว้ล่วงหน้าแบบเลือกใช้ เพื่อช่วยให้งานเสร็จสมบูรณ์
• ฟีเจอร์สร้างเอกสารของ Claude ที่ประกาศในเดือนกันยายน แท้จริงแล้วถูก สร้างขึ้นด้วย Skills ทั้งหมด
  • สามารถดูสกิลสำหรับจัดการไฟล์ .pdf, .docx, .xlsx, .pptx ได้ใน public repository

ประสิทธิภาพด้านโทเคน: จุดเด่นหลักของ Skills

• เมื่อเริ่มเซสชัน Claude จะสแกนไฟล์สกิลทั้งหมดที่มี และอ่านเพียง คำอธิบายสั้น ๆ จาก frontmatter YAML ของแต่ละสกิล
• โทเคนเริ่มต้นที่แต่ละสกิลใช้มีเพียง ไม่กี่สิบโทเคน จึงมีประสิทธิภาพสูงมาก
• จะโหลดรายละเอียดทั้งหมดก็ต่อเมื่อผู้ใช้ร้องของานที่สกิลนั้นอาจช่วยได้
• นี่คือจุดต่างสำคัญที่ทำให้มันไม่ได้เป็นเพียงการเก็บไฟล์ไว้บนดิสก์ แต่กลายเป็น ฟีเจอร์ที่ใช้งานได้จริง

กรณีฝึกใช้สกิลสร้าง GIF สำหรับ Slack

• คำอธิบายเมทาดาทาของสกิล slack-gif-creator
  • ชุดเครื่องมือสร้าง GIF แบบแอนิเมชันที่ปรับให้เหมาะกับ Slack
  • มีตัวตรวจสอบข้อจำกัดด้านขนาด และองค์ประกอบแอนิเมชันพื้นฐานที่นำมาประกอบกันได้
  • ใช้กับคำขออย่าง “ช่วยสร้าง GIF สำหรับ Slack ที่เป็นภาพ X ทำ Y ให้หน่อย”
• กระบวนการทดสอบจริง
  • เปิดใช้งานสกิล slack-gif-creator บน Claude mobile web app ด้วยโมเดล Sonnet 4.5
  • ป้อนพรอมป์ต์ “Make me a gif for slack about how Skills are way cooler than MCPs”
  • Claude สร้าง GIF ให้อัตโนมัติทันที (คุณภาพยังควรปรับปรุงได้ แต่สกิลแบบนี้ทำซ้ำเพื่อพัฒนาได้ง่าย)
• จุดที่น่าสนใจใน Python script ที่สร้างขึ้น
  • เพิ่มไดเรกทอรีสกิลเข้าไปใน Python path: sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
  • ใช้คลาส GIFBuilder ในไดเรกทอรี core/ ของสกิล
  • บันทึกไฟล์ไว้ที่ /mnt/user-data/outputs/
  • ใช้ ฟังก์ชันตรวจสอบขนาดตามข้อจำกัดของ Slack (2MB) check_slack_size() เพื่อยืนยันว่าเป็นไปตามข้อกำหนด
  • ถ้าขนาดเกิน โมเดลสามารถลองสร้างไฟล์ใหม่ที่เล็กลงโดยอัตโนมัติได้

การพึ่งพาสภาพแวดล้อมของ Skills

• กลไกของ Skills จะ ทำงานได้เต็มรูปแบบ ก็ต่อเมื่อโมเดลเข้าถึงสิ่งต่อไปนี้ได้
  • ระบบไฟล์
  • เครื่องมือสำหรับสำรวจระบบไฟล์
  • ความสามารถในการรันคำสั่งในสภาพแวดล้อม
• นี่เป็นแพตเทิร์นทั่วไปของเครื่องมือ LLM
  • ChatGPT Code Interpreter เป็นกรณีขนาดใหญ่ครั้งแรกตั้งแต่ ต้นปี 2023
  • หลังจากนั้นก็ขยายไปถึงเครื่องมือเอเจนต์เขียนโค้ดบนเครื่องโลคัล เช่น Cursor, Claude Code, Codex CLI และ Gemini CLI
• ข้อกำหนดนี้คือ ความต่างที่ใหญ่ที่สุด จากความพยายามขยายความสามารถของ LLM ในอดีตอย่าง MCP หรือ ChatGPT Plugins
• แม้จะเป็นการพึ่งพาที่สำคัญ แต่ ขนาดของความสามารถใหม่ที่ปลดล็อกได้ นั้นน่าทึ่งมาก
• ประเด็นด้านความปลอดภัยยังคงสำคัญ
  • ต้องมีสภาพแวดล้อมการเขียนโค้ดที่ ปลอดภัย
  • ต้องมีวิธีสร้างสภาพแวดล้อมแบบ sandbox ที่จำกัดความเสียหายจากการโจมตีอย่าง prompt injection ให้อยู่ในระดับที่ยอมรับได้

Claude Code: วิวัฒนาการสู่เอเจนต์อเนกประสงค์

• ในเดือนมกราคม 2025 ผู้เขียนเคยคาดการณ์ว่า “เอเจนต์” จะล้มเหลว แต่กลับผิดเต็ม ๆ
  • ปี 2025 กลายเป็นปีแห่ง “เอเจนต์” จริง ๆ (แม้จะมีหลายคำนิยาม แต่ผู้เขียนนิยามว่าเป็น “tools in a loop”)
• Claude Code เป็นชื่อที่ตั้งได้ไม่ตรงนัก
  • มันไม่ใช่แค่เครื่องมือเขียนโค้ดล้วน ๆ แต่เป็น เครื่องมืออัตโนมัติสำหรับคอมพิวเตอร์แบบอเนกประสงค์
  • สามารถทำงานอัตโนมัติได้กับ ทุกงาน ที่ทำได้ด้วยการพิมพ์คำสั่งลงในคอมพิวเตอร์
  • คำอธิบายที่เหมาะที่สุดคือ general agent
• Skills ทำให้ศักยภาพนี้ชัดเจนและเป็นรูปธรรมมากยิ่งขึ้น
• ขอบเขตการประยุกต์ใช้นั้นกว้างจนแทบเวียนหัว
  • ตัวอย่างด้าน data journalism: สามารถจัดโฟลเดอร์สกิลสำหรับงานต่อไปนี้ได้
    • ทำความเข้าใจแหล่งข้อมูลและโครงสร้างของข้อมูลสำมะโนประชากรสหรัฐฯ
    • โหลดข้อมูลหลายรูปแบบเข้า SQLite/DuckDB ด้วยไลบรารี Python
    • เผยแพร่ข้อมูลออนไลน์เป็นไฟล์ Parquet บน S3 หรือตาราง Datasette Cloud
    • วิธีค้นหาเรื่องราวที่น่าสนใจจากชุดข้อมูลใหม่ ๆ (ตามแนวทางของนักข่าวข้อมูลที่มีประสบการณ์)
    • สร้าง data visualization ที่สะอาดและอ่านง่ายด้วย D3
  • ผลลัพธ์คือ สามารถสร้าง “เอเจนต์ data journalism” ที่ค้นพบและเผยแพร่เรื่องราวจากข้อมูลสำมะโนประชากรสหรัฐฯ ได้ ด้วยเพียงไฟล์ Markdown และตัวอย่าง Python script ไม่กี่ไฟล์

เปรียบเทียบ Skills กับ MCP

• Model Context Protocol (MCP) ได้รับความสนใจอย่างมหาศาลหลังเปิดตัวในเดือนพฤศจิกายน 2024
  • ทุกบริษัทต่างต้องการ “กลยุทธ์ AI” และการประกาศรองรับ MCP ก็เป็นวิธีง่าย ๆ ที่ตอบโจทย์นั้น
• ข้อจำกัดของ MCP เริ่มชัดเจนขึ้นเรื่อย ๆ
  • ปัญหาสำคัญที่สุดคือปริมาณการใช้โทเคน
  • MCP อย่างเป็นทางการของ GitHub เพียงตัวเดียวก็ใช้ context token หลายหมื่นโทเคน
  • ถ้าเพิ่มอีกไม่กี่ตัว ก็แทบไม่เหลือพื้นที่ให้ LLM ทำงานที่มีประโยชน์จริง
• หลังจากผู้เขียนเริ่มจริงจังกับ coding agent ความสนใจใน MCP ก็ลดลง
  • เกือบทุกอย่างที่ทำได้ด้วย MCP สามารถ แทนที่ด้วยเครื่องมือ CLI ได้
  • LLM รู้วิธีเรียก cli-tool --help อยู่แล้ว จึงไม่จำเป็นต้องเสียโทเคนจำนวนมากเพื่ออธิบายวิธีใช้
  • โมเดลสามารถหาคำตอบเองได้เมื่อจำเป็น
• Skills มีข้อดีแบบเดียวกันนี้ตรง ๆ และยิ่งไปกว่านั้น ยังไม่จำเป็นต้องสร้างเครื่องมือ CLI ใหม่ด้วยซ้ำ
  • แค่วางไฟล์ Markdown ที่อธิบายวิธีทำงานนั้นลงไป
  • เพิ่มสคริปต์เฉพาะเมื่อช่วยเรื่องเสถียรภาพหรือประสิทธิภาพได้จริงเท่านั้น

แนวโน้มการเติบโตแบบระเบิดของระบบนิเวศ Skills

• หนึ่งในจุดที่น่าสนใจที่สุดของ Skills คือ การแชร์ได้ง่าย
  • คาดว่าสกิลจำนวนมากจะถูกทำเป็นไฟล์เดียว
  • ส่วนสกิลที่ซับซ้อนขึ้นก็จะเป็นโฟลเดอร์ที่มีไม่กี่ไฟล์
• เอกสารจาก Anthropic
  • Agent Skills documentation
  • Claude Skills Cookbook
• ผู้เขียนเองก็กำลังคิดไอเดียสกิล เช่น วิธีสร้าง Datasette plugin
• ใช้กับโมเดลอื่นได้ด้วย: เป็นข้อดีอีกอย่างของการออกแบบ Skills
  • หากเชื่อมโฟลเดอร์สกิลเข้ากับ Codex CLI หรือ Gemini CLI แล้วสั่งว่า “อ่าน pdf/SKILL.md แล้วสร้าง PDF ที่อธิบายโปรเจกต์นี้ให้หน่อย” ก็ใช้งานได้
  • ทำได้แม้เครื่องมือและโมเดลนั้นจะไม่มีความรู้ในตัวเกี่ยวกับระบบสกิลเลยก็ตาม
• คาดการณ์ว่า จะเกิด การระเบิดแบบแคมเบรียนของ Skills จนทำให้กระแส MCP ในปีนี้ดูจืดชืดไปเลย

ความเรียบง่ายคือจุดแข็งหลัก

• บางคนอาจคัดค้านว่า Skills เรียบง่ายเกินไปจนแทบไม่ใช่ฟีเจอร์
  • หลายคนเคยทดลองใส่คำแนะนำเพิ่มเติมไว้ในไฟล์ Markdown แล้วให้ coding agent อ่านอยู่แล้ว
  • AGENTS.md เป็นแพตเทิร์นที่ได้รับการยอมรับดี และสามารถใส่คำสั่งอย่าง “ให้อ่าน PDF.md ก่อนสร้าง PDF” ได้
• แต่ ความเรียบง่ายที่เป็นหัวใจของการออกแบบ Skills นี่เอง คือเหตุผลที่ผู้เขียนรู้สึกตื่นเต้น
• MCP มีทั้ง สเปกของโปรโตคอล เต็มรูปแบบ
  • host, client, server, resource, prompt, tool, sampling, root, elicitation
  • รวมถึงการขนส่ง 3 แบบ (stdio, streamable HTTP และเดิมคือ SSE)
• ขณะที่ Skills มีเพียง Markdown + เมทาดาทา YAML เล็กน้อย + สคริปต์สำหรับรันแบบเลือกใช้
  • มันใกล้กับธรรมชาติของ LLM มากกว่า คือโยนข้อความให้โมเดลแล้วปล่อยให้จัดการเอง
• Skills โยนส่วนที่ยากไปให้ LLM harness และสภาพแวดล้อมคอมพิวเตอร์ที่เกี่ยวข้อง รับผิดชอบ
  • เมื่อพิจารณาจากทุกสิ่งที่เราได้เรียนรู้ในช่วงไม่กี่ปีที่ผ่านมาเกี่ยวกับความสามารถของ LLM ในการเรียกใช้เครื่องมือ นี่ถือเป็นกลยุทธ์ที่ฉลาดมาก

[shakespeares]

ผมก็สงสัยเหมือนกันว่าส่วนนี้จะนำไปประยุกต์ใช้ได้ตอนใช้ Claude Code สำหรับการเขียนโค้ดหรือเปล่า
ตอนนี้ก็ใส่ไกด์ไว้ใน Claude.md อยู่แล้ว และแยกไกด์รายละเอียดออกไปดำเนินการทีละส่วนครับ

[labeldock]

ถ้าต้องการทำงานได้มากด้วยโทเค็นน้อย ๆ ผมรู้สึกว่าน่าจะแก้ได้อย่างเรียบง่ายกว่าด้วยการใช้มัลติเอเจนต์และการสรุป มากกว่าการทำ prompt optimization นะครับ ผมเห็นด้วยกับปัญหาที่ชี้มา แต่ก็รู้สึกว่าวิธีแก้นั้นยังมีข้อจำกัดอยู่

[savvykang]

Skills ก็ใช้โทเค็นเหมือนกันไม่ใช่เหรอ? ถ้าเป็นอย่างนั้นก็ดูเหมือนว่าปัญหาเรื่องปริมาณการใช้โทเค็นจะเกิดขึ้นอีก แล้วตอนนั้นจะรับมือกันอย่างไร ผมก็ยังไม่ค่อยแน่ใจเหมือนกัน

[dnjstmxhs]

ดูเหมือนว่าในคอนเท็กซ์จะไม่ได้ใส่ SKILLS.md ทั้งหมด แต่จะใส่เฉพาะส่วนชื่อและคำอธิบายด้านบนแบบด้านล่างนี้ไว้เสมอก่อน

---

name: skill-creator
description: คู่มือสำหรับการสร้าง skills ที่มีประสิทธิภาพ skill นี้ควรถูกใช้เมื่อผู้ใช้ต้องการสร้าง skill ใหม่ (หรืออัปเดต skill ที่มีอยู่) ที่ขยายความสามารถของ Claude ด้วยความรู้เฉพาะทาง เวิร์กโฟลว์ หรือการผสานรวมเครื่องมือ
license: เงื่อนไขทั้งหมดอยู่ใน LICENSE.txt

[ds2ilz]

เวลาทำงานด้วย Claude Code เรามักต้องป้อนคำสั่งหรือกฎต่าง ๆ เข้าไปเป็นคอนเท็กซ์อยู่เรื่อย ๆ สุดท้ายก็ต้องคอยชั่งใจระหว่างปริมาณโทเคนที่ใช้กับคอนเท็กซ์ที่มีอยู่ครับ แล้วผมก็คิดวิธีขึ้นมาได้ คือสร้างโฟลเดอร์ไว้ แล้วใส่รายละเอียดเชิงลึกเป็นไฟล์ .md แยกตามฟังก์ชัน ส่วนใน claude.md ก็ใส่แค่พอยน์เตอร์เยอะ ๆ ว่าถ้าจะทำอะไรให้ไปดูอะไร วิธีนี้ทำงานได้ดีทีเดียวในต้นทุนที่ค่อนข้างต่ำ ถ้า skills ก็คือการเอาสิ่งพวกนี้มารวมไว้ สุดท้ายก็น่าจะใช้งานได้ดีไม่น้อยเลย

[laeyoung]

แล้วถ้ามี skills marketplace ออกมาตามที่ประกาศไว้จริง ก็รู้สึกว่าน่าจะโอเคพอสมควรเลยนะ แค่ดาวน์โหลด skill ที่จำเป็นมาแล้วเปิดใช้งานตอนที่ต้องใช้

[shakespeares]

โอ ขอบคุณสำหรับคำอธิบายประเด็นสำคัญครับ

[dnjstmxhs]

ความเกี่ยวข้องระหว่างการจัดการคอนเท็กซ์กับ Claude Skills คืออะไรกันนะ? ตอนแรกผมคิดว่าแล้วมันต่างจาก custom command ของ Claude Code ที่มีมาก่อนหน้านี้อย่างไร? แต่พออ่านเอกสารไปเรื่อย ๆ ก็รู้สึกว่าความแตกต่างที่ใหญ่ที่สุดน่าจะเป็นการที่ภายในสกิลหนึ่งเดียวสามารถใส่และรันสคริปต์โค้ดอย่าง Python หรือ JavaScript ได้ ซึ่งตรงนี้แหละที่ให้ความรู้สึกว่าแตกต่างมากที่สุด

[GN⁺]

ความคิดเห็นจาก Hacker News

• สำหรับผม Claude Skills ดูเหมือนเป็นหลักฐานว่า RAG ถูกทำให้ใช้งานยากเกินจำเป็นในแง่ประสบการณ์ผู้ใช้ ไม่ใช่ว่ามันซับซ้อนทางเทคนิค แต่ปัญหาอยู่ที่ UX ถ้าแก้จุดนี้ได้ดีพอ ผมคิดว่า Claude Skills เองอาจไม่จำเป็นเลยก็ได้ ข้อดีของ Claude Skills เมื่อเทียบกับ MCP คือมันสร้างได้ง่าย แค่เขียนข้อความก็ทำได้ ใครก็ใช้ได้ แต่ก็พึ่งพาสภาพแวดล้อมมาก เช่น ถ้าต้องใช้เครื่องมือเฉพาะบางอย่างในการทำงาน แล้วจะทำให้มันเป็นอัตโนมัติ ต้องตั้งค่า sandbox ยังไง? แถมยังยากจะมั่นใจด้วยว่าเป็นเวอร์ชันที่ถูกต้องจริงหรือเปล่า

• ในบริษัทเราก็ลองทำอะไรคล้าย ๆ กันภายใน เรามีไฟล์คอนเท็กซ์ของ monorepo ที่ใหญ่เกินไป เลยสร้างต้นไม้ของ fragment ที่โหลดเพิ่มทีละส่วนตามงาน เอกสารคอนเท็กซ์พวกนี้ดูเผิน ๆ คล้ายเอกสารสำหรับนักพัฒนาทั่วไปมาก แต่จริง ๆ แล้วมีประโยชน์กว่าเยอะและเน้นงานเป็นหลัก ทำให้นึกสงสัยว่าทำไมเมื่อก่อนเราถึงทำเอกสารแบบนี้ไม่ได้

  1. วงจรฟีดแบ็กมันยาวเกินไป เขียนเอกสารไปแล้วอาจไม่มีวันรู้เลยว่ามันได้ผลไหม หรือกว่าจะรู้ก็อีกหลายปี การแก้ไขก็ทำ A/B test อะไรแบบนั้นไม่ได้ ตอนนี้แค่ลองเขียน context markdown ง่าย ๆ แล้วให้ Claude ใช้ ก็ปรับปรุงได้ทันที
  2. เครื่องมือทุกวันนี้ช่วยให้การเขียนเอกสารเองง่ายขึ้นด้วย การทำเอกสารดี ๆ แต่ก่อนเป็นเรื่องยากเสมอ และถ้าจะใส่ตัวอย่าง ลิงก์ หรือข้อมูลเสริมที่มีประโยชน์ก็ใช้เวลามหาศาล แต่ตอนนี้ต้นทุนลดลงเพราะมีเครื่องมือช่วย
  3. นักพัฒนาหลายคนก็เห็นแก่ตัวพอสมควร เอกสารที่เขียนเพื่อคนอื่นมักไม่ค่อยมีแรงจูงใจ แต่ถ้าเป็นเอกสารที่ช่วยให้สั่ง AI ได้ดีขึ้น ก็จะมีแรงจูงใจขึ้นมาเอง ไม่รู้ว่ามีทฤษฎีอื่นอีกไหม

  • นี่แทบจะเป็นปัญหา principal agent ที่ผสมความเป็น marshmallow test อยู่ด้วย ถ้านักพัฒนาต้องเขียนเอกสารให้คนอื่นแทน AI เขาไม่รู้ด้วยซ้ำว่าคนนั้นคือใคร ต้องการอะไร หรือจะได้อ่านจริงไหม แน่นอนว่าทีหลังมันอาจกลับมาช่วยตัวเองได้ แต่การจะเข้าใจแบบนั้นหรือมีเวลาและวินัยพอก็ไม่ง่าย แต่ถ้าเป็นสถานการณ์ที่ AI ใช้เอกสารนั้นมาช่วยผมโดยตรง ก็จะมีแรงจูงใจแบบฉับพลันมหาศาลให้จดสิ่งที่จำเป็นไว้ อีกอย่าง วงจรฟีดแบ็กก็สั้นลงด้วย อนึ่ง ด้วยธรรมชาติของ LLM ที่ชอบลบคอมเมนต์ในโค้ด ทุกวันนี้ผมเลยทิ้งเอกสารไว้มากขึ้นและใส่คอมเมนต์น้อยลงมาก

  • นักพัฒนาใหม่มักไม่ค่อยบ่นว่าเอกสารห่วย เพราะกลัวจะดูโง่ คนเขียนเองก็มีโมเดลอยู่ในหัวอยู่แล้ว เลยไม่ค่อยรู้สึกว่ามีปัญหา และการเขียนเอกสารดี ๆ ก็เหมือนเป็นการทำให้งานตัวเองเสี่ยง แต่ถ้ายื่นเอกสารห่วย ๆ ให้หุ่นยนต์โง่ ๆ แล้วมันทำงานไม่ออก ก็ต้องโทษตัวเอง สรุปแล้วผมคิดว่าเป็นข้อ #2 + #3 และถ้าจะมีการเปลี่ยนแปลงครั้งใหญ่ มันคือการที่ "ความสามารถในการถูกแทนที่" เปลี่ยนจากเรื่องลบเป็นเรื่องบวก (แทนที่จะรอให้ agent ราคาถูกมายึดที่ของตัวเอง ก็เปลี่ยนตัวเองให้เป็น agent ไปก่อน)

  • คล้ายกับเหตุผลที่หนี้ทางเทคนิคมีอยู่: แรงกดดันทางธุรกิจ การออกแบบที่ผิดพลาด และทรัพยากรไม่พอ เมื่อก่อนการคอยทำเอกสารดี ๆ ให้ทันทุกครั้งที่โค้ดเปลี่ยน เป็นเรื่องที่มีต้นทุนสูงมากจริง ๆ

• พอนึกภาพว่ามีหลาย ๆ skills อยู่ในโฟลเดอร์เดียว ผมจะนึกถึงงานอย่างการบอกตำแหน่งข้อมูลสำมะโนสหรัฐหรืออธิบายวิธีตีความโครงสร้างข้อมูล พอได้ยินแบบนี้ก็นึกถึงตอนใช้ Wolfram Alpha ครั้งแรก ทึ่งมากที่มันแก้ปัญหาด้วยเครื่องมือที่มีโครงสร้างจริง ๆ ไม่เหมือน search engine ทั่วไป พอลองใช้อีกครั้งตอนนี้ก็ยังสุดยอดอยู่: ค้นหาข้อมูลประชากรสหรัฐด้วย Wolfram Alpha โมเดลเรื่อง Skills ในหัวผมคล้ายกับการเอาส่วนขยายแบบ custom ไปเพิ่มบน Wolfram Alpha

  • ผมลองกดลิงก์ที่คุณแปะแล้ว Wolfram Alpha เปิดคำค้นเป็น what%27s the total population of the United States%3F ผลลัพธ์ที่ได้ตลกมาก มันขึ้นว่า 6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates) อยากรู้จริง ๆ ว่ามันคำนวณออกมายังไง

  • เอาจริง Wolfram Alpha ยุคก่อนนี่เป็นความสำเร็จที่บ้าคลั่งมาก จนถึงตอนนี้ผมก็ยังทึ่งว่าพวกเขาสร้างระบบที่จัดการโจทย์คณิตซับซ้อนได้โดยไม่มี AI ในยุคนั้นได้ยังไง

• ผมยังสับสนอยู่หน่อย ๆ ว่า Skills ต่างจากเครื่องมือเดิม ๆ ยังไง skills หลายตัวก็ดูเป็นแค่เครื่องมือ หรือไม่ก็เป็นชุดของหลายเครื่องมือพร้อมคำอธิบายเพิ่ม แต่เหมือนนิยามของ tool กับ skill อยู่กันคนละที่ไม่ใช่หรือ? เลยสงสัยว่าจะระบุ dependency ระหว่างสองอย่างนี้ยังไง ถ้า skills ระบุว่า "ใช้ command line ได้, python, ต้องมี tool A, tool B" หมายความว่าตอนโหลด skill เครื่องมือเหล่านี้จะถูกเปิดใช้ไปพร้อมกันหรือเปล่า?

• ที่น่าสนใจจริง ๆ คือทุกคนหมกมุ่นกับ MCP มากเกินไปและทำตัวตาม path dependency สิ่งที่น่าสนใจจริง ๆ กลับเป็นแค่ "tool call" เองต่างหาก tool call มีประโยชน์และน่าทึ่งมาก MCP เป็นแค่หนึ่งในหลายวิธีที่จะทำมันได้เท่านั้น แถมก็ไม่ใช่วิธีที่ยอดเยี่ยมอะไรขนาดนั้น

  • ผมคิดว่าที่ MCP แพร่เร็วขนาดนี้เป็นเรื่องของจังหวะล้วน ๆ ก่อน MCP ก็มีการเรียกใช้เครื่องมืออยู่แล้ว แต่โมเดลยังทำได้ไม่ดี พอ MCP ออกมาตรงกับช่วงที่โมเดลเริ่มเรียกใช้เครื่องมือได้ดีพอดี ผู้คนเลยเพิ่งตระหนักว่า LLM สามารถเรียกใช้เครื่องมือเพื่อโต้ตอบกับระบบอื่นได้ และนั่นแหละคือแก่นของกระแส MCP

  • MCP server ก็แทบจะเป็น registry สำหรับลงทะเบียน tool call แล้วมันแย่กว่าการทำ tool call ปกติยังไง?

  • สิ่งที่ทำให้ MCP มีความหมายคือมันทำให้ LLM เข้าใจแนวคิดแบบ oauth จึงทำให้การเรียกใช้เครื่องมือแบบอิงเซิร์ฟเวอร์เป็นไปได้ เมื่อก่อนแต่ละ cli ที่จะใช้ต้องติดตั้งแยก แล้วก็จัดการการยืนยันตัวตนในนั้นอีกที ผมก็เห็นด้วยว่า tool calling คือจุดแข็งใหญ่ที่สุดของ LLM แต่การที่มันทำให้เห็นชัดว่าต้อง "ใส่ใจกับการยืนยันตัวตนของเครื่องมือ" ก็มีคุณค่ามากเหมือนกัน

  • อนึ่ง MCP เองก็เป็นฟีเจอร์ที่ Anthropic เป็นคนสร้างนวัตกรรมไว้เหมือนกัน

  • ต่อให้ไม่พูดถึง Skills ผมก็อยากรู้ว่าถ้ามีวิธีที่ดีกว่า MCP มันจะเป็นแบบไหน

• อิทธิพลของ MCP กว้างไกลเกินกว่าแค่ในเทอร์มินัลมาก ใช้ได้ทั้งใน ChatGPT, Claude Web, n8n, LibreChat และยังคิดเรื่องการยืนยันตัวตน ทรัพยากร ไปจนถึง UI (เช่น apps-sdk) ไว้แล้ว ถ้าโฟกัสที่ workflow การเขียนโค้ดหรือ agent แบบ CLI (อย่าง Claude Code) เครื่องมือ CLI ก็มีคุณค่ามหาศาล แต่ในงานสาย CRM, การขาย, ซัพพอร์ต, ปฏิบัติการ, การเงิน เครื่องมือแบบ MCP จะเหมาะกว่า Skills กับ MCP ไม่ได้แข่งกัน แต่มีจุดประสงค์ที่เสริมกัน โดยเฉพาะตอนที่โค้ด Python ของ Skills สามารถเรียก MCP โดยตรงผ่าน interpreter ได้ นั่นแหละคือก้าวกระโดดจริง ๆ (พวกเราลองแล้วและเวิร์กมาก)

  • ข้อดีใหญ่ข้อหนึ่งของ MCP เมื่อเทียบกับเครื่องมือแบบเทอร์มินัลคือมันทำงานได้โดยไม่ต้องมี sandbox อย่างสภาพแวดล้อม Linux ที่แยกเต็มรูปแบบ และยังใช้กับโมเดลที่ง่ายกว่ามากได้ด้วย โมเดลที่รันบนโน้ตบุ๊กหรือแม้แต่บนมือถือก็ยังจัดการ MCP สักสองสามตัวได้สบาย แต่จะให้โมเดลแบบนั้นอ่านไฟล์และใช้ curl อย่างน่าเชื่อถือนี่ค่อนข้างเกินไป

  • การเอา LLM ไปเชื่อมกับซอฟต์แวร์ภายนอกหรือโลกจริงตอนนี้ให้ความรู้สึกเจ๋งมาก และทั้งหมดนี้ทำได้ด้วยภาษาธรรมชาติ แถม LLM ยังเขียนโค้ด MCP server ได้ด้วย ทำให้สร้างความสามารถใหม่ ๆ จากศูนย์ได้ง่ายมาก

• พูดตามตรง ผมคิดว่า MCP ถูกประเมินค่าสูงเกินไปและข้อจำกัดก็ชัดเจนมาก MCP server ปัจจุบัน 95% ใช้ประโยชน์ไม่ได้ และแทนที่ด้วย tool call ธรรมดาก็พอแล้ว

  • ก็จริงที่ MCP server ที่ทำมาดีนั้นดีมาก แต่ MCP server ที่ทำมาแย่กลับสร้างปัญหาหนักกว่าเดิม ปกติทุกทีมผลิตภัณฑ์มักถูกกดดันว่า "MCP กำลังฮิต" เลยต้องมี MCP server ให้ได้ ลูกค้าเองก็มีเป้าหมายเรื่องการใช้ AI อยู่แล้วจึงร้องขอสิ่งนี้ แต่จริง ๆ ก็ไม่รู้ว่าต้องการอะไร แค่พูดได้ว่า "มี AI แล้ว" ก็พอ ดังนั้นทีมผลิตภัณฑ์เลยใช้ MCP เป็นวิธีโปรโมตว่า "นี่คือผลิตภัณฑ์ AI ของเรา" ได้เร็ว แม้ผลลัพธ์จากการใส่ AI จะไม่ชัดเจนนัก เป็นปรากฏการณ์ที่แทบไม่เกี่ยวกับแก่นแท้ของ AI เลย

  • MCP ใช้ได้ก็ต่อเมื่อคุณเชื่อใจผู้ให้บริการเซิร์ฟเวอร์ มันพึ่งพาความซื่อสัตย์ของเซิร์ฟเวอร์โดยปริยาย ในโลกจริง บริษัทอย่าง Uber คงจะใช้ prompt engineering ทุกแบบเพื่อชี้นำให้ LLM คิดว่าบริการของตัวเองเป็นตัวเลือกที่ดีที่สุดอยู่ตลอด สุดท้ายแรงจูงใจระหว่าง publisher กับ consumer ของ MCP ก็ไม่ตรงกันโดยสิ้นเชิง

  • ผมก็เห็นด้วยว่าท้ายที่สุดแล้ว tool call คือหัวใจ แต่ MCP มีข้อดีเหนือ CLI อย่างน้อยสองอย่าง อย่างแรกคือถ้าเป็น LLM ที่ใช้ tool call และต้องการผลลัพธ์แบบมีโครงสร้าง พร้อมทั้งทำปฏิสัมพันธ์ที่ซับซ้อน MCP จะง่ายกว่า CLI อีกอย่างคือ state ระหว่าง tool call หลายครั้งสามารถคงอยู่บน MCP server ได้อย่างเป็นธรรมชาติ ตอนแรกผมก็คิดว่าตัวเองอาจหลง hype ไปเหมือนกัน แต่เดโมเล็ก ๆ ที่ทำขึ้นมาเพื่อเรียน MCP ช่วงหลัง (https://github.com/cournape/text2synth) กลับทำง่ายกว่าถ้าจะทำด้วย CLI และผมคิดว่ากรณีแบบนี้แสดงศักยภาพการใช้งาน MCP ที่น่าสนใจได้ดี

  • MCP server ดูเป็นที่นิยมมากในหมู่แฮ็กเกอร์ มีอินสแตนซ์ที่ตั้งค่าแบบลวก ๆ และปล่อยใช้งานแบบขอไปทีอยู่เยอะเกินไป บริษัทต่าง ๆ เหมือนลบแนวป้องกันเรื่องการ deploy ที่เคยมีทิ้งไปหมดแล้ว

  • ทีมฟรอนต์เอนด์ของเราดึงคุณค่าจาก figma MCP ได้มหาศาล งานที่เคยใช้เวลา 3 สัปดาห์ ทำเสร็จได้ในวันเดียว

• ผมเองก็ทำอะไรที่พอ ๆ กับ skills ได้ด้วยไฟล์ markdown แค่ไม่กี่ไฟล์ แค่เตือน agent เรื่อง skill สักครั้งต่อ session ก็พอแล้ว ผมยังไม่ค่อยเข้าใจว่าที่ Claude ทำอยู่นี่มีอะไรพิเศษ

  • ส่วนสำคัญคือการตั้งชื่อให้กับแพตเทิร์นแบบหนึ่ง มันเป็นแพตเทิร์นที่มีประโยชน์ซึ่งหลายคนค้นพบและใช้งานกันเองอยู่แล้ว พอมีชื่อ ก็เปิดทางให้คุยกันในระดับที่ลึกขึ้นได้ Anthropic ยังจับได้ด้วยว่าแพตเทิร์นนี้ช่วยแก้ปัญหาเรื้อรังของ coding agent เรื่อง "context ปนเปื้อน" ได้ AGENTS.md หรือ MCP ในอดีตมักอัดข้อมูลเข้าคอนเท็กซ์มากเกินไปจนใช้งานจริงลำบาก แต่แพตเทิร์น skills มีประสิทธิภาพกว่ามาก

  • มันให้ความรู้สึกเหมือนเอาปัญหาที่แก้ไปแล้วมาจัดโครงสร้างอย่างเป็นทางการ และเพิ่มระบบอัตโนมัติเข้าไปอีกนิด ก่อนหน้านี้ MCP หลายตัวที่ผมเคยใช้ก็เป็นแค่ระบบค้นหาเอกสารแบบ fancy และผมหวังว่า skills แบบนี้จะมาแทนสิ่งเหล่านั้นได้

  • ผมก็สงสัยเหมือนกัน ผมใช้มันแบบนี้กับ Aider หรือ CC มามากกว่าหนึ่งปีแล้ว

• อันนี้อาจจะฟังดูแง่ลบนิดหน่อย แต่อยากรู้ว่ามีใครรู้สึกคล้ายกันไหม ถ้าคาดหวังให้ผู้ใช้ทั่วไปมาตั้งค่าบริการแบบนี้เอง พวกเขาก็คงคิดว่า "บ้าไปแล้วเหรอ" คนส่วนใหญ่แค่อยากล็อกอิน ขออะไรบางอย่าง แล้วระบบจัดการที่เหลือให้เอง MCP, Apps, Skills, Gems ทั้งหมดนี้กำลังแก้ปัญหาผิดจุด มันคล้ายช่อง YouTube ที่ทุก 6 เดือนจะบอกว่า "ภาษาโปรแกรมหรือเฟรมเวิร์กใหม่ตัวนี้ดีที่สุด" แล้วก็ทำ todo app แบบเดิมซ้ำ ๆ ได้มากสุด 6 รอบ มันมีแต่การปรับผิวเผินแบบวนซ้ำ แต่ปัญหารากฐานไม่ถูกแก้เลย เหมือนมีบางอย่างผิดเพี้ยนในแนวเทคโนโลยีนี้ และพอมีเงินไหลเข้ามาก็จะมีแต่งานเปิดตัวแบบนี้ออกมาเรื่อย ๆ แล้วก็ออกรุ่นถัดไป เลื่อนตำแหน่ง ย้ายงาน แต่ไม่เหลือคุณค่าที่เป็นแก่นจริง ๆ

  • ถ้าจะพูดถึงข้ออ้างที่ว่าปัญหารากฐานยังไม่ถูกแก้ ทุกวันนี้โซลูชันกลับแถมปัญหาใหม่มาเป็นแพ็กเกจเลย เปิดกล่องออกมา ปัญหากับโซลูชันกระโดดออกมาพร้อมกัน ไล่จับกันไปมา แล้วก็ทำให้รู้สึกเหมือนตัวเองเป็นมนุษย์ที่ก้าวหน้าทางเทคนิคมากขึ้น

  • เรื่องที่ว่า MCP, Apps, Skills, Gems ทั้งหมดกำลังแก้ปัญหาผิด ผมมองในแง่ลบว่าเรากำลังสร้างเอกสารและ API เพิ่มขึ้นเพื่อ AI ทั้งที่ถ้าทำเป็นเอกสารสำหรับคน ผลลัพธ์ก็คงไม่ต่างกันมาก ครึ่งหนึ่งของเวลาผมหมดไปกับการถูกลากไปดีบักระบบซับซ้อนที่ไม่มีเอกสาร

  • ผมอยากรู้ว่า "ปัญหารากฐาน" ที่ว่าคืออะไร และก่อนที่ ChatGPT จะดังเป็นวงกว้างในปี 2023 รอบการแก้ปัญหา "รากฐาน" แบบนี้มันใช้เวลาประมาณเท่าไร

  • ถ้าจะยกตัวอย่างเรื่อง "ทำ todo app เรื่องเดิม 6 ครั้งแล้วก็ลืมมันไป" ผมไม่ค่อยเข้าใจว่ามันเป็นปัญหาตรงไหน เทคโนโลยีก็ก้าวหน้าแบบค่อยเป็นค่อยไปและซ้ำ ๆ อยู่แล้ว พรุ่งนี้ก็จะมีคนทำวิดีโอเฟรมเวิร์กฟรอนต์เอนด์ที่ดีที่สุดขึ้นมาอีก เมื่อก่อนก็มี Nextjs ก่อนหน้านั้น React, Angular, JQuery, PHP, HTML ทำแบบเดียวกันมาแล้ว ถ้ากระสุนทั้งหมดไม่ได้เทไปที่ AI เราก็คงยังติดอยู่ที่ GPT-3 กับ Claude 2 ในมุมของเครื่องมือบางอย่างอาจมีของห่วยออกมาบ้าง (ผมว่า Skills ค่อนข้างดี) แต่เพราะแบบนั้นก็สรุปไม่ได้ว่าทั้งอุตสาหกรรมเน่าไปหมด

  • ก็ใช่ ตอนนี้ทุกอย่างยังอยู่ในช่วงเริ่มต้น และยังไม่มีใครรู้จริง ๆ ว่าอะไรเวิร์ก แม้มันจะดูเหมือนความพยายามผิวเผิน แต่จริง ๆ แล้วก็คือแนวหน้าสุดของเทคโนโลยี

• นี่เป็นคนละแนวคิดกันโดยสิ้นเชิง MCP คือการเชื่อมต่อบริการภายนอก รวมถึงการจัดการการยืนยันตัวตนอย่าง oauth ด้วย ส่วน Skills แทบจะเป็นการผสมกันของเครื่องมือ cli + prompt ขอบเขตการใช้งานต่างกัน เลยเทียบกันตรง ๆ ได้ยาก อนึ่ง ก่อน MCP จะมา เราเองก็สร้างระบบชื่อ Skillset ใช้กันอยู่ และพอมองตอนนี้ ผมคิดว่ามันเป็นไฮบริดที่ดีที่สุด ซึ่งผสมข้อดีของทั้ง MCP และ Skills เข้าด้วยกัน

[github88]

พูดเกินไปจริง ๆ