เทคนิคการป้อนพรอมต์ Claude Fable 5.1: จัดการทุกพฤติกรรมที่เปลี่ยนไปด้วยหนึ่งบรรทัด

คู่มือปรับพรอมต์จาก Claude Fable 5 ให้เหมาะกับ Fable 5.1

Anthropic ระบุว่าพรอมต์ของ Claude Fable 5 ควรทำงานได้ดีบน Fable 5.1 โดยไม่ต้องแก้ไข แต่พฤติกรรมรอบ ๆ คำตอบเปลี่ยนไป เช่น จำนวนการเรียกใช้เครื่องมือ การอัปเดตความคืบหน้า ความหนาแน่นของสำนวน การจัดรูปแบบ การแก้ไขไฟล์ และการหยุดขออนุญาตระหว่างงาน ดูรายละเอียดจาก คู่มือการสร้างพรอมต์สำหรับ Claude Fable 5.1 และ Claude Fable 5.1 คืออะไร

ลองใช้ Apidog วันนี้

1. ปรับ Effort ก่อนแก้พรอมต์

Effort เป็นตัวควบคุมหลักของ Fable 5.1 สำหรับแลกเปลี่ยนระหว่างความฉลาด ความหน่วง และค่าใช้จ่าย

แนวทางเริ่มต้น:

1. เริ่มที่ high
2. ทดสอบระดับที่เหลือเทียบกับชุดประเมินของคุณ
3. ทดสอบใหม่แม้เคยทดสอบบน Fable 5 แล้ว เพราะระดับชื่อเดียวกันไม่ได้หมายถึงปริมาณการคิดเท่ากันในทุกโมเดล

ข้อสังเกตของ Anthropic ที่ควรตรวจสอบกับงานจริง:

• medium อาจให้ผลลัพธ์ใกล้เคียง Fable 5 ด้วยค่าใช้จ่ายต่ำกว่า
• low อาจแข่งขันกับ Opus และ Sonnet ได้ในด้านค่าใช้จ่ายต่องาน พร้อมคะแนนที่สูงกว่าในบางงาน
• ประโยชน์จาก Fable 5.1 อาจเด่นที่สุดที่ xhigh และ max

คุณสามารถเปลี่ยนระดับความพยายามระหว่างการสนทนาโดยไม่รีเซ็ตแคช ผ่านข้อความระบบว่างร่วมกับ output_config และ beta header mid-conversation-output-config-2026-07-01 ดูรูปแบบได้จาก Effort และ คำแนะนำการใช้งาน Claude Fable 5.1 API

2. วางคำสั่งต่อรอบให้ถูกตำแหน่ง

นี่เป็นความแตกต่างสำคัญของ Fable 5.1

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

• รีสตาร์ทพรอมต์แคช
• ทำให้บล็อกความคิดถัดไปไม่ถูกต้องสำหรับบัญชีที่สร้างในหรือหลังวันที่ 31 สิงหาคม 2026

ใช้ system message แบบขอบเขตต่อรอบ

เปิด beta mid-conversation-system-clear-at-2026-08-21 แล้วเพิ่มคำสั่งหลังข้อความผลลัพธ์ของเครื่องมือ:

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "คำสั่งต่อรอบของคุณ"
}

เก็บสำเนาคำสั่งเก่าไว้ในอาร์เรย์ เมื่อมีข้อความผู้ใช้ใหม่ API จะลบสำเนาเก่าออกเอง จึงไม่เสียโทเค็นจากสำเนาที่ถูกลบ

หากไม่มี beta นี้ ให้ใส่คำสั่งไว้ในบล็อกข้อความหลัง tool_result ภายในข้อความผู้ใช้เดียวกัน และเก็บสำเนาเก่าไว้เสมอ ห้ามลบหรือเขียนข้อความที่ส่งไปแล้วใหม่

อ่านเพิ่มเติมจาก การรักษาความคิด, ข้อความระบบแบบขอบเขตต่อรอบ และ คู่มือการรักษาความคิดของ Claude Fable 5.1

คำสั่งระดับเซสชันควรอยู่ในพรอมต์ระบบหรือข้อความผู้ใช้รอบแรก โดย Anthropic ระบุว่าคำสั่งด้านรูปแบบในข้อความผู้ใช้รอบแรกมักถูกเก็บรักษาไว้ดีกว่าข้อความเดียวกันในพรอมต์ระบบ

3. จำกัดการเรียกใช้เครื่องมือไว้ครั้งเดียวต่อรอบ

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

คำตอบสุดท้ายอาจไม่เปลี่ยน แต่แต่ละรอบที่เพิ่มขึ้นทำให้เสีย:

• โทเค็น
• เวลาเดินทางไปกลับ
• เวลาประมวลผลจริง

วัดผลก่อนแก้ไข โดยติดตามสัดส่วนรอบผู้ช่วยที่มี tool_use มากกว่าหนึ่งรายการ แล้วเพิ่มคำสั่งเฉพาะเมื่อพบว่าการรวมกลุ่มลดลง

เพิ่มข้อความนี้ต่อท้ายผลลัพธ์ของเครื่องมือแต่ละรายการใน system message แบบขอบเขตต่อรอบ:

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

ควรคงคำว่า privately ไว้ เพราะหากลบออก โมเดลอาจแสดงคำเตือนดังกล่าวให้ผู้ใช้เห็นแทนที่จะดำเนินการต่อ

4. ลดข้อความระหว่างการเรียกใช้เครื่องมือ

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

ลองแก้ตามลำดับนี้:

1. ตรวจสอบก่อนว่าการอัปเดตถูกส่งกลับมาหรือไม่ บล็อก thinking ที่ว่างเปล่าระหว่างการเรียกใช้เครื่องมือจะถูกซ่อนไว้เมื่อใช้ display: "omitted" ให้เปลี่ยนเป็น display: "updates" ด้วย beta header thinking-display-updates-2026-08-18
2. ลบคำสั่งจากโมเดลเก่าที่บังคับให้เก็บผลลัพธ์ทั้งหมดไว้ตอบตอนท้าย
3. หากยังต้องการการอัปเดต ให้เพิ่มข้อความนี้ในพรอมต์ระบบ:

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own, covering what you found, what you did, and what's next, so a reader who only sees the last message has the full picture.

หากผลิตภัณฑ์ซ่อนผลลัพธ์ของเครื่องมือ ให้ระบุอย่างชัดเจนว่า:

คุณเท่านั้นที่เห็นผลลัพธ์ของคำสั่งนั้น หากผู้ใช้จำเป็นต้องอ่านส่วนใดส่วนหนึ่ง ให้ใส่ไว้ในคำตอบของคุณ

วิธีนี้ป้องกันไม่ให้โมเดลเรียกใช้คำสั่งเพิ่มเติมเพียงเพื่อ “แสดง” ผลลัพธ์ที่ผู้ใช้มองไม่เห็น

5. ป้องกันรอบจบก่อนงานเสร็จ

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

เพิ่มข้อความนี้ในพรอมต์ระบบ:

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to...?' or 'Shall I...?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.

Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done, do that work now with tool calls. End your turn only when the task is complete or you are blocked on input only the user can provide.

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

หากพรอมต์ขอให้โมเดลตรวจสอบงานก่อนรายงาน ให้คงคำสั่งนั้นไว้ ต่างจากคำแนะนำสำหรับ Opus 5 ที่ให้ลบคำสั่งตรวจสอบ อ่านรายละเอียดเพิ่มเติมจาก คำแนะนำของ Opus 5

6. จำกัดการแก้ไขที่ไม่ได้ร้องขอ

เมื่อได้รับคำขอแบบปลายเปิด Fable 5.1 อาจทำมากกว่างานที่ระบุ เช่น แก้บั๊กข้างเคียง เพิ่มพฤติกรรม หรือสร้างไฟล์ทดสอบที่เกินขอบเขต

ใช้กฎนี้เพื่อลดส่วนเกิน:

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files. This is about extras only: implement every behavior the task asks for, completely.

กฎนี้ใช้ควบคุมเฉพาะงานส่วนเกิน ไม่ได้ลดทอนพฤติกรรมที่คำขอระบุไว้

7. แก้ไฟล์แบบเฉพาะเจาะจง

Fable 5.1 มีแนวโน้มเขียนไฟล์ทั้งหมดใหม่แม้ต้องเปลี่ยนเพียงบรรทัดเดียว ทำให้ใช้โทเค็นเอาต์พุตมากขึ้น

เพิ่มข้อความนี้ในพรอมต์ระบบหรือข้อความผู้ใช้รอบแรก:

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

8. ลดสำนวนที่ยาวและหนาแน่น

โดยรวมการเขียนของ Fable 5.1 ดีขึ้นและมีวลีสำเร็จรูปน้อยลง แต่บางครั้งประโยคยาวขึ้นและแบ่งย่อหน้าน้อยลง

ระบุรูปแบบที่ไม่ต้องการโดยตรง:

โปรดลบสำนวนที่ใช้ภาษาเกินจริงทั้งหมดออก

Anthropic ใช้คำว่า “mannered prose” สำหรับการเขียนที่ใช้คำเปรียบเทียบหรือถ้อยคำหรูหราแทนการสื่อสารตรง ๆ และเน้นบุคลิกผู้เขียนมากกว่าแนวคิด หากมีคำตรงตัว ให้เลือกคำนั้น

9. ให้แชทมีโครงสร้างเท่าที่เนื้อหาต้องการ

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

แนวทางที่เหมาะกว่า:

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

10. ป้องกันการสร้างคำพูดจากแหล่งที่มาโดยไม่ระบุ

เมื่อสรุปเอกสาร Fable 5.1 มีแนวโน้มทำซ้ำข้อความจากต้นฉบับโดยไม่บอกว่าเป็นคำพูด

เพิ่มตัวอย่างสมบูรณ์หนึ่งตัวอย่างในพรอมต์ระบบ ประกอบด้วย:

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

เปลี่ยนตัวแทนการเรียกใช้เครื่องมือในตัวอย่างของ Anthropic เป็นชื่อเครื่องมือจริงของคุณ

11. บังคับให้ค้นหาเมื่อใช้ความพยายามต่ำ

ที่ระดับ low Fable 5.1 อาจเรียกใช้เครื่องมือค้นหาและเรียกข้อมูลน้อยกว่า Fable 5 โดยเฉพาะเมื่อถามถึงผลิตภัณฑ์หรือโมเดลที่รู้จักชื่อ แต่ข้อมูลอาจเปลี่ยนแปลงแล้ว

มีสองแนวทาง:

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

12. ควบคุมงานส่งมอบขนาดใหญ่ที่ xhigh และ max

ที่ xhigh และโดยเฉพาะ max Fable 5.1 อาจร่างงานส่งมอบส่วนใหญ่ระหว่างการคิด แล้วเขียนซ้ำในคำตอบ ส่งผลให้เวลาและโทเค็นเอาต์พุตเพิ่มขึ้นเกือบสองเท่า

แนวทางแก้ไข:

• ใช้ high เป็นค่าเริ่มต้น และเลื่อนระดับเมื่อมีผลการวัดรองรับ
• หากใช้ xhigh หรือ max ให้ตั้ง max_tokens เผื่อทั้งบล็อกความคิดและคำตอบ
• ระบุในข้อความผู้ใช้ว่าเหตุผลและทุกสิ่งที่สร้างในคำตอบเดียวกันนับรวมอยู่ในขีดจำกัด max_tokens เดียวกัน
• เก็บสำเนาบันทึกก่อนหน้าไว้ในคำขอถัดไป

การสร้างงานส่งมอบฉบับเต็มระหว่างการคิด แล้วสร้างซ้ำอีกครั้งในคำตอบ เพิ่มรอบโดยไม่ได้เพิ่มคุณภาพ

13. ลดผลบวกลวงจากการปฏิเสธคำขอโค้ด

ตัวแยกประเภทของ Fable 5.1 ให้ผลบวกลวงน้อยกว่า Fable 5 เมื่อเปิดตัว และอนุญาตให้ค้นหาช่องโหว่ในซอร์สโค้ดได้แล้ว แต่ยังอาจปฏิเสธคำขอที่ไม่เป็นอันตรายบางส่วน

ลองปรับสามจุดนี้:

• ถามว่า Are there any bugs in this program? แทน Does this program compile without errors?
• ให้เอกสารสำหรับภาษาที่โมเดลรู้จักน้อย
• ลบเครื่องมือที่ส่งข้อมูลเข้ารหัส Base64 เข้าสู่บริบท หากไม่จำเป็น
• คงค่า fallback ที่กำหนดไว้เสมอ

ดูแนวทางเพิ่มเติมจาก คู่มือการจัดการการปฏิเสธ

14. รักษารายละเอียดระหว่างการบีบอัดฝั่งไคลเอ็นต์

Fable 5.1 ตอบสนองได้ดีเมื่อระบุชัดเจนว่าสรุปต้องเก็บรายละเอียดใดไว้ การบีบอัดฝั่งเซิร์ฟเวอร์จัดการเรื่องนี้อยู่แล้ว แต่หากคุณบีบอัดฝั่งไคลเอ็นต์ ให้สั่งให้โมเดลสรุปภายในแท็ก <summary> ตามลำดับนี้:

1. ปัญหาที่เกิดขึ้นและวิธีแก้ไข
2. แนวทางที่เสนอหรือถูกพักไว้ พร้อมเหตุผล
3. สิ่งที่ถูกร้องขอหรือตัดสินใจ โดยระบุให้ชัดเจน
4. สถานการณ์ปัจจุบัน
5. สิ่งที่ยังไม่เสร็จ
6. รายละเอียดที่สร้างใหม่ได้ยาก เช่น ชื่อ ตัวเลข และลิงก์

ปิดท้ายด้วยข้อความนี้:

Do not call any tools while writing this summary; respond with text only

ข้อความนี้สำคัญเมื่อคำขอสรุปยังอยู่ในบทสนทนาที่มีเครื่องมือ

15. ออกแบบเอเจนต์ย่อยและการมองเห็น

การแก้ไขสองข้อนี้เป็นเรื่องสถาปัตยกรรมมากกว่าการเขียนพรอมต์

งานเขียนโค้ด

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

แผนภูมิและตารางหนาแน่น

ให้โมเดลมีเครื่องมือครอบตัดที่ส่งคืนพื้นที่ที่เลือกในขนาดใหญ่ขึ้น หรือมีคอนเทนเนอร์พร้อมไลบรารีรูปภาพพื้นฐาน

ที่ระดับ low โมเดลอาจข้ามการครอบตัด จึงควรตรวจสอบบันทึกการเรียกใช้เครื่องมือ

16. ทดสอบการเปลี่ยนแปลงใน Apidog

การปรับทั้งหมดควรทดสอบแบบก่อนและหลัง:

1. บันทึกสามรอบแรกของลูปเอเจนต์เป็นลำดับคำขอ
2. กำหนดพรอมต์ระบบเป็นพารามิเตอร์
3. รันทั้งเวอร์ชันที่มีและไม่มีการแก้ไข โดยใช้ระดับความพยายามเท่ากัน
4. เปรียบเทียบผลลัพธ์และตัวชี้วัด

ตัวชี้วัดที่ควรดู:

• จำนวนบล็อก tool_use ต่อรอบผู้ช่วย เพื่อวัดการรวมกลุ่มเครื่องมือ
• usage.output_tokens เพื่อวัดการแก้ไขแบบเฉพาะเจาะจงและความหนาแน่นของข้อความ
• การไม่มีวรรคสุดท้ายที่ขึ้นต้นด้วย Next, I เพื่อวัดความเป็นอิสระของเอเจนต์

ใช้ Apidog เพื่อสร้างและรันทดสอบ และอ่าน คู่มือ Claude Code เพื่อดูว่าควรเพิ่มบรรทัดใดใน CLAUDE.md

คำถามที่พบบ่อย

พรอมต์ Fable 5 ของฉันใช้งานบน Fable 5.1 ได้หรือไม่?

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

ควรใช้ระดับความพยายามใด?

เริ่มที่ high แล้วทดสอบกับชุดประเมินของคุณ Anthropic ระบุว่า medium อาจให้ผลลัพธ์ใกล้เคียง Fable 5 ด้วยค่าใช้จ่ายต่ำกว่า ส่วน low อาจแข่งขันกับ Opus และ Sonnet ได้ในด้านค่าใช้จ่ายต่องาน

ควรวางคำสั่งต่อรอบไว้ที่ไหน?

ใช้ system message แบบขอบเขตต่อรอบที่มี clear_at: "next_user_message" หลังผลลัพธ์ของเครื่องมือ และเก็บสำเนาเก่าไว้ การแทรกหรือลบข้อความจากประวัติรอบก่อนจะทำให้บล็อกความคิดถัดไปไม่ถูกต้องและรีสตาร์ทแคช

ควรลบคำสั่ง “ตรวจสอบงานของคุณ” เหมือน Opus 5 หรือไม่?

ไม่ควรลบ คำแนะนำดังกล่าวเป็นกรณีเฉพาะของการตรวจสอบที่มากเกินไปใน Opus 5 ให้คงคำสั่งตรวจสอบไว้บน Fable 5.1

จะหยุดไม่ให้ Fable 5.1 เขียนไฟล์ทั้งหมดใหม่ได้อย่างไร?

เพิ่มข้อความนี้ในพรอมต์ระบบหรือข้อความผู้ใช้รอบแรก:

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

ลิงก์อ้างอิง

• คู่มือการสร้างพรอมต์สำหรับ Claude Fable 5.1
• Claude Fable 5.1 คืออะไร
• Effort
• คำแนะนำการใช้งาน API
• การรักษาความคิด
• ข้อความระบบแบบขอบเขตต่อรอบ
• คู่มือการรักษาความคิด
• คำแนะนำของ Opus 5 ที่ให้ลบคำสั่งตรวจสอบ
• คู่มือการจัดการการปฏิเสธ
• Apidog
• ดาวน์โหลด Apidog
• คู่มือ Claude Code