Cieľová skupina: Vývojári, ktorí používajú nástroje na programovanie s AI (ako Cursor, Windsurf, trae...) a technickí manažéri, ktorí si neuvedomujú náklady na AI.

Kľúčová myšlienka: Token nie je len jednoduchá účtovná jednotka, ale aj „zdroj pozornosti“ a „výpočtová mena“. Zneužívanie režimu Agent, ignorovanie správy kontextu, v skutočnosti zakrýva strategickú lenivosť (nesamostatné myslenie) taktickou usilovnosťou (necháva AI bezcieľne tápať).

Vaše „výdavky na AI“ môžu byť vyššie ako plat

Pred pár dňami som sa pozrel na svoj účet za tokeny. Keď som videl to číslo, bol som trochu prekvapený: 10 miliónov tokenov. Upozorňujem, že to nie je mesačná spotreba, ale denná.

Myslel som si, že som na tom zle. Neskôr som zverejnil krátke video o výpočte tokenov.

Výsledkom bolo, že komentáre mi ukázali, čo znamená „nebo nad nebom“.

Nasledujúci obrázok je snímka obrazovky záznamu spotreby dvoch miliárd tokenov za deň od používateľa siete „Old K's Daily“:

Spočiatku som si myslel, že ide o ojedinelý prípad, ale keď mi mnohí používatelia siete napísali, že denne spotrebujú 100 miliónov, pochopil som, že ide o veľmi bežný jav.

Čo znamená sto miliónov tokenov? Ak to vypočítame podľa bežnej úrovne účtovania „niektorých hlavných komerčných modelov“ (vstup/výstup sa účtuje samostatne, spolu zhruba 10 USD / milión tokenov), potom sa za deň spáli 1000 dolárov. Za deň sa spáli 7000 RMB. Plat mnohých junior programátorov za mesiac nemusí stačiť na to, aby AI „premýšľala“ jeden deň.

(Poznámka: Cenové rozdiely medzi rôznymi modelmi/dodávateľmi sú obrovské a jednotkové ceny vstupu a výstupu sa tiež často líšia. Cieľom tu nie je presný výpočet na dve desatinné miesta, ale najprv vytvoriť „pocit rozsahu“.)

Ak si to chcete sami prepočítať, zvyčajne existuje tento vzorec (ignorujte špeciálne pravidlá, ako je ukladanie do vyrovnávacej pamäte/zľavy): Náklady ≈ (vstupné tokeny / 1 000 000) × jednotková cena_in + (výstupné tokeny / 1 000 000) × jednotková cena_out

Táto vec je príliš protiintuitívna. Vždy si myslíme, že AI je lacná, OpenAI dokonca znižuje ceny. Ale prečo v skutočnom inžinierstve spotreba tokenov exponenciálne exploduje?

Dnes s vami hlboko rozoberieme logiku za touto „tokenovou čiernou dierou“ a ako môžeme zastaviť straty.

I. Prečo tokeny „exponenciálne explodujú“?

Mnohí bratia nemajú o objeme tokenov vôbec žiadnu predstavu. Myslia si: „Ach, nie je to len posielanie niekoľkých riadkov kódu? Koľko toho môže byť?“

1. Urobte si jasno v účtoch

Najprv si vytvoríme kvantitatívne vnímanie, ktoré je dostatočné pre inžinierstvo. Najprv to povedzme priamo: Token nie je počet slov, ani počet znakov. Je to „kódový fragment“, ktorý model rozdelí z textu. Rôzne modely používajú rôzne tokenizátory, takže môžeme dať len rozsah, nie konštantu, ktorá je „vhodná pre všetky prípady“.

Nasledujúce čísla berte ako „odhadovacie pravítka“ (cieľom je posúdiť rozsah, odhadnúť náklady a urobiť rozhodnutia o zastavení strát):

• 1 čínsky znak: bežne 1–2 tokeny (vysokofrekvenčné znaky sa viac blížia k 1, zriedkavé znaky/kombinácie sa ľahšie dostanú na 2–3)

• 1 anglické slovo: bežne okolo 1,2–1,5 tokenov (pre hrubý odhad môžete použiť aj 1,3)

• 1 riadok kódu ≈ 10–50 tokenov (vrátane odsadenia, komentárov, deklarácie typu)

• Stručná obchodná logika ≈ 12–20 tokenov

• S anotáciami typu, rozhraním, JSDoc, 4-medzerovým odsadením ≈ 20–35 tokenov

• S veľkým množstvom importov / dekorátorov / komentárov ≈ 30–50+ tokenov

• 1 zdrojový súbor (400–600 riadkov, moderný projekt TS/Java) ≈ 4 000 – 24 000 tokenov je veľmi bežné (medián ≈ 12 000 – 18 000)

• 1 stredne veľký projekt (100–200 zdrojových súborov, počíta sa len src/, bez node_modules/ / generovaného kódu)

• „Prečítanie“ základného zdrojového kódu „raz“ často začína miliónom tokenov

• Ak sa do toho pridajú testy, konfigurácie, skripty, deklarácie závislostí a protokoly, nie je nezvyčajné, že to dosiahne desiatky miliónov tokenov

Súčasné front-end projekty sú TypeScript, plné zložitých definícií rozhraní; alebo Java, ktorá má desiatky riadkov importov. Tento „štandardný kód“ je v skutočnosti zabijak tokenov. Ak má stredne veľký projekt 100 súborov, len to, že AI „prečíta kód raz“, môže priamo zničiť 1 milión tokenov.

2. Efekt „snehovej gule“ tokenov

Najstrašidelnejšia vec na spotrebe tokenov nie je jednorazová konverzácia, ale kumulácia kontextu vo viacerých kolách konverzácie.

Mechanizmus LLM je bezstavový. Aby si AI pamätala, čo ste povedali v predchádzajúcej vete, systém zvyčajne zabalí a pošle modelu „systémovú výzvu + históriu konverzácie + úryvky súborov/kódu, ktoré ste citovali + výstup volania nástroja (napríklad výsledky vyhľadávania, chybové protokoly)“. Myslíte si, že ste sa opýtali len jednu vetu, ale v skutočnosti opakovane platíte za „celý kontextový balík“.

• 1. kolo: Odoslaných 10 000 tokenov, AI odpovie 1 000.

• 2. kolo: Odoslaných (10 000 + 1 000 + nová otázka), AI odpovie...

• 10. kolo: Váš kontext sa mohol nafúknuť na 200 000 tokenov.

V tomto okamihu, aj keď sa opýtate len „pomôž mi zmeniť názov premennej“, spotrebujete poplatok 200 000 tokenov. To je dôvod, prečo máte pocit, že ste nič neurobili, ale váš účet prudko stúpa.

Čo je ešte horšie: Režim Agent „aktívne číta súbory“. Ak poviete „pomôž mi optimalizovať modul používateľa“, môže najprv prejsť súvisiace adresáre, potom prejsť na závislosti, potom na konfigurácie a potom na testy... Nerobí to preto, že by bol lenivý, ale preto, že „zodpovedne plní predvolenú stratégiu“ a predvolená stratégia je často: viac čítať, viac skúšať, viac iterovať.

II. Dva druhy „lenivosti“ ničia vaše inžinierske schopnosti

Po preskúmaní tých niekoľkých „miliardárov“ v sekcii komentárov som zistil, že koreň prudkého nárastu tokenov nespočíva len v probléme mechanizmu spotreby AI, ale aj v lenivosti ľudí.

Existujú dva typické druhy „myšlienkovej lenivosti“.

Lenivosť 1: Typ „zbav sa zodpovednosti“

Máte aj vy takúto mentalitu?

• „Tento starý projekt je príliš chaotický, nechce sa mi pozerať na logiku, nechám to priamo na AI.“

• „Cursor vydal režim Agent, to je skvelé, nech si sám opraví chyby.“

A tak hodíte celú zložku src agentovi a vydáte nejasný príkaz: „Pomôž mi optimalizovať modul používateľa.“ Agent začne pracovať:

• Načíta 50 súborov (spotrebuje 500 000).

• Zistí, že odkazuje na utils, a ide čítať triedy nástrojov (spotrebuje 200 000).

• Pokúsi sa o zmenu, vyskytne sa chyba, prečíta chybový protokol (spotrebuje 100 000).

• Pokúsi sa o opravu, opäť sa vyskytne chyba...

Šialene skúša a robí chyby, šialene spotrebúva tokeny. A čo vy? Prezeráte si telefón a myslíte si, že ste naozaj efektívni. Pravda je: „Pseudoefektívnosť“, ktorú ste si kúpili za peniaze, vytvorila hromadu kódu, ktorý neskôr nemôžete udržiavať.

Povedané odbornejšie, existujú dve vrstvy strát:

• Nákladová vrstva: Zväčšuje sa vstupný token, zvyšuje sa počet iterácií a náklady sa lineárne sčítavajú

• Inžinierska vrstva: Stratíte kontext a rozhodovaciu právomoc a nakoniec vám zostane len nekontrolovateľný systém, ktorý „funguje“.

Lenivosť 2: Typ „všetko zmiešané“

Ako odovzdávate chybu AI? Kopírujete priamo Ctrl+A celú chybovú konzolu alebo necháte AI, aby si ju sama našla pomocou @Codebase?

To sa nazýva „všetko zmiešané“. Nechce sa vám nájsť jadro problému, nechce sa vám filtrovať kľúčové úryvky kódu. Hodíte AI 99 % neplatných informácií (šumu) a 1 % platných informácií (signálu).

AI je ako zosilňovač.

• Ak mu dáte jasnú logiku (signál), zosilní vašu múdrosť, spotrebuje sa menej tokenov a efekt je dobrý.

• Ak mu dáte zmätok a nejasnosti, zosilní váš zmätok, tokeny prudko stúpajú a vytvára odpad.

III. Riešenie: Ako efektívne používať AI a znížiť spotrebu tokenov

Ak chcete chrániť svoju peňaženku, dôležitejšie je chrániť svoju inžiniersku kontrolu, musíme zmeniť náš režim spolupráce s AI.

1. Princíp minimálneho kontextu

Toto je prvá zásada programovania s AI. Vždy dajte AI minimálnu množinu kódu, ktorá zodpovedá aktuálnemu problému.

V Cursore dobre využívajte tieto operátory:

• @File: Odkazujte sa len na súvisiace súbory, nie na celé priečinky.

• Ctrl+L Vyberte kód: Pošlite chatu len 50 riadkov kódu, ktoré kurzor vybral, nie celý súbor.

• @Docs: Pre knižnice tretích strán citujte dokumentáciu namiesto toho, aby ste ju nechali hádať.

Toto je štruktúrovaný, opakovane použiteľný SOP, ktorý často používam (ak to urobíte, tokeny viditeľne klesnú):

Táto veta znamená: Pri spolupráci s AI dávajte pozor na efektivitu a presnosť. Konkrétne postupy sú nasledovné:

• Najprv si ujasnite cieľ: Stručne a jasne povedzte AI aktuálny problém a požadovaný výsledok, nenechajte ju hádať.

• Zjednodušte reprodukciu problému: Ak môžete použiť najjednoduchšiu metódu na reprodukciu problému, nepoužívajte zložitú metódu, prilepte najmenšie a najdôležitejšie riadky kódu, nehromadte veľké množstvo nesúvisiaceho obsahu.

• Poskytnite minimálne potrebné informácie: Stačí uviesť 1-3 súvisiace súbory, kľúčové funkcie a prvých niekoľko riadkov zásobníka chýb, nie všetky informácie.

• Požadujte vrátenie bodov úpravy: Nechajte AI, aby vám povedala len to, čo sa zmenilo a prečo sa to zmenilo, nenechajte ju rozsiahlo prepisovať celý kód.

• Nakoniec to sami skontrolujte: Urobte najstručnejšie overenie, aby ste sa uistili, že zmena neovplyvnila iné miesta.

Stručne povedané, použite najmenšie a najdôležitejšie informácie na to, aby AI robila veci, a ponechajte si konečnú kontrolu a úsudok.

2. A čo je najdôležitejšie: Najprv premýšľajte, potom zadajte výzvu, najprv plánujte, potom konajte

Pred stlačením klávesu Enter sa prinúťte na 10 sekúnd zastaviť a položte si tri otázky:

• Aký problém riešim? (Definujte hranice)

• Ktoré kľúčové moduly sa týkajú tohto problému? (Filtrujte kontext)

• Ako by som to napísal, keby som to písal sám? (Poskytnite nápady)

Vy ste 1, AI je 0 za vami. Ak 1 nestojí, potom aj keby bolo za ňou viac 0, je to len nezmyselná spotreba.

Pár úprimných slov

Príbeh o „100 miliónoch tokenov za deň“ sa nemusí stať každému. Ale správanie pri plytvaní tokenmi zažije takmer každý programátor, ktorý používa programovanie s AI.

AI síce uľahčuje programovanie, ale stále existujú prekážky. Tí, ktorí to naozaj vedia používať, budú mať krídla.

Predtým váš zlý kód len „znechutil“ kolegov. Teraz sa vaša lenivosť priamo premení na čísla na účte a potrestá vás prudko rastúcimi nákladmi. Takže nebuďte "pasívny manažér". Buďte AI architekt, ktorý hlboko premýšľa, presne sa vyjadruje a koná až po plánovaní. To je tiež naša najväčšia nenahraditeľnosť v tejto dobe.