Skills, Subagents, MCP และ Plugins ใน Claude Code: ควรเลือกอะไร

ตอนนี้ใน Claude Code มีห้าวิธีทำ code review แบบเดียวกัน ได้แก่ slash command, skill, subagent, plugin หรือเพียงแค่พรอมป์ต์ในแชต และไม่มีวิธีใดดีกว่าวิธีอื่นโดยปริยาย การเลือกขึ้นอยู่กับงาน งบประมาณโทเค็น และคนอื่นที่จะใช้วิธีนั้นนอกเหนือจากคุณ

คู่มือนี้คือสิ่งที่ฉันอยากมอบให้ตัวเองเมื่อหนึ่งปีก่อน มีแผนผังคำถาม 4 ข้อ เมทริกซ์ “งาน → ชั้น” ที่พร้อมใช้ และข้อผิดพลาดทั่วไป 5 อย่างที่ทำให้โปรแกรมเมอร์สาย vibe คนอื่น ๆ ที่ฉันทำงานด้วยเสียโทเค็น

ดูวิธีทำงานกับบริการได้ในเอกสารประกอบของ Ailoot

AI agent skill คืออะไร และต่างจาก subagents, MCP และ plugins ใน Claude Code อย่างไร?#

ก่อนเลือก เรามาแยกความหมายของคำเหล่านี้กัน ทั้งสี่ชั้นมีเป้าหมายเดียวกัน คือขยายสิ่งที่ Claude ทำได้ตั้งแต่แรก แต่ละชั้นมีลักษณะเฉพาะของตัวเอง

Skill คือไดเรกทอรีที่มีไฟล์ SKILL.md อธิบายว่าเมื่อใดและอย่างไรจึงควรใช้ระเบียบวิธีหนึ่ง ๆ Anthropic เปรียบ skill กับคำแนะนำสำหรับพนักงานใหม่: คุณไม่ต้องบอกทุกขั้นตอนกับพวกเขาทุกวัน แต่ให้ขั้นตอนการทำงานไว้

Subagent คือเซสชัน Claude แยกต่างหากที่มีบริบทของตัวเอง และเริ่มทำงานจากบทสนทนาหลัก จุดเด่นสำคัญของมันคือการแยกบริบท Subagent สามารถอ่านไฟล์ 30 ไฟล์ สร้างสรุป แล้วส่งกลับมาเฉพาะสรุปให้แชตหลักได้ บริบทของบทสนทนาหลักจึงยังสะอาด

MCP (Model Context Protocol) คือมาตรฐานเปิดจาก Anthropic สำหรับเชื่อม Claude เข้ากับระบบภายนอก ในบล็อกโพสต์เมื่อวันที่ 13 พฤศจิกายน 2025 Anthropic อธิบายความแตกต่างไว้อย่างชัดเจนที่สุดว่า:

Plugin คือชุดสำเร็จรูปของ skills, subagents, hooks และคำสั่งที่ผู้อื่นสร้างและบรรจุไว้ใน marketplace ติดตั้งด้วยบรรทัดเดียวโดยใช้ /plugin install แล้วคุณก็ได้ทุกอย่างพร้อมกัน หาก skill คือขั้นตอนการทำงานของคุณเอง plugin ก็คือขั้นตอนที่ซื้อจากบริษัทอื่น

สรุปสั้น ๆ: skills คือสูตรทำงาน, subagents คือเพื่อนร่วมงานผู้เชี่ยวชาญ และ MCP จัดหาเครื่องมือภายนอกที่ Claude ใช้เข้าถึงบริการและข้อมูลได้ ค่าใช้จ่ายด้านโทเค็นแตกต่างกันไป: skill มีต้นทุนต่ำที่สุด (โหลดเมื่อเรียกใช้) ส่วน MCP มีต้นทุนสูงกว่ามาก (เซิร์ฟเวอร์ที่เชื่อมต่อแต่ละตัวใช้พื้นที่ใน context window ตลอดเวลา)

ทำไมต้องมี 4 ชั้น ถ้าใช้ CLAUDE.md ไฟล์เดียวได้?#

ในโปรเจกต์ที่กล่าวถึง CLAUDE.md เป็นแผนที่กฎขนาดใหญ่: สิ่งต่าง ๆ อยู่ที่ไหน วิธีเผยแพร่ และมีข้อตกลงอะไรบ้าง หากไม่มีไฟล์นี้ Claude จะเริ่มต้นแต่ละเซสชันใหม่จากศูนย์

แต่ CLAUDE.md มีขีดจำกัด ขออธิบายด้วยสามสถานการณ์ที่มันเริ่มใช้ไม่ได้

สถานการณ์ที่ 1: กฎใช้ได้แค่บางครั้ง CLAUDE.md ระบุว่า “รัน npm run build ก่อน git push เสมอ” Claude อ่านตอนเริ่มเซสชัน พยักหน้า เริ่มเขียนโค้ดหลังผ่านไป 25 ข้อความ แล้วก็ลืม ฉันจับได้แล้วว่าตัวเอง push โดยไม่ build ไปสามครั้ง และการ push เหล่านั้นล้มเหลวใน production hook ที่ตั้งถูกและทดสอบแล้วรัน build แบบกำหนดแน่นอนและปฏิเสธการกระทำที่ครอบคลุมได้ แต่ขอบเขตขึ้นกับ event และเส้นทางเครื่องมือ hook Claude Code ไม่ดักทุก push จากเทอร์มินัลหรือแอปอื่นเอง ต้องทดสอบว่า build ที่จงใจให้ตกบล็อกเส้นทางจริงที่คุณใช้

สถานการณ์ที่ 2: กระบวนการ 15 ขั้นตอนที่ต้องทำซ้ำ ในตัวอย่างที่กล่าวถึง คู่มือแต่ละเล่มผ่าน 14 ขั้นตอน ได้แก่ วิจัย → วางโครงสร้าง → MDX → ตรวจ QA 7 รายการแบบขนาน → เผยแพร่ขึ้น production → IndexNow ถ้าฉันเขียนพรอมป์ต์ทุกครั้งว่า “ทำขั้นตอนที่ 1 ต่อด้วย 2 แล้ว 3” ก็จะเสียโทเค็นไปก่อนเริ่มงานเสียอีก นั่นคือเหตุผลที่เวิร์กโฟลว์ทั้งหมดนี้ถูกรวมไว้ใน skill build-masterskaya-guide ซึ่งเป็นชุดคำสั่งขนาด 34 KB ที่เริ่มทำงานด้วยวลี “มาทำคู่มือใหม่สำหรับโปรเจกต์กัน”

สถานการณ์ที่ 3: งานที่กินบริบท หากต้องตรวจสอบว่าคู่มือที่เผยแพร่ไปแล้วทันสมัยหรือไม่ Claude ต้องอ่านบทถอดเสียงไลฟ์ขนาด 30 KB, บันทึกทบทวนย้อนหลัง 20 รายการที่มีขนาดรายการละ 5 KB และเปรียบเทียบกับเว็บไซต์ปัจจุบัน หากทำในแชตหลัก พอตรวจเสร็จบริบทของฉันจะเต็มไปด้วยข้อมูลรก ๆ ถึง 200K โทเค็น Subagent ทำงานเดียวกัน ส่งกลับมาเฉพาะสรุป 300 คำให้บทสนทนาหลัก แล้วปิดตัวลง

สถานการณ์ที่ 4: ฉันอยากให้ทีมได้เทมเพลตแบบเดียวกับที่ฉันมี ชุดกฎสำเร็จรูปสำหรับการออกแบบ frontend, hooks สำหรับเผยแพร่ผ่าน Coolify และ MCP สำหรับตรวจสอบด้วย Playwright นี่คือ plugin: ฉันรวมการตั้งค่าของตัวเอง เผยแพร่ใน marketplace แล้วเพื่อนร่วมงานก็ติดตั้งได้ด้วยบรรทัดเดียว

CLAUDE.md ครอบคลุมพื้นฐานว่า “เราทำงานกันอย่างไรที่นี่” ส่วนอีก 4 ชั้นครอบคลุมสิ่งที่ CLAUDE.md ทำไม่ได้ในทางปฏิบัติ ได้แก่ การทำซ้ำผ่าน triggers, การแยกบริบท การเข้าถึงโลกภายนอก และการแบ่งปัน

เมื่อใดควรใช้ skill แทน CLAUDE.md?#

วิธีทดสอบว่าเหมาะจะทำเป็น skill หรือไม่ง่ายมาก: คุณสังเกตว่าตัวเองคัดลอกพรอมป์ต์ยาว ๆ แบบเดิมจากโน้ตมาใส่แชตซ้ำ ๆ ครั้งที่สามก็เป็นสัญญาณแล้ว

ตอนนี้ฉันมี 7 ไดเรกทอรีใน ~/.claude/skills/: build-masterskaya-guide, build-vc-spoke, build-reel-script, build-practicum-instruction, update-config, simplify และ keybindings-help รายการที่ใช้มากที่สุดคือ build-masterskaya-guide (คู่มือนี้เขียนโดยใช้รายการนี้) ภายในมีระเบียบวิธีขนาด 34 KB: ต้องผ่านขั้นตอนใดบ้าง ต้องรันการตรวจ QA แบบหลายเอเจนต์รายการใด เงื่อนไข gate ใดควรหยุดกระบวนการ และต้องบันทึกอาร์ติแฟกต์ใดไว้ใน /tmp/

เมื่อใดไม่ควรสร้าง skill

• กฎอย่าง “ตอบเป็นภาษาที่ผู้ใช้ต้องการ” ควรอยู่ใน CLAUDE.md ไม่ใช่ skill เพราะ skill จะโหลดเมื่อถูกเรียกใช้ แต่กฎนี้ควรมีผลตลอดเวลา
• คำสั่งที่ใช้ครั้งเดียว เช่น “รันการรีแฟกเตอร์ตอนนี้” ควรอยู่ในแชต ไม่ใช่ skill
• งานที่ต้องการบริบทแยกใช้ซับเอเจนต์ได้ หากมีขั้นตอนทำซ้ำด้วย ให้เก็บระเบียบวิธีในสกิล

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

ดูวิธีจัดโครงสร้าง skill สิ่งที่ควรใส่ใน frontmatter และวลีเรียกใช้แบบใดที่ได้ผลในคู่มือ Claude Code Skills ในปี 2026: วิธีสร้างคลัง Skills ส่วนตัว

เมื่อใดควรใช้ subagent แทน skill?#

Skill เก็บระเบียบวิธี ส่วน subagent ทำงาน ทั้งสองเป็นคนละชั้นกัน แต่มักสับสนเพราะเริ่มทำงาน “จากแชต” เหมือนกัน

Subagent มีประโยชน์เฉพาะเมื่อจำเป็นต้องแยกบริบท เซสชัน Claude หลักมีงบ 200,000 โทเค็น (หรือ 1 ล้านในรุ่น beta) หากขอให้มันอ่านไฟล์ 30 ไฟล์และวิเคราะห์ทีละไฟล์ในแชตหลัก คุณจะเสียพื้นที่ไปครึ่งหนึ่งกับการอ่านระหว่างทำงาน Subagent ทำงานเดียวกันทั้งหมดในเซสชันแยกต่างหาก แล้วส่งกลับมาเฉพาะผลลัพธ์ให้แชตหลัก

ตัวอย่างจากโปรเจกต์ที่เป็นรูปธรรม คู่มือทุกเล่มผ่านการตรวจ QA หลายรายการแบบขนาน ได้แก่ สไตล์ การตรวจคำอ้างอิงและข้อเท็จจริงกับแหล่งข้อมูลปฐมภูมิ โครงสร้างสำหรับเครื่องมือค้นหา และความครบถ้วนของลิงก์ภายในและภายนอก การตรวจแต่ละรายการใช้บริบทของตัวเอง เช่น อภิธานศัพท์กฎ ใช้ WebFetch กับ URL หลายสิบรายการ และ grep ข้อความ

หากฉันรันการตรวจทั้งหมดในแชตเดียว บริบทคงท่วมฉันก่อนที่การตรวจแรกจะเสร็จ การเรียกใช้ subagents พร้อมกันด้วย run_in_background: true ช่วยแก้ปัญหานี้: พวกมันทำงานเบื้องหลัง แชตหลักทำงานต่อ และหลังจาก 4–6 นาที ฉันก็ได้รายงานแบบกระชับและนำการแก้ไขไปใช้

ตัวอย่างที่สอง — งานวิจัยหนัก เมื่อเลือกหัวข้อสำหรับคู่มือใหม่ subagents 4 ตัวจะรวบรวมสัญญาณพร้อมกัน:

• V1 - ฟอรัมและชุมชนในช่วง 14 วัน
• V2 - เครือข่ายสังคมออนไลน์
• V3 - แพลตฟอร์มวิดีโอ + บล็อก Anthropic
• V4 - ช่องว่าง SEO

แต่ละตัวส่งกลับมา 30–40 รายการพร้อมคะแนนความไวรัล ฉันรวบรวมเป็นชุดข้อมูล ให้ค่าน้ำหนักใน 9 มิติ แล้วเลือกตัวที่ดีที่สุด หากไม่มี subagents ขั้นตอนนี้จะยืดเป็น 2–3 ชั่วโมง พร้อมกับเผาผลาญบริบทหลัก

เมื่อใดไม่ควรสร้าง subagent

• งานที่ไม่ต้องอ่านไฟล์หรือใช้ WebFetch ควรทำในแชตหลัก
• ขั้นตอนทำซ้ำอยู่ในสกิล แต่รันภายในซับเอเจนต์ได้เมื่อการแยกมีประโยชน์
• การเข้าภายนอกต้องมีเครื่องมืออนุญาต เช่น MCP หรือ CLI ซับเอเจนต์ใช้เครื่องมือนั้นได้เมื่อรับมอบงาน

รูปแบบต่อต้านหลัก การสร้าง subagent ชื่อ backend-engineer หรือ qa โดยหวังว่า Claude จะเข้าใจเองว่าควรใช้เมื่อใด subagents ที่เจาะจง (เช่น migration-test-writer หรือ api-route-reviewer) ให้คุณภาพดีกว่า subagent ทั่วไปมาก ยิ่งชื่อและคำสั่งของ subagent เฉพาะเจาะจงมากเท่าไร Claude ก็จะเลือกใช้ได้แม่นยำขึ้นเท่านั้น

ดูวิธีสร้าง subagents สำหรับงานเฉพาะ ไวยากรณ์ frontmatter และตัวอย่างพร้อมใช้ 5 รายการในคู่มือ Claude Code Subagents ในปี 2026: คู่มือทีละขั้นตอน

เมื่อใดควรใช้ MCP แทน skill หรือ subagent?#

Anthropic ให้สูตรที่สั้นที่สุดสำหรับความแตกต่างนี้ไว้ในบล็อกโพสต์: MCP เชื่อม Claude เข้ากับข้อมูล ส่วน skills สอน Claude ว่าจะทำอะไรกับข้อมูลนั้น

เช่น สกิลรีวิว GitHub issue ต้องมีเนื้อหา issue ให้ผ่าน MCP ที่อนุญาต CLI หรือข้อความที่ผู้ใช้ให้ สกิลกำหนดว่าจะรีวิวและจัดข้อค้นพบอย่างไร ส่วนสิทธิ์ MCP อย่างเดียวไม่ได้กำหนดขั้นตอนนั้น

ชุด MCP ที่ฉันใช้โดยเฉพาะ

• Playwright MCP - ตรวจ QA ด้วยภาพสำหรับคู่มือทุกเล่ม เปิดหน้าเว็บบนเดสก์ท็อปและมือถือ ตรวจความกว้างของ container และดูว่าบล็อกต่าง ๆ แสดงผลแล้วหรือยัง
• Stitch MCP - เข้าถึงระบบออกแบบและสร้างคอมโพเนนต์ตามสไตล์แบรนด์
• vidIQ MCP - วิเคราะห์เทรนด์และตรวจสอบแนวคิดเรื่องความไวรัล
• Railway MCP - จัดการโครงสร้างพื้นฐานสำหรับ deployment

ทั้ง 4 ตัวนี้เป็นสะพานเชื่อมไปยังระบบภายนอก หากไม่มี MCP ฉันจะต้องเขียน wrapper code เองหรือเปลี่ยนไปใช้เบราว์เซอร์ เมื่อมี MCP ทุกอย่างเกิดขึ้นภายในเซสชัน Claude

ต้นทุนโทเค็น MCP เป็นชั้นที่มีค่าใช้จ่ายสูงที่สุด แต่ละเซิร์ฟเวอร์ที่เชื่อมต่อใช้พื้นที่ใน context window ตลอดเวลา ทั้งคำประกาศเครื่องมือ สคีมาอาร์กิวเมนต์ และคำอธิบาย ฉันมี MCP servers 4 ตัว ซึ่งใช้ประมาณ 8–12K โทเค็นในทุกเซสชันใหม่ ก่อนที่ฉันจะถามอะไรเสียอีก

ดังนั้นเราควรเชื่อม MCP เฉพาะเมื่อจำเป็นจริง ๆ ในเซสชันส่วนใหญ่ หากใช้ Sentry MCP สัปดาห์ละครั้ง ให้เปิดใช้งานตามต้องการด้วยแฟล็ก --mcp sentry จะดีกว่าปล่อยไว้ในรายการถาวร

เมื่อใดไม่ควรใช้ MCP

• ระเบียบวิธีเรื่อง “วิธีทำงานกับข้อมูล” ควรอยู่ใน skill ไม่ใช่ MCP
• งานอ่านยาวอาจได้ประโยชน์จากซับเอเจนต์ หากไฟล์หรือระเบียนบางส่วนอยู่ภายนอก ซับเอเจนต์นั้นอาจต้องมีสิทธิ์ MCP ด้วย
• การเผยแพร่ด้วยคำสั่งเดียวควรใช้ hook หรือ plugin ไม่ใช่ MCP

รูปแบบต่อต้านหลัก การสร้าง MCP server สำหรับสิ่งที่เหมาะกับ skill มากกว่า ฉันเห็นตัวอย่างหนึ่งในวงสนทนา HN (กระทู้เดียวกับที่มี 422 คะแนนเมื่อวันที่ 27 พฤษภาคม): ผู้เขียนสร้าง MCP server ที่ให้ “คำแนะนำสำหรับ code review” แต่สิ่งนั้นไม่ใช่การเข้าถึงโลกภายนอก มันคือขั้นตอนการทำงาน Skill ทำสิ่งเดียวกันได้โดยใช้โทเค็นน้อยกว่า 10 เท่า

เหตุการณ์ทรัพยากรชนกัน ครั้งหนึ่ง Playwright MCP ค้างพร้อมข้อผิดพลาด “Browser is already in use” ตอนนั้นฉันเปิดหน้าต่าง Chrome อยู่ด้วย และ MCP ก็เข้าควบคุมเบราว์เซอร์ไม่ได้ บทเรียนสำคัญคือ MCP server ใช้ทรัพยากรระบบร่วมกัน หากทรัพยากรเกิดการแย่งใช้ (เบราว์เซอร์ พอร์ต หรือไฟล์) ให้คิดถึงการแยกการใช้งานตั้งแต่ต้น

คู่มือพร้อมใช้สำหรับเชื่อมต่อ MCP ที่ใช้งานได้ 7 ตัวอยู่ใน Claude Code MCP Servers ในปี 2026: การตั้งค่าพร้อมใช้ 7 แบบ

เมื่อใดควรใช้ plugin แทน skill หรือ subagent?#

Skills, subagents และ MCP เป็นเรื่องระเบียบวิธีของคุณ ส่วน plugin คือระเบียบวิธีสำเร็จรูปของผู้อื่นที่นำเข้ามาใช้ในการตั้งค่าของคุณ

ในเดือนตุลาคม 2025 Anthropic เปิดตัว Claude Code Plugins ซึ่งเป็นกลไกเผยแพร่อย่างเป็นทางการ Plugin คือไดเรกทอรีที่มีสิ่งต่อไปนี้ได้:

• slash commands ของตัวเอง
• skills ของตัวเอง
• subagents ของตัวเอง
• hooks ของตัวเอง
• การตั้งค่า MCP ของตัวเอง
• รูปแบบเอาต์พุตของตัวเอง

ทั้งหมดนี้ถูกรวมไว้ในแพ็กเกจเดียวด้วย plugin.json ติดตั้งได้ด้วยบรรทัดเดียวใน ~/.claude/settings.json หรือใช้คำสั่ง /plugin install <name>

ชุด plugins ที่ฉันใช้โดยเฉพาะ

• frontend-design จาก claude-plugins-official อย่างเป็นทางการ — มี 67 สไตล์, 96 พาเลตต์, คู่ฟอนต์ 57 ชุด และเฟรมเวิร์ก 13 รายการ เมื่อสร้างบล็อกใหม่สำหรับเว็บไซต์หรือเทมเพลตอีเมล ฉันโหลด plugin นี้แล้วได้คลังทั้งหมดมาพร้อมกัน
• playwright จาก marketplace อย่างเป็นทางการเดียวกัน — ชุด skills พร้อมการตั้งค่า MCP สำหรับทดสอบเบราว์เซอร์
• telegram — ชุดพร้อมใช้สำหรับจัดการบัญชี Telegram จาก Claude Code (นโยบาย, allowlist, pairing)
• trailofbits/skills — ชุด skills ด้านความปลอดภัยจาก Trail of Bits บริษัทที่ฉันเชื่อถือในเรื่องความปลอดภัย

ทั้ง 4 รายการใช้เพียงสามบรรทัดใน settings.json หากไม่มี plugins ฉันคงต้องเสียเวลาหลายชั่วโมงสร้างคลังเดียวกันขึ้นมาเอง

เมื่อใดไม่ควรใช้ plugin

• หากระเบียบวิธีเป็นของคุณทั้งหมดและไม่ต้องขยายให้คนอื่นใช้ ให้เก็บไว้เป็น skill
• หากยังไม่รู้ว่าใครจะใช้ ให้ลองใช้เองในรูปแบบ skill ก่อน
• หากต้องการย้ายไฟล์สามไฟล์ไปยังเครื่องใหม่อย่างรวดเร็ว คำสั่ง cp ~/.claude/skills/X /new/machine/.claude/skills/ ก็ทำได้

รูปแบบต่อต้านหลัก ใช้ plugin แทน CLAUDE.md เช่น plugin ที่มีกฎว่า “เราทำงานกันอย่างไรในโปรเจกต์นี้” Plugin ออกแบบมาเพื่อเผยแพร่และนำกลับมาใช้ซ้ำ หากกฎเป็นของ repository เดียว ก็ควรอยู่ใน CLAUDE.md ไม่ใช่ plugin

มองไปข้างหน้าถึงปี 2026: เห็นได้ชัดว่า Anthropic กำลังมุ่งไปสู่ marketplace สำหรับ plugins ระดับทีม นั่นหมายความว่าบริษัทต่าง ๆ จะเผยแพร่ระเบียบวิธีภายในของตนเป็น plugins จัดการเวอร์ชัน และอัปเดตให้พนักงานทุกคนได้ด้วยคำสั่งเดียว สำหรับผู้ประกอบการที่ทำงานคนเดียว นั่นหมายความว่าให้ติดตั้งสิ่งที่พร้อมใช้แล้ว และไม่ต้องสร้างขึ้นมาใหม่

แผนผังการตัดสินใจ: 4 คำถามที่ควรถามก่อนเริ่มแต่ละงาน#

คำถาม 1: มีขั้นตอนทำซ้ำที่ควรเก็บหรือไม่?

หากใช่ รวมระเบียบวิธีเป็น skill ใน SKILL.md พร้อม description ชัดว่าใช้เมื่อไร สกิลให้ขั้นตอน ไม่ได้ให้สิทธิ์ภายนอกหรือบริบทแยกเอง

คำถาม 2: ควรมีบริบทแยกหรือบทบาทรับมอบที่เน้นงานหรือไม่?

หากใช่ ใช้ subagent ให้งานกับเครื่องมือชัด งานเดียวกันทำตามระเบียบวิธีสกิลในบริบทแยกได้

คำถาม 3: ต้องใช้เครื่องมือหรือข้อมูลภายนอกหรือไม่?

หากใช่ ให้สิทธิ์ที่อนุญาตผ่าน MCP หรือเครื่องมือเหมาะสมอื่น เช่น CLI ที่ตั้งแล้ว สกิลบอกวิธีใช้ ส่วนซับเอเจนต์เป็นผู้ใช้เครื่องมือนั้นได้

คำถาม 4: ควรแจกและดูแลชุดตั้งค่านี้เป็นแพ็กเกจหรือไม่?

หากใช่ ใช้ plugin แจก skills นิยามเอเจนต์ hooks หรือค่า MCP ที่เกี่ยวข้อง แพ็กเกจเป็นของคุณเองหรือผู้เขียนอื่นได้

ตัวอย่างรวม: รีวิว GitHub issue ซ้ำเป็นประจำ สกิลกำหนดวิธีรีวิวกับรูปแบบผล MCP GitHub หรือ CLI ที่ตั้งให้สิทธิ์ issue ซับเอเจนต์อ่านเธรดยาวในบริบทตนแล้วคืนข้อค้นพบ plugin แจกชุดนี้ให้ทีม ทั้งสี่ข้อเป็น “ใช่” พร้อมกันได้ ไม่มีข้อใดยกเลิกอีกข้อ

5 ข้อผิดพลาดในการเลือกชั้นที่โปรแกรมเมอร์สาย vibe มักทำ#

ฉันเห็นรูปแบบเหล่านี้ทั้ง 5 แบบสัปดาห์ละครั้งในกลุ่มโปรแกรมเมอร์สาย vibe ที่ทำงานด้วย อย่างน้อยครึ่งหนึ่งทำผิดพลาดเหล่านี้อย่างน้อยหนึ่งข้อในสัปดาห์แรก

ข้อผิดพลาดที่ 1: ใช้ subagent แทน skill

อาการ: ผู้เขียนสร้าง subagent สำหรับ “เขียนบล็อกโพสต์ใหม่” ทุกครั้งที่เรียกใช้ subagent มันจะโหลด อ่านระเบียบวิธีขนาด 2 KB สร้างโพสต์ แล้วปิดตัว หลังผ่านไปหนึ่งสัปดาห์ ผู้เขียนสังเกตว่าแต่ละครั้งเสียโทเค็นเพิ่มอีก 5K เพื่อโหลด subagent

สิ่งที่ควรทำ: เก็บ “วิธีเขียนโพสต์” ในสกิลพร้อมคำบอกว่าใช้เมื่อไร จะรันในแชตหลักหรือซับเอเจนต์ให้เลือกตามประโยชน์ของบริบทแยกและบทบาทเฉพาะ แล้ววัดยอดใช้รวมกับผลที่ได้

ข้อผิดพลาดที่ 2: ใช้ MCP server แทน skill

อาการ: ผู้เขียนสร้าง MCP server ที่ให้คำแนะนำเรื่อง “วิธีทำ code review” คำประกาศเครื่องมือ คำอธิบายสคีมาอาร์กิวเมนต์ และเอกสาร ยังคงกินพื้นที่ในบริบท ทุกคำขอเสียโทเค็นไป 2–3K โดยเปล่าประโยชน์

สิ่งที่ควรทำ: “วิธีทำ code review” เป็นขั้นตอน ไม่ใช่การเข้าถึงระบบภายนอก ให้ใช้ skill MCP เหมาะสมเฉพาะเมื่อจำเป็นต้องเข้าถึงข้อมูลแบบเรียลไทม์ เช่น ใช้ Sentry ดึงข้อผิดพลาดล่าสุด

ข้อผิดพลาดที่ 3: ใช้ plugin แทน CLAUDE.md

อาการ: ผู้เขียนบรรจุกฎของโปรเจกต์ (“ใช้โหมด TypeScript strict เสมอ”, “อย่าใช้ขีดกลาง”, “ใช้ pnpm เท่านั้น ไม่ใช้ npm”) เป็น plugin แล้วติดตั้ง ตอนนี้ทุกเซสชันใหม่จะโหลด plugin ที่ทำซ้ำสิ่งซึ่งควรอยู่ใน CLAUDE.md

สิ่งที่ควรทำ: กฎของโปรเจกต์หนึ่งควรอยู่ใน CLAUDE.md ของโปรเจกต์นั้น Plugin มีไว้สำหรับระเบียบวิธีที่ขยายไปใช้กับคนหรือ repository หลายแห่งได้

ข้อผิดพลาดที่ 4: พยายามสร้าง skill ผ่าน hook

อาการ: ผู้เขียนเห็นว่า hook ทำงานอัตโนมัติเมื่อเกิดเหตุการณ์หนึ่ง (เช่น ก่อนบันทึกไฟล์) จึงตัดสินใจสร้าง “skill ผ่าน hook” เพื่อให้ Claude ใช้ระเบียบวิธีโดยอัตโนมัติทุกครั้งที่แก้ไขไฟล์ ผลที่ได้คือลูปการเรียกใช้ไม่รู้จบ เปลืองบริบท และมีพฤติกรรมคาดเดาไม่ได้

สิ่งที่ควรทำ: hook คือโค้ดที่ทำงานแบบกำหนดแน่นอนเพื่อรันคำสั่ง จัดรูปแบบผลลัพธ์ หรือบล็อกการทำงาน Hook ไม่ได้โหลด skill หรือเรียกใช้ Claude หากต้องการ “ใช้ระเบียบวิธี X เสมอ” ให้ใช้ skill ที่มี trigger หรือเพิ่มรายการไว้ใน CLAUDE.md

ข้อผิดพลาดที่ 5: เพิ่มชั้นโดยไม่จำเป็น

อาการ: ผู้เขียนได้ยินเรื่อง skills อ่านคู่มือ แล้วคิดว่า “ฉันต้องจัดระเบียบวิธีนี้เป็นชุด” จากนั้นก็ใช้เวลาทั้งเย็นสร้าง skill สำหรับงานที่ทำเดือนละครั้ง

สิ่งที่ควรทำ: งานครั้งเดียวควรทำในแชตตามสถานการณ์ Skill สมเหตุสมผลเฉพาะเมื่อทำสิ่งนี้มากกว่าวันละครั้ง มิฉะนั้นก็เป็นการออกแบบเกินจำเป็นและต้องคอยบำรุงรักษา

ทุกตัวอย่างให้ตรวจความต้องการอย่างอิสระ: ขั้นตอน การแยกบริบทหรือบทบาท สิทธิ์เครื่องมือ และการแจก เพิ่มแต่ละชั้นที่มีหน้าที่รูปธรรม และรวมเมื่อหนึ่งงานต้องใช้หลายชั้น

Anthropic พูดถึงการกระจัดกระจายอย่างไร: Claude Code กำลังมุ่งไปทางไหนในปี 2026#

สิ่งนี้หมายความว่าอย่างไรในช่วงหกเดือนถึงหนึ่งปีข้างหน้า

ประการแรก: skills กำลังกลายเป็นชั้นหลักสำหรับงานที่ทำตามขั้นตอน เห็นได้ชัดว่า Anthropic กำลังเดิมพันกับชั้นนี้ในฐานะตัวเลือกที่ต้นทุนต่ำและคาดการณ์ได้มากที่สุด หากคุณไม่เข้าใจว่าทำไมต้องใช้ skill ในปี 2026 ให้เริ่มศึกษาสิ่งนี้ก่อน ชั้นอื่น ๆ ทั้งหมดจะหมุนรอบมัน

ประการที่สอง: subagents กำลังเฉพาะทางมากขึ้น บทบาทหลักของ subagents คือแยกบริบทสำหรับงานหนัก Subagents ทั่วไปอย่าง qa-engineer จะหายไป ส่วนตัวเฉพาะทางอย่าง migration-test-writer และ api-route-reviewer จะยังคงอยู่

ประการที่สาม: ประกาศใหม่ของ Anthropic ในช่วง 14 วัน ได้แก่คำสั่ง /workflows (28 พฤษภาคม 2026) สำหรับควบคุม subagents หลายสิบตัว และการแยกการเรียกเก็บเงินของ Agent SDK ซึ่งเริ่มตั้งแต่วันที่ 15 มิถุนายน หมายความว่าการใช้งานแบบเขียนโปรแกรมกำลังย้ายไปยังโควตาแยกต่างหาก นี่เป็นสัญญาณว่า Anthropic กำลังสร้างโครงสร้างพื้นฐานสำหรับระบบอัตโนมัติที่มี agents มากกว่า 10 ตัว ไม่ใช่เซสชันรายบุคคล

สำหรับโปรแกรมเมอร์สาย vibe ในปี 2026 เรื่องนี้หมายถึงสิ่งง่าย ๆ อย่างหนึ่ง: สี่ชั้นนี้จะยังอยู่ต่ออย่างน้อยอีกหกเดือน แล้วบางชั้นจะถูกรวมเข้าด้วยกัน แต่แผนผังคำถาม 4 ข้อจะยังใช้ได้หลังการรวม เพราะมันเกี่ยวกับลักษณะของงาน ไม่ใช่ชื่อเฉพาะของชั้นนั้น

เมทริกซ์พร้อมใช้: 10 งานทั่วไป → ชั้นที่เหมาะสม#

กฎหลักในการใช้ตารางนี้คืออย่าพยายาม “ทำทั้ง 10 อย่างพร้อมกัน” โปรแกรมเมอร์สาย vibe ที่ทำงานคนเดียวส่วนใหญ่ใช้แค่ CLAUDE.md + 5–7 skills + MCP servers 2–4 ตัวก็เพียงพอ เมื่อโปรเจกต์เติบโตจึงค่อยเพิ่ม subagents และ plugins

ต่อไป: วิธีสร้างพื้นที่ทำงานของคุณใน Claude Code#

ทั้งห้าชั้นนี้ไม่ได้เรียงต่อกันเป็นลำดับ แต่ประกอบเข้าด้วยกัน CLAUDE.md เป็นรากฐานของโปรเจกต์ และอีกสี่ชั้นจะเชื่อมเข้ามาเมื่อภารกิจขยายตัว

ทำความรู้จักกับ Ailoot