Ciljana 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 ideja: Token nije samo jednostavna jedinica naplate, već i "resurs pažnje" i "računalna valuta". Zlouporaba Agent načina rada i zanemarivanje upravljanja kontekstom zapravo prikrivaju stratešku lijenost (nedostatak vlastitog razmišljanja) taktičkom marljivošću (pustiti AI da se besciljno muči).

Vaši "AI troškovi" mogu biti veći od plaće

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

Mislio sam da je ovo ludo. Kasnije sam objavio kratki video o izračunu Tokena.

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

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

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

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

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

Ako želite sami ponovno izračunati, općenito postoji ova formula (zanemarujući posebna pravila kao što su predmemorija/popusti): Trošak ≈ (Ulazni Tokeni / 1,000,000) × Jedinična cijena_ulaz + (Izlazni Tokeni / 1,000,000) × Jedinična cijena_izlaz

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

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

I. Zašto Tokeni "eksponencijalno eksplodiraju"?

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

1. Izračunajte jasnu računicu

Prvo uspostavimo kvantitativnu percepciju koja je dovoljna za inženjering. Prvo to recimo jasno: 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 možete smatrati "mjernim alatima" (svrha je procijeniti veličinu, procijeniti troškove i donijeti odluke o zaustavljanju gubitaka):

• 1 kineski znak: Obično 1–2 Tokena (visokofrekventni 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)

• Sažeta poslovna logika ≈ 12–20 Tokena

• S anotacijama tipova, sučeljem, JSDoc, 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/, bez node_modules/ / generiranog koda)

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

• Ako se u to uključe testovi, konfiguracije, skripte, deklaracije ovisnosti i zapisi, nije rijetkost da se dosegne desetke milijuna Tokena

Današnji frontend projekti su TypeScript, puni složenih definicija sučelja; 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 u vezi s potrošnjom 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 šalje model "uputu sustava + povijest razgovora + isječke datoteka/koda koje ste citirali + izlaz poziva alata (kao što su rezultati pretraživanja, zapisi pogrešaka)". Mislite da ste postavili samo jedno pitanje, ali zapravo više puta plaćate za "cijeli paket konteksta".

• 1. krug: Pošaljite 10,000 Tokena, AI odgovara s 1,000.

• 2. krug: Pošaljite (10,000 + 1,000 + novo pitanje), AI odgovara...

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

U ovom trenutku, čak i ako samo pitate "pomozi mi promijeniti naziv varijable", potrošit ćete 200,000 Tokena. Zato mislite da niste ništa radili, ali vam računi divljaju.

Ono što je još gore: Agent način rada će "proaktivno čitati datoteke". Ako kažete "pomozi mi optimizirati korisnički modul", on može prvo skenirati relevantni direktorij, zatim pratiti ovisnosti, zatim pratiti konfiguraciju, zatim pratiti testove... On ne zabušava, 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 ljudskom lijenošću.

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 način rada, super, neka sam popravlja greške."

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 uslužne klase (troši 200,000).

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

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

Ludo pokušava i griješi, ludo troši Tokene. A vi? Vi skrolate po telefonu i mislite 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:

• Razina troškova: Ulazni Tokeni postaju veći, broj iteracija se povećava, a troškovi se linearno zbrajaju

• Inženjerska razina: Gubitak konteksta i ovlasti odlučivanja, na kraju ostaje samo nekontrolirani sustav "sve dok radi"

Lijenost 2: Tip "sve u jednom"

Kako dajete AI-u grešku? Kopirate li izravno cijelu konzolu pogrešaka s Ctrl+A ili dopuštate AI-u da sam pronađe s @Codebase?

Ovo se zove "sve u jednom". Previše ste lijeni da biste locirali srž 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) u AI.

AI je poput pojačala.

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

• Ako mu date kaos i nejasnoće, on pojačava vaš kaos, Tokeni divljaju, a proizvodi se smeće.

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

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

1. Načelo minimalnog konteksta

Ovo je prvo načelo AI programiranja. Uvijek dajte AI samo minimalni 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 u Chat, a ne cijelu datoteku.

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

Ovo je strukturirani SOP koji često koristim i koji se može ponovno koristiti (ako to učinite, Tokeni će vidljivo pasti):

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

• Prvo definirajte cilj: Sažeto i jasno recite AI trenutni problem i željeni rezultat, nemojte dopustiti da sam pogađa.

• Pojednostavite reprodukciju problema: Ako možete koristiti najjednostavniju metodu za reprodukciju problema, nemojte koristiti složenu metodu, zalijepite najmanje i ključne kodove, nemojte gomilati hrpu nepovezanog sadržaja.

• Pružite 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 povratne informacije o izmjenama: Neka vam AI kaže samo gdje se mijenja i zašto se mijenja, nemojte dopustiti da prepisuje cijeli kod u velikoj mjeri.

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

Ukratko, koristite najmanje i najvažnije informacije kako biste natjerali AI da radi i zadržite konačnu kontrolu i prosudbu.

2. Također najvažnije: prvo razmislite, zatim upitajte, 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)

• Koje ključne module ovaj problem uključuje? (Filtrirajte kontekst)

• Kako bih to napisao da pišem sam? (Pružite ideje)

**Vi ste 1, AI je 0 iza. **Ako 1 ne može stajati, bez obzira koliko 0 ima iza, to je samo besmisleno trošenje.

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 ga stvarno znaju koristiti bit će još moćniji.

Prije su vaši loši kodovi samo "gadili" kolege. Sada će vaša lijenost izravno postati broj na računu, kažnjavajući vas rastućim troškovima. Dakle, nemojte biti "samo promatrač". Budite AI arhitekt koji duboko razmišlja, precizno se izražava i djeluje nakon planiranja. To je također naša najveća nezamjenjivost u ovom dobu.