Målgrupp: Utvecklare som använder AI-programmeringsverktyg (som Cursor, Windsurf, trae...) och tekniska chefer som saknar insikt i AI-kostnader.

Kärnargument: Token är inte bara en enkel faktureringsenhet, utan en "uppmärksamhetsresurs" och en "beräkningsvaluta". Missbruk av Agent-läget och ignorering av kontexthantering är i själva verket att dölja strategisk lathet (att inte tänka själv) med taktisk flit (låta AI göra meningslösa saker).

Dina "AI-utgifter" kan vara högre än din lön

För några dagar sedan kollade jag min Token-räkning. När jag såg siffran blev jag lite förvånad: 10 miljoner Token. Observera att detta inte är en månadsförbrukning, utan en dag.

Jag trodde att det var absurt. Senare publicerade jag en kort video om Token-beräkning.

Resultatet blev att kommentarsfältet visade mig vad "himlen är gränsen" betyder.

Bilden nedan är en skärmdump av användaren "老K的日常"s förbrukningsrekord på tvåhundra miljoner Token på en dag:

Först trodde jag att det var ett enskilt fall, men när många användare kommenterade att de förbrukade 100 miljoner per dag förstod jag att det var ett mycket vanligt fenomen.

Vad betyder hundra miljoner Token? Om vi räknar med den vanliga faktureringsnivån för "vissa vanliga kommersiella modeller" (separat fakturering för input/output, grovt uppskattat till 10 USD / miljon Token), bränns 1000 dollar på en dag. 7000 RMB bränns på en dag. Många juniorprogrammerares månadslön kanske inte räcker för att AI ska "tänka" den här dagen.

(Anmärkning: Priserna varierar kraftigt mellan olika modeller/leverantörer, och priserna för input och output är ofta olika. Syftet här är inte att räkna exakt till andra decimalen, utan att först etablera en känsla för "storleksordningen".)

Om du vill beräkna själv är det i allmänhet denna formel (ignorera cache/rabatter och andra specialregler): Kostnad ≈ (InputToken / 1 000 000) × Pris_in + (OutputToken / 1 000 000) × Pris_ut

Det här är för kontraintuitivt. Vi tycker alltid att AI är billigt, och OpenAI sänker till och med priserna. Men varför exploderar Token-förbrukningen exponentiellt i praktiska projekt?

Idag tar jag dig med på en djupgående analys av logiken bakom detta "Token-svarta hål" och hur vi kan stoppa förlusterna.

1. Varför "exploderar" Token exponentiellt?

Många bröder har ingen aning om Token-storleken. De tänker: "Åh, är det inte bara några rader kod? Hur mycket kan det vara?"

1. Räkna ut det

Vi ska först etablera en kvantitativ känsla som är tillräcklig för tekniska ändamål. Låt oss vara lite dogmatiska: Token är inte antalet ord, och inte heller antalet tecken. Det är "kodningsfragment" som modellen delar upp texten i. Olika modeller använder olika tokenizer, så vi kan bara ge intervall, inte en konstant som är "lämplig för alla situationer".

Du kan betrakta följande siffror som en "uppskattningsskala" (syftet är att bedöma storleksordningen, uppskatta kostnader och fatta beslut om att stoppa förluster):

• 1 kinesiskt tecken: Vanligtvis 1–2 Token (vanliga tecken närmare 1, ovanliga tecken/kombinationer lättare 2–3)

• 1 engelskt ord: Vanligtvis cirka 1,2–1,5 Token (grov uppskattning med 1,3 är också ok)

• 1 rad kod ≈ 10–50 Token (inklusive indrag, kommentarer, typdeklarationer)

• Enkel affärslogik ≈ 12–20 Token

• Med typannoteringar, interface, JSDoc, 4-mellanslagsindrag ≈ 20–35 Token

• Med massor av import / dekoratörer / kommentarer ≈ 30–50+ Token

• 1 källfil (400–600 rader, moderna TS/Java-projekt) ≈ 4 000–24 000 Token är mycket vanligt (median ≈ 12 000–18 000)

• 1 medelstort projekt (100–200 källfiler, endast src/, exklusive node_modules/ / genererad kod)

• Att "läsa igenom" kärnkällkoden "en gång" börjar ofta med miljoner Token

• Om du lägger till tester, konfigurationer, skript, beroendedeklarationer och loggar är det inte ovanligt med tiotals miljoner Token

Nuvarande frontend-projekt är alla TypeScript, fulla av komplexa Interface-definitioner; eller Java, med dussintals rader av Import. Dessa "standardkoder" är faktiskt Token-mördare. Om ett medelstort projekt har 100 filer kan det direkt döda 1 miljon Token bara genom att låta AI "läsa koden en gång".

2. Token-snöbollseffekten

Det mest skrämmande med Token-förbrukning är inte enstaka konversationer, utan ackumuleringen av kontext i flera konversationer.

LLM:s mekanism är tillståndslös. För att få AI att komma ihåg vad du sa i föregående mening, paketerar systemet vanligtvis "systemprompt + historiska konversationer + fil-/kodavsnitt du refererar till + verktygsanropsutdata (t.ex. sökresultat, felloggar)" tillsammans och skickar det till modellen. Du tror att du bara ställde en fråga, men i själva verket betalar du upprepade gånger för "hela kontextpaketet".

• Omgång 1: Skicka 10 000 Token, AI svarar med 1 000.

• Omgång 2: Skicka (10 000 + 1 000 + ny fråga), AI svarar...

• Omgång 10: Din kontext kan ha svällt upp till 200 000 Token.

Vid den här tiden, även om du bara ställer frågan "Hjälp mig att ändra ett variabelnamn", förbrukar du 200 000 Token. Det är därför du känner att du inte har gjort något, men räkningen skjuter i höjden.

Ännu värre är att: Agent-läget "läser aktivt filer". Du säger "Hjälp mig att optimera användarmodulen", den kanske först skannar igenom relevanta kataloger, sedan spårar beroenden, sedan spårar konfigurationer, sedan spårar tester... Den är inte lat, den "gör sitt bästa enligt standardstrategin", och standardstrategin är ofta: läs mer, prova mer, iterera mer.

2. Två typer av "lathet" förstör din tekniska förmåga

Efter att ha granskat kommentarerna från de "hundra miljoner bröderna" fann jag att roten till den kraftiga ökningen av Token inte bara är AI:s förbrukningsmekanism, utan också relaterad till människors lathet.

Det finns två typiska typer av "tankelathet" nedan.

Lathet 1: Handskakningstyp

Har du också denna mentalitet:

• "Det här gamla projektet är för rörigt, jag orkar inte titta på logiken, jag ger det direkt till AI."

• "Cursor har släppt Agent-läget, bra, låt det fixa buggarna själv."

Så du slänger hela src-mappen till Agent och ger en vag instruktion: "Hjälp mig att optimera användarmodulen." Agent börjar arbeta:

• Den läser 50 filer (förbrukar 500 000).

• Den upptäcker att utils refereras och läser verktygsklasserna (förbrukar 200 000).

• Den försöker ändra, ett fel uppstår och felloggen läses (förbrukar 100 000).

• Den försöker fixa, och ett annat fel uppstår...

Den försöker och misslyckas frenetiskt och förbrukar Token frenetiskt. Och du? Du scrollar på din telefon och känner att du är riktigt effektiv. Sanningen är: du byter ut "pseudo-effektivitet" mot pengar och producerar en massa kod som du inte kan underhålla senare.

Mer professionellt sett finns det två lager av förluster här:

• Kostnadslager: Input Token blir större, antalet iterationer ökar och kostnaderna läggs på linjärt

• Tekniskt lager: Du förlorar kontext och beslutsfattande, och till slut har du bara ett okontrollerbart system som "bara fungerar"

Lathet 2: Allt i ett-typ

När du stöter på en bugg, hur ger du den till AI? Kopierar du direkt hela felkonsolen med Ctrl+A, eller låter du AI hitta den själv med @Codebase?

Detta kallas "allt i ett". Du orkar inte lokalisera problemets kärna, du orkar inte filtrera bort viktiga kodavsnitt. Du slänger 99 % av den ogiltiga informationen (brus) och 1 % av den giltiga informationen (signal) till AI.

AI är som en förstärkare.

• Du ger den tydlig logik (signal), den förstärker din visdom, Token används mindre och effekten är bra.

• Du ger den förvirring och vaghet, den förstärker din förvirring, Token skjuter i höjden och producerar skräp.

3. Lösning: Hur man använder AI effektivt och minskar Token-förbrukningen

För att skydda din plånbok är det viktigare att skydda din tekniska kontroll. Vi måste ändra vårt samarbetsläge med AI.

1. Principen om minsta kontext

Detta är den första principen för AI-programmering. Ge alltid AI den minsta koduppsättningen som motsvarar det aktuella problemet.

I Cursor, använd dessa operatorer väl:

• @File: Referera bara till relevanta filer, inte hela mappen.

• Ctrl+L** Välj kod**: Skicka bara de 50 rader kod som markeras av markören till Chat, inte hela filen.

• @Docs: För tredjepartsbibliotek, referera till dokumentationen istället för att låta den gissa.

Detta är en strukturerad, återanvändbar SOP som jag ofta använder (om du gör det kommer Token att sjunka synbart):

Denna passage betyder: När du samarbetar med AI, var uppmärksam på effektivitet och precision. Specifika metoder är följande:

• Definiera först målet: Berätta kortfattat för AI om det aktuella problemet och det önskade resultatet, låt den inte gissa själv.

• Förenkla problemreproduktionen: Använd den enklaste metoden för att återskapa problemet istället för en komplex metod, klistra in den minsta och viktigaste koden, stapla inte upp en massa irrelevant innehåll.

• Ange minsta nödvändiga information: Ge bara de relevanta 1-3 filerna, viktiga funktioner och de första raderna i felstacken, inte all information.

• Kräv att ändringspunkter returneras: Låt AI bara berätta var du ska ändra och varför du ska ändra, låt den inte skriva om all kod i stor utsträckning.

• Slutligen, kontrollera själv: Gör den kortaste verifieringen för att säkerställa att ändringen inte påverkar andra platser.

Kort sagt, använd den minsta och viktigaste informationen för att få AI att göra saker och behåll den slutliga kontrollen och bedömningen.

2. Också det viktigaste: Tänk först, prompta sedan, planera först, agera sedan

Innan du trycker på Enter, tvinga dig själv att pausa i 10 sekunder och ställ dig själv tre frågor:

• Vilket problem löser jag? (Definiera gränser)

• Vilka kärnmoduler är involverade i detta problem? (Filtrera kontext)

• Om jag skulle skriva det själv, hur skulle jag skriva det? (Ge idéer)

Du är 1, AI är 0:orna efter. Om 1 inte kan stå, är de efterföljande 0:orna bara meningslös förbrukning.

Några uppriktiga ord

Historien om "en miljard Token per dag" kanske inte händer alla. Men beteendet att slösa Token upplevs av nästan alla programmerare som använder AI-programmering.

Även om AI gör programmering enklare, finns det fortfarande trösklar. De som verkligen vet hur man använder det kommer att vara ännu mer effektiva.

Tidigare skulle din dåliga kod bara "äckla" kollegor. Nu kommer din lathet direkt att bli siffror på räkningen och straffa dig själv med stigande kostnader.Så, var inte en "passiv chef". Var en AI-arkitekt som tänker djupt, uttrycker sig precist och planerar innan du agerar. Det är också vår största oersättlighet i denna tid.