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

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

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

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

หากคำว่าทักษะ (skill) เป็นเรื่องใหม่สำหรับคุณ ให้เริ่มจาก ทักษะของเอเจนต์คืออะไรกันแน่: คือโฟลเดอร์ที่เก็บไฟล์ SKILL.md ซึ่งมีคำอธิบายในส่วน frontmatter บอกเอเจนต์ว่าควรโหลดเนื้อหาเมื่อใด ส่วนโมเดลที่เป็นที่มาของชื่อ repository นี้ได้ถูกอธิบายไว้ใน 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/

ให้กำหนดเวอร์ชัน (pin) โดยใช้ 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 ล่าสุด หากการรันเพื่อควบคุม (control run) ของคุณอ่านกฎเวอร์ชันหนึ่ง และการรันเพื่อทดสอบ (test run) อ่านอีกเวอร์ชันหนึ่ง ผลลัพธ์ที่คุณวัดได้จะไม่มีความหมายใดๆ

สิ่งที่ทักษะทั้งสี่สั่งให้โมเดลทำ

ไฟล์หลักที่รับภาระงานคือ 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 คือวิธีการเดียวกันที่ทำงานในรูปแบบการประสานงานสี่ขั้นตอน: วางแผนด้วยเอเจนต์ย่อยที่รวบรวมหลักฐานแบบขนาน, ดำเนินการบนเธรดหลัก, ตรวจสอบด้วยเอเจนต์ย่อยฝ่ายโจมตีหนึ่งถึงสามตัวที่ใช้มุมมองต่างกัน, จากนั้นตรวจสอบซ้ำและรายงาน โดยสมมติว่าใช้โมเดลราคาประหยัดในบทบาทการรวบรวมหลักฐานและฝ่ายโจมตี และใช้โมเดลที่ทรงพลังกว่าในการตัดสินใจและแก้ไขโค้ด

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

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 testing บน 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 โดยอัตโนมัติ แฟล็กนี้คือสิ่งที่ทำให้มันเป็นกลุ่มควบคุม: 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) คือคำสั่งเดียวกันโดยเพิ่มแฟล็กหนึ่งตัว ซึ่งจะโหลด 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 เดียวกัน, โมเดลเดียวกัน, เครื่องมือเดียวกัน และ tree เริ่มต้นเดียวกัน แฟล็กที่ต่างกันเพียงตัวเดียวคือวิธีเดียวที่จะทำให้การเปรียบเทียบมีความหมาย

การออกแบบนี้วัดผลที่ตัวข้อความของ method ไม่ใช่วัดผลที่การจัดแพ็กเกจของ skill ซึ่งเป็นคนละประเด็นกัน หากต้องการวัดผลการจัดแพ็กเกจ ให้เอา --bare ออก ติดตั้ง skills ตามขั้นตอนข้างต้น และใส่ชื่อ skill ลงใน prompt string เพราะ skill ที่เรียกโดยผู้ใช้จะขยายผลใน print mode: 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 คือตัวเลขที่เชื่อถือได้ ประการที่สอง การรันเพียงครั้งเดียวต่อหนึ่งวิธีถือเป็นเพียงข้อมูลเชิงประสบการณ์ ดังนั้นควรทำการรันแต่ละวิธีซ้ำสามถึงสี่ครั้งในงานเดียวกันก่อนที่จะสรุปว่ามีความแตกต่างกันจริง เนื่องจากแม้แต่การรันเอเจนต์ตัวเดิมในงานเดิมสองครั้งก็ยังให้ผลลัพธ์ที่ต่างกัน สำหรับมุมมองด้านค่าใช้จ่ายในระยะยาว เครื่องมือที่ติดตามค่าใช้จ่ายของ Claude Code และ วิธีการที่ Claude Code นับโทเค็น จะอธิบายว่าเหตุใดบรรทัดแคช (cache lines) จึงมีผลมากกว่าจำนวนนับดิบ

ตรวจสอบให้แน่ใจว่าเอเจนต์ไม่สามารถเข้าถึงสิ่งใดก็ตามที่คุณให้ความสำคัญในขณะที่มันทำงานโดยไม่มีผู้ดูแล การรัน 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), และความถูกต้องของข้อมูลวิจัยเป็นปัจจุบันเฉพาะ ณ วันที่รันเท่านั้น" และระบุไว้อย่างตรงไปตรงมาว่า: "log นี้มีไว้เพื่อทดสอบการแก้ไขวิธีการ ไม่ใช่เพื่อให้ใครเข้าใจผิดว่าเป็นเกณฑ์มาตรฐาน (benchmark)"

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

README ยังระบุไว้อย่างชัดเจนว่าวิธีการนี้ไม่ได้ผลในส่วนใด ซึ่งนับเป็นย่อหน้าที่เป็นประโยชน์ที่สุด โดยระบุว่าไม่พบการปรับปรุงสำหรับงานขนาดเล็กทั่วไปในโมเดลที่มีความสามารถสูง และระบุว่า "วิธีการนี้ไม่สามารถทำให้ข้อเท็จจริงของโมเดลสดใหม่ขึ้นได้; โมเดลระดับ frontier ที่ไม่มีการปรับแต่งยังคงชนะในงานวิจัยที่เน้นความรู้" นอกจากนี้ยังระบุว่าคุณค่าของมันอยู่ที่ "กับดัก (ความขัดแย้งของอำนาจ, การอ้างว่าทำเสร็จสิ้นทั้งที่เป็นเท็จ, executor ที่อ่อนแอ, การรันโดยไม่มีผู้ดูแล) ไม่ใช่ทุกที่" หากงาน 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 ได้แก่ marketing ในรอบที่ 9 และ devops ในรอบที่ 12 ส่วน adapter สำหรับ finance, legal, design และ data นั้นถูกส่งมาโดยไม่มีข้อมูลการทดสอบรองรับ แม้ adapter สำหรับสายงานของคุณอาจจะยังใช้งานได้ดี แต่มันก็เป็นเพียงร่างที่ผู้เขียนทำขึ้น ไม่ใช่สิ่งที่ผ่านการทดสอบด้วย trap fixture มาแล้ว

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

สิ่งที่ต้องรักษาไว้หากคุณไม่สามารถรักษาอะไรไว้ได้เลย

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

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

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

FAQ

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

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

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

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

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

ให้รัน 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 ของคุณ ดังนั้นควรทำการเปรียบเทียบแบบสองกลุ่ม (two-arm comparison) ด้วยตัวคุณเอง