Universal Claude.md - Giảm token đầu ra của Claude

 (github.com/drona23)
2 điểm bởi GN⁺ 21 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Tệp cấu hình giúp giảm lãng phí token đầu ra bằng cách loại bỏ phần mở đầu, kết thúc và diễn đạt lại không cần thiết của mô hình Claude
  • Chỉ cần thêm CLAUDE.md vào thư mục gốc của dự án là áp dụng ngay mà không cần sửa mã, với hiệu quả giảm trung bình 63% số token
  • Tối giản phản hồi bằng 12 quy tắc như chỉ xuất ASCII, không suy đoán, giới hạn trả lời trong phạm vi yêu cầu
  • Mang lại hiệu quả tiết kiệm chi phí lớn trong các môi trường xuất lượng lớn như pipeline tự động hóa, sinh mã, vòng lặp tác tử, nhưng có thể kém hiệu quả với truy vấn đơn lẻ
  • Được phát hành theo giấy phép MIT, cho phép quản lý quy tắc dựa trên hồ sơ theo nhóm hoặc theo công việc và đóng góp từ cộng đồng

Tổng quan vấn đề

  • Claude Code khiến mọi từ được tạo ra đều phát sinh chi phí token, và ở thiết lập mặc định người dùng khó kiểm soát định dạng phản hồi
  • Mặc định thường tự động chèn mở đầu lịch sự như "Sure!", "Great question!", kết thúc mang tính hình thức như "I hope this helps!", diễn đạt lại câu hỏi và đề xuất không cần thiết
  • Ngoài ra còn dùng các ký tự có thể làm hỏng parser như em dash, dấu ngoặc kép thông minh, ký tự Unicode, đồng thời chứa mức độ trừu tượng hóa mã quá mức hoặc những biểu đạt đồng ý không chính xác
  • Điều này dẫn đến lãng phí token trong khi giá trị thông tin thực tế gần như không có

Cách giải quyết

  • Thêm tệp CLAUDE.md vào thư mục gốc của dự án để Claude Code tự động đọc và thay đổi hành vi đầu ra ngay lập tức
  • Hoạt động mà không cần sửa mã hay cấu hình bổ sung, đồng thời giảm khoảng 63% lượng token đầu ra sử dụng
  • Ví dụ cấu trúc 
    your-project/
└── CLAUDE.md

Khi nào nên áp dụng và khi nào không nên

  • Trường hợp có lợi

    • Các tác vụ có lượng đầu ra lớn như pipeline tự động hóa, vòng lặp tác tử, sinh mã

      • Khi các tác vụ lặp lại và có cấu trúc khiến phản hồi mặc định dài dòng của Claude bị cộng dồn
      • Môi trường làm việc nhóm cần định dạng đầu ra nhất quán giữa các phiên

  • Trường hợp bất lợi

    • Với truy vấn ngắn đơn lẻ hoặc sử dụng một lần, CLAUDE.md sẽ chiếm token đầu vào mỗi lần, nên chi phí có thể còn tăng
    • Không hiệu quả với việc giải quyết vấn đề chuyên sâu như sửa ảo giác (hallucination) hay chỉnh lỗi kiến trúc
    • Trong pipeline mở phiên mới cho mỗi tác vụ, hiệu quả tiết kiệm dựa trên phiên duy trì sẽ biến mất
    • Để đảm bảo độ tin cậy parser ở quy mô lớn, chế độ JSON hoặc công cụ dựa trên schema phù hợp hơn
    • Có thể gây cảm giác gò bó với các công việc mang tính khám phá hoặc thảo luận

  • Điểm đánh đổi thực tế

    • Bản thân CLAUDE.md cũng tiêu tốn token đầu vào, nên chỉ có lãi ròng khi lượng đầu ra đủ lớn
    • Với mức sử dụng thấp, chi phí có thể lớn hơn phần tiết kiệm

Kết quả benchmark

  • Kiểm thử với cùng 5 prompt
    Kiểm thử Mặc định Tối ưu hóa Tỷ lệ giảm
    Giải thích async/await 180 từ 65 từ 64%
    Code review 120 từ 30 từ 75%
    Giải thích REST API 110 từ 55 từ 50%
    Sửa ảo giác 55 từ 20 từ 64%
    Tổng cộng 465 từ 170 từ 63%
  • Tiết kiệm khoảng 295 từ, không mất thông tin
  • Tuy nhiên đây chỉ là chỉ báo định hướng, không có kiểm soát thống kê hay thí nghiệm lặp lại
  • Chỉ tạo ra hiệu quả tiết kiệm ròng khi lượng đầu ra lớn

  • Ví dụ tiết kiệm ở quy mô lớn

    Mức sử dụng Token tiết kiệm mỗi ngày Số tiền tiết kiệm mỗi tháng (theo Sonnet)
    100 lần/ngày khoảng 9,600 khoảng $0.86
    1,000 lần/ngày khoảng 96,000 khoảng $8.64
    3 dự án khoảng 288,000 khoảng $25.92

Ví dụ so sánh trước và sau

  • Phản hồi code review mặc định (120 từ)

    • Bao gồm lời khen, giải thích và đề xuất dài dòng

  • Sau khi áp dụng CLAUDE.md (30 từ)

    • Theo dạng "Bug: <= causes an off-by-one error...", chỉ truyền đạt phần cốt lõi, giảm 75% token

Các hạng mục được chỉnh sửa

Số Vấn đề Cách chỉnh sửa
1 Mở đầu mang tính tâng bốc Cấm - bắt đầu trả lời ngay từ dòng đầu
2 Kết thúc rỗng nghĩa Cấm - loại bỏ "I hope this helps!"
3 Diễn đạt lại câu hỏi Cấm - thực hiện ngay
4 em dash, dấu ngoặc kép thông minh, Unicode Bắt buộc đầu ra chỉ dùng ASCII
5 Cụm từ "As an AI..." Cấm
6 Tuyên bố miễn trừ trách nhiệm không cần thiết Chỉ cho phép khi có rủi ro an toàn thực sự
7 Đề xuất ngoài yêu cầu Cấm - chỉ làm trong phạm vi yêu cầu
8 Trừu tượng hóa mã quá mức Chỉ cho phép mã chạy được đơn giản nhất
9 Ảo giác về sự thật không chắc chắn Ghi rõ "không biết", cấm suy đoán
10 Bỏ qua chỉnh sửa của người dùng Nội dung chỉnh sửa được cố định thành sự thật theo phiên
11 Đọc lại tệp trùng lặp Cấm đọc lại cùng một tệp
12 Mở rộng phạm vi Cấm sửa mã ngoài yêu cầu

Mẹo từ cộng đồng

  • Viết quy tắc bám theo các mẫu thất bại thực tế là hiệu quả nhất
    • Ví dụ: nếu Claude bỏ qua lỗi pipeline -> thêm quy tắc "dừng ngay khi một bước thất bại và báo toàn bộ lỗi cùng traceback"

  • Tệp CLAUDE.md có thể được hợp nhất theo cấu trúc phân cấp

    • Toàn cục (~/.claude/CLAUDE.md): quy tắc chung (giọng điệu, ASCII, v.v.)
    • Thư mục gốc dự án: ràng buộc theo dự án (ví dụ: cấm sửa /config)
    • Thư mục con: quy tắc chi tiết theo công việc
    • Nhờ đó có thể quản lý quy tắc phân tán và tránh tệp phình to

Cấu hình hồ sơ

  • Có thể chọn mức độ nén khác nhau theo loại dự án
    Hồ sơ Đối tượng phù hợp
    CLAUDE.md Dùng chung
    profiles/CLAUDE.coding.md Phát triển, code review, gỡ lỗi
    profiles/CLAUDE.agents.md Tự động hóa, hệ thống đa tác tử
    profiles/CLAUDE.analysis.md Phân tích dữ liệu, nghiên cứu, báo cáo

Cách sử dụng

Quy tắc ghi đè

  • Lệnh của người dùng luôn được ưu tiên

    • Nếu người dùng nêu rõ như "hãy giải thích chi tiết", Claude sẽ làm theo đúng như vậy
    • CLAUDE.md không kìm hãm ý định của người dùng

Cách đóng góp

  • Nếu phát hiện hành vi có thể chỉnh sửa, hãy tạo Issue
    1. Hành vi mặc định gây vấn đề
    2. Prompt đã kích hoạt hành vi đó
    3. Quy tắc chỉnh sửa được đề xuất
  • Các đề xuất từ cộng đồng sẽ được phản ánh vào phiên bản tiếp theo và người đóng góp sẽ được ghi nhận công trạng

Kiểm chứng và tham khảo

  • Có thể xem toàn bộ kết quả benchmark trong BENCHMARK.md
  • Dự án được xây dựng dựa trên các trường hợp phàn nàn thực tế trong cộng đồng Claude
  • Bao gồm nhiều nguồn tham khảo liên quan (GitHub Issues, The Register, DEV Community, Medium, Anthropic Docs, v.v.)

Giấy phép

  • Giấy phép MIT, cho phép sử dụng, sửa đổi và phân phối tự do

Bài viết liên quan

1 bình luận

 
GN⁺ 21 ngày trước
Ý kiến trên Hacker News

  • Benchmark ở đây bị thiên lệch về các tác vụ giải thích đơn lẻ, và theo tôi không phù hợp với vòng lặp agent như sinh mã
    Tôi tự hỏi khi dự án đang chạy, các phần giải thích dài dòng của Claude có thực sự giúp duy trì tính nhất quán và sự tập trung của phiên làm việc hay không
    Quy tắc “đừng lặp lại ngữ cảnh trùng lặp” thì hay, nhưng tôi lại nghĩ dùng nhiều token suy luận theo định hướng mục tiêu hơn mới có ích
    Vẫn còn thiếu dữ liệu để biết cách tiếp cận này có hiệu quả trong coding kiểu agent ngoài thực tế hay không

    • Tôi đã tạo một skill tên là /handoff để tự động sinh báo cáo Markdown trước khi phiên chạm tới giới hạn nén
      Tệp này vừa là bản ghi lâu dài của phiên, vừa đóng vai trò như “báo cáo hằng ngày”, nên rất tiện để tra cứu lại hoặc chia sẻ với quản lý
      Để duy trì tính nhất quán dài hạn, tôi nghĩ kiểu tài liệu hóa dạng tóm tắt như thế này tốt hơn
      Cách cài đặt tôi đã đăng ở đây
    • Nhờ quy tắc “đừng giải thích sẽ làm gì, cứ làm đi” mà tôi có thể nhận ra ngay khi Claude đi sai hướng và sửa lại prompt
    • Tôi không hiểu vì sao mọi người không đưa các quy tắc chặn ngôn ngữ không cần thiết vào CLAUDE.md
      Theo các nghiên cứu gần đây, đường suy luận dư thừa (self-consistency) và ensemble mô hình giúp cải thiện hiệu năng
    • Scaling theo thời gian suy luận cũng quan trọng. Dùng nhiều token hơn khi tìm câu trả lời lại giúp nâng chất lượng
      Nếu quá ám ảnh với độ dài tối thiểu thì sẽ lệch khỏi mục tiêu huấn luyện RL
    • Tôi đã chạy thử coding test với nhiều cấu hình, và cách tiếp cận này nhìn chung cho hiệu năng thấp hơn trong 30 lần chạy
      Mã kiểm thử ở đây

  • Planning mode của Claude Code hoạt động không ổn nên tôi khá hoài nghi với cách làm dựa trên file .md
    Theo tôi, planning mode đơn giản chỉ nên là một tính năng tắt quyền ghi file

  • Quy tắc “câu trả lời luôn ở dòng đầu tiên, phần suy luận ở sau” là kiểu làm bỏ qua đặc tính tự hồi quy của LLM
    Nếu chốt đáp án trước thì phần suy luận phía sau rất dễ rơi vào thiên kiến xác nhận

    • Ý tưởng của cách này thì hay nhưng cách triển khai có vẻ sai
      Nén suy luận theo kiểu bài báo Compressed Chain of Thought (CCoT) sẽ hiệu quả hơn
      Chất lượng có giảm nhẹ nhưng bù lại có lợi về tốc độ và chi phí (liên kết bài báo)
    • Trong các phiên quan trọng, tôi thêm prompt kiểm tra lần hai như “sanity check” để rà lại kế hoạch ban đầu
    • Reasoning LLM có thể nội bộ sinh ra hàng nghìn token suy luận trước khi viết câu trả lời
      Nói cách khác, quy tắc “trả lời trước” chỉ đổi thứ tự đầu ra chứ không đổi thứ tự suy luận thực sự
    • Claude Code không có tùy chọn “no thinking”, và mặc định ít nhất cũng là chế độ low thinking

  • Benchmark này vô nghĩa vì chỉ so số lượng token đầu ra mà không xét độ chính xác
    Chỉ cần prompt kiểu “luôn trả lời bằng một từ” là cũng dễ nâng điểm rồi
    Những quy tắc như “nếu người dùng chỉ ra lỗi thực tế thì cứ chấp nhận ngay” là rất nguy hiểm

    • Người ta bảo “prompt engineering quay trở lại à?”, nhưng 1–2 năm gần đây meta prompt hầu như không đem lại cải thiện đáng kể
    • Những quy tắc kiểu “đừng mắc lỗi” là không thực tế

  • Tôi nghĩ các kiểu giải pháp vạn năng như thế này sẽ nhanh chóng mất sức hút hoặc bị tích hợp vào CC
    Việc đổi workflow liên tục thật sự quá mệt
    Cấu hình Claude Code mặc định hiện giờ vẫn là ổn định nhất

    • Tôi cũng nghĩ tương tự. Giữ thiết lập vanilla có vẻ tốt hơn về dài hạn
      Tôi thích Skills nhưng hầu như không dùng MCP hay worktree
    • Anthropic vốn đã tối ưu bằng dogfooding nội bộ, nên khả năng cao cấu hình mặc định là hiệu quả nhất
      Chỉ cần xem CLAUDE.md như một bản ghi chú nháp gửi cho một đồng nghiệp thông minh là nó đã hoạt động khá ổn
    • Tôi đồng ý với ý “rồi cuối cùng sẽ được tích hợp vào CC”
      Nếu Anthropic chưa tự thêm tính năng đó, có lẽ là vì mức cải thiện hiệu năng chưa được chứng minh
    • Những “lớp cải tiến Claude” kiểu này rốt cuộc chỉ dẫn đến sự bất ổn trong workflow
      Dù có hữu ích trong chốc lát thì rồi cũng sẽ sớm bị hấp thụ vào tính năng mặc định hoặc biến mất
    • Ngay trong Claude cũng liên tục có các cập nhật về tối ưu hóa md
      Vì thế dù có dùng các script thử nghiệm kiểu này thì chỉ cần cập nhật file md thường xuyên là vẫn giữ được trạng thái mới nhất

  • Với câu hỏi “nếu file được nạp vào context ở mỗi tin nhắn thì chẳng phải là lãng phí token sao?”,
    tôi nghĩ tính năng personalization của Claude đã đảm nhiệm vai trò đó rồi
    Theo tôi, sự ngắn gọn chỉ có ý nghĩa khi nó nâng chất lượng
    Các công cụ liên quan tôi thấy trên Reddit cũng khá thú vị:
    Headroom nén context 34%,
    RTK nén đầu ra CLI từ 60–90%,
    MemStack cung cấp bộ nhớ liên tục để tránh đọc lại file không cần thiết

  • Tôi cảm thấy những nỗ lực kiểu này thực ra là kết quả của việc hiểu sai nguyên lý cơ bản của LLM
    “Trả lời trước, suy luận sau” là bỏ qua cấu trúc tự hồi quy của transformer
    Huấn luyện RL vốn đã điều chỉnh độ dài và chất lượng tối ưu rồi, nên chỉnh sửa quá mức có thể dẫn tới giảm hiệu năng

    • Nếu ép độ dài phản hồi xuống thì chất lượng suy luận và độ nhất quán sẽ giảm, còn xác suất ảo giác thì tăng lên
      Mô hình được huấn luyện để thực hiện suy luận nhiều bước dựa trên tiếng Anh
    • Quy tắc “trả lời trước” thực tế không thay đổi thứ tự suy luận. Nó đã nghĩ xong bên trong rồi mới xuất câu trả lời
    • Có lẽ tác giả không phải là không hiểu transformer, mà chỉ đang thử một mẹo để giảm chi phí token
      Đây là một cách tiếp cận mang tính thử nghiệm, ưu tiên hiệu quả hơn chất lượng
    • Phần lớn API đã có tùy chọn kiểm soát độ dài COT. Theo tôi nên tận dụng thiết lập API thay vì dùng mấy mẹo vòng vo kiểu này
    • Cuối cùng tôi vẫn thấy công cụ do Anthropic làm là đáng tin nhất.
      Vì thế tôi chỉ dùng công cụ first-party thay vì bên thứ ba như OpenCode

  • Như trong video của Karpathy, có vẻ mô hình dùng càng nhiều token thì độ chính xác càng cao
    Cách tiếp cận này ngược lại còn có thể làm mô hình tệ đi

    • Tuy vậy, nếu mục tiêu ở đây là giảm đầu ra giá trị thấp (ví dụ: câu nịnh nọt, nhiễu định dạng) thì cũng có thể chấp nhận được
      Nhưng nếu bắt nó đưa đáp án ngay mà không suy luận thì sẽ có nguy cơ thiên kiến chốt sớm
    • Đầu ra lặp lại đóng vai trò củng cố định hướng, nên nếu loại bỏ đi thì độ mơ hồ có thể tăng lên

  • Tôi không hiểu vì sao những dự án vô nghĩa kiểu này lại thành xu hướng trên HN
    Các công cụ thực sự giúp giảm mức dùng token là claude-mem và lumen

    • Lý do rất đơn giản. Thuật toán xu hướng của HN được tối ưu cho mức độ tương tác hơn là độ chính xác

  • Trước đây người ta nghiên cứu hash, mã hóa và thuật toán nén mới
    Còn giờ thì lại nghiên cứu cách bảo AI im lặng bớt đi, thật đúng là mỉa mai