เวลาสั่งเอเจนต์แก้โค้ดหลายไฟล์แล้วงานเริ่มยาวเกินขอบเขต หลายคนตอบโต้ด้วยการเพิ่มคำว่า “คิดให้ละเอียด” “ตรวจซ้ำ” หรือ “ทำให้ดีที่สุด” ลงใน prompt ผลคือเอเจนต์อาจมีคำสั่งมากขึ้นให้ตีความ แต่เรายังไม่ได้บอกว่าควรหยุดตรงไหน ส่งอะไร และรายงานอย่างไร

เอกสาร Claude Platform Docs สำหรับ Claude Opus 5 ชี้ไปอีกทาง: ให้กำหนดสเปกงานและรูปแบบการทำงานให้ชัด แล้วทดลองเลือกระดับ effort กับ evals ของเราเอง บทความนี้สรุปเป็น คันโยกในการคุมงานเอเจนต์ 5 ตัว สำหรับคนที่ใช้ Opus 5 หรือ Claude Code กับงานโค้ดหลายไฟล์

1. เริ่มจากสเปกและขอบเขตงาน ไม่ใช่คำสั่งให้คิดหนัก

เมื่อต้องให้เอเจนต์เขียนโค้ดที่ซับซ้อน เอกสารแนะนำให้ส่งสเปกให้ครบตั้งแต่ต้น แล้วปล่อยให้โมเดลทำงานตามนั้น อย่าบอกแค่ว่า “แก้บั๊กนี้” ควรระบุไฟล์หรือส่วนของระบบที่เกี่ยวข้อง พฤติกรรมที่ต้องการ เกณฑ์ยอมรับ และสิ่งที่ไม่อยู่ในงาน

ตัวอย่างเช่น หากต้องการเพิ่มการตรวจสอบข้อมูลให้ API อย่าปล่อยให้คำสั่งเปิดกว้างจนเอเจนต์ตัดสินใจปรับโครงสร้างโมดูลข้างเคียงเอง ระบุให้ชัดว่าแก้ endpoint ใด ต้องส่งอะไร และห้ามเปลี่ยน public API หากไม่จำเป็น

คำสั่งแบบนี้ช่วยแยก “งานที่ต้องทำ” ออกจาก “งานที่ดูเหมือนน่าจะดี” ซึ่งเป็นจุดสำคัญเมื่อให้เอเจนต์ทำงานต่อเนื่องหรือทำงานข้ามหลายไฟล์

2. แยกการคุมระดับ effort ออกจากการคุมความสั้นของคำตอบ

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

เอกสารแนะนำให้เริ่มทดลองที่ระดับ high แล้วไล่ทดลองระดับ effort โดยวัดด้วย evals ของงานเราเอง หากยังได้คุณภาพตามต้องการ จึงลอง low หรือ medium เพื่อลดโทเค็นและเวลา ส่วนงานเขียนโค้ดหรืองานแบบเอเจนต์ที่หนักขึ้น อาจต้องลอง xhigh ด้วย แต่ไม่มีระดับใดที่เหมาะกับทุกทีมโดยอัตโนมัติ

ส่วนรูปแบบคำตอบ ควรบอกให้เห็นภาพว่าต้องการอะไร เช่น ให้ตอบแบบ focused, brief หรือ concise และเมื่อต้องอธิบาย ให้เริ่มจากภาพรวมก่อน ถ้า system prompt ยาว ให้ย้ำคำสั่งสั้น ๆ นี้ใกล้ท้าย prompt ด้วย

อย่ารวมสองเรื่องนี้เข้าด้วยกัน: ตั้งค่า effort เพื่อกำหนดปริมาณการคิด ส่วนความยาวของคำตอบต้องบอกโมเดลโดยตรงว่าควรสื่อสารอย่างไร

3. กำหนดจังหวะอัปเดตความคืบหน้าให้พอดีกับงาน

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

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

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

4. ตัดคำสั่งตรวจซ้ำ แล้วจำกัดการมอบหมายให้ subagent

คำว่า “double-check” หรือ “re-verify” ฟังดูปลอดภัย แต่เอกสารแนะนำให้ลบคำสั่งตรวจซ้ำที่ตกค้างมาจากโมเดลรุ่นก่อน เพราะ Opus 5 ตรวจงานตัวเองอยู่แล้ว คำสั่งเหล่านี้อาจเพิ่มต้นทุนโดยไม่เพิ่มคุณภาพที่เห็นได้ชัด

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

การมอบหมายให้ subagent ก็ต้องมีขอบเขต เอกสารระบุว่า Opus 5 ประสานทีม subagent ได้ดี แต่หากต้องคุมต้นทุน ให้มอบหมายเฉพาะงานใหญ่ที่แยกทำพร้อมกันได้จริง ใช้ subagent เพียงหนึ่งตัวถ้าตัวเดียวทำงานนั้นได้ครบ และอย่าสร้าง subagent เพื่อตรวจงานซ้ำ

ใน Claude Code หรือ Claude Agent SDK กำหนดเพดานได้ผ่าน CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH, CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS และตัวเลือก max_budget_usd เพดานเหล่านี้ต้องใช้ Claude Code เวอร์ชัน 2.1.217 ขึ้นไป และข้อมูลนี้ไม่ได้หมายความว่าระบบเอเจนต์อื่นจะมีการตั้งค่าเดียวกัน

5. อย่าปิด thinking เพียงเพื่อคุมต้นทุน

Claude Opus 5 เปิด thinking เป็นค่าเริ่มต้น และปิดได้เมื่อ effort อยู่ที่ high หรือต่ำกว่า เอกสารแนะนำให้เปิด thinking ไว้ แล้วลด effort หากเป้าหมายคือคุมต้นทุน

เมื่อปิด thinking อาจมีคำสั่งเรียก tool หลุดออกมาเป็นข้อความที่ผู้ใช้เห็น หรือมีแท็ก XML ภายในปรากฏในคำตอบได้เป็นครั้งคราว ไม่ได้เกิดทุกครั้ง แต่เป็นความเสี่ยงที่ต้องยอมรับก่อนเลือกโหมดนี้ หากจำเป็นต้องปิดจริง ๆ ควรบอกให้โมเดลพูดสั้น ๆ ก่อนใช้ tool ระบุว่าถ้าไม่มี tool ที่เหมาะให้บอกแทนการเดา และห้ามใส่แท็ก XML ภายในหรือของระบบ

เช็กลิสต์ก่อนเริ่มงานครั้งต่อไป

ก่อนส่ง prompt ให้ Opus 5 ลองตรวจด้วยคำถามสั้น ๆ นี้

• กำหนดสเปกงาน เกณฑ์ยอมรับ และขอบเขตที่ห้ามแตะแล้วหรือยัง
• แยกคำสั่งเรื่องระดับ effort ออกจากคำสั่งเรื่องความกระชับของคำตอบแล้วหรือยัง
• บอกจังหวะอัปเดตความคืบหน้าที่ต้องการชัดเจนหรือยัง
• ตัด “double-check” และไม่สร้าง subagent เมื่องานไม่ได้แยกจากกันจริงแล้วหรือยัง
• หากต้องใช้ subagent กำหนดเพดานตามเครื่องมือที่ใช้อย่างเหมาะสมแล้วหรือยัง
• จะตัดสินใจเลือก effort จาก evals ของงานจริง ไม่ใช่จากค่าตายตัวที่คนอื่นแนะนำใช่หรือไม่
• ถ้าคิดจะปิด thinking ยอมรับความเสี่ยงที่ผลลัพธ์อาจผิดรูปแบบ และมีคำสั่งป้องกันที่ชัดเจนแล้วหรือยัง

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

ที่มา: Prompting Claude Opus 5, Claude Platform Docs