Universal Claude.md - ลดโทเค็นเอาต์พุตของ Claude

• ไฟล์การตั้งค่าที่ช่วยลดการสิ้นเปลือง โทเค็นเอาต์พุต โดยตัด คำเกริ่นนำ คำลงท้าย และการกล่าวซ้ำที่ไม่จำเป็น ของโมเดล Claude
• เพียงเพิ่ม CLAUDE.md ที่รากโปรเจกต์ก็ ใช้งานได้ทันทีโดยไม่ต้องแก้โค้ด และช่วย ลดโทเค็นได้เฉลี่ย 63%
• ทำให้คำตอบกระชับขึ้นด้วยกฎ 12 ข้อ เช่น บังคับเอาต์พุตแบบ ASCII เท่านั้น, ห้ามเดา, จำกัดการตอบให้อยู่ในขอบเขตคำขอ
• ช่วยลดต้นทุนได้มากในสภาพแวดล้อมที่มีเอาต์พุตปริมาณมาก เช่น ไปป์ไลน์อัตโนมัติ, การสร้างโค้ด, ลูปเอเจนต์ แต่สำหรับคำถามเดี่ยวอาจไม่คุ้มค่า
• เผยแพร่ภายใต้ MIT License ทำให้สามารถจัดการกฎแบบ อิงโปรไฟล์ตามทีมและตามงาน และเปิดรับการมีส่วนร่วมจากชุมชน

---

ภาพรวมของปัญหา

• Claude Code มีต้นทุนเป็น โทเค็น สำหรับทุกคำที่สร้างขึ้น และในการตั้งค่าเริ่มต้นผู้ใช้ควบคุมรูปแบบคำตอบได้ยาก
• โดยปกติจะมี คำเกริ่นนำเชิงสุภาพ อย่าง “Sure!”, “Great question!”, คำลงท้ายตามมารยาท อย่าง “I hope this helps!”, การกล่าวทวนคำถาม, และ ข้อเสนอแนะที่ไม่จำเป็น ถูกใส่มาโดยอัตโนมัติ
• นอกจากนี้ยังใช้ตัวอักษรอย่าง em dash, smart quotes, อักขระ Unicode ที่อาจทำให้พาร์เซอร์พัง รวมถึงมี การทำโค้ดให้นามธรรมเกินไป หรือ การแสดงความเห็นด้วยที่ไม่ถูกต้อง
• สิ่งเหล่านี้ทำให้เกิด การสิ้นเปลืองโทเค็น ทั้งที่แทบไม่มีคุณค่าด้านข้อมูลจริง

วิธีแก้ปัญหา

• เพิ่มไฟล์ CLAUDE.md ไว้ที่รากโปรเจกต์ แล้ว Claude Code จะอ่านโดยอัตโนมัติและ เปลี่ยนพฤติกรรมเอาต์พุตได้ทันที
• ทำงานได้โดยไม่ต้องแก้โค้ดหรือเพิ่มการตั้งค่าใดๆ และช่วย ลดการใช้โทเค็นเอาต์พุตได้ราว 63%
• ตัวอย่างโครงสร้าง

  your-project/
  └── CLAUDE.md
  

กรณีที่เหมาะและไม่เหมาะกับการใช้งาน

• กรณีที่เหมาะ

  • งานอย่าง ไปป์ไลน์อัตโนมัติ, ลูปเอเจนต์, การสร้างโค้ด ที่มีปริมาณเอาต์พุตสูง

    • เมื่อเป็น งานที่ทำซ้ำและมีโครงสร้าง ซึ่งคำตอบเริ่มต้นที่ยืดยาวของ Claude สะสมขึ้นเรื่อยๆ
    • สภาพแวดล้อมแบบทีมที่ต้องการ รูปแบบเอาต์พุตที่สม่ำเสมอข้ามเซสชัน

• กรณีที่ไม่เหมาะ

  • สำหรับ คำถามสั้นเพียงครั้งเดียว หรือ การใช้งานครั้งเดียวจบ นั้น CLAUDE.md จะกินโทเค็นอินพุตทุกครั้ง จึงอาจทำให้ต้นทุนเพิ่มขึ้นแทน
  • ไม่ได้ช่วยกับการแก้ปัญหาเชิงลึก เช่น การแก้ hallucination หรือ การแก้ข้อผิดพลาดด้านสถาปัตยกรรม
  • ใน ไปป์ไลน์ที่เปิดเซสชันใหม่ทุกงาน ประโยชน์จากการประหยัดแบบอิงเซสชันต่อเนื่องจะหายไป
  • หากต้องการ ความน่าเชื่อถือของพาร์เซอร์ในระดับใหญ่ การใช้โหมด JSON หรือเครื่องมือแบบอิงสคีมาจะเหมาะกว่า
  • สำหรับ งานเชิงสำรวจหรือเน้นการอภิปราย อาจรู้สึกว่ามีข้อจำกัดมากเกินไป

• จุดแลกเปลี่ยนที่เกิดขึ้นจริง

  • เนื่องจาก CLAUDE.md เองก็ใช้โทเค็นอินพุต จึงจะ คุ้มค่าแบบสุทธิเมื่อมีปริมาณเอาต์พุตมากพอเท่านั้น
  • ในการใช้งานปริมาณน้อย ต้นทุนอาจสูงกว่าปริมาณที่ประหยัดได้

ผลการเบนช์มาร์ก

• ทดสอบด้วยพรอมป์ต์ชุดเดียวกัน 5 รายการ

  การทดสอบ	ค่าเริ่มต้น	ปรับให้เหมาะสม	อัตราการลด
  อธิบาย async/await	180 คำ	65 คำ	64%
  รีวิวโค้ด	120 คำ	30 คำ	75%
  อธิบาย REST API	110 คำ	55 คำ	50%
  แก้ hallucination	55 คำ	20 คำ	64%
  รวม	465 คำ	170 คำ	63%

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

• ตัวอย่างการประหยัดเมื่อใช้งานขนาดใหญ่

  ปริมาณการใช้งาน	โทเค็นที่ประหยัดได้ต่อวัน	มูลค่าที่ประหยัดได้ต่อเดือน (อ้างอิง Sonnet)
  100 ครั้ง/วัน	ประมาณ 9,600	ประมาณ $0.86
  1,000 ครั้ง/วัน	ประมาณ 96,000	ประมาณ $8.64
  3 โปรเจกต์	ประมาณ 288,000	ประมาณ $25.92

ตัวอย่างเปรียบเทียบก่อนและหลัง

• คำตอบรีวิวโค้ดแบบเริ่มต้น (120 คำ)

  • มีทั้งคำชม คำอธิบาย และข้อเสนอแนะที่ยืดยาว

• หลังใช้ CLAUDE.md (30 คำ)

  • ถ่ายทอดเฉพาะสาระสำคัญในรูปแบบอย่าง “Bug: <= causes an off-by-one error…” พร้อม ลดโทเค็นได้ 75%

สิ่งที่ถูกปรับแก้

หมายเลข	ปัญหา	วิธีแก้
1	คำเกริ่นนำเชิงประจบ	ห้าม - เริ่มตอบตั้งแต่บรรทัดแรก
2	คำลงท้ายว่างเปล่า	ห้าม - ลบ “I hope this helps!”
3	การกล่าวทวนคำถาม	ห้าม - ลงมือทำทันที
4	em dash, smart quotes, Unicode	บังคับเอาต์พุตแบบ ASCII เท่านั้น
5	วลี “As an AI…”	ห้าม
6	ข้อสงวนความรับผิดที่ไม่จำเป็น	อนุญาตเฉพาะเมื่อมีความเสี่ยงด้านความปลอดภัยจริง
7	ข้อเสนอแนะนอกคำขอ	ห้าม - ทำเฉพาะในขอบเขตคำขอ
8	การทำโค้ดให้นามธรรมเกินไป	อนุญาตเฉพาะโค้ดที่ทำงานได้และง่ายที่สุด
9	การเดาข้อเท็จจริงที่ไม่แน่ชัดจนเกิด hallucination	ระบุว่า “ไม่ทราบ” และห้ามเดา
10	เมินการแก้ไขของผู้ใช้	ให้สิ่งที่ผู้ใช้แก้กลายเป็นข้อเท็จจริงของเซสชัน
11	อ่านไฟล์ซ้ำ	ห้ามอ่านไฟล์เดิมซ้ำ
12	ขยายขอบเขตงาน	ห้ามแก้โค้ดนอกเหนือจากที่ร้องขอ

เคล็ดลับจากชุมชน

• การเขียนกฎให้ตรงกับ รูปแบบความล้มเหลวที่เกิดขึ้นจริง มีประสิทธิภาพที่สุด
  • ตัวอย่าง: หาก Claude กลบข้อผิดพลาดของไปป์ไลน์ -> เพิ่มกฎ “หากขั้นตอนล้มเหลวให้หยุดทันทีและรายงานข้อผิดพลาดทั้งหมดพร้อม traceback”

• ไฟล์ CLAUDE.md สามารถรวมแบบลำดับชั้นได้

  • ระดับ global (~/.claude/CLAUDE.md): กฎทั่วไป เช่น โทนภาษา, ASCII
  • รากโปรเจกต์: ข้อจำกัดเฉพาะโปรเจกต์ เช่น ห้ามแก้ /config
  • ไดเรกทอรีย่อย: กฎเฉพาะงานอย่างละเอียด
  • วิธีนี้ช่วยให้ กระจายการจัดการกฎ และหลีกเลี่ยงไม่ให้ไฟล์ใหญ่เกินไป

การจัดโปรไฟล์

• สามารถเลือกระดับการบีบอัดต่างกันตามประเภทโปรเจกต์

  โปรไฟล์	เหมาะสำหรับ
  CLAUDE.md	ใช้งานทั่วไป
  profiles/CLAUDE.coding.md	งานพัฒนา, รีวิวโค้ด, ดีบัก
  profiles/CLAUDE.agents.md	ระบบอัตโนมัติ, ระบบหลายเอเจนต์
  profiles/CLAUDE.analysis.md	วิเคราะห์ข้อมูล, รีเสิร์ช, รายงาน

วิธีใช้งาน

• ตัวเลือก 1 (ทั่วไป)

  curl -o CLAUDE.md https://raw.githubusercontent.com/drona23/claude-token-efficient/…
  

• ตัวเลือก 2 (เลือกโปรไฟล์)

  git clone https://github.com/drona23/claude-token-efficient
  cp claude-token-efficient/profiles/CLAUDE.coding.md your-project/CLAUDE.md
  

• ตัวเลือก 3 (ทำเอง)

  • คัดลอกเนื้อหา CLAUDE.md จากรีโพซิทอรีโดยตรง

กฎการ override

• คำสั่งของผู้ใช้มีลำดับความสำคัญสูงสุดเสมอ

  • หากผู้ใช้ระบุชัดเจน เช่น “อธิบายแบบละเอียด” Claude จะทำตามนั้น
  • CLAUDE.md จะไม่ขัดขวางเจตนาของผู้ใช้

วิธีมีส่วนร่วม

• หากพบพฤติกรรมที่ควรแก้ไข ให้เปิด Issue พร้อมระบุ
  1. พฤติกรรมเริ่มต้นที่เป็นปัญหา
  2. พรอมป์ต์ที่ทำให้เกิดพฤติกรรมนั้น
  3. กฎการแก้ไขที่เสนอ
• ข้อเสนอจากชุมชนจะถูกรวมในเวอร์ชันถัดไป และ มอบเครดิตให้ผู้มีส่วนร่วม

การตรวจสอบและข้อมูลอ้างอิง

• สามารถดูผลเบนช์มาร์กทั้งหมดได้ใน BENCHMARK.md
• โปรเจกต์นี้สร้างขึ้นจาก กรณีร้องเรียนจริงในชุมชน Claude
• มีแหล่งอ้างอิงที่เกี่ยวข้องหลายแห่งรวมอยู่ด้วย (GitHub Issues, The Register, DEV Community, Medium, Anthropic Docs เป็นต้น)

ไลเซนส์

• MIT License สามารถใช้งาน แก้ไข และแจกจ่ายได้อย่างอิสระ

[GN⁺]

ความคิดเห็นใน Hacker News

• benchmark ตรงนี้เอนเอียงไปทาง งานอธิบายแบบครั้งเดียว และดูไม่เหมาะกับ agent loop อย่างการสร้างโค้ด
  สงสัยว่าระหว่างที่โปรเจกต์กำลังดำเนินอยู่ ความอธิบายที่ยืดยาวของ Claude อาจช่วยรักษา ความสม่ำเสมอและสมาธิ ของเซสชันได้มากกว่าหรือไม่
  กฎอย่าง “อย่าพูดซ้ำ context ที่ซ้ำซ้อน” นั้นดี แต่ฉันกลับคิดว่าการใช้โทเค็นกับการให้เหตุผลที่มุ่งเป้าหมายมากขึ้นมีประโยชน์กว่า
  ยังมีข้อมูลไม่พอว่าท่าทีแบบนี้ได้ผลจริงแค่ไหนกับ agentic coding

  • ฉันทำ skill ชื่อ /handoff เพื่อให้มันสร้าง รายงาน Markdown อัตโนมัติก่อนที่เซสชันจะชนขีดจำกัดการบีบอัด
    ไฟล์นี้ทำหน้าที่เป็นบันทึกถาวรของเซสชันและเป็น “รายงานประจำวัน” ไปด้วยในตัว จึงสะดวกทั้งสำหรับอ้างอิงภายหลังหรือแชร์ให้ผู้จัดการ
    ถ้าจะรักษาความสม่ำเสมอระยะยาว ฉันคิดว่าแนวทาง สรุปเป็นเอกสาร แบบนี้ดีกว่า
    วิธีติดตั้งโพสต์ไว้ ที่นี่
  • กฎ “อย่าอธิบายว่าจะทำอะไร แค่ลงมือทำ” ช่วยให้ฉันสังเกตได้ทันทีเมื่อ Claude กำลังไปผิดทาง แล้วแก้พรอมป์ต์ได้ทัน
  • ไม่เข้าใจว่าทำไมคนถึงไม่ใส่กฎกัน ภาษาที่ไม่จำเป็น ลงใน CLAUDE.md
    งานวิจัยล่าสุดบอกว่า เส้นทางการให้เหตุผลที่ซ้ำกัน (self-consistency) และ model ensembling ช่วยเพิ่มประสิทธิภาพได้
  • การสเกลเวลาให้เหตุผล ก็สำคัญ การใช้โทเค็นมากขึ้นระหว่างหาคำตอบกลับช่วยยกระดับคุณภาพ
    ถ้ายึดติดกับความสั้นที่สุดมากเกินไปก็จะขัดกับเป้าหมายการฝึกแบบ RL
  • ฉันลองรัน coding test ด้วยหลายการตั้งค่าแล้ว แนวทางนี้ให้ ประสิทธิภาพต่ำกว่าโดยรวม ใน 30 รอบ
    โค้ดทดสอบอยู่ ที่นี่

• เพราะ planning mode ของ Claude Code ทำงานได้ไม่ดี ฉันเลยค่อนข้างสงสัยกับแนวทางใช้ไฟล์ .md
  สำหรับฉัน planning mode น่าจะเป็นแค่ฟังก์ชันที่ปิดการเขียนไฟล์เท่านั้น

• กฎอย่าง “ให้คำตอบอยู่บรรทัดแรกเสมอ แล้วค่อยตามด้วยเหตุผล” มองข้าม คุณสมบัติแบบ autoregressive ของ LLM
  ถ้าตรึงคำตอบไว้ก่อน การให้เหตุผลทีหลังมีความเสี่ยงสูงที่จะเกิด confirmation bias

  • แนวคิดนี้ดี แต่เหมือนวิธีนำไปใช้จะผิดทาง
    วิธีบีบอัดการให้เหตุผลแบบในงานวิจัย Compressed Chain of Thought (CCoT) น่าจะมีประสิทธิภาพกว่า
    คุณภาพอาจลดลงเล็กน้อย แต่ได้เปรียบด้านความเร็วและต้นทุน (ลิงก์งานวิจัย)
  • ในเซสชันสำคัญ ฉันจะเพิ่ม พรอมป์ต์ตรวจทานรอบสอง อย่าง “sanity check” เพื่อให้ทบทวนแผนช่วงต้นอีกครั้ง
  • reasoning LLM สามารถสร้าง โทเค็นการให้เหตุผล ภายในได้เป็นพันโทเค็นก่อนเขียนคำตอบ
    ดังนั้นกฎ “ตอบก่อน” จึงแค่เปลี่ยนลำดับการแสดงผล ไม่ได้เปลี่ยนลำดับการคิดจริง
  • Claude Code ไม่มีตัวเลือก “no thinking” และอย่างน้อยก็ใช้โหมด low thinking เป็นค่าเริ่มต้น

• benchmark นี้ไม่มีความหมาย เพราะ เทียบแค่จำนวนโทเค็นเอาต์พุตโดยไม่คำนึงถึงความแม่นยำ
  แค่ใช้พรอมป์ต์ว่า “ตอบเป็นคำเดียวเสมอ” ก็ปั่นคะแนนให้สูงได้ง่าย
  กฎอย่าง “ถ้าผู้ใช้ชี้ข้อผิดพลาดเชิงข้อเท็จจริง ให้ยอมรับเสมอ” ก็อันตราย

  • ถึงจะพูดกันว่า “prompt engineering กลับมาแล้ว?” แต่ช่วง 1-2 ปีที่ผ่านมา meta prompt ก็แทบไม่ได้ช่วยให้ดีขึ้นนัก
  • กฎแนว “อย่าทำผิด” ไม่ใช่สิ่งที่ใช้ได้จริง

• พวกแนว โซลูชันครอบจักรวาล แบบนี้น่าจะทำให้คนหมดความสนใจเร็ว หรือไม่ก็ถูกดูดซึมเข้าไปใน CC
  การเปลี่ยน workflow บ่อย ๆ มันเหนื่อยเกินไป
  ตอนนี้การตั้งค่าเริ่มต้นของ Claude Code ยังเสถียรที่สุด

  • ฉันก็คิดคล้ายกัน รู้สึกว่าการคง vanilla setting ไว้ดีกว่าในระยะยาว
    Skills นั้นดี แต่ฉันแทบไม่ได้ใช้ MCP หรือ worktree เลย
  • ในเมื่อ Anthropic เองก็ปรับแต่งผ่าน dogfooding ภายใน อยู่แล้ว การตั้งค่าเริ่มต้นก็น่าจะมีโอกาสสูงสุดที่จะมีประสิทธิภาพที่สุด
    แค่ใช้ CLAUDE.md เหมือนโน้ตร่างที่ส่งให้เพื่อนร่วมงานเก่ง ๆ ก็มักทำงานได้ดีพอแล้ว
  • เห็นด้วยกับคำพูดที่ว่า “เดี๋ยวสุดท้ายก็คงถูกรวมเข้า CC”
    ถ้าเป็นฟีเจอร์ที่ Anthropic ยังไม่ได้ใส่มาเอง ก็น่าจะเพราะ ยังพิสูจน์ไม่ได้ว่าช่วยเพิ่มประสิทธิภาพ
  • “ชั้นเสริมปรับปรุง Claude” แบบนี้สุดท้ายมักนำไปสู่ ความไม่เสถียรของ workflow
    ต่อให้มีประโยชน์ชั่วคราว ไม่นานก็ถูกดูดเข้าเป็นฟังก์ชันพื้นฐานหรือหายไป
  • ตัว Claude เองก็อัปเดต ฟังก์ชันปรับแต่ง md อยู่เรื่อย ๆ
    ดังนั้นถึงจะใช้สคริปต์ทดลองแบบนี้ ถ้าอัปเดตไฟล์ md บ่อย ๆ ก็ยังตามให้ทันของใหม่ได้

• สำหรับคำถามว่า “ถ้าไฟล์ถูกโหลดเข้า context ทุกข้อความ แบบนั้นไม่เปลืองโทเค็นหรือ?”
  ฉันคิดว่าฟีเจอร์ personalization ของ Claude ก็ทำหน้าที่นั้นอยู่แล้ว
  ฉันมองว่า ความกระชับมีความหมายก็ต่อเมื่อช่วยให้คุณภาพดีขึ้นเท่านั้น
  เครื่องมือที่เกี่ยวข้องซึ่งเห็นใน Reddit ก็น่าสนใจ:
  Headroom บีบอัด context ได้ 34%,
  RTK บีบอัดเอาต์พุต CLI ได้ 60~90%,
  MemStack ให้ หน่วยความจำถาวร เพื่อเลี่ยงการอ่านไฟล์ซ้ำโดยไม่จำเป็น

• รู้สึกว่าความพยายามแบบนี้กลับเป็นผลจากการเข้าใจ หลักการพื้นฐานของ LLM ผิด
  “ตอบก่อน ค่อยให้เหตุผลทีหลัง” เป็นการมองข้าม โครงสร้าง autoregressive ของ transformer
  ในเมื่อการฝึกแบบ RL ปรับสมดุลระหว่างความยาวที่เหมาะสมกับคุณภาพไว้อยู่แล้ว การปรับแต่งมากเกินไปอาจนำไปสู่ ประสิทธิภาพที่แย่ลง

  • ถ้าฝืนลดความยาวของคำตอบลง คุณภาพและความสม่ำเสมอของการให้เหตุผล จะตก และ โอกาสหลอน จะสูงขึ้น
    โมเดลถูกฝึกให้ทำการให้เหตุผลหลายขั้นโดยมีภาษาอังกฤษเป็นฐาน
  • กฎ “ตอบก่อน” ไม่ได้เปลี่ยนลำดับการคิดจริง โมเดลคิดเสร็จภายในก่อนแล้วค่อยพิมพ์คำตอบออกมาอยู่ดี
  • ผู้เขียนอาจไม่ได้ไม่รู้เรื่อง transformer แต่แค่กำลังลอง แฮ็กเพื่อลดต้นทุนโทเค็น
    เป็นแนวทางเชิงทดลองที่เน้นประสิทธิภาพมากกว่าคุณภาพ
  • API ส่วนใหญ่มี ตัวเลือกควบคุมความยาว COT อยู่แล้ว ฉันคิดว่าใช้การตั้งค่า API ตรง ๆ จะดีกว่าทางลัดแบบนี้
  • สุดท้ายฉันก็ยังคิดว่า เครื่องมือที่ Anthropic ทำเอง น่าเชื่อถือที่สุด
    เพราะงั้นฉันจึงใช้แต่ เครื่องมือ first-party ไม่ใช้ third-party อย่าง OpenCode

• อย่างที่เห็นในวิดีโอของ Karpathy ยิ่งโมเดลใช้โทเค็นมากขึ้น ความแม่นยำก็มีแนวโน้มสูงขึ้น
  แนวทางนี้อาจยิ่งทำให้โมเดลแย่ลง

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

• ไม่เข้าใจว่าทำไมโปรเจกต์ ไร้ความหมาย แบบนี้ถึงกลายเป็นเทรนด์บน HN
  เครื่องมือที่ช่วยลดการใช้โทเค็นได้จริงคือ claude-mem และ lumen

  • เหตุผลง่ายมาก อัลกอริทึมเทรนด์ของ HN ปรับให้เหมาะกับ การมีส่วนร่วมมากกว่าความแม่นยำ

• เมื่อก่อนเราวิจัย อัลกอริทึมแฮช การเข้ารหัส และการบีบอัด แบบใหม่ ๆ กัน
  ตอนนี้กลับมาศึกษาวิธีสั่ง AI ให้ เงียบ ๆ หน่อย แทน มันช่างประชดประชันดีจริง ๆ