En milliard tokens om dagen? Programmørernes AI-regninger straffer de 'dovne'

Målgruppe: Udviklere, der bruger AI-værktøjer til programmering (som Cursor, Windsurf, trae...), samt teknologiledere, der mangler forståelse for AI-omkostninger.

Kernepoint: Tokens er ikke blot en simpel faktureringsenhed, men en 'opmærksomhedsressource' og 'beregningsvaluta'. Misbrug af agenttilstand og manglende konteksthåndtering er faktisk en taktisk flittighed (lad AI rode rundt), der skjuler strategisk dovenskab (selv ikke at tænke).

Dine 'AI-udgifter' kan være højere end din løn

For nogle dage siden tjekkede jeg min token-regning. Da jeg så tallet, blev jeg lidt overrasket: 10 millioner tokens. Bemærk, det er ikke et månedligt forbrug, det er en dag.

Jeg troede, det var ekstremt. Senere lagde jeg en kort video om token-beregning ud.

Resultatet: kommentarsporet viste mig, hvad der betyder 'der er altid en, der er bedre'.

Billedet herunder er et screenshot af netbrugeren '老K的日常' daglige forbrug på 200 millioner tokens:

Først troede jeg, det var en enkeltstående sag, men da mange brugere skrev, at de forbruger 100 millioner om dagen, forstod jeg, at det er et meget udbredt fænomen.

Hvad betyder 100 millioner tokens? Hvis vi tager udgangspunkt i de almindelige faktureringsniveauer for 'visse kommercielle modeller' (input/output faktureres separat, samlet groft estimeret til 10 USD / million tokens), så brændes der 1000 dollars af på en dag. 7000 RMB brændt af på en dag. Mange nybegynderprogrammørers månedsløn er måske ikke engang nok til, at AI kan 'tænke' denne ene dag.

(Bemærkning: Priserne varierer meget mellem forskellige modeller/leverandører, og input- og outputpriserne er ofte også forskellige. Formålet her er ikke at regne nøjagtigt til to decimaler, men først at etablere en 'følelse af størrelsesorden'.)

Hvis du selv vil regne efter, er der generelt kun denne formel (ignorer cache/rabat osv.): omkostning ≈ (inputTokens / 1.000.000) × pris_in + (outputTokens / 1.000.000) × pris_out

Det er så modintuitivt. Vi har altid følt, at AI er billigt, OpenAI sænker endda priserne. Men hvorfor eksploderer token-forbruget eksponentielt i praksis?

I dag vil jeg dykke dybt ned i logikken bag dette 'token-sorte hul' og hvordan vi kan begrænse tabet.

1. Hvorfor eksploderer tokens 'eksponentielt'?

Mange har slet ingen fornemmelse af token-mængder. De tænker: 'Nå, det er bare et par kodelinjer, ikke? Hvor meget kan det være?'

1. Lad os regne det ud

Lad os først etablere en kvantitativ fornemmelse, der er tilstrækkelig i praksis. For at sige det klart: Tokens er ikke antal ord eller tegn. Det er 'kodningssegmenter', som modellen opdeler teksten i. Forskellige modeller bruger forskellige tokenizers, så vi kan kun give et interval, ikke en 'universel konstant'.

Tag disse tal som en 'estimationslineal' (formålet er at vurdere størrelsesorden, estimere omkostninger og træffe beslutninger om tabbegrænsning):

• 1 kinesisk skrifttegn: Typisk 1–2 tokens (almindelige tegn tættere på 1, sjældne/kombinationer nemmere 2–3)
• 1 engelsk ord: Typisk omkring 1,2–1,5 tokens (grovt estimat med 1,3 er også fint)
• 1 kodelinje ≈ 10–50 tokens (inkl. indrykning, kommentarer, typedeklarationer)
  • Konsis forretningslogik ≈ 12–20 tokens
  • Med typeannotationer, interface, JSDoc, 4-mellemrumsindrykning ≈ 20–35 tokens
  • Med mange import / dekoratører / kommentarer ≈ 30–50+ tokens
• 1 kildefil (400–600 linjer, moderne TS/Java-projekt) ≈ 4.000–24.000 tokens er almindeligt (median ≈ 12.000–18.000)
• 1 mellemstort projekt (100–200 kildefiler, kun src/, uden node_modules/ / genereret kode)
  • Bare at 'læse' kernesourcekoden igennem starter ofte ved en million tokens
  • Hvis man også propper tests, konfiguration, scripts, afhængighedserklæringer, logs med, er flere millioner tokens ikke usædvanligt

Moderne frontend-projekter er i TypeScript, fyldt med komplekse interface-definitioner; eller Java, hvor import ofte er mange linjer. Disse 'skabelonkoder' er faktisk token-drabere. Et mellemstort projekt med 100 filer kan nemt bruge 1 million tokens bare på at lade AI 'læse koden igennem'.

2. Tokens 'sneboldseffekt'

Det mest skræmmende ved token-forbrug er ikke en enkelt samtale, men akkumuleringen af kontekst i flerrundesamtaler.

LLM'er er statsløse. For at AI kan huske, hvad du sagde sidst, sender systemet typisk 'systemprompt + samtalehistorik + de filer/kodeuddrag, du refererer til + værktøjskald-output (f.eks. søgeresultater, fejllogs)' pakket sammen til modellen. Du tror, du kun stiller et spørgsmål, men du betaler faktisk gentagne gange for 'hele kontekstpakken'.

• Runde 1: Send 10.000 tokens, AI svarer med 1.000.
• Runde 2: Send (10.000 + 1.000 + nyt spørgsmål), AI svarer...
• Runde 10: Din kontekst er måske vokset til 200.000 tokens.

På dette tidspunkt, selv hvis du bare spørger 'hjælp mig med at ændre et variabelnavn', koster det 200.000 tokens. Derfor føler du, at du ikke laver noget, men regningen stiger vildt.

Endnu værre: Agenttilstand 'læser filer aktivt'. Et enkelt 'hjælp mig med at optimere brugermodulet' kan få den til først at scanne den relevante mappe, derefter følge afhængigheder, konfiguration, tests... Den er ikke doven, den 'udfører sin pligt efter standardstrategien', og standardstrategien er ofte: læs meget, prøv meget, iterer meget.

2. To typer 'dovenskab' ødelægger din ingeniørmæssige evne

Efter at have gennemgået de få 'milliard-gutter' i kommentarsporet, fandt jeg ud af, at roden til token-eksplosionen ikke kun er AI's forbrugsmekanisme, men også menneskers dovenskab.

Her er to typiske 'tankedovenskaber'.

Dovenskab type 1: Den afstående type

Har du også denne tankegang:

• 'Dette gamle projekt er for rodet, jeg gider ikke se på logikken, bare smid det til AI.'
• 'Cursor har fået agenttilstand, perfekt, lad den selv fikse fejlene.'

Så smider du hele src-mappen til agenten og giver en vag instruktion: 'Hjælp mig med at optimere brugermodulet.' Agenten begynder at arbejde:

• Den læser 50 filer (forbrug 500.000).
• Den opdager reference til utils, læser værktøjsklasser (forbrug 200.000).
• Den prøver at ændre, får fejl, læser fejlloggen (forbrug 100.000).
• Den prøver at rette, får fejl igen...

Den prøver vildt fejl, forbruger vildt tokens. Og du? Du scroller på telefonen og føler, du er effektiv. Sandheden er: Du køber 'pseudo-effektivitet' med penge og producerer en masse kode, du senere ikke kan vedligeholde.

Mere professionelt sagt er der to lag af tab:

• Omkostningslag: Inputtokens stiger, antal iterationer stiger, omkostningerne stiger lineært.
• Ingeniørlag: Du mister kontekst og beslutningsret, til sidst står du med et ukontrollerbart system, der bare 'virker'.

Dovenskab type 2: Den ufiltrerede type

Hvordan smider du fejl til AI? Kopierer du hele fejlkonsollen med Ctrl+A, eller bruger du bare @Codebase og lader AI selv finde?

Dette kaldes 'ufiltreret'. Du gider ikke lokalisere problemets kerne, filtrere nøglekodeuddrag. Du propper 99% irrelevante oplysninger (støj) og 1% relevante oplysninger (signal) ned i AI.

AI er som en forstærker.

• Giver du den klar logik (signal), forstærker den din intelligens, bruger få tokens, god effekt.
• Giver du den rod og uklarhed, forstærker den dit rod, tokens eksploderer, producerer skrald.

3. Løsning: Hvordan bruger man AI effektivt og reducerer token-forbrug

For at beskytte din pung, og vigtigere, din ingeniørmæssige kontrol, må vi ændre samarbejdsformen med AI.

1. Mindste-kontekst-princippet

Dette er det første princip i AI-programmering. Giv altid AI den mindste kodesamling, der er nødvendig for at løse det aktuelle problem.

I Cursor, brug disse operatorer godt:

• @File: Referer kun til relevante filer, ikke hele mappen.
• Ctrl+L for at markere kode: Send kun de 50 markerede linjer til Chat, ikke hele filen.
• @Docs: For tredjepartsbiblioteker, referer til dokumentationen i stedet for at lade den gætte.

Dette er en struktureret, genanvendelig SOP, jeg ofte bruger (følg den, og tokens vil synke synligt):

Meningen med dette afsnit er: Når du samarbejder med AI, skal du være opmærksom på effektivitet og præcision. Konkrete tiltag:

• Først afklar mål: Fortæl AI klart og kort problemet og det ønskede resultat, lad den ikke gætte selv.
• Reducer problemgengivelse: Brug den enkleste metode til at gengive problemet, indsæt minimal, afgørende kode, ikke en masse irrelevante ting.
• Giv minimal nødvendig information: Kun de relevante 1-3 filer, nøglefunktioner og de første linjer af fejlstacken, ikke al information.
• Kræv ændringspunkter returneret: Lad AI kun fortælle, hvad der ændres og hvorfor, ikke omskriv hele koden i stor stil.
• Til sidst kontrollerer du selv: Lav en meget kort validering for at sikre, at ændringerne ikke påvirker andre steder.

Kort sagt, brug mindst mulig, mest afgørende information til at lade AI arbejde, og behold den endelige kontrol og dømmekraft.

2. Også det vigtigste: Tænk først, så prompt, planlæg først, så handl

Før du trykker enter, tving dig selv til at stoppe i 10 sekunder og stille dig selv tre spørgsmål:

• Hvilket problem prøver jeg at løse? (definér grænser)
• Hvilke kernemoduler involverer dette problem? (filtrer kontekst)
• Hvordan ville jeg selv skrive det? (giv en tankegang)

Du er 1-tallet, AI er nullerne bagved. Hvis 1-tallet ikke står fast, er alle nullerne bagved bare meningsløst forbrug.

Et par oprigtige ord

Historien om '100 millioner tokens om dagen' sker måske ikke for alle. Men at spilde tokens oplever næsten alle programmører, der bruger AI til programmering.

AI gør programmering nemmere, men der er stadig en tærskel. Kun dem, der virkelig kan bruge det, får forstærket deres evner.

Før kunne din dårlige kode kun 'kvalme' kolleger. Nu bliver din dovenskab direkte til tal på regningen og straffer dig selv med stigende omkostninger.

Så vær ikke 'den afstående'. Vær en dybtænkende, præcist udtrykkende, først-planlæggende-så-handlende AI-arkitekt. Det er også vores største uerstattelighed i denne tid.