Caveman - ประหยัดโทเค็น Claude/Codex ด้วยสำนวนพูดแบบมนุษย์ถ้ำ
(github.com/JuliusBrussee)- สกิลที่บังคับให้ตอบด้วย สำนวนพูดแบบมนุษย์ถ้ำ เพื่อลด โทเค็นเอาต์พุตเฉลี่ย 65~75%
- ปรับระดับความบีบอัดได้ 3 ขั้นคือ Lite·Full·Ultra พร้อมสร้าง คำตอบที่สั้นและมีประสิทธิภาพ โดยยังคงความแม่นยำทางเทคนิค
- จากเบนช์มาร์กจริง คำอธิบายเกี่ยวกับ React·PostgreSQL·Git ต่างลดการใช้โทเค็นลงเหลือน้อยกว่าครึ่งทั้งหมด
- ให้ผลทั้ง ความเร็วตอบกลับเพิ่มขึ้นราว 3 เท่า, อ่านง่ายขึ้น, และ ลดค่าใช้จ่าย พร้อมกัน
- ติดตั้งได้ด้วยคำสั่งง่ายๆ บน Claude Code และ Codex และใช้งานต่อเนื่องได้ตลอดทั้งเซสชัน
ภาพรวมของ Caveman
- ปลั๊กอินสำหรับ Claude Code และ Codex ที่แปลงคำตอบของ LLM ให้เป็น ‘สำนวนพูดแบบมนุษย์ถ้ำ (caveman-speak)’ เพื่อลด การใช้โทเค็นลงราว 75%
- สร้าง คำตอบที่สั้นและมีประสิทธิภาพ โดยตัดคำที่ไม่จำเป็นออก แต่ยังคงความแม่นยำทางเทคนิค
- ติดตั้งได้ด้วยคำสั่งบรรทัดเดียว และใช้งานต่อเนื่องได้ในทุกเซสชัน
- ลดเฉพาะ โทเค็นเอาต์พุต เท่านั้น — โทเค็นการคิด/การให้เหตุผลไม่ได้รับผลกระทบ
- สิ่งที่ถูกตัดออก:
- คำทักทาย·เกริ่นนำ: "Sure, I'd be happy to help" (สิ้นเปลือง 8 โทเค็น)
- คำขึ้นต้นเพื่ออธิบายเหตุผล: "The reason this is happening is because" (7 โทเค็น)
- สำนวนแนะนำ: "I would recommend that you consider" (7 โทเค็น)
- บทนำฟุ่มเฟือย: "Sure, let me take a look at that for you" (10 โทเค็น)
- สิ่งที่คงไว้: โค้ดบล็อก, คำศัพท์เทคนิค (เช่น polymorphism), ข้อความ error, ข้อความ commit·PR ของ git
ตัวอย่าง Before / After
- อธิบายเนื้อหาทางเทคนิคเดียวกันโดย บีบให้เป็นประโยคสั้นลง
- คำอธิบายสาเหตุที่ React component re-render: 69 โทเค็น → 19 โทเค็น
- คำอธิบายบั๊กใน authentication middleware: ลดโทเค็นได้มากกว่า 75%
- ปรับระดับความบีบอัดได้ 3 ขั้นคือ Lite / Full / Ultra
- Lite (
/caveman lite): ตัดสำนวนที่ไม่จำเป็น แต่คงไวยากรณ์ไว้ — ยังเป็นมืออาชีพแต่ไม่เยิ่นเย้อ - Full (
/caveman full): โหมด caveman มาตรฐาน — ละ article ใช้ประโยคสั้น·เป็นท่อน - Ultra (
/caveman ultra): บีบอัดสูงสุด — สไตล์โทรเลข ย่อทุกอย่าง
- Lite (
เบนช์มาร์ก
- ผลเปรียบเทียบการใช้โทเค็นจริงผ่าน Claude API แสดงว่า ลดได้เฉลี่ย 65%
- ช่วงการลดลง: 22%~87%
- คำอธิบายบั๊ก React re-rendering: 1,180 → 159 โทเค็น (ลด 87%)
- การตั้งค่า PostgreSQL connection pool: 2,347 → 380 โทเค็น (ลด 84%)
- Docker multi-stage build: 1,042 → 290 โทเค็น (ลด 72%)
- คำอธิบาย git rebase vs merge: 702 → 292 โทเค็น (ลด 58%)
- รีแฟกเตอร์ callback → async/await: 387 → 301 โทเค็น (ลด 22%, ผลน้อยที่สุด)
- ลดเฉพาะ โทเค็นเอาต์พุต ส่วนโทเค็นการคิด·การให้เหตุผลคงเดิม
- ข้อดีหลักคือ อ่านง่ายขึ้นและตอบเร็วขึ้น ส่วนการลดค่าใช้จ่ายเป็นผลพ่วง
หลักฐานเชิงวิทยาศาสตร์
- งานวิจัยเดือนมีนาคม 2026 "Brevity Constraints Reverse Performance Hierarchies in Language Models": เมื่อบังคับให้โมเดลขนาดใหญ่ตอบแบบกระชับ พบว่า ความแม่นยำบนบางเบนช์มาร์กเพิ่มขึ้น 26 จุดเปอร์เซ็นต์ และลำดับประสิทธิภาพพลิกกลับ
- "Verbose not always better. Sometimes less word = more correct"
- มีกรณีที่ คำตอบสั้นกลับแม่นยำกว่าคำตอบยาว
วิธีติดตั้ง
- ติดตั้งบรรทัดเดียว:
npx skills add JuliusBrussee/caveman - ปลั๊กอิน Claude Code:
claude plugin marketplace add JuliusBrussee/caveman - Codex: โคลนรีโพแล้วค้นหาและติดตั้ง Caveman ในเมนู
/plugins - ทริกเกอร์:
/caveman, "talk like caveman", "caveman mode", "less tokens please" - ปิดการใช้งาน: "stop caveman" หรือ "normal mode"
- ติดตั้งครั้งเดียว → หลังจากนั้นใช้ได้กับทั้งเซสชัน
วิธีใช้งาน
-
คำสั่งทริกเกอร์:
/caveman,$caveman, “talk like caveman”, “caveman mode”, “less tokens please” -
คำสั่งยุติ: “stop caveman”, “normal mode”
-
ปรับระดับความแรง
Level Trigger คุณลักษณะ Lite /caveman liteคงไวยากรณ์ ตัดคำที่ไม่จำเป็น Full /caveman fullโหมดพื้นฐาน ตัด article·คำฟุ่มเฟือย Ultra /caveman ultraบีบอัดสูงสุด เน้นคำย่อ -
การตั้งค่าจะคงอยู่จนกว่าจะจบเซสชัน
-
MIT license / Python 100% / รองรับปลั๊กอิน Claude Code & Codex
2 ความคิดเห็น
พูดสไตล์สปาร์ตันที่นี่เหรอ..? 555
ความเห็นจาก Hacker News
ผู้เขียนเอง มีบางคนกำลังโต้แย้ง ข้ออ้างที่แรงกว่า สิ่งที่รีโปนี้อ้างไว้จริง ๆ อันที่จริงนี่ทำขึ้นเป็นมุก ไม่ใช่คอมเมนต์ระดับงานวิจัย
ทักษะนี้ไม่ได้มุ่งลด hidden reasoning token แต่โฟกัสที่การลด ข้อความส่วนเกินในผลลัพธ์ และไม่มีผลกับโค้ดเอง
ผมคิดว่าโมเดลของ Anthropic ถูกจูนด้วย RL มาดีพอ จึงยากที่จะทำให้ประสิทธิภาพตกอย่างหนักแบบจงใจ
ตัวเลข “~75%” ที่เขียนไว้ใน README เป็นผลทดสอบเบื้องต้น เลยควรเขียนอย่างระมัดระวังกว่านี้ ตอนนี้กำลังเตรียม benchmark แบบเป็นทางการอยู่
ทักษะนี้ไม่ฟรี และกิน context บางส่วนตอนโหลด ดังนั้นการประเมินจริงต้องรวมทั้ง input/output token, latency และคุณภาพ
ก็มีงานวิจัยที่บอกว่า prompt ที่กระชับสามารถลดความยาวของคำตอบโดยยังรักษาคุณภาพไว้ได้ (ลิงก์งานวิจัย)
สรุปคือ เป็นไอเดียที่น่าสนใจ แต่มีการตีความเกินจริงอยู่เยอะ และ README ก็ควรเขียนให้แม่นยำกว่านี้จนกว่าจะมีการประเมินอย่างเป็นทางการ
(แล้วก็ไม่เข้าใจว่าทำไมคอมเมนต์แนวนี้ถึงโดน downvote ตลอด)
ถ้าใส่พรอมป์ต์ว่า “จงทำตัวโง่” ก็ทำให้ประสิทธิภาพตกได้แน่นอน ประเด็นคือ สไตล์ผลลัพธ์ แบบหนึ่ง ๆ มีผลจริงมากแค่ไหน
ผมคิดมาตลอดว่าถ้าบังคับให้ LLM พูดต่างไปจากสไตล์ปกติ ความสามารถในการให้เหตุผล จะลดลง
เพราะเลเยอร์บางส่วนของโมเดลต้องทุ่มให้กับ “จะพูดอะไร” หรือ “จะพูดยังไง” อย่างใดอย่างหนึ่ง
ในการทดลองอย่างนิยายร่วมกันหรือ roleplay ผมเห็นว่ายิ่งโมเดลต้องคำนึงถึงข้อเท็จจริงมากเท่าไร ก็ยิ่งรักษาสไตล์ได้ยากขึ้น
ไอเดียนี้สนุกดี แต่ผมอยากเห็นแนวทางที่ใช้ โทเคนที่เข้มข้นกว่า ไม่ใช่แค่โทเคนที่น้อยลง
เช่น ใช้คำว่า “improve idiomatically” แทน “make good” ที่ละเอียดกว่า ภาษาเป็น ตัวมอดูเลต ที่ปรับความเป็นจริงได้ ดังนั้นการใช้ให้ประณีตกว่าน่าจะให้ผลดีกว่า รอ benchmark อยู่
ผมลองคุยกับ Claude แบบ caveman แล้ว ความเข้าใจ แย่ลงและมีการเข้าใจผิดเยอะ กลายเป็นว่าต้องอธิบายมากขึ้น และถ้ามีคำพิมพ์ผิดก็เสียบริบทหนักมาก
สุดท้ายเลยรู้สึกว่าต้องใช้คำมากกว่าเดิม แถม LLM ก็ดูเหมือนจะได้ข้อมูลจากคำตอบก่อนหน้าของตัวเองน้อยลงด้วย
ผมเห็นบทความที่ Grug brained developer มาเจอกับเครื่องมือ AI (grugbrain.dev)
ไอเดียนี้น่าสนใจ แต่ที่บริษัทผมวัดผลงานจาก ปริมาณการใช้โทเคน มีสกิลที่ทำให้ Claude พูดยืดยาวโดยตั้งใจไหม?
/tmpทุกลูปก็ได้เป็นไอเดียน่ารัก แต่ในทางปฏิบัติ input token ต่างหากที่เป็นคอขวด
โมเดลต้องอ่านไฟล์จำนวนมาก, ผลลัพธ์จากเครื่องมือ, และ directory tree แต่ผลลัพธ์กลับมีแค่โค้ดไม่กี่ร้อยบรรทัดกับคำอธิบายสั้น ๆ
อีกอย่าง ประเด็นเดียวกันก็สื่อได้โดยไม่ต้องขึ้นต้นด้วย “Cute idea, but” (ลิงก์)
มีงานวิจัยที่เกี่ยวข้องคือ ‘Brevity Constraints Reverse Performance Hierarchies in Language Models’ (2026)
น่าสนใจ อาจจะเอาผลลัพธ์ไป คลายบีบอัด ด้วยโมเดล 2B ต่อก็ได้
ไม่ก็มีคนลองไปแล้ว หรือไม่ผมก็อาจลงมือทำเอง
ถ้า LLM คุยกันด้วย ภาษาที่ไม่ใช่มนุษย์ แทนภาษามนุษย์ ประสิทธิภาพอาจดีขึ้นได้
โมเดลโลคัลขนาดเล็กจะแปลอินพุตจากมนุษย์เป็นภาษาที่เป็นมิตรกับ LLM แล้วโมเดลใหญ่ก็คิดด้วยภาษานั้นก่อนแปลกลับอีกที
โมเดลที่มี context window ขนาดเล็ก แบบ Apple Fundamental Models ก็อาจถูกใช้เป็นชั้นแปลลักษณะนี้ได้
และก็ดูเป็นไปได้ที่จะใช้ reinforcement learning ให้มันค้นพบภาษาประเภทนี้ได้เอง น่าจะเป็นโปรเจกต์ที่สนุกมาก
เพราะต้องสร้างทั้งภาษาใหม่และวิธีฝึกใหม่หมด ถึงอย่างนั้นถ้ามีใครไประดมทุน VC ได้ ผมก็อยากร่วมด้วย