30 คะแนน โดย GN⁺ 24 일 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • สกิลที่บังคับให้ตอบด้วย สำนวนพูดแบบมนุษย์ถ้ำ เพื่อลด โทเค็นเอาต์พุตเฉลี่ย 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): บีบอัดสูงสุด — สไตล์โทรเลข ย่อทุกอย่าง

เบนช์มาร์ก

  • ผลเปรียบเทียบการใช้โทเค็นจริงผ่าน 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 ความคิดเห็น

 
joyfui 24 일 전

พูดสไตล์สปาร์ตันที่นี่เหรอ..? 555

 
GN⁺ 24 일 전
ความเห็นจาก Hacker News
  • ผู้เขียนเอง มีบางคนกำลังโต้แย้ง ข้ออ้างที่แรงกว่า สิ่งที่รีโปนี้อ้างไว้จริง ๆ อันที่จริงนี่ทำขึ้นเป็นมุก ไม่ใช่คอมเมนต์ระดับงานวิจัย
    ทักษะนี้ไม่ได้มุ่งลด hidden reasoning token แต่โฟกัสที่การลด ข้อความส่วนเกินในผลลัพธ์ และไม่มีผลกับโค้ดเอง
    ผมคิดว่าโมเดลของ Anthropic ถูกจูนด้วย RL มาดีพอ จึงยากที่จะทำให้ประสิทธิภาพตกอย่างหนักแบบจงใจ
    ตัวเลข “~75%” ที่เขียนไว้ใน README เป็นผลทดสอบเบื้องต้น เลยควรเขียนอย่างระมัดระวังกว่านี้ ตอนนี้กำลังเตรียม benchmark แบบเป็นทางการอยู่
    ทักษะนี้ไม่ฟรี และกิน context บางส่วนตอนโหลด ดังนั้นการประเมินจริงต้องรวมทั้ง input/output token, latency และคุณภาพ
    ก็มีงานวิจัยที่บอกว่า prompt ที่กระชับสามารถลดความยาวของคำตอบโดยยังรักษาคุณภาพไว้ได้ (ลิงก์งานวิจัย)
    สรุปคือ เป็นไอเดียที่น่าสนใจ แต่มีการตีความเกินจริงอยู่เยอะ และ README ก็ควรเขียนให้แม่นยำกว่านี้จนกว่าจะมีการประเมินอย่างเป็นทางการ

    • ฟังดูสมเหตุสมผล การถกเถียงออนไลน์ก็มักไหลไปแบบนี้อยู่แล้ว ถึงอย่างนั้นเธรดนี้ก็ยังดีกว่าค่าเฉลี่ย แม้จะมีช่วงที่น่าผิดหวังบ้าง
    • ถ้าอยากได้ benchmark แนะนำให้ดู adam-s/testing-claude-agent
    • สรุปสั้น ๆ คือ “นี่เป็นมุก อย่ามาโกรธฉัน แต่ก็เหมือนจะได้ผลนิดหน่อย?”
    • ผมก็เคยคุยแบบคล้าย ๆ กันกับ LLM แล้วอธิบายว่า มันมักตอบสั้นกับคำถามสั้น และให้ คำตอบที่ข้อมูลแน่นกว่า กับคำขอที่สุภาพ สุดท้ายแล้ววิธีถามย่อมมีผลต่อสไตล์คำตอบ
      (แล้วก็ไม่เข้าใจว่าทำไมคอมเมนต์แนวนี้ถึงโดน downvote ตลอด)
    • คำพูดที่ว่า “โมเดล Anthropic ถูกปรับแต่งมาเพื่อการเขียนโค้ด จึงบังคับให้ประสิทธิภาพแย่ลงไม่ได้” ฟังดูชวนสับสนอยู่หน่อย
      ถ้าใส่พรอมป์ต์ว่า “จงทำตัวโง่” ก็ทำให้ประสิทธิภาพตกได้แน่นอน ประเด็นคือ สไตล์ผลลัพธ์ แบบหนึ่ง ๆ มีผลจริงมากแค่ไหน
  • ผมคิดมาตลอดว่าถ้าบังคับให้ LLM พูดต่างไปจากสไตล์ปกติ ความสามารถในการให้เหตุผล จะลดลง
    เพราะเลเยอร์บางส่วนของโมเดลต้องทุ่มให้กับ “จะพูดอะไร” หรือ “จะพูดยังไง” อย่างใดอย่างหนึ่ง
    ในการทดลองอย่างนิยายร่วมกันหรือ roleplay ผมเห็นว่ายิ่งโมเดลต้องคำนึงถึงข้อเท็จจริงมากเท่าไร ก็ยิ่งรักษาสไตล์ได้ยากขึ้น

    • ในทางกลับกัน ถ้าบอกให้ “พูดเยิ่นเย้อ” ผลลัพธ์จะยาวขึ้นมาก ตัวกำหนดบุคลิก มีผลค่อนข้างมากจริง ๆ
    • ผมก็คิดคล้ายกัน สุดท้ายแล้วโมเดลมี attention budget จำกัด เลยทำอะไรพร้อมกันได้จำกัด
  • ไอเดียนี้สนุกดี แต่ผมอยากเห็นแนวทางที่ใช้ โทเคนที่เข้มข้นกว่า ไม่ใช่แค่โทเคนที่น้อยลง
    เช่น ใช้คำว่า “improve idiomatically” แทน “make good” ที่ละเอียดกว่า ภาษาเป็น ตัวมอดูเลต ที่ปรับความเป็นจริงได้ ดังนั้นการใช้ให้ประณีตกว่าน่าจะให้ผลดีกว่า รอ benchmark อยู่

    • สไตล์ “caveman” นี้ทำให้นึกถึงภาษาของ โทรเลข (telegram) สมัยก่อน จะเป็นไปได้ไหมถ้าโมเดลเรียนรู้ “โทเคนเข้มข้น” แบบที่บีบข้อมูลเหมือนพจนานุกรมคำย่อโทรเลข แล้วให้เบราว์เซอร์ถอดความออก ลิงก์พจนานุกรมคำย่อโทรเลข
    • มันเหมือนข้อถกเถียง RISC vs CISC เลย ความเรียบง่ายชนะในด้านการขยายขนาด และ LLM ก็ดูเหมือนกำลังพัฒนาไปในทางที่คิดด้วยแนวคิดที่เรียบง่ายและแยกส่วนชัดเจน
    • มีคนเสนอให้ลองพรอมป์ต์อย่าง “MILSPEC prose register. Max per-token semantic yield.”
  • ผมลองคุยกับ Claude แบบ caveman แล้ว ความเข้าใจ แย่ลงและมีการเข้าใจผิดเยอะ กลายเป็นว่าต้องอธิบายมากขึ้น และถ้ามีคำพิมพ์ผิดก็เสียบริบทหนักมาก
    สุดท้ายเลยรู้สึกว่าต้องใช้คำมากกว่าเดิม แถม LLM ก็ดูเหมือนจะได้ข้อมูลจากคำตอบก่อนหน้าของตัวเองน้อยลงด้วย

    • ในฟอรัมทั่วไป (Twitter, Reddit) คนชอบบ่นว่า LLM โง่ แต่พอดู วิธีเขียน ของพวกเขาแล้วก็เข้าใจเลยว่าทำไม
    • ตอน ChatGPT ช่วงแรก ๆ ผมเคยลองคุยด้วย s-expression อย่างเดียว โมเดลก็ตอบกลับมาเป็น s-expression เหมือนกัน เนื้อหาเละเทะ แต่ใส่วงเล็บถูก ตอนนี้ไม่เป็นแบบนั้นแล้ว
    • “พูดเยอะทำไม? พูดน้อยประหยัดเวลา ทะเลโลก”
    • ข้อมูลสไตล์ “caveman” ส่วนใหญ่ไม่ได้เป็นบทสนทนาทางวิทยาศาสตร์ เลยดูเหมือนโมเดลจะทำนายบริบทแบบนั้นไม่ค่อยได้
  • ผมเห็นบทความที่ Grug brained developer มาเจอกับเครื่องมือ AI (grugbrain.dev)

    • ผมก็ชอบใช้ Grug เป็นตัวอย่างเวลาจะให้ LLM อธิบายแนวคิดเหมือนกัน
  • ไอเดียนี้น่าสนใจ แต่ที่บริษัทผมวัดผลงานจาก ปริมาณการใช้โทเคน มีสกิลที่ทำให้ Claude พูดยืดยาวโดยตั้งใจไหม?

    • ให้มันอธิบายแบบ ELI5 ลง /tmp ทุกลูปก็ได้
    • พูดจริงหรือเล่นมุก? ทำงานที่ Nvidia อยู่หรือเปล่า?
  • เป็นไอเดียน่ารัก แต่ในทางปฏิบัติ input token ต่างหากที่เป็นคอขวด
    โมเดลต้องอ่านไฟล์จำนวนมาก, ผลลัพธ์จากเครื่องมือ, และ directory tree แต่ผลลัพธ์กลับมีแค่โค้ดไม่กี่ร้อยบรรทัดกับคำอธิบายสั้น ๆ

    • ถ้าเป็นเทิร์นเดียวก็จริง แต่พอสะสมหลายเทิร์น การปรับผลลัพธ์ให้เหมาะสมก็มีความหมาย
      อีกอย่าง ประเด็นเดียวกันก็สื่อได้โดยไม่ต้องขึ้นต้นด้วย “Cute idea, but” (ลิงก์)
    • อีกอย่าง ทักษะนี้ไม่ได้มีผลกับ thinking token เลย อันที่จริงการแปลงเป็นสไตล์ caveman อาจต้องใช้การให้เหตุผลภายในมากขึ้นด้วยซ้ำ
  • มีงานวิจัยที่เกี่ยวข้องคือ ‘Brevity Constraints Reverse Performance Hierarchies in Language Models’ (2026)

  • น่าสนใจ อาจจะเอาผลลัพธ์ไป คลายบีบอัด ด้วยโมเดล 2B ต่อก็ได้

  • ไม่ก็มีคนลองไปแล้ว หรือไม่ผมก็อาจลงมือทำเอง
    ถ้า LLM คุยกันด้วย ภาษาที่ไม่ใช่มนุษย์ แทนภาษามนุษย์ ประสิทธิภาพอาจดีขึ้นได้
    โมเดลโลคัลขนาดเล็กจะแปลอินพุตจากมนุษย์เป็นภาษาที่เป็นมิตรกับ LLM แล้วโมเดลใหญ่ก็คิดด้วยภาษานั้นก่อนแปลกลับอีกที
    โมเดลที่มี context window ขนาดเล็ก แบบ Apple Fundamental Models ก็อาจถูกใช้เป็นชั้นแปลลักษณะนี้ได้
    และก็ดูเป็นไปได้ที่จะใช้ reinforcement learning ให้มันค้นพบภาษาประเภทนี้ได้เอง น่าจะเป็นโปรเจกต์ที่สนุกมาก

    • ผมก็เคยคิดคล้าย ๆ กัน ถ้าสร้าง ภาษาเฉพาะสำหรับ LLM แล้วฝึกโมเดลด้วยภาษานั้นก็น่าจะดี แต่คงต้องใช้เงินราว 60–100 ล้านดอลลาร์
      เพราะต้องสร้างทั้งภาษาใหม่และวิธีฝึกใหม่หมด ถึงอย่างนั้นถ้ามีใครไประดมทุน VC ได้ ผมก็อยากร่วมด้วย