หลัง Opus 5 ออกได้เพียงวันเดียว Boris Cherny คนสร้าง Claude Code ก็ขึ้นเวที YC Startup School 2026 ให้ Diana Hu จาก Y Combinator สัมภาษณ์ บนเวทีนั้นเขาเล่าว่า เมื่อเปลี่ยนมาใช้โมเดลรุ่นนี้ ทีมเพิ่งลบ system prompt ของ Claude Code ทิ้งไปเกิน 80% เหตุผลสั้น ๆ คือ ข้อความเหล่านั้นเอาไว้กำกับสิ่งที่ Opus 5 ทำถูกอยู่แล้วโดยไม่ต้องบอก

นี่ไม่ใช่ครั้งแรกที่ทีมทำแบบนี้ Boris บอกว่าเมื่อ Anthropic ปล่อยโมเดลที่เก่งขึ้น ทีม Claude Code จะกลับมาลบและเขียนทั้ง system prompt ชุด tool และ prompt ของ tool แต่ละตัวใหม่เสมอ การลบจึงเป็นงานประจำทุกครั้งที่เปลี่ยนรุ่นโมเดล ไม่ใช่ทำครั้งเดียวแล้วจบ นั่นหมายความว่า กฎที่ค่อย ๆ สะสมอยู่ในแต่ละโปรเจกต์ก็มีอายุเท่ากับโมเดลรุ่นที่เป็นเหตุให้ต้องเขียนกฎนั้นขึ้นมา

ทำไมลบแล้วโมเดลถึงทำงานได้ดีขึ้น

บรรทัดเหล่านี้ล้วนมีที่มา Boris อธิบายว่า ข้อความจำนวนมากใน system prompt เขียนขึ้นเมื่อโมเดลยังพลาดในเรื่องที่ควรทำได้เอง คนเขียนจึงต้องใส่คำสั่งกำกับไว้ ต่อมาโมเดลรุ่นใหม่ทำเรื่องนั้นได้เอง แต่คำสั่งเดิมยังไม่หายไป สุดท้ายจึงกลายเป็นการสอนเรื่องที่โมเดลทำได้ดีกว่าคนเขียนเสียอีก

Anthropic ทดลองวัดผลเรื่องนี้โดยตรง Boris เผยว่า Claude Code มีความสามารถหนึ่งที่ไม่ได้เขียนไว้ในเอกสาร เพียงตั้งค่า environment variable ตัวหนึ่ง โปรแกรมก็จะถอดทั้ง system prompt และ prompt ของ tool ออกทั้งหมด ทีมใช้วิธีนี้ทำ ablation โดยเริ่มจากถอดออกให้หมด แล้ววัดว่า prompt ที่เขียนไว้แต่ละส่วนยังช่วยอะไรจริงหรือไม่ ผลที่ได้คือ เมื่อเอาข้อความส่วนเกินเหล่านั้นออก โมเดลฉลาดขึ้นเล็กน้อย

อย่างไรก็ตาม Boris แบ่งเส้นไว้ชัดว่า ข้อสรุปไม่ใช่ยิ่งมีข้อความน้อยเท่าไรก็ยิ่งดี ในมุมของ product เขายังอยากใส่ข้อความบางส่วนกลับเข้าไป เพราะข้อความเหล่านั้นกำหนดว่า Claude Code ควรทำงานแบบไหนให้กับคนที่ใช้งานทุกวัน ข้อความส่วนที่เปิดทางให้โมเดลคิดเองได้อิสระขึ้น กับส่วนที่ทำให้ product ทำงานได้อย่างคงเส้นคงวา จึงทำหน้าที่คนละอย่างกัน เวลาตัดต้องรู้ว่ากำลังตัดส่วนไหน

สิ่งที่ยังเหลืออยู่หลังตัดมาหลายรอบช่วยให้เห็นเส้นแบ่งนี้ชัดขึ้น Boris บอกว่า ทุกวันนี้โค้ดใน harness ของ Claude Code ส่วนใหญ่ดูแลเรื่อง safety การจัดการ permission และ static analysis รวมถึงโค้ดฝั่ง UI ส่วนโค้ดที่เคยใช้ประคองความสามารถของโมเดลก็ค่อย ๆ หายไปในแต่ละรอบ

ลูปที่เอาไปทำกับ CLAUDE.md ของตัวเองได้

Boris ไม่ได้จำกัดคำแนะนำนี้ไว้แค่ทีมตัวเอง แต่แนะนำให้คนที่ใช้ Claude Code ลบ CLAUDE.md skills และ hooks ของตัวเองทิ้งราวทุกหกเดือน เพื่อดูว่าเมื่อไม่มีสิ่งเหล่านี้คอยกำกับ โมเดลทำอะไรเองได้บ้าง และเขาบอกให้ลองกับ Opus 5 ได้ตั้งแต่ตอนนี้

หลังตัดของเดิมออก เขาสร้าง prompt ขึ้นมาใหม่ตามลำดับสี่ขั้น

1. ลบคำสั่งเดิมออกก่อน
2. เอาโมเดลไปใช้งานจริง โดยไม่เดาล่วงหน้าว่าจะต้องกำกับอะไร
3. ดูว่าสะดุดหรือทำพลาดซ้ำ ๆ ที่จุดไหน
4. เติมคำสั่งกลับเข้าไปเฉพาะจุดที่พลาดซ้ำ

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

eval ต้องเก็บสะสม ไม่ใช่ลบตามรอบโมเดล

ไม่ใช่ทุกอย่างในโปรเจกต์ที่ควรลบทิ้งเมื่อโมเดลเปลี่ยนรุ่น Boris แยกชุด eval ไว้เป็นข้อยกเว้นชัดเจน ทีมเก็บชุดเดิมไว้พร้อมกับเขียนเพิ่มต่อเนื่องข้ามรุ่น เพราะต้องใช้มันวัดว่าการตัดแต่ละครั้งทำให้ผลดีขึ้นหรือแย่ลง

ถึงอย่างนั้น eval แต่ละชุดก็มีอายุ Boris ประเมินว่าอยู่ได้ราวหนึ่งถึงสามรุ่นโมเดล เมื่อโมเดลทำโจทย์ในชุดนั้นได้หมด eval ก็ใช้วัดความสามารถของโมเดลไม่ได้อีกต่อไป ทีมจึงปลดชุดเดิมแล้วเขียนชุดใหม่ โดยเริ่มจากจุดที่โมเดลรุ่นปัจจุบันยังทำได้ไม่ดี

เส้นแบ่งจึงอยู่ตรงนี้ คำสั่งกำกับพฤติกรรมมีอายุสั้นและควรลบบ่อย ส่วนเครื่องมือที่ใช้วัดความสามารถของโมเดลต้องมีอยู่เสมอ แต่โจทย์ข้างในต้องยากขึ้นให้ทันความสามารถของโมเดลแต่ละรุ่น

แล้วเอาอะไรไปแทนกฎที่ลบทิ้ง

พอลบกฎเดิมออก คำถามต่อมาคือควรสั่งงานอย่างไร Boris บอกว่าความผิดพลาดที่พบบ่อยคือการแจกแจงทุกขั้นอย่างละเอียดว่า "ทำอันนี้ แล้วทำอันนี้ แล้วทำอันนี้" วิธีนี้เคยจำเป็นสำหรับโมเดลรุ่นเก่า แต่ใช้กับโมเดลรุ่นนี้ไม่ได้ผลแล้ว

เขาแนะนำให้เปลี่ยนมาให้โจทย์ที่ยากกว่าระดับที่คิดว่าโมเดลทำไหวเล็กน้อย อธิบายภาพรวมของงาน guardrail และเงื่อนไขว่างานเสร็จเมื่อไร จากนั้นปล่อยให้โมเดลลงมือทำ ในมุมของเขา ทักษะสำคัญตอนนี้กำลังขยับจาก prompt engineering ไปอยู่ที่การตั้งโจทย์แบบนั้น กับการทำให้ Claude ตรวจงานของตัวเองระหว่างทางได้ ซึ่งเขาบอกว่าน่าจะเป็นสิ่งสำคัญที่สุดที่คนยังทำกันไม่ถูก

ขอบเขตของคำแนะนำนี้

Boris พูดบนเวทีว่า coding is solved แต่ประโยคถัดมาก็ตีกรอบทันทีว่า หมายถึงเฉพาะงานเขียนโค้ดแบบที่เขาทำ เขาชี้ว่า Claude ยังทำงาน systems ระดับลึก งาน distributed systems และการตรวจ UI ระดับพิกเซลได้ไม่ดี แม้ Opus 5 จะพัฒนาด้าน vision และ computer use ขึ้นมาก แต่เขาบอกว่ายังทำงานละเอียดระดับพิกเซลได้ไม่สมบูรณ์

เขามองว่าคนที่ใช้ Claude ได้เก่งต้องมีท่าทีแบบ empirical คือไม่ตั้งต้นจากสมมติฐานที่ติดมาจากโมเดลรุ่นเก่าและทฤษฎีที่เคยเรียนไว้ แต่เอาโมเดลไปรันกับงานจริง ดูว่าติดตรงไหน จากนั้นค่อยปรับตามสิ่งที่เห็น สำหรับคนที่มีกฎสะสมอยู่เต็มโปรเจกต์ จุดเริ่มต้นของวิธีคิดนี้คือ ลบกฎเหล่านั้นออกแล้วดูว่าเกิดอะไรขึ้นจริง

---

ที่มา: คลิป Boris Cherny: We Cut 80% of Claude Code's Prompt จากช่อง Y Combinator