Dzień spalania miliarda tokenów? Rachunki za AI programistów karzą „leniwych”
Docelowi odbiorcy: Programiści korzystający z narzędzi programistycznych AI (takich jak Cursor, Windsurf, trae…) oraz menedżerowie techniczni, którzy nie zdają sobie sprawy z kosztów AI.
Kluczowa teza: Token to nie tylko prosta jednostka rozliczeniowa, ale „zasób uwagi” i „waluta mocy obliczeniowej”. Nadużywanie trybu Agent, ignorowanie zarządzania kontekstem, to w rzeczywistości maskowanie strategicznego lenistwa (brak własnego myślenia) taktyczną pilnością (pozwalanie AI na bezsensowne działania).
Twoje „wydatki na AI” mogą być wyższe niż pensja
Kilka dni temu sprawdziłem moje rachunki za tokeny. Kiedy zobaczyłem tę liczbę, byłem trochę zaskoczony: 10 milionów tokenów. Zwróć uwagę, że to nie jest zużycie miesięczne, ale dzienne.
Myślałem, że to już przesada. Później opublikowałem krótki film o obliczeniach tokenów.
W rezultacie sekcja komentarzy pokazała mi, co to znaczy „niebo nad niebem”.
Poniższy obrazek to zrzut ekranu z dziennego zużycia dwóch miliardów tokenów użytkownika „Codzienność starego K”:

Na początku myślałem, że to odosobniony przypadek, ale kiedy wielu użytkowników zaczęło pisać, że zużywają 100 milionów dziennie, zdałem sobie sprawę, że to powszechne zjawisko.
Co to znaczy sto milionów tokenów? Jeśli oszacujemy to na podstawie typowego poziomu rozliczeń „niektórych głównych modeli komercyjnych” (opłaty za wejście/wyjście są naliczane oddzielnie, łącznie z grubsza 10 USD / milion tokenów), to dziennie spala się 1000 USD. Dzień spalania 7000 RMB. Miesięczna pensja wielu początkujących programistów może nie wystarczyć na jeden dzień „myślenia” AI.
(Uwaga: Różnice w cenach między różnymi modelami/dostawcami są ogromne, a ceny jednostkowe za wejście i wyjście często się różnią. Celem tutaj nie jest dokładne obliczenie do dwóch miejsc po przecinku, ale raczej ustalenie „poczucia skali”.)
Jeśli chcesz samemu przeliczyć, zazwyczaj jest to jeden wzór (ignorując buforowanie/rabaty i inne specjalne zasady):
Koszt ≈ (Tokeny wejściowe / 1 000 000) × Cena jednostkowa_in + (Tokeny wyjściowe / 1 000 000) × Cena jednostkowa_out
To jest bardzo sprzeczne z intuicją. Zawsze myślimy, że AI jest tanie, a OpenAI nawet obniża ceny. Ale dlaczego w rzeczywistych projektach zużycie tokenów eksploduje wykładniczo?
Dziś przeprowadzimy dogłębną analizę logiki stojącej za tym „czarną dziurą tokenów” i tego, jak powinniśmy powstrzymać straty.
I. Dlaczego tokeny „eksplodują wykładniczo”?
Wielu braci nie ma pojęcia o skali tokenów. Myślą: „Och, to tylko kilka linijek kodu, ile to może być?”
1. Obliczmy to jasno
Najpierw ustalmy użyteczne w projekcie postrzeganie ilościowe. Powiedzmy to jasno: Token to nie liczba słów ani liczba znaków. To „fragment kodu” po podziale tekstu przez model. Różne modele używają różnych tokenizerów, więc możemy podać tylko przedział, a nie stałą, która jest „uniwersalna”.
Poniższe liczby traktuj jako „miarki szacunkowe” (celem jest ocena skali, oszacowanie kosztów, podjęcie decyzji o powstrzymaniu strat):
-
1 chiński znak: Zazwyczaj 1–2 tokeny (częste znaki są bliższe 1, rzadkie znaki/kombinacje łatwiej osiągają 2–3)
-
1 angielskie słowo: Zazwyczaj około 1,2–1,5 tokena (do zgrubnego oszacowania można użyć 1,3)
-
1 linia kodu ≈ 10–50 tokenów (wraz z wcięciami, komentarzami, deklaracjami typów)
-
Zwięzła logika biznesowa ≈ 12–20 tokenów
-
Z adnotacjami typów, interfejsem, JSDoc, 4 spacjami wcięcia ≈ 20–35 tokenów
-
Z dużą liczbą importów / dekoratorów / komentarzy ≈ 30–50+ tokenów
-
1 plik źródłowy (400–600 linii, nowoczesny projekt TS/Java) ≈ 4 000–24 000 tokenów jest bardzo powszechne (mediana ≈ 12 000–18 000)
-
1 średniej wielkości projekt (100–200 plików źródłowych, licząc tylko
src/, beznode_modules// wygenerowanego kodu) -
„Przeczytanie” kodu źródłowego często zaczyna się od miliona tokenów
-
Jeśli dodamy testy, konfiguracje, skrypty, deklaracje zależności, logi, to nie dziwi kilkanaście milionów tokenów
Obecne projekty front-endowe są w TypeScript, pełne złożonych definicji interfejsów; lub Java, z dziesiątkami linii importu. Ten „kod szablonowy” jest w rzeczywistości zabójcą tokenów. Średniej wielkości projekt, jeśli ma 100 plików, samo „przeczytanie kodu” przez AI może bezpośrednio zabić 1 milion tokenów.
2. Efekt „kuli śnieżnej” tokenów
Najstraszniejsze w zużyciu tokenów nie jest pojedyncza rozmowa, ale akumulacja kontekstu w wieloetapowych rozmowach.
Mechanizm LLM jest bezstanowy. Aby AI pamiętało, co powiedziałeś wcześniej, system zazwyczaj pakuje „podpowiedź systemową + historię rozmów + fragmenty plików/kodu, do których się odwołałeś + wyjście wywołania narzędzia (np. wyniki wyszukiwania, logi błędów)” i wysyła je do modelu. Myślisz, że zadałeś tylko jedno pytanie, ale w rzeczywistości płacisz wielokrotnie za „cały pakiet kontekstowy”.
-
Runda 1: Wysyłasz 10 000 tokenów, AI odpowiada 1000.
-
Runda 2: Wysyłasz (10 000 + 1000 + nowe pytanie), AI odpowiada...
-
Runda 10: Twój kontekst mógł już urosnąć do 200 000 tokenów.
W tym momencie, nawet jeśli zapytasz tylko „pomóż mi zmienić nazwę zmiennej”, zużyjesz 200 000 tokenów. Dlatego czujesz, że nic nie robisz, a rachunek szaleje.
Co gorsza: Tryb Agent „aktywnie czyta pliki”. Mówisz „pomóż mi zoptymalizować moduł użytkownika”, a on może najpierw przeskanować powiązane katalogi, następnie przejść do zależności, następnie do konfiguracji, następnie do testów… Nie leni się, ale „sumiennie przestrzega domyślnej strategii”, a domyślna strategia często brzmi: czytaj więcej, próbuj więcej, iteruj więcej.
II. Dwa rodzaje „lenistwa” niszczą twoje umiejętności inżynierskie
Po przeanalizowaniu tych kilku „miliarderów” z sekcji komentarzy, odkryłem, że źródłem gwałtownego wzrostu tokenów jest nie tylko problem mechanizmu zużycia AI, ale także lenistwo ludzi.
Poniżej znajdują się dwa typowe rodzaje „lenistwa myślowego”.
Lenistwo 1: Typ „zrzucający odpowiedzialność”
Czy masz taką mentalność:
-
„Ten stary projekt jest zbyt zagmatwany, nie chce mi się patrzeć na logikę, po prostu wrzucę go do AI.”
-
„Cursor wypuścił tryb Agent, świetnie, niech sam naprawia błędy.”
Więc wrzucasz cały folder src do Agenta i wydajesz niejasne polecenie: „Pomóż mi zoptymalizować moduł użytkownika”. Agent zaczyna działać:
-
Odczytuje 50 plików (zużywa 500 000).
-
Odkrywa, że odwołuje się do
utils, więc idzie czytać klasy narzędziowe (zużywa 200 000). -
Próbuje modyfikować, pojawia się błąd, odczytuje logi błędów (zużywa 100 000).
-
Próbuje naprawić, znowu pojawia się błąd...
Szaleńczo próbuje i popełnia błędy, szaleńczo zużywa tokeny. A ty? Przeglądasz telefon, myśląc, że jesteś bardzo wydajny. Prawda jest taka: płacisz pieniędzmi za „fałszywą wydajność”, produkując stertę kodu, którego nie będziesz w stanie utrzymać w przyszłości.
Mówiąc bardziej profesjonalnie, są tu dwie warstwy strat:
-
Warstwa kosztów: Zwiększa się liczba tokenów wejściowych, zwiększa się liczba iteracji, koszty sumują się liniowo
-
Warstwa inżynierska: Tracisz kontekst i prawo do podejmowania decyzji, a na końcu zostaje tylko niekontrolowany system, który „po prostu działa”
Lenistwo 2: Typ „wszystko w jednym”
Jak wrzucasz błąd do AI? Czy po prostu kopiujesz cały konsolę błędów za pomocą Ctrl+A, czy po prostu @Codebase pozwalasz AI samemu znaleźć?
To się nazywa „wszystko w jednym”. Nie chce ci się lokalizować sedna problemu, nie chce ci się filtrować kluczowych fragmentów kodu. Wrzucasz do AI 99% bezużytecznych informacji (szumu) i 1% użytecznych informacji (sygnału).
AI jest jak wzmacniacz.
-
Dajesz mu jasną logikę (sygnał), on wzmacnia twoją mądrość, zużywa mało tokenów, efekt jest dobry.
-
Dajesz mu chaos i niejasność, on wzmacnia twój chaos, tokeny szaleją, produkuje śmieci.
III. Rozwiązanie: Jak efektywnie korzystać z AI, zmniejszyć zużycie tokenów
Aby chronić swój portfel, ważniejsze jest zachowanie kontroli inżynierskiej, musimy zmienić model współpracy z AI.
1. Zasada minimalnego kontekstu
To jest pierwsza zasada programowania AI. Zawsze dawaj AI tylko minimalny zbiór kodu odpowiadający aktualnemu problemowi.
W Cursorze dobrze wykorzystuj te operatory:
-
@File: Odwołuj się tylko do powiązanych plików, a nie do całego folderu. -
Ctrl+L** Zaznacz kod**: Wysyłaj do Chatu tylko 50 linii kodu zaznaczonych kursorem, a nie cały plik. -
@Docs: W przypadku bibliotek zewnętrznych odwołuj się do dokumentacji, zamiast pozwalać mu zgadywać.
To jest mój często używany, ustrukturyzowany, wielokrotnego użytku SOP (jeśli to zrobisz, tokeny spadną w widoczny sposób):
To zdanie oznacza: Współpracując z AI, należy zwracać uwagę na wydajność i precyzję. Konkretne kroki są następujące:
-
Najpierw określ cel: Zwięźle powiedz AI o aktualnym problemie i oczekiwanym wyniku, nie pozwól mu zgadywać.
-
Uprość odtworzenie problemu: Użyj najprostszej metody, aby odtworzyć problem, zamiast używać złożonej metody, wklej najmniej i kluczowy kod, nie dodawaj dużej ilości nieistotnych treści.
-
Podaj minimalne niezbędne informacje: Podaj tylko 1-3 powiązane pliki, kluczowe funkcje i kilka pierwszych linii stosu błędów, nie podawaj pełnych informacji.
-
Zażądaj zwrócenia punktów modyfikacji: Pozwól AI powiedzieć ci tylko, gdzie zmienić, dlaczego zmienić, nie pozwól mu pisać na nowo całego kodu.
-
Na koniec sam to sprawdź: Wykonaj najprostsze sprawdzenie, aby upewnić się, że zmiany nie wpłynęły na inne miejsca.
Krótko mówiąc, użyj najmniejszej ilości kluczowych informacji, aby AI wykonało zadanie, i zachowaj ostateczną kontrolę i osąd.
2. Również najważniejsze: Najpierw pomyśl, potem Prompt, najpierw zaplanuj, potem działaj
Zanim naciśniesz Enter, zmuś się do zatrzymania na 10 sekund i zadaj sobie trzy pytania:
-
Jaki problem rozwiązuję? (Zdefiniuj granice)
-
Jakie kluczowe moduły dotyczą tego problemu? (Filtruj kontekst)
-
Gdybym sam to pisał, jak bym to napisał? (Podaj pomysły)
Ty jesteś 1, AI jest 0 za tobą. Jeśli 1 nie stoi mocno, to bez względu na to, ile jest 0 za tobą, jest to tylko bezsensowne zużycie.
Kilka słów od serca
Historia „miliarda tokenów dziennie” może nie przydarzyć się każdemu. Ale marnowanie tokenów to zachowanie, którego doświadczył prawie każdy programista korzystający z programowania AI.
Chociaż AI sprawia, że programowanie staje się łatwiejsze, nadal istnieją bariery. Ci, którzy naprawdę wiedzą, jak go używać, będą mieli skrzydła.
Wcześniej twój zły kod tylko „obrzydzał” kolegów. Teraz twoje lenistwo bezpośrednio zamieni się w liczby na rachunku, karząc cię rosnącymi kosztami. Więc nie bądź "wolnym strzelcem". Bądź architektem AI, który głęboko myśli, precyzyjnie się wyraża i planuje przed działaniem. To jest nasza największa niezastąpiona cecha w tych czasach.




