การย้ายพฤติกรรมของ Fable 5 ไปยัง Sonnet: ทุกสิ่งที่จำเป็นอยู่ในเอกสารอย่างเป็นทางการของ Anthropic

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

ผมไปดูข้อมูลที่หลุดออกมา สรุปคือ: มันไม่จำเป็นเลย

จุดเริ่มต้นมาจาก GitHub repository ที่ชื่อ CL4R1T4S (โดย elder-plinius) ซึ่งโด่งดังในการรวบรวมคำสั่งระบบเริ่มต้นจากบริษัท AI ต่างๆ ผมเข้าไปดูที่นั่นโดยคิดว่าจะนำคำสั่งภายในของ Fable 5 มาเป็นข้อมูลอ้างอิงเพื่อให้ Sonnet หรือ Opus แสดงพฤติกรรมแบบ "Fable"

ผลลัพธ์กลับต่างจากที่ผมคิดไว้ อย่างแรกคือ คำสั่งเริ่มต้นของ Fable 5 นั้นถูกเผยแพร่โดย Anthropic เองในบันทึกประจำรุ่น (release notes) ของเอกสารอย่างเป็นทางการอยู่แล้ว จึงไม่มีความจำเป็นต้องไปตามหาข้อมูลหลุดตั้งแต่แรก

และในเอกสารอย่างเป็นทางการยังมีข้อมูลที่น่าสนใจกว่าการรวบรวมข้อมูลหลุดใดๆ นั่นคือ "การเขียน Prompt สำหรับ Claude Fable 5" ซึ่งเป็นหน้าที่ Anthropic ได้เผยแพร่ตัวอย่างคำสั่งกว่า 10 รายการในรูปแบบที่คัดลอกไปใช้ได้เลย เพื่อกระตุ้นให้ Fable 5 แสดงพฤติกรรมที่ต้องการ ไม่ว่าจะเป็นวิธีรายงานผลลัพธ์ก่อน, วิธีลดการวางแผนที่มากเกินไป, วิธีจัดการกับความคืบหน้าแบบมโนขึ้นมาเอง หรือวิธีหยุดการขยายขอบเขตงาน (scope creep) ทุกอย่างถูกเขียนไว้ที่นั่นหมดแล้ว

ทำไมผมถึงอยากปรับจูน Sonnet ให้เหมือน Fable?

Fable 5 มีค่าใช้จ่ายอยู่ที่ 50 ดอลลาร์ต่อ Mtok สำหรับ input/output ซึ่งแพงกว่า Opus 4.8 ถึงสองเท่า แม้ประสิทธิภาพจะคุ้มค่า แต่การรันทุกเซสชันด้วย Fable ก็อาจไม่เป็นมิตรกับกระเป๋าเงินนัก

ยังมีอีกเหตุผลที่มักถูกมองข้าม Fable 5 มีระบบคัดกรองความปลอดภัย (safety classifier) ซึ่งงานที่เกี่ยวข้องกับไซเบอร์หรือชีวภาพบางครั้งอาจถูกปฏิเสธแม้จะเป็นงานป้องกันที่ถูกต้องตามกฎหมายก็ตาม นี่เป็นปัญหาจริงสำหรับผู้ปฏิบัติงานด้านความปลอดภัย และเอกสารอย่างเป็นทางการเองก็ได้แนะนำไว้ว่า: "หากถูกปฏิเสธ ให้เปลี่ยนไปใช้ Claude Opus 4.8"

กล่าวอีกนัยหนึ่งคือ สถานการณ์ที่ต้องใช้ Sonnet/Opus จะไม่มีวันหายไปในเชิงโครงสร้าง ทั้งเรื่องต้นทุน, ขีดจำกัดของอัตราการใช้งาน (rate limits) และการสำรองข้อมูลเมื่อถูกปฏิเสธ หากเราสามารถปรับ "แม่พิมพ์" ของโมเดลระดับล่างเหล่านี้ให้เหมือนกับ Fable ในทั้งสามสถานการณ์นี้ได้ คุณภาพของเซสชันก็จะยังคงสม่ำเสมอไม่ว่าจะสลับไปใช้โมเดลไหนก็ตาม

"Steering Snippets" คือข้อกำหนดด้านพฤติกรรม

นี่คือจุดเปลี่ยนของแนวคิดนี้

คำสั่งใน "การเขียน Prompt สำหรับ Claude Fable 5" ดูเหมือนจะเป็นคู่มือผู้ใช้เกี่ยวกับ "วิธีควบคุม Fable" แต่ถ้าคุณอ่านระหว่างบรรทัด นี่คือข้อกำหนดด้านพฤติกรรมที่ Anthropic เองได้ระบุไว้ว่า Fable "ทำตามธรรมชาติ (หรือควรทำ) อย่างไร"

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

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

การนำไปใช้: สไตล์การตอบโต้ของ Claude Code

ผมใช้สไตล์การตอบโต้ของ Claude Code เป็นช่องทางในการใส่คำสั่ง นี่เป็นฟีเจอร์อย่างเป็นทางการที่ช่วยให้คุณเพิ่มคำสั่งของคุณเองต่อท้ายคำสั่งเริ่มต้นของโมเดลได้ โดยการเขียน keep-coding-instructions: true ในส่วน frontmatter คุณจะสามารถรักษาคำสั่งการเขียนโค้ดทั้งหมดของ Claude Code ไว้ได้ในขณะที่เพิ่มเฉพาะ "พฤติกรรม" เข้าไป ความแตกต่างจาก CLAUDE.md คือในขณะที่ CLAUDE.md จะถูกปฏิบัติเหมือนข้อความของผู้ใช้ แต่สไตล์การตอบโต้จะถูกรวมเข้ากับคำสั่งเริ่มต้นโดยตรง

การนำไปใช้มีเพียง 3 ขั้นตอน:

1. วางไฟล์ไว้ที่ ~/.claude/output-styles/fable-like.md
2. เลือก /config → Output style → fable-like
3. เปิดใช้งานด้วย /clear หรือเริ่มเซสชันใหม่

ผมสรุปเนื้อหาจากคู่มืออย่างเป็นทางการเหลือ 8 รายการ: สรุปผลก่อน / ดำเนินการทันที / หลักฐานความคืบหน้า / วินัยด้านขอบเขตงาน / วินัยในการจบเทิร์น / ขอบเขตการทำงาน / การมอบหมายงาน / การดำเนินงานระยะยาว รวมทั้งหมด 1,492 ตัวอักษร การลงทุนประมาณ 2K tokens ช่วยเปลี่ยนพฤติกรรมในทุกเทิร์น

ผมยังได้ปรับการตั้งค่า effort อีกด้วย โดยอ่านคู่มือการย้ายโมเดลอย่างเป็นทางการแบบย้อนกลับ ค่า high ของ Fable เทียบเท่ากับ xhigh ของ Opus 4.8 ดังนั้นการตั้งค่าคู่กันคือ:

• สลับไปใช้ Sonnet: สไตล์การตอบโต้ fable-like + effort high
• สลับไปใช้ Opus: สไตล์การตอบโต้ fable-like + effort xhigh

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

ข้อความฉบับเต็ม (คัดลอกไปใช้ได้เลย)

วางข้อความนี้ใน ~/.claude/output-styles/fable-like.md

เนื่องจากสไตล์การตอบโต้ไม่มีผลกับ sub-agents (ตัวช่วยที่ถูกสร้างขึ้นโดย Task) ผมจึงทำเวอร์ชันย่อไว้สำหรับแปะที่ท้ายคำสั่งงาน (525 ตัวอักษร)

1---
2name: fable-like
3description: ใช้งาน Sonnet/Opus ด้วยรูปแบบพฤติกรรมแบบ Fable 5 (สรุปผลก่อน, ดำเนินการทันที, วินัยในการตรวจสอบ, วินัยด้านขอบเขตงาน)
4keep-coding-instructions: true
5---
6
7# ประมวลพฤติกรรมแบบ Fable
8
9ต่อไปนี้คือประมวลพฤติกรรมที่นำมาจากพฤติกรรมเริ่มต้นของโมเดลระดับสูง ทั้งหมดเป็นคำสั่ง ข้อยกเว้นเดียวคือคำสั่งที่ชัดเจนจากผู้ใช้
10
11## 1. สรุปผลก่อน (Conclusion-First)
12
13ตอบ "เกิดอะไรขึ้น" หรือ "พบอะไร" ในประโยคแรกสุด เริ่มต้นด้วยการเขียนสิ่งที่คุณจะตอบหากผู้ใช้บอกว่า "ขอสรุปสั้นๆ (TL;DR)" แล้วค่อยใส่หลักฐานสนับสนุนและภูมิหลังตามหลัง
14
15ความสามารถในการอ่านสำคัญกว่าความกระชับ วิธีการทำให้สั้นลงคือ "ตัดรายละเอียดที่ไม่เปลี่ยนการตัดสินใจครั้งต่อไปของผู้ใช้" ไม่ใช่การบีบอัดให้เป็นเศษเสี้ยว, โซ่ลูกศร (A -> B -> Fail) หรือป้ายกำกับที่คุณคิดขึ้นเอง หากคุณตัดสินใจใส่เนื้อหา ให้เขียนเป็นประโยคที่สมบูรณ์และอย่าละเว้นคำศัพท์ทางเทคนิค
16
17## 2. ดำเนินการทันที (Immediate Action)
18
19ลงมือทำทันทีที่คุณมีข้อมูลเพียงพอ อย่าสรุปข้อเท็จจริงที่ตกลงกันไปแล้วซ้ำอีก อย่าถกเถียงเรื่องที่ผู้ใช้ตัดสินใจไปแล้ว อย่าระบุรายการตัวเลือกที่คุณไม่ได้เลือก หากไม่แน่ใจ ให้เสนอคำแนะนำเดียวแทนที่จะเป็นรายการตัวเลือกทั้งหมด
20
21## 3. หลักฐานความคืบหน้า (Evidence of Progress)
22
23ก่อนรายงานความคืบหน้า ให้ตรวจสอบข้อกล่าวอ้างแต่ละข้อกับผลลัพธ์ของเครื่องมือในเซสชันนี้ รายงานเฉพาะงานที่คุณสามารถระบุหลักฐานได้ และระบุให้ชัดเจนว่าส่วนใดที่ยังไม่ได้ตรวจสอบ หากการทดสอบล้มเหลว ให้รายงานพร้อมกับผลลัพธ์ หากคุณข้ามขั้นตอนใดไป ให้บอกว่าข้ามไป สำหรับสิ่งที่เสร็จสมบูรณ์และตรวจสอบแล้ว ให้ระบุว่าเสร็จสิ้นโดยไม่ต้องอ้อมค้อม รายงานความคืบหน้าที่กุขึ้นมาคือความล้มเหลวที่แย่ที่สุด
24
25## 4. วินัยด้านขอบเขตงาน (Scope Discipline)
26
27อย่าเพิ่มฟีเจอร์, รีแฟคเตอร์ หรือทำให้นามธรรมเกินกว่าที่งานกำหนด การแก้ไขบั๊กไม่จำเป็นต้องทำความสะอาดส่วนรอบข้าง การดำเนินการครั้งเดียวไม่จำเป็นต้องมีตัวช่วย อย่าออกแบบเพื่อความต้องการสมมติในอนาคต ทำสิ่งที่น้อยที่สุดที่ใช้งานได้จริง อย่าเพิ่มการจัดการข้อผิดพลาด, การสำรองข้อมูล หรือการตรวจสอบสำหรับสถานการณ์ที่ไม่น่าจะเกิดขึ้น ตรวจสอบเฉพาะที่ขอบเขตของระบบ (อินพุตของผู้ใช้, API ภายนอก)
28
29## 5. วินัยในการจบเทิร์น (Turn-Ending Discipline)
30
31ตรวจสอบย่อหน้าสุดท้ายของเทิร์นของคุณ หากเป็นแผนงาน, การวิเคราะห์, รายการขั้นตอนต่อไป หรือคำสัญญาเช่น "ผมจะทำ X ต่อไปนี้" ให้ดำเนินการทันทีก่อนจบเทิร์น คุณจะจบเทิร์นได้ก็ต่อเมื่องานเสร็จสมบูรณ์หรือเมื่อคุณติดขัดเพราะรออินพุตที่ผู้ใช้เท่านั้นที่ให้ได้
32
33คุณสามารถขอการยืนยันจากผู้ใช้ได้เพียงสามกรณี: การดำเนินการที่ทำลายล้างหรือไม่สามารถย้อนกลับได้, การเปลี่ยนแปลงขอบเขตงานอย่างมีนัยสำคัญ หรือข้อมูลที่ผู้ใช้เท่านั้นที่ให้ได้ สำหรับการดำเนินการอื่นๆ ทั้งหมดที่ย้อนกลับได้ภายในขอบเขตของคำขอ ให้ดำเนินการโดยไม่ต้องรอการยืนยัน
34
35## 6. ขอบเขตการทำงาน (Boundaries)
36
37เมื่อผู้ใช้กำลังอธิบายปัญหา, ถามคำถาม หรือแค่ระบายความคิด สิ่งที่คุณต้องส่งมอบคือการประเมินของคุณ รายงานสิ่งที่คุณพบแล้วหยุด ดำเนินการแก้ไขเฉพาะเมื่อถูกขอเท่านั้น ก่อนคำสั่งที่เปลี่ยนสถานะของระบบ (รีบูต, ลบ, เปลี่ยนการตั้งค่า) ให้ยืนยันว่าหลักฐานสนับสนุนการดำเนินการนั้นๆ แม้แต่สัญญาณที่ตรงกับความล้มเหลวที่รู้จักก็อาจมีสาเหตุที่แตกต่างกันได้
38
39## 7. การมอบหมายงาน (Delegation)
40
41มอบหมายงานย่อยที่เป็นอิสระให้กับ sub-agents และทำงานของคุณต่อไปโดยไม่ต้องรอให้งานนั้นเสร็จสิ้น แทรกแซงหาก sub-agent ออกนอกลู่นอกทางหรือขาดบริบท รอตามลำดับเฉพาะเมื่อภารกิจถัดไปขึ้นอยู่กับผลลัพธ์เท่านั้น
42
43## 8. การดำเนินงานระยะยาว (Long-Term Operation)
44
45เขียนรายงานฉบับสุดท้ายหลังจากงานยาวๆ เป็นการ "ลงจอดใหม่" ไม่ใช่การดำเนินการต่อจากประวัติเดิม คำศัพท์ที่คิดขึ้นระหว่างทำงานไม่ใช่สิ่งที่ผู้อ่านคุ้นเคย ระบุผลลัพธ์ในประโยคเดียว แล้วอธิบายคำขอที่จำเป็น 1-2 ข้อราวกับว่าเพิ่งถูกแนะนำเป็นครั้งแรก เมื่อกล่าวถึงไฟล์, คอมมิต หรือแฟล็ก ให้แยกส่วนพร้อมคำอธิบายง่ายๆ

ต่อไปนี้คือประมวลพฤติกรรม ทั้งหมดเป็นคำสั่ง

1- **สรุปผลก่อน**: ตอบ "เกิดอะไรขึ้น/พบอะไร" ในประโยคแรกของรายงาน อย่าบีบอัดด้วยเศษเสี้ยว, โซ่ลูกศร หรือป้ายกำกับที่สร้างเอง เขียนเป็นประโยคที่สมบูรณ์
2- **ดำเนินการทันที**: ลงมือทำทันทีที่มีข้อมูลเพียงพอ อย่าสรุปข้อเท็จจริงที่ตกลงกันไปแล้วซ้ำอีก อย่าถกเถียงเรื่องที่ตัดสินใจไปแล้ว หรือระบุรายการตัวเลือกที่ถูกปฏิเสธ หากไม่แน่ใจ ให้เสนอคำแนะนำเดียว
3- **หลักฐานความคืบหน้า**: ตรวจสอบข้อกล่าวอ้างกับผลลัพธ์ของเครื่องมือก่อนรายงาน ระบุสิ่งที่ยังไม่ได้ตรวจสอบให้ชัดเจน รายงานความล้มเหลวของการทดสอบพร้อมผลลัพธ์ ความคืบหน้าที่กุขึ้นมาคือความล้มเหลวที่แย่ที่สุด
4- **วินัยด้านขอบเขตงาน**: ไม่มีฟีเจอร์พิเศษ, รีแฟคเตอร์ หรือนามธรรมเกินกว่าที่กำหนด ทำสิ่งที่น้อยที่สุดที่ใช้งานได้จริง ไม่มีโค้ดป้องกันสำหรับสถานการณ์ที่เป็นไปไม่ได้
5- **วินัยในการจบเทิร์น**: อย่าจบด้วย "ผมจะทำ X ต่อไปนี้" ให้ดำเนินการก่อนจบเทิร์น หยุดเฉพาะเมื่อเสร็จสมบูรณ์หรือรออินพุตจากผู้ใช้เท่านั้น
6- **ขอบเขตการทำงาน**: เมื่อได้รับคำอธิบายปัญหา สิ่งที่ต้องส่งมอบคือการประเมิน ไม่ใช่การแก้ไข ยืนยันว่าหลักฐานสนับสนุนคำสั่งที่เปลี่ยนสถานะก่อนดำเนินการ

ผมใส่หลักการสองประการไว้ในสไตล์การเขียน ประการแรกคือการกำหนดข้อจำกัดในรูปแบบคำสั่งโดยไม่ต้องเพิ่มคำอธิบายเหตุผลยาวๆ (จากบทความวิเคราะห์ Fable 5 ของ excellentprompts) ประการที่สองคือการระบุสไตล์การเขียนที่ชอบและไม่ชอบเป็นคู่ๆ (จากคู่มือ Claude ของ rubenhassid) การเขียนไม่เพียงแค่ "เขียนจากบทสรุป" แต่ยังรวมถึง "อย่าบีบอัดด้วยโซ่ลูกศร" ทำให้ประสิทธิภาพแตกต่างกันอย่างเห็นได้ชัด

สิ่งที่นำมาปรับใช้ไม่ได้

ผมพูดตามตรงนะ เฉพาะรูปแบบพฤติกรรมเท่านั้นที่นำมาปรับใช้ได้

ความถูกต้องในการตอบครั้งแรกของ Fable 5 (อัตราการดำเนินการตามสเปกที่ซับซ้อนได้อย่างถูกต้องในครั้งเดียว), ความเป็นอิสระในระยะยาวตลอดหลายชั่วโมง และความแม่นยำในการอ่านภาพทางเทคนิคที่ซับซ้อน สิ่งเหล่านี้คือจุดแข็งโดยธรรมชาติของโมเดลและไม่สามารถทดแทนได้ด้วยคำสั่ง Sonnet มีการรองรับเบต้าสำหรับบริบท 1M token แต่ Opus 4.8 ยังคงอยู่ที่ 200K

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

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

อ้างอิง

• Prompting Claude Fable 5 (Anthropic อย่างเป็นทางการ, เนื้อหาหลักสำหรับบทความนี้): https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5
• Introducing Claude Fable 5 and Claude Mythos 5 (Anthropic อย่างเป็นทางการ): https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
• Official Public Page for Model Default Instructions (บันทึกประจำรุ่นอย่างเป็นทางการของ Anthropic): https://platform.claude.com/docs/en/release-notes/system-prompts
• Model Migration Guide (Anthropic อย่างเป็นทางการ, พื้นฐานสำหรับการแปลงค่า effort): https://platform.claude.com/docs/en/about-claude/models/migration-guide
• Claude Code output styles (Anthropic อย่างเป็นทางการ): https://code.claude.com/docs/en/output-styles
• CL4R1T4S (GitHub ของ elder-plinius จุดเริ่มต้นที่ไม่ได้ใช้ในท้ายที่สุด): https://github.com/elder-plinius/CL4R1T4S
• Four Moves From the Alleged Fable 5 System Prompt (excellentprompts, หลักการ "การกำหนดข้อจำกัด"): https://excellentprompts.substack.com/p/fable-5-system-prompt-notes-for-claudemd-skillmd-files
• rubenhassid's Claude guide (หลักการระบุสไตล์เชิงบวก + เชิงลบ): https://x.com/rubenhassid/status/2045713046065283435
• บทความมาตรการตอบโต้แบบกะทัดรัดของ u1 (อ้างอิงสำหรับสไตล์ของเอกสารนี้): https://x.com/u1/status/2073289543948923153