ความจริงคือ... ต่อให้รู้เรื่องนั้น ก็ยังมีอีกหลายอย่างที่ไปไกลกว่านั้นอยู่ดี..

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

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

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

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

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

แต่สุดท้ายก็ดูเหมือนว่าจะได้ทำสิ่งที่ดีไปแล้วนะ

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

แม้ว่า Livewire จะสนุกจริง แต่ถ้า UI ซับซ้อนขึ้นมาอีกนิดเดียวก็จะกลายเป็นนรก ทันทีที่ถึงจุดนั้น Phoenix ก็จะเสียข้อดีไปอย่างมาก ยิ่งวงจรยาวขึ้นก็ยิ่งลำบาก ดังนั้นผมเลยไม่ค่อยแนะนำเท่าไรครับ

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

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

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

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

MSA, OneDrive, Copilot อะไรพวกนี้... อยากให้เลิกยัดเยียดใส่ปากผู้ใช้แบบบังคับเสียที

หวังว่าจะไม่เข้าใจผิดนะครับ/คะ ผม/ฉันไม่ได้หมายความว่ากำลังพูดจาไร้สาระเกี่ยวกับ Hacker News

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

Claude Skills น่าทึ่งมาก อาจเป็นนวัตกรรมที่ยิ่งใหญ่กว่า MCP เสียอีก
GN+ เพิ่งสรุปไว้เมื่อกี้นี้ ลองดูประกอบกันได้เลย!

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

ดูคล้ายกับ Copilot Spaces และให้ความรู้สึกว่าเป็นระบบอัตโนมัติมากกว่าด้วยครับ

การจัดแนวแบบคลั่งไคล้ (alignment in dogmatism)

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