วิธีใช้งาน Fable Method เพื่อเพิ่มทักษะให้ AI Agent

สิ่งที่วิธี Fable กล่าวอ้างไว้จริง

วิธี Fable คือชุดทักษะสำหรับเอเจนต์ขนาดเล็กที่บันทึกนิสัยการทำงานของโมเดลหนึ่งออกมาเป็นขั้นตอนที่เรียงลำดับไว้ เพื่อให้โมเดลอื่นสามารถรันขั้นตอนเดียวกันนั้นได้ รีโพสิทอรีนี้คือ Sahir619/fable-method ซึ่งใช้สัญญาอนุญาตแบบ MIT โดยมีคำอธิบายบรรทัดเดียวของตนเองว่า "วิธีที่ Claude Fable 5 ทำงาน ถูกกลั่นกรองออกมาเป็นทักษะที่โมเดลใดก็รันได้ พร้อมการประเมินผลที่ช่วยรักษาความถูกต้อง" ข้อกล่าวอ้างที่ควรค่าแก่การทดสอบคือส่วนที่สองของประโยคนั้น

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

หากคำว่าทักษะ (skill) เป็นเรื่องใหม่สำหรับคุณ ให้เริ่มต้นที่ ทักษะของเอเจนต์คืออะไรกันแน่: คือโฟลเดอร์ที่เก็บไฟล์ SKILL.md ซึ่งคำอธิบายในส่วน frontmatter จะบอกเอเจนต์ว่าควรโหลดเนื้อหาเมื่อใด โมเดลที่เป็นชื่อของรีโพสิทอรีนี้ถูกกล่าวถึงไว้ใน Claude Fable 5 มีค่าใช้จ่ายเท่าใดและเก่งเรื่องอะไร

ติดตั้งทักษะและตรึงเวอร์ชันที่คุณทดสอบ

มีเส้นทางในการติดตั้งอยู่สองทาง ภายใน Claude Code เส้นทางสำหรับปลั๊กอินประกอบด้วยสองคำสั่ง:

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

บน VPS ในกรณีที่คุณต้องการสำเนาที่ตรึงเวอร์ชันไว้บนดิสก์ ให้ทำการ clone และ checkout tag ก่อน:

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh ไม่จำเป็นต้องใช้ sudo เนื่องจากเขียนข้อมูลลงภายใต้ $HOME/.claude/skills เท่านั้น หลังจากรันคำสั่งแล้ว ls ~/.claude/skills จะแสดงรายการ fable-judge, fable-loop และ fable-method ให้ตรวจสอบว่ามีรายการใดขาดหายไปบ้าง ตัว repository นี้มาพร้อมกับทักษะ 4 รายการ แต่ตัวติดตั้งแบบ shell จะคัดลอกไปเพียง 3 รายการ ดังนั้นผู้ใช้ทั่วไปจะไม่ได้รับ fable-domain เว้นแต่จะคัดลอกด้วยตนเอง:

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

ให้ตรึง tag ไว้ และจดบันทึก tag นั้นไว้ข้างผลลัพธ์ที่คุณได้รับ repository นี้ได้เผยแพร่ release ออกมา 5 รายการระหว่างวันที่ 2026-07-06 ถึง 2026-07-15 ตั้งแต่ v1.0.0 จนถึง v1.4.0 โดย v1.4.0 ได้เปลี่ยนวิธีการทำงานด้วยการเพิ่ม routing gate ใหม่ ณ เดือนสิงหาคม 2026 v1.4.0 ยังคงเป็น tag ล่าสุด หากการรันเพื่อควบคุมของคุณอ่านกฎเวอร์ชันหนึ่ง และการรันเพื่อทดสอบอ่านอีกเวอร์ชันหนึ่ง แสดงว่าคุณไม่ได้วัดผลอะไรเลย

ทักษะทั้งสี่ประการบอกให้โมเดลทำอะไร

ไฟล์หลักที่รับภาระงานคือ skills/fable-method/SKILL.md ซึ่งประกอบด้วยเกตสองชุดและขั้นตอนที่มีหมายเลขกำกับเจ็ดขั้นตอน กฎของมันมีความเฉพาะเจาะจงเพียงพอที่จะโต้แย้งได้

เกตแรกคือเกตความเรียบง่าย (triviality gate): ให้ลงมือทำทันทีโดยไม่ต้องมีพิธีรีตอง เมื่อการเปลี่ยนแปลงนั้นกระทบไฟล์เดียว มีความยาวไม่เกิน 10 บรรทัด ไม่มีการเพิ่มพฤติกรรมใหม่ และคุณรู้อยู่แล้วว่าต้องแก้ไขอะไร ทักษะแยกต่างหากถูกสร้างขึ้นจากสัญชาตญาณนั้นเพียงอย่างเดียว คือ Ponytail ซึ่งผลักดันให้เอเจนต์ทำการเปลี่ยนแปลงที่เล็กที่สุดที่ใช้งานได้ โดยกฎหลักของมันสั้นพอที่จะคัดลอกลงในคำสั่งของคุณเองได้โดยไม่ต้องติดตั้งอะไรเพิ่ม เกตถัดมาคือเกตความเหมาะสม (fit gate) ซึ่งจะคัดแยกคำขอตามแหล่งที่มาของคำตอบ ได้แก่ แหล่งข้อมูลที่คุณเปิดอ่านได้ เทคนิคที่คุณต้องค้นคว้าก่อน หรือการอนุมานของคุณเอง ซึ่งต้องระบุว่าเป็นความเชื่อมั่นต่ำแทนที่จะนำเสนอเป็นข้อเท็จจริง สาขากลางนั้นจะทำงานได้ก็ต่อเมื่อเอเจนต์สามารถเข้าถึงเว็บได้จริง ซึ่งบน VPS ที่ถูกจำกัดสิทธิ์ หมายความว่าต้องให้มันมีแบ็กเอนด์การค้นหาของตัวเอง เช่น อินสแตนซ์ SearXNG ที่โฮสต์เองและเปิดเผยผ่านเครื่องมือค้นหา JSON

จากนั้นคือลูปการทำงาน: จำแนกคำขอ, กำหนดนิยามของคำว่าเสร็จสิ้น, รวบรวมหลักฐาน, ตัดสินใจ, ลงมือทำ, ตรวจสอบ, และรายงาน ขั้นตอนที่ 2 ระบุให้กำหนดทิศทางโดยการแสดงรายการไฟล์ในไดเรกทอรก่อนที่จะเลือกไฟล์, ให้ความสำคัญกับแหล่งข้อมูลปฐมภูมิมากกว่าการเรียกความจำ, และให้หยุดหลังจากทำการค้นหาติดต่อกันสองครั้งแล้วไม่พบข้อมูลใหม่ ขั้นตอนที่ 4 ระบุให้เขียนบรรทัด INTENT: ก่อนการแก้ไขใดๆ โดยระบุว่าโค้ดทำหน้าที่อะไร, การตรวจสอบที่ล้มเหลวคาดหวังผลลัพธ์อย่างไร, และข้อกำหนดระบุไว้อย่างไร และห้ามแก้ไขหากทั้งสามส่วนนี้ไม่ตรงกัน เพราะความไม่ตรงกันนั้นคือสิ่งที่ค้นพบจริง ขั้นตอนที่ 5 จำกัดจำนวนการลองใหม่: หลังจากลูปการแก้ไขและตรวจสอบล้มเหลว 3 ครั้งในปัญหาเดิม ให้หยุดและส่งคืนผลลัพธ์จริง

ส่วนที่ทดสอบได้มากที่สุดของไฟล์คือโทเค็นรายงานทั้งสี่รายการ การเปลี่ยนแปลงพฤติกรรมต้องมีบรรทัด INTENT: การดำเนินการที่ส่งผลต่อภายนอกต้องมี AUTH: user said "<exact words>" โดยอ้างอิงคำพูดของผู้ใช้ เนื่องจาก repo ระบุไว้อย่างชัดเจนว่าเอกสารประกอบไม่ใช่การอนุญาต การดำเนินการที่ถูกกำหนดไว้แต่ไม่ได้ทำต้องมีบรรทัด PENDING: ข้อบกพร่องที่แก้ไขแล้วต้องมี TWINS: searched <pattern> - found <N> other sites คุณไม่จำเป็นต้องเชื่อถือวิธีการใดๆ เพื่อตรวจสอบว่าสตริงทั้งสี่นี้ปรากฏขึ้นเมื่อถึงเวลาที่ต้องมีหรือไม่ ซึ่งเป็นสิ่งที่ทำให้ทุกอย่างวัดผลได้แทนที่จะใช้เพียงความรู้สึก

fable-loop คือวิธีการเดียวกันที่ทำงานในรูปแบบการประสานงานสี่ขั้นตอน: วางแผนด้วยเอเจนต์ย่อยที่รวบรวมหลักฐานแบบขนาน, ดำเนินการบนเธรดหลัก, ตรวจสอบด้วยเอเจนต์ย่อยฝ่ายโจมตี 1 ถึง 3 ตัวที่ใช้มุมมองต่างกัน, จากนั้นตรวจสอบและรายงาน โดยสมมติว่าใช้โมเดลราคาประหยัดในบทบาทการรวบรวมหลักฐานและฝ่ายโจมตี และใช้โมเดลที่ทรงพลังกว่าในการตัดสินใจและการแก้ไข

fable-judge คือส่วนที่คุ้มค่าแก่การติดตั้งแม้ว่าคุณจะทิ้งส่วนที่เหลือไปก็ตาม จุดยืนของมันคือ "รายงานคือชุดของข้อกล่าวอ้าง ไม่ใช่หลักฐาน" มันจะรวบรวมข้อกล่าวอ้างจากรายงานที่เสร็จสมบูรณ์, สร้างความจริงพื้นฐานจาก git diff และ git status, รันการตรวจสอบทุกอย่างที่รายงานระบุว่าได้ทำไปแล้วซ้ำอีกครั้ง, และไล่ล่ารายการการฉ้อโกงที่ระบุไว้: การตรวจสอบที่อ่อนแอ, การทำให้เสร็จแบบจอมปลอม, การขยายขอบเขตงานโดยไม่ได้รับอนุญาต, การดำเนินการที่ไม่ได้รับอนุญาต, การทรยศต่อข้อกำหนด, และเศษซากที่หลงเหลืออยู่ มันจะส่งคืนค่า VERIFIED, VERIFIED WITH CAVEATS, หรือ REFUTED และทำเครื่องหมายสิ่งที่มันไม่สามารถทำซ้ำได้ว่าเป็น UNVERIFIABLE แทนที่จะสันนิษฐานว่าผ่าน บรรทัดปิดท้ายของผู้ติดตั้งชี้ไปที่สิ่งนี้: "ลองใช้ดู: เปิด Claude Code แล้วพิมพ์ /fable-judge หลังจากเอเจนต์อ้างว่างานเสร็จสิ้นแล้ว" หากคุณต้องการสร้างการตรวจสอบนั้นลงในงานแทนที่จะรันหลังจากเสร็จสิ้น ทักษะ Old Coder จะให้เอเจนต์สร้าง SPEC ที่คุณอนุมัติและรายงาน EVIDENCE ที่คุณสามารถรันซ้ำได้ด้วยตัวเอง โดยมีการทดสอบการกลายพันธุ์ (mutation testing) ทำหน้าที่แทนความครอบคลุม (coverage) เพื่อเป็นหลักฐานว่าการทดสอบจะตรวจพบการถดถอย (regression) ได้จริง

fable-domain สร้างชุดอะแดปเตอร์โดเมนพร้อมฟิกซ์เจอร์สำหรับดักจับและ smoke evals โดยมีอะแดปเตอร์ 8 รายการ: การตลาด, การวิจัย, การวิเคราะห์ข้อมูล, ธุรกิจและการปฏิบัติการ, การเงิน, กฎหมายและการปฏิบัติตามกฎระเบียบ, การออกแบบและ UX, และ devops ส่วนงานด้านการแพทย์และคลินิกถูกละเว้นไว้โดยเจตนา

ส่วนใดที่ย้ายไปใช้กับโมเดลอื่นได้ และส่วนใดที่ทำไม่ได้

ที่เก็บโค้ดนี้ตอบคำถามนี้โดยตรงด้วย AGENTS.md ซึ่งระบุว่า: "เวอร์ชันพกพาสำหรับ coding agent หรือ harness ใดๆ (Codex, Cursor, aider, หรือ system prompt แบบดิบ) ใช้วิธีการเดียวกับ SKILL.md โดยให้คัดลอกไฟล์นี้ไปไว้ในคำสั่งสำหรับ agent ของคุณ หรือวางไว้ที่ root ของ repository ในชื่อ AGENTS.md" เนื้อหามีความยาวประมาณ 2,600 คำ และมีเกต ขั้นตอน และโหมดการทำงานเดียวกัน หากคุณเก็บไฟล์คำสั่งไว้ที่ root ของ repository อยู่แล้ว ธรรมเนียมปฏิบัติ AGENTS.md และ HUMAN.md จะระบุตำแหน่งที่ควรวางไฟล์และผู้ที่ต้องอ่านไฟล์ดังกล่าว

มีสองส่วนที่ย้ายไปใช้งานได้โดยไม่มีปัญหา ส่วนที่เป็นเนื้อหาวิธีการคือชุดคำสั่งแบบเรียงลำดับที่ไม่มีโค้ดเฉพาะเจาะจงสำหรับโมเดลใดโมเดลหนึ่ง ดังนั้นโมเดลใดก็ตามที่ปฏิบัติตามคำสั่งได้ย่อมทำตามวิธีนี้ได้เช่นกัน และสมมติฐานหลักของที่เก็บโค้ดนี้คือความยากง่ายในการทำงานแปรผกผันกับระดับของโมเดล ส่วนที่เป็นตัวตัดสิน (judge) ก็สามารถย้ายไปใช้ได้เช่นกัน ตราบใดที่ agent มี shell และ repository เพราะทุกสิ่งที่ทำคือ git diff บวกกับการรันคำสั่งซ้ำซึ่งผู้ใช้ก็สามารถรันเองได้ด้วย

มีหนึ่งส่วนที่ไม่สามารถย้ายไปใช้งานได้อย่างราบรื่น fable-loop สมมติว่า harness สามารถสร้าง subagent แบบขนานและส่งงานไปยังโมเดลที่แตกต่างกันได้ หาก agent ไม่มี subagent ก็จะต้องรันขั้นตอนเหล่านั้นแบบอนุกรมบนโมเดลเดียว ซึ่งจะทำให้สูญเสียความสามารถในการทำงานขนานและการประหยัดต้นทุนที่เป็นเหตุผลหลักของการออกแบบนี้ สิ่งที่เหลืออยู่จึงเป็นเพียง fable-method ที่มีคำศัพท์เพิ่มเติมเท่านั้น

มีอีกสองส่วนเล็กๆ ที่ขึ้นอยู่กับ harness และมักถูกมองข้าม ตัวกระตุ้น /fable-method เป็น slash command ของ Claude Code ดังนั้นหากใช้ harness อื่น คุณต้องเรียกใช้วิธีการนี้ด้วยการอธิบายแทน และคำอธิบายส่วน frontmatter ของ SKILL.md คือสิ่งที่ช่วยให้ agent โหลดเนื้อหาเฉพาะเมื่อตรงกับงานที่ได้รับ ซึ่งหมายความว่า skill ที่ติดตั้งไว้จะไม่มีต้นทุนจนกว่าจะถูกเรียกใช้งาน หากคุณคัดลอก AGENTS.md ไปไว้ใน system prompt แทน เนื้อหา 2,600 คำนั้นจะถูกส่งไปพร้อมกับทุกคำขอที่คุณส่ง ไม่ว่างานนั้นจะเป็นเพียงการแก้ไขคำผิดบรรทัดเดียวหรือการทำ refactor ก็ตาม ซึ่งนั่นคือความแตกต่างของต้นทุนที่แท้จริง และเป็นเหตุผลส่วนใหญ่ที่การจัดรูปแบบ skill แบบนี้มีอยู่

วิธีการทดสอบแบบ A/B บน VPS: งานเดียวกัน ทำสองครั้ง

ตั้งค่า working copy ที่เหมือนกันสองชุดเพื่อให้การทำงานแต่ละรอบไม่เห็นการแก้ไขของอีกรอบหนึ่ง แทนที่ YOUR_ORG/YOUR_REPO ด้วย repository ที่คุณต้องการทดสอบ โดย clone ทั้งสองชุดต้องมาจาก commit เดียวกัน

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

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

รันกลุ่มควบคุม (control arm) ด้วย --bare ซึ่งจะข้ามการค้นหา hooks, skills, plugins และ CLAUDE.md โดยอัตโนมัติ flag นี้คือสิ่งที่ทำให้มันเป็นกลุ่มควบคุม: skills ที่คุณติดตั้งไว้ก่อนหน้าจะไม่สามารถหลุดเข้ามาได้ โหมด bare จะไม่ใช้การล็อกอินผ่าน subscription ของคุณ ดังนั้นให้ตั้งค่า API key จาก Claude Console ก่อน

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

กลุ่มทดสอบ (method arm) คือคำสั่งเดียวกันโดยเพิ่ม flag เข้าไปหนึ่งตัว ซึ่งจะโหลด portable method เข้าไปเป็นส่วนเสริมของ system prompt:

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

ใช้ binary เดียวกัน, model เดียวกัน, เครื่องมือเดียวกัน และ tree เริ่มต้นเดียวกัน ต่างกันเพียง flag เดียว ซึ่งเป็นวิธีเดียวที่จะทำให้การเปรียบเทียบมีความหมาย

การออกแบบนี้เป็นการวัดผลที่ตัวเนื้อหาของ method ไม่ได้วัดผลที่การบรรจุ skill (skill packaging) ซึ่งเป็นคนละประเด็นกัน หากต้องการวัดผลการบรรจุ ให้เอา --bare ออก ติดตั้ง skills ตามขั้นตอนข้างต้น และใส่ชื่อ skill ลงใน prompt string เพราะ skill ที่เรียกโดยผู้ใช้จะแสดงผลในโหมด print: claude -p "/fable-method $task" คาดการณ์ได้ว่าโปรไฟล์ค่าใช้จ่ายจะแตกต่างจากกลุ่มที่ใช้ system-prompt แม้ว่าพฤติกรรมที่เห็นได้ชัดเจนจะดูเหมือนกันก็ตาม

การนับจำนวนขั้นตอนและค่าใช้จ่าย

การรันทั้งสองครั้งได้สร้างสตรีมของเหตุการณ์ในรูปแบบ JSON บรรทัดสุดท้ายคือข้อความ result ซึ่งประกอบด้วยข้อความสรุป ค่าใช้จ่าย และข้อมูลเมตาของเซสชัน ให้พิมพ์ข้อมูลนี้ออกมาหนึ่งครั้งและอ่านให้เข้าใจก่อนที่จะเขียนสคริปต์ใดๆ ครอบไว้ เนื่องจากชื่อฟิลด์อาจมีการเปลี่ยนแปลงระหว่างการปล่อยเวอร์ชันของ Claude Code

tail -1 ~/ab/control.jsonl | jq .

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

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

จำนวนขั้นตอนที่ใช้มาจากการนับการเรียกใช้เครื่องมือ (tool calls) ในไฟล์เดียวกัน:

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

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

ข้อควรระวังสองประการเกี่ยวกับตัวเลขเหล่านี้ ประการแรก อย่ารวมค่า output_tokens จากบันทึกเซสชันภายใต้ ~/.claude/projects/ แล้วสรุปว่าเป็นผลรวมทั้งหมด เนื่องจากบล็อกการใช้งานต่อข้อความเหล่านั้นเป็นเพียงภาพรวมที่บันทึกไว้ระหว่างการสตรีม และมีรายงานว่าตัวเลขดังกล่าวอาจนับได้ไม่ครบถ้วน บรรทัด result คือตัวเลขที่เชื่อถือได้ ประการที่สอง การรันเพียงครั้งเดียวต่อหนึ่งวิธีเป็นเพียงข้อมูลเชิงสังเกตเท่านั้น ดังนั้นควรทำการรันแต่ละวิธีซ้ำ 3 หรือ 4 ครั้งในงานเดียวกันก่อนที่จะสรุปว่ามีความแตกต่างกันจริง เพราะการรันเอเจนต์ตัวเดิมในงานเดียวกันสองครั้งก็ให้ผลลัพธ์ที่ต่างกันอยู่แล้ว สำหรับมุมมองด้านค่าใช้จ่ายในระยะยาว เครื่องมือติดตามค่าใช้จ่ายของ Claude Code และ วิธีการนับโทเค็นของ Claude Code จะอธิบายว่าเหตุใดข้อมูลใน cache จึงมีผลมากกว่าจำนวนนับดิบ

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

การประเมินของตัว repository เอง อ่านอย่างตรงไปตรงมา

หัวข้อใน README ระบุว่า "การประเมิน 15 รอบ, การรัน agent มากกว่า 260 ครั้ง, ผู้ตัดสินที่เป็น LLM แบบ blind ซึ่งตรวจสอบโดยการทำ diff และรันโค้ดจริง" นี่เป็นหลักฐานที่มากกว่า repository ทักษะส่วนใหญ่ที่เผยแพร่ออกมา และ eval/RESULTS.md ถูกเขียนขึ้นทีละรอบโดยเก็บข้อมูลความล้มเหลวไว้ทั้งหมด อย่างไรก็ตาม ข้อมูลนี้มีความเบาบางกว่าตัวเลขในหัวข้อเมื่อพิจารณาเจาะลึกไปยังแต่ละเซลล์ที่อยู่เบื้องหลังแถวเหล่านั้น

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

แถวที่ใหญ่ที่สุดในจำนวน 4 แถวนั้นมาจากจำนวนการรัน 4 ครั้ง ส่วนอีกสามแถวที่เหลือมาจากการรันแถวละ 2 ครั้ง ตัว repository เองได้ระบุไว้ในข้อจำกัดที่ด้านบนของ log ว่า: "ใช้ n ขนาดเล็กตลอดการทดสอบ (1-4 ครั้งต่อเซลล์), ใช้ผู้ตัดสินที่เป็น LLM (แบบ blind ในกรณีที่มีการเปรียบเทียบผลลัพธ์หลายรายการ แต่สร้างขึ้นบนโมเดลระดับ frontier เดียวกันกับที่ใช้เป็น baseline), ใช้ข้อมูลจำลอง (synthetic fixtures), และข้อมูลความจริง (ground truth) สำหรับการวิจัยมีความสดใหม่เพียงเท่าวันที่รันเท่านั้น" และระบุไว้อย่างตรงไปตรงมาว่า: "log นี้มีไว้เพื่อทดสอบการแก้ไขวิธีการ ไม่ใช่เพื่อให้ใครเข้าใจผิดว่าเป็น benchmark"

ต้องให้เครดิตในจุดนี้ ผู้เขียนที่เปิดเผยค่า n ของตนเองและระบุปัญหาว่าผู้ตัดสินของตนสร้างขึ้นบนโมเดลเดียวกับที่ใช้เป็น baseline นั้น ถือว่ามีความซื่อตรงมากกว่ามาตรฐานทั่วไปในกลุ่มนี้ ให้มองตัวเลขเหล่านี้เป็นหลักฐานว่าผู้เขียนได้รันการทดสอบจริงและเก็บข้อมูลความล้มเหลวไว้ การทำ A/B testing ด้วยตัวเองเท่านั้นที่จะบอกคุณได้ว่า codebase ของคุณเป็นอย่างไร

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

จุดที่การจัดแพ็กเกจเป็นเพียงความเชื่อแบบงมงาย

มีข้อวิจารณ์ 4 ประการที่ควรกล่าวถึง แต่ไม่มีข้อใดที่เป็นเหตุผลให้คุณควรข้าม repository นี้ไป

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

ทักษะ 4 ประการนั้นดูผิวเผินเกินกว่าที่เนื้อหาต้องการ fable-loop เป็นการเรียบเรียงเนื้อหาส่วนใหญ่ของ fable-method ใหม่โดยเพิ่มการจัดการ (orchestration) เข้าไป และเมื่ออยู่บน harness ที่ไม่มี subagents มันก็จะยุบตัวกลับไปเป็น fable-method ให้ลองอ่านไฟล์ทั้งสองควบคู่กันก่อนที่คุณจะติดตั้งทั้งคู่

ตัวปรับแต่ง (adapter) 8 โดเมนนั้นมีความกว้างเกินกว่าที่การประเมินผลจะครอบคลุม มีเพียง 2 จาก 8 รายการเท่านั้นที่ปรากฏใน log ได้แก่ การตลาดในรอบที่ 9 และ devops ในรอบที่ 12 ส่วนตัวปรับแต่งสำหรับด้านการเงิน กฎหมาย การออกแบบ และข้อมูลนั้นถูกส่งมาโดยไม่มีรอบการทำงานรองรับ ตัวปรับแต่งสำหรับสายงานของคุณอาจจะยังใช้งานได้ดี แต่มันเป็นเพียงร่างที่ผู้เขียนทำขึ้น ไม่ใช่สิ่งที่ผ่านการทดสอบด้วย trap fixture มาแล้ว

และตัวติดตั้ง (installer) ก็มีความเห็นไม่ตรงกับ repository ในเรื่องสิ่งที่มันจัดส่ง โดยมีการคัดลอกทักษะ 3 จาก 4 ประการลงใน ~/.claude/skills ข้อผิดพลาดนี้เป็นเรื่องเล็กน้อย แต่มันเป็นช่องว่างประเภทที่บอกให้รู้ว่าการจัดแพ็กเกจนั้นดำเนินการไปเร็วกว่าการตรวจสอบ ซึ่งเป็นสิ่งที่ควรจดจำไว้เมื่อคุณตัดสินใจว่าจะนำสิ่งนี้มาใช้งานมากน้อยเพียงใดในคราวเดียว

สิ่งที่ควรยึดถือไว้หากต้องเลือกเพียงไม่กี่อย่าง

หากตัดเรื่องแบรนด์ออกไป จะเหลือหลักการ 4 ข้อที่สามารถนำไปใช้ได้ด้วยตนเอง ไม่ว่าคุณจะใช้เอเจนต์ตัวใดก็ตาม

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

หลักการทั้ง 4 ข้อนี้ไม่มีค่าใช้จ่ายในการนำไปใช้ และคุณสามารถใช้คำสั่ง grep เพื่อตรวจสอบการปฏิบัติตามได้ เริ่มต้นจากจุดนี้ วัดผลด้วยเครื่องมือที่กล่าวถึงข้างต้น แล้วจึงตัดสินใจว่าส่วนที่เหลือของ repo นั้นคุ้มค่ากับงบประมาณด้านบริบทของคุณหรือไม่ หากคุณต้องการให้เอเจนต์มีบริบทของโปรเจกต์ที่ชัดเจนแทนที่จะเป็นเพียงวิธีการทำงาน ไฟล์ DESIGN.md ที่เอเจนต์อ่านก่อนทำการแก้ไข คือสิ่งที่ควรทำควบคู่กันไป

FAQ

วิธี Fable ใช้กับโมเดลอื่นที่ไม่ใช่ Claude ได้หรือไม่?

เนื้อหาของวิธีนี้ใช้ได้ เนื่องจากเป็นชุดคำสั่ง (prompt) ที่เรียงลำดับขั้นตอนโดยไม่มีโค้ดเฉพาะเจาะจงสำหรับโมเดลใดโมเดลหนึ่ง และตัว repository ได้จัดเตรียม AGENTS.md ไว้เป็นสำเนาที่นำไปใช้กับ Codex, Cursor, aider หรือใช้เป็น system prompt แบบดิบได้ แต่มีสองสิ่งที่นำไปใช้ข้ามกันไม่ได้ คือคำสั่ง /fable-method และ /fable-judge ซึ่งเป็น slash command ของ Claude Code ดังนั้นในสภาพแวดล้อมอื่น คุณต้องเรียกใช้วิธีนี้ด้วยการอธิบายขั้นตอนแทน และ fable-loop นั้นตั้งสมมติฐานว่ามีระบบที่สามารถสร้าง subagent แบบขนานบนโมเดลที่แตกต่างกันได้ หากไม่มีระบบดังกล่าว การทำงานจะเป็นแบบลำดับ (serial) และจะทำให้คุณได้ fable-method ที่มีขั้นตอนเพิ่มขึ้น

การเรียกใช้ทักษะเหล่านี้ทำให้เสียค่า token มากขึ้นหรือไม่?

ใช่ และจำนวนที่เสียจะขึ้นอยู่กับวิธีการโหลด หากติดตั้งเป็นทักษะ (skills) ตัวเนื้อหาจะถูกโหลดเฉพาะเมื่อคำอธิบายตรงกับงานที่ได้รับ ดังนั้นคำขอที่ไม่เกี่ยวข้องแทบจะไม่เสียค่าใช้จ่ายเลย แต่หากนำไปวางใน system prompt ตัวเนื้อหาประมาณ 2,600 คำของ AGENTS.md จะถูกส่งไปพร้อมกับทุกคำขอ นอกจากนี้การทำงานจริงยังมีค่าใช้จ่ายสูงขึ้น เพราะวิธีนี้กำหนดให้มีการวางแนวทางก่อนแก้ไข มีการหาหลักฐานก่อนตัดสินใจ และมีการตรวจสอบจริงหลังจากนั้น ให้วัดผลด้วยการรันงานเดียวกันโดยใช้ --output-format json ในทั้งสองกลุ่มแล้วเปรียบเทียบช่อง total_cost_usd

ควรติดตั้ง fable-method เวอร์ชันใด และทำไมต้องระบุเวอร์ชัน (pin)?

ให้รัน git checkout v1.4.0 ก่อนทำการติดตั้ง tag ดังกล่าวลงวันที่ 2026-07-15 และยังคงเป็นเวอร์ชันล่าสุด ณ เดือนสิงหาคม 2026 ตัว repository ได้ออก releases ถึง 5 ครั้งในช่วง 9 วันก่อนหน้านั้น และ v1.4.0 ได้เปลี่ยนกฎการกำหนดเส้นทาง (routing rules) ไป การติดตาม main ในขณะที่คุณกำลังวัดผลอาจทำให้การรันเพื่อควบคุม (control run) และการรันเพื่อทดสอบ (test run) อ่านคำสั่งที่แตกต่างกัน ซึ่งจะทำให้การเปรียบเทียบไม่มีความหมาย ให้บันทึก tag ไว้คู่กับผลลัพธ์ของคุณเสมอ

การประเมิน (eval) ใน repository เป็นเกณฑ์มาตรฐานที่เชื่อถือได้หรือไม่?

ให้ถือว่ามันเป็นบันทึกการเปลี่ยนแปลง (change log) ของวิธีนี้ ตามที่ผู้เขียนได้ระบุไว้ว่า "บันทึกนี้มีไว้เพื่อทดสอบการแก้ไขวิธี ไม่ใช่เพื่อให้ใครเข้าใจผิดว่าเป็นเกณฑ์มาตรฐาน" ข้อจำกัดต่างๆ ได้ระบุไว้ที่ด้านบนของไฟล์แล้ว ได้แก่ การรัน 1 ถึง 4 ครั้งต่อเซลล์, การใช้ข้อมูลจำลอง (synthetic fixtures) และการใช้ LLM เป็นผู้ตัดสินซึ่งสร้างขึ้นบนโมเดลระดับแนวหน้าตัวเดียวกับที่ใช้เป็น baseline รอบการทดสอบนั้นเป็นของจริงและมีการเก็บผลการทดลองที่ล้มเหลวไว้ด้วย ซึ่งมากกว่าที่ repository ส่วนใหญ่จะทำกัน อย่างไรก็ตาม นี่ไม่ใช่การวัดผลว่าจะเกิดอะไรขึ้นกับ codebase ของคุณ ดังนั้นควรทำการเปรียบเทียบแบบสองกลุ่มด้วยตัวคุณเอง