Mērķauditorija: Izstrādātāji, kuri izmanto AI programmēšanas rīkus (piemēram, Cursor, Windsurf, trae...) un tehniskie vadītāji, kuriem trūkst izpratnes par AI izmaksām.

Galvenā doma: Tokeni nav tikai vienkāršas norēķinu vienības, bet gan "uzmanības resurss" un "skaitļošanas jaudas valūta". Agentu režīma ļaunprātīga izmantošana un konteksta pārvaldības ignorēšana faktiski ir taktisks centīgums (ļaujot AI bezjēdzīgi rosīties), kas slēpj stratēģisku slinkumu (pašam nedomājot).

Jūsu "AI izdevumi" var būt lielāki par algu

Pirms dažām dienām es pārbaudīju savu Tokenu rēķinu. Redzot šo skaitli, es biju nedaudz pārsteigts: 10 miljoni Tokenu. Ņemiet vērā, ka tas nav mēneša patēriņš, bet gan vienas dienas.

Es domāju, ka tas ir ļoti absurdi. Vēlāk es publicēju īsu video par Tokenu aprēķināšanu.

Rezultātā komentāru sadaļa man parādīja, ko nozīmē "debesis virs debesīm".

Zemāk redzamais attēls ir ekrānuzņēmums no lietotāja "老K的日常" viena dienas 200 miljonu Tokenu patēriņa ieraksta:

Sākumā es domāju, ka tas varētu būt atsevišķs gadījums, bet, kad daudzi lietotāji atstāja komentārus, sakot, ka viņi katru dienu patērē 100 miljonus, es sapratu, ka tā ir ļoti izplatīta parādība.

Ko nozīmē 100 miljoni Tokenu? Ja mēs aprēķinām pēc "dažu galveno komerciālo modeļu" parastā norēķinu līmeņa (ievade/izvade tiek apmaksāta atsevišķi, un kopā aptuveni 10 USD / miljons Tokenu), tad šī diena ir sadedzinājusi 1000 USD. Vienā dienā sadedzina 7000 RMB. Daudzu jaunāko programmētāju mēneša alga varētu nebūt pietiekama, lai AI "domātu" šo vienu dienu.

(Piezīme: dažādiem modeļiem/piegādātājiem ir ļoti atšķirīgas cenas, un ievades un izvades vienības cenas bieži vien ir atšķirīgas. Šeit mērķis nav precīzi aprēķināt līdz decimāldaļām, bet gan vispirms izveidot "mēroga sajūtu".)

Ja vēlaties pats pārrēķināt, parasti ir šāda formula (ignorējot kešatmiņas/atlaides un citus īpašus noteikumus): Izmaksas ≈ (Ievades Tokeni / 1 000 000) × Cena_in + (Izvades Tokeni / 1 000 000) × Cena_out

Šī lieta ir pārāk pretrunā intuīcijai. Mēs vienmēr domājam, ka AI ir lēts, un OpenAI pat vēlas samazināt cenas. Bet kāpēc reālajā inženierijā Tokenu patēriņš eksplodē eksponenciāli?

Šodien es jūs dziļi iepazīstināšu ar loģiku, kas slēpjas aiz šī "Tokenu melnā cauruma", un to, kā mums apturēt zaudējumus.

I. Kāpēc Tokeni "eksponenciāli eksplodē"?

Daudziem brāļiem nav ne jausmas par Tokenu apjomu. Viņi domā: "Ak, vai tad tās nav tikai dažas koda daļas? Cik daudz var būt?"

1. Aprēķiniet skaidru rēķinu

Mēs vispirms izveidosim inženierijas ziņā pietiekamu kvantitatīvu uztveri. Vispirms pateiksim to stingri: Tokeni nav vārdu skaits, un tie nav arī rakstzīmju skaits. Tie ir modeļa teksta sadalīšanas "kodēšanas fragmenti", dažādiem modeļiem ir dažādi tokenizeri, tāpēc var dot tikai intervālu, nevis "visiem piemērotu" konstanti.

Šos skaitļus jūs varat uzskatīt par "mērlenti" (mērķis ir novērtēt apjomu, prognozēt izmaksas un pieņemt lēmumus par zaudējumu apturēšanu):

• 1 ķīniešu rakstzīme: parasti 1–2 Tokeni (bieži lietoti vārdi ir tuvāk 1, reti sastopami vārdi/kombinācijas vieglāk sasniedz 2–3)

• 1 angļu vārds: parasti apmēram 1,2–1,5 Tokeni (aptuvenam aprēķinam var izmantot arī 1,3)

• 1 koda rinda ≈ 10–50 Tokeni (ieskaitot atkāpes, komentārus, tipu deklarācijas)

• Vienkārša biznesa loģika ≈ 12–20 Tokeni

• Ar tipu anotācijām, interfeisu, JSDoc, 4 atstarpju atkāpēm ≈ 20–35 Tokeni

• Ar lielu skaitu importu / dekoratoru / komentāru ≈ 30–50+ Tokeni

• 1 avota fails (400–600 rindas, moderns TS/Java projekts) ≈ 4 000–24 000 Tokeni ir ļoti izplatīti (mediāna ≈ 12 000–18 000)

• 1 vidēja izmēra projekts (100–200 avota faili, tikai src/, neietverot node_modules/ / ģenerēto kodu)

• "Izlasīt" galveno pirmkodu "vienreiz" bieži vien sākas ar miljonu Tokenu

• Ja vēl ievietojat testus, konfigurācijas, skriptus, atkarību deklarācijas, žurnālus, tad nav nekas neparasts, ka tie sasniedz desmitiem miljonu Tokenu

Pašreizējie priekšgala projekti ir TypeScript, kas ir pilns ar sarežģītām interfeisa definīcijām; vai Java, kurā importēšana bieži vien aizņem desmitiem rindu. Šis "parauga kods" patiesībā ir Tokenu slepkava. Vidēja izmēra projektam, ja ir 100 faili, tikai ļaujot AI "izlasīt kodu vienreiz", ļoti iespējams, ka tiks iznīcināts 1 miljons Tokenu.

2. Tokenu "sniega bumbas" efekts

Visbriesmīgākais Tokenu patēriņš nav vienreizēja saruna, bet gan konteksta uzkrāšanās vairāku sarunu laikā.

LLM mehānisms ir bezstāvokļa. Lai AI atcerētos, ko teicāt iepriekšējā teikumā, sistēma parasti iepako un nosūta modelim "sistēmas uzvednes + vēsturiskās sarunas + jūsu citētos failus/koda fragmentus + rīku izsaukumu izvadi (piemēram, meklēšanas rezultātus, kļūdu žurnālus)". Jūs domājat, ka uzdevāt tikai vienu jautājumu, bet patiesībā jūs atkārtoti maksājat par "visu konteksta paketi".

• 1. kārta: nosūta 10 000 Tokenu, AI atbild ar 1000.

• 2. kārta: nosūta (10 000 + 1000 + jauns jautājums), AI atbild...

• 10. kārta: jūsu konteksts var būt uzpūties līdz 200 000 Tokenu.

Šajā laikā, pat ja jūs vienkārši uzdodat jautājumu "palīdziet man mainīt mainīgā nosaukumu", jūs patērējat 200 000 Tokenu maksu. Tāpēc jūs jūtat, ka neko nedarāt, bet rēķins strauji pieaug.

Vēl briesmīgāk ir tas, ka: Agentu režīms "aktīvi lasa failus". Jūs sakāt "palīdziet man optimizēt lietotāju moduli", tas var vispirms skenēt saistītos direktorijus, pēc tam izsekot atkarības, pēc tam izsekot konfigurācijas, pēc tam izsekot testus... Tas neslinko, tas "atbildīgi ievēro noklusējuma stratēģiju", un noklusējuma stratēģija bieži vien ir: vairāk lasīt, vairāk mēģināt, vairāk atkārtot.

II. Divi "slinkumi" iznīcina jūsu inženierijas spējas

Pēc komentāru sadaļas "simts miljonu brāļu" pārskatīšanas es atklāju, ka Tokenu straujā pieauguma sakne nav tikai AI patēriņa mehānisma problēma, bet arī cieši saistīta ar cilvēku slinkumu.

Zemāk ir divi tipiski "domāšanas slinkumi".

Slinkums viens: atbildības noveltājs

Vai jums arī ir šāda mentalitāte:

• "Šis vecais projekts ir pārāk haotisks, es slinkoju skatīties loģiku, vienkārši iemetīšu to AI."

• "Cursor ir izlaidis Agentu režīmu, lieliski, ļaujiet tam pašam labot kļūdas."

Tāpēc jūs iemetat visu src mapi Agentam un izsniedzat neskaidru norādījumu: "Palīdziet man optimizēt lietotāju moduli." Agents sāk darbu:

• Tas nolasa 50 failus (patērē 500 000).

• Tas atklāj, ka ir atsauce uz utils, un atkal nolasa utilītu klases (patērē 200 000).

• Tas mēģina modificēt, rodas kļūda, nolasa kļūdu žurnālus (patērē 100 000).

• Tas mēģina labot, atkal rodas kļūda...

Tas traki mēģina un kļūdās, traki patērējot Tokenus. Un jūs? Jūs ritinat tālruni un jūtaties patiešām efektīvs. Patiesība ir tāda, ka jūs apmaināt naudu pret "pseidoefektivitāti", radot kaudzi koda, kuru vēlāk nevarat uzturēt.

Profesionālāk sakot, šeit ir divi zaudējumu līmeņi:

• Izmaksu līmenis: palielinās ievades Tokeni, palielinās atkārtojumu skaits, izmaksas lineāri summējas

• Inženierijas līmenis: jūs zaudējat kontekstu un lēmumu pieņemšanas tiesības, un beigās paliek tikai "darbojas un labi" nekontrolējama sistēma

Slinkums divi: viss vienā maisā

Kad rodas kļūda, kā jūs to iemetat AI? Vai jūs tieši kopējat visu kļūdu konsoli ar Ctrl+A, vai arī ļaujat AI pašam atrast ar @Codebase?

To sauc par "visu vienā maisā". Jūs slinkojat noteikt problēmas būtību, slinkojat atlasīt galvenos koda fragmentus. Jūs iemetat AI 99% nederīgas informācijas (trokšņa) un 1% derīgas informācijas (signāla).

AI ir kā pastiprinātājs.

• Jūs dodat viņam skaidru loģiku (signālu), tas pastiprina jūsu gudrību, Tokeni tiek izmantoti mazāk, un efekts ir labs.

• Jūs dodat viņam haosu un neskaidrības, tas pastiprina jūsu haosu, Tokeni strauji pieaug, un tiek radīti atkritumi.

III. Risinājums: kā efektīvi izmantot AI, samazināt Tokenu patēriņu

Lai aizsargātu savu maku, vēl svarīgāk ir aizsargāt savu inženierijas kontroli, mums ir jāmaina sadarbības modelis ar AI.

1. Minimālā konteksta princips

Tas ir AI programmēšanas pirmais princips. Vienmēr dodiet AI tikai minimālo koda kopu, kas atbilst pašreizējai problēmai.

Programmā Cursor labi izmantojiet šos operatorus:

• @File: citējiet tikai saistītos failus, nevis visu mapi.

• Ctrl+L** Atlasiet kodu**: nosūtiet tērzēšanai tikai 50 koda rindas, kuras ir atlasītas ar kursoru, nevis visu failu.

• @Docs: trešo pušu bibliotēkām citējiet dokumentāciju, nevis ļaujiet tai minēt.

Šis ir strukturēts, atkārtoti izmantojams SOP, ko es bieži izmantoju (ja jūs to darāt, Tokeni redzami samazināsies):

Šis teikums nozīmē: sadarbojoties ar AI, jāpievērš uzmanība efektivitātei un precizitātei. Konkrēti pasākumi ir šādi:

• Vispirms noskaidrojiet mērķi: īsi un kodolīgi pastāstiet AI par pašreizējo problēmu un vēlamo rezultātu, neļaujiet tai pašai minēt.

• Vienkāršojiet problēmas atkārtošanu: ja problēmu var atkārtot ar vienkāršāko metodi, neizmantojiet sarežģītu metodi, ielīmējiet minimālo un svarīgāko kodu, nekrājiet lielu daudzumu nesaistīta satura.

• Nodrošiniet minimālo nepieciešamo informāciju: dodiet tikai 1–3 saistītus failus, galvenās funkcijas un kļūdu steka pirmās rindas, nevis visu informāciju.

• Pieprasiet atgriezt izmaiņu punktus: ļaujiet AI pastāstīt tikai to, kur mainīt, kāpēc mainīt, neļaujiet tai plaši pārrakstīt visu kodu.

• Visbeidzot, jūs pats pārbaudiet: veiciet visvienkāršāko validāciju, lai pārliecinātos, ka izmaiņas neietekmē citas vietas.

Īsāk sakot, izmantojiet minimālo un svarīgāko informāciju, lai AI darbotos, un saglabājiet galīgo kontroli un spriedumu.

2. Vissvarīgākais: vispirms domājiet, pēc tam Prompt, vispirms plānojiet, pēc tam rīkojieties

Pirms nospiežat Enter, piespiediet sevi apstāties uz 10 sekundēm un uzdodiet sev trīs jautājumus:

• Kādu problēmu es risinu? (definējiet robežas)

• Kurus galvenos moduļus šī problēma ietekmē? (atlasiet kontekstu)

• Ja es rakstītu pats, kā es to rakstītu? (nodrošiniet idejas)

Jūs esat 1, AI ir 0 aiz tā. Ja 1 nevar nostāties, tad, neatkarīgi no tā, cik daudz 0 ir aiz tā, tas ir tikai bezjēdzīgs patēriņš.

Daži sirsnīgi vārdi

Stāsts par "simts miljoniem Tokenu dienā" var nenotikt ar katru. Bet Tokenu izšķērdēšana ir uzvedība, ko piedzīvo gandrīz katrs programmētājs, kurš izmanto AI programmēšanu.

Lai gan AI ir padarījis programmēšanu vienkāršāku, joprojām pastāv slieksnis. Tikai tie, kas patiešām zina, kā to izmantot, var gūt papildu labumu.

Agrāk jūsu sliktais kods tikai "atbaidīja" kolēģus. Tagad jūsu slinkums tieši pārvērtīsies par skaitļiem rēķinā, sodot sevi ar strauji augošām izmaksām.Tātad, neesi "rokas mazgātājs". Esi AI arhitekts, kas dziļi domā, precīzi izsakās un plāno pirms rīkojas. Tas ir arī mūsu lielākais neaizstājamības faktors šajā laikmetā.