Austin Marchese เจ้าของช่อง YouTube ที่ทำคอนเทนต์เกี่ยวกับ AI workflow เผยแพร่คลิป "How Anthropic Engineers ACTUALLY Prompt Claude Code" โดยสรุปจากการฟัง engineer ของ Anthropic ที่งาน AI Code Summit และนำเนื้อหาที่ Anthropic ตีพิมพ์ไว้มาประกอบเพิ่ม เขาชี้ว่าคนส่วนใหญ่ใช้ Claude Code ผิดทาง เพราะยังเขียน prompt ใหม่ทุกครั้ง แทนที่จะยกระดับไปสู่การสร้าง skill ที่ใช้ซ้ำได้
จากที่ Austin Marchese นำเสนอ Anthropic engineers ทำงานต่างจากคนทั่วไปชัดเจนใน 4 ประเด็นหลัก ได้แก่ prompt skill ไม่ใช่ prompt Claude, มอง skill ว่าเป็นมากกว่า prompt, ออกแบบ skill ให้ประกอบกันได้ และทำให้ skill ฉลาดขึ้นทุกครั้งที่ใช้งาน บทความนี้สรุปและเรียบเรียงจากคลิปดังกล่าว เพื่อให้คนไทยที่ใช้ Claude Code เห็นภาพและนำไปปรับใช้ได้ทันที
1. กฎข้อที่ 1: prompt skill ไม่ใช่ prompt Claude
Austin Marchese ตั้งข้อสังเกตว่า ตอนเริ่มใช้ AI คนส่วนใหญ่มักเขียน prompt ใหม่ทุกครั้งสำหรับงานทุกแบบ ทั้งที่งานส่วนใหญ่ของคนคนหนึ่งเป็นงานซ้ำเดิม Anthropic engineers จึงสร้าง Claude skills ขึ้นมาเพื่อจัดการงานซ้ำเหล่านี้ engineer ของ Anthropic นิยามไว้ว่า "Skills are organized collections of files that package composable procedural knowledge for agents" แปลรวบรัดได้ว่า skill คือ folder ที่บรรจุวิธีทำงานเรื่องใดเรื่องหนึ่งให้ Claude หยิบไปใช้ได้
ในคลิปมีตัวอย่างที่จับต้องได้ของการเลิก prompt แบบเดิม ผู้ใช้ที่ต้องการให้ Claude ช่วยร่างอีเมลตอบกลับด้วย voice และสำนวนของตัวเอง ไม่จำเป็นต้องพิมพ์ prompt ยาวเหยียดทุกครั้ง แต่สร้าง skill ชื่อ /draft email เก็บไว้ แล้วเรียกใช้ด้วย slash command พร้อมแนบอีเมลต้นทางได้ Austin Marchese อธิบายการยกระดับนี้ด้วย diagram ของ Anthropic ที่แบ่งเป็น 3 ชั้น ชั้นล่างสุดคือตัว AI model, ชั้นกลางคือ AI agents และ prompts ซึ่งเป็นจุดที่คนส่วนใหญ่หยุดอยู่, ส่วนชั้นบนสุดคือ skill หรือ application layer ของโลก AI ถ้าเทียบกับมือถือ Anthropic เป็นผู้สร้างตัวเครื่อง ส่วนผู้ใช้มีหน้าที่สร้าง app ที่รันบนเครื่องนั้น และ skill ก็คือ app เหล่านั้น
Austin Marchese ย้ำว่ากุญแจของกฎข้อนี้ไม่ใช่เรื่องเทคนิค แต่เป็น mental shift จาก "เขียน prompt ใหม่ทุกครั้ง" ไปสู่ "เขียน prompt ที่ชี้ไปที่ skill ที่มีอยู่แล้ว" เมื่อตั้ง mindset แบบนี้ได้ คำถามจะเปลี่ยนจาก "พิมพ์อะไรลงไปดี" เป็น "งานนี้ควรกลายเป็น skill ตัวไหน" และถ้า label skill ไว้ดี Claude จะรู้เองโดยอัตโนมัติว่าควรเรียก skill ไหนมาใช้ โดยไม่ต้องระบุชื่ออย่างชัดเจน
2. กฎข้อที่ 2: skill ไม่ใช่แค่ prompt มี 3 ชั้น
เมื่อตัดสินใจว่าจะหันมาใช้ skill แล้ว ก้าวต่อไปคือการสร้าง skill ที่ใช้งานได้จริง Austin Marchese ชี้ว่าจุดที่คนส่วนใหญ่พลาด คือเข้าใจว่า skill เป็นแค่ prompt ที่บันทึกไว้ใน folder ทั้งที่ skill หนึ่งตัวมี 3 ชั้น และแต่ละชั้นมีบทบาทชัดเจน
ชั้นแรกคือ description เปรียบเหมือนชื่อบนปก folder Claude จะอ่าน description นี้ทุกครั้งที่ผู้ใช้ส่งคำถามเข้ามา เพื่อตัดสินใจว่าจะหยิบ skill ตัวนี้มาใช้หรือไม่ ถ้า label เขียนกำกวม โอกาสที่ Claude จะพลาดก็สูง แต่ถ้า label เฉพาะเจาะจง Claude จะเรียก skill ขึ้นมาเองได้ แม้ผู้ใช้ไม่ได้พิมพ์ชื่อ skill ตรง ๆ ก็ตาม
ชั้นที่สองคือ instructions เป็น playbook ที่ Claude อ่านตามขั้นตอนเมื่อหยิบ skill ขึ้นมาแล้ว ชั้นนี้คือคำสั่งทีละก้าวว่างานนั้นต้องทำอย่างไร เริ่มจากอะไร และจบที่อะไร ในคลิป Austin Marchese ระบุว่าคนส่วนใหญ่หยุดที่ชั้นนี้ และทุ่มเวลาส่วนใหญ่ไปกับการเขียน instructions ให้สวยงาม
ชั้นที่สามคือ tools ซึ่ง Austin Marchese ระบุว่าเป็นจุดที่ skill มี leverage จริง ๆ และเป็นชั้นที่คนส่วนใหญ่ข้ามไป tools ในที่นี้หมายถึง script, API call, reference file ที่ skill เรียกใช้ได้ Eric จากทีม Anthropic ที่ Austin Marchese อ้างถึงในคลิปบอกว่าสิ่งที่ตลกที่สุดที่เขาเห็น คือคนใส่ effort มหาศาลไปกับการเขียน prompt ให้สวยหรู แต่ tools ที่ส่งให้ model กลับ bare-bones ไม่มี documentation, parameter ตั้งชื่อเป็น A, B ซึ่ง engineer คนใดก็คงไม่อยากใช้ฟังก์ชันแบบนั้น
Austin Marchese ยกกรณีจากประสบการณ์ของตนเอง ตอนต้องเช็คชื่อโดเมนหลายตัวว่าซื้อได้หรือไม่ แทนที่จะถาม Claude ไปมา เขาสร้าง skill ที่มี script ตรวจสอบโดเมนแบบ programmatic ติดมาด้วย ทำให้รายชื่อโดเมนที่ Claude แนะนำผ่านการ verify มาตั้งแต่ต้น และยังเปิดทางให้ sub-agent หลายตัวใช้ skill เดียวกันกวาดโดเมนนับหมื่นตัวพร้อมกัน งานแบบนี้ทำไม่ได้ด้วยการพิมพ์ prompt มือเปล่า ข้อสรุปของกฎข้อนี้คือ Anthropic engineers ทุ่มเทกับการเขียน tools ที่ดี ขณะที่คนส่วนใหญ่ทุ่มเทกับการเขียน prompt ที่สวย
3. กฎข้อที่ 3: skill ต้อง composable ไม่ใช่ monolithic
เมื่อเข้าใจกายวิภาคของ skill แล้ว คำถามถัดมาคือควรสร้าง skill แบบไหน Austin Marchese ดึงข้อความจาก engineering blog ของ Anthropic มาตรง ๆ ว่า skill ที่ดีต้องมีคุณสมบัติ composable, portable, efficient และ powerful โดย composability หมายถึง skill หลายตัวทำงานร่วมกันได้ และ Claude เป็นผู้ประสานว่าเมื่อใดควรเรียก skill ตัวใด ในทางปฏิบัติ เราจึงควรมี skill เล็ก ๆ ที่โฟกัสเรื่องเดียวและนำกลับมาใช้ใหม่ได้ แทนที่จะมี skill ก้อนใหญ่ที่พยายามทำทุกอย่างในตัวเดียว
Austin Marchese เล่าประสบการณ์ตรงตอนเริ่มสร้าง skill สำหรับ content engine ของตน เขาเคยสร้าง skill ก้อนใหญ่ชื่อ /content creation ที่รวมการคิด idea, การเขียน script และการร่าง social post ไว้ทั้งหมดในตัวเดียว หนึ่ง skill แต่แบกความเป็นไปได้เป็นล้าน ผลคือมันกลายเป็น skill ที่จัดการไม่ได้ ทุกครั้งที่อยากเปลี่ยนวิธีเขียน script ก็ต้องไปแก้ทั้ง skill โดยไม่รู้ว่ากระทบส่วนไหนบ้าง สุดท้าย Austin Marchese แตก skill เดียวนั้นออกเป็น skill ที่โฟกัสเฉพาะเรื่อง เช่น YouTube idea research, YouTube script writer, LinkedIn post และให้ skill เหล่านี้เรียกหากันได้
ในคลิปสรุปประโยชน์ของการแตก skill ไว้ 3 ข้อ ข้อแรกคือหาต้นตอปัญหาได้ง่าย เมื่อ skill ที่โฟกัสเรื่องเดียวพัง ผู้ดูแลจะรู้ทันทีว่าจุดผิดอยู่ที่ไหน ต่างจาก skill ก้อนใหญ่ที่ทำให้ตามหาจุดพังได้ยาก ข้อที่สองคือการปรับปรุงแบบทบต้น เมื่ออัปเดต skill YouTube idea research ทุก workflow ที่เรียก skill นี้จะได้รับการอัปเกรดทันที แต่ skill ก้อนใหญ่มักมี functionality ซ้ำซ้อน แก้ในที่หนึ่งแล้วอีกที่ยังพังอยู่ ข้อที่สามคือ reuse ได้แทนที่จะสร้างใหม่ เช่น skill เช็คโดเมนที่เคยทำไว้สามารถ plug เข้า workflow ใดก็ได้ ไม่ต้องเริ่มจากศูนย์ทุกครั้งที่มี workflow ใหม่
นอกจากแนวคิดเรื่อง composability แล้ว Austin Marchese ยังยก pattern เชิงเทคนิคอีก 2 แบบที่ Anthropic engineers ใช้กัน
pattern แรกคือการบันทึก script ไว้ภายใน skill ในคลิป Barry จาก Anthropic เล่าว่าทีมสังเกตเห็น Claude เขียน Python script เดิม ๆ ซ้ำแล้วซ้ำเล่าเพื่อจัดสไตล์สไลด์ ทีมจึงให้ Claude บันทึก script นั้นไว้ใน skill เป็น tool สำหรับ Claude เวอร์ชันต่อ ๆ ไปของตัวเอง พอ session ถัดมา Claude ไม่ต้องเขียน script ใหม่ เพียงรัน script ที่มีอยู่แล้ว ผลลัพธ์จึงสม่ำเสมอและประหยัดทรัพยากร เหตุผลที่ pattern นี้ทรงพลังคือ code เป็น deterministic ถ้า input เดียวกันก็ให้ output เดียวกันเสมอ ขณะที่ AI ต้องตีความและเดาทุกครั้ง ซึ่งเปลือง token ที่ต้องจ่ายเงินจริง ๆ Austin Marchese สรุปเป็นกฎคร่าว ๆ ว่า ถ้าเรื่องใดทำด้วย code ได้ ให้ใช้ code ไม่ต้องใช้ AI และ code ก็ไม่จำเป็นต้องเขียนเอง ให้ AI เขียนครั้งเดียวแล้วเอามาใช้ซ้ำเท่าที่อยากใช้
pattern ที่สองคือการควบคุมว่าใครเรียก skill ได้ Austin Marchese ระบุว่า Anthropic สร้าง flag ไว้ 2 ตัวที่คนส่วนใหญ่ไม่รู้ ตัวแรกคือ user invocable ถ้าตั้งเป็น false skill จะถูกซ่อนจาก slash menu หมายความว่าผู้ใช้ทั่วไปเรียก skill ตัวนี้ตรง ๆ ไม่ได้ มีแต่ agent เท่านั้นที่เรียกได้ เหมาะกับ skill ที่เป็นเครื่องมือภายในของ agent และผู้ใช้ไม่ควรไปยุ่ง ตัวที่สองคือ disable model invocation ซึ่งทำงานกลับกัน คือเฉพาะผู้ใช้เท่านั้นที่เรียกได้ model เรียกไม่ได้ flag นี้เหมาะกับ skill ที่เสี่ยงสูง เช่น skill ที่ส่งข้อความออกไปจริง หรือ deploy code ขึ้น production การมี flag เหล่านี้ในคลังช่วยให้การออกแบบ skill รัดกุมขึ้นมาก
4. กฎข้อที่ 4: skill ฉลาดขึ้นทุก session
กฎข้อสุดท้ายที่ Austin Marchese ระบุว่าเป็นจุดที่ Anthropic engineers ทิ้งห่างคนทั่วไป คือ skill ของพวกเขาไม่ได้แค่ใช้งานได้ แต่เก่งขึ้นทุกครั้งที่ใช้ Austin Marchese อธิบายว่า ถ้า prompt Claude ด้วยประโยคเดียว ประโยคนั้นจะหายไปทันทีที่ปิดหน้าต่างแชต แต่ถ้า prompt ผ่าน skill ตัว skill จะคงอยู่ และทุกครั้งที่เรียกใช้ก็เป็นโอกาสให้ขัดเกลา skill ให้คมขึ้น
ในคลิป Austin Marchese อ้างคำพูดของ engineer ของ Anthropic ที่ระบุว่า เมื่อใช้ Claude ครั้งแรก รูปแบบมาตรฐานที่ Claude จดบันทึกไว้จะช่วยให้สิ่งที่ Claude เขียนลงไปนำกลับมาใช้ได้อย่างมีประสิทธิภาพโดย Claude เวอร์ชันถัดไปของตัวเอง เป้าหมายของ Anthropic คือ Claude ที่ใช้งานร่วมกับผู้ใช้มา 30 วันต้องดีกว่า Claude วันแรกอย่างชัดเจน ทุกครั้งที่ Claude เรียนรู้เรื่อง voice, process, edge case ของผู้ใช้ Claude จะบันทึกข้อมูลเหล่านั้นลงใน skill เพื่อให้ session ถัดไปเริ่มต้นด้วยความฉลาดที่สูงกว่าครั้งก่อน
วิธีลงมือทำตามที่ Austin Marchese แนะนำ คือทุกครั้งที่รัน skill แล้วผลลัพธ์ไม่ตรงใจ ให้ถามตัวเองด้วยคำถามเดียวว่า จุดที่ต้องแก้นี้เป็น "การแก้ครั้งเดียวจบ" หรือ "สิ่งที่ควรอยู่ใน skill ตลอดไป" ถ้าเป็นแบบหลัง ก็อัปเดต skill โดยใส่ rule, ตัวอย่าง และ edge case ลงไป จุดที่คนส่วนใหญ่ทำผิดคือรัน skill ได้ output แล้วก็เลิกราโดยไม่เก็บบทเรียน Anthropic engineers ทำตรงข้าม คือใช้ skill, ได้ output, แล้วอัปเดต skill จนเกิดเป็น compounding loop ที่ปรับปรุงตลอดเวลา
เคล็ดลับจาก Austin Marchese คือไม่ต้องเขียนการอัปเดต skill ด้วยตัวเอง ให้ใช้ chat history ของ session ที่เพิ่งใช้ skill เป็น reference แล้วสั่ง Claude ว่า "Review the back and forth I just had after using this skill. Can we enhance the skill so this is handled automatically or we don't make the same mistake again?" Claude จะวิเคราะห์ session แล้วเสนอการอัปเดต skill ให้เอง การปิด loop แบบนี้ทำให้ skill ที่ดูธรรมดาในวันแรก กลายเป็น skill ที่ทรงพลังในวันที่ 30 ของการใช้งาน
5. สิ่งที่นำไปใช้ได้ทันที
Austin Marchese สรุปทั้ง 4 ข้อไว้สั้น ๆ ตอนปิดคลิปว่า ใช้ skill แทน prompt, สร้าง tools ไม่ใช่หยุดแค่ skill ที่มี prompt, ออกแบบ skill ให้ composable ไม่ใช่ custom monolith, และอัปเดต skill ทุกครั้งที่ใช้ การใช้ Claude แบบ engineer ไม่จำเป็นต้องซับซ้อนเสมอไป
สำหรับผู้ใช้ Claude Code ในไทยที่อยากลงมือทันที ลำดับที่เหมาะคือเริ่มจากกฎข้อที่ 1 ก่อน ลองลิสต์งานซ้ำที่ทำในรอบสัปดาห์ที่ผ่านมา แล้วเลือก 1-2 งานมาแปลงเป็น skill ตัวแรก เช่น skill สำหรับร่างอีเมล, skill สำหรับสรุปประชุม, skill สำหรับสร้าง release note จากนั้นค่อยขยับไปกฎข้อที่ 2 โดยเพิ่ม tool layer ให้ skill เหล่านั้น เช่น แนบ script ตรวจ format หรือ reference file ที่เก็บรูปแบบเฉพาะของทีม กฎข้อที่ 3 และ 4 จะเข้ามาเมื่อ skill เริ่มมีจำนวนมากขึ้นและต้องจัดระเบียบ การแยก skill ใหญ่ออกเป็นชิ้นเล็กที่เรียกหากันได้ และการปิด loop อัปเดต skill หลังใช้งานทุกครั้ง จะทำให้ระบบงานของผู้ใช้ค่อย ๆ ฉลาดขึ้นโดยอัตโนมัติ
ที่มา: Austin Marchese: How Anthropic Engineers ACTUALLY Prompt Claude Code (YouTube, 2026-05-15)
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกที่แสดงความเห็น!