Đối tượng mục tiêu: Các nhà phát triển đang sử dụng các công cụ lập trình AI (như Cursor, Windsurf, trae...) và các nhà quản lý kỹ thuật thiếu nhận thức về chi phí AI.

Quan điểm cốt lõi: Token không chỉ là một đơn vị thanh toán đơn giản, mà còn là một "tài nguyên chú ý" và "tiền tệ tính toán". Lạm dụng chế độ Agent, bỏ qua quản lý ngữ cảnh, thực chất là sử dụng sự siêng năng về mặt chiến thuật (để AI làm bừa) để che đậy sự lười biếng về mặt chiến lược (bản thân không suy nghĩ).

"Chi phí AI" của bạn có thể cao hơn cả tiền lương

Hôm trước, tôi kiểm tra hóa đơn Token của mình. Khi nhìn thấy con số đó, tôi hơi ngạc nhiên: 10 triệu Token. Lưu ý, đây không phải là mức sử dụng trong một tháng, mà là một ngày.

Tôi nghĩ rằng điều này thật vô lý. Sau đó, tôi đã đăng một video ngắn liên quan đến tính toán Token.

Kết quả là, khu vực bình luận cho tôi thấy thế nào là "núi cao còn có núi cao hơn".

Hình ảnh dưới đây là ảnh chụp màn hình ghi lại mức tiêu thụ hai trăm triệu Token mỗi ngày của người dùng mạng "Lão K's Daily Life":

Ban đầu, tôi nghĩ rằng đây có thể là một trường hợp cá biệt, nhưng khi nhiều người dùng mạng bình luận rằng họ tiêu thụ 100 triệu mỗi ngày, tôi hiểu rằng đây là một hiện tượng rất phổ biến.

Một trăm triệu Token là gì? Nếu tính theo mức thanh toán phổ biến của "một số mô hình thương mại chính thống" (tính phí riêng cho đầu vào/đầu ra, ước tính sơ bộ khoảng 10 đô la Mỹ / triệu Token), thì một ngày sẽ đốt 1000 đô la. Một ngày đốt 7000 tệ. Tiền lương một tháng của nhiều lập trình viên mới vào nghề có thể không đủ để AI "suy nghĩ" trong một ngày.

(Lưu ý: Sự khác biệt về giá giữa các mô hình/nhà cung cấp là rất lớn, và đơn giá đầu vào và đầu ra cũng thường khác nhau. Mục đích ở đây không phải là tính toán chính xác đến chữ số thập phân thứ hai, mà là thiết lập "cảm giác về quy mô" trước.)

Nếu bạn muốn tự tính lại, thì đây là công thức chung (bỏ qua các quy tắc đặc biệt như bộ nhớ cache/chiết khấu): Chi phí ≈ (Số lượng Token đầu vào / 1.000.000) × Đơn giá_in + (Số lượng Token đầu ra / 1.000.000) × Đơn giá_out

Điều này quá trái ngược với trực giác. Chúng ta luôn nghĩ rằng AI rẻ, OpenAI thậm chí còn giảm giá. Nhưng tại sao trong kỹ thuật thực tế, mức tiêu thụ Token lại bùng nổ theo cấp số nhân?

Hôm nay, tôi sẽ cùng mọi người phân tích sâu sắc logic đằng sau "hố đen Token" này và cách chúng ta nên ngăn chặn tổn thất.

1. Tại sao Token lại "bùng nổ theo cấp số nhân"?

Nhiều anh em hoàn toàn không có khái niệm về quy mô của Token. Họ nghĩ: "Ôi, chỉ là gửi vài đoạn mã thôi mà? Có bao nhiêu đâu?"

1. Tính toán rõ ràng

Chúng ta hãy thiết lập một nhận thức định lượng đủ dùng trong kỹ thuật. Nói thẳng ra: Token không phải là số lượng chữ, cũng không phải là số lượng ký tự. Nó là "đoạn mã hóa" sau khi mô hình chia nhỏ văn bản, các mô hình khác nhau sử dụng tokenizer khác nhau, vì vậy chỉ có thể đưa ra khoảng chứ không thể đưa ra một hằng số "áp dụng được ở mọi nơi".

Bạn chỉ cần coi những con số này là "thước đo ước tính" (mục đích là để đánh giá quy mô, ước tính chi phí, đưa ra quyết định ngăn chặn tổn thất):

• 1 ký tự Hán ngữ: Thường là 1–2 Token (các ký tự tần số cao gần 1 hơn, các ký tự/tổ hợp hiếm gặp dễ đạt 2–3 hơn)

• 1 từ tiếng Anh: Thường là khoảng 1.2–1.5 Token (ước tính sơ bộ có thể dùng 1.3)

• 1 dòng mã ≈ 10–50 Token (bao gồm thụt lề, chú thích, khai báo kiểu)

• Logic nghiệp vụ đơn giản ≈ 12–20 Token

• Có chú thích kiểu, interface, JSDoc, thụt lề 4 dấu cách ≈ 20–35 Token

• Có nhiều import / decorator / chú thích ≈ 30–50+ Token

• 1 tệp nguồn (400–600 dòng, dự án TS/Java hiện đại) ≈ 4.000–24.000 Token rất phổ biến (trung vị ≈ 12.000–18.000)

• 1 dự án cỡ vừa (100–200 tệp nguồn, chỉ tính src/, không bao gồm node_modules/ / mã được tạo)

• "Đọc lướt qua" mã nguồn cốt lõi thường bắt đầu từ hàng triệu Token

• Nếu bạn nhét cả thử nghiệm, cấu hình, tập lệnh, khai báo phụ thuộc, nhật ký vào, thì hàng chục triệu Token cũng không có gì lạ

Các dự án frontend hiện tại đều là TypeScript, chứa đầy các định nghĩa Interface phức tạp; hoặc là Java, cứ động đến là hàng chục dòng Import. Những "mã soạn sẵn" này thực chất là những kẻ giết Token. Một dự án cỡ vừa, nếu có 100 tệp, chỉ cần để AI "đọc mã một lần", rất có thể sẽ tiêu diệt trực tiếp 1 triệu Token.

2. Hiệu ứng "lăn cầu tuyết" của token

Mức tiêu thụ Token đáng sợ nhất không phải là một cuộc trò chuyện duy nhất, mà là sự tích lũy ngữ cảnh trong nhiều vòng trò chuyện.

Cơ chế của LLM là không trạng thái. Để AI nhớ những gì bạn đã nói ở câu trước, hệ thống thường sẽ đóng gói "lời nhắc hệ thống + lịch sử trò chuyện + đoạn tệp/mã bạn tham khảo + đầu ra gọi công cụ (ví dụ: kết quả tìm kiếm, nhật ký lỗi)" và gửi cho mô hình. Bạn nghĩ rằng bạn chỉ hỏi một câu, nhưng thực chất bạn đang trả tiền lặp đi lặp lại cho "toàn bộ gói ngữ cảnh".

• Vòng 1: Gửi 10.000 Token, AI trả lời 1.000.

• Vòng 2: Gửi (10.000 + 1.000 + câu hỏi mới), AI trả lời...

• Vòng 10: Ngữ cảnh của bạn có thể đã phình to lên 200.000 Token.

Lúc này, ngay cả khi bạn chỉ hỏi một câu "giúp tôi đổi tên biến", bạn cũng đang tiêu tốn chi phí của 200.000 Token. Đây là lý do tại sao bạn cảm thấy mình không làm gì cả, nhưng hóa đơn lại tăng vọt.

Điều tồi tệ hơn là: Chế độ Agent sẽ "chủ động đọc tệp". Bạn nói một câu "giúp tôi tối ưu hóa mô-đun người dùng", nó có thể quét các thư mục liên quan trước, sau đó truy đến các phụ thuộc, sau đó truy đến cấu hình, sau đó truy đến thử nghiệm... Nó không phải là lười biếng, nó đang "tận tâm theo chiến lược mặc định", và chiến lược mặc định thường là: đọc nhiều, thử nhiều, lặp lại nhiều.

2. Hai loại "lười biếng" đang phá hủy khả năng kỹ thuật của bạn

Sau khi xem xét lại những "người anh em trăm triệu" trong khu vực bình luận, tôi thấy rằng nguồn gốc của việc Token tăng vọt không chỉ là vấn đề về cơ chế tiêu thụ của AI, mà còn liên quan mật thiết đến sự lười biếng của con người.

Dưới đây là hai loại "lười biếng tư duy" điển hình.

Lười biếng một: Kiểu người quản lý khoán trắng

Bạn có tâm lý này không?

• "Dự án cũ này quá lộn xộn, tôi lười xem logic, cứ ném cho AI đi."

• "Cursor ra mắt chế độ Agent, tuyệt vời quá, cứ để nó tự sửa lỗi đi."

Vì vậy, bạn ném toàn bộ thư mục src cho Agent, đưa ra một chỉ thị mơ hồ: "Giúp tôi tối ưu hóa mô-đun người dùng." Agent bắt đầu làm việc:

• Nó đọc 50 tệp (tiêu thụ 500.000).

• Nó phát hiện ra rằng nó tham chiếu đến utils, và lại đi đọc các lớp công cụ (tiêu thụ 200.000).

• Nó cố gắng sửa đổi, báo lỗi, đọc nhật ký lỗi (tiêu thụ 100.000).

• Nó cố gắng sửa chữa, lại báo lỗi...

Nó đang thử và sai một cách điên cuồng, tiêu thụ Token một cách điên cuồng. Còn bạn thì sao? Bạn đang lướt điện thoại, cảm thấy hiệu quả của mình thật cao. Sự thật là: Bạn đã dùng tiền để đổi lấy "hiệu quả giả tạo", tạo ra một đống mã mà bạn không thể bảo trì sau này.

Nói một cách chuyên nghiệp hơn, có hai lớp tổn thất ở đây:

• Lớp chi phí: Token đầu vào lớn hơn, số lần lặp lại nhiều hơn, chi phí cộng dồn tuyến tính

• Lớp kỹ thuật: Bạn mất ngữ cảnh và quyền quyết định, cuối cùng chỉ còn lại một hệ thống không thể kiểm soát với "chỉ cần chạy được là được"

Lười biếng hai: Kiểu người trộn lẫn bùn và cát

Khi gặp lỗi, bạn ném cho AI như thế nào? Có phải bạn trực tiếp Ctrl+A sao chép toàn bộ bảng điều khiển lỗi, hoặc trực tiếp @Codebase để AI tự tìm?

Đây gọi là "trộn lẫn bùn và cát". Bạn lười xác định vị trí cốt lõi của vấn đề, lười sàng lọc các đoạn mã quan trọng. Bạn nhét 99% thông tin không hợp lệ (nhiễu) và 1% thông tin hợp lệ (tín hiệu) vào AI.

AI giống như một bộ khuếch đại.

• Bạn cung cấp cho nó logic rõ ràng (tín hiệu), nó khuếch đại trí tuệ của bạn, sử dụng ít Token, hiệu quả tốt.

• Bạn cung cấp cho nó sự hỗn loạn và mơ hồ, nó khuếch đại sự hỗn loạn của bạn, Token tăng vọt, tạo ra rác.

3. Giải pháp: Làm thế nào để sử dụng AI hiệu quả, giảm tiêu thụ Token

Để giữ được ví tiền của bạn, điều quan trọng hơn là giữ được quyền kiểm soát kỹ thuật của bạn, chúng ta phải thay đổi mô hình hợp tác với AI.

1. Nguyên tắc ngữ cảnh tối thiểu

Đây là nguyên tắc đầu tiên của lập trình AI. Luôn chỉ cung cấp cho AI tập hợp mã tối thiểu tương ứng với vấn đề hiện tại.

Trong Cursor, hãy sử dụng tốt các toán tử này:

• @File: Chỉ tham khảo các tệp liên quan, không phải toàn bộ thư mục.

• Ctrl+L Chọn mã: Chỉ gửi 50 dòng mã mà con trỏ đã chọn cho Chat, không phải toàn bộ tệp.

• @Docs: Đối với các thư viện của bên thứ ba, hãy tham khảo tài liệu thay vì để nó đoán.

Đây là SOP có cấu trúc, có thể tái sử dụng mà tôi thường sử dụng (bạn cứ làm theo, Token sẽ giảm rõ rệt):

Đoạn này có nghĩa là: Khi hợp tác với AI, bạn cần chú ý đến hiệu quả và độ chính xác. Các bước cụ thể như sau:

• Xác định rõ mục tiêu: Nói ngắn gọn và súc tích cho AI biết vấn đề hiện tại và kết quả mong muốn, đừng để nó tự đoán.

• Đơn giản hóa việc tái hiện vấn đề: Nếu có thể sử dụng phương pháp đơn giản nhất để tái hiện vấn đề thì không cần sử dụng phương pháp phức tạp, dán mã ít nhất và quan trọng nhất, không cần chồng chất một đống nội dung không liên quan.

• Cung cấp thông tin cần thiết tối thiểu: Chỉ cần cung cấp 1-3 tệp liên quan, các hàm quan trọng và vài dòng đầu tiên của ngăn xếp lỗi, không cần thông tin đầy đủ.

• Yêu cầu trả lại các điểm sửa đổi: Yêu cầu AI chỉ cho bạn biết những gì cần thay đổi, tại sao cần thay đổi, không cần nó viết lại toàn bộ một cách dài dòng.

• Cuối cùng, bạn tự mình kiểm tra: Thực hiện xác minh đơn giản nhất để đảm bảo rằng các thay đổi không ảnh hưởng đến các khu vực khác.

Nói tóm lại, hãy sử dụng thông tin ít nhất và quan trọng nhất để AI làm việc và giữ lại quyền kiểm soát và phán đoán cuối cùng.

2. Cũng là điều quan trọng nhất: Suy nghĩ trước, Prompt sau, Lập kế hoạch trước, Hành động sau

Trước khi nhấn Enter, hãy ép bản thân dừng lại 10 giây, tự hỏi mình ba câu hỏi:

• Tôi đang giải quyết vấn đề gì? (Xác định ranh giới)

• Vấn đề này liên quan đến những mô-đun cốt lõi nào? (Lọc ngữ cảnh)

• Nếu tự tôi viết, tôi sẽ viết như thế nào? (Cung cấp ý tưởng)

Bạn là 1, AI là 0 ở phía sau. Nếu 1 không đứng vững, thì có bao nhiêu số 0 ở phía sau cũng chỉ là sự tiêu thụ vô nghĩa.

Vài lời từ tận đáy lòng

Câu chuyện về "một ngày một trăm triệu Token" có thể không xảy ra với mọi người. Nhưng hành vi lãng phí Token, hầu như mọi lập trình viên sử dụng lập trình AI đều đã trải qua.

Mặc dù AI giúp lập trình trở nên dễ dàng hơn, nhưng vẫn có những rào cản. Những người thực sự biết cách sử dụng nó mới có thể thêm cánh cho hổ.

Trước đây, mã xấu mà bạn viết chỉ "làm ghê tởm" đồng nghiệp. Bây giờ, sự lười biếng của bạn sẽ trực tiếp biến thành những con số trên hóa đơn, trừng phạt bạn bằng chi phí tăng vọt.Vậy nên, đừng làm "người quản lý hờ". Hãy trở thành một kiến trúc sư AI suy nghĩ sâu sắc, diễn đạt chính xác, lên kế hoạch trước khi hành động. Đó cũng là khả năng không thể thay thế lớn nhất của chúng ta trong thời đại này.