Anthropic ตัด system prompt ของ Claude Code ทิ้งกว่า 80% — กติกาใหม่ของ context engineering ยุคโมเดล Claude 5

วันที่ 24 ก.ค. 2026 Anthropic เผยแพร่บทความวิศวกรรมชื่อ “The new rules of context engineering for Claude 5 generation models” เขียนโดย Thariq Shihipar (Member of Technical Staff) ที่เปิดตัวเลขซึ่งน่าจะทำให้หลายทีมต้องกลับไปรื้อ prompt ของตัวเอง: ทีม Claude Code ตัด system prompt ออกไปมากกว่า 80% สำหรับโมเดลรุ่นใหม่อย่าง Claude Opus 5 และ Claude Fable 5 แล้วพบว่าคุณภาพงาน ไม่ได้แย่ลง

ประเด็นไม่ใช่ “prompt สั้นดีกว่ายาว” แบบกำปั้นทุบดิน แต่คือ สิ่งที่เคยต้องเขียนกำกับไว้ กลายเป็นสิ่งที่โมเดลรุ่นใหม่ทำได้เองอยู่แล้ว — และการยังเขียนกำกับต่อไป กลับกลายเป็นการ “จำกัด” โมเดลมากกว่าจะช่วย นี่คือการเปลี่ยนโหมดจากยุคที่เราต้องเขียนกฎเยอะ ๆ กันโมเดลทำพลาด มาเป็นยุคที่เราต้องออกแบบ สภาพแวดล้อมและเครื่องมือ ให้โมเดลตัดสินใจเอง

กติกาใหม่ 6 ข้อ — “แล้ว” กับ “ตอนนี้”

บทความวางกรอบเป็นคู่เปรียบเทียบระหว่างวิธีเดิมกับวิธีที่ได้ผลกับโมเดลรุ่น Claude 5:

• ให้ judgment แทนกฎตายตัว (Judgment over rules) — ตัวอย่างที่ชัดที่สุดคือ Claude Code เปลี่ยนจากคำสั่งแบบ “ห้ามเขียน docstring หลายย่อหน้าเด็ดขาด” มาเป็น “เขียนโค้ดให้เข้ากับสไตล์ของโค้ดรอบข้าง” ปล่อยให้โมเดลอ่านบริบทแล้วตัดสินเอง แทนที่จะยัดกฎซึ่งจะผิดในบางกรณีเสมอ
• ออกแบบ interface แทนการใส่ตัวอย่าง (Interface design over examples) — การใส่ตัวอย่างการเรียกเครื่องมือเยอะ ๆ ตอนนี้กลับ บีบพื้นที่สำรวจ ของโมเดล สิ่งที่ให้ผลดีกว่าคือออกแบบพารามิเตอร์และหน้าตาของ tool ให้ชัดจนโมเดลเดาวิธีใช้ถูกเอง
• Progressive disclosure แทนการเทข้อมูลหมดหน้าตัก — ย้ายรายละเอียดเชิงลึกออกจาก system prompt ไปไว้ใน Skills ที่โหลดเฉพาะตอนต้องใช้ แทนที่จะแบกคอนเท็กซ์ทั้งก้อนไปทุกเทิร์น
• อธิบายที่ tool description แทนการพูดซ้ำ — คำสั่งที่ซ้ำกันระหว่าง system prompt กับ tool definition ถูกตัดออก เหลือแหล่งความจริงเดียว
• Auto-memory แทนการสั่งให้จำเอง — โมเดลเก็บความจำที่เกี่ยวข้องเองอัตโนมัติ แทนที่จะต้องคอยอัปเดต CLAUDE.md ด้วยมือ
• Reference ที่รวยข้อมูล แทน spec แห้ง ๆ (Rich references over simple specs) — HTML artifact, โค้ดตัวอย่างจริง, และ rubric ใช้กำกับงานได้ดีกว่าการเขียนสเปกเป็น markdown เปล่า ๆ

แล้วควรเขียน CLAUDE.md และ Skills ยังไง

คำแนะนำเชิงปฏิบัติจากบทความสรุปได้ประมาณนี้:

• CLAUDE.md ควรบางที่สุดเท่าที่จะทำได้ เก็บเฉพาะ “กับดักเฉพาะของ repo นี้” (repository-specific gotchas) — อะไรที่โมเดลเดาเองได้ ไม่ต้องเขียน
• ย้ายความเห็นและ best practice ของทีมไปไว้ใน Skills แล้วทำ progressive disclosure ด้วยการแตกเป็นหลายไฟล์ที่ลิงก์ถึงกัน ไม่ใช่ไฟล์เดียวยาวเป็นพรืด
• อ้างไฟล์ด้วย @ mention เมื่อต้องการสเปกฉบับเต็ม แทนการก็อปสเปกมาแปะใน prompt
• อ้างโค้ดดีกว่าบรรยาย — ชี้ไปที่ไฟล์ที่ทำถูกแล้ว ได้ผลกว่าการพยายามอธิบายเป็นภาษาคน
• ฝั่งเครื่องมือ Claude Code มีคำสั่ง /doctor ไว้ช่วย “rightsize” ไฟล์ Skills และ CLAUDE.md ที่บวมเกินจำเป็น

บทความยังพูดถึงกลไกที่รับลูกแนวคิดนี้โดยตรง เช่น ToolSearch ที่โหลดสคีมาของ tool เฉพาะเมื่อจำเป็น (แทนที่จะยัดทุก tool ไว้ตั้งแต่ต้น), การใช้ HTML mockup เป็น reference แทนคำบรรยาย UI, และการใช้ verifier agent พร้อม rubric คุมคุณภาพงาน

ทำไมเรื่องนี้ใหญ่กว่าที่เห็น

ตัวเลข “ตัดทิ้ง 80%” มีนัยเชิงต้นทุนตรง ๆ: system prompt คือโทเคนที่คุณจ่ายทุกเทิร์นของทุก session ถ้าทีมคุณรัน agent เป็นแสนครั้งต่อเดือน การรีดคอนเท็กซ์ที่ไม่จำเป็นออกคือการลดบิลจริง ๆ ไม่ใช่การจูนเพื่อความสวยงาม

แต่ผลที่ลึกกว่านั้นคือเรื่อง ความสามารถ — บทความชี้ว่าคำสั่งที่มากเกินไปทำให้โมเดลรุ่นใหม่ “ทำงานได้แย่ลง” เพราะถูกล็อกให้เดินตามกฎที่เขียนไว้ตอนโมเดลยังไม่เก่งพอ นี่คือหนี้ทางเทคนิคชนิดใหม่: prompt debt — กฎที่เคยจำเป็นเมื่อหกเดือนก่อน แต่วันนี้กลายเป็นตัวถ่วง และแทบไม่มีทีมไหนมีกระบวนการ “ล้าง” มันเป็นระบบ

มุมมอง AI Curator

สิ่งที่บทความนี้บอกกลาย ๆ คือ ทักษะ prompt engineering แบบเขียนกฎยาว ๆ กำลังเสื่อมค่าเร็วมาก สิ่งที่มาแทนคือทักษะที่ใกล้กับงานสถาปัตยกรรมซอฟต์แวร์มากกว่า — ออกแบบ tool interface ให้ดี, จัดโครงสร้างเอกสารให้โหลดเป็นชั้น ๆ, และรู้ว่าอะไรควรเป็น “ความรู้ที่โหลดเมื่อต้องใช้” ไม่ใช่ “ความรู้ที่แบกไปทุกเทิร์น” ทีมไทยที่ลงแรงสะสม prompt playbook ยาว ๆ ไว้ตั้งแต่ยุค Claude 3/4 ควรตั้งงบเวลาไว้รื้อ อย่างน้อยทุกครั้งที่เปลี่ยนรุ่นโมเดลหลัก

ข้อควรระวังที่บทความไม่ได้เน้นแต่สำคัญกับบ้านเรา: กติกานี้ผูกกับโมเดลรุ่นบนสุด ทีมจำนวนมากในไทยและ SEA ยังรันงาน production ด้วยโมเดลเล็กกว่า (Sonnet, Haiku, หรือโมเดลโอเพนเวตอย่าง Qwen/GLM/Kimi) ด้วยเหตุผลด้านต้นทุน — และกับโมเดลเหล่านั้น การ “ตัดกฎออก 80%” อาจทำให้คุณภาพร่วงทันที ทางที่ปลอดภัยคือ วัดก่อนตัด: ทำ eval ชุดเล็ก ๆ ของงานจริง แล้วลองลอกกฎออกทีละชั้นเทียบผล ไม่ใช่ลบทิ้งเพราะบล็อกของ Anthropic บอกให้ลบ

อีกมุมที่น่าคิดคือ Skills กำลังกลายเป็นหน่วยของ “ความรู้องค์กร” อย่างเป็นทางการ เมื่อ system prompt บางลงและ Skills หนาขึ้น สิ่งที่เคยเป็นความรู้ในหัวของ senior engineer จะถูกเขียนลงเป็นไฟล์ที่ agent โหลดเองได้ — นั่นแปลว่าการลงทุนเขียน Skills ให้ดีวันนี้ ให้ผลตอบแทนข้ามรุ่นโมเดล ต่างจาก prompt ที่ต้องเขียนใหม่ทุกครั้งที่โมเดลอัปเกรด สำหรับทีมที่ทรัพยากรจำกัด นี่คือจุดที่ควรลงแรงก่อน

แหล่งข่าว

• The new rules of context engineering for Claude 5 generation models — Anthropic Engineering Blog (24 ก.ค. 2026)
• Introducing Claude Opus 5 — Anthropic (24 ก.ค. 2026)