
Chi tiêu cho lập trình AI được phân bổ như sau: 48% cho viết mã, 40% cho tư duy.
Điểm: 2 Bình luận: 0
Ngày 29/5/2026
**Chưa đến một nửa chi phí lập trình AI của tôi thực sự dành cho việc viết mã**
Phân tích dữ liệu thực tế về nơi tiền thực sự được chi tiêu – được đo lường, không ước tính.
Trong 30 ngày qua, tôi đã chi 7.890 USD cho 105.718 lượt gọi API lập trình AI. Tôi cho rằng phần lớn số tiền đó là để các mô hình viết mã. Nhưng không phải vậy. Chỉ 47,9% chi phí của tôi dành cho việc thực sự tạo ra mã. Phần còn lại dành cho việc khám phá cơ sở mã, gỡ lỗi, ủy quyền cho các tác nhân phụ và các cuộc trò chuyện qua lại đơn thuần.
Tôi biết điều này là do tôi đã xây dựng một công cụ để đo lường nó. CodeBurn là một công cụ dòng lệnh (CLI) đọc dữ liệu phiên lập trình AI của bạn trực tiếp từ đĩa và phân loại mọi lượt gọi API vào một trong 13 danh mục tác vụ. Không có khóa API, không có trình bao bọc, không có dữ liệu nào rời khỏi máy của bạn. Việc phân loại hoàn toàn mang tính xác định – dựa trên các mẫu sử dụng công cụ và nội dung tin nhắn, không phải mô hình ngôn ngữ lớn (LLM) – do đó các con số có thể tái tạo.
Đây là nơi tiền thực sự đã được chi tiêu:
| Danh mục tác vụ | Chi phí | % chi tiêu |
|---|---|---|
| Lập trình | 3.781 USD | 47,9% |
| Khám phá | 876 USD | 11,1% |
| Ủy quyền | 765 USD | 9,7% |
| Gỡ lỗi | 695 USD | 8,8% |
| Phát triển tính năng | 654 USD | 8,3% |
| Đối thoại | 462 USD | 5,9% |
| Động não | 294 USD | 3,7% |
| Kiểm thử | 168 USD | 2,1% |
| Tái cấu trúc | 132 USD | 1,7% |
| Thao tác Git | 34 USD | 0,4% |
| Xây dựng/Triển khai | 21 USD | 0,3% |
| Lập kế hoạch | 4 USD | <0,1% |
| Chung | 4 USD | <0,1% |
| **Tổng cộng** | **7.890 USD** | **100%** |
Lập trình là danh mục lớn nhất, nhưng vẫn chưa đến một nửa. Nếu bạn nhóm tất cả các hoạt động tạo ra mã – Lập trình, Phát triển tính năng, Tái cấu trúc và Kiểm thử – bạn sẽ có khoảng 60%. Điều đó có nghĩa là khoảng 40% chi phí của tôi là để mô hình suy nghĩ, không phải gõ: đọc tệp, suy luận về vấn đề, thảo luận về các phương pháp tiếp cận và tìm lỗi.
Đó không phải là lãng phí. Khám phá và gỡ lỗi là công việc thực sự. Nhưng nó định hình lại những gì tôi đang chi trả. Tôi không mua một trình tạo mã. Tôi đang mua một cộng tác viên dành phần lớn ngân sách của mình để hiểu vấn đề trước khi viết một dòng mã.
`npx codeburn@latest`
Phần còn lại của bài viết này sẽ trình bày cách CodeBurn tạo ra những con số như vậy, sử dụng các ảnh chụp màn hình thực tế từ cùng một quy trình làm việc.
**Bảng điều khiển**
Chạy `codeburn` mà không có đối số và bạn sẽ nhận được một bảng điều khiển giao diện người dùng văn bản (TUI) tương tác. Nó tải dữ liệu 7 ngày gần nhất theo mặc định. Các phím mũi tên chuyển đổi giữa Hôm nay, 7 ngày, 30 ngày, Tháng này và 6 tháng.
Bảng điều khiển tương tác CodeBurn hiển thị chi phí hàng ngày, dự án, mô hình, phân tích hoạt động, công cụ cốt lõi và lệnh shell.
Mọi thứ đều nằm trên một màn hình. Hàng trên cùng: tổng chi phí, số lượt gọi API, phiên và tỷ lệ truy cập bộ nhớ đệm. Bên dưới: biểu đồ chi phí hàng ngày, phân tích chi tiết theo từng dự án với chi phí trung bình mỗi phiên, các danh mục hoạt động với tỷ lệ thực hiện một lần, mức sử dụng mô hình, phân phối công cụ cốt lõi và các lệnh shell chính xác mà AI của bạn đã chạy.
Bảng hoạt động là nơi mọi thứ trở nên thú vị. CodeBurn phân loại mọi lượt gọi API vào 13 danh mục tác vụ dựa trên các mẫu sử dụng công cụ và từ khóa tin nhắn. Lập trình, Đối thoại, Phát triển tính năng, Khám phá, Gỡ lỗi, Tái cấu trúc, Kiểm thử, Ủy quyền, Thao tác Git, Xây dựng/Triển khai, Động não, Lập kế hoạch và Chung. Việc phân loại hoàn toàn mang tính xác định. Không có lượt gọi LLM.
Trong ảnh chụp màn hình ở trên, Lập trình chiếm 19,08 USD qua 38 lượt với tỷ lệ thực hiện một lần là 88%. Đối thoại là 3,29 USD qua 24 lượt. Tỷ lệ đó rất quan trọng. Nếu Đối thoại liên tục chiếm ưu thế trong chi tiêu của bạn, bạn đang trả tiền cho trò chuyện, không phải đầu ra.
**Phân tích mô hình theo tác vụ**
Lệnh `models` cung cấp bảng chi phí theo từng mô hình. Thêm `--by-task` và nó sẽ phân tích từng mô hình thành các hàng cho mọi loại tác vụ mà nó được sử dụng.
`codeburn models --by-task`
Phân tích chi tiết token và chi phí theo từng mô hình, theo từng tác vụ trên Claude Opus 4.6, GPT-5.5, Sonnet 4.6, Haiku 4.5 và Cursor.
Đây là dữ liệu thực tế từ cửa sổ 30 ngày. Opus 4.6 đã chi 119,68 USD cho C.
khi mã hóa một mình, với 604.4K mã thông báo đầu ra và 155.1M lượt đọc bộ nhớ đệm. GPT-5.5 trên Codex đã tiêu tốn 4,63 USD cho Phát triển tính năng và 2,59 USD cho Mã hóa. Sonnet 4.6 xử lý Khám phá với 2,04 USD và 1.1M lượt đọc bộ nhớ đệm. Haiku 4.5 thực hiện Khám phá nhẹ với 0,297 USD.
Bảng hiển thị Đầu vào, Đầu ra, Ghi bộ nhớ đệm, Đọc bộ nhớ đệm, Tổng số mã thông báo và Chi phí cho mỗi sự kết hợp. Có thể thấy chính xác nơi mỗi mô hình phát huy hiệu quả và nơi nó có thể bị lạm dụng.
mô hình codeburn --tác vụ gỡ lỗi --nhà cung cấp claude
mô hình codeburn --top 5
mô hình codeburn --định dạng markdownLọc theo tác vụ, nhà cung cấp hoặc giới hạn theo N hàng đầu. Định dạng markdown hữu ích để dán vào các yêu cầu kéo (PR) hoặc tài liệu nhóm.
Phát hiện lãng phí
Lệnh tối ưu hóa quét lịch sử phiên và cấu hình cục bộ để tìm các mẫu lãng phí cụ thể, có thể khắc phục được. Mỗi phát hiện bao gồm ước tính số mã thông báo và số tiền tiết kiệm được, cùng với một bản sửa lỗi sẵn sàng để dán.
đầu ra tối ưu hóa codeburn hiển thị Tình trạng: F (20/100), 6 vấn đề được tìm thấy, với khả năng tiết kiệm khoảng 25.4M mã thông báo (khoảng 17,18 USD). Bản quét này đã tìm thấy 6 vấn đề trên 54 phiên và 216,35 USD chi tiêu. Tổng số tiền tiết kiệm tiềm năng: khoảng 25.4M mã thông báo, xấp xỉ 17,18 USD hoặc 8% tổng số. Điểm sức khỏe thiết lập là F (20/100).
Phát hiện đầu tiên đánh dấu 2 phiên tốn kém với tín hiệu phân phối yếu. Một phiên tốn 116,17 USD với 28 lần thử lại. Một phiên khác tốn 4,20 USD mà không có bất kỳ lượt chỉnh sửa nào. Đây là những ứng cử viên để xem xét, không phải bằng chứng về sự lãng phí. CodeBurn đánh dấu chúng để người dùng có thể quyết định xem công việc có đáng giá hay không trước khi nó trở thành thói quen.
Phát hiện thứ hai xác định 9 phiên nặng ngữ cảnh, trong đó mã thông báo đầu vào/bộ nhớ đệm áp đảo đầu ra. Một phiên có đầu vào hiệu quả 4.0M so với đầu ra 40.1K (tỷ lệ 98.6:1). Điều đó thường có nghĩa là ngữ cảnh cũ bị chuyển giao hoặc các lần chạy bị bỏ dở đã tải quá nhiều.
Những điều tối ưu hóa phát hiện:
Đọc tệp trùng lặp giữa các phiên. Khắc phục: thêm vào ngữ cảnh CLAUDE.md.
Đầu ra bash không giới hạn. Khắc phục: xuất BASH_MAX_OUTPUT_LENGTH=4096
Máy chủ MCP không sử dụng. Mỗi máy chủ thêm chi phí công cụ-schema vào mỗi tin nhắn.
Các tác nhân, kỹ năng và lệnh gạch chéo ma. Được định nghĩa nhưng không bao giờ được gọi.
Các tệp CLAUDE.md bị phình to. Được tính bằng cách mở rộng @-import.
Các phiên tốn kém có giá trị thấp. Chi phí cao, không chỉnh sửa, không phân phối.
Các phiên nặng ngữ cảnh. Tỷ lệ đầu vào:đầu ra trên 25:1.
Các phiên ngoại lệ. Các phiên có chi phí gấp 2 lần trở lên so với mức trung bình của dự án.
Chạy lại sau khi thực hiện các thay đổi. Nó theo dõi trạng thái trong cửa sổ 48 giờ và phân loại mỗi phát hiện là mới, đang cải thiện hoặc đã được giải quyết.
So sánh mô hình
Lệnh so sánh đặt hai mô hình cạnh nhau với các số liệu hiệu suất và hiệu quả.




Nguồn tin: Hacker News AI — Tác giả: agentseal. Bản dịch tiếng Việt do AI thực hiện, có thể có sai sót.