Trong kỷ nguyên lập trình hiện đại, các công cụ AI như Claude Code đã trở thành trợ thủ đắc lực, tăng tốc quá trình phát triển và giải quyết vấn đề. Tuy nhiên, một thực tế mà nhiều nhà phát triển thường bỏ qua là chi phí token và hiệu quả sử dụng. Việc phụ thuộc quá mức vào các phiên làm việc kéo dài, prompt mơ hồ có thể âm thầm đốt cháy ngân sách của bạn trong khi chất lượng đầu ra không đạt mức tối ưu. Bài viết này sẽ chia sẻ những chiến lược đã được chứng minh để cắt giảm tới 60% lượng token sử dụng cho Claude Code, đồng thời mang lại kết quả chất lượng cao hơn đáng kể.
Mục lục
Cửa Sổ Ngữ Cảnh Không Phải Là Sổ Ghi Chép Của Bạn
Một trong những sai lầm phổ biến nhất khi làm việc với Claude Code là coi cửa sổ ngữ cảnh (context window) như một không gian làm việc vĩnh viễn. Bạn bắt đầu phiên làm việc vào buổi sáng, xử lý một lỗi, nghỉ giải lao và tiếp tục. Đến chiều, cửa sổ ngữ cảnh đã chất đầy những thông tin không cần thiết: các lần thử thất bại, cách tiếp cận thử nghiệm, lỗi Docker đã được giải quyết từ nhiều giờ trước. Mô hình AI vẫn “ghi nhớ” tất cả những điều này, liên tục định hướng theo chúng, và bạn phải trả tiền cho mỗi token trong đó.
Giải pháp: Đặt lại phiên làm việc một cách chủ động.
Thay vì để mô hình “quên” một cách tự nhiên (điều này có thể dẫn đến mất ngữ cảnh quan trọng), hãy chủ động thiết lập lại các phiên. Mục tiêu là tạo ra sự liên tục có chọn lọc. Trước mỗi phiên làm việc quan trọng, hãy cung cấp một bộ ngữ cảnh cốt lõi, ngắn gọn:
mục tiêu: triển khai logic làm mới JWT
các tệp liên quan: src/auth/session.ts, src/middleware/verify.ts
ràng buộc: không sử dụng thư viện mới, giữ nguyên xử lý lỗi hiện có
những gì đã thất bại: đã thử lưu refresh tokens trong bộ nhớ — không tồn tại sau khi khởi động lại
đầu ra mong đợi: endpoint làm mới hoạt động với kiểm thử đầy đủ
Đây là toàn bộ thông tin ban đầu. Không có gì khác được thêm vào cho đến khi thực sự cần thiết. Cách tiếp cận này giúp đầu ra sắc nét hơn ngay lập tức, vì mô hình tập trung vào vấn đề hiện tại thay vì suy đoán dựa trên ngữ cảnh đã cũ. Ngữ cảnh càng sạch, phản hồi càng chính xác.
Prompt Mơ Hồ Là Tác Nhân Nhân Đôi Chi Phí Token
Thói quen tốn kém thứ hai là sử dụng các prompt dạng câu hỏi chung chung, thiếu cụ thể:
- “Bạn nghĩ sao về cách tiếp cận này?”
- “Có gợi ý nào ở đây không?”
- “Bạn sẽ xử lý việc này như thế nào?”
Những câu hỏi này có vẻ tự nhiên trong giao tiếp, nhưng đối với mô hình AI, chúng là lời mời tạo ra một không gian đầy rẫy các khả năng. Mô hình sẽ tạo ra các tùy chọn, đánh đổi, triết lý, giải pháp thay thế, cân nhắc liên quan và vô số thứ mà bạn có thể không bao giờ sử dụng. Tất cả đều được tính phí theo token.
Giải pháp: Coi prompt như hướng dẫn vận hành thiết bị công nghiệp.
Hãy biến prompt thành các chỉ dẫn cụ thể với động từ, phạm vi và ràng buộc rõ ràng. Thay vì:
"bạn nghĩ gì về luồng xác thực?"
Hãy sử dụng:
"Xác định vấn đề bảo mật trong logic xác thực token. Trả về dòng code dễ bị tấn công và giải thích lý do nó có thể bị khai thác. Dưới 150 từ."
Mô hình phản hồi tốt với các ràng buộc về phạm vi. Hãy cho nó biết kích thước đầu ra mong muốn, định dạng đầu ra và chính xác phần nào của vấn đề bạn đang gặp phải. Sự mơ hồ không phải là một điều tốt bụng đối với mô hình; đó là lời mời để nó “nói chuyện” cho đến khi tìm thấy điều gì đó bạn phản hồi.
Phân Tách Chế Độ Làm Việc Là Bắt Buộc
Một loại phiên làm việc đặc biệt tốn nhiều token nhất trên mỗi giờ làm việc hữu ích là các phiên làm việc kết hợp nhiều chế độ. Ví dụ:
- Lập kế hoạch trong khi đang triển khai.
- Gỡ lỗi đồng thời với việc thiết kế lại.
- Hỏi “nhân tiện, chúng ta có nên xem xét lại toàn bộ cấu trúc không?” trong một việc đáng lẽ chỉ mất mười lăm phút để sửa.
Mô hình phải ghi nhớ tất cả những điều này. Mỗi hướng kiến trúc mới bạn đưa ra đều trở thành một phần của ngữ cảnh làm việc mà nó phải dựa vào để suy luận. Bạn có thể cảm thấy phiên làm việc trở nên nặng nề hơn khi nó tích lũy các quyết định chưa được giải quyết.
Giải pháp: Xử lý các chế độ làm việc như các khu vực vật lý trong một xưởng.
Các phiên lập kế hoạch nên là một hoạt động riêng biệt, tạo ra một tài liệu có cấu trúc. Tài liệu này sau đó sẽ được sử dụng để bắt đầu các phiên triển khai… nhưng chỉ chọn lọc các phần liên quan. Các phiên gỡ lỗi nên bắt đầu với một định dạng sự cố có cấu trúc:
mong đợi: webhook xử lý dưới 500ms
thực tế: hết thời gian sau 30s với payload trên 10KB
cách tái hiện: bất kỳ yêu cầu nào với body > 10KB đến /api/webhooks
thay đổi gần đây: đã thêm xác thực payload trong middleware, PR #47
logs: [dán các dòng liên quan duy nhất]
phạm vi nghi ngờ: có thể là bước mã hóa base64 trong validatePayload()
Không có lời kể, không có cuộc trò chuyện. Chỉ có bề mặt sạch sẽ, tập trung vào vấn đề.
Prompt Phủ Định Thực Sự Hiệu Quả
Những người tạo ảnh AI thường biết điều này một cách bản năng, nhưng ít ai áp dụng nó cho các tác nhân lập trình, mặc dù nó cũng hiệu quả không kém.
Giải pháp: Thêm các hướng dẫn loại trừ rõ ràng vào hầu hết các prompt quan trọng.
Ví dụ:
không thiết kế lại kiến trúc
không giải thích những điều cơ bản
không thêm dependencies mới
không động đến code bên ngoài hàm tôi đã chỉ định
không viết lại các kiểm thử đang hoạt động
Nếu không có ràng buộc, mô hình sẽ mặc định hướng tới sự “giúp đỡ tối đa”. Nó sẽ diễn giải yêu cầu của bạn một cách rộng rãi và phóng khoáng. Một sửa lỗi nhỏ có thể trở thành một refactor. Một thay đổi có mục tiêu có thể biến thành một đề xuất cải thiện hệ thống. Phản hồi không sai, nhưng nó lớn hơn mức bạn cần và chạm vào những thứ bạn không yêu cầu. Việc giới hạn phạm vi bằng các ràng buộc phủ định sẽ giảm kích thước đầu ra và loại bỏ thiệt hại phụ.
Ngừng Dán Toàn Bộ Tệp
Đây là một điều khó chấp nhận vì nhiều người đã làm nó liên tục trong vài tháng đầu tiên. Khi bạn dán toàn bộ một tệp lớn làm ngữ cảnh, mô hình sẽ định hướng theo toàn bộ tệp, ngay cả khi vấn đề chỉ nằm trong hai mươi dòng. Nó sẽ tốn token để mô tả các phần bạn đã có thể đọc, tạo ra các giải thích cho mã không cần giải thích. Bạn đang phải trả tiền cho công việc định hướng đó trên mỗi prompt.
Giải pháp: Phân lập thông tin một cách tàn nhẫn.
Hãy chỉ cung cấp những gì thực sự liên quan:
- Hàm liên quan.
- Giao diện liên quan.
- Thông báo lỗi và năm dòng xung quanh nơi nó xảy ra.
Không có gì khác trừ khi vấn đề thực sự yêu cầu ngữ cảnh lớn hơn, và hầu hết các vấn đề không cần. Việc này tạo ra cảm giác cơ học, như việc thiết lập một cỗ máy để làm một công việc cụ thể thay vì yêu cầu nó ứng biến trên toàn bộ sàn nhà xưởng.
Ngân Sách Trả Lời Là Có Thật
Điều này nghe có vẻ cầu kỳ cho đến khi bạn thấy điều gì xảy ra khi bạn thực thi chúng. Việc giới hạn đầu ra không chỉ tiết kiệm token mà còn cải thiện chất lượng đáng kể.
Giải pháp: Áp đặt ngân sách cho câu trả lời.
- “Trả lời tối đa năm gạch đầu dòng.”
- “Sử dụng dưới 200 token.”
- “Chỉ một đoạn văn duy nhất.”
- “Chỉ trả về bản vá, không giải thích.”
Chất lượng thường được cải thiện không phải vì mô hình trở nên thông minh hơn dưới áp lực, mà vì ràng buộc buộc nó phải chọn lọc. Mô hình sẽ xác định thông tin quan trọng nhất thay vì tạo ra mọi thứ có vẻ hợp lý và để bạn tự lọc. Các kỹ sư viết nhận xét theo dõi lỗi tốt đã biết điều này: người viết ba câu và xác định chính xác vấn đề hữu ích hơn người viết bốn đoạn văn về hành vi quan sát được. Ràng buộc làm sắc nét giao tiếp ở cả con người và mô hình.
Các Đoạn Prompt Có Thể Tái Sử Dụng Không Phải Là Phức Tạp Không Cần Thiết
Ban đầu, việc hệ thống hóa các prompt có vẻ như là một công việc phụ không cần thiết. Nhưng thực tế, chi phí này đã tồn tại; bạn chỉ đang trả nó trong mỗi phiên bằng cách gõ lại các ràng buộc tương tự.
Giải pháp: Tạo các đoạn prompt có thể tái sử dụng.
Các hướng dẫn được lặp đi lặp lại liên tục bao gồm:
giữ nguyên tất cả các comment hiện có
chỉ diff tối thiểu — không chạm vào mã đang hoạt động
TypeScript strict mode, không có any
giải thích lý do của bạn trước khi viết code
không có dependencies mới
mobile-first cho mọi thay đổi UI
Hãy lưu trữ những đoạn này trong một tệp snippet. Mỗi phiên làm việc chỉ cần tải subset liên quan. Sự nhất quán của prompt làm giảm sự biến thiên của đầu ra. Những khác biệt nhỏ trong cách diễn đạt giữa các phiên có thể tạo ra các hành vi mô hình khác nhau đáng ngạc nhiên theo thời gian – đầu vào nhất quán tạo ra đầu ra nhất quán, có thể kiểm toán được.
Biết Khi Nào Không Nên Sử Dụng Claude
Đây là điều khó chấp nhận nhất nhưng cũng có giá trị nhất. Đôi khi, con đường nhanh nhất là tự mở tệp và sửa lỗi. Các công cụ AI tạo ra một sự méo mó khiến mọi tác vụ đều có vẻ như là một tác vụ AI.
Giải pháp: Đánh giá thực tế về giá trị của AI cho từng tác vụ.
Các sửa lỗi cục bộ không mơ hồ, những vấn đề bạn đã hiểu hoàn toàn, những thay đổi mà chi phí xác minh cao hơn việc thực hiện trực tiếp – những điều này thường tốn kém hơn trong việc tạo prompt và xem xét so với việc tự hành động trực tiếp. Có một mô hình đang nổi lên trong các không gian làm việc chung và máy chủ Discord nơi mọi người dành nhiều năng lượng nhận thức để điều phối AI hơn là giải quyết vấn đề. Việc chờ đợi câu trả lời xuất hiện thay vì đã biết câu trả lời và tự viết nó là một sự lãng phí.
Không phải mọi vấn đề đều được giải quyết tốt hơn thông qua một trợ lý AI.
Biến Số Thực Sự Là Sự Chú Ý
Tất cả các kỹ thuật cụ thể ở trên đều bắt nguồn từ một thay đổi duy nhất: ngừng coi chi phí token là trừu tượng. Khi chi phí trở nên rõ ràng, sự lãng phí cũng rõ ràng. Bạn sẽ thấy các prompt khổng lồ. Việc tải ngữ cảnh lặp đi lặp lại. Các lần viết lại dự đoán trên mã đã ổn. Sự lạc đề trong cuộc trò chuyện đã đốt cháy hai giờ và không tạo ra bất cứ điều gì có thể hành động.
Những tối ưu hóa này cũng cải thiện tư duy. Việc nén thông tin buộc phải có sự rõ ràng. Kỹ thuật tốt là sự nén – trích xuất tín hiệu, loại bỏ nhiễu, đưa ra quyết định và ghi lại chúng thay vì tranh luận lại. Các hệ thống tích lũy ngữ cảnh không kiểm soát sẽ suy thoái, cho dù hệ thống đó là một codebase, một nhóm hay một cuộc trò chuyện.
Hầu hết mọi người vẫn đang trong giai đoạn “dư dả” với các công cụ lập trình AI: ngữ cảnh vô hạn, sự kiên nhẫn vô hạn, không nhận thức về ma sát. Điều đó sẽ thay đổi khi hóa đơn đến, hoặc khi đầu ra bắt đầu suy giảm vì không ai mô hình hóa chi phí của sự hỗn loạn. Các nhà phát triển thích nghi sớm nhất có xu hướng xây dựng các hệ thống bình tĩnh hơn. Các hệ thống bình tĩnh hơn dễ gỡ lỗi hơn, rẻ hơn để chạy và nhanh hơn để lặp lại. Đó không phải là một sự trùng hợp.
Bằng cách áp dụng những chiến lược này, bạn không chỉ tiết kiệm chi phí mà còn trở thành một nhà phát triển hiệu quả và có tư duy sắc bén hơn, biến Claude Code thực sự trở thành một công cụ nâng cao năng suất thay vì một lỗ hổng chi phí tiềm ẩn.
