Public țintă: Dezvoltatorii care utilizează instrumente de programare AI (cum ar fi Cursor, Windsurf, trae...) și managerii tehnici care nu sunt conștienți de costurile AI.

Ideea centrală: Tokenii nu sunt doar o simplă unitate de facturare, ci și o „resursă de atenție” și o „monedă de putere de calcul”. Abuzul de modul Agent și ignorarea gestionării contextului înseamnă, de fapt, acoperirea lenei strategice (lipsa de gândire proprie) cu sârguința tactică (lăsarea AI să bâjbâie).

Cheltuielile tale cu AI ar putea fi mai mari decât salariul

Zilele trecute, mi-am verificat factura de Tokeni. Când am văzut numărul, am fost puțin surprins: 10 milioane de Tokeni. Atenție, aceasta nu este utilizarea pe o lună, ci pe o zi.

Credeam că sunt un caz extrem. Apoi am postat un scurt videoclip despre calculul Tokenilor.

Ca rezultat, secțiunea de comentarii mi-a arătat ce înseamnă „cerul este limita”.

Următoarea imagine este o captură de ecran a înregistrării consumului de două sute de milioane de Tokeni pe zi a utilizatorului de internet „Viața de zi cu zi a lui Lao K”:

La început, am crezut că este un caz izolat, dar când mulți utilizatori de internet au comentat că consumă 100 de milioane pe zi, am înțeles că este un fenomen foarte comun.

Ce înseamnă un miliard de Tokeni? Dacă calculăm după nivelul obișnuit de facturare al „unor modele comerciale mainstream” (facturarea separată pentru intrare/ieșire, estimând aproximativ 10 USD / milion de Tokeni), atunci se ard 1000 de dolari pe zi. Se ard 7000 de yuani pe zi. Salariul lunar al multor programatori juniori ar putea să nu fie suficient pentru ca AI să „gândească” în acea zi.

(Notă: Diferențele de preț între diferite modele/furnizori sunt foarte mari, iar prețul unitar al intrărilor și ieșirilor este adesea diferit. Scopul aici nu este de a calcula cu precizie până la a doua zecimală, ci de a stabili mai întâi un „sentiment de scară”.)

Dacă doriți să vă recalculați singur, există, în general, această formulă (ignorând regulile speciale, cum ar fi memoria cache/reducerile): Cost ≈ (Tokeni de intrare / 1.000.000) × Preț unitar_in + (Tokeni de ieșire / 1.000.000) × Preț unitar_out

Acest lucru este prea contraintuitiv. Credem întotdeauna că AI este ieftină, iar OpenAI chiar vrea să reducă prețurile. Dar de ce, în ingineria reală, consumul de Tokeni explodează exponențial?

Astăzi, vă vom duce să analizați în profunzime logica din spatele acestei „găuri negre de Tokeni” și cum ar trebui să oprim pierderile.

I. De ce Tokenii „explodează exponențial”?

Mulți frați nu au deloc o idee despre volumul Tokenilor. Ei cred: „Auzi, nu sunt doar câteva rânduri de cod? Cât de mult poate fi?”

1. Să facem un calcul clar

Trebuie mai întâi să stabilim o percepție cantitativă utilă în inginerie. Să spunem mai întâi ceva definitiv: Tokenii nu sunt numărul de cuvinte și nici numărul de caractere. Este „fragmentul de codificare” după ce modelul împarte textul. Diferite modele folosesc tokenizatoare diferite, deci se poate da doar un interval, nu o constantă „valabilă pentru toate situațiile”.

Considerați următoarele numere ca „instrumente de estimare” (scopul este de a determina scara, de a estima costurile și de a lua decizii de stop-loss):

• 1 caracter chinezesc: frecvent 1–2 Tokeni (caracterele de înaltă frecvență sunt mai aproape de 1, iar caracterele/combinațiile rare sunt mai ușor de ajuns la 2–3)

• 1 cuvânt englezesc: frecvent în jur de 1,2–1,5 Tokeni (aproximativ 1,3 pentru estimare brută este, de asemenea, OK)

• 1 rând de cod ≈ 10–50 Tokeni (inclusiv indentare, comentarii, declarații de tip)

• Logică de afaceri concisă ≈ 12–20 Tokeni

• Cu adnotări de tip, interfață, JSDoc, indentare cu 4 spații ≈ 20–35 Tokeni

• Cu o mulțime de importuri / decoratori / comentarii ≈ 30–50+ Tokeni

• 1 fișier sursă (400–600 de rânduri, proiect modern TS/Java) ≈ 4.000–24.000 Tokeni este foarte frecvent (median ≈ 12.000–18.000)

• 1 proiect de dimensiuni medii (100–200 de fișiere sursă, numărând doar src/, excluzând node_modules/ / cod generat)

• „Citirea” codului sursă de bază „o dată” începe adesea cu un milion de Tokeni

• Dacă mai adăugați teste, configurații, scripturi, declarații de dependență și jurnale, nu este neobișnuit să ajungeți la zeci de milioane de Tokeni

Proiectele front-end de astăzi sunt toate TypeScript, pline de definiții complexe de interfață; sau Java, cu zeci de rânduri de Import dintr-o dată. Acest „cod boilerplate” este de fapt un ucigaș de Tokeni. Un proiect de dimensiuni medii, dacă are 100 de fișiere, doar pentru a permite AI să „citească codul” poate elimina direct 1 milion de Tokeni.

2. Efectul de „bulgăre de zăpadă” al tokenilor

Cel mai înfricoșător lucru despre consumul de Tokeni nu este o singură conversație, ci acumularea contextului în conversații multiple.

Mecanismul LLM este stateless. Pentru a face AI să-și amintească ce ai spus ultima dată, sistemul va împacheta de obicei „promptul de sistem + istoricul conversațiilor + fragmentele de fișiere/cod pe care le-ai citat + ieșirea apelurilor de instrumente (cum ar fi rezultatele căutării, jurnalele de erori)” și le va trimite modelului. Crezi că ai pus doar o întrebare, dar de fapt plătești în mod repetat pentru „întregul pachet de context”.

• Runda 1: Trimiterea a 10.000 de Tokeni, AI răspunde cu 1.000.

• Runda 2: Trimiterea (10.000 + 1.000 + întrebare nouă), AI răspunde...

• Runda 10: Contextul tău s-ar putea să se fi umflat deja la 200.000 de Tokeni.

În acest moment, chiar dacă pui doar o întrebare „ajută-mă să schimb un nume de variabilă”, vei consuma și costul a 200.000 de Tokeni. De aceea simți că nu ai făcut nimic, dar factura crește vertiginos.

Ceea ce este și mai grav este că: Modul Agent va „citi proactiv fișierele”. Dacă spui „ajută-mă să optimizez modulul utilizator”, ar putea mai întâi să scaneze directoarele relevante, apoi să urmărească dependențele, apoi să urmărească configurația, apoi să urmărească testele... Nu este leneș, ci „își îndeplinește responsabilitățile conform strategiei implicite”, iar strategia implicită este adesea: citește mai mult, încearcă mai mult, iterează mai mult.

II. Două tipuri de „lene” îți distrug capacitatea de inginerie

După o analiză aprofundată a acelor câțiva „băieți de un miliard” din secțiunea de comentarii, am descoperit că rădăcina creșterii vertiginoase a Tokenilor nu este doar problema mecanismului de consum al AI, ci și strâns legată de lenea oamenilor.

Există două tipuri tipice de „lene mentală” mai jos.

Lenea unu: Tipul de manager care nu se implică

Ai și tu această mentalitate:

• „Acest proiect vechi este prea dezordonat, sunt prea leneș să mă uit la logică, hai să-l arunc direct la AI.”

• „Cursor a lansat modul Agent, excelent, lasă-l să repare singur Bug-urile.”

Așa că arunci întregul folder src la Agent și dai o instrucțiune vagă: „Ajută-mă să optimizez modulul utilizator.” Agentul începe să lucreze:

• Citește 50 de fișiere (consumând 500.000).

• Descoperă că utils este citat și merge să citească clasele de instrumente (consumând 200.000).

• Încearcă să modifice, primește o eroare, citește jurnalul de erori (consumând 100.000).

• Încearcă să repare, primește din nou o eroare...

Încearcă și greșește nebunește, consumând Tokeni nebunește. Și tu? Navighezi pe telefon și simți că ești foarte eficient. Adevărul este: „pseudo-eficiența” pe care o cumperi cu bani produce o grămadă de cod pe care nu o poți menține ulterior.

Mai profesional, există două straturi de pierderi aici:

• Stratul de cost: Tokenii de intrare devin mai mari, numărul de iterații crește, iar costurile se adună liniar

• Stratul de inginerie: Îți pierzi contextul și dreptul de decizie și, în cele din urmă, rămâi doar cu un sistem incontrolabil care „poate rula”

Lenea doi: Tipul care aruncă totul la grămadă

Când întâlnești un Bug, cum îl arunci la AI? Copiezi direct întregul console de erori cu Ctrl+A sau folosești direct @Codebase pentru a lăsa AI să-l găsească singur?

Aceasta se numește „aruncarea totului la grămadă”. Ești prea leneș să localizezi nucleul problemei, prea leneș să filtrezi fragmentele de cod cheie. Arunci 99% din informațiile nevalide (zgomot) și 1% din informațiile valabile (semnal) la AI.

AI este ca un amplificator.

• Îi dai o logică clară (semnal), îți amplifică înțelepciunea, consumă mai puțini Tokeni și are un efect bun.

• Îi dai confuzie și vaguitate, îți amplifică confuzia, Tokenii cresc vertiginos și produce gunoi.

III. Soluție: Cum să folosești AI eficient și să reduci consumul de Tokeni

Pentru a-ți păstra portofelul, cel mai important este să-ți păstrezi controlul ingineresc. Trebuie să schimbăm modul în care colaborăm cu AI.

1. Principiul contextului minim

Acesta este primul principiu al programării AI. Dă întotdeauna AI cel mai mic set de cod care corespunde problemei curente.

În Cursor, folosește bine acești operatori:

• @File: Citează doar fișierele relevante, nu întregul folder.

• Ctrl+L Selectează codul: Trimite doar cele 50 de rânduri de cod selectate de cursor la Chat, nu întregul fișier.

• @Docs: Pentru bibliotecile terțe, citează documentația în loc să o lași să ghicească.

Acesta este un SOP structurat și reutilizabil pe care îl folosesc adesea (dacă îl urmezi, Tokenii vor scădea vizibil):

Această frază înseamnă: Când colaborezi cu AI, acordă atenție eficienței și preciziei. Pașii specifici sunt următorii:

• Mai întâi definește obiectivul: spune-i AI pe scurt și concis problema curentă și rezultatul dorit, nu o lăsa să ghicească singură.

• Simplifică reproducerea problemei: dacă poți reproduce problema cu cea mai simplă metodă, nu folosi o metodă complexă, postează cel mai mic și mai important cod, nu arunca o grămadă de conținut irelevant.

• Furnizează informațiile minime necesare: dă doar 1-3 fișiere relevante, funcții cheie și primele câteva rânduri ale stivei de erori, nu informații complete.

• Cere să returnezi punctele de modificare: lasă AI să-ți spună doar unde să modifici, de ce să modifici, nu o lăsa să rescrie totul pe larg.

• În cele din urmă, verifică singur: fă cea mai simplă verificare pentru a te asigura că modificările nu afectează alte locuri.

Pe scurt, folosește cele mai puține și mai importante informații pentru a face AI să facă lucruri și păstrează controlul final și judecata.

2. De asemenea, cel mai important: gândește mai întâi, apoi Prompt, planifică mai întâi, apoi acționează

Înainte de a apăsa Enter, forțează-te să te oprești 10 secunde și pune-ți trei întrebări:

• Ce problemă rezolv? (Definește limitele)

• Ce module de bază implică această problemă? (Filtrează Contextul)

• Dacă aș scrie-o eu însumi, cum aș scrie-o? (Furnizează idei)

Tu ești 1, AI este 0 după el. Dacă 1 nu poate sta în picioare, oricât de mulți 0 ar fi după el, este doar un consum lipsit de sens.

Câteva cuvinte sincere

Povestea „un miliard de Tokeni pe zi” s-ar putea să nu se întâmple tuturor. Dar comportamentul de risipire a Tokenilor este experimentat de aproape fiecare programator care folosește programarea AI.

Deși AI face programarea mai ușoară, există încă un prag. Cei care știu cu adevărat să o folosească vor fi și mai puternici.

Înainte, codul tău prost scris doar îi „dezgusta” pe colegi. Acum, lenea ta se va transforma direct în numere pe factură, penalizându-te cu costuri vertiginoase.Așadar, nu fi un "șef absent". Fii un arhitect AI care gândește profund, se exprimă cu precizie și planifică înainte de a acționa. Aceasta este și cea mai mare ireemplasabilitate a noastră în această eră.