Ciljna publika: Programeri koji koriste AI alate za programiranje (kao što su Cursor, Windsurf, trae...) i tehnički menadžeri koji nemaju svijest o troškovima AI.

Ključna teza: Token nije samo jednostavna jedinica za naplatu, već i "resurs pažnje" i "računalna valuta". Zloupotreba Agent moda, zanemarivanje upravljanja kontekstom, zapravo je korištenje taktičke marljivosti (dopuštanje AI-u da se besciljno muči) kako bi se prikrila strateška lijenost (nedostatak vlastitog razmišljanja).

Vaš "AI trošak" može biti veći od plaće

Prije nekoliko dana, provjerio sam svoj račun za Tokene. Bio sam malo iznenađen kada sam vidio tu brojku: 10 milijuna Tokena. Imajte na umu, ovo nije mjesečna potrošnja, već dnevna.

Mislio sam da je ovo već ekstremno. Kasnije sam objavio kratki video o izračunu Tokena.

Kao rezultat toga, komentari su mi pokazali što znači "nebo iznad neba".

Sljedeća slika je snimka zaslona dnevne potrošnje od dvije milijarde Tokena korisnika "老K的日常":

U početku sam mislio da je to možda izoliran slučaj, ali kada su mnogi korisnici ostavili komentare da troše 100 milijuna dnevno, shvatio sam da je to vrlo česta pojava.

Što znači 100 milijuna Tokena? Ako se računa prema uobičajenoj razini naplate "nekih glavnih komercijalnih modela" (ulaz/izlaz se naplaćuju zasebno, a zajedno se grubo procjenjuje na 10 USD / milijun Tokena), onda se taj dan spalilo 1000 USD. Jedan dan spaljivanje 7000 juana. Plaća mnogih početnika programera možda nije dovoljna za "razmišljanje" AI-a taj dan.

(Napomena: Razlike u cijenama između različitih modela/dobavljača su velike, a jedinične cijene za ulaz i izlaz također se često razlikuju. Svrha ovdje nije precizno izračunati do dvije decimale, već prvo uspostaviti "osjećaj za razmjer".)

Ako želite sami ponovno izračunati, općenito postoji ova formula (zanemarujući posebna pravila kao što su predmemorija/popusti): Trošak ≈ (UlazniToken / 1,000,000) × JediničnaCijena_in + (IzlazniToken / 1,000,000) × JediničnaCijena_out

Ovo je previše kontraintuitivno. Uvijek mislimo da je AI jeftin, OpenAI čak želi smanjiti cijene. Ali zašto se u stvarnom inženjeringu potrošnja Tokena eksponencijalno eksplodira?

Danas ću vas provesti kroz dubinsku analizu logike iza ove "crne rupe Tokena" i kako bismo trebali zaustaviti gubitke.

I. Zašto Tokeni "eksponencijalno eksplodiraju"?

Mnogi ljudi nemaju pojma o veličini Tokena. Misle: "Ah, zar to nije samo nekoliko redaka koda? Koliko to može biti?"

1. Izračunajte jasan račun

Prvo uspostavimo kvantitativnu percepciju koja je dovoljna za inženjering. Prvo budimo kategorični: Token nije broj riječi, niti broj znakova. To je "kodni fragment" nakon što model podijeli tekst. Različiti modeli koriste različite tokenizer-e, tako da se može dati samo raspon, a ne "univerzalna" konstanta.

Sljedeće brojeve tretirajte kao "mjerila za procjenu" (svrha je procijeniti veličinu, procijeniti troškove, donijeti odluke o zaustavljanju gubitaka):

• 1 kineski znak: Obično 1–2 Tokena (češći znakovi su bliži 1, rijetki znakovi/kombinacije lakše dosežu 2–3)

• 1 engleska riječ: Obično oko 1.2–1.5 Tokena (gruba procjena može koristiti i 1.3)

• 1 redak koda ≈ 10–50 Tokena (uključujući uvlake, komentare, deklaracije tipova)

• Jednostavna poslovna logika ≈ 12–20 Tokena

• S anotacijama tipova, interface-om, JSDoc-om, 4 razmaka za uvlake ≈ 20–35 Tokena

• S velikim brojem import-a / dekoratora / komentara ≈ 30–50+ Tokena

• 1 izvorna datoteka (400–600 redaka, moderni TS/Java projekt) ≈ 4,000–24,000 Tokena je vrlo često (medijan ≈ 12,000–18,000)

• 1 srednji projekt (100–200 izvornih datoteka, samo src/, ne uključuje node_modules/ / generirani kod)

• "Čitanje" osnovnog izvornog koda "jednom" često počinje s milijun Tokena

• Ako se u to ubace testovi, konfiguracije, skripte, deklaracije ovisnosti, zapisi, nije neobično da se dosegne desetke milijuna Tokena

Današnji frontend projekti su TypeScript, puni složenih Interface definicija; ili Java, s desecima redaka Import-a. Ovaj "boilerplate kod" zapravo je ubojica Tokena. Srednji projekt, ako ima 100 datoteka, samo dopuštanje AI-u da "pročita kod" vjerojatno će izravno uništiti 1 milijun Tokena.

2. Učinak "grude snijega" Tokena

Najstrašnija stvar kod potrošnje Tokena nije jednokratni razgovor, već akumulacija konteksta u višestrukim razgovorima.

Mehanizam LLM-a je bez stanja. Kako bi se AI sjetio što ste rekli u prethodnoj rečenici, sustav obično pakira "upute sustava + povijest razgovora + isječke datoteka/koda koje ste citirali + izlaz poziva alata (kao što su rezultati pretraživanja, zapisi pogrešaka)" i šalje ih modelu. Mislite da ste postavili samo jedno pitanje, ali zapravo više puta plaćate za "cijeli paket konteksta".

• 1. krug: Šalje se 10 000 Tokena, AI odgovara s 1 000.

• 2. krug: Šalje se (10 000 + 1 000 + novo pitanje), AI odgovara...

• 10. krug: Vaš kontekst se možda već proširio na 200 000 Tokena.

U ovom trenutku, čak i ako samo pitate "pomozi mi promijeniti naziv varijable", trošite 200 000 Tokena. Zato mislite da niste ništa radili, ali vaš račun divlja.

Što je još gore: Agent mod "aktivno čita datoteke". Kažete "pomozi mi optimizirati korisnički modul", on može prvo skenirati relevantne direktorije, zatim pratiti ovisnosti, zatim pratiti konfiguraciju, zatim pratiti testove... On ne izbjegava posao, on "odgovorno izvršava zadanu strategiju", a zadana strategija je često: čitaj više, pokušavaj više, iteriraj više.

II. Dvije vrste "lijenosti" uništavaju vaše inženjerske sposobnosti

Nakon pregleda onih nekoliko "milijardera" u odjeljku za komentare, otkrio sam da korijen eksplozije Tokena nije samo problem mehanizma potrošnje AI-a, već je usko povezan s lijenošću ljudi.

U nastavku su dvije tipične vrste "mentalne lijenosti".

Lijenost 1: Tip "predaj sve"

Imate li i vi ovaj mentalitet:

• "Ovaj stari projekt je previše neuredan, previše sam lijen da bih gledao logiku, samo ću ga baciti AI-u."

• "Cursor je objavio Agent mod, super, neka sam popravi Bugove."

Dakle, bacite cijelu mapu src Agentu i izdate nejasnu naredbu: "Pomozi mi optimizirati korisnički modul." Agent počinje raditi:

• Čita 50 datoteka (troši 500 000).

• Otkriva da se poziva na utils, pa ide čitati pomoćne klase (troši 200 000).

• Pokušava modificirati, javlja se pogreška, čita zapis pogreške (troši 100 000).

• Pokušava popraviti, opet se javlja pogreška...

On ludo pokušava i griješi, ludo troši Tokene. A vi? Vi skrolate po telefonu, misleći da ste vrlo učinkoviti. Istina je: lažnu učinkovitost koju ste kupili novcem, proizvela je hrpu koda koju kasnije ne možete održavati.

Profesionalnije rečeno, ovdje postoje dva sloja gubitaka:

• Sloj troškova: Ulazni Token postaje veći, broj iteracija se povećava, troškovi se linearno zbrajaju

• Sloj inženjeringa: Gubitak konteksta i ovlasti za donošenje odluka, na kraju ostaje samo nekontrolirani sustav "sve dok radi"

Lijenost 2: Tip "sve u jednom"

Kako dajete AI-u Bug kada ga naiđete? Kopirate li izravno cijelu konzolu pogrešaka s Ctrl+A, ili izravno @Codebase dopuštate AI-u da sam pronađe?

Ovo se zove "sve u jednom". Previše ste lijeni da biste locirali jezgru problema, previše ste lijeni da biste filtrirali ključne isječke koda. Bacate 99% nevažećih informacija (šuma) i 1% važećih informacija (signal) AI-u.

AI je poput pojačala.

• Dajete mu jasnu logiku (signal), on pojačava vašu mudrost, troši se manje Tokena, učinak je dobar.

• Dajete mu zbrku i nejasnoće, on pojačava vašu zbrku, Tokeni divljaju, proizvodi smeće.

III. Rješenje: Kako učinkovito koristiti AI, smanjiti potrošnju Tokena

Želite li zaštititi svoj novčanik, još je važnije zaštititi svoju kontrolu nad inženjeringom, moramo promijeniti način na koji surađujemo s AI-om.

1. Načelo minimalnog konteksta

Ovo je prvo načelo AI programiranja. Uvijek dajte AI-u najmanji skup koda koji odgovara trenutnom problemu.

U Cursoru, dobro iskoristite ove operatore:

• @File: Citirajte samo relevantne datoteke, a ne cijelu mapu.

• Ctrl+L Odaberite kod: Pošaljite samo 50 redaka koda koje je odabrao kursor Chatu, a ne cijelu datoteku.

• @Docs: Za biblioteke trećih strana, citirajte dokumentaciju umjesto da dopustite da nagađa.

Ovo je SOP koji često koristim, strukturiran i višekratno upotrebljiv (ako to učinite, Tokeni će vidljivo pasti):

Ova rečenica znači: Kada surađujete s AI-om, obratite pozornost na učinkovitost i preciznost. Konkretne prakse su sljedeće:

• Prvo razjasnite cilj: Ukratko i jezgrovito recite AI-u trenutni problem i željeni rezultat, nemojte dopustiti da sam nagađa.

• Pojednostavite reprodukciju problema: Ako se problem može reproducirati najjednostavnijom metodom, nemojte koristiti složenu metodu, zalijepite najmanje i ključne kodove, nemojte gomilati hrpu nepovezanog sadržaja.

• Osigurajte minimalne potrebne informacije: Dajte samo 1-3 relevantne datoteke, ključne funkcije i prvih nekoliko redaka stoga pogrešaka, nemojte davati sve informacije.

• Zatražite vraćanje točaka izmjene: Neka vam AI kaže samo gdje se mijenja, zašto se mijenja, nemojte dopustiti da ponovno napiše cijeli odlomak.

• Na kraju, sami provjerite: Napravite najjednostavniju provjeru kako biste osigurali da promjene ne utječu na druga mjesta.

Ukratko, koristite najmanje, najvažnije informacije kako bi AI radio stvari i zadržite konačnu kontrolu i ovlast za donošenje odluka.

2. Također najvažnije: prvo razmislite, zatim Prompt, prvo planirajte, zatim djelujte

Prije nego što pritisnete enter, prisilite se da zastanete 10 sekundi i postavite si tri pitanja:

• Koji problem rješavam? (Definirajte granice)

• Koji su ključni moduli uključeni u ovaj problem? (Filtrirajte kontekst)

• Da pišem sam, kako bih pisao? (Osigurajte ideje)

**Vi ste 1, AI je 0 iza. **Ako 1 ne može stajati, bez obzira koliko 0 ima iza, to je samo besmislena potrošnja.

Nekoliko iskrenih riječi

Priča o "sto milijuna Tokena dnevno" možda se neće dogoditi svima. Ali ponašanje rasipanja Tokena doživjet će gotovo svaki programer koji koristi AI programiranje.

Iako AI olakšava programiranje, još uvijek postoje prepreke. Oni koji znaju kako ga koristiti, bit će kao tigar s krilima.

Prije je vaš loš kod samo "gadio" kolegama. Sada će vaša lijenost izravno postati broj na računu, kažnjavajući vas rastućim troškovima. Zato, nemojte biti "samo nadzornik". Budite AI arhitekt koji duboko razmišlja, precizno se izražava i planira prije nego što djeluje. To je naša najveća nezamjenjivost u ovom dobu.