Agent Skills

 (addyosmani.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Agent Skills คือสแคฟโฟลดิ้งที่บังคับให้เอเจนต์เขียนโค้ด AI ต้องทำตาม กระบวนการวิศวกรรมระดับซีเนียร์ ผ่านเวิร์กโฟลว์ เพื่อไม่ให้ข้ามขั้นตอนอย่างสเปก การทดสอบ PR ที่รีวิวได้ หรือการตรวจสอบขอบเขตความเชื่อถือ
  • สกิล (skill) คือไฟล์ Markdown ที่มี frontmatter โดยมีลักษณะใกล้เคียง เวิร์กโฟลว์ มากกว่าเอกสารอ้างอิง เพราะมีลำดับขั้นตอน หลักฐานที่ต้องมีในจุดตรวจ และเกณฑ์การจบงาน
  • สกิล 20 รายการในรีโปประกอบด้วย 6 ช่วงวงจรชีวิตคือ Define, Plan, Build, Verify, Review, Ship และ 7 slash command ได้แก่ /spec, /plan, /build, /test, /review, /ship, /code-simplify
  • หลักการสำคัญคือ ให้ความสำคัญกับกระบวนการมากกว่าร้อยแก้ว, ตารางต้านการหาเหตุผลเข้าข้างตัวเอง, การยึดการตรวจสอบเป็นเกณฑ์จบงาน, การเปิดเผยแบบค่อยเป็นค่อยไป และวินัยด้านขอบเขต โดย using-agent-skills จะเปิดใช้เฉพาะสกิลที่เหมาะกับงานนั้น
  • ใช้งานได้ผ่านการติดตั้งใน Claude Code marketplace, การใส่ไฟล์ลงใน .cursor/rules/ ของ Cursor, Gemini CLI, Codex, Aider, Windsurf, OpenCode และเครื่องมืออื่น ๆ ที่อ่าน Markdown ได้ พร้อมเผยแพร่ภายใต้ไลเซนส์ MIT

วัตถุประสงค์และโจทย์ปัญหา

  • Agent Skills คือสแคฟโฟลดิ้งสำหรับบังคับให้เอเจนต์เขียนโค้ด AI ทำตาม กระบวนการวิศวกรรมระดับซีเนียร์ ที่ปกติจะถูกข้ามไป โดยใช้เวิร์กโฟลว์เป็นตัวบังคับ
  • เมื่อถูกขอให้สร้างฟีเจอร์ เอเจนต์เขียนโค้ด AI มักจะเดินไปตามเส้นทางที่สั้นที่สุดเพื่อให้การพัฒนาเสร็จ และโดยปกติจะไม่ทำขั้นตอนอย่างการเขียนสเปก การเขียนเทสต์ก่อน การตรวจสอบขอบเขตความเชื่อถือ หรือการจัด PR ให้รีวิวได้
  • งานของวิศวกรระดับซีเนียร์มีหลายส่วนที่ไม่ปรากฏอยู่ใน diff
    • เปิดเผยสมมติฐาน
    • เขียนสเปก
    • แบ่งงานออกเป็นหน่วยที่รีวิวได้
    • เลือกดีไซน์ที่น่าเบื่อแต่ปลอดภัย
    • ทิ้งหลักฐานว่าผลลัพธ์นั้นถูกต้อง
    • จำกัดขนาดการเปลี่ยนแปลงให้อยู่ในระดับที่มนุษย์รีวิวได้จริง
  • เหตุผลที่เอเจนต์ข้ามขั้นตอนเหล่านี้ก็คล้ายกับวิศวกรจูเนียร์ คือสัญญาณรางวัลถูกปรับให้เข้ากับ “งานเสร็จ” ไม่ใช่ “งานเสร็จพร้อมมีเอกสารสเปกด้วย”
  • รีโป Agent Skills มี stars เกิน 26K แล้ว และไม่ได้หยุดแค่ README แต่ยังอธิบายเหตุผลของการเลือกดีไซน์ การแมปกับ SDLC มาตรฐานและแนวปฏิบัติวิศวกรรมสาธารณะของ Google ตลอดจนแพตเทิร์นที่หยิบไปใช้ได้แม้ไม่ติดตั้ง

ความหมายที่แท้จริงของสกิล

  • สกิล (skill) คือไฟล์ Markdown ที่มี frontmatter ซึ่งจะถูกฉีดเข้าไปในคอนเท็กซ์ของเอเจนต์ตามสถานการณ์ โดยมีรูปแบบอยู่กึ่งกลางระหว่างชิ้นส่วน system prompt กับ runbook
  • สกิลไม่ใช่เอกสารอ้างอิง และไม่ใช่คลังความรู้ประเภท “ทุกอย่างที่ต้องรู้เกี่ยวกับการทดสอบ”
  • สกิลที่มีประโยชน์คือ เวิร์กโฟลว์ ที่เอเจนต์ต้องทำตาม
    • มีลำดับขั้นตอน
    • สร้างหลักฐานที่จุดตรวจ
    • จบด้วยเกณฑ์การสิ้นสุดที่ชัดเจน
  • ถ้าใส่บทความ 2,000 คำว่าด้วย best practice ด้านการทดสอบลงในคอนเท็กซ์ เอเจนต์อาจสร้างประโยคที่ดูน่าเชื่อถือ แต่ข้ามการทดสอบจริงไปได้
  • แต่ถ้าใส่เวิร์กโฟลว์ที่กำหนดให้เขียนเทสต์ที่ต้องล้มเหลวก่อน จากนั้นรันเพื่อยืนยันว่าล้มเหลว เขียน implementation ขั้นต่ำที่ทำให้ผ่าน ยืนยันว่าผ่าน แล้วค่อยรีแฟกเตอร์ เอเจนต์ก็จะมีงานที่ต้องทำจริง และมนุษย์ก็ตรวจสอบได้
  • ความต่างหลักคือ ให้ความสำคัญกับกระบวนการมากกว่าร้อยแก้ว, ให้เวิร์กโฟลว์มากกว่าเอกสารอ้างอิง และให้ขั้นตอนที่มีเกณฑ์จบงานมากกว่าบทความที่ไม่มีเกณฑ์จบงาน
  • สาเหตุที่รีโป “AI rules” จำนวนมากไม่ค่อยได้ผลจริง ก็เพราะกฎเหล่านั้นยังเป็นแค่บทความ ไม่ใช่เวิร์กโฟลว์

โครงสร้าง SDLC และ slash command

  • สกิล 20 รายการในรีโปถูกจัดเป็น 6 ช่วงวงจรชีวิต และมี 7 slash command วางอยู่ด้านบน

  • ขั้นตอนและคำสั่ง

    • /spec: ขั้น Define สำหรับตัดสินใจว่าจะสร้างอะไร
    • /plan: ขั้น Plan สำหรับแตกงานออกเป็นส่วนย่อย
    • /build: ขั้น Build สำหรับลงมือทำเป็น vertical slice
    • /test: ขั้น Verify สำหรับพิสูจน์ว่ามันทำงาน
    • /review: ขั้น Review สำหรับจับปัญหาที่หลุดรอดไป
    • /ship: ขั้น Ship สำหรับส่งมอบให้ผู้ใช้อย่างปลอดภัย
    • /code-simplify: คำสั่งทำให้เรียบง่ายที่ใช้ครอบคลุมทั้งโฟลว์
    • โครงสร้างนี้เป็นโฟลว์แบบเดียวกับ SDLC ขององค์กรวิศวกรรมที่ทำงานได้จริง ต่างกันแค่ศัพท์ที่ใช้ในแต่ละองค์กร
    • ที่ Google จะอยู่ในรูป flow แบบ design doc → review → implementation → readability review → launch checklist ส่วนที่ Amazon จะปรากฏในรูปแบบอย่าง working-backwards memo และ bar raiser
    • ปัญหาใหม่ของเอเจนต์เขียนโค้ด AI คือเอเจนต์ส่วนใหญ่ข้ามขั้นตอนเหล่านี้ไปเกือบทั้งหมดเป็นค่าเริ่มต้น
    • เมื่อขอฟีเจอร์ มักได้กลับมาแค่ implementation โดยไม่มีสเปก แผน เทสต์ การรีวิว หรือเช็กลิสต์ก่อนปล่อย
    • สกิลทำให้เอเจนต์ต้องผ่านขั้นตอนที่วิศวกรซีเนียร์บังคับใช้กับตัวเอง และการปล่อยโค้ดโดยไม่มีขั้นตอนเหล่านี้มักนำไปสู่ incident
    • ฟีเจอร์ที่ซับซ้อนอาจเปิดใช้สกิล 11 รายการต่อเนื่องกัน ขณะที่การแก้บั๊กเล็ก ๆ อาจใช้เพียง 3 รายการ
    • ตัว router using-agent-skills จะตัดสินว่าสกิลใดเหมาะกับงานปัจจุบัน และเวิร์กโฟลว์จะขยายตามขอบเขตจริง ไม่ใช่ขอบเขตที่สมมติไว้

หลักการที่ทำให้มันทำงานได้

  • 1. ให้ความสำคัญกับกระบวนการมากกว่าร้อยแก้ว

    • เวิร์กโฟลว์คือสิ่งที่เอเจนต์ลงมือทำได้ แต่บทความทำไม่ได้
    • หลักการเดียวกันนี้ใช้ได้กับทีมมนุษย์ด้วย
    • ถ้าคู่มือทีมยาว 200 หน้า มันมักไม่ถูกอ่านในสถานการณ์กดดัน แต่ถ้าเป็นเวิร์กโฟลว์สั้น ๆ ที่มีจุดตรวจ ก็มีโอกาสถูกทำตามจริงมากกว่า

  • 2. ตารางต้านการหาเหตุผลเข้าข้างตัวเอง

    • หนึ่งในการเลือกดีไซน์ที่โดดเด่นที่สุดของ Agent Skills และเป็นสิ่งที่ทีมอื่นควรหยิบไปใช้ คือ ตารางต้านการหาเหตุผลเข้าข้างตัวเอง (anti-rationalization tables)
    • ในแต่ละสกิลจะมีข้ออ้างที่เอเจนต์หรือวิศวกรที่อ่อนล้าอาจใช้เพื่อข้ามเวิร์กโฟลว์ พร้อมคำโต้แย้งที่เขียนเตรียมไว้ล่วงหน้า
    • ตัวอย่างเช่น
      • “งานนี้ง่ายเกินกว่าจะต้องมีสเปก” → เกณฑ์การยอมรับยังคงจำเป็น 5 บรรทัดโอเค แต่ 0 บรรทัดไม่โอเค
      • “เดี๋ยวค่อยเขียนเทสต์ทีหลัง” → ปัญหาหลักอยู่ที่คำว่า “ทีหลัง” ไม่มีคำว่าเดี๋ยวค่อย ต้องเขียนเทสต์ที่ล้มเหลวก่อน
      • “เทสต์ผ่านแล้ว งั้น deploy ได้เลย” → เทสต์ที่ผ่านคือหลักฐาน ไม่ใช่ข้อพิสูจน์ ต้องเช็กด้วยว่าได้ตรวจ runtime แล้วหรือยัง ยืนยันพฤติกรรมที่ผู้ใช้เห็นหรือยัง และมีคนอ่าน diff แล้วหรือยัง
    • LLM นั้นเก่งในการหาเหตุผลเข้าข้างตัวเอง และสามารถเขียนย่อหน้าที่ดูน่าเชื่อถือเพื่ออธิบายได้ว่า งานบางอย่างไม่ต้องมีสเปก หรือการเปลี่ยนบางอย่างควรถูก merge ได้โดยไม่ต้อง review
    • ตารางต้านการหาเหตุผลเข้าข้างตัวเองคือ คำโต้แย้งที่เขียนไว้ล่วงหน้า ต่อคำโกหกที่เอเจนต์ยังไม่ได้พูดออกมาด้วยซ้ำ
    • แพตเทิร์นนี้ใช้ได้กับทีมมนุษย์เช่นกัน
    • คุณภาพงานวิศวกรรมที่ตกลงมักไม่ได้เกิดจากมีใครตั้งใจทำสิ่งไม่ดี แต่เกิดจากการยอมรับคำอธิบายที่ฟังขึ้นสำหรับการข้ามขั้นตอนที่ไม่อยากทำ

  • 3. การตรวจสอบเป็นสิ่งที่ต่อรองไม่ได้

    • ทุกสกิลจบลงด้วยหลักฐานที่จับต้องได้
    • เทสต์ผ่าน, ผลลัพธ์ build ที่สะอาด, runtime trace ที่แสดงพฤติกรรมตามคาด, การอนุมัติจาก reviewer ล้วนเป็นเกณฑ์จบงาน
    • แค่ “ดูเหมือนใช้ได้” ยังไม่เพียงพอ
    • นี่เป็นหลักการเดียวกับที่ harness ของ Anthropic ใช้ในการกู้คืนจากความล้มเหลว, การแยก planner/worker/judge ของ Cursor ที่ช่วยจับบั๊กได้จริง และเหตุผลที่ long-running agent ฟื้นตัวกลับมาได้
    • เพราะเอเจนต์เป็นเครื่องกำเนิด จึงต้องมีสัญญาณแยกต่างหากไว้ตัดสินว่างานเสร็จหรือยัง และสกิลก็นำสัญญาณนั้นไปฝังไว้ในแต่ละเวิร์กโฟลว์

  • 4. การเปิดเผยแบบค่อยเป็นค่อยไป

    • ตอนเริ่มเซสชัน จะไม่ใส่สกิลทั้ง 20 รายการลงในคอนเท็กซ์พร้อมกัน
    • จะเปิดใช้เฉพาะสกิลที่จำเป็นตามขั้นตอนปัจจุบัน
    • เมตาสกิลขนาดเล็ก using-agent-skills ทำหน้าที่เป็น router เพื่อตัดสินว่าสกิลไหนเหมาะกับงานที่กำลังทำ
    • นี่คือการนำบทเรียนจาก harness engineering มาใช้ในระดับสกิล
    • ทุก token ที่โหลดเข้าคอนเท็กซ์ย่อมไปลดประสิทธิภาพที่ไหนสักแห่ง ดังนั้นควรโหลดเฉพาะสิ่งที่เกี่ยวข้องและปล่อยที่เหลือไว้บนดิสก์
    • การเปิดเผยแบบค่อยเป็นค่อยไป คือวิธีใส่คลังสกิล 20 รายการลงในช่อง 5K-token โดยไม่ทำให้คอนเท็กซ์ทั้งหมดปนเปื้อน

  • 5. วินัยด้านขอบเขต

    • เมตาสกิลจะเข้ารหัสหลักการที่ต่อรองไม่ได้ว่า “แตะเฉพาะสิ่งที่ถูกขอเท่านั้น”
    • ไม่ควรรีแฟกเตอร์ระบบข้างเคียง ไม่ควรลบโค้ดที่ยังไม่เข้าใจทั้งหมด และไม่ควรเห็น TODO แล้วตัดสินใจเขียนไฟล์ใหม่ทั้งไฟล์
    • เอเจนต์อาจเริ่มจากแก้บั๊กเพียงจุดเดียว แต่กลับพยายาม modernize ไฟล์ที่ไม่เกี่ยวข้องอีก 3 ไฟล์
    • วินัยด้านขอบเขต เป็นปัจจัยชี้ขาดที่สุดว่า PR ของเอเจนต์จะ merge ได้ หรือควรถูก revert
    • สิ่งนี้สอดคล้องกับแนวปฏิบัติ code review ของ Google ที่ reviewer สามารถบล็อก PR ได้หาก PR เดียวทำมากกว่าหนึ่งอย่าง

ความเชื่อมโยงกับแนวปฏิบัติทางวิศวกรรมของ Google

  • Agent Skills สะท้อนแนวปฏิบัติจำนวนมากจาก Software Engineering at Google และวัฒนธรรมวิศวกรรมสาธารณะของ Google
  • หลายองค์ประกอบที่ทำให้ซอฟต์แวร์ในระดับ Google ทำงานได้ถูกเอกสารไว้สาธารณะอยู่แล้ว และนั่นก็คือส่วนที่เอเจนต์มักข้ามมากที่สุด

  • การแมประหว่างสกิลกับแนวปฏิบัติ

    • api-and-interface-design: สะท้อน Hyrum’s Law เพราะทุกพฤติกรรมที่สังเกตได้ของ API สุดท้ายจะมีคนพึ่งพา จึงต้องออกแบบโดยคำนึงถึงจุดนี้
    • test-driven-development: สะท้อน test pyramid ~80/15/5 และ Beyoncé Rule ซึ่งมีหลักว่า “ถ้าคุณชอบมัน คุณควรใส่เทสต์ให้มัน” และบั๊กถูกจับด้วยเทสต์ ไม่ใช่การเปลี่ยนโครงสร้างพื้นฐาน
    • DAMP over DRY ในการทดสอบ: ปรัชญาการทดสอบของ Google มองว่าโค้ดเทสต์ควรอ่านเหมือนสเปก แม้ต้องยอมให้ซ้ำบ้าง การทำเทสต์ให้ abstract มากเกินไปคือ anti-pattern ที่รู้จักกันดี
    • code-review-and-quality: สะท้อนขนาด ~100-line PR และป้ายความรุนแรงแบบ Critical / Nit / Optional / FYI โดย PR ขนาดใหญ่มักไม่ได้รับการรีวิวจริงและมีแนวโน้มถูกอนุมัติแบบประทับตรายาง
    • code-simplification: สะท้อน Chesterton’s Fence คือไม่ควรลบสิ่งใดออกจนกว่าจะเข้าใจว่ามันถูกวางไว้เพราะอะไร
    • git-workflow-and-versioning: สะท้อน trunk-based development และ atomic commits
    • ci-cd-and-automation: สะท้อน Shift Left และ feature flags คือควรจับปัญหาให้เร็วที่สุด และแยกการ deploy ออกจากการ release
    • deprecation-and-migration: สะท้อนแนวคิด code-as-liability เพราะทุกบรรทัดที่คงอยู่คือสิ่งที่ต้องดูแลไปตลอด จึงควรเลือกพื้นผิวที่เล็กกว่า
    • แนวคิดเหล่านี้ไม่ใช่เรื่องใหม่ แต่ไม่ได้ติดตั้งมาเป็นค่าเริ่มต้นในเอเจนต์
    • ต่อให้ frontier model เคยอ่านคำว่า “Hyrum’s Law” จากข้อมูลฝึก ก็ไม่ได้หมายความว่ามันจะนำไปใช้โดยอัตโนมัติขณะออกแบบ API ตอนตีสาม
    • สกิลทำให้เอเจนต์นำแนวปฏิบัติเหล่านี้ไปใช้ระหว่างการทำงานจริง

วิธีใช้งานจริง

  • วิธีที่ 1: ติดตั้งผ่าน marketplace

    • ถ้าใช้ Claude Code สามารถติดตั้งด้วยคำสั่งต่อไปนี้
    /plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
    • เมื่อติดตั้งแล้วจะสามารถใช้ slash command /spec, /plan, /build, /test, /review, /ship, /code-simplify ได้
    • เอเจนต์จะเปิดใช้สกิลที่เกี่ยวข้องโดยอัตโนมัติตามคอนเท็กซ์
    • สำหรับผู้ใช้ส่วนใหญ่ แนะนำให้เริ่มต้นด้วยวิธีนี้

  • วิธีที่ 2: ใส่ Markdown ลงในเครื่องมือที่ต้องการ

    • สกิลเป็นไฟล์ Markdown ปกติที่มี frontmatter
    • ผู้ใช้ Cursor สามารถใส่ไว้ใน .cursor/rules/ ได้
    • Gemini CLI มี path สำหรับติดตั้งของตัวเอง
    • Codex, Aider, Windsurf, OpenCode และเครื่องมืออื่นที่รับ system prompt ได้ก็สามารถอ่านได้
    • สิ่งสำคัญไม่ใช่ตัวเครื่องมือ แต่คือเวิร์กโฟลว์ที่อยู่ข้างใต้

  • วิธีที่ 3: อ่านเหมือนเอกสารสเปก

    • ต่อให้ไม่ติดตั้งอะไรเลย สกิลก็ยังเป็นคำอธิบายที่ถูกบันทึกไว้ว่า จะทำวิศวกรรมที่ดีร่วมกับเอเจนต์ AI อย่างไร
    • คุณสามารถอ่าน code-review-and-quality.md แล้วนำเฟรมเวิร์ก 5 แกนไปใช้กับกระบวนการรีวิวของทีมได้
    • อ่าน test-driven-development.md แล้วใช้กับข้อถกเถียงประเภท “ควรเขียนเทสต์ก่อนหรือไม่”
    • อ่านเมตาสกิลแล้วหยิบหลักการ 5 ข้อที่ต่อรองไม่ได้ไปใส่ใน AGENTS.md ของตัวเองได้
    • จุดเริ่มต้นอาจเป็นการเลือกสกิล 4–5 รายการที่ใกล้กับปัญหาที่เจ็บที่สุดในตอนนี้ กำหนดเวิร์กโฟลว์ที่อยากบังคับใช้ แล้วติดตั้งหรือสร้าง runtime ขึ้นมาเองเพื่อบังคับใช้มัน

แพตเทิร์นที่หยิบไปใช้ได้แม้ไม่ติดตั้ง

  • ทำให้การต้านการหาเหตุผลเข้าข้างตัวเองเป็นแนวปฏิบัติของทีม

    • ทีมควรเขียนคำโกหกที่พวกเขามักพูดกับตัวเองลงมา
    • ตัวอย่างเช่น “เดี๋ยวค่อยแก้เทสต์หลังปล่อย”, “การเปลี่ยนนี้เล็กเกินกว่าจะต้องมี design doc”, “มี monitoring อยู่แล้วจึงไม่เป็นไร”
    • ถ้าใส่คำโต้แย้งไว้กับแต่ละประโยค แล้วนำไปไว้ใน AGENTS.md หรือวิกิวิศวกรรม ก็จะช่วยลดการถกเถียงและหยุดทางลัดตอนบ่ายวันศุกร์ที่ทุกคนล้าได้

  • เขียนเอกสารภายในให้เป็นกระบวนการมากกว่าร้อยแก้ว

    • ถ้าคุณกำลังเขียนเอกสาร 2,000 คำเรื่อง “เราเข้าหา X อย่างไร” นั่นคือการเขียนเอกสารอ้างอิง
    • หากเปลี่ยนเป็นเวิร์กโฟลว์ที่มีจุดตรวจ เอกสารอาจเหลือ 400 คำและมีโอกาสถูกทำตามจริงมากขึ้น
    • หลักการนี้ใช้ได้กับ onboarding guide, runbook และ agent skills ทั้งหมด

  • ใช้การตรวจสอบเป็นเกณฑ์จบงานที่แข็งแรง

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

  • ใช้การเปิดเผยแบบค่อยเป็นค่อยไปกับทุกชุดกฎ

    • อย่าเขียนคู่มือ 50 หน้า แต่ควรเขียน router เล็ก ๆ ที่ส่งผู้ใช้ไปยังบทสั้น ๆ ตามสถานการณ์
    • สิ่งนี้ใช้ได้กับ AGENTS.md, runbook, playbook รับมือ incident และเอกสารทุกอย่างที่ต้องอ่านภายใต้ความกดดัน

  • 5 หลักการที่ต่อรองไม่ได้สำหรับใส่ใน AGENTS.md

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

ตำแหน่งของมันภายใน harness

  • มองในภาพใหญ่ สกิลเป็นหนึ่งในเลเยอร์ของ agent harness engineering
  • harness ครอบคลุมทั้งตัวโมเดลและทุกสิ่งที่สร้างล้อมรอบมัน ส่วนสกิลคือชิ้นส่วนเวิร์กโฟลว์ที่ใช้ซ้ำได้และถูกเปิดเผยเข้าสู่ system prompt แบบค่อยเป็นค่อยไป
  • สกิลวางอยู่ข้าง ๆ AGENTS.md, hooks, tools และ session log
    • AGENTS.md: ทำหน้าที่เป็นชุดกฎที่อัปเดตต่อเนื่อง
    • hooks: เลเยอร์บังคับใช้แบบ deterministic
    • tools: การกระทำที่เอเจนต์สามารถทำได้
    • session log: หน่วยความจำที่คงอยู่
    • skills: รับผิดชอบกระบวนการวิศวกรรมระดับซีเนียร์
  • สกิลสำคัญกับ long-running agents มากกว่าเอเจนต์แบบแชต
  • การทำงานยาวนานจะขยายผลของทุกทางลัด
    • ในเซสชัน 10 นาที เอเจนต์ที่ข้ามการทดสอบอาจสร้างบั๊กหนึ่งตัว
    • แต่ในเซสชัน 30 ชั่วโมง เอเจนต์ที่ข้ามการทดสอบอาจทิ้งงานขุดโบราณคดีเพื่อดีบักในตอนท้าย โดยไม่มีใครจำเจตนาเดิมได้แล้ว
  • ยิ่งรันนานเท่าไร สแคฟโฟลดิ้งทางวิศวกรรมระดับซีเนียร์ก็ยิ่งต้องเป็นการบังคับใช้ ไม่ใช่เพียงคำแนะนำ
  • ความสามารถในการพกพาของรูปแบบสกิลก็สำคัญเช่นกัน
  • ไฟล์ SKILL.md เดียวกันสามารถใช้ได้ทั้งกับ Claude Code, Cursor ที่ใช้ rules, Gemini CLI, Codex และ harness อื่นที่รับเนื้อหา system prompt ได้
  • เมื่อเขียนเวิร์กโฟลว์หนึ่งครั้ง runtime ก็สามารถบังคับใช้มันได้ และนี่คือข้อดีของรูปแบบ Markdown-with-frontmatter เมื่อเทียบกับ bespoke prompt engineering

บทสรุป

  • เอเจนต์เขียนโค้ด AI ทำงานเหมือนวิศวกรจูเนียร์ที่มีความสามารถสูงมาก แต่ไม่มีสัญชาตญาณสำหรับงานที่ไม่ปรากฏอยู่ใน diff
  • งานวิศวกรรมระดับซีเนียร์อย่างการเปิดเผยสมมติฐาน การควบคุมขนาดการเปลี่ยนแปลง การเขียนสเปก การทิ้งหลักฐาน และการปฏิเสธการ merge การเปลี่ยนที่รีวิวไม่ได้ มีโอกาสสูงที่เอเจนต์จะข้าม หากไม่ทำให้มันข้ามไม่ได้
  • งานที่สำคัญขึ้นเรื่อย ๆ คือการเข้ารหัสวินัยเหล่านี้ให้อยู่ในรูปที่เอเจนต์ไม่สามารถใช้คำพูดหาทางเลี่ยงเองได้
  • สกิลคือหนึ่งในรูปแบบดังกล่าว และแกนสำคัญก็คือตารางต้านการหาเหตุผลเข้าข้างตัวเอง การเปิดเผยแบบค่อยเป็นค่อยไป การให้ความสำคัญกับกระบวนการมากกว่าร้อยแก้ว การตรวจสอบในฐานะเกณฑ์จบงาน และโครงสร้างที่ทำให้แนวปฏิบัติของ Google ซึ่งใช้งานได้จริง สามารถพกพาไปใช้ที่อื่นได้
  • รีโป Agent Skills เผยแพร่ภายใต้ไลเซนส์ MIT และมุมมองสแคฟโฟลดิ้งที่กว้างกว่านั้นจะต่อเนื่องไปใน Agent Harness Engineering และ Long-running Agents

บทความที่เกี่ยวข้อง

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

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • ใกล้เคียงกับ ยาครอบจักรวาลหลอกลวง มาก อ่านแล้วก็มีประโยชน์และดูน่าเชื่อถือดี แต่สุดท้ายก็ยังเป็นยาครอบจักรวาลหลอกลวงอยู่ดี
    เพราะโมเดลแบบตู้สล็อตสามารถพลาด ข้อกำหนดบังคับ ที่เขียนไว้ใน AGENTS.md, memory.md และสกิลแบบ Markdown อีกหลายสิบไฟล์ได้ทุกเมื่อ ซึ่งแทบจะเป็นสิ่งที่รับประกันได้เลย
    แนวทางแบบ harness นี้ทำเหมือนกับว่า LLM ปฏิบัติตามกฎได้อย่างเคร่งครัดและสมบูรณ์แบบ และปัญหามีแค่ว่าเราเขียนกฎให้ชัดและมากพอหรือยังเท่านั้น ซึ่งเป็นความเข้าใจผิดระดับพื้นฐานเกี่ยวกับวิธีทำงานของ LLM
    สุดท้ายแล้ว สิ่งที่เชื่อถือไม่ได้ก็คือเชื่อถือไม่ได้ และตัวเลือกที่เชื่อถือได้กว่าเมื่อเทียบกันก็คือ การตรวจทานและกำกับดูแลโดยมนุษย์ เท่านั้น และถ้าเป็นไปได้ก็ควรทำติดกันสองรอบ
    ที่เหลือทั้งหมดก็เป็นยาครอบจักรวาลหลอกลวง และพอไปถึงจุดนั้นก็จะตระหนักได้ว่าคำสัญญาเรื่องเพิ่มผลิตภาพก็เป็นแบบเดียวกัน เพราะการอ่านโค้ดและสร้างโมเดลในหัวนั้นยากกว่าการแปลงสิ่งที่มีโมเดลในหัวอยู่แล้วออกมาเป็นโค้ดมาก

    • คำว่ายาครอบจักรวาลหลอกลวงแรงไปหน่อย ยาแบบนั้นไม่มีทางได้ผลเลย แต่สิ่งที่มี LLM อยู่ด้วยนั้น แม้จะเป็นเชิงความน่าจะเป็น ก็ยังทำงานได้ด้วยโอกาสที่ค่อนข้างสูง
      การอ่านโค้ดก็ขึ้นกับว่าเป็นโค้ดแบบไหน แต่เหมือนทักษะอื่น ๆ คือถ้าฝึกก็จะง่ายขึ้น เป็นเรื่องปกติมานานแล้วในสถานการณ์ที่ต้องอ่านโค้ดมากกว่าเขียน เช่น เวลาต้องดูแล codebase ใหญ่และซับซ้อนที่มีมานาน
      มันจะง่ายขึ้นอีกเมื่อมี โมเดลในหัว เกี่ยวกับโค้ดนั้นอยู่แล้วจากเอกสาร ประสบการณ์ที่ผ่านมา หรือการถามเพื่อนร่วมงาน
      เรื่องนี้ทำได้กับเอเจนต์เหมือนกัน ปกติก่อนจะใส่พรอมป์ต์ให้ AI เราก็รู้โครงสร้างโค้ดดีอยู่แล้ว และถ้าแยกงานอย่างระมัดระวัง การรีวิวโค้ดที่สร้างขึ้นมาก็ง่ายมาก รู้สึกเหมือนอ่านหนังสือที่เคยอ่านแล้ว และถ้ามีอะไรผิดก็จะสะดุดตาทันทีจนจับได้ตั้งแต่ต้น ไม่ว่าจะมองทางไหนก็เร็วขึ้นมาก
    • คนเองก็พลาด ข้อกำหนดบังคับ ที่ระบุไว้บ่อยเหมือนกัน และก็ต้องมีการรีวิวเหมือนกัน ถึงอย่างนั้นเราก็เพิ่มความน่าเชื่อถือของผลงานมนุษย์ได้ด้วยกระบวนการและการรีวิว และวิธีจำนวนมากที่ใช้ใน harness ก็หยิบมาจากประสบการณ์ในการลดปัญหาของมนุษย์ซึ่งส่งต่อความต้องการอย่างน่าเชื่อถือได้ยาก
    • สิ่งที่พูดมาทั้งหมดเป็นไปได้ และในเชิงทฤษฎีก็เห็นด้วย
      แต่ในช่วงหลายเดือนที่ผ่านมาได้ลองใช้ spec-kit หรือก็คือการใช้ AI แบบนี้ และในทางปฏิบัติแล้วมัน ดีจนน่าตกใจ กำลังสร้างของดี ๆ อยู่ และปัญหาที่ตั้งเป็นสมมติฐานมาก็ยังไม่เจอ อาจจะเกิดวันหนึ่งก็ได้ เลยยังระวังอยู่
      แต่พอได้ใช้เองมาระดับหนึ่งแล้ว ก็โยนทิ้งว่าเป็นแค่ยาครอบจักรวาลหลอกลวงไม่ได้ ทำงานเป็นโปรแกรมเมอร์มามากกว่า 30 ปี และรู้สึกว่าพอจะแยกออกว่าอะไรใช้ได้จริงอะไรใช้ไม่ได้
    • มันคล้ายกับการบอกว่าดาบ +5 ก็ไร้ประโยชน์เพราะถ้าทอยได้ 1 ก็ยังพลาดอยู่ดี ต้องมองที่ ค่าคาดหวัง ถ้ามีคน merge PR ที่ใช้ได้ห้าชิ้นแล้วทิ้งไปสามชิ้น การมาบ่นหนักเพราะหนึ่งในนั้นแย่มาก มันเทียบกันไม่ได้
    • หวังว่าที่คนเรียกข้อเสนอแบบ Markdown พวกนี้ว่า workflow ก็เพราะกลัวว่ามันจะล้าสมัยระหว่างที่กำลังขัดเกลาแนวทางที่มีโครงสร้างกว่านี้ ไม่คิดว่าความเร็วของนวัตกรรมใน base model จะเป็นแบบนี้ไปตลอด
      ต่อไปอยากเห็น harness ที่ไม่ได้แค่ร้องขอแต่ “บังคับ” เช่น ถ้าบอกให้อยู่ในโหมดวางแผน แล้วเอเจนต์ไม่ทำตามขั้นตอนการวางแผนที่กำหนดไว้ก็ฆ่าทิ้งไปเลย ถึงจะไม่สมบูรณ์แบบ แต่ก็ควรดีกว่าวิธีปัจจุบันที่ยังต้องมีคนคั่นกลาง

  • เขาบอกว่า “สกิลคือไฟล์ Markdown ที่มี frontmatter ซึ่งจะถูก inject เข้าไปในบริบทของเอเจนต์เมื่อเหมาะกับสถานการณ์” แต่คนที่ตัดสินว่านั่นใช่สถานการณ์นั้นหรือไม่ก็คือ LLM
    เขายังบอกอีกว่า “มันเป็นชุดขั้นตอนที่เอเจนต์ทำตาม และจบลงด้วย checkpoint ที่สร้างหลักฐานและมีเกณฑ์จบที่ชัดเจน” แต่สิ่งที่ตัดสินว่าจะทำตามขั้นตอนเหล่านั้นหรือไม่ก็ยังเป็น LLM อยู่ดี

    • สกิลมักถูกผู้ใช้ เรียกแบบคำสั่งโดยตรง ถ้าตั้งใจให้ LLM ใช้เอง ก็แค่ใส่ไว้ที่ไหนสักแห่งในบริบท เช่น: 
      After implementing the feature, read the testing skill for instructions on how to test.
    • พูดอย่างเป็นธรรม ใน Codex และระบบคล้ายกัน คุณสามารถเรียกสกิลโดยตรงด้วย $my-skill ได้ และถ้าทำแบบนั้นสกิลนั้นก็จะถูก inject เข้าไปในบริบทจริง ๆ หลังจากนั้น LLM ก็จะทำตามสกิลนั้นพอ ๆ กับที่มันทำตามพรอมป์ต์ คำสั่ง หรือส่วนอื่น ๆ ของบริบท

  • รอวันที่ทุกคนจะตระหนักว่าใช้เวลาเกินปีไปกับการลองเล่นเอเจนต์และได้มาแค่ความรู้สึกของ ผลิตภาพปลอม

    • เข้าใจความสงสัยอยู่บ้าง และอาจเชื่อโดยพื้นฐานว่า AI แย่ด้วยเหตุผลหลายอย่างก็ได้ แต่ยิ่งนานยิ่งไม่เข้าใจคำพูดที่ฟันธงแบบนี้ สงสัยจริง ๆ ว่ามั่นใจได้อย่างไรว่า AI development มันพังขนาดนี้
      มันไม่ตรงกับประสบการณ์จริงของผมเลย อยากรู้ว่าประสบการณ์แบบไหนทำให้มั่นใจนักว่า AI coding จะล่มสลายอย่างหลีกเลี่ยงไม่ได้ เป็นความเชื่อเชิงปรัชญาว่า AI ผิดศีลธรรมหรือเปล่า หรือว่าได้ลองสร้างอะไรด้วย AI จริง ๆ และสำรวจมันมากพอจนได้ข้อสรุปที่แรงขนาดนั้น
      ผมเขียนโค้ดทุกวันมามากกว่า 30 ปี และทำเป็นอาชีพมากกว่า 20 ปี เห็นกระแสมาแล้วก็ไป และก็เห็นความก้าวหน้าจริงที่เปลี่ยนวิธีทำงานหลายครั้ง ยิ่งสร้างโปรเจกต์ด้วย AI มากเท่าไร ก็ยิ่งมั่นใจว่านี่คือ การเปลี่ยนแปลงที่ต่อเนื่องและเป็นพื้นฐาน ต่อวิธีสร้างซอฟต์แวร์และใช้คอมพิวเตอร์
      ผมเห็น AI ดีขึ้น และเห็นตัวเองเก่งขึ้นในการใช้มันให้งานเสร็จด้วย งานพวกนั้นผ่านการทดสอบกับภาระงาน production ในโลกจริงแล้ว คุณอาจไม่ชอบสิ่งที่กำลังเกิดขึ้นและไม่ชอบความรู้สึกของการทำงานกับ AI แต่ไม่ได้แปลว่ามันไม่ได้สร้างคุณค่าจริงหรือไม่ได้ทำงานจริงให้คน
    • อยากเข้าใจมุมมองนี้ ถามด้วยเจตนาดี คือมันมีสมมติฐานแฝงอยู่ว่าคนที่ใช้ AI/เอเจนต์/harness ไม่ได้ deploy ฟีเจอร์จริง หรือเปล่า?
      พวกเราเข้า Claude Code เต็มตัวตั้งแต่ประมาณกันยายน และติดตามการปรับปรุงได้สำเร็จ เรากำลัง deploy ฟีเจอร์ที่ใช้งานจริงใน production ทั้งงานฝั่ง infra การทำ business logic รวมถึงทั้ง frontend และ backend
      ผมไม่คิดว่าคนพวกนี้กำลังเสียเวลาแบบนั้น แต่ก็เห็นด้วยว่าบทความแนวนี้ส่วนใหญ่ไร้สาระ รวมถึงชิ้นนี้ด้วย ถึงอย่างนั้น AI development ก็เกิดขึ้นแล้วในหลายบริษัททั่วโลก
    • มันเหมือนการบอกว่าคนเลิกใช้สมุดบัญชีกระดาษ แล้วเสียผลิตภาพไปกับการลองเล่นสิ่งที่เรียกว่า ฐานข้อมูล
    • ผมทำงานในโปรเจกต์ที่วัดผลลัพธ์อยู่ และตรงนั้นไม่มีคำว่า “ปลอม” เลย
    • ผมมองมันเหมือนระบบอัตโนมัติใน Minecraft คือเอาไว้สนุกและฆ่าเวลา
      ผมยังไม่คิดว่า workflow แบบเอเจนต์ไปถึงจุดนั้นแล้ว แต่การทำสกิลเพื่อใช้ตอนเรียกเองแล้วทำงานข้าง ๆ AI นั้นใช้ได้ดีจริง ๆ บริษัทผมช่วงนี้โฟกัสกับ sandboxing และสกิลที่ปลอดภัยมาก
      ผมยังไม่คิดว่ามันจับงานพัฒนาฟีเจอร์ได้ดีนัก แต่ review skill กับ Grafana skill ที่เราเขียนไว้ค่อนข้างแข็งแรง

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

    • MCP และ system instruction ก็เหมือนกัน มีหลายคนติดตั้งทุกอย่างทั้งที่ไม่เข้าใจ แล้วก็เอาเครื่องมือที่ไม่จำเป็นมาทำให้บริบทยุ่งเหยิง เสียไป มากกว่า 50k token แล้วค่อยบ่นว่าชนลิมิตเร็วเกินไปจนต้องจ่ายเกิน 100 ดอลลาร์ต่อเดือน

  • ถ้ามองจากมุม SEO หรือ LLM optimization ดูเหมือนว่าสกิลพวกนี้จะ ค้นพบได้ยาก ถ้าไม่เปลี่ยนชื่อ: https://agentskills.io/
    ถ้า Addy มาเห็น อยากรู้ว่าจะอธิบายว่ามันต่างจาก Superpowers อย่างไร: https://github.com/obra/superpowers

    • อยากรู้ว่ามีคนใช้ superpowers จริง ๆ มากแค่ไหน
      ผมอยู่สาย agent dev มาก่อน superpowers และกังวลว่าเกิน 50% ของกระบวนการที่สร้างเองตอนนี้ถูก superpowers ครอบคลุมไปแล้ว
      ผมไม่เชื่อ GitHub stars อีกต่อไปแล้ว อยากให้มีคนบอกหน่อยว่า superpowers ถูกใช้งานจริงแล้วหรือยัง ถ้ามันมีคุณค่าจริง ทำไม Boris ยังไม่รวมแนวคิดนี้เข้าไป?
    • มันเหมือนตั้งชื่อ React framework ว่า ReactJS เพื่อไปแข่งกับ NextJS
    • มันดูเหมือนชุดสกิลสำเร็จรูปที่แจกมาในรูปแบบปลั๊กอิน
    • superpowers ใช้งานได้จริงไหม? ไฟล์สกิลหลักไม่ได้ทำให้มั่นใจนัก:
      “ถ้าคุณคิดว่ามีโอกาสแม้แค่ 1% ที่สกิลนั้นจะเกี่ยวข้องกับสิ่งที่กำลังทำอยู่ คุณต้องเรียกใช้สกิลนั้นเสมอ”

  • ไม่เข้าใจว่าทำไมทุกคนถึงกระตือรือร้นกับการทำลายงานของตัวเองกันขนาดนี้
    ของพวกนี้หรือ “สกิล” ไหน ๆ คงไม่ได้ทำแบบนั้นจริง แต่ในเชิงหลักการแล้ว มันดูเหมือน ความ疏離จากแรงงาน กำลังเกิดขึ้นในวงกว้าง

    • เราทำให้งานส่วนใหญ่ในอดีตเป็นอัตโนมัติกันมาหลายสิบปีแล้ว ถ้าไม่ทำ ทุกคนก็คงพยายามทำอะไรให้ไร้ประสิทธิภาพที่สุดเพื่อให้งานใช้เวลานานที่สุด ซึ่งไม่ใช่ความคิดที่ดี
      เท่าที่ตามรอยได้ มนุษย์พยายามลดแรงงานที่ต้องใช้เพื่อให้ได้ผลผลิตระดับหนึ่งมาโดยตลอด และนั่นแหละคืออารยธรรม เราควรกลับไปทำเกษตรด้วยจอบด้วยมือเพื่อเพิ่มแรงงานที่ใช้หรือ? ควรกลับไปยุคที่ต้องจุดไฟถนนทีละดวงหรือ?
      สังคมที่ตาม automation ไม่ทันจะยากจนลงและสุดท้ายก็ตาย เพราะแม้แต่คนที่เกิดที่นั่นก็ย้ายไปที่ที่มีผลิตภาพสูงกว่า มันเกิดขึ้นในยุโรปตะวันออก กับชาว Amish และในทุกสังคมยากจนที่มีการอพยพ ทำให้ไดั้มากขึ้นด้วยสิ่งที่น้อยลง เป็นเรื่องน่าสนใจเสมอ
    • ในฐานะโปรแกรมเมอร์คอมพิวเตอร์ มันยากที่จะเข้าใจความคิดแบบนี้ เพราะทั้งชีวิตผมทำแต่งานที่ทำให้คอมพิวเตอร์ทำแทน เพื่อให้คนไม่ต้องทำอีกต่อไป ซอฟต์แวร์ทุกชิ้นที่ถูกเขียนขึ้นมาก็เพื่อกำจัดงานของใครสักคน
      ผมสงสัยว่าคุณรู้สึกแบบนี้กับ automation ทุกอย่างที่สร้างขึ้นหรือเปล่า มี sysadmin สายเก่าบางคนที่มองความก้าวหน้าของการทำ infra automation แบบนี้ และไม่ชอบที่สคริปต์กับระบบเข้ามาทำสิ่งที่เมื่อก่อนต้องทำด้วยมือ
      ทีมของเราที่บริษัทหนึ่งเคยสร้างระบบ patch อัตโนมัติให้กับ เซิร์ฟเวอร์ 30,000 เครื่อง รวมถึงเอาระบบออกจาก production และใส่กลับเข้าไปโดยอัตโนมัติ กระบวนการทั้งหมดกลายเป็นแบบไม่ต้องแตะมือเลย และเมื่อก่อนเคยมีทีมเฉพาะที่คอยรันกระบวนการนี้ด้วยมือ automation แย่งงานพวกเขาไหม?
      ในความหมายหนึ่งก็ใช่ แต่ก็ยังมีงานอื่นที่ต้องทำ และตอนนี้พวกเขาก็ทำงานนั้นได้
      นี่แหละเหตุผลที่ผมชอบการเขียนโปรแกรม คอมพิวเตอร์ และเทคโนโลยี เพราะมันทำงานแทนเรา ยูโทเปียของผมคือโลกที่หุ่นยนต์ทำงานหนักทั้งหมดเพื่อให้มนุษย์ไปทำสิ่งที่อยากทำได้ AI กำลังพาเราเข้าใกล้ทางนั้นอีกก้าว แทนที่จะพยายามเก็บงานไว้ให้มากพอเพื่อให้มนุษย์ยุ่งอยู่กับงานที่ไม่อยากทำ ผมอยากโฟกัสกับวิธีทำให้ผลประโยชน์จากการที่หุ่นยนต์แย่งงานไป ไม่ได้ตกอยู่แค่กับเจ้าของที่ร่ำรวย แต่เป็นของทั้งโลก
    • ปกติแล้วคนที่ตกงานคือคนที่ปรับตัวเข้ากับตลาดไม่ได้
      ตอนนี้ยังไม่ชัดว่าทุกอย่างกำลังวิวัฒน์ไปทางไหน คนเลยกำลังลองส่งข้อมูลของตัวเองให้เอเจนต์สุ่ม ๆ ดู หาวิธีเก็บและเข้าถึงบริบท ใช้พรอมป์ต์ซ้ำ และทดลองหลายแนวทางในการรับมือกับเทคโนโลยีนี้
      ส่วนใหญ่ของสิ่งเหล่านี้อาจไร้ประโยชน์ภายในหนึ่งปี เมื่อมันถูกหลอมรวมลึกเข้าไปในโมเดลรุ่นถัดไปอยู่แล้ว ถึงอย่างนั้น การตามให้ทันความก้าวหน้าก็เป็นส่วนหนึ่งของความสนุกในการทำงานด้านนี้เสมอ
    • มันคือสัญชาตญาณเอาตัวรอด เมื่อคนรอบตัว ทุกสิ่งทุกอย่าง และแม้แต่งาน ต่างตะโกนว่า “ใช้ AI สิ” ก็ยากที่จะยืนค้านหรือแม้แต่ตั้งข้อระวัง ไม่ใช่ว่าตื่นเต้นหรอก แต่ใกล้เคียงกับการกลัวว่าจะพลาดคลื่นและ ตามหลังคนอื่น มากกว่า
      ถ้ามีข้อมูลระยะยาวออกมาว่าโดยเฉลี่ยแล้วการเพิ่มผลิตภาพมีข้อจำกัด และถึงจะมีโมเดลชั้นนำรุ่นล่าสุดช่วยอยู่ การทำซอฟต์แวร์คุณภาพดีก็ยังต้องการความพิถีพิถันและความใส่ใจจากมนุษย์ ทั้งฝั่งที่เห็นด้วยและไม่เห็นด้วยก็คงประหลาดใจเล็กน้อย
      มันก็แค่งานเดิม แต่มีสว่านไฟฟ้าแทนไขควง บางคนสร้างบ้านที่อยู่ได้หลายร้อยปี บางคนก็ทำไม่ได้
    • ดูเหมือนว่าคนที่เดิมทีไม่ได้เป็นนักพัฒนาที่เก่ง กลับรู้สึกว่าตัวเองถูกเร่งให้ไปถึงระดับ “ปกติ” ทันที และคนกลุ่มนี้ก็ดูจะกระตือรือร้นที่สุด นักพัฒนาที่เก่งจริงที่ผมรู้จักล้วนระวังกับการนำมันมาใช้มากกว่า

  • ช่วงนี้ได้ยินคำพูดแบบนี้บ่อยขึ้นเรื่อย ๆ ว่า สิ่งที่ดีต่อการบริหารทีมพัฒนาก็ดีต่อ การบริหาร LLM ด้วย
    เช่น test case ที่ดี เอกสารที่ชัดเจนและกระชับ CI/CD best practices และเอกสาร onboarding
    การจัดการ LLM กำลังคล้ายกับการจัดการทีมคนมากขึ้นเรื่อย ๆ

    • ใช่ ผมเองก็พูดแบบนั้นมาตั้งแต่ประมาณหนึ่งปีก่อน และในการนำเสนอภายในก็ใช้เกร็ดนี้เป๊ะเลย
    • เช่นกัน เรื่องเล่าความสำเร็จของการเขียนโค้ดแบบเอเจนต์ก็มักมาจากองค์กรที่มีสิ่งเหล่านี้ครบอยู่แล้วตั้งแต่แรก

  • อยากรู้ว่ามันดีกว่าหรือแตกต่างจาก spec-kit อย่างไร ปรัชญาดูคล้ายกันมาก และก็สงสัยว่าน่าจะใช้ร่วมกันได้ไหม หรือจริง ๆ แล้วแค่ซ้ำซ้อน?
    https://github.com/github/spec-kit

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

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

    • ที่มันยาวก็เพราะสกิลพวกนี้ส่วนใหญ่สร้างด้วย Claude Code และ Opus และไม่มีคนปกติคนไหนจะอ่านไฟล์พวกนั้นหรือสร้างโมเดลในหัวจากมันอยู่แล้ว มีการซ้อนสมมติฐานหลายชั้นว่ามันจะเวิร์ก แต่ในโลกจริงมันไม่เวิร์กและเปลือง
      มีการทดลองสนุก ๆ อย่างหนึ่ง ลองขอให้ LLM ใช้สิ่งที่มันคุ้นแบบคลุมเครือดู เช่นขอว่า “write a fib” แทบทุก LLM จะถูก fine-tune ด้วยโค้ดจนแม้สำหรับคนที่ไม่ใช่โปรแกรมเมอร์มันอาจหมายถึง “เขียนคำโกหกเล็ก ๆ” แต่มันกลับตอบเป็น อัลกอริทึมลำดับฟีโบนัชชี
      นี่หมายความว่ามีการบีบอัดเกิดขึ้น โดยไม่ต้องอธิบายละเอียดว่าลำดับฟีโบนัชชีคืออะไร ก็สามารถสื่อผลลัพธ์ได้ด้วยโทเคนกำกวมแค่ 3 ตัว
      เพราะงั้นเราจึงรู้ว่าความยาวของพรอมป์ต์ไม่ใช่เรื่องสำคัญ สิ่งสำคัญคือคำที่ถูกต้อง ความถี่ และลำดับ พรอมป์ต์ยาวสองหน้ากับพรอมป์ต์สองประโยคอาจให้ผลลัพธ์แบบเดียวกันก็ได้
    • พอดูผ่าน ๆ อย่างน้อยบางอันก็ดูใกล้เคียงกับ system prompt สำหรับ sub-agent ขอบเขตแคบ มากกว่าจะเป็นสกิลจริง ๆ เห็นด้วยว่าไม่อยากใช้ของแบบนี้เยอะ ๆ ในเซสชันงานที่ยาวนาน
      จนถึงตอนนี้ผมประสบความสำเร็จกับสกิลที่สั้นและโฟกัสชัด เจอกับมันเหมือนเป็นชิ้นส่วนบริบทที่ใช้ซ้ำได้แต่ต้องเล็ก เช่นสองสามย่อหน้าเกี่ยวกับวิธีใช้ Python ในโปรเจกต์ของผม และวิธีรัน unit test
      ผมยังมีสกิล “info” สั้น ๆ หลายอันที่ไม่ได้สั่งเอเจนต์ แต่มีแค่ข้อมูลบริบทที่มีประโยชน์ซึ่งดึงขึ้นมาใช้เมื่อจำเป็น
      สกิลมากเกินไปก็อาจเป็นปัญหา เพราะสุดท้ายรายการชื่อและคำอธิบายของสกิลก็ต้องเข้าไปอยู่ในบริบท ณ จุดหนึ่งอยู่ดี
    • ผมยังไม่เคยเขียนสกิลเองสักอัน เลยไม่รู้ว่าปกติแค่ไหน ลองนับคำของบางอันดูแล้วอยู่ราว ๆ 2,000 คำ สกิล 5 อันก็ประมาณ 10,000 คำ
      แม้ในบริบท LLM เล็กอย่าง 128k ก็ประมาณ 10% และในหน้าต่างบริบท 1M ของโมเดลใหญ่แทบไม่เห็นผลเลย
    • โดยพื้นฐานแล้ว ในบริบทจะโหลดแค่ frontmatter ของสกิล เช่น ชื่อ คำอธิบาย trigger เป็นต้น เพราะงั้นถ้าไม่ได้มีสกิลเป็นพัน ๆ อัน ก็คงไม่ค่อยเกิดปัญหาแบบนั้น
    • ผมไปเช็กจำนวนบรรทัดของไฟล์สกิลในโปรเจกต์ตัวเองมา สามอันดับแรกคือ 805 บรรทัด 660 บรรทัด และ 511 บรรทัด
      บางทีผมอาจจะอนุรักษ์นิยมเกินไปในเรื่องนี้ ยังมีอะไรให้สำรวจอีกมาก

  • “งานส่วนใหญ่ของวิศวกรอาวุโสคือสิ่งที่มองไม่เห็นใน diff”
    Agent Skills คือความพยายามของ Addy ที่จะลบงานส่วนนั้นออกไปด้วย ชนแก้วให้ Addy :P