กฎวิศวกรรมบริบทใหม่สำหรับโมเดล Claude 5

• ใน Claude Opus 5 และ Claude Fable 5 แม้จะ ลด system prompt ของ Claude Code ลงมากกว่า 80% ก็ไม่พบว่าประสิทธิภาพในการประเมินงานเขียนโค้ดลดลงในระดับที่วัดได้
• กฎละเอียดที่เคยใช้ป้องกันกรณีเลวร้ายที่สุดของโมเดลรุ่นก่อนอาจขัดแย้งกันระหว่าง system prompt, Skills, CLAUDE.md และคำขอของผู้ใช้ ดังนั้นสำหรับโมเดลล่าสุด การให้ใช้ บริบทแวดล้อมและดุลยพินิจของตัวเอง จะดีกว่า
• แทนที่จะให้คำสั่งและตัวอย่างเครื่องมือทั้งหมดไว้ล่วงหน้า ให้ใช้ progressive disclosure หรือการค่อย ๆ เปิดเผยข้อมูล โดยออกแบบอินเทอร์เฟซที่สื่อความหมายได้ดี และเรียกข้อมูลหรือเครื่องมือเมื่อจำเป็น
• แนะนำให้บันทึกเฉพาะจุดที่เป็นกับดักของ repository ไว้อย่างกระชับใน CLAUDE.md แยกคำสั่งยาว ๆ ไปไว้ใน Skills และใช้ เอกสารอ้างอิงที่หลากหลาย เช่น สเปก ชุดทดสอบ โมเดล HTML โค้ด และ rubric เกณฑ์ประเมิน
• สามารถใช้ /doctor และ claude doctor เพื่อปรับขนาดของ Skills และ CLAUDE.md ได้ และควรจัดบริบทสำหรับโมเดลล่าสุดให้ ลดการย้ำซ้ำและข้อจำกัดที่มากเกินไป พร้อมให้ค้นหาข้อมูลที่เกี่ยวข้องเมื่อจำเป็น

---

วิศวกรรมบริบทที่ไปไกลกว่า prompt

• เมื่อ Claude ประมวลผลข้อความ prompt ของผู้ใช้เป็นเพียงส่วนหนึ่งของบริบททั้งหมด ส่วนที่เหลือถูกประกอบขึ้นจาก system prompt, Skills, CLAUDE.md, memory และอื่น ๆ
• วิศวกรรมบริบท ถูกใช้ร่วมกันกับหลายคำขอ จึงเขียนให้เฉพาะเจาะจงเหมือน prompt รายครั้งได้ยาก แต่มีผลอย่างมากต่อผลลัพธ์ของ Claude Code และ agent ที่สร้างเอง
• ต้องออกแบบ prompt และคำสั่งทั่วไปโดยที่ยังไม่รู้คำขอของผู้ใช้ล่วงหน้า และเมื่อความสามารถของ Claude พัฒนาขึ้น วิธีที่เหมาะสมก็เปลี่ยนไปด้วย
• ใน Claude Opus 5 และ Claude Fable 5 แม้จะ ลบ system prompt ของ Claude Code ออกมากกว่า 80% ก็ไม่พบว่าประสิทธิภาพในการประเมินงานเขียนโค้ดลดลงในระดับที่วัดได้
• แนวปฏิบัติที่ดีนี้ถูกนำไปสะท้อนใน claude doctor แล้ว และใน Claude Code สามารถใช้ /doctor เพื่อปรับ Skills และ CLAUDE.md ให้มีขนาดเหมาะสมได้

ปลดโมเดลออกจากข้อจำกัดที่มากเกินไป

• Claude Code เดิมถูก จำกัดมากเกินไป ไม่ใช่แค่ใน system prompt แต่รวมถึง CLAUDE.md และ Skills ด้วย
  • ในคำขอเดียวกัน คำสั่งอย่าง “ให้ทิ้งเอกสารที่เหมาะสมไว้” กับ “อย่าเพิ่มคอมเมนต์” อาจขัดแย้งกันผ่าน system prompt, Skills และคำขอของผู้ใช้
  • แม้ Claude จะตีความเจตนาของผู้ใช้ได้ แต่เพราะคำสั่งที่ซ้ำซ้อนหรือขัดแย้งกัน จึงต้องคิดอย่างระมัดระวังมากขึ้นก่อนตัดสินใจว่าจะทำอย่างไร
• ในอดีตข้อจำกัดเหล่านี้จำเป็นเพื่อหลีกเลี่ยงสถานการณ์เลวร้ายที่สุด แต่โมเดลล่าสุดสามารถลบข้อจำกัดจำนวนมากออก และให้ใช้ บริบทแวดล้อมกับดุลยพินิจของตัวเอง ได้
• เครื่องมือที่ Claude Code ใช้ได้ก็เพิ่มขึ้นเช่นกัน
  • ในอดีต CLAUDE.md เป็นแหล่งหลักสำหรับเก็บ memory ข้อมูล และคำสั่ง
  • ปัจจุบันสามารถเรียกและแชร์บริบทระหว่าง session ได้ผ่าน memory, artifacts และ Skills

ใช้การตัดสินตามบริบทแทนกฎตายตัว

• Claude Code รุ่นแรกใส่คำสั่งที่เข้มงวดซึ่งไม่ได้เหมาะเสมอไป เพื่อป้องกันกรณีเลวร้ายที่สุด เช่น การลบไฟล์
• system prompt รุ่นก่อนกำหนดว่าโดยค่าเริ่มต้นไม่ให้เขียนคอมเมนต์ในโค้ด ห้าม docstring หลายย่อหน้าหรือคอมเมนต์หลายบรรทัด และหากผู้ใช้ไม่ได้ขอ ก็ไม่ให้สร้างเอกสารแผน การตัดสินใจ หรือการวิเคราะห์
• กฎเหล่านี้อาจไม่เหมาะกับบางคำขอ
  • ผู้ใช้อาจมีความชอบด้านเอกสารประกอบที่ต่างออกไป
  • โค้ดซับซ้อนบางส่วนอาจจำเป็นต้องมี คอมเมนต์หลายบรรทัด
• โมเดลรุ่นเก่ามักเขียนคอมเมนต์ผิดพลาดหากไม่มี guardrail จึงต้องมีการประนีประนอมแบบนี้ แต่โมเดลล่าสุดจัดการการตัดสินใจที่เกี่ยวข้องได้ดีขึ้นแม้ไม่มี rule ที่ชัดเจน
• system prompt ใหม่ใช้ คำสั่งแบบอิงบริบท เช่น “เขียนโค้ดให้อ่านเหมือนโค้ดรอบ ๆ ปรับความหนาแน่นของคอมเมนต์ การตั้งชื่อ และสำนวนให้เข้ากัน”

ออกแบบอินเทอร์เฟซที่สื่อความหมายได้ดีมากกว่าการให้ตัวอย่าง

• กฎสำคัญของการใช้เครื่องมือในอดีตคือการให้ ตัวอย่างการใช้งาน แก่ Claude
• สำหรับโมเดลล่าสุด ตัวอย่างอาจจำกัดขอบเขตการสำรวจไปยังพื้นที่หนึ่ง ๆ ดังนั้นควรให้ความสำคัญกับอินเทอร์เฟซของเครื่องมือ สคริปต์ และไฟล์ รวมถึงความสามารถในการสื่อความหมายของพารามิเตอร์ก่อน
• หากกำหนด status ของเครื่องมือ Todo เป็น enum ได้แก่ pending, in_progress, completed ก็สามารถบอกวิธีใช้งานได้อย่างเป็นธรรมชาติ
• คำสั่งให้คงไว้เพียงหนึ่งรายการเป็น in_progress เป็นการระบุพฤติกรรมที่ต้องการในระดับอินเทอร์เฟซ

เปิดข้อมูลเมื่อถึงเวลาที่จำเป็นด้วย progressive disclosure

• ในช่วงแรกที่ Claude Code มุ่งเน้นงานเขียนโค้ด ได้ใส่วิธีตรวจทานและตรวจสอบโค้ดไว้อย่างละเอียดใน system prompt
• ข้อมูลเหล่านี้ไม่ได้จำเป็นเสมอไป แต่สำคัญสำหรับงานบางประเภท
• ปัจจุบันสามารถใช้ progressive disclosure เพื่อเรียกบริบทที่เหมาะสมในเวลาที่จำเป็นได้
  • ย้ายคำสั่งด้านการตรวจสอบและการรีวิวโค้ดไปเป็น Skill แยกกัน ให้ Claude Code เรียกใช้แบบเลือกได้
  • เครื่องมือบางส่วนโหลดแบบหน่วงเวลา และก่อนใช้ agent ต้องค้นหาคำจำกัดความทั้งหมดด้วย ToolSearch
  • สามารถให้เครื่องมือจำนวนมาก เช่น Task tool โดยไม่กินพื้นที่บริบทก่อนจำเป็นต้องใช้
• ไม่จำเป็นต้องทำให้ CLAUDE.md และ Skill.md เป็นคลังกลางของแนวปฏิบัติทั้งหมดที่เป็นไปได้
• แต่สามารถจัดเป็น file tree ที่เรียกใช้เมื่อจำเป็นแทน แนวทางนี้ถูกกล่าวถึงใน harness เวิร์กโฟลว์แบบไดนามิกสำหรับแต่ละงาน ด้วย

รวมคำสั่งที่ซ้ำกันให้เป็นคำอธิบายเครื่องมือแบบเรียบง่าย

• โมเดล Claude รุ่นก่อนบางครั้งต้องย้ำคำสั่งเดียวกัน และมักทำตามคำสั่งช่วงท้ายของบริบทได้ดีกว่าช่วงต้น
• ด้วยเหตุนี้จึงใส่คำสั่งหรือตัวอย่างการใช้เครื่องมือเดียวกันไว้ทั้งในเนื้อหา system prompt และคำอธิบายเครื่องมือ
• สำหรับโมเดลล่าสุด สามารถลบตัวอย่างที่ซ้ำกันออก และ วางวิธีใช้เครื่องมือไว้เฉพาะในคำอธิบายเครื่องมือ ได้

เปลี่ยนจาก CLAUDE.md ไปสู่ memory อัตโนมัติ

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

เอกสารอ้างอิงที่หลากหลายมากกว่าสเปกแบบง่าย

• Claude Code ใน plan mode เคยพึ่งพาไฟล์แผน Markdown อย่างมากเพื่อใช้อ้างอิงซ้ำเมื่อจำเป็น และในโปรเจกต์ระยะยาวก็เคยเก็บสเปกไว้ใน codebase ด้วย
• Claude รุ่นล่าสุดสามารถจัดการ เอกสารอ้างอิง ในรูปแบบที่ซับซ้อนขึ้นได้
  • HTML artifact ที่สร้างด้วยฟีเจอร์ artifacts ใหม่
  • โค้ด เช่น ฟังก์ชันที่จะย้ายมาจาก codebase อื่น
  • สเปกที่แสดงผ่านชุดทดสอบอย่างละเอียด
• rubric เกณฑ์ประเมินเป็นรูปแบบอ้างอิงอีกแบบหนึ่งที่ให้ Claude ทดลองและตรวจสอบรสนิยมหรือมาตรฐานคุณภาพเฉพาะด้านได้
  • สามารถกำหนดเกณฑ์ เช่น API design ที่ดีคืออะไร
  • สามารถสร้าง validation agent ที่ใช้ rubric ดังกล่าวผ่าน dynamic workflow ได้

บทบาทขององค์ประกอบบริบทแต่ละส่วน

• System prompt

  • เชื่อมโยงอย่างใกล้ชิดกับบริบทของผลิตภัณฑ์ และบอก Claude ว่ากำลังทำงานอะไรอยู่ภายในผลิตภัณฑ์ใด
  • ผู้ใช้ Claude Code แทบไม่ต้องแก้ไขส่วนนี้ แต่ถ้าสร้าง agent harness ของตัวเอง ก็เป็นพื้นที่ที่ควรใช้เวลาอย่างมาก

• CLAUDE.md

  • ควรรักษาให้เบาและอธิบายวัตถุประสงค์ของ repository อย่างสั้น ๆ แต่ควรใช้ token ส่วนใหญ่เพื่อบันทึก กับดักที่ต้องระวัง ใน codebase
  • กฎของ repository ที่ให้เก็บ type ทั้งหมดไว้ในไฟล์เดียวเท่านั้น เป็นสิ่งที่ควรบันทึก
  • ควรหลีกเลี่ยงข้อมูลที่ชัดเจนอยู่แล้วซึ่ง Claude รู้ได้จากการดู file system หรือ repository
  • หากการตรวจสอบงานมีคำสั่งเฉพาะหลายข้อ ให้สร้าง validation Skill แล้วอ้างอิงจาก CLAUDE.md เพื่อใช้ progressive disclosure

• Skills

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

• เอกสารอ้างอิง

  • เมื่อ mention ไฟล์ด้วย @ Claude จะตรวจสอบรายละเอียดที่เกี่ยวข้องกับแผนปัจจุบันได้
  • ไฟล์สเปก โมเดล และ codebase ทั้งหมดก็เป็นเอกสารอ้างอิงได้
  • โดยทั่วไปควรให้ความสำคัญกับ ไฟล์ในรูปแบบโค้ด เพราะโค้ดให้คำสั่งที่ชัดเจนและครบถ้วนในภาษาที่ Claude คุ้นเคยดี
  • โดยทั่วไป HTML design mockup ให้ผลลัพธ์ดีกว่าคำอธิบายดีไซน์หรือ screenshot

ทำให้บริบทเดิมเรียบง่ายขึ้น

• ควรลบกฎ การย้ำซ้ำ และข้อมูลที่ไม่จำเป็นออกจาก system prompt, Skills และ CLAUDE.md โดยรวม เพื่อ ทำให้บริบทเรียบง่ายขึ้น
• คำสั่ง claude doctor ช่วยสนับสนุนงานลดความซับซ้อนนี้โดยอัตโนมัติ
• สามารถอ่านวิธีเขียน prompt สำหรับโมเดลขั้นสูงเพิ่มเติมได้ใน คู่มือภาคสนาม Claude Fable