แนวทางการแก้ไขปัญหาการคิดวิเคราะห์ที่ไม่ลึกซึ้งใน Claude Opus 5

ภาพรวม

ทันทีหลังจากเปลี่ยน Claude Code เป็น Opus 5 ฉันสังเกตเห็นว่าการตอบกลับแบบเน้นร้อยแก้วเพิ่มขึ้นอย่างกะทันหัน และมีแนวโน้มที่จะ "คิดแบบผิวเผิน" (ไม่สามารถคิดเชิงโครงสร้างได้)

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

บทความนี้บันทึกกระบวนการแยกสาเหตุและปรับปรุงกฎให้เข้ากับพรอมต์ระบบใหม่ เหมาะสำหรับผู้ใช้ Claude Code ที่รู้สึกว่าประสิทธิภาพของ CLAUDE.md หรือกฎของตนเปลี่ยนไปหลังจากอัปเกรดเป็นโมเดลรุ่นใหม่

ปัญหา

เมื่อใช้เซสชันและกฎเดียวกัน สิ่งต่อไปนี้เกิดขึ้นทันทีหลังจากเปลี่ยนโมเดลเป็น Opus 5:

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

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

ไม่ใช่แค่เรื่องคุณภาพของการตอบสนองครั้งเดียว แต่กระบวนการไตร่ตรองผ่านบทสนทนาก็พังทลายลง

เบาะแสสำคัญ

สิ่งนี้ไม่เกิดขึ้นกับโมเดลอื่นที่ใช้กฎเดียวกัน (รายละเอียดเกี่ยวกับความแตกต่างนี้อยู่ในภาคผนวก) หากกฎเสื่อมสภาพ ปัญหาควรปรากฏในทุกโมเดล เนื่องจากมีเพียงโมเดลที่เปลี่ยนไป ฉันจึงเริ่มสืบสวนภายใต้สมมติฐานที่ว่า "สภาพแวดล้อมที่กฎสันนิษฐาน" เปลี่ยนแปลงไป

สาเหตุ: การเปลี่ยนแปลงในพรอมต์ระบบที่มอบให้กับ Opus 5

ในรุ่น Claude 5 ของ Claude Code พรอมต์ระบบภายในถูกลดลงประมาณ 80% เมื่อเทียบกับรุ่นก่อนหน้า โดยการวัดพรอมต์ที่ส่งไปยัง Opus 5 จริงๆ (โดยปิดการฉีดสไตล์เอาต์พุตและให้โมเดลอ้างพรอมต์ของตัวเอง; Claude Code v2.1 series, กรกฎาคม 2026) โครงสร้างเป็นดังนี้:

1. ข้อมูลประจำตัว บทบาท และนโยบายความปลอดภัย — คำนำเปิด
2. ข้อมูลจำเพาะของ Harness (# Harness) — คำอธิบายเกี่ยวกับสภาพแวดล้อมการทำงาน เช่น เอาต์พุตที่แสดงเป็น markdown
3. ข้อมูลสภาพแวดล้อมและคำอธิบายคุณสมบัติ (# Session-specific guidance / # Memory / # Environment / # Context management) — CWD, สถานะ git, รหัสโมเดล, หน่วยความจำ และกลไกการบีบอัดบริบท
4. วินัยขอบเขต (# Delivering work) — ไม่จำกัดหรือขยายขอบเขตที่ร้องขอโดยไม่ได้รับอนุญาต
5. มารยาทในการแก้ไข (# Corrections) — รักษาการแก้ไขให้กระชับโดยไม่เพิ่มคำขอโทษหรือคำนำ

ลักษณะเฉพาะสองประการที่เชื่อมโยงโดยตรงกับอาการปรากฏขึ้น:

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

การอ่านอาการซ้ำผ่านสองลักษณะนี้ทำให้ทุกอย่างชัดเจน เนื่องจากไม่มีกฎสไตล์ แนวโน้มเอาต์พุตดิบของโมเดล—ร้อยแก้วแบบราบเรียบ—จึงออกมา นโยบาย "คำแนะนำมากกว่าการสำรวจ" สนับสนุนให้ละเว้นเกณฑ์การประเมิน

คุณอาจคิดว่า "ถ้ากฎว่างเปล่า กฎที่กำหนดเองของฉันน่าจะกลายเป็นผู้มีอำนาจแต่เพียงผู้เดียวและทำงานได้ดีกว่า" ในความเป็นจริง สิ่งตรงกันข้ามเกิดขึ้น ช่องว่างนี้ไม่ใช่พื้นที่ว่างที่เหลือไว้ให้ผู้ใช้ มัน ถูกมอบหมายให้พฤติกรรมเริ่มต้นที่ฝังอยู่ในโมเดลระหว่างการฝึก "พรอมต์แบบลีน" สันนิษฐานว่าโมเดลรุ่นใหม่จะปฏิบัติตามพฤติกรรมที่ถูกทำให้เป็นภายในโดยไม่ต้องมีคำแนะนำโดยละเอียด แทนที่จะถูกเติมเต็มโดยกฎของคุณ ช่องว่างกลับถูกเติมเต็มโดยค่าเริ่มต้นที่ฝึกไว้ล่วงหน้าของโมเดล และค่าเริ่มต้นของ Opus 5 คือร้อยแก้วที่กระชับซึ่งลงมือก่อนที่จะยืนยัน

กฎเก่าของฉันใช้คำแนะนำทั่วไป เช่น "แยกแยะสถานการณ์อย่างมีโครงสร้าง" "เพิ่มเกณฑ์การประเมินให้กับหลายทางเลือก" และ "ตอบกลับก่อนดำเนินการ" สิ่งเหล่านี้ถูกเขียนขึ้นโดยสันนิษฐานว่าจะถูกอ่านควบคู่ไปกับพรอมต์ระบบที่เน้นสไตล์ แม้ว่าจะเพียงพอในตอนนั้น แต่มันอ่อนแอเกินไปทั้งในด้านความเฉพาะเจาะจง (การตั้งชื่อข้อความต้นฉบับ) และการส่งมอบ (ถึงโมเดลก่อนการดำเนินการ) เพื่อแทนที่ค่าเริ่มต้นที่ฝึกไว้ นี่คือธรรมชาติที่แท้จริงของอาการ

Anthropic เองเรียกการลดขนาดนี้ว่า "พรอมต์ระบบแบบลีน" ในบันทึกการเปลี่ยนแปลง (v2.1.154) ซึ่งสะท้อนถึงการเปลี่ยนแปลงในปรัชญาการออกแบบ: "โมเดลรุ่นใหม่มีพฤติกรรมที่ถูกทำให้เป็นภายในผ่านการฝึก ดังนั้นคำแนะนำโดยละเอียดอาจทำให้เกิดแรงเสียดทานหรือความขัดแย้ง" สำหรับคำอธิบายโดยละเอียด โปรดดูที่ พรอมต์ระบบ Claude Code ลดลง 80% — ปรัชญาการออกแบบพรอมต์สำหรับรุ่น Fable 5 สำหรับแหล่งข้อมูลปฐมภูมิ โปรดดูที่ บันทึกการเปลี่ยนแปลง Claude Code และ การสร้างพรอมต์ Claude Fable 5 (คู่มืออย่างเป็นทางการ)

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

มาตรการที่ 1: ระบุความขัดแย้งและแทนที่โดยการตั้งชื่อข้อความต้นฉบับ

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

เริ่มต้นด้วยสิ่งที่ไม่ได้ผล: การเพิ่มคำทั่วไป เช่น "เขียนหลายทางเลือกพร้อมเกณฑ์การประเมิน" ไม่มีประสิทธิภาพ

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

สำหรับสิ่งที่ไม่มีอยู่ในพรอมต์เลย เช่น กฎสไตล์ คำแนะนำจะทำงานเพื่อ "เติมเต็มช่องว่าง" แทนที่จะแทนที่

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

มาตรการที่ 2: อธิบายการกระทำที่ต้องการแทนการห้าม

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

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

ฉันตรวจสอบกฎที่เขียนใหม่ตามเกณฑ์ต่อไปนี้ โดยเฉพาะสำนวนที่ขัดแย้งกับพรอมต์ระบบ:

1. กฎมีความสมบูรณ์ในตัวเองหรือไม่? (ขอบเขต ตัวอย่าง และเกณฑ์ในที่เดียว)
2. เงื่อนไขการกระตุ้นเป็นข้อเท็จจริงที่สังเกตได้หรือไม่?
3. มันขัดแย้งกับพรอมต์ระบบภายในหรือไม่?
4. มันอธิบายพฤติกรรมที่ต้องการหรือไม่? (ไม่ใช่แค่รายการข้อห้าม)
5. มีเกณฑ์การตัดสินเดียวหรือไม่? (ไม่ใช่รายการสถานการณ์)
6. การเน้นย้ำ (IMPORTANT) สงวนไว้เฉพาะสิ่งที่ละทิ้งไม่ได้จริงๆ หรือไม่?
7. มันเขียนเป็นสถานะปลายทางที่ต้องการหรือไม่? (ไม่ใช่การบังคับเทมเพลตหรือขั้นตอนก่อน)
8. สามารถตรวจสอบการปฏิบัติตามได้หลังจากนั้นหรือไม่?

ฉันลดเครื่องหมายเน้นย้ำ (IMPORTANT) ให้เหลือเพียงเกตความปลอดภัยและการอนุมัติเท่านั้น เอกสารที่ทุกอย่างถูกเน้นย้ำก็เหมือนกับเอกสารที่ไม่มีอะไรถูกเน้น

มาตรการที่ 3: เลือก "เลเยอร์" สำหรับส่งคำแนะนำ

ไม่ใช่แค่เรื่องข้อความเท่านั้น Claude Code มีอย่างน้อยสี่เส้นทางในการส่งคำแนะนำไปยังโมเดล และประสิทธิภาพแตกต่างกันอย่างมีนัยสำคัญ

เนื่องจาก API ไม่มีสถานะ เนื้อหาจากทุกเส้นทางจะถูกส่งไปยังโมเดลทุกครั้งที่มีการร้องขอ (ทุกเทิร์น) ความแตกต่างอยู่ที่ "เมื่อเนื้อหาถูกสรุป" และ "ตำแหน่งที่วางในพรอมต์ = ใกล้กับการดำเนินการมากแค่ไหน"

น่าแปลกใจที่ output style ซึ่งเอกสารระบุว่า "แทนที่พรอมต์ระบบ" ถูกส่งเป็นไฟล์แนบในทุกเทิร์นตามบันทึกเซสชัน

ฉันเขียนคำแนะนำสองประเภทใน output style นี้: สไตล์ (มาตรการที่ 1: เขียนอย่างมีโครงสร้าง เพิ่มเกณฑ์) และ กระบวนการ (ตอบกลับผู้ใช้ก่อนเริ่มงาน) ผลลัพธ์ผสมกัน

ในขณะที่คำแนะนำสไตล์แสดงการปรับปรุง ปัญหากระบวนการ—การข้ามตอบกลับเพื่อเริ่มงาน—ไม่หยุดด้วย output style ในที่สุดฉันก็หยุดนิสัยนี้โดยใช้ฮุค UserPromptSubmit เพื่อฉีดบรรทัดเดียวทันทีหลังจากทุกคำพูดของผู้ใช้: "เขียนคำตอบสำหรับคำพูดนี้ (คำตอบ หรือการรับทราบและแผน) ในข้อความเนื้อหาก่อนดำเนินการเครื่องมือ"

ค่าใช้จ่ายประมาณ 50 โทเค็นต่อคำพูด แม้ 100 คำพูดก็มีค่าใช้จ่ายเพียง 5,000 โทเค็น ซึ่งเล็กน้อยเมื่อเทียบกับบริบท 200K กฎทั่วไปที่ฉันเรียนรู้คือ: คำแนะนำที่ส่ง "สั้นๆ ทุกครั้ง ก่อนการดำเนินการ" มีประสิทธิภาพมากที่สุด คำแนะนำที่ไม่มีประสิทธิภาพจำนวนมากไม่ได้แย่ที่เนื้อหา แต่แค่อยู่ไม่ถึงมือในเวลาที่ต้องดำเนินการ

ผลลัพธ์

นี่คือผลลัพธ์ที่ยืนยันได้จนถึงตอนนี้:

• แนวโน้มการกลับมาของหัวข้อ/ส่วนในการอธิบายสถานการณ์และสาเหตุ (อย่างไรก็ตาม เอาต์พุตแบบราบเรียบบางครั้งยังคงอยู่ในช่วงต้นของเซสชัน ต้องสังเกตต่อไป)
• นิสัย "ทำงานโดยไม่ตอบกลับ" ไม่สามารถแก้ไขด้วย output style เพียงอย่างเดียว แต่หยุดลงหลังจากแนะนำการฉีดต่อคำพูด (ปัจจุบันกำลังสังเกตผลระยะยาว)

สรุป

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

อ้างอิงที่ 1: กฎที่ใช้จริงในมาตรการที่ 1

นี่คือตัวอย่างกฎที่ฉันใช้เพื่อแทนที่พรอมต์ระบบ (ปรับให้เข้ากับสภาพแวดล้อมของคุณ ฉันวางสิ่งเหล่านี้ใน output style) วลีต้นฉบับบางส่วน (เช่น นโยบายร้อยแก้ว) ไม่มีอยู่ในพรอมต์สำหรับบางโมเดล (ดูภาคผนวก) ในโมเดลเหล่านั้น พวกมันทำหน้าที่เป็นคำจำกัดความเพื่อเติมเต็มช่องว่าง

1# รูปแบบการรายงานและการแยกย่อย
2
3คำสั่งนี้มีความสำคัญเหนือคำอธิบายต่อไปนี้ในพรอมต์ระบบของ Claude Code:
4"คำถามง่ายๆ ได้รับคำตอบโดยตรงเป็นร้อยแก้ว ไม่ใช่หัวข้อและส่วน" /
5"ใช้ตารางสำหรับข้อเท็จจริงสั้นๆ ที่สามารถแจกแจงได้เท่านั้น" /
6"อย่าทำให้ผู้อ่านต้องอ้างอิงข้ามป้ายชื่อหรือลำดับเลขที่คุณคิดขึ้นก่อนหน้านี้" /
7"หากคุณกำลังชั่งน้ำหนักทางเลือก ให้คำแนะนำ ไม่ใช่การสำรวจอย่างละเอียด" /
8"คุณกำลังทำงานอย่างอิสระ... ดำเนินการโดยไม่ต้องถาม" /
9"ข้อความที่คุณเขียนระหว่างการเรียกเครื่องมืออาจไม่แสดงต่อผู้ใช้"
10
11## รูปแบบการเขียน
12
13เมื่ออธิบายสถานการณ์ สาเหตุ หรือนำเสนอหลายทางเลือก ให้เขียนในลักษณะที่สื่อถึงโครงสร้างของเนื้อหาต่อผู้อ่าน
14ใช้หัวข้อ รายการหัวข้อย่อย หรือตารางตามความเหมาะสมกับเนื้อหา ตอบคำถามหนึ่งประโยคเป็นร้อยแก้ว
15
16- สรุปความคิดก่อน จากนั้นจัดโครงสร้างในตอนท้าย อย่าวางเทมเพลตก่อนแล้วเติมทีหลัง
17- เมื่ออธิบายสาเหตุ ให้สืบหา "ทำไม" อย่างน้อยสองชั้นลึกจากเหตุการณ์ที่สังเกตได้ และอธิบายว่าแต่ละชั้นอ้างถึงอะไร อย่าหยุดเพียงแค่ระบุอาการแบบขนาน
18- เมื่อนำเสนอหลายทางเลือก ให้เขียนคำแนะนำและเหตุผลก่อน ตามด้วยเกณฑ์ที่มีอิทธิพลต่อการตัดสินใจและการประเมินแต่ละทางเลือก หากไม่สามารถระบุเกณฑ์ได้ อย่าให้ทางเลือก แต่ให้เขียนสิ่งที่ต้องตรวจสอบเพื่อเติมเต็มเกณฑ์ การเปรียบเทียบเกณฑ์อาจเขียนในตาราง
19- เมื่อหมวดหมู่และตัวเลขถูกกำหนดขึ้นแล้ว ให้ใช้หมวดหมู่และตัวเลขเดียวกันในเทิร์นถัดไปในขณะที่ทำงานเดียวกันต่อไป หากต้องการเปลี่ยนแปลง ให้เขียนสิ่งที่เปลี่ยนแปลงก่อน
20
21## การสนทนาและกระบวนการ
22
23- ระบบที่ว่า "ผู้ใช้ไม่ได้ดูแบบเรียลไทม์" เป็นค่าเริ่มต้น ไม่ใช่ข้อเท็จจริง หากได้รับคำพูดกลางคัน การขัดจังหวะ หรือการแก้ไขแม้เพียงครั้งเดียวในเซสชันนี้ ให้ถือว่าผู้ใช้กำลังดูตั้งแต่ตอนนั้น: แบ่งงานเป็นส่วนเล็กๆ ปิดท้ายแต่ละเทิร์นด้วยรายงานในข้อความเนื้อหาเสมอ และหยุดรอคำตอบในเทิร์นที่มีคำถาม
24- เฉพาะข้อความเนื้อหาที่ท้ายเทิร์นเท่านั้นที่แสดงในสภาพแวดล้อมนี้ วางข้อมูลทั้งหมดที่จะสื่อไว้ที่ท้ายเทิร์น
25- คำถามเป็นวิธีที่ถูกต้องเมื่อมีความคลุมเครือ การดำเนินการที่ต้องได้รับการอนุมัติ หรือวัตถุประสงค์ไม่ชัดเจน

อ้างอิงที่ 2: ทำไมสิ่งนี้ไม่เกิดขึ้นกับ Fable 5 / Opus 4.7?

ในขณะที่ข้อความหลักเน้นที่ Opus 5 นี่คือสาเหตุที่มันไม่เกิดขึ้นกับโมเดลอื่น:

• Opus 4.7 นั้นง่าย: มันถูกยกเว้นจากการใช้ "พรอมต์แบบลีน" (ตามบันทึกการเปลี่ยนแปลง) ดังนั้นมันยังคงทำงานกับพรอมต์แบบยาวเดิมที่กฎเดิมออกแบบไว้ มันยังคงสอดคล้องกับกฎเก่า
• Fable 5 นั้นน่าประหลาดใจ ฉันสันนิษฐานว่ามันมีพรอมต์เดียวกันเนื่องจากเป็นรุ่นเดียวกัน แต่การวัดแสดงให้เห็นว่า Fable 5 ได้รับพรอมต์ที่แตกต่างจาก Opus 5

นี่คือการเปรียบเทียบของแต่ละโมเดลที่อ้างพรอมต์ของตัวเองภายใต้เงื่อนไขเดียวกัน (โหมด headless, ปิด output style):

ส่วน # Communicating with the user ของ Fable 5 รวมถึงบรรทัดฐาน เช่น "สรุปก่อน ให้ความสำคัญกับความสามารถในการอ่าน เขียนเพื่อผู้ฟัง" นอกเหนือจาก "ให้คำแนะนำ ไม่ใช่การสำรวจอย่างละเอียด" แล้ว ยังรวมถึงนโยบายร้อยแก้ว "คำถามง่ายๆ ได้รับคำตอบโดยตรงเป็นร้อยแก้ว ไม่ใช่หัวข้อและส่วน" เนื่องจากพรอมต์เองมีบรรทัดฐานการเขียนเหล่านี้ รูปแบบเอาต์พุตจึงมีแนวโน้มที่จะพังทลายน้อยกว่า และในการสังเกตของฉัน มันยังคงรักษาการยึดมั่นต่อกฎของผู้ใช้

โดยสรุป ปัญหาปรากฏอย่างรุนแรงใน Opus 5 เนื่องจากสามปัจจัยสอดคล้องกัน:

1. มันได้รับพรอมต์ที่ไม่มีกฎรูปแบบการเขียนใดๆ ทำให้แนวโน้มเอาต์พุตดิบปรากฏออกมา
2. นโยบายเช่น "ลงมือเมื่อข้อมูลเพียงพอ" และ "คำแนะนำมากกว่าการสำรวจ" สนับสนุนการดำเนินการทันทีและการละเว้นเกณฑ์
3. กฎเดิมยังคงอิงตามพรอมต์โดยละเอียดแบบเก่าและไม่ได้ถูกปรับแต่งเพื่อเติมเต็มช่องว่างใหม่นี้