ไม่จำเป็นต้องเปิด Effort สูงสุดตลอดเวลา
“Effort ไม่ใช่ระดับคุณภาพที่ควรเลือกสูงที่สุดเสมอ” แต่เป็นระดับทรัพยากรการคิดที่ควรเพิ่มตามความยากของงาน
พูดง่าย ๆ คือ เริ่มจากระดับที่เหมาะกับโจทย์ แล้วค่อยเพิ่มเมื่อ Claude เริ่มติด ไม่จำเป็นต้องเปิด Max ตั้งแต่ต้นทุกครั้ง
5 ระดับ Effort ควรใช้ตอนไหน
1. Low — เมื่อแผนชัดอยู่แล้ว
เหมาะกับงานที่สามารถอธิบายสิ่งที่ต้องแก้ได้แทบจะในประโยคเดียว เช่น
- เปลี่ยนชื่อตัวแปร
- แก้ข้อความ
- ปรับ CSS เล็กน้อย
- เปลี่ยนรูปแบบตาม pattern ที่มีอยู่
- แก้โค้ดหลายไฟล์ด้วยกฎเดียวกัน
- ทำ prototype เพื่อดูแนวทางเร็ว ๆ
แนวคิดคือ “รู้อยู่แล้วว่าต้องทำอะไร จึงไม่จำเป็นต้องเสียเวลาให้ AI คิดหนัก”
Low จึงเหมาะมากกับช่วงที่ยังต้องการ iterate เร็ว ๆ เพราะถ้าทิศทางผิด เราจะได้เห็นและแก้โจทย์ได้เร็ว
2. Medium — ค่าเริ่มต้นสำหรับงานประจำส่วนใหญ่
ถ้าเป็นงานที่ขอบเขตชัด และเรารู้ว่ากำลังสร้างอะไรอยู่ ให้เริ่มจาก Medium
เช่น
- เพิ่ม feature ตาม requirement
- สร้างหน้าเว็บ
- เขียน API
- แก้ business logic
- refactor ระบบที่เข้าใจโครงสร้างอยู่แล้ว
- สร้าง component ใหม่ตาม architecture เดิม
นี่อาจเป็น “sweet spot” สำหรับงาน Claude Code ส่วนใหญ่ เพราะสมดุลระหว่าง
ความเร็ว + คุณภาพ + Token + จำนวนรอบ
จึงไม่จำเป็นต้องขยับขึ้น High ถ้า Medium ทำงานจบได้อยู่แล้ว
3. High — เมื่อ Medium เริ่มติด
High ไม่จำเป็นต้องใช้เพราะ “งานสำคัญ” อย่างเดียว แต่ควรใช้เมื่อเริ่มเห็นว่า Medium
- พลาดบางเงื่อนไข
- แก้ bug ไม่ครบ
- วนอยู่กับปัญหาเดิม
- มีหลาย dependency
- มี edge case เยอะ
- ต้องตรวจความถูกต้องมากขึ้น
สิ่งที่มักเกิดขึ้นเมื่อเพิ่ม Effort คือ Claude จะใช้เวลามากขึ้นกับการตรวจสอบงานของตัวเอง
เช่น
เขียน → ทดสอบ → เจอปัญหา → วิเคราะห์ → แก้ → ทดสอบอีกครั้ง
ดังนั้นเวลาที่เพิ่มขึ้นไม่ได้ถูกใช้เพียงเพื่อ “คิดคำตอบให้นานขึ้น” แต่บางส่วนถูกใช้ในการค้นหาสิ่งที่ระดับต่ำกว่าพลาดไป
4. Extra High — เมื่อ High ยังแก้โจทย์ไม่ได้
Extra High หรือ xHigh เหมาะกับปัญหาที่ยากขึ้นอีกระดับ เช่น
- bug ซับซ้อน
- architecture หลายระบบ
- concurrency
- performance
- security
- algorithm
- งานที่มี edge case จำนวนมาก
ถ้า High พยายามแล้วแต่ยังติดอยู่ การเพิ่มเป็น Extra High อาจช่วยให้โมเดลสำรวจสมมติฐานและตรวจวิธีแก้ละเอียดขึ้น
แต่มีหลักคิดสำคัญอีกข้อจากภาพคือ
ถ้า xHigh ยังติดปัญหาเดิม อาจไม่ใช่เรื่องของ Effort แล้ว แต่อาจถึงเวลาลองเปลี่ยนโมเดล เช่น Fable 5.1 สำหรับงานนั้นโดยเฉพาะ
เพราะการเพิ่มแรงคิดให้วิธีที่ผิด ไม่ได้แปลว่าจะทำให้วิธีนั้นกลายเป็นวิธีที่ถูก
5. Max — ใช้กับงานที่ซับซ้อนที่สุด
Max ควรเป็น “โหมดเฉพาะกิจ” มากกว่าจะเป็นค่าเริ่มต้นถาวร
เหมาะกับงานประเภท
- ปัญหาที่แก้มาหลายวิธีแล้วยังไม่ได้
- security-critical code
- migration ขนาดใหญ่
- debugging ที่เกี่ยวข้องหลายระบบ
- algorithm ซับซ้อน
- การตรวจงานขั้นสุดท้ายที่ความผิดพลาดมีต้นทุนสูง
หลักคิดคือ
เปิด Max → แก้โจทย์ยาก → เสร็จแล้วลด Effort ลง
ไม่ใช่
เปิด Max → ใช้กับทุกอย่าง
เพราะงานจำนวนมากไม่ได้ต้องการการคิดระดับนั้น
Workflow ที่เหมาะกว่าการเปิด Max ตั้งแต่ต้น
จากบทความและภาพ สามารถสรุป workflow ที่ใช้งานจริงได้ประมาณนี้
Requirement → Low → Medium → High → Extra High → Max
แต่ไม่ได้หมายความว่าทุกงานต้องผ่านทุกขั้น
ตัวอย่างเช่น ถ้า requirement ชัดมาก
Medium → เสร็จ
ก็จบได้เลย
หรือถ้ากำลังสำรวจไอเดีย
Low → ดูงาน → ปรับ requirement → Low
จนกว่าจะมั่นใจในทิศทาง แล้วจึงขยับไป Medium หรือ High
วิธีคิดที่สำคัญกว่า Effort คือ “แยก Build กับ Verify”
หนึ่งในแนวคิดที่น่าสนใจที่สุดคือ อย่าให้ AI พยายาม “สร้างของสมบูรณ์แบบในรอบเดียว”
สามารถแบ่งงานเป็นสองช่วงได้
Build
ใช้ Low หรือ Medium
เป้าหมายคือ
- สร้างเร็ว
- เห็นของจริงเร็ว
- ตรวจว่าความเข้าใจตรงกันหรือไม่
- ปรับ requirement ได้เร็ว
Verify
ใช้ High หรือ Extra High
เป้าหมายคือ
- หา bug
- ทดสอบ edge case
- ตรวจ security
- ตรวจ performance
- ตรวจ integration
- ตรวจว่าส่วนอื่นของระบบไม่พัง
จึงกลายเป็นแนวคิดง่าย ๆ ว่า
สร้างเร็ว → ตรวจหนัก
แทนที่จะ
คิดหนักทุกอย่างตั้งแต่ยังไม่รู้ด้วยซ้ำว่าทิศทางถูกหรือไม่
Effort สูงไม่ได้แปลว่าคุ้มกว่าเสมอ
สมมติว่า
Medium ใช้ $1 ต่อครั้ง แต่ต้องวนแก้ 5 ครั้ง
ต้นทุนรวมอาจกลายเป็น
$5
ขณะที่ High ใช้ $2 แต่แก้จบในครั้งเดียว
High อาจถูกกว่าในระดับ “งานที่เสร็จจริง”
แต่ในทางกลับกัน ถ้า Medium ทำจบได้ตั้งแต่รอบแรก การเปิด High หรือ Max ก็เป็นต้นทุนที่ไม่จำเป็น
ดังนั้นตัวเลขที่ควรดูไม่ใช่
Cost per Prompt
แต่คือ
Cost per Completed & Verified Task
หรือต้นทุนจนได้งานที่ “เสร็จและตรวจแล้ว”
สิ่งที่ Effort สูงช่วยมากที่สุดคือ “การตรวจ”
จากตัวอย่างในบทความ จุดที่แตกต่างระหว่าง Effort ต่ำกับสูงมักไม่ได้อยู่ที่ความสามารถในการ “เขียนโค้ด” เพียงอย่างเดียว
แต่อยู่ที่พฤติกรรมอย่าง
- ทำให้ bug เกิดซ้ำก่อนแก้
- อ่าน implementation ที่เกี่ยวข้อง
- สร้าง test เพิ่ม
- สุ่มข้อมูลเพื่อทดสอบ
- ทดลองหลายสมมติฐาน
- เปรียบเทียบผลลัพธ์หลายวิธี
- ตรวจว่าการแก้ใหม่ไม่ได้ทำของเดิมพัง
- ทดสอบ performance กับข้อมูลขนาดใหญ่
จึงอธิบายได้ว่าทำไมงาน security, algorithm หรือ debugging บางประเภทถึงได้ประโยชน์จาก Effort สูงมากกว่างานแก้ UI เล็ก ๆ
สรุป
หัวใจของเรื่องนี้ไม่ใช่การพยายาม “ประหยัด Token ให้มากที่สุด” และก็ไม่ใช่ “เปิด AI ให้ฉลาดที่สุดตลอดเวลา”
แต่คือการจัดสรรแรงคิดให้เหมาะกับแต่ละช่วงของงาน
Low = ทำเร็ว
Medium = ทำงานจริง
High = ตรวจให้ลึก
Extra High = แก้โจทย์ยาก
Max = ใช้กับปัญหาที่ซับซ้อนที่สุด
ประโยคสรุปที่ดีที่สุดคือ:
“อย่าเริ่มจาก Effort สูงที่สุด ให้เริ่มจาก Effort ต่ำที่สุดที่สามารถทำงานนั้นได้ดี แล้วค่อยเพิ่มเมื่อความซับซ้อนของปัญหาบังคับให้ต้องเพิ่ม”
แบบนี้เราจะได้ทั้งความเร็ว คุณภาพ และต้นทุนที่เหมาะสมกว่าเปิด Max ไว้ตลอดครับ
