Célközönség: Az AI programozási eszközöket (mint például Cursor, Windsurf, trae...) használó fejlesztők, valamint azok a technológiai vezetők, akik nem rendelkeznek megfelelő ismeretekkel az AI költségeiről.

Fő gondolat: A token nem csupán egy egyszerű számlázási egység, hanem egyfajta "figyelem erőforrás" és "számítási teljesítmény valuta". Az Agent mód túlzott használata és a kontextuskezelés figyelmen kívül hagyása valójában a taktikai szorgalommal (az AI-t értelmetlen dolgokkal foglalkoztatva) leplezi a stratégiai lustaságot (a saját gondolkodás hiányát).

Az "AI kiadásaid" magasabbak lehetnek, mint a fizetésed

Pár napja megnéztem a token számlámat. Amikor megláttam a számot, kissé meglepődtem: 10 millió token. Figyelem, ez nem egy havi felhasználás, hanem egy napra.

Gondoltam, hogy ez nagyon kirívó. Később közzétettem egy rövid videót a token számításokkal kapcsolatban.

Ennek eredményeként a hozzászólások megmutatták, mit jelent az, hogy "nincs határa a hülyeségnek".

Az alábbi kép a "老K的日常" felhasználó napi kétmilliárd token felhasználási rekordjának képernyőképe:

Eleinte azt hittem, hogy ez egyedi eset, de amikor sok felhasználó megjegyezte, hogy naponta 100 millió tokent használnak fel, rájöttem, hogy ez egy nagyon általános jelenség.

Mit jelent 100 millió token? Ha a "néhány mainstream kereskedelmi modell" általánosan használt számlázási szintjét vesszük alapul (a bemenet/kimenet külön számlázva, durván 10 dollár / millió token nagyságrendben becsülve), akkor ez a nap 1000 dollárba kerül. Egy nap alatt 7000 jüant éget el. Sok kezdő programozó havi fizetése valószínűleg nem fedezi az AI "gondolkodásának" ezt az egy napot.

(Megjegyzés: A különböző modellek/szolgáltatók árai nagyon eltérőek, és a bemeneti és kimeneti árak is gyakran eltérőek. Itt nem az a cél, hogy a tizedesjegyig pontosan kiszámoljuk, hanem az, hogy először a "nagyságrendet" tisztázzuk.)

Ha saját maga szeretné újra kiszámolni, akkor általában ez az egyetlen képlet (a gyorsítótárat/kedvezményeket és egyéb speciális szabályokat figyelmen kívül hagyva): Költség ≈ (Bemeneti token / 1 000 000) × Egységár_in + (Kimeneti token / 1 000 000) × Egységár_out

Ez az egész dolog nagyon ellentmond az intuíciónak. Mindig azt gondoljuk, hogy az AI olcsó, az OpenAI még árat is csökkent. De miért robban fel a token felhasználás exponenciálisan a tényleges mérnöki munkában?

Ma mélyrehatóan elemezzük a "token fekete lyuk" mögötti logikát, és azt, hogy hogyan állíthatjuk meg a veszteségeket.

I. Miért "robban fel exponenciálisan" a token?

Sok testvérnek fogalma sincs a tokenek mennyiségéről. Azt gondolják: "Á, csak pár kódsort küldök, mennyi lehet az?"

1. Számoljunk egyértelműen

Először is hozzunk létre egy mérnöki szempontból használható mennyiségi érzékelést. Először is szögezzük le: A token nem a szavak száma, és nem is a karakterek száma. Ez a modell által a szöveg felosztása után kapott "kódolt töredék", a különböző modellek különböző tokenizálókat használnak, ezért csak intervallumot lehet megadni, nem pedig "mindenre érvényes" állandót.

Az alábbi számokat tekintsd "becslési mérőszámnak" (a cél a nagyságrend megítélése, a költségek előrejelzése és a veszteségmegelőzési döntések meghozatala):

• 1 kínai karakter: Általában 1-2 token (a gyakori karakterek közelebb vannak az 1-hez, a ritka karakterek/kombinációk könnyebben elérik a 2-3-at)

• 1 angol szó: Általában 1,2-1,5 token körül (durva becsléshez használhatod az 1,3-at is)

• 1 kódsor ≈ 10-50 token (behúzásokkal, megjegyzésekkel, típusdeklarációkkal)

• Egyszerű üzleti logika ≈ 12-20 token

• Típusjegyzetekkel, interface-szel, JSDoc-kal, 4 szóközzel behúzva ≈ 20-35 token

• Sok importtal / dekorátorral / megjegyzéssel ≈ 30-50+ token

• 1 forrásfájl (400-600 sor, modern TS/Java projekt) ≈ 4 000-24 000 token nagyon gyakori (medián ≈ 12 000-18 000)

• 1 közepes méretű projekt (100-200 forrásfájl, csak a src/ számít, a node_modules/ / generált kód nélkül)

• A lényeges forráskód "átolvasása" gyakran millió tokennel kezdődik

• Ha a teszteket, konfigurációkat, szkripteket, függőségi deklarációkat és naplókat is belerakjuk, akkor a több tízmillió token sem ritka

A mai frontend projektek TypeScript-ben készülnek, tele bonyolult Interface definíciókkal; vagy Java, ahol könnyen több tíz soros Importok vannak. Ezek a "sablonkódok" valójában token gyilkosok. Egy közepes méretű projekt, ha 100 fájlja van, csak az, hogy az AI "átolvassa a kódot", könnyen elvihet 1 millió tokent.

2. A tokenek "hógolyó" hatása

A token felhasználás legfélelmetesebb része nem az egyszeri beszélgetés, hanem a többfordulós beszélgetésekben felhalmozódó kontextus.

Az LLM mechanizmusa állapotmentes. Ahhoz, hogy az AI emlékezzen arra, amit az előző mondatban mondtál, a rendszer általában egy csomagba gyűjti a "rendszerüzenetet + a korábbi beszélgetéseket + az általad hivatkozott fájlokat/kódrészleteket + az eszközhívások kimenetét (például a keresési eredményeket, hibanaplókat)" és elküldi a modellnek. Azt hiszed, hogy csak egy kérdést tettél fel, de valójában folyamatosan fizetsz az "egész kontextus csomagért".

• 1. kör: 10 000 token elküldése, az AI 1000-rel válaszol.

• 2. kör: (10 000 + 1000 + új kérdés) elküldése, az AI válaszol...

• 10. kör: A kontextusod már 200 000 tokenre duzzadhatott.

Ekkor, még ha csak egy "segíts megváltoztatni egy változónevet" kérdést teszel is fel, 200 000 token költségét fizeted. Ez az oka annak, hogy úgy érzed, nem csináltál semmit, de a számla mégis száguld.

Ami még rosszabb: Az Agent mód "proaktívan olvas fájlokat". Ha azt mondod, hogy "segíts optimalizálni a felhasználói modult", akkor először végigpásztázza a kapcsolódó könyvtárakat, majd a függőségeket, majd a konfigurációkat, majd a teszteket... Nem lustálkodik, hanem "a szokásos stratégia szerint kötelességtudó", és a szokásos stratégia gyakran a következő: többet olvas, többet próbálkozik, többet iterál.

II. Kétféle "lustaság" teszi tönkre a mérnöki képességeidet

A hozzászólásokban szereplő "százmilliósok" elemzése után rájöttem, hogy a tokenek robbanásszerű növekedésének gyökere nem csak az AI felhasználási mechanizmusában rejlik, hanem az emberek lustaságában is.

Az alábbiakban két tipikus "gondolkodási lustaságot" mutatunk be.

Lustaság egy: Áthárító típus

Neked is van ilyen hozzáállásod?

• "Ez a régi projekt túl zavaros, lusta vagyok megnézni a logikát, csak dobjam oda az AI-nak."

• "A Cursor kiadta az Agent módot, nagyszerű, hagyja, hogy maga javítsa ki a hibákat."

Így az egész src mappát az Agentnek adod, és kiadsz egy homályos utasítást: "Segíts optimalizálni a felhasználói modult." Az Agent elkezd dolgozni:

• 50 fájlt olvas be (500 000-et fogyaszt).

• Felfedezi, hogy hivatkozik a utils-ra, és elolvassa a segédosztályokat (200 000-et fogyaszt).

• Megpróbálja módosítani, hibaüzenetet kap, elolvassa a hibanaplót (100 000-et fogyaszt).

• Megpróbálja kijavítani, és újra hibaüzenetet kap...

Őrülten próbálkozik, őrülten fogyasztja a tokeneket. És te? A telefonodat nyomkodod, és azt hiszed, hogy milyen hatékony vagy. Az igazság az, hogy pénzzel vásároltál "álhatékonyságot", és egy csomó olyan kódot hoztál létre, amelyet később nem tudsz karbantartani.

Szakszerűbben fogalmazva, itt kétféle veszteség van:

• Költség szint: A bemeneti tokenek száma megnő, az iterációk száma megnő, a költségek lineárisan összeadódnak

• Mérnöki szint: Elveszíted a kontextust és a döntési jogot, és végül csak egy "működik" típusú, ellenőrizhetetlen rendszer marad

Lustaság kettő: Mindent bele típus

Mikor hibával találkozol, hogyan adod át az AI-nak? Közvetlenül a Ctrl+A billentyűkombinációval másolod a teljes hibakonzolt, vagy közvetlenül a @Codebase-t használod, hogy az AI maga keresse meg?

Ezt hívják "mindent bele"-nek. Lusta vagy meghatározni a probléma lényegét, lusta vagy kiválasztani a kulcsfontosságú kódrészleteket. A hatástalan információk (zaj) 99%-át és a hatékony információk (jel) 1%-át egy kalap alatt az AI-nak adod.

Az AI olyan, mint egy erősítő.

• Ha tiszta logikát (jelet) adsz neki, akkor felerősíti a bölcsességedet, kevesebb tokent használ, és jó az eredmény.

• Ha zavart és homályosságot adsz neki, akkor felerősíti a zavarodottságodat, a tokenek száguldanak, és szemetet termel.

III. Megoldás: Hogyan használjuk hatékonyan az AI-t, és hogyan csökkentsük a token felhasználást

Ahhoz, hogy megvédd a pénztárcádat, még fontosabb, hogy megvédd a mérnöki ellenőrzésedet, meg kell változtatnunk az AI-val való együttműködés módját.

1. Minimális kontextus elve

Ez az AI programozás elsődleges elve. Mindig csak azt a minimális kódot add meg az AI-nak, amely az aktuális probléma megoldásához szükséges.

A Cursorban használd ki ezeket az operátorokat:

• @File: Csak a kapcsolódó fájlokat hivatkozd, ne az egész mappát.

• Ctrl+L Kód kijelölése: Csak a kurzor által kijelölt 50 sornyi kódot küldd el a Chatnek, ne az egész fájlt.

• @Docs: Harmadik féltől származó könyvtárak esetében hivatkozz a dokumentációra, ne hagyd, hogy találgasson.

Ez egy strukturált, újrafelhasználható SOP, amelyet gyakran használok (ha követed, a tokenek láthatóan csökkennek):

Ez a mondat azt jelenti, hogy az AI-val való együttműködés során figyelni kell a hatékonyságra és a pontosságra. A konkrét lépések a következők:

• Először tisztázd a célt: Rövid és tömör módon mondd el az AI-nak az aktuális problémát és a kívánt eredményt, ne hagyd, hogy találgasson.

• Egyszerűsítsd a probléma reprodukálását: Ha a legegyszerűbb módszerrel újra tudod reprodukálni a problémát, akkor ne használj bonyolult módszert, illessz be a lehető legkevesebb és legfontosabb kódot, ne halmozz fel egy csomó irreleváns tartalmat.

• Add meg a minimálisan szükséges információt: Csak a kapcsolódó 1-3 fájlt, a kulcsfontosságú függvényeket és a hibaüzenet első néhány sorát add meg, ne az összes információt.

• Kérd a módosítások visszaadását: Az AI csak azt mondja meg, hogy hol változtasson, és miért változtasson, ne írja át az egész kódot.

• Végül te magad ellenőrizd: Végezz egy rövid ellenőrzést, hogy a változtatás nem befolyásol-e más helyeket.

Röviden, a lehető legkevesebb és legfontosabb információval végeztesd el az AI-val a munkát, és tartsd meg a végső ellenőrzést és döntési jogot.

2. A legfontosabb: Először gondolkodj, majd Prompt, először tervezz, majd cselekedj

Mielőtt megnyomnád az Entert, kényszerítsd magad, hogy 10 másodpercig állj meg, és tedd fel magadnak a következő három kérdést:

• Milyen problémát oldok meg? (Határok meghatározása)

• Melyek a probléma szempontjából releváns kulcsfontosságú modulok? (Kontextus szűrése)

• Ha én magam írnám, hogyan írnám meg? (Ötletek megadása)

Te vagy az 1, az AI a mögötte lévő 0. Ha az 1 nem áll meg, akkor a mögötte lévő 0-k bármennyire is sokan vannak, csak értelmetlen pazarlás.

Néhány szívből jövő szó

Lehet, hogy a "napi százmillió token" története nem fog mindenkivel megtörténni. De a tokenek pazarlása szinte minden AI programozást használó programozóval megtörténik.

Bár az AI egyszerűbbé teszi a programozást, még mindig vannak korlátai. Aki igazán tudja használni, az szárnyakat kap.

Korábban a rossz kódod csak a kollégáidat "undorította". Most a lustaságod közvetlenül a számlán jelenik meg, és a szárnyaló költségekkel bünteted magad.Tehát ne légy "hátradőlő vezető". Légy egy mélyen gondolkodó, pontosan fogalmazó, előre tervező, majd cselekvő AI építész. Ez a legnagyobb pótolhatatlanságunk ebben a korban.