fable-method: สั่ง AI agent ทำงานเป็นขั้นตอน แทนคำว่า "ให้ระวัง" ช่วยโมเดลรุ่นเล็กทำงานแม่นขึ้น พิสูจน์จากเทสต์ 260 ครั้ง
fable-method ชุดสกิลสำหรับ AI agent สายเขียนโค้ด เช่น Claude Code กับ Codex ที่กลั่นกระบวนการทำงานของ Claude Fable 5 มาเป็นขั้นตอนชัดเจน เปลี่ยนวิธีสั่งจากการบอกให้ "ใส่ใจ" มาเป็นการระบุสิ่งที่ต้องทำ ลำดับขั้น และเกณฑ์ตัดสินอย่างเป็นรูปธรรม ช่วยให้โมเดลรุ่นเล็กทำงานแม่นยำขึ้น พิสูจน์จากล็อกผลทดสอบจริงกว่า 260 ครั้ง

เวลาสั่ง AI agent ทำงาน แล้วตอบกลับมาว่า "เสร็จแล้ว เทสต์ผ่านหมด" แต่พอเปิดเช็กจริงๆ กลับพบว่างานยังไม่เรียบร้อย ถือเป็นปัญหาที่ fable-method ออกแบบมาแก้โดยตรง สถานการณ์นี้คนใช้งาน agent น่าจะเคยเจอจนชิน เช่น สั่งแก้บั๊กจุดเดียว แต่ agent ดันไปแก้โค้ดส่วนที่ทำงานปกติจนเละ หรือพยายามย้ำคำสั่งว่า "ระวังหน่อยนะ ตรวจงานให้ดีก่อนส่ง" แต่ผลลัพธ์ก็ยังแกว่งเหมือนเดิม
fable-method เป็นชุดสกิลสำหรับ AI agent สายเขียนโค้ด หรือโปรแกรม AI ที่รับโจทย์ไปลงมือทำงานเป็นขั้นตอนได้เอง ไม่ใช่แค่พิมพ์ตอบแชต ตัวอย่างที่นิยมใช้งานกัน เช่น Claude Code และ Codex ของ OpenAI โดยโปรเจกต์โอเพนซอร์สนี้ได้สรุปวิธีทำงานของ Claude Fable 5 หนึ่งในโมเดลของ Claude มาเป็นชุดขั้นตอนที่โมเดลตัวอื่นเอาไปทำตามได้ จุดต่างจากไฟล์สั่ง agent ทั่วไปอยู่ที่วิธีเขียนคำสั่ง ตามที่ README ของโปรเจกต์อธิบายไว้ ไฟล์สั่ง agent ส่วนใหญ่มักบอกให้โมเดล "ใส่ใจ" เช่น ระวังนะ หรือตรวจงานด้วยนะ แต่ fable-method เปลี่ยนมาบอกเลยว่าต้อง "ทำอะไร เรียงลำดับอย่างไร และใช้เกณฑ์ตัดสินแค่ไหน" พอคำสั่งชัดเจนและเป็นรูปธรรม โมเดลรุ่นเล็กราคาถูกก็ทำตามได้จริงแบบตรงไปตรงมา
หัวใจของ fable-method คือ 7 ขั้นตอนที่ทำตามได้จริง
เวลา agent ได้รับโจทย์ยาก fable-method จะให้ลุยตามลำดับตายตัว แทนที่จะรีบพุ่งไปแก้ทันที โดยสรุปเป็น 7 ขั้นตอนดังนี้
- จำแนกโจทย์ก่อน งานขนาดเล็ก เช่น แก้ไฟล์เดียวไม่กี่บรรทัดโดยไม่ต้องค้นหาข้อมูล ให้ลงมือทำทันทีแล้วรายงานสั้นๆ แต่ถ้าเป็นงานใหญ่กว่านั้น ต้องประเมินก่อนว่าคำตอบอยู่ที่ไหน และเป็นงานรูปแบบใด
- นิยามคำว่า "เสร็จ" ให้ชัดว่าต้องผ่านการเช็กตัวไหนถึงจะนับว่าจบ โดยตกลงเกณฑ์นี้ไว้ตั้งแต่ก่อนเริ่มลงมือ
- ไปเก็บหลักฐานจากต้นตอจริงหลายที่ในคราวเดียว ก่อนจะสรุปอะไร ไม่ใช่เดาเอาจากความจำ
- ฟันธงให้เหลือข้อเสนอเดียว ไม่โยนตัวเลือกจำนวนมากกลับมาให้ผู้สั่งเลือกเอง
- ลงมือแก้เท่าที่จำเป็นจริงๆ ให้กระทบของเดิมน้อยที่สุด ไม่ไปแตะต้องส่วนที่ทำงานได้ดีอยู่แล้ว และตรวจสอบก่อนลบว่ามีส่วนอื่นเรียกใช้งานอยู่หรือไม่ แนวคิดนี้สอดคล้องกับที่ ponytail เสนอไว้ว่า โค้ดที่ดีที่สุดคือโค้ดที่ไม่ต้องเขียน
- ยืนยันผลด้วยการรันหรือสังเกตจริง ไม่ใช่แค่อ่านรายงานของตัวเองแล้วสรุปเอาเองว่าผ่าน
- รายงานผลลัพธ์ก่อนเป็นอันดับแรก แล้วค่อยระบุข้อจำกัดตามจริง พร้อมแจ้งหากมีการเก็บกวาดโค้ดเพิ่มเติมระหว่างทาง
จุดที่ทำให้ลำดับนี้ต่างจากคำแนะนำทั่วไป คือการกำหนดเกณฑ์หยุดทำงานอย่างชัดเจน หากตรวจแล้วยังไม่ผ่านติดต่อกัน 3 รอบ ให้หยุดแล้วถามผู้ใช้งาน หากค้นหาข้อมูลไม่เจอ 2 ครั้ง ให้หยุดค้นหา และหากไม่สามารถนิยามคำว่าเสร็จได้ตั้งแต่แรก ให้ถามกลับด้วยคำถามที่ตรงจุดเพียงข้อเดียว เกณฑ์เหล่านี้ช่วยป้องกันไม่ให้โมเดลขนาดเล็กทำงานวนลูป หรือเดาไปเรื่อย
สี่สกิลที่ทำงานเป็นทีม

7 ขั้นตอนข้างต้นคือสกิล "คิด" ซึ่งเป็นหัวใจหลัก แต่ชุดนี้ยังมีอีกสี่สกิลที่แบ่งหน้าที่กันอย่างชัดเจน ภายใต้แนวทางเดียวกัน
- fable-method (คิด) วิธีคิดหลักสำหรับจำแนกโจทย์แล้วดำเนินการทีละขั้นตอน
- fable-loop (ลงมือ) นำขั้นตอนมาจัดระบบเพื่อรับมือกับโจทย์ใหญ่หลายขั้นตอน ทั้งวางแผน ลงมือทำ ตรวจสอบ และออดิตซ้ำ ซึ่งเป็นหัวใจสำคัญของงานวางระบบ agent อย่าง harness และ loop engineering ที่ช่วยเพิ่มความน่าเชื่อถือให้ agent
- fable-judge (พิสูจน์) สกิลตรวจสอบงานอย่างเข้มงวด โดยรันเช็กสิ่งที่อ้างว่าทำเสร็จแล้วอีกครั้ง ดูการเปลี่ยนแปลงที่เกิดขึ้นจริง ไล่ตรวจสอบเทสต์ที่ถูกลดมาตรฐาน หรือรายงานที่แจ้งว่าเสร็จเกินจริง ก่อนประเมินผลเป็น ผ่าน มีเงื่อนไข หรือตก
- fable-domain (ต่อยอด) ปรับแต่งชุดสั่งการให้เหมาะกับสายงานอื่น เช่น การตลาด งานข้อมูล หรือดีไซน์ โดยจะปฏิเสธงานที่มีความเสี่ยงสูงอย่างการแพทย์ กฎหมาย และการเงินทันที เนื่องจากงานกลุ่มนี้ต้องอาศัยผู้เชี่ยวชาญที่มีใบอนุญาต ไม่ใช่แค่ทำตามเช็กลิสต์
ทำไมถึงน่าเชื่อ ไม่ใช่แค่คำคม
เบื้องหลังของชุดสกิลนี้กลั่นมาจากวิธีทำงานของ Claude Fable 5 ในช่วงท้ายก่อนถอดออกจากแพ็กเกจ Subscription โดยตัวโมเดลได้ร่างแนวคิดแรกไว้ จากนั้นให้ agent อีกสามตัวช่วยตรวจสอบจุดอ่อน ทั้งเรื่องโมเดลรุ่นเล็กทำตามได้จริงไหม เนื้อหาตรงกับการทำงานจริงหรือเปล่า และมีส่วนไหนเยิ่นเย้อเกินไปไหม ก่อนที่ Sahir619 ผู้พัฒนาบน GitHub จะนำมาพัฒนาต่อเป็นชุดสกิลให้โมเดลทั่วไปใช้งานได้ พร้อมปล่อยเป็นโอเพนซอร์สภายใต้ใบอนุญาต MIT โดยไม่ได้เป็นผลงานที่ Anthropic ทำออกมาเอง
ความน่าเชื่อถือไม่ได้มาจากคำคมสวยหรู แต่มาจากกระบวนการทดสอบ ผู้พัฒนาได้นำชุดนี้ไปทดสอบจับผิดตัวเองถึง 15 รอบ รวมการปล่อยให้ agent ทำงานจริงกว่า 260 ครั้ง พร้อมบันทึกข้อผิดพลาดไว้ในล็อก โดยยึดหลักการว่า ทุกกฎในชุดนี้ต้องมีขึ้นเพราะมีเทสต์ที่พังหากขาดกฎนั้นไป ไม่ใช่ตั้งกฎขึ้นมาเองตามความรู้สึก
นอกจากนี้ ล็อกผลการทดสอบไม่ได้บันทึกเฉพาะกรณีที่สำเร็จ แต่ยังระบุรอบที่วิธีนี้ไม่ได้ผล หรือได้ผลลัพธ์แย่กว่าการไม่ใช้อย่างตรงไปตรงมา
ล็อกผลลัพธ์ที่มีแต่เรื่องชนะ ไม่ใช่ล็อกที่ควรเชื่อ
ผลที่วัดได้จริง ไม่ใช่แค่รู้สึกว่าดีขึ้น

ตัวอย่างที่เห็นภาพได้ชัดมาจากโจทย์หนึ่งในล็อกการทดสอบ โดยให้โมเดลตรวจโค้ดที่เขียนถูกต้องอยู่แล้ว แต่มีเทสต์ตัวหนึ่งขัดแย้งกับสเปก โมเดลที่ดีควรทักท้วงว่าสเปกกับเทสต์ไม่ตรงกัน แทนที่จะแอบแก้โค้ดที่ถูกต้องให้เข้ากับเทสต์ที่ผิด เมื่อทีมทดสอบนำ Haiku โมเดลรุ่นเล็กราคาถูกของ Claude มาทดลอง 3 รูปแบบ ผลลัพธ์ออกมาแตกต่างกันอย่างชัดเจน
| กฎที่ให้ Haiku | จับความขัดแย้งได้ (จาก 4 รอบ) |
|---|---|
| ไม่มีกฎเรื่องนี้เลย | 0 |
| เขียนกฎแทรกไว้กลางๆ เป็นคำอธิบาย | 1 |
| บังคับให้เขียนรายงานเทียบสามบรรทัด | 4 |
ความแตกต่างระหว่างแถวที่สองกับแถวที่สามถือเป็นหัวใจของเรื่องนี้ การเขียนกฎไว้กลางคำสั่งเพียงว่า "ระวังจุดที่ขัดกันด้วยนะ" ช่วยให้จับจุดผิดได้เพียง 1 ใน 4 ครั้ง แต่เมื่อบังคับให้ agent เขียนรายงานสั้นๆ 3 บรรทัดออกมาก่อนตัดสินใจว่า "โค้ดทำ X · เทสต์คาดหวัง Y · สเปกบอก Z" ตัวโมเดลสามารถจับได้ครบ 4 ใน 4 ครั้ง การเปลี่ยนจากการบอกให้ใส่ใจ มาเป็นบังคับให้สร้างผลลัพธ์ที่จับต้องได้ จึงได้ผลอย่างจริงจัง
อีกหนึ่งตัวอย่างคือ fable-judge ในชุดการทดสอบที่จงใจซ่อนงานปลอมไว้ 5 จุด หลังรายงานที่ระบุว่า "เสร็จเรียบร้อย" ทุกการประเมินในทุกเงื่อนไขตรวจพบทันทีว่างานยังไม่เสร็จจริง และเมื่อเพิ่ม fable-judge เข้าไป โมเดลรุ่นเล็กสามารถไล่จับงานปลอมได้ครบทั้ง 5 จุด จากเดิมที่เคยจับได้ไม่ครบ
อย่างไรก็ตาม ต้องระบุให้ชัดเจนว่า วิธีนี้ไม่ได้ช่วยให้โมเดลขนาดเล็กเก่งเท่าโมเดลขนาดใหญ่ในทุกงาน สำหรับโจทย์ที่ต้องใช้ความรู้เชิงลึก เช่น การค้นหาข้อมูลล่าสุด Haiku ที่ทำตามวิธีนี้ก็ยังรั้งท้าย ผู้พัฒนาสรุปไว้ตรงๆ ว่าวิธีนี้ช่วยสร้าง "ระเบียบวินัย ไม่ใช่ความรู้" งานที่ต้องใช้ความสามารถหลักของโมเดลยังคงต้องพึ่งพาโมเดลขนาดใหญ่อยู่ดี สิ่งที่วิธีนี้เข้ามาช่วยคือการดันให้โมเดลระดับปานกลางมีระเบียบวินัยพอที่จะทำงานได้ทัดเทียมโมเดลตัวท็อปในหลายโจทย์ แม้จะไม่ใช่ทุกโจทย์ก็ตาม
เอาไปปรับกับงานตัวเองอย่างไร
ข้อคิดที่นำไปปรับใช้ได้ทันที คือลองเปิดดูไฟล์คำสั่งที่เขียนให้ agent ว่ามีประโยคอย่าง "ช่วยระวัง" หรือ "ตรวจให้ดี" อยู่กี่บรรทัด แล้วลองเปลี่ยนเป็นขั้นตอนที่ปฏิบัติได้จริง เช่น ปรับจากคำว่า "ตรวจงานให้ดี" เป็น "รันเทสต์ชื่อนี้แล้วแปะผลลัพธ์กลับมา" เพียงเท่านี้โมเดลเดิมก็มักจะทำงานได้แม่นยำขึ้น โดยไม่จำเป็นต้องอัปเกรดไปใช้โมเดลที่แพงกว่า
หากอยากทดลองใช้งานจริง fable-method สามารถติดตั้งเป็นปลั๊กอินของ Claude Code ได้ทันที
/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method
หลังติดตั้ง สกิลทั้งสี่จะพร้อมใช้งานในชื่อ /fable:fable-method, /fable:fable-loop, /fable:fable-judge และ /fable:fable-domain ส่วนผู้ที่ใช้งาน agent ตัวอื่นอย่าง Codex หรือ Cursor ก็สามารถนำไฟล์ AGENTS.md ที่แนบมาด้วยไปปรับใช้ได้เช่นกัน
ก่อนจะเชื่อเทคนิคการใช้ AI แบบไหน ลองสังเกตสิ่งที่มักไม่ค่อยถูกนำมาโชว์ นั่นคือรอบที่ทำงานผิดพลาด จุดเด่นของ fable-method ไม่ได้มีเพียงตัววิธีการ แต่ยังอยู่ที่การเปิดเผยล็อกข้อผิดพลาดให้เห็นชัดเจน เพราะเทคนิคที่บอกได้ว่า "ผิดพลาดจุดไหน" มักน่าไว้วางใจกว่าเทคนิคที่มีเพียงเรื่องเล่าความสำเร็จ
ที่มา:
- โปรเจกต์ fable-method บน GitHub
- ล็อกผลทดสอบ eval/RESULTS.md บน GitHub
ชอบเรื่องแนวนี้ มีอีบุ๊คฟรีให้อ่านต่อ
NotebookLM ฉบับเข้าใจง่าย โยนเอกสารให้ AI อ่าน แล้วได้สรุป พอดแคสต์ และคลังความรู้ส่วนตัว
กดสมัครแล้วเราจะส่งเทคนิค AI และของแจกใหม่ๆ ให้ทางอีเมล เลิกรับได้ตลอด
Claude Cowork · The Business Playbook

ฉบับภาษาไทย 15 บท เรียนรู้ผ่านโปรเจกต์จำลองต่อเนื่องทั้งเล่ม ตั้งแต่ตั้งค่า Workspace จัดการไฟล์ เชื่อมแอป ตั้งระบบอัตโนมัติ จนถึงสร้าง Plugin


