Brenner du én milliard tokens om dagen? AI-regningen til programmerere straffer de «late»

Målgruppe: Utviklere som bruker AI-verktøy for programmering (som Cursor, Windsurf, trae...), og teknologiledere som mangler bevissthet om AI-kostnader.

Kjernepoeng: Tokens er ikke bare en enkel faktureringsenhet, men en «oppmerksomhetsressurs» og «regnekraftvaluta». Å misbruke agent-modus og overse konteksthåndtering, er egentlig å dekke over strategisk latskap (å ikke tenke selv) med taktisk flid (la AI gjøre kaos).

Din «AI-utgift» kan være høyere enn lønnen

For noen dager siden sjekket jeg token-regningen min. Da jeg så tallet, ble jeg overrasket: 10 millioner tokens. Merk, dette er ikke forbruket for en måned, men for én dag.

Jeg trodde dette var ekstremt. Så la jeg ut en kortvideo om token-beregning.

Resultatet var at kommentarfeltet viste meg hva som betyr «det finnes alltid noen som er bedre».

Bildet under er et skjermbilde av nettbrukeren «老K的日常» sitt token-forbruk på 200 millioner på én dag:

Først trodde jeg det kanskje var et enkeltilfelle, men da mange nettbrukere kommenterte at de forbrukte 100 millioner om dagen, skjønte jeg at dette er et utbredt fenomen.

Hva betyr én milliard tokens? Hvis vi regner med «vanlige faktureringsnivåer for noen kommersielle modeller» (input/output faktureres separat, til sammen grovt estimert til 10 dollar per million tokens), så brenner det 1000 dollar på én dag. 7000 kinesiske yuan brent på én dag. Mange juniorprogrammereres månedslønn er kanskje ikke nok til at AI kan «tenke» i løpet av denne ene dagen.

(Merknad: Prisforskjellene mellom ulike modeller/leverandører er store, og enhetsprisene for input og output er ofte forskjellige. Hensikten her er ikke å regne nøyaktig til to desimaler, men først å etablere en «følelse for størrelsesorden».)

Hvis du vil regne ut selv, er det vanligvis denne formelen (ignorerer spesielle regler som caching/rabatter): kostnad ≈ (input-tokens / 1 000 000) × pris_in + (output-tokens / 1 000 000) × pris_out

Dette er så kontraintuitivt. Vi føler alltid at AI er billig, OpenAI skal til og med senke prisene. Men hvorfor blir token-forbruket eksplosivt i eksponentiell grad i praktisk utvikling?

I dag tar vi en dyp dykk i logikken bak dette «token-svarte hullet», og hvordan vi kan begrense tapet.

1. Hvorfor «eksploderer» tokens eksponentielt?

Mange har ingen anelse om størrelsen på tokens. De tenker: «Å, det er bare å sende noen kodelinjer, vel? Hvor mye kan det være?»

1. Regn ut en klar konto

La oss først etablere en kvantitativ forståelse som er tilstrekkelig for utvikling. La oss si det klart: Tokens er ikke antall ord, og ikke antall tegn. Det er «kodefragmenter» etter at modellen har delt opp teksten, og ulike modeller bruker ulike tokenizers, så vi kan bare gi et intervall, ikke en «universell konstant».

Tallene nedenfor kan du bruke som en «estimatskala» (målet er å bedømme størrelsesorden, estimere kostnader og ta beslutninger for tapbegrensning):

• 1 kinesisk skrifttegn: Vanligvis 1–2 tokens (høyfrekvente tegn nærmere 1, sjeldne tegn/kombinasjoner lettere 2–3)
• 1 engelsk ord: Vanligvis rundt 1,2–1,5 tokens (grovt estimat med 1,3 fungerer også)
• 1 kodelinje ≈ 10–50 tokens (inkludert innrykk, kommentarer, typedeklarasjoner)
  • Konsis forretningslogikk ≈ 12–20 tokens
  • Med typeannotasjoner, interface, JSDoc, 4-mellomroms innrykk ≈ 20–35 tokens
  • Med mange import / dekoratører / kommentarer ≈ 30–50+ tokens
• 1 kildefil (400–600 linjer, moderne TS/Java-prosjekt) ≈ 4000–24 000 tokens er vanlig (median ≈ 12 000–18 000)
• 1 mellomstort prosjekt (100–200 kildefiler, bare src/, uten node_modules/ / generert kode)
  • Å «lese gjennom» kjernekilden er ofte start på millioner av tokens
  • Hvis du også putter inn tester, konfigurasjon, skript, avhengighetsdeklarasjoner, logger, er det ikke uvanlig med over 10 millioner tokens

Moderne frontend-prosjekter bruker TypeScript, fulle av komplekse interface-definisjoner; eller Java, med titalls linjer med import. Disse «mal-kodene» er egentlig token-drepere. Et mellomstort prosjekt med 100 filer, bare for å la AI «lese koden en gang», kan fort bruke 1 million tokens.

2. Tokens «snøball-effekt»

Det skumleste med token-forbruk er ikke enkeltdialoger, men akkumulering av kontekst i flerdialoger.

LLM-mekanismen er tilstandsløs. For at AI skal huske hva du sa forrige gang, sender systemet vanligvis «systemprompt + dialoghistorikk + filer/kodesnutter du refererer til + verktøyutdata (f.eks. søkeresultater, feillogger)» sammen til modellen. Du tror du bare stilte ett spørsmål, men du betaler faktisk gjentatte ganger for «hele kontekstpakken».

• Runde 1: Sender 10 000 tokens, AI svarer med 1000.
• Runde 2: Sender (10 000 + 1000 + nytt spørsmål), AI svarer...
• Runde 10: Din kontekst kan ha vokst til 200 000 tokens.

Da, selv om du bare spør «hjelp meg å endre et variabelnavn», koster det deg 200 000 tokens. Derfor føler du at du ikke gjør noe, men regningen stiger.

Enda verre: Agent-modus «leser filer aktivt». Med én setning «hjelp meg å optimalisere brukermodulen», kan den først skanne relevante kataloger, deretter følge avhengigheter, konfigurasjon, tester... Den er ikke lat, den «gjør sin plikt etter standardstrategi», og standardstrategien er ofte: les mye, prøv mye, iterer mye.

2. To typer «latskap» som ødelegger din utviklingsevne

Etter å ha gått gjennom de «milliard-gutta» i kommentarfeltet, fant jeg at roten til token-eksplosjonen ikke bare er AI-forbruksmekanismen, men også menneskers latskap.

Her er to typiske «tenkelatskap».

Latskap én: Typen som gir fra seg ansvaret

Har du også denne holdningen:

• «Dette gamle prosjektet er så rotete, jeg gidder ikke se på logikken, bare gi det til AI.»
• «Cursor har agent-modus, flott, la den fikse feilene selv.»

Så kaster du hele src-mappen til agenten, med et vagt instruks: «Hjelp meg å optimalisere brukermodulen.» Agenten begynner å jobbe:

• Den leser 50 filer (forbruk 500 000).
• Den finner referanser til utils, leser verktøyklasser (forbruk 200 000).
• Den prøver å endre, får feil, leser feillogger (forbruk 100 000).
• Den prøver å fikse, får feil igjen...

Den prøver og feiler som en gal, og bruker tokens som en gal. Og du? Du ser på telefonen, føler du er så effektiv. Realiteten er: Du bytter penger mot «pseudoeffektivitet», og produserer kode du ikke kan vedlikeholde senere.

Mer profesjonelt sagt, er det to lag med tap:

• Kostnadslag: Input-tokens øker, antall iterasjoner øker, kostnadene summeres lineært
• Utviklingslag: Du mister kontekst og beslutningsmyndighet, og sitter til slutt med et ukontrollerbart system som «bare må fungere»

Latskap to: Typen som kaster alt på en gang

Når du møter en feil, hvordan gir du den til AI? Kopierer du hele feilkonsollen med Ctrl+A, eller bruker du direkte @Codebase for at AI skal finne det selv?

Dette kalles «å kaste alt på en gang». Du gidder ikke lokalisere problemets kjerne, gidder ikke filtrere viktige kodesnutter. Du gir 99 % ugyldig informasjon (støy) og 1 % gyldig informasjon (signal) til AI på en gang.

AI er som en forsterker.

• Gir du den klar logikk (signal), forsterker den din intelligens, bruker få tokens, godt resultat.
• Gir du den kaos og uklarhet, forsterker den ditt kaos, tokens eksploderer, produserer søppel.

3. Løsning: Hvordan bruke AI effektivt og redusere token-forbruk

For å beskytte lommeboken, og viktigere, din utviklingskontroll, må vi endre samarbeidsmodellen med AI.

1. Prinsippet om minimal kontekst

Dette er det første prinsippet for AI-programmering. Gi alltid AI den minste kodesamlingen som trengs for å løse det aktuelle problemet.

I Cursor, bruk disse operatorene godt:

• @File: Referer kun til relevante filer, ikke hele mapper.
• Ctrl+L for å velge kode: Send bare de 50 kodelinjene markert med markøren til Chat, ikke hele filen.
• @Docs: For tredjepartsbiblioteker, referer til dokumentasjon i stedet for å la den gjette.

Dette er en strukturert, gjenbrukbar SOP jeg ofte bruker (gjør dette, og token-forbruket vil synke merkbart):

Meningen med denne teksten er: Når du samarbeider med AI, må du være oppmerksom på effektivitet og presisjon. Konkrete tiltak er som følger:

• Først, avklar målet: Fortell AI kort og klart om det aktuelle problemet og ønsket resultat, ikke la den gjette selv.
• Forenklet problemgjengivelse: Bruk den enkleste metoden for å reprodusere problemet, lim inn minst mulig og avgjørende kode, ikke dyng på masse irrelevant innhold.
• Gi minimal nødvendig informasjon: Bare gi relevante 1–3 filer, nøkkelfunksjoner og de første linjene av feilstakken, ikke all informasjon.
• Be om endringspunkter: Be AI bare fortelle deg hva som endres og hvorfor, ikke la den omskrive all kode i stor skala.
• Til slutt, ta kontroll selv: Gjør en kort verifisering for å sikre at endringene ikke påvirker andre steder.

Kort sagt, bruk minst mulig, mest avgjørende informasjon for å la AI gjøre jobben, og behold den endelige kontrollen og dømmekraften.

2. Også det viktigste: Tenk først, så prompt, planlegg først, så handl

Før du trykker enter, tving deg selv til å stoppe i 10 sekunder, og spør deg selv tre spørsmål:

• Hvilket problem løser jeg? (Definer grenser)
• Hvilke kjerne-moduler involverer dette problemet? (Filtrer kontekst)
• Hvordan ville jeg skrevet det selv? (Gi tankegang)

Du er 1, AI er nullene etter. Hvis 1 ikke står fast, er alle nullene etter bare meningsløst forbruk.

Noen ord fra hjertet

Historien om «én milliard tokens om dagen» vil kanskje ikke skje med alle. Men å sløse med tokens har nesten alle programmerere som bruker AI-programmering opplevd.

Selv om AI gjør programmering enklere, finnes det fortsatt terskler. De som virkelig kan bruke det, vil få vinger.

Før, plaget dårlig kode bare kollegaene dine. Nå, blir latskapen din direkte til tall på regningen, og straffer deg selv med økende kostnader.

Så, ikke vær «ansvarsfraskriver». Vær en AI-arkitekt som tenker dypt, uttrykker seg presist, planlegger før handling. Dette er også vår største uerstattelighet i denne tiden.