Públic objectiu: Desenvolupadors que utilitzen eines de programació d'IA (com Cursor, Windsurf, trae...) i gestors tècnics sense consciència dels costos de la IA.

Opinió principal: Un token no és només una simple unitat de facturació, sinó un "recurs d'atenció" i una "moneda de poder de càlcul". L'ús excessiu del mode Agent i la negligència en la gestió del context equivalen a emmascarar la mandra estratègica (no pensar per un mateix) amb la diligència tàctica (deixar que la IA faci coses sense sentit).

Les teves "despeses d'IA" podrien ser superiors al teu sou

Fa uns dies, vaig revisar la meva factura de tokens. Em vaig sorprendre quan vaig veure el número: 10 milions de tokens. Tingueu en compte que aquest no és l'ús d'un mes, sinó un dia.

Pensava que això era escandalós. Després vaig publicar un vídeo curt sobre el càlcul de tokens.

Com a resultat, la secció de comentaris em va mostrar el que significa "hi ha un món més enllà del món".

La imatge següent és una captura de pantalla del registre de consum de dos-cents milions de tokens en un dia de l'usuari "La vida diària de Lao K":

Al principi, vaig pensar que podria ser un cas aïllat, però quan molts usuaris van comentar que consumien 100 milions al dia, vaig entendre que era un fenomen molt comú.

Què són cent milions de tokens? Si es calcula segons l'escala de facturació comuna de "alguns models comercials principals" (la facturació d'entrada/sortida es factura per separat, i juntes s'estima aproximadament a 10 dòlars EUA / milió de tokens), es cremen 1000 dòlars EUA en aquest dia. Es cremen 7000 iuans xinesos en un dia. El sou mensual de molts programadors principiants podria no ser suficient perquè la IA "pensi" aquest dia.

(Nota: la diferència de preu entre diferents models/proveïdors és molt gran, i el preu unitari d'entrada i sortida sovint és diferent. L'objectiu aquí no és calcular amb precisió fins al segon decimal, sinó primer establir un "sentit d'escala".)

Si voleu tornar a calcular-ho vosaltres mateixos, generalment hi ha aquesta fórmula (ignorant les regles especials com ara la memòria cau/descomptes): Cost ≈ (Tokens d'entrada / 1.000.000) × Preu unitari_entrada + (Tokens de sortida / 1.000.000) × Preu unitari_sortida

Això és massa contrari a la intuïció. Sempre pensem que la IA és barata, i OpenAI fins i tot vol reduir els preus. Però per què el consum de tokens explota exponencialment en l'enginyeria real?

Avui, us portaré a disseccionar profundament la lògica darrere d'aquest "forat negre de tokens" i com podem aturar les pèrdues.

I. Per què els tokens "exploten exponencialment"?

Molts germans no tenen cap concepte del volum de tokens. Pensen: "Oh, no són només uns quants fragments de codi? Quants poden ser?"

1. Feu un compte clar

Primer establim una percepció quantitativa que sigui útil en l'enginyeria. Primer diguem-ho sense embuts: Un token no és un nombre de paraules, ni un nombre de caràcters. És un "fragment de codificació" després que el model divideix el text. Diferents models utilitzen diferents tokenitzadors, de manera que només es pot donar un interval, no una constant que sigui "aplicable a tot el món".

Preneu aquests números com a "escala d'estimació" (l'objectiu és jutjar l'escala, estimar els costos i prendre decisions per aturar les pèrdues):

• 1 caràcter xinès: comú a 1-2 tokens (els caràcters d'alta freqüència estan més a prop d'1, i els caràcters/combinacions rars són més propensos a arribar a 2-3)

• 1 paraula anglesa: comú al voltant d'1,2-1,5 tokens (l'estimació aproximada també pot utilitzar 1,3)

• 1 línia de codi ≈ 10-50 tokens (incloent sagnat, comentaris, declaracions de tipus)

• Lògica de negoci senzilla ≈ 12-20 tokens

• Amb anotacions de tipus, interfície, JSDoc, sagnat de 4 espais ≈ 20-35 tokens

• Amb un gran nombre d'importacions / decoradors / comentaris ≈ 30-50+ tokens

• 1 fitxer font (400-600 línies, projecte modern TS/Java) ≈ 4.000-24.000 tokens és molt comú (mediana ≈ 12.000-18.000)

• 1 projecte de mida mitjana (100-200 fitxers font, només comptant src/, sense incloure node_modules/ / codi generat)

• "Llegir" el codi font principal "una vegada" sovint comença amb un milió de tokens

• Si s'hi afegeixen proves, configuració, scripts, declaracions de dependència i registres, no és estrany que arribi a desenes de milions de tokens

Els projectes front-end actuals són TypeScript, plens de definicions d'interfície complexes; o Java, amb desenes de línies d'importació a cada pas. Aquest "codi de plantilla" és en realitat un assassí de tokens. Un projecte de mida mitjana, si té 100 fitxers, només deixar que la IA "llegeixi el codi" podria eliminar directament 1 milió de tokens.

2. L'efecte "bola de neu" dels tokens

El més terrible del consum de tokens no és una sola conversa, sinó l'acumulació de context en converses de diverses rondes.

El mecanisme de LLM és sense estat. Perquè la IA recordi el que vas dir a l'última frase, el sistema normalment empaqueta i envia al model "indicacions del sistema + historial de converses + fragments de fitxers/codi que has referenciat + sortida de crides d'eines (com ara resultats de cerca, registres d'errors)". Penses que només has fet una pregunta, però en realitat estàs pagant repetidament per tot el "paquet de context".

• Ronda 1: s'envien 10.000 tokens, la IA respon amb 1.000.

• Ronda 2: s'envien (10.000 + 1.000 + nova pregunta), la IA respon...

• Ronda 10: el teu context podria haver-se inflat fins a 200.000 tokens.

En aquest moment, fins i tot si només fas una pregunta com "ajuda'm a canviar un nom de variable", es consumeixen 200.000 tokens. Per això sents que no has fet res, però la factura s'està disparant.

Més crític encara: el mode Agent "llegeix fitxers de manera proactiva". Si dius "ajuda'm a optimitzar el mòdul d'usuari", podria escanejar primer els directoris relacionats, després rastrejar les dependències, després rastrejar la configuració i després rastrejar les proves... No està sent mandrós, està "complint amb el seu deure segons l'estratègia per defecte", i l'estratègia per defecte sol ser: llegir més, provar més, iterar més.

II. Dos tipus de "mandres" estan destruint la teva capacitat d'enginyeria

Després de revisar els "germans de cent milions" a la secció de comentaris, vaig trobar que l'arrel de l'augment dels tokens no només és el problema del mecanisme de consum de la IA, sinó que també està estretament relacionat amb la mandra de les persones.

A continuació hi ha dos tipus típics de "mandres de pensament".

Mandres 1: Tipus de gestor de mans buides

Tens aquesta mentalitat?

• "Aquest projecte antic és massa desordenat, sóc massa mandrós per veure la lògica, només l'enviaré a la IA."

• "Cursor ha llançat el mode Agent, genial, deixeu que repari els errors per si mateix."

Per tant, envieu tota la carpeta src a l'Agent i doneu una instrucció vaga: "ajuda'm a optimitzar el mòdul d'usuari". L'Agent comença a treballar:

• Llegeix 50 fitxers (consumint 500.000).

• Troba que fa referència a utils, i torna a llegir les classes d'eines (consumint 200.000).

• Intenta modificar-lo, hi ha un error, llegeix el registre d'errors (consumint 100.000).

• Intenta reparar-lo, hi ha un altre error...

Està provant i errorant frenèticament, consumint tokens frenèticament. I tu? Estàs navegant pel teu telèfon, pensant que ets molt eficient. La veritat és: estàs canviant "pseudoeficiència" per diners, produint un munt de codi que no pots mantenir en el futur.

Més professionalment, hi ha dues pèrdues aquí:

• Nivell de cost: l'entrada de tokens augmenta, el nombre d'iteracions augmenta i les despeses s'acumulen linealment

• Nivell d'enginyeria: perds el context i el poder de decisió, i al final només queda un sistema incontrolable que "pot funcionar"

Mandres 2: Tipus de barreja de fang i sorra

Quan trobes un error, com l'envies a la IA? Copies directament Ctrl+A tota la consola d'errors, o directament @Codebase perquè la IA el trobi per si mateixa?

Això s'anomena "barreja de fang i sorra". Ets massa mandrós per localitzar el nucli del problema, massa mandrós per filtrar fragments de codi clau. Envies el 99% d'informació no vàlida (soroll) i l'1% d'informació vàlida (senyal) a la IA.

La IA és com un amplificador.

• Si li dones una lògica clara (senyal), amplifica la teva saviesa, utilitza menys tokens i té un bon efecte.

• Si li dones confusió i ambigüitat, amplifica la teva confusió, els tokens es disparen i produeix escombraries.

III. Solució: com utilitzar la IA de manera eficient i reduir el consum de tokens

Per protegir la teva cartera, el més important és protegir el teu poder de control d'enginyeria, hem de canviar el nostre mode de col·laboració amb la IA.

1. Principi de context mínim

Aquest és el primer principi de la programació d'IA. Sempre doneu a la IA el conjunt de codi mínim corresponent al problema actual per resoldre.

A Cursor, feu un bon ús d'aquests operadors:

• @File: només feu referència als fitxers rellevants, no a tota la carpeta.

• Ctrl+L Seleccioneu el codi: només envieu les 50 línies de codi seleccionades pel cursor al xat, no tot el fitxer.

• @Docs: per a biblioteques de tercers, citeu la documentació en lloc de deixar que ho endevini.

Aquest és un SOP estructurat i reutilitzable que utilitzo sovint (si ho feu, els tokens cauran visiblement):

Aquesta frase significa: quan col·laboreu amb la IA, heu de prestar atenció a l'eficiència i la precisió. Els passos específics són els següents:

• Primer definiu l'objectiu: digueu a la IA el problema actual i el resultat desitjat de manera concisa, no deixeu que ho endevini per si mateix.

• Simplifiqueu la reproducció del problema: si podeu utilitzar el mètode més senzill per reproduir el problema, no utilitzeu mètodes complexos, enganxeu el codi mínim i crític, no acumuleu una gran quantitat de contingut irrellevant.

• Proporcioneu la informació necessària mínima: només doneu els 1-3 fitxers rellevants, les funcions clau i les primeres línies de la pila d'errors, no tota la informació.

• Demaneu que es retornin els punts de modificació: deixeu que la IA només us digui on canviar i per què canviar, no deixeu que reescrigui tot el codi en gran mesura.

• Finalment, comproveu-ho vosaltres mateixos: feu la verificació més senzilla per assegurar-vos que els canvis no afecten altres llocs.

En resum, utilitzeu la informació mínima i més crítica per deixar que la IA faci coses i conserveu el control i el judici finals.

2. També el més important: penseu primer, després demaneu, planifiqueu primer, després actueu

Abans de prémer la tecla Enter, obligueu-vos a aturar-vos durant 10 segons i feu-vos tres preguntes:

• Quin problema estic resolent? (Definir límits)

• Quins mòduls bàsics implica aquest problema? (Filtrar context)

• Si ho escrivís jo mateix, com ho escriuria? (Proporcionar idees)

Tu ets l'1, la IA són els 0 que hi ha darrere. Si l'1 no pot aguantar, no importa quants 0 hi hagi darrere, només és un consum sense sentit.

Unes quantes paraules sinceres

La història de "cent milions de tokens al dia" potser no li passa a tothom. Però el comportament de malgastar tokens és experimentat per gairebé tots els programadors que utilitzen la programació d'IA.

Tot i que la IA facilita la programació, encara hi ha un llindar. Les persones que realment saben utilitzar-la seran com un tigre amb ales.

Abans, el codi dolent que escrivíeu només "fastidiava" els vostres companys. Ara, la mandra que robeu es convertirà directament en un número a la factura, castigant-vos amb costos creixents.Per tant, no facis de «cap visible». Sigues un arquitecte d'IA que pensa profundament, s'expressa amb precisió i planifica abans d'actuar. Aquesta és també la nostra major insubstituïbilitat en aquesta era.