Anthropic ระบุว่าพรอมต์ Fable 5 เดิมของคุณควรทำงานได้ดีบน Claude Fable 5.1 โดยไม่ต้องเปลี่ยนแปลง นี่เป็นจริงสำหรับคำตอบ แต่ไม่ค่อยเป็นจริงสำหรับทุกสิ่งที่อยู่รอบข้าง เช่น จำนวนการเรียกใช้เครื่องมือที่โมเดลประมวลผลต่อรอบ, ปริมาณการบรรยาย, ความหนาแน่นของสำนวน, การจัดรูปแบบในการแชท, การเขียนไฟล์ทั้งหมดใหม่เพื่อเปลี่ยนเพียงบรรทัดเดียว, และการหยุดเพื่อขออนุญาตสำหรับงานที่คุณร้องขอไปแล้ว สิ่งเหล่านี้มีการเปลี่ยนแปลงไปมาระหว่าง Fable 5 และ Fable 5.1 และแต่ละปัญหามีวิธีแก้ไขเฉพาะอยู่ในคู่มือการสร้างพรอมต์สำหรับ Claude Fable 5.1 ของ Anthropic
คู่มือนี้รวบรวมทุกการเปลี่ยนแปลงพร้อมวิธีแก้ไข โดยอ้างอิงข้อความอย่างเป็นทางการในส่วนที่คำพูดมีความสำคัญ รวมถึงกฎการจัดวางที่สำคัญกว่าในโมเดลนี้เมื่อเทียบกับรุ่นก่อนหน้าทั้งหมด: ตำแหน่งที่คุณวางคำสั่งต่อรอบตอนนี้จะเป็นตัวกำหนดว่าจะทำให้บล็อกความคิดของคุณไม่ถูกต้องและรีสตาร์ทแคชหรือไม่ สำหรับภาพรวมโมเดล โปรดดูที่Claude Fable 5.1 คืออะไร
เริ่มต้นด้วยความพยายาม ไม่ใช่พรอมต์
Effort เป็นตัวควบคุมหลักสำหรับการแลกเปลี่ยนระหว่างความฉลาด, ความหน่วง, และค่าใช้จ่ายบน Fable 5.1 และควรปรับแต่งก่อนการเปลี่ยนแปลงพรอมต์ใดๆ เริ่มต้นที่ค่าเริ่มต้น high จากนั้นทดสอบระดับอีกสี่ระดับที่เหลือเทียบกับการประเมินของคุณเอง ดำเนินการทดสอบซ้ำแม้ว่าคุณจะเคยทดสอบบน Fable 5 มาแล้วก็ตาม: ชื่อระดับไม่สอดคล้องกับปริมาณการคิดเท่ากันในแต่ละโมเดล
ข้อกล่าวอ้างของ Anthropic ที่ควรทดสอบ: ที่ medium ผลลัพธ์จะใกล้เคียงกับ Fable 5 โดยมีค่าใช้จ่ายที่ต่ำกว่า; ที่ low Fable 5.1 มักจะแข่งขันได้กับ Opus และ Sonnet ในด้านค่าใช้จ่ายต่องาน ในขณะที่ได้คะแนนสูงกว่า; ประโยชน์ที่ได้รับจาก Fable 5 จะสูงสุดที่ xhigh และ max บน Fable 5.1 คุณสามารถเปลี่ยนระดับความพยายามระหว่างการสนทนาได้โดยไม่ต้องรีเซ็ตแคช โดยใช้ข้อความ role: "system" ที่ไม่มีเนื้อหาพร้อม output_config (ส่วนหัวเบต้า mid-conversation-output-config-2026-07-01) คำแนะนำการใช้งาน API จะแสดงรูปแบบการร้องขอ
การจัดวางมีความสำคัญมากกว่าคำพูด
บล็อกความคิดของ Fable 5.1 จะใช้ได้เฉพาะในการสนทนาที่สร้างขึ้นมาเท่านั้น (การรักษาความคิด) การแทรกคำเตือนเข้าไปในการสนทนารอบก่อนหน้าและลบออกในการร้องขอครั้งถัดไปถือเป็นการแก้ไขประวัติ: ซึ่งจะรีสตาร์ทแคชของพรอมต์ และสำหรับบัญชีที่สร้างขึ้นในหรือหลังวันที่ 31 สิงหาคม 2026 จะทำให้บล็อกความคิดที่ตามมาทั้งหมดไม่ถูกต้อง
ดังนั้น คำสั่งต่อรอบจึงอยู่ในสองตำแหน่ง ด้วยเบต้า mid-conversation-system-clear-at-2026-08-21 ให้เพิ่มคำสั่งเหล่านั้นเป็นข้อความระบบแบบขอบเขตต่อรอบ: {"role": "system", "clear_at": "next_user_message", "content": "..."} หลังจากข้อความผลลัพธ์ของเครื่องมือ และคงสำเนาที่เก่ากว่าทั้งหมดไว้ในอาร์เรย์ เมื่อมีข้อความผู้ใช้ใหม่เข้ามา API จะลบสำเนาเก่าออก ดังนั้นโมเดลจะอ่านเฉพาะข้อความที่ใหม่ที่สุดเท่านั้น และสำเนาที่ถูกลบก็ไม่เสียค่าโทเค็น หากไม่มีเบต้า ให้ใส่ประโยคในบล็อกข้อความหลังจากบล็อก tool_result ในข้อความผู้ใช้เดียวกัน โดยเก็บสำเนาที่เก่ากว่าไว้ ห้ามลบหรือเขียนสำเนาที่ส่งไปแล้วใหม่โดยเด็ดขาด คู่มือการรักษาความคิด อธิบายเหตุผล
คำสั่งระดับเซสชันจะอยู่ในพรอมต์ระบบหรือการสนทนารอบแรกของผู้ใช้ Anthropic ตั้งข้อสังเกตว่าคำสั่งด้านรูปแบบที่อยู่ในรอบแรกของผู้ใช้จะถูกเก็บรักษาไว้ดีกว่าข้อความเดียวกันที่อยู่ในพรอมต์ระบบ
เรียกใช้เครื่องมือครั้งเดียวต่อรอบในลูปตัวแทน
การเปลี่ยนแปลง. เมื่อคำร้องขอระบุหลายสิ่งให้ดึงข้อมูล Fable 5.1 จะออกการเรียกใช้แบบขนาน ในลูปการเขียนโค้ดและการใช้งานคอมพิวเตอร์ที่การอ่านอิสระครั้งถัดไปถูกบอกเป็นนัยเท่านั้น มันอาจออกหนึ่งครั้งต่อรอบ ในขณะที่ Fable 5 ประมวลผลหลายรายการพร้อมกัน คำตอบไม่ได้รับผลกระทบ; แต่ละรอบที่เพิ่มขึ้นมีค่าใช้จ่ายเป็นโทเค็น การเดินทางไปกลับ และเวลาจริง
วัดผลก่อน. ติดตามสัดส่วนของรอบผู้ช่วยที่มีการเรียกใช้เครื่องมือมากกว่าหนึ่งครั้ง และเพิ่มการแก้ไขก็ต่อเมื่อสัดส่วนนั้นลดลง การแก้ไข ซึ่งเพิ่มต่อท้ายข้อความผลลัพธ์ของเครื่องมือแต่ละรายการในฐานะข้อความระบบแบบขอบเขตต่อรอบ:
First privately list what you need next; then request every item that doesn't depend on another's result in this one response.
คงคำว่า “privately” ไว้ หากไม่มีคำนี้ โมเดลอาจตอบคำเตือนแทนที่จะตอบผู้ใช้ บางประโยคใกล้ท้ายคำร้องขอปัจจุบันมีผลต่อจำนวนมากกว่าข้อความเดียวกันในพรอมต์ระบบ
ข้อความน้อยหรือไม่เลยระหว่างการเรียกใช้เครื่องมือ
การเปลี่ยนแปลง. Fable 5.1 เขียนการอัปเดตที่ผู้ใช้เห็นน้อยลงระหว่างการเรียกใช้เครื่องมือที่ยาวนานกว่า Fable 5 โดยเฉพาะอย่างยิ่งเมื่อใช้ความพยายามสูง ผู้ใช้จะเห็นเอเจนต์เงียบไปหลายนาที หรือข้อความสุดท้ายที่ครอบคลุมเฉพาะขั้นตอนสุดท้ายเท่านั้น
สามวิธีแก้ไข ตามลำดับ. ประการแรก ตรวจสอบให้แน่ใจว่าคุณได้รับการอัปเดตความคืบหน้าหรือไม่: บันทึกระหว่างเครื่องมือของโมเดลจะส่งกลับมาเป็นบล็อก thinking ที่ว่างเปล่าภายใต้ค่าเริ่มต้น display: "omitted" ให้ตั้งค่า display: "updates" (ส่วนหัวเบต้า thinking-display-updates-2026-08-18) และแสดงผลบล็อกความคิดที่ไม่ว่างเปล่าแต่ละรายการเป็นบรรทัดสถานะ ประการที่สอง ลบประโยคพรอมต์ที่เขียนขึ้นสำหรับโมเดลเก่าที่ต้องการอัปเดต เช่น “เก็บผลลัพธ์ทั้งหมดไว้สำหรับการตอบกลับขั้นสุดท้าย” ประการที่สาม หากคุณยังต้องการเพิ่ม ให้เพิ่มบรรทัดพรอมต์ระบบ:
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.
หากผลิตภัณฑ์ของคุณซ่อนผลลัพธ์ของเครื่องมือ ให้แจ้งโมเดลด้วยข้อความระบบแบบขอบเขตต่อรอบ มิฉะนั้นมันอาจรันคำสั่งเพื่อ “แสดง” ผลลัพธ์ที่ผู้ใช้ไม่เคยเห็น: “คุณเท่านั้นที่เห็นผลลัพธ์ของคำสั่งนั้น หากผู้ใช้จำเป็นต้องอ่านส่วนใดส่วนหนึ่ง ให้ใส่ไว้ในคำตอบของคุณ”
รอบสิ้นสุดก่อนงานจะเสร็จสิ้น
การเปลี่ยนแปลง. สำหรับเวิร์กโหลดแบบอะซิงโครนัสที่ซับซ้อน 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.
Anthropic จับคู่กับบล็อกที่สองที่กำหนดคำร้องขอของผู้ใช้เป็นขอบเขตของผลลัพธ์ที่ส่งมอบ: อย่าจำกัด, ขยาย, หรือสลับมัน; ทำทุกส่วนที่ไม่ได้ถูกบล็อกให้เสร็จและบอกว่ามีอะไรที่เหลืออยู่บ้าง; ปฏิบัติต่อสิ่งที่สังเกตเห็นแต่ไม่ได้ถูกร้องขอเป็นข้อเสนอแนะ ไม่ใช่การเปลี่ยนแปลง การจับคู่นี้สามารถทำให้โมเดลมีโอกาสน้อยลงที่จะถามเกี่ยวกับคำร้องขอที่ไม่ชัดเจน ดังนั้นให้เพิ่มบรรทัดที่ระบุการยืนยันที่คุณยังต้องการ ความแตกต่างอย่างหนึ่งจาก Opus 5: หากพรอมต์ของคุณขอให้โมเดลตรวจสอบงานก่อนรายงาน ให้คงไว้ คำแนะนำของ Opus 5 ที่ให้ลบคำสั่งตรวจสอบ ไม่ได้ใช้กับรุ่นนี้
การแก้ไขที่ไม่ร้องขอและไฟล์ทดสอบพิเศษ
การเปลี่ยนแปลง. เมื่อถูกร้องขอคุณสมบัติปลายเปิด Fable 5.1 จะส่งมอบคุณสมบัตินั้นและบางครั้งก็ให้มากกว่านั้น: การแก้ไขใกล้เคียง, พฤติกรรมที่ขยายออกไป, ไฟล์ทดสอบที่คอมมิตเกินกว่าที่การเปลี่ยนแปลงจะรับประกันได้
วิธีแก้ไข ซึ่ง Anthropic กล่าวว่าช่วยลดส่วนเกินลงได้อย่างมากโดยไม่ทำให้ความสำเร็จของงานเปลี่ยนแปลง:
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.
ไฟล์ทั้งหมดถูกเขียนใหม่เพื่อการเปลี่ยนแปลงเล็กน้อย
การเปลี่ยนแปลง. Fable 5.1 มีแนวโน้มที่จะเขียนไฟล์ทั้งหมดใหม่มากกว่า Fable 5 แทนที่จะทำการแก้ไขแบบเฉพาะเจาะจง ให้ผลลัพธ์เดียวกัน แต่ใช้โทเค็นเอาต์พุตมากขึ้น
วิธีแก้ไข ในพรอมต์ระบบหรือข้อความผู้ใช้แรก:
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.
สำนวนยาวและหนาแน่น
การเปลี่ยนแปลง. การเขียนของ Fable 5.1 โดยทั่วไปถือเป็นการพัฒนาที่ดีขึ้น โดยมีวลีสำเร็จรูปน้อยลง แต่ในบางกรณีก็มีความหนาแน่นมากกว่าของ Fable 5: ประโยคยาวขึ้น การแบ่งย่อหน้าลดลง
วิธีแก้ไข คือการกำหนดรูปแบบที่ไม่พึงประสงค์ ข้อความของ Anthropic อธิบาย “สำนวนที่ใช้ภาษาเกินจริง” (mannered prose) ว่าเป็นการเขียนที่ใช้คำเปรียบเทียบและสำนวนที่หรูหราแทนการบอกตรงๆ และมีอยู่เพื่อแสดงให้เห็นถึงผู้เขียนมากกว่าที่จะสื่อสารแนวคิด; คำแนะนำคือให้พูดในสิ่งที่คุณต้องการและใช้คำตรงตัวเมื่อมีให้เลือกใช้ รูปแบบสั้นๆ ก็ใช้ได้เช่นกัน: “โปรดลบสำนวนที่ใช้ภาษาเกินจริงทั้งหมดออก”
คำตอบในแชทมีโครงสร้างน้อยกว่าที่เนื้อหาต้องการ
การเปลี่ยนแปลง. โมเดลรุ่นก่อนๆ ใช้สัญลักษณ์หัวข้อย่อยและตัวหนามากเกินไป ทำให้พรอมต์จำนวนมากมีกฎต่อต้านการจัดรูปแบบ Fable 5.1 กลับกันคือ: ใช้ตัวหนาน้อยลง, หัวข้อและรายการน้อยลง กฎเก่าเหล่านั้นตอนนี้กลับไปยับยั้งโครงสร้างที่เนื้อหาต้องการ
วิธีแก้ไข. ลบภาษาที่ต่อต้านการจัดรูปแบบออก หรือแทนที่ด้วยกฎที่ระบุว่าเมื่อใดการจัดรูปแบบมีประโยชน์: ใช้รายการเมื่อถูกร้องขอหรือเมื่อเนื้อหามีหลายแง่มุมมากพอที่จะช่วยให้เกิดความชัดเจน; เคารพคำขอที่ชัดเจนสำหรับการจัดรูปแบบที่น้อยที่สุด; ใช้สำนวนธรรมดาในการแลกเปลี่ยนบทสนทนาหรืออารมณ์
การสรุปจะสร้างคำพูดจากแหล่งที่มาซ้ำโดยไม่ระบุว่าเป็นคำพูด
การเปลี่ยนแปลง. เมื่อสรุปเอกสาร Fable 5.1 มีแนวโน้มที่จะทำซ้ำข้อความจากแหล่งที่มาโดยไม่ระบุว่าเป็นคำพูดมากกว่า Fable 5
วิธีแก้ไข. เพิ่มตัวอย่างที่สมบูรณ์หนึ่งตัวอย่างลงในพรอมต์ระบบ: คำร้องขอของผู้ใช้, การตอบสนองที่ถูกต้องที่สื่อถึงแต่ละแหล่งข้อมูลด้วยคำพูดทางอ้อมของผู้ช่วย โดยมีคำพูดที่ถูกระบุไม่เกินหนึ่งคำพูดสั้นๆ, และเหตุผลหนึ่งประโยคที่อธิบายว่าทำไมจึงถูกต้อง แทนที่ตัวยึดตำแหน่งการเรียกใช้เครื่องมือในตัวอย่างของ Anthropic ด้วยชื่อเครื่องมือของคุณเอง
ตอบจากความจำแทนการค้นหาเมื่อใช้ความพยายามต่ำ
การเปลี่ยนแปลง. ที่ความพยายาม low Fable 5.1 จะเรียกใช้เครื่องมือค้นหาและเรียกข้อมูลน้อยกว่า Fable 5 ซึ่งเห็นได้ชัดที่สุดสำหรับผลิตภัณฑ์และโมเดลที่มีชื่อที่มันรู้จักแต่มีข้อมูลเก่า
สองวิธีแก้ไข. เพิ่มความพยายามสำหรับรอบที่ได้รับผลกระทบด้วยความพยายามต่อข้อความ หรือบอกโมเดลในพรอมต์ระบบว่าการจดจำชื่อจากพื้นที่ที่เปลี่ยนแปลงรวดเร็วไม่เหมือนกับการรู้สถานะปัจจุบันของมัน ว่าควรค้นหาก่อนตอบ และว่าควรใส่ชื่อตามที่ผู้ใช้เขียนไว้ในคำค้นหาอย่างน้อยหนึ่งครั้ง
งานส่งมอบที่ยาวนานที่ xhigh และ max ใช้เวลานานเกินไป
การเปลี่ยนแปลง. ที่ xhigh และโดยเฉพาะอย่างยิ่ง max Fable 5.1 สามารถร่างส่วนใหญ่ของงานส่งมอบที่ยาวนานในระหว่างการคิด แล้วเขียนซ้ำอีกครั้งเป็นคำตอบ ซึ่งจะเพิ่มระยะเวลารอและโทเค็นเอาต์พุตเป็นสองเท่า
สองวิธีแก้ไข. รันคำร้องขอเหล่านั้นที่ high และเลื่อนขึ้นไปเฉพาะเมื่อคุณวัดผลได้ว่ามีประสิทธิภาพดีขึ้น หากคุณยังคงอยู่ที่ xhigh หรือ max ให้ตั้งค่า max_tokens เพื่อให้มีพื้นที่สำหรับการคิดและการตอบกลับ และเพิ่มบันทึกในข้อความผู้ใช้ระบุว่าทุกสิ่งที่ผลิตในการตอบกลับครั้งเดียว รวมถึงเหตุผลด้วย นับรวมเป็นขีดจำกัดเดียวประมาณ max_tokens จริงของคุณ และการสร้างงานส่งมอบฉบับเต็มเป็นเหตุผลและอีกครั้งเป็นคำตอบจะเพิ่มรอบเป็นสองเท่าโดยไม่ปรับปรุงอะไรเลย คงสำเนาบันทึกก่อนหน้าไว้ในคำร้องขอถัดไป
คำร้องขอการเขียนโค้ดที่ไม่เป็นอันตรายถูกปฏิเสธ
การเปลี่ยนแปลง. ตัวแยกประเภทของ Fable 5.1 สร้างผลบวกลวงน้อยกว่าที่ Fable 5 ทำเมื่อเปิดตัว และตอนนี้การค้นหาช่องโหว่ในซอร์สโค้ดก็ได้รับอนุญาตแล้ว แต่ก็ยังคงเกิดผลบวกลวงอยู่
สามวลีที่ต้องเปลี่ยน. ถามว่า “Are there any bugs in this program?” แทนที่จะเป็น “Does this program compile without errors?” ให้เอกสารสำหรับภาษาที่ไม่ค่อยเป็นที่รู้จักแก่โมเดล ลบเครื่องมือที่ส่งคืนข้อมูลที่เข้ารหัส base64 เข้าสู่บริบท คงค่า fallbacks ที่กำหนดค่าไว้เสมอ; คู่มือการจัดการการปฏิเสธ ครอบคลุมเรื่องนี้
สรุปการบีบอัดฝั่งไคลเอ็นต์ทิ้งรายละเอียด
Fable 5.1 ตอบสนองได้ดีเมื่อถูกบอกอย่างชัดเจนว่าสรุปการบีบอัดจะต้องเก็บรายละเอียดอะไรบ้าง การบีบอัดฝั่งเซิร์ฟเวอร์ทำสิ่งนี้อยู่แล้ว หากคุณบีบอัดข้อมูลฝั่งไคลเอ็นต์ ให้สั่งให้โมเดลสรุปภายในแท็ก <summary> และรักษาตามลำดับ: ปัญหาที่เกิดขึ้นและวิธีแก้ไข; แนวทางที่เสนอหรือถูกพักไว้และเหตุผล; สิ่งที่ถูกร้องขอหรือตัดสินใจ โดยระบุให้ชัดเจน; สถานการณ์ปัจจุบัน; สิ่งที่ยังไม่เสร็จสิ้น; และรายละเอียดที่ยากต่อการสร้างใหม่ เช่น ชื่อ, ตัวเลข, และลิงก์ ปิดท้ายด้วย “Do not call any tools while writing this summary; respond with text only” ซึ่งมีความสำคัญเมื่อคำร้องขอการสรุปยังคงมีเครื่องมือของการสนทนาอยู่
เอเจนต์ย่อยและการมองเห็น
การแก้ไขสองอย่างเป็นเชิงสถาปัตยกรรมมากกว่าพรอมต์ สำหรับงานเขียนโค้ด ให้เอเจนต์หลักทำงานต่อไปในขณะที่เอเจนต์ย่อยกำลังทำงาน: ให้เครื่องมือที่เริ่มเอเจนต์ย่อยส่งคืนค่าทันที, ส่งมอบผลลัพธ์แต่ละรายการในข้อความผู้ใช้ถัดไป, และให้เอเจนต์หลักมีเครื่องมือแยกต่างหากที่สามารถเรียกใช้เมื่อต้องการรอ สำหรับแผนภูมิที่หนาแน่นและตารางซ้อนกัน ให้โมเดลมีเครื่องมือครอบตัดที่ส่งคืนพื้นที่ที่เลือกแบบขยายใหญ่ขึ้น หรือคอนเทนเนอร์ที่มีไลบรารีรูปภาพพื้นฐาน; ที่ความพยายาม low มันอาจข้ามการครอบตัด ดังนั้นให้ตรวจสอบบันทึกสำหรับการเรียกใช้
การทดสอบการเปลี่ยนแปลงพรอมต์ใน Apidog
การแก้ไขทุกอย่างข้างต้นเป็นสิ่งที่สามารถนำมาทดสอบแบบก่อนและหลังได้ ใน Apidog ให้บันทึกสามรอบแรกของลูปเอเจนต์ของคุณเป็นลำดับคำขอ, กำหนดพารามิเตอร์พรอมต์ระบบ, และรันโดยมีและไม่มีแต่ละส่วนย่อยด้วยความพยายามเท่ากัน ตรวจสอบจำนวนบล็อก tool_use ต่อรอบผู้ช่วยสำหรับการแก้ไขการรวมกลุ่ม, ตรวจสอบ usage.output_tokens สำหรับการแก้ไขการแก้ไขแบบกำหนดเป้าหมายและความหนาแน่น, และการไม่มีวรรคสุดท้ายที่เริ่มต้นด้วย “Next, I” สำหรับการแก้ไขความเป็นอิสระ ดาวน์โหลด Apidog เพื่อสร้างมัน; คู่มือ Claude Code แสดงให้เห็นว่าบรรทัดใดบ้างที่ควรอยู่ในไฟล์ CLAUDE.md
คำถามที่พบบ่อย
พรอมต์ Fable 5 ของฉันใช้งานได้บน Fable 5.1 หรือไม่? Anthropic ระบุว่าควรทำงานได้ดีโดยไม่ต้องเปลี่ยนแปลง ความแตกต่างอยู่ที่พฤติกรรม: การเรียกใช้เครื่องมือแบบกลุ่มน้อยลง, การอัปเดตความคืบหน้าน้อยลง, สำนวนที่หนาแน่นขึ้น, การจัดรูปแบบการแชทน้อยลง, การเขียนไฟล์ทั้งหมดใหม่, และขอบเขตงานที่ขยายออกไปในงานปลายเปิด
ฉันควรใช้ระดับความพยายามใดในการสร้างพรอมต์ Fable 5.1? เริ่มต้นที่ high และทำการทดสอบ Anthropic ระบุว่า medium ให้ผลลัพธ์ใกล้เคียงกับ Fable 5 โดยมีค่าใช้จ่ายที่ต่ำกว่า และ low มักจะแข่งขันได้กับ Opus และ Sonnet ในด้านค่าใช้จ่ายต่องาน
ฉันควรวางคำสั่งต่อรอบบน Fable 5.1 ไว้ที่ไหน? เป็นข้อความระบบแบบขอบเขตต่อรอบพร้อม clear_at: "next_user_message" หลังผลลัพธ์ของเครื่องมือ โดยคงสำเนาที่เก่ากว่าไว้ การแทรกและลบข้อความจากการสนทนารอบก่อนหน้าจะทำให้บล็อกความคิดที่ตามมาไม่ถูกต้องและรีสตาร์ทแคช
ฉันควรลบคำสั่ง “ตรวจสอบงานของคุณ” เหมือนที่ทำใน Opus 5 หรือไม่? ไม่ นั่นเป็นคำแนะนำเฉพาะสำหรับการตรวจสอบที่มากเกินไปของ Opus 5 ให้คงคำสั่งเหล่านี้ไว้บน Fable 5.1
ฉันจะหยุด Fable 5.1 ไม่ให้เขียนไฟล์ทั้งหมดใหม่ได้อย่างไร? หนึ่งบรรทัดในพรอมต์ระบบหรือข้อความผู้ใช้แรก: ลดโทเค็นที่ใช้ในการแก้ไขไฟล์ และแก้ไขเฉพาะส่วนที่จำเป็นแทนการเขียนใหม่ทั้งหมดเมื่อไม่ส่งผลกระทบต่อผลลัพธ์