Learning Opportunities - สกิลที่ช่วยพัฒนาทักษะอย่างมีเจตนาใน Claude Code และ Codex

 (github.com/DrCatHicks)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สกิลสำหรับ Claude Code และ Codex ที่ช่วยให้ระหว่างทำ agentic coding ไม่ได้พัฒนาแค่โปรเจ็กต์ แต่ยังช่วยยกระดับ ความเชี่ยวชาญของผู้ใช้ ด้วย
  • หลังทำ งานเชิงสถาปัตยกรรม เช่น การสร้างไฟล์ใหม่ การเปลี่ยนสคีมา หรือการรีแฟกเตอร์เสร็จ Claude จะเสนอแบบฝึกการเรียนรู้แบบเลือกทำความยาว 10–15 นาที
  • แบบฝึกใช้เทคนิคจากวิทยาศาสตร์การเรียนรู้ เช่น prediction, generation, retrieval practice, spaced repetition และสร้างโจทย์ตัวอย่างที่ทำค้างไว้ครึ่งหนึ่งจากงานจริงในโปรเจ็กต์ของผู้ใช้
  • ออกแบบมาเพื่อลดปัญหาที่เครื่องมือเขียนโค้ดด้วย AI อาจก่อให้เกิด เช่น การยอมรับโค้ดที่สร้างมาโดยไม่ไตร่ตรอง ภาพลวงตาว่าตนเองเข้าใจคล่องแล้ว การโหมทำงานยาวนาน การขาด metacognition และการลดลงของการทดสอบตนเอง
  • Claude จะถามในลักษณะว่า “อยากลองทำแบบฝึกการเรียนรู้สั้น ๆ ในหัวข้อนี้ไหม? ใช้เวลาประมาณ 10–15 นาที” และหากผู้ใช้ยอมรับ ก็จะเริ่ม แบบฝึกแบบโต้ตอบ
  • หลักการออกแบบสำคัญคือ Claude จะไม่ตอบคำถามของตัวเอง แต่จะ รอข้อมูลจากผู้ใช้ โดยตั้งใจให้เป็นโหมดสะท้อนคิดและสำรวจที่ต่างจาก agentic coding แบบรวดเร็ว
  • ประเภทของแบบฝึกประกอบด้วย prediction→observation→reflection, generation→comparison, การไล่ตามเส้นทางการทำงาน, การคาดการณ์การดีบัก, การอธิบายให้ผู้พัฒนาใหม่ฟัง, และการทบทวนดึงความจำจากเซสชันก่อนหน้า
  • เงื่อนไขการยับยั้งที่เสนอไว้ในตอนนี้คือ จะไม่เสนอโอกาสการเรียนรู้อีกหากในเซสชันเดียวกันผู้ใช้เคยปฏิเสธแบบฝึกไปแล้ว หรือทำแบบฝึกครบ 2 ครั้งแล้ว
  • ใน Codex สามารถเพิ่มเข้า marketplace ได้ด้วย codex plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.git และมี learning-opportunities, learning-opportunities-auto, orient รวมอยู่ด้วย
  • ใน Claude Code ให้เพิ่มผ่าน Claude Code plugin marketplace จากนั้นติดตั้งด้วย /plugin install learning-opportunities@learning-opportunities แล้วรีสตาร์ตเพื่อเปิดใช้งาน
  • learning-opportunities-auto เป็น hook แบบเลือกใช้บน Linux และ macOS ที่ทำให้ Claude พิจารณาเสนอแบบฝึกหลัง git commit และบน Windows ก็ใช้งานได้ด้วยการตั้งค่าเพิ่มเติม
  • สกิล orient จะสร้าง orientation.md เมื่อต้องเรียนรู้รีโพซิทอรีใหม่ และให้บทเรียนแนะนำที่อิงจากงานวิจัยด้านความเข้าใจโปรแกรมและการสำรวจโค้ดเบส
  • เหมาะสำหรับใช้ร่วมกับ Learning-Goal โดยสกิลดังกล่าวถูกแนะนำว่าเป็นตัวช่วยตั้งเป้าหมายการเรียนรู้แบบกึ่งมีโครงสร้างและโต้ตอบได้ด้วยเทคนิค MCII
  • สำหรับการทดลองในทีม สามารถใช้ MEASURE-THIS.md ร่วมกันได้ โดยมีทั้งคำถามแบบสำรวจที่ผ่านการตรวจสอบแล้ว คู่มือการตีความผลลัพธ์ เทมเพลต “team boast” สำหรับแชร์กับฝ่ายผู้นำ และ nudges เรื่องความเข้มงวดทางสถิติใน Claude.md
  • เผยแพร่ภายใต้สัญญาอนุญาต Creative Commons Attribution 4.0 International License

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

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

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

  • ยังไม่ค่อยเข้าใจ Skills เท่าไร แต่พอดูในรีโปแล้วรู้สึกว่า โค้ดและข้อความที่ประดับตกแต่ง ดูเยอะเกินไปเมื่อเทียบกับพรอมป์ต์สั้น ๆ แค่ตัวเดียวใน bash script ที่รันหลังคอมมิต
    แก่นจริง ๆ ก็ใกล้เคียงกับการบอกว่า ผู้ใช้เพิ่งคอมมิตไป ดังนั้นถ้ามีไฟล์ใหม่ การเปลี่ยน schema การตัดสินใจด้านสถาปัตยกรรม การ refactor หรือแพตเทิร์นที่ไม่คุ้นเคย ก็ให้เสนอ แบบฝึกหัดการเรียนรู้ 10–15 นาที

    • Skills มีประโยชน์ในการอธิบายเวิร์กโฟลว์ที่ทำซ้ำได้แบบเป็นมาตรฐาน ประหยัดคอนเท็กซ์ด้วยการเปิดเผยแบบค่อยเป็นค่อยไป แชร์พรอมป์ต์ และรวบส่วนที่ไม่ค่อยถูกใช้แต่ไม่เป็น deterministic เข้าไว้ใน ขั้นตอนแบบ deterministic อย่างสคริปต์
      ในเชิงแนวคิดควรมองมันไม่ใช่เป็นการหยิบเวทมนตร์ของคนอื่นมาใช้ แต่เป็น ซอฟต์แวร์ที่ค่อย ๆ เติบโต https://alexhans.github.io/posts/series/evals/building-agent...
      ใน coding harness มักมี agent skill ชื่อ SkillBuilder อยู่แล้ว จึงสร้างได้ง่ายและพัฒนาต่อไปเรื่อย ๆ ได้
      แนะนำให้ทำขึ้นมาเองให้ตรงกับปัญหาของตัวเอง และก็มีตัวอย่างง่าย ๆ ที่ใช้การประเมินเพื่อดันความแม่นยำของระบบอัตโนมัติให้สูงพอ https://alexhans.github.io/posts/series/evals/sketch-to-text...
    • เครื่องมือพวกนี้ส่วนใหญ่สุดท้ายก็เป็น ไฟล์ Markdown อีกไฟล์หนึ่งที่เอาไปเสียบไว้ในพรอมป์ต์ และเมื่อดูจากวิธีทำงานของโมเดลภาษาใหญ่แล้วก็ถือเป็นโครงสร้างที่ปกติ
      เพราะงั้นเลยอยากแนะนำให้ใช้ Claude สร้างเครื่องมือแบบคล้าย ๆ กันของตัวเอง ตอนแรกอาจเปลืองโทเค็น แต่หลังจากนั้นเครื่องมือของตัวเองจะช่วยลดโทเค็นและการเรียกใช้ที่ต้องใช้กับงานสำคัญได้มาก
      ยังสามารถล็อกการเรียกใช้เครื่องมือให้ปลอดภัยขึ้น ทำให้งานของเอเจนต์ retry ได้ และลด failure mode ลงได้ด้วย ถ้าโน้ตบุ๊กดับระหว่างทำงาน ก็ยังเลี่ยงสถานการณ์ที่ต้องเผาโทเค็นจำนวนมากเพื่อให้เอเจนต์ไล่ฟื้นว่าทำถึงไหนแล้วได้

  • แปลกใจที่ Skills บางอันไม่ได้เขียนขั้นตอนที่ชัดเจนหรือสิ่งที่ต้องทำเลย แต่แค่ตั้งต้นแบบ คำพูดปลุกใจ เพื่อให้โมเดลเขียนข้อความได้ดีขึ้นในงานบางประเภท
    frontend design skill ที่ Claude ใช้ก็แทบจะเป็นแค่การขอให้เลือกฟอนต์ดี ๆ และทำให้ดีไซน์สอดคล้องกัน โดยไม่ได้ลงรายละเอียดว่าจะใช้ฟอนต์อะไร หรือจะจัดชุดสีและเลย์เอาต์อย่างไร
    https://github.com/anthropics/claude-code/blob/main/plugins/...

  • เอเจนต์เขียนโค้ดอาจก่อให้เกิด หนี้จากการทำซ้ำ ได้ ถ้ารับผลลัพธ์จาก coding assistant มาใช้โดยไม่ตรวจว่าถูกไหม ความรู้เกี่ยวกับโค้ดเบสของตัวเองจะค่อย ๆ หายไป
    ไฟล์คอนเท็กซ์อย่าง CLAUDE.md, migration protocol, authentication protocol จะทำงานได้ดีก็ต่อเมื่อเราเข้าใจมันมากพอที่จะอัปเดตมันได้อย่างถูกต้อง
    เคยมีช่วงที่ยอมรับโค้ดที่เอเจนต์สร้างมาแบบไม่ลืมหูลืมตาอยู่สองชั่วโมง แล้วสุดท้ายก็ลืมไปเลยว่าโค้ดเบสทำงานอย่างไร จนสร้างไฟล์คอนเท็กซ์ใหม่ไม่ได้ หนี้ด้านทักษะ แบบนี้ไม่ปรากฏใน diff และจะโผล่มาให้เห็นตอนที่ต้องเป็นคนนำเอเจนต์เอง

    • ฟังดูเหมือนจะเป็นแบบ recursive มากกว่า repetitive ไหม
      เวลาจะเปลี่ยนฟีเจอร์ใหญ่ ๆ ควรคุยกันในแชตก่อนให้ตรงกันว่า ปัญหาในโดเมนธุรกิจ ที่พยายามแก้อยู่นั้นคืออะไร ก่อนจะให้เอเจนต์ไปเขียนโค้ด เหมือนนั่งคุยกับผู้รับเหมาพัฒนาซอฟต์แวร์ภายนอกเพื่อจัดสิ่งที่ต้องการให้ชัด
      จากนั้นก็เขียนเอกสารออกแบบเป็น bullet แบบลำดับชั้นร่วมกับเอเจนต์ลงในไฟล์ .md จริง ๆ โดยให้เอเจนต์ช่วยสร้างและแก้ไขเป็นส่วนใหญ่ แต่ต้องไล่ตรวจปัญหาและการตัดสินใจที่กำกวมอย่างละเอียด เพื่อให้การตัดสินใจระดับดีไซน์จบตั้งแต่ตรงนี้
      ต่อจากนั้นก็ให้แปลงสเปกการออกแบบไปเป็นโครงของชุดทดสอบสเปกแบบ BDD และค่อยเติมรายละเอียดระหว่างลงมือทำ
      ในขั้น implementation จะเพิ่ม แก้ไข หรือลบ unit test และ integration test ก็ได้ แต่ไฟล์สเปกการออกแบบและโครงสร้างการทดสอบ BDD ที่ต่อยอดมาจากมันควรถูกตรึงไว้ ก่อนเสร็จ BDD tests ต้องถูกเติมด้วยลอจิกที่ตรงกับป้ายกำกับและต้องผ่านทั้งหมด
      ถ้าโปรเจ็กต์ใหญ่มาก ก็อาจวนเป็นสปรินต์แล้วทำซ้ำกระบวนการอย่างการนิยามความต้องการทางธุรกิจใหม่ การแก้แบบ การเพิ่มชุด BDD ใหม่อีกครั้ง หรือจะคั่นระหว่างขั้นตอน 2 และ 3 ด้วยการแบ่งดีไซน์เป็น milestone แล้วสร้างและแก้เฉพาะรายการ BDD ของ milestone ปัจจุบันก็ได้
      สรุปคือใช้ แนวทางแบบ waterfall กับ LLM นั่นเอง ถ้ากระบวนการทั้งหมดจบได้ภายในหนึ่งชั่วโมง waterfall ก็อาจใช้งานได้สบายมาก
      จุดสำคัญคือหลังจบโปรเจ็กต์หรือ milestone ให้เอเจนต์อธิบายโค้ดที่มันเขียนในแชต แต่ห้ามอธิบายสิ่งที่ปรากฏอยู่ในดีไซน์แล้ว
      แบบนั้นเราจะเอาคำอธิบายเฉพาะส่วนที่น่าแปลกใจไปแปลงเป็นคอมเมนต์ในโค้ดได้ และผลที่ได้จะไม่ใช่คอมเมนต์ขยะเชิงพิธีการ แต่เป็นคอมเมนต์ที่เหมือนคนจริงเขียน

  • ถ้าไม่มี benchmark และ evaluation แล้วจะรู้ได้อย่างไรว่ามันให้ผลดีกว่า /create-skill? การทดสอบแบบพื้น ๆ ไม่ได้ทำให้รู้สึกเชื่อถือได้

    • เหมือนสิ่งที่พูดถึงตรงนี้จะเป็นการพัฒนา ทักษะของมนุษย์ มากกว่า เป็นฟังก์ชันที่ให้โอกาสผู้ใช้ได้เรียนรู้
      มีคำอธิบายว่าหลังทำงานด้านสถาปัตยกรรมเสร็จ Claude จะเสนอแบบฝึกหัดทางเลือก 10–15 นาทีที่อิงกับวิทยาศาสตร์การเรียนรู้ซึ่งมีหลักฐานรองรับ โดยใช้เทคนิคอย่างการทำนาย การสร้าง การดึงคืนความจำ และ spaced repetition พร้อมยกตัวอย่างที่ทำค้างไว้ครึ่งหนึ่งจากงานในโปรเจ็กต์ของตัวเอง
      ชื่อนี่ชวนสับสนจริง
    • เหมือนอยู่กับ LLM มากเกินไปจนแค่เห็นคำศัพท์ที่เกี่ยวข้องก็เกิด ปฏิกิริยาแบบพาฟลอฟ ขึ้นมาทันที
    • ดีแล้วที่ยกเรื่อง evaluation ขึ้นมา แต่ตอนนี้อยากรู้ว่าใช้อะไรอยู่หรือกำลังมองหาอะไร ทำเองอยู่หรือใช้ evaluation framework ที่มีอยู่แล้วด้วย

  • สำหรับคนที่ยังไม่ได้ลงไปในโพรงกระต่ายนี้ Skills คือ ไฟล์ Markdown แบบมีโครงสร้าง ที่อธิบายว่าจะจัดการงานขอบเขตแคบ ๆ อย่างไร
    ตัวอย่างเช่น ถ้าเขียน API endpoint ด้วยวิธีเฉพาะ ก็เขียนขั้นตอนนั้นไว้ใน skill ต่อมาเมื่อเอเจนต์ดู skill นี้แล้วตัดสินว่าเกี่ยวข้องกับคอนเท็กซ์ของแชตปัจจุบัน มันก็จะโหลดขึ้นมาแล้วทำตามคำสั่ง
    คล้ายการเรียกใช้เครื่องมือ แต่ไม่ใช่ฟังก์ชันที่เรียกได้ หากเป็นคำแนะนำว่าควรทำ “ทักษะ” นั้นอย่างไร
    อย่างน้อยใน Cline ที่ฉันใช้ Skills สามารถนิยามได้ทั้งแบบ global หรือแบบ local ระดับโปรเจ็กต์

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

  • ยังไม่เข้าใจว่า adaptive dynamic textbook approach คืออะไรแน่ ต้องการตัวอย่าง
    แต่ประเด็นที่ว่าถ้ารับโค้ดที่สร้างมาแล้วตัวเองเขียนโค้ดน้อยลง ก็จะข้ามการประมวลผลเชิงรุกที่ทำให้เกิดความเข้าใจ อันนี้จริงมาก

  • ไม่เข้าใจเลยว่าทำไมเวลาคิดไอเดียเจ๋ง ๆ แบบนี้ถึงยังไม่ใส่ลิงก์ เดโมหรือผลลัพธ์ตัวอย่าง มาด้วย เป็นแพตเทิร์นที่เห็นใน HN ทุกวัน
    ถ้าอยากดูว่า skill นี้หน้าตาจริง ๆ เป็นอย่างไร ต้องดาวน์โหลดมารันเองเท่านั้นเหรอ? ไม่อยากทำแบบนั้น

    • ตอนนี้ยังรู้สึกว่าการใช้ skill มีความเสถียรน้อยกว่าการสั่งชัด ๆ ใน AGENTS.md มาก
      เข้าใจไอเดียที่ว่าไม่เพิ่ม skill ตอนที่ไม่เกี่ยวข้องเพื่อเลี่ยงคอนเท็กซ์บวม แต่ถ้าไม่มีคำสั่งชัดใน AGENTS.md ก็ไม่มีอะไรรับประกันว่าเอเจนต์จะใช้ skill นั้น แบบนี้ก็แทบไม่ต่างจากไฟล์ Markdown ที่ถูกอ้างถึงไว้ตรงจุดหนึ่ง
      ตอนทำ https://www.agentkanban.io ซึ่งเป็นบอร์ดงานที่ผสานกับ GitHub Copilot ฉันลองมาหลายแบบมากว่าจะวางคำสั่งไว้ตรงไหน
      โครงสร้างที่ลึกลงไปอีกหนึ่งชั้นจาก AGENTS.md ทำงานได้ค่อนข้างดี เพราะต้องทำให้เอเจนต์หยิบ ID เฉพาะของงานได้อย่างเสถียร สุดท้ายเลยลงเอยกับวิธีใส่ INSTRUCTION.md ไว้ในไฟล์ที่เครื่องมือเป็นคนจัดการ ซึ่งช่วยลดการปนเปื้อนของ AGENTS.md ได้ด้วย
      ฉันก็ลองใช้ Skills เหมือนกัน แต่โดนข้ามบ่อยเกินไป เลยยากที่จะทำให้เครื่องมือทำงานได้เสถียรเท่ากับวิธีปัจจุบัน
    • มี SKILL.md อยู่ตรงนั้นอยู่แล้ว แค่อ่านดูก็รู้ว่ามันทำอะไร

  • ชอบไอเดียนี้มาก เคยให้ Claude ใช้ตำราและเอกสารโอเพนซอร์สมาสร้างตำราแบบสด ๆ ให้
    เลยสงสัยว่า skill นี้ขยายไปเป็นด้าน การเรียนรู้และการประยุกต์ใช้ ที่กว้างกว่านี้ได้ไหม หรือว่ามันเฉพาะทางด้านโค้ด

  • ปฏิกิริยาที่นี่น่าสนใจดี แต่ดูเหมือนคนส่วนใหญ่จะพลาดประเด็นสำคัญไป
    สำหรับฉัน บทเรียนสำคัญคือการได้เห็นว่าคนอื่น ใช้ Skills กันอย่างไร แล้วเอามาเรียนรู้ เมื่อวานฉันดูคลาสของ Matt Pocock เรื่องการใช้เอเจนต์ เขาโชว์ Skills โดยใช้ skill ชื่อ “grill-me” เพื่อพัฒนาเอกสารข้อกำหนดผลิตภัณฑ์
    ฉันคงไม่ทำตามที่เขาทำเป๊ะ ๆ แต่ก็ได้ไอเดียเกี่ยวกับวิธีสร้าง requirement และลงมือ implement ในแบบของตัวเอง
    อย่างที่วิศวกรของ Anthropic พูดไว้ Claude เหมือนวิศวกรที่มีพรสวรรค์แต่ยังขาดความเชี่ยวชาญ ส่วน Skills ก็คือโฟลเดอร์และไฟล์ที่ใช้สะสมความเชี่ยวชาญนั้น
    อีกอย่างที่ได้จาก Pocock คือยิ่งคอนเท็กซ์หรือขนาดโทเค็นยาวขึ้น คำตอบก็ยิ่งมีแนวโน้มจะทึ่มลง เพราะฉะนั้น Skills จึงเป็นอีกวิธีหนึ่งในการนำเสนอปัญหาให้ LLM ในรูปแบบที่บีบอัดแล้วเพื่อให้ได้คำตอบที่เหมาะขึ้น
    Claude เองก็มีลักษณะพฤติกรรมด้วย ถ้าใครสักคนสร้าง skill ซ้ำ ๆ แบบเดิมไว้ มันอาจถ่ายทอดไปยังผู้ใช้อื่นได้ไม่ดีนัก เพราะแต่ละคนคุยกับ Claude ไม่เหมือนกัน
    เพราะงั้นฉันเลยลังเลที่จะเอาโฟลเดอร์ skill ของตัวเองไปแชร์ให้เพื่อนร่วมทีม ตรงกันข้าม ฉันอยากโชว์สิ่งที่ทำไว้เป็นเดโม เพื่อให้แต่ละคนเห็นความเป็นไปได้แล้วไปหาเวิร์กโฟลว์ของตัวเอง
    คุณค่าคือการได้เห็นว่าคนอื่นสร้างของกับ Claude อย่างไร แล้วเอามาเลียนแบบในแบบของตัวเอง คล้ายตอนเริ่มหัดเขียนโปรแกรมแล้วคัดโค้ดจากหนังสือ C ของ Kernighan และ Ritchie มาพิมพ์ตาม ลองแก้เพื่อทำความเข้าใจการทำงาน แล้วค่อยดัดแปลงให้ตรงกับเป้าหมายของตัวเองในภายหลัง
    อีกเหตุผลที่พูดถึงลักษณะพฤติกรรมก็เพราะผู้เขียนเป็นนักจิตวิทยา เลยน่าสนใจว่ารูปแบบการโต้ตอบกับ Claude ของเขาอาจต่างจากโปรแกรมเมอร์พอสมควร
    เห็นมีคนบอกว่าผู้เขียนกับผู้เชี่ยวชาญจากหลายสาขาย้ายออกจาก Twitter ไปนานแล้ว เลยว่าจะติดตั้ง bsky หรือ Mastodon แล้วตามดู คิดว่าการสังเกตว่าผู้เชี่ยวชาญที่ไม่ใช่โปรแกรมเมอร์ใช้ LLM อย่างไรเป็นเรื่องสำคัญ

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