17 คะแนน โดย GN⁺ 2025-10-17 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • Agent Skills ของ Anthropic ช่วยให้สามารถ ขยายความเชี่ยวชาญของ AI ให้สอดรับกับเวิร์กโฟลว์การทำงานของผู้ใช้ ได้
  • Skill คือ องค์ประกอบในรูปแบบโฟลเดอร์ที่มีคำสั่ง สคริปต์ และทรัพยากรอยู่ภายใน โดย Claude จะโหลดเฉพาะในช่วงเวลาที่จำเป็นต่อการทำงาน
  • ช่วยมอบ ความสามารถเฉพาะทางสำหรับงานบางประเภท เช่น การสร้าง Excel·PowerPoint การปฏิบัติตามแบรนด์ไกด์ เป็นต้น
  • ผู้ใช้หรือนักพัฒนาสามารถสร้าง Skill ได้เองและ นำไปใช้ได้ทั่วทั้ง Claude app, Claude Code และ API
  • ยังมีแผนรองรับการเผยแพร่และการจัดการในระดับองค์กร ซึ่งจะเป็น รากฐานของการสร้าง AI workflow แบบปรับแต่งเฉพาะ

ภาพรวมของ Skills และหลักการทำงาน

  • ฟีเจอร์ Agent Skills ช่วยให้สามารถใช้สกิลที่ปรับแต่งมาเพื่อให้ Claude ทำงานเฉพาะทางได้ดีขึ้น
  • สกิลถูกจัดให้มาในรูปแบบโฟลเดอร์ที่มี คำแนะนำ สคริปต์ และทรัพยากร โดย Claude จะเข้าถึงสกิลนั้นเฉพาะเมื่อจำเป็นกับงานที่เกี่ยวข้อง
  • ฟีเจอร์นี้ช่วยให้ใช้งาน Claude กับงานเฉพาะทางได้ทรงพลังยิ่งขึ้น เช่น การจัดการเอกสาร Excel หรือการปฏิบัติตามแนวทางแบรนด์ขององค์กร
  • ผู้ใช้สามารถสร้างสกิลแบบกำหนดเองและใช้งานได้ครอบคลุมใน Claude app, Claude Code, API และส่วนอื่น ๆ

วิธีการทำงานของ Skills

  • ระหว่างการทำงาน Claude จะสแกนสกิลทั้งหมดที่มีอยู่ เพื่อค้นหาสกิลที่เกี่ยวข้องมากที่สุดด้วยอัลกอริทึมของระบบ
  • หากพบสกิลที่ตรงกัน ระบบจะโหลดเฉพาะ ข้อมูลและไฟล์เท่าที่จำเป็นขั้นต่ำ เพื่อ รักษาความเร็วพร้อมรองรับงานเฉพาะทาง
  • คุณลักษณะของสกิล
    • การประกอบร่วมกันได้: ใช้หลายสกิลร่วมกันแบบซ้อนเป็นสแต็กได้ และ Claude จะปรับเลือกสกิลที่จำเป็นให้อัตโนมัติ
    • การพกพาได้: เขียนด้วยฟอร์แมตเดียวกัน จึงใช้ได้ทั่วทั้งผลิตภัณฑ์ตระกูล Claude
    • ประสิทธิภาพ: เรียกใช้เฉพาะความสามารถที่จำเป็นในเวลาที่ต้องใช้
    • ทรงพลัง: สามารถรวมโค้ดที่รันได้จริง (เช่น Python, Shell) ไว้ภายใน จึงใช้ประโยชน์จากประสิทธิภาพของการเขียนโปรแกรมแบบดั้งเดิมได้
  • สกิลมีแนวคิดเป็น ชุดข้อมูล onboarding แบบปรับแต่งเฉพาะ ที่แพ็กความรู้เฉพาะทางขององค์กรส่งต่อให้ Claude เพื่อให้ทำหน้าที่เสมือนผู้เชี่ยวชาญในโดเมนหนึ่ง ๆ

การผสานเข้ากับผลิตภัณฑ์ Claude

Claude Apps

  • ผู้ใช้ Pro, Max, Team และ Enterprise สามารถใช้ฟีเจอร์สกิลได้ทั้งหมด
  • มีตัวอย่างสกิลสำหรับงานทั่วไป เช่น การเขียนเอกสาร ให้ใช้งานมาโดยค่าเริ่มต้น และยังปรับแต่งเองได้
  • เมื่อผู้ใช้ป้อนงานที่ต้องการ Claude จะเรียกสกิลที่เหมาะสมโดยอัตโนมัติ และสามารถตรวจสอบการทำงานของสกิลได้ใน chain of thought
  • สกิล skill-creator ช่วยให้สร้างสกิลได้ง่ายผ่านการแนะนำแบบโต้ตอบ เช่น ถามเกี่ยวกับเวิร์กโฟลว์ สร้างโครงสร้างโฟลเดอร์ จัดรูปแบบ SKILL.md อัตโนมัติ และรวมทรัพยากรเป็นบันเดิล
  • สำหรับ Team/Enterprise ผู้ดูแลระบบต้องเปิดใช้ฟีเจอร์นี้ในระดับองค์กรก่อน
  • ใช้งานได้จากหน้าการตั้งค่า

Claude Developer Platform (API)

  • สามารถควบคุมการจัดการเวอร์ชันและการใช้งานของ custom skill ได้ผ่านคำขอ Messages API และ endpoint ใหม่ /v1/skills
  • การใช้สกิลต้องอาศัยฟีเจอร์เบตา Code Execution Tool ที่ให้สภาพแวดล้อมสำหรับรันโค้ดอย่างปลอดภัย
  • สกิลที่ Anthropic จัดให้สามารถใช้สร้างและแก้ไขเอกสารระดับมืออาชีพได้ เช่น Excel, PowerPoint, Word และ PDF
  • นักพัฒนาสามารถสร้าง custom skill ให้เหมาะกับเวิร์กโฟลว์เฉพาะ เพื่อขยายขอบเขตการใช้งาน Claude ได้อย่างอิสระ
  • Claude Console รองรับการสร้าง ดู และอัปเกรดเวอร์ชันของสกิลได้อย่างง่ายดาย
  • เรียนรู้เพิ่มเติมได้จากเอกสาร และ Anthropic Academy

กรณีการใช้งานของพาร์ตเนอร์

  • Box: แปลงคอนเทนต์ที่จัดเก็บไว้โดยอัตโนมัติให้เป็นเอกสาร PowerPoint·Excel·Word พร้อมรองรับ งานจัดทำเอกสารอัตโนมัติที่สอดคล้องกับมาตรฐานขององค์กร
  • Notion: เปลี่ยนคำถามที่ซับซ้อนให้กลายเป็นงานที่นำไปทำต่อได้ทันที พร้อม ลดภาระในการปรับแต่งพรอมป์ต์
  • Canva: ปรับแต่งเอเจนต์ผ่าน Skill เพื่อทำงานออกแบบอัตโนมัติและ สนับสนุนการผลิตคอนเทนต์คุณภาพสูงในระดับทีม
  • Rakuten: ใช้ Skill เป็นฐานสำหรับ ระบบอัตโนมัติด้านการเงินและบัญชี รวมการประมวลผลหลายสเปรดชีตและลดเวลาในการสร้างรายงานจาก 1 วัน → 1 ชั่วโมง

การเชื่อมต่อกับ Claude Code

  • Claude Code รองรับการติดตั้งสกิลเพื่อ ขยายความเชี่ยวชาญและเวิร์กโฟลว์ของทีม
    • ใช้ได้ทั้งผ่านปลั๊กอิน marketplace ของ anthropics/skills และการเพิ่มโฟลเดอร์เข้าไปที่ ~/.claude/skills โดยตรง
  • รองรับการแชร์สกิลและการทำงานร่วมกันระหว่างทีมผ่านการเชื่อมต่อกับระบบจัดการเวอร์ชัน
  • รองรับการพัฒนา custom agent ผ่าน Claude Agent SDK

เริ่มต้นใช้งาน


แผนในอนาคตและข้อควรระวัง

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

4 ความคิดเห็น

 
ahwjdekf 2025-10-21

มันฝรั่งหัวเดียวเอาไปอบ กินแบบต้ม กินแบบผัด กินแบบเคี่ยว แล้วก็บดกิน ...

 
ahwjdekf 2025-10-21

ทุกครั้งก็ตั้งชื่อหรูหราสารพัด สุดท้ายมันก็รสมันฝรั่งเหมือนเดิม

 
GN⁺ 2025-10-17
ความคิดเห็นจาก Hacker News
  • ต่อจากประสบการณ์ในสาย frontend development ที่ผ่านมา ดูเหมือนว่าในอนาคตรอบ ๆ ChatGPT, Claude และอื่น ๆ จะมีความสับสนเชิงแนวคิดอยู่มาก ตอนนี้มีทั้ง tools, functions, skills, agents, sub-agents, commands, apps และแนวคิดอีกสารพัดไหลบ่าเข้ามา แล้วบนความสับสนนี้ก็ยังมีเฟรมเวิร์กสาย ‘vibe’ เพิ่มขึ้นเรื่อย ๆ

    • อย่าลืมฟีเจอร์ที่เกี่ยวกับ MCP ด้วย ใช่แล้ว มันสับสนจริง แต่ข้างใต้ทั้งหมดนี้มีแนวคิดพื้นฐานที่เรียนรู้ได้ไม่ยาก ซึ่งต่อให้มีฟีเจอร์ใหม่เพิ่มเข้ามาก็เอาไปใส่ใน mental model เดิมได้ง่าย หรือจะมองข้ามไปแล้วสร้างเครื่องมือใช้เองเลยก็เป็นวิธีที่ดี mental model พื้นฐานนี้คือการเรียก LLM แบบวนลูป พร้อมเก็บประวัติว่าใน session ทำอะไรไปบ้างไว้เป็น history (= context) และเปิดให้เรียกใช้เครื่องมืออย่างการอ่านไฟล์ เขียนไฟล์ เรียก bash เป็นต้น โครงสร้างนี้บางทีก็เรียกว่า ‘agent loop’ และทำได้แม้กระทั่งด้วยโค้ด Python แค่ร้อยบรรทัด ถ้าเป็นนักพัฒนาที่สนใจ LLM ผมแนะนำว่าควรลองทำเองสักครั้ง เพราะมันเป็นประสบการณ์ที่เปิดตาจริง ๆ พอลองสร้าง agent แบบง่าย ๆ ด้วยตัวเองแล้ว ต่อให้มีเครื่องมือใหม่ออกมา คุณก็จะอธิบายการทำงานของมันในมุม implementation ได้ไม่ยาก เช่น Claude Skills ก็คือ 1) มีหลายไฟล์ที่เป็นคำสั่งสำหรับ LLM 2) ตอนเริ่มต้นจะไล่ดูเฉพาะ skills ที่ใช้ได้ แล้วรวบรวมคำอธิบายสั้น ๆ ใส่ไว้ใน context ของ LLM 3) บอก LLM ว่าควรใช้ skill อย่างไร และใน Claude จะใช้เครื่องมือ bash 4) เวลาใช้งาน skill จริง ก็ ‘call bash’ เพื่ออ่านไฟล์และรันงาน แน่นอนว่ารายละเอียดสำคัญอย่างการจัดการสิทธิ์ถูกละไว้ตรงนี้ แต่โครงสร้างหลักก็เป็นแบบนี้
    • ecosystem ตอนนี้เริ่มซับซ้อนเกินไปจนรู้สึกว่าอาจพังเพราะน้ำหนักตัวเองได้ ทุกระบบหรือทุกแพลตฟอร์มมีเหมือนงบความซับซ้อนรวมที่คนเราจะเก็บไว้ในหัวและใช้งานในชีวิตประจำวันได้ ซึ่งสำคัญมากว่าจะเอางบนี้ไปใช้กับอะไร ถ้าผู้ให้บริการแพลตฟอร์มเพิ่มความซับซ้อนใหม่เข้าไป มันก็เท่ากับไปหักจากคุณค่าที่สร้างต่อบนแพลตฟอร์มนั้นได้ ช่วงนี้ผู้ให้บริการหลายรายพยายามเพิ่มความแตกต่างด้วยการยัดความซับซ้อนเข้าไปเรื่อย ๆ สุดท้ายกลับสร้างกำแพงให้กลุ่มผู้ใช้ที่จำเป็นเข้ามาใช้งานได้ยากขึ้น และยังลดคุณค่าจริง ๆ ที่สามารถสร้างบนแพลตฟอร์มได้ด้วย ตอนนี้ก็ยังมีแนวคิดที่คล้ายกันและซ้ำกันจำนวนมากมากินงบความซับซ้อนใหม่ไป ทั้งที่ความสามารถที่เพิ่มจริง ๆ มีไม่มาก ภายในองค์กรอาจหลงคิดว่า “เพิ่มฟีเจอร์แบบนี้แล้วจะเรียนรู้ง่ายขึ้น” แต่ความจริงอาจแค่ดึงคนเข้ามาได้พอ ๆ กับที่ผลักคนออกไป ทำให้สุดท้ายไม่ได้คุ้มเท่าไร
    • เพราะเป็นเทคโนโลยีใหม่จริง ๆ ก็เลยยังมีพื้นที่ที่ไม่รู้เยอะมาก การเลือก cloud tools หรือ Python libraries ก็เคยเป็นปัญหาคล้ายกัน นี่เองจึงเป็นเหตุผลว่าทำไมไม่ใช่ทุกคนจะเป็น early adopter เพราะต้นทุนทางความคิดในการตามทุกอย่างนี้สูงมาก
    • ลูปแกนหลักนั้นเรียบง่าย แต่เฟรมเวิร์กขั้นต่ำที่เปิดให้ทดลองกับแนวคิดเชิงคำสั่งแบบนี้ได้อย่างอิสระมีค่ามาก ผมเคยเอา Beads มาต่อเข้ากับเฟรมเวิร์กได้ทันที ถ้าเวิร์กก็ใช้ต่อ ไม่เวิร์กก็ถอดออกได้ง่าย เลยชอบมาก และของอย่าง toolkami ก็น่าลองดูเช่นกัน
    • คำว่า ‘Metastasizing’ อธิบายปรากฏการณ์นี้ได้ดีมาก คือมันสะสมทับถมไม่รู้จบบนแนวคิดเดิม
  • ผมเพิ่งเขียนโพสต์เกี่ยวกับ skills ไปว่า “Claude Skills เจ๋งมาก และอาจเป็นการเปลี่ยนแปลงที่ใหญ่กว่า MCP เสียอีก” ลิงก์บทความ

    • คิดว่า Skills กับ AGENTS.md มีส่วนที่ทับซ้อนกันไหม? ใน VSCode เองก็เพิ่งเริ่มทดลองฟีเจอร์ nested AGENTS.md เช่นกัน อาจจะไม่เป็นทางการเท่า แต่แนวคิดน่าจะทับกันอยู่บ้าง ลิงก์อัปเดต VSCode
    • รู้สึกว่า skills ไม่ได้เป็นฟีเจอร์ที่จำเป็นต้องใส่ไว้ในสเปกแบบเข้มงวดนัก แต่ใกล้เคียงกับ design pattern หรือเทคนิค prompt engineering มากกว่า จริง ๆ แล้วทำใน MCP ได้อยู่แล้ว ผมใช้งานแบบ “ก่อนเริ่มอะไรก็ตาม ให้ค้นหาใน skills MCP แล้วอ่านคู่มือที่เกี่ยวข้องก่อน” มาตลอด
    • สงสัยว่าเราควรแยกช่วงเวลาที่ต้องใช้ skill ออกจากช่วงเวลาที่ควรทำเป็น project เมื่อไร
  • ผมมองว่าความสามารถของระบบพวกนี้ในการแก้ปัญหาได้ดี ส่วนใหญ่ขึ้นอยู่กับข้อความสรุปที่เขียนไว้ใน skill มนุษย์เมื่อมีประสบการณ์มากขึ้นจะรู้เองว่าเมื่อไรควรใช้ skill ไหน แต่ Claude เริ่มใหม่ทุกครั้งโดยอ่านคำอธิบายคร่าว ๆ แล้วก็ลุยเลย

    • ต่างจากมนุษย์ที่ผ่านประสบการณ์จนกลายเป็นผู้ใช้ skill ที่เชี่ยวชาญ LLM ทำได้แค่เลียนแบบเท่านั้น นี่จึงเป็นเหตุผลที่ Richard Sutton มองว่า LLM จะไม่พัฒนาไปเป็น AGI ตาม Sutton แล้ว AGI จะมาจาก reinforcement learning ส่วน LLM (โครงข่ายประสาท) ทำได้แค่เลียนแบบ LLM ไม่มีรากฐานทางการรับรู้เรื่องเป้าหมายและผลลัพธ์ของการกระทำ ดังนั้น “skill” ในโลก LLM จึงใกล้เคียงกับ reference manual มากกว่า ไม่เหมือน ‘ทักษะ’ ที่นำไปประยุกต์ซ้ำกับงาน/เครื่องมือ/การพัฒนาวิธีแก้ปัญหาได้ วิดีโอของ Sutton
    • สุดท้ายแล้วนี่คือปัญหาเรื่อง context window มนุษย์จำบริบทกว้างมาก ๆ ได้แม้จะไม่แม่นยำนัก และถ้าทุ่มเวลาเกิน 10,000 ชั่วโมงจนชำนาญในสาขาใดสาขาหนึ่ง ก็จะจำ “ทักษะ” ด้านนั้นได้ดี ส่วนอย่างอื่นก็ลืมไป LLM เก็บบริบทแบบเป็นโปรแกรมได้สม่ำเสมอและเรียกคืนได้เป๊ะ แต่การไล่ดูบริบททั้งหมดใช้เวลาและต้นทุนสูงเกินไป เพราะอย่างนั้น Skills (ให้แม่นคือ context insertion) จึงเป็นวิธีปรับลำดับความสำคัญของผลลัพธ์ด้วยมือ โหมดการคิดของ LLM เองก็เป็นการปรับบริบทใหม่เช่นกัน มันอาจไม่ใช่ “เริ่มใหม่ทุกครั้ง” เสมอไป ถ้ามองแบบนี้ การใช้เครื่องมือจะง่ายขึ้นมาก
    • ผมคิดว่าเหตุที่ LLM ต้องเริ่มต้นใหม่ทุกครั้งอาจมาจากโครงสร้าง multi-tenant infrastructure ก็ได้ เป็นเรื่องธรรมดาที่ OpenAI หรือ Anthropic อยาก reuse server/memory ระหว่างผู้ใช้หลายคน เลยสงสัยว่าจะทำการตั้งค่าแบบ “personal” single-tenant ได้ไหม ที่ LLM จำบทสนทนาทั้งหมดในอดีตได้
    • หัวใจของการสะสมความรู้/เครื่องมือให้ LLM อย่างสมบูรณ์คือทำอย่างไรให้ LLM รู้ตัวว่าอะไรควรใช้เมื่อไร ซึ่งตอนนี้แทบเป็นปัญหาที่แก้ไม่ได้เลย
    • ประสบการณ์ส่วนใหญ่เป็นข้อมูลทั่วไป ไม่ใช่เรื่องที่ผูกกับ project/บทสนทนา LLM ควรเริ่มจากความรู้แบบนี้ก่อน แล้วค่อยมีวิธีจำและดึงข้อมูลเฉพาะโปรเจกต์แยกต่างหาก มนุษย์ค้นข้อมูลได้เร็วมาก ส่วน LLM แม้จะช้ากว่า แต่ก็ยังอ้างอิงได้เกือบเรียลไทม์
  • มันค่อนข้างตลกที่ “skills” ของ Claude จะทำงานได้ดี ก็ต่อเมื่อมีนักพัฒนาที่เขียนและดูแลเอกสารอย่างเป็นระบบ ทั้งที่แค่งานเอกสารโค้ดจริง ๆ นักพัฒนาจำนวนมากก็ยังจัดการไม่ได้ เอกสารสำหรับ LLM น่าจะยิ่งยากขึ้นไปอีก สำหรับนักพัฒนาส่วนน้อยที่มีทั้งระบบไฟล์ที่เป็นระเบียบมากและยอมรับความเสี่ยงได้สูง มันอาจมีประโยชน์ แต่ถ้าเป็นคนแบบนั้นอยู่แล้ว จะให้ junior ทำงานพวกนี้ไปพร้อมการสอนงานอาจจะดีกว่าโยนให้ LLM ด้วยซ้ำ เพราะสุดท้ายก็ต้องตรวจผลงานทั้งหมดอยู่ดี และเพราะ context window ยังจำกัด จึงยากที่จะทำให้รู้สึกเหมือน “ซึมซับทักษะ” แบบมนุษย์ได้จริง ๆ ถ้าถึงขั้นเทรน LLM เฉพาะทาง ก็เท่ากับต้องผูกชีวิตไว้กับ LLM ตัวนั้นไปเลย หลายมุมเลยทำให้สมมติฐานแบบ “ทุกอย่างลงตัวอย่างสมบูรณ์ภายในองค์กร” นี้ดูน่าสนใจในเชิงขำ ๆ

    • การที่ LLM จะทำงานได้ดีต้องมีทั้งเอกสารสำหรับนักพัฒนาและ infrastructure สำหรับนักพัฒนาอาชีพหลากหลายแบบ ที่สรุปไว้ในบทความนี้ ซึ่งจริง ๆ แล้วเป็นแรงจูงใจที่ดีมาก กลับกันมันยังช่วยตอนต้องอธิบายให้ผู้บริหารเข้าใจด้วย
    • LLM ให้ผลตอบแทนกับนักพัฒนาที่เขียนเก่งมากกว่า จึงอาจเป็นเหตุผลหนึ่งที่นักพัฒนาหลายคนไม่ชอบ LLM
    • ผมก็เข้ามาหาคอมเมนต์แนวนี้เหมือนกัน แต่ดูเหมือนคุณเป็นคนเดียวที่ชี้ประเด็นนี้ “Skills” สุดท้ายก็คือเอกสารแบบละเอียด และในความเป็นจริงแทบไม่เคยมีใครเขียนเอกสารแบบนั้นให้แต่ละโปรเจกต์ ถ้า LLM skills จะทำให้ทุกคนเริ่มเขียนเอกสารละเอียดจริงก็คงดี แต่ผมว่าโอกาสเกิดขึ้นน้อยมาก
  • สงสัยว่า sub agents, MCP, skills พวกนี้จะทำงานร่วมกันอย่างไร เพราะรู้สึกว่ามีส่วนซ้ำกันเยอะพอสมควร การอัปเกรดสเปกเพื่อเพิ่มความสามารถให้ Claude เองก็ไม่เลว แต่ในทางปฏิบัติไม่ว่าจะใช้วิธีไหน ความสามารถระดับ agent ก็มักทำได้ใกล้เคียงกัน ตอนนี้ใน MCP ต้องใช้ JSON แต่ใน Claude แค่ใส่ Markdown ลงในไฟล์/โฟลเดอร์ได้เลย แถมยังรับ multimodal input ได้ด้วย ดูเหมือน UX จะดีขึ้นมาก

    • Claude Skills ดูเหมือน MCP prompts เป๊ะ ๆ สเปก MCP prompts เลยไม่เข้าใจว่าทำไมต้องสร้างแนวคิดใหม่ขึ้นมาอีก ใน chat UI มองในเชิงการตลาดก็พอเข้าใจ แต่ใน Claude Code ล่ะ? ไหนจะมี CLAUDE.md อีก ก็เลยยังงง ๆ
    • ผมมองว่าสามอย่างนี้เสริมกันได้ดีมาก MCP ทำหน้าที่ห่อ API ให้ LLM agent ใช้งานได้ Skills ใช้ส่งคำแนะนำเพิ่มเติมให้ agent เฉพาะตอนจำเป็นอย่างประหยัด context และบางคำสั่งก็ใช้เพื่ออธิบายวิธีใช้ MCP ได้ด้วย ส่วน Sub-agents ก็เป็นอีกแพตเทิร์นของการจัดการ context โดยให้ agent หลักส่งภารกิจไปยัง agent ย่อย แล้วถ้าจำเป็นก็ใช้ skills กับ MCP ร่วมกันเพื่อประหยัดโทเค็นได้
  • การมีฟีเจอร์แบบนี้เพิ่มเข้ามาถือว่าสดใหม่พอสมควร ในโปรเจกต์ของผม ผมแยกทำโฟลเดอร์ย่อย bin/claude เอาไว้เก็บสคริปต์ที่ Claude สร้างขึ้นอะไรทำนองนั้น แล้วก็เขียนตำแหน่งนี้ไว้ให้ชัดใน claude.md เพื่อช่วยตอนค้นหาเครื่องมือ ประสิทธิภาพตอนใช้งานจริงก็ค่อนข้างดี จริง ๆ สิ่งที่ต้องการมากกว่าคือ context management helper แบบ “เริ่ม claude ด้วยชุด MCP นี้ แล้วสลับไปอีกชุด MCP หนึ่ง” แต่ตอนนี้ผมยังจัดการเป็น subdirectory (profiles) แยกตามโปรเจกต์ แล้วค่อยเปิด claude ทีละครั้งจากตรงนั้น ในโครงสร้างแบบนี้ bin/claude มีบทบาทมาก เพราะ Claude จะรู้ทันทีว่าต้องวิเคราะห์ BigQuery dataset อย่างไร หรือไฟล์ยืนยันตัวตนอยู่ตรงไหน ผมไม่คิดมาก่อนว่าจะใช้ filesystem เพื่อจัดการโปรไฟล์ แต่สุดท้ายก็ลงเอยแบบนี้

    • พอพูดถึง “context management helper” ก็ทำให้นึกว่าจริง ๆ แล้วนั่นไม่ใช่ sub agents หรอกหรือ
  • ไม่เข้าใจว่าทำไมเดโมพวกนี้ถึงใช้ตัวอย่างที่ง่ายเกินไปอย่างพลิกรูปหมาหรือตัดรูปหมา ทั้งที่มีตัวอย่างการใช้ skills ที่น่าเชื่อถือกว่านี้เยอะมาก

    • ในหน้า developer มีตัวอย่างการจัดการ PDF ที่ดีกว่ามาก เอกสาร PDF skill จริง ๆ แล้วใน claude code ผมก็เคยใช้ไฟล์ Markdown ที่ใส่คู่มือการใช้งานแล้ว @tag เอาไว้ ตอนนี้พอทำเป็นอัตโนมัติได้ก็ยิ่งดี
    • ลองอ่านบทความในวิกิพีเดีย "The purpose of a system is what it does" ก็น่าคิดอยู่
    • ปัญหาสองอย่างที่ผมเจอเมื่อเช้าเกี่ยวกับการสร้างไฟล์ .xlsx ใน Claude ก็มีวิธีแก้อยู่ในเอกสารนี้ทั้งหมด ตัวอย่าง Excel skill
    • ตัวอย่างรูปหมาก็มีไว้เป็น reference ง่าย ๆ สำหรับสื่อสารกับผู้บริโภคในวงกว้างเท่านั้น
  • รู้สึกว่าการนำ Claude-skills มาใช้กำลังแพร่เร็วมาก วันอังคารผมเพิ่งอินกับโพสต์เปิดตัว "Superpowers" โพสต์แนะนำ แล้วก็เอาเครื่องมือที่ทำไว้ก่อนหน้านี้มาจัดระเบียบและแพ็กเป็น skills ให้ agent ใช้ได้ด้วย ยินดีรับฟีดแบ็กสำหรับโอเพนซอร์ส deli-gator

    • ความสามารถด้านการมอบหมายงานให้ agent น่าสนใจมาก บางครั้ง context จาก Linear issues ถูกยัดมาเยอะเกินไป เช่นผมอยากได้แค่คำอธิบาย issue กับคอมเมนต์ล่าสุด แต่ Linear MCP กลับดึงคอมเมนต์ทั้งหมดมาจน context สกปรก
  • เมื่อวันศุกร์ที่แล้วผมเผลอเปิดเผยการมีอยู่ของ Claude Skills ก่อนเวลาไปแล้ว แต่ตอนนี้ออกอย่างเป็นทางการแล้วก็โล่งใจ บล็อกโพสต์ที่เกี่ยวข้อง

    • เรื่องแบบ “เปิด Claude instance ใหม่แล้ว prompt ให้ zip ทั้งโฟลเดอร์ /mnt/skills ออกมา ก็ทำได้จริง” มันทั้งน่าสนใจและน่ากลัวที่การแฮ็กแบบนี้กลายเป็นเรื่องจริงขึ้นมาแล้ว ขอแค่อย่าให้มันเข้าถึงทั้ง filesystem หรือ binary ทั้งหมดได้เลย และถ้ามี SSH ด้วยนี่...
    • ช่วงนี้บล็อกของ Jesse คึกคักมากจริง ๆ ขอบคุณมาก
  • เดี๋ยวนี้มีทั้ง skills, plugins, marketplaces, connectors, add-ons และอะไรอีกมากมายจนตามไม่ทัน

    • ผมคิดว่าไม่จำเป็นต้องตามให้ทันก็ได้ คล้ายกับ “best practices” ใน prompt engineering สิ่งเหล่านี้เป็นเพียงทางแก้ชั่วคราวเพื่ออ้อมข้อจำกัดชั่วคราวเท่านั้น ไม่จำเป็นต้องลงทุนเวลาไปกับมันจนกว่าความสามารถที่ต้องการจริงจะถูกฝังมาในโมเดลพื้นฐานโดยตรง อีกไม่กี่เดือนของพวกนี้ก็น่าจะหายไปแล้ว ควรสนใจเฉพาะตอนที่ประสิทธิภาพเป็นเรื่องเร่งด่วนจริง ๆ
    • ต้องเข้าใจด้วยว่าทำไมบริษัทถึงทำแบบนี้ ในมุมบริษัทพวกเขาจำเป็นต้องมีอะไรออกมา เพราะโปรดักต์หลักยังทำตามคำสัญญาเรื่อง ‘ยุคแห่งการตกงานจำนวนมหาศาล’ ไม่ได้ สิ่งนี้เป็นสัญญาณส่งถึงนักลงทุนมากกว่าผู้ใช้ว่า “เราไม่ได้จ่ายเงินเดือนนักวิจัยแล้วไม่ทำอะไรนะ เรายังออกผลิตภัณฑ์หลากหลายแบบและหมุนข้อมูลอยู่” โดยเฉพาะเมื่อมีฐาน AB test ขนาดใหญ่รองรับ
    • ในมุมผู้ใช้ ยิ่งมีฟีเจอร์เฉพาะผู้ให้บริการมากเท่าไร ก็ยิ่งต้องเรียนรู้มากขึ้น ต้องตั้งค่ามากขึ้น และโดน vendor lock-in หนักขึ้น ซึ่งจริง ๆ แล้วเสียประโยชน์ แต่สำหรับผู้ให้บริการโมเดล การปล่อยฟีเจอร์พวกนี้ต่อเนื่องคือวิธีรักษาความแตกต่างของสินค้า เพราะถ้าไม่มีสิ่งเหล่านี้ สิ่งที่พวกเขาสร้างก็จะกลายเป็นแค่ commodity
    • ฟีเจอร์ใหม่คงถูกเพิ่มต่อไปจนกว่าทีมจะรู้สึกคึกคักพอ
    • จริง ๆ แล้วผมว่าไม่ได้ซับซ้อนขนาดนั้น Plugins ก็รวม commands, MCPs, Subagents และตอนนี้รวม Skills เข้าไปด้วย ส่วน marketplace ก็คือพื้นที่รวม plugins พวกนี้ไว้ด้วยกัน