Cílová skupina: Vývojáři používající AI programovací nástroje (jako Cursor, Windsurf, trae…) a techničtí manažeři, kteří si neuvědomují náklady na AI.

Hlavní myšlenka: Token není jen jednoduchá účetní jednotka, ale „zdroj pozornosti“ a „výpočetní měna“. Zneužívání režimu Agent, ignorování správy kontextu, to je ve skutečnosti zakrývání strategické lenosti (nesamostatné myšlení) taktickou pílí (nechat AI dělat nesmysly).

Vaše „AI výdaje“ mohou být vyšší než plat

Před pár dny jsem se podíval na svůj účet za tokeny. Když jsem viděl to číslo, byl jsem trochu překvapen: 10 milionů tokenů. Pozor, to není měsíční spotřeba, to je denní.

Myslel jsem si, že jsem na tom hodně špatně. Později jsem zveřejnil krátké video o výpočtu tokenů.

Výsledkem bylo, že jsem v sekci komentářů viděl, co znamená „nebe nad nebem“.

Následující obrázek je snímek záznamu spotřeby dvou set milionů tokenů za den od uživatele „Old K's Daily“:

Zpočátku jsem si myslel, že to může být ojedinělý případ, ale když mnoho uživatelů napsalo, že spotřebují 100 milionů denně, uvědomil jsem si, že je to velmi běžný jev.

Co znamená sto milionů tokenů? Pokud se to počítá podle běžné úrovně fakturace „některých hlavních komerčních modelů“ (vstup/výstup se účtuje samostatně, dohromady se hrubě odhaduje na 10 USD / milion tokenů), pak se za tento den spálí 1000 USD. Za den se spálí 7000 RMB. Měsíční plat mnoha začínajících programátorů nemusí stačit na to, aby AI „přemýšlela“ tento jeden den.

(Poznámka: Cenové rozdíly mezi různými modely/dodavateli jsou velké a jednotkové ceny vstupu a výstupu se také často liší. Cílem zde není přesný výpočet na dvě desetinná místa, ale nejprve stanovit „pocit rozsahu“.)

Pokud si chcete sami přepočítat, obecně platí tento vzorec (ignorujte speciální pravidla, jako je ukládání do mezipaměti/slevy): Náklady ≈ (vstupní tokeny / 1 000 000) × cena_in + (výstupní tokeny / 1 000 000) × cena_out

Tohle je velmi neintuitivní. Vždy si myslíme, že AI je levná, OpenAI dokonce snižuje ceny. Ale proč ve skutečném inženýrství spotřeba tokenů exponenciálně exploduje?

Dnes s vámi hloubkově rozebereme logiku za touto „tokenovou černou dírou“ a jak bychom měli zastavit ztráty.

I. Proč tokeny „exponenciálně explodují“?

Mnoho bratrů nemá o objemu tokenů vůbec žádnou představu. Myslí si: „Ach, to je jen pár řádků kódu, kolik toho může být?“

1. Spočítejme si to jasně

Nejprve si vytvořme kvantifikovatelné vnímání, které je dostatečné pro inženýrství. Řekněme to jasně: Token není počet slov, ani počet znaků. Je to „kódový fragment“, který model rozdělí z textu. Různé modely používají různé tokenizátory, takže lze uvést pouze rozsah, nikoli konstantu, která by platila „pro všechny případy“.

Berte tato čísla jako „odhadovací měřítko“ (cílem je posoudit rozsah, odhadnout náklady, rozhodnout o zastavení ztrát):

• 1 čínský znak: Běžně 1–2 tokeny (běžné znaky se blíží 1, vzácné znaky/kombinace snadněji dosáhnou 2–3)

• 1 anglické slovo: Běžně kolem 1,2–1,5 tokenů (pro hrubý odhad lze použít i 1,3)

• 1 řádek kódu ≈ 10–50 tokenů (včetně odsazení, komentářů, deklarací typů)

• Jednoduchá obchodní logika ≈ 12–20 tokenů

• S anotacemi typů, rozhraním, JSDoc, 4 mezerami pro odsazení ≈ 20–35 tokenů

• S velkým množstvím importů / dekorátorů / komentářů ≈ 30–50+ tokenů

• 1 zdrojový soubor (400–600 řádků, moderní TS/Java projekt) ≈ 4 000–24 000 tokenů je běžné (medián ≈ 12 000–18 000)

• 1 středně velký projekt (100–200 zdrojových souborů, počítá se pouze src/, neobsahuje node_modules/ / generovaný kód)

• „Přečtení“ základního zdrojového kódu často začíná na milionu tokenů

• Pokud se do toho přidají testy, konfigurace, skripty, deklarace závislostí, protokoly, není divu, že to dosáhne desítek milionů tokenů

Současné front-end projekty jsou TypeScript, plné složitých definic rozhraní; nebo Java, která má desítky řádků importů. Tyto „šablonové kódy“ jsou ve skutečnosti zabijáci tokenů. Středně velký projekt, který má 100 souborů, může spotřebovat 1 milion tokenů jen tím, že AI „přečte kód“.

2. „Sněhová koule“ efekt tokenů

Nejhorší na spotřebě tokenů není jednorázový rozhovor, ale kumulace kontextu ve vícekolových rozhovorech.

Mechanismus LLM je bezstavový. Aby si AI pamatovala, co jste řekli v předchozí větě, systém obvykle zabalí a odešle modelu „systémovou výzvu + historii rozhovorů + fragmenty souborů/kódu, na které odkazujete + výstup volání nástrojů (například výsledky vyhledávání, chybové protokoly)“. Myslíte si, že jste se zeptali jen na jednu věc, ale ve skutečnosti opakovaně platíte za „celý kontextový balíček“.

• 1. kolo: Odesláno 10 000 tokenů, AI odpoví 1 000.

• 2. kolo: Odesláno (10 000 + 1 000 + nová otázka), AI odpoví...

• 10. kolo: Váš kontext se mohl nafouknout na 200 000 tokenů.

V tomto okamžiku, i když se zeptáte jen na „pomoz mi změnit název proměnné“, spotřebujete poplatek 200 000 tokenů. Proto si myslíte, že jste nic nedělali, ale účet raketově stoupá.

Ještě horší je, že režim Agent „aktivně čte soubory“. Zeptáte se „pomoz mi optimalizovat uživatelský modul“ a on může nejprve prohledat příslušné adresáře, pak sledovat závislosti, pak sledovat konfiguraci, pak sledovat testy… Nedělá to proto, že by se flákal, ale proto, že „plní své povinnosti podle výchozí strategie“ a výchozí strategie je často: číst více, zkoušet více, iterovat více.

II. Dva druhy „lenosti“ ničí vaše inženýrské schopnosti

Po rekapitulaci s těmi „miliardáři“ v sekci komentářů jsem zjistil, že kořenem prudkého nárůstu tokenů není jen problém spotřebního mechanismu AI, ale také úzce souvisí s lidskou leností.

Následují dva typické příklady „myšlenkové lenosti“.

Lenost 1: Typ „přehazovače odpovědnosti“

Máte také tento postoj?

• „Tento starý projekt je příliš chaotický, nechce se mi dívat na logiku, hodím to rovnou na AI.“

• „Cursor vydal režim Agent, skvělé, ať si sám opraví chyby.“

A tak hodíte celou složku src Agentovi a vydáte vágní pokyn: „Pomoz mi optimalizovat uživatelský modul.“ Agent začne pracovat:

• Přečte 50 souborů (spotřebuje 500 000).

• Zjistí, že odkazuje na utils, a jde číst třídy nástrojů (spotřebuje 200 000).

• Pokusí se o úpravu, dojde k chybě, přečte chybový protokol (spotřebuje 100 000).

• Pokusí se o opravu, dojde k další chybě...

Šíleně zkouší a dělá chyby, šíleně spotřebovává tokeny. A co vy? Prohlížíte si telefon a myslíte si, že jste opravdu efektivní. Pravda je: za „pseudoefektivitu“ jste zaplatili penězi a vytvořili jste hromadu kódu, který později nemůžete udržovat.

Profesionálněji řečeno, existují zde dvě vrstvy ztrát:

• Nákladová vrstva: Zvětšuje se vstupní token, zvyšuje se počet iterací, náklady se lineárně sčítají

• Inženýrská vrstva: Ztrácíte kontext a rozhodovací pravomoc a nakonec vám zbude jen nekontrolovatelný systém, který „prostě funguje“

Lenost 2: Typ „všechno dohromady“

Jak předáváte chybu AI? Zkopírujete přímo celý chybový konzole pomocí Ctrl+A, nebo necháte AI, aby si to sama našla pomocí @Codebase?

Tohle se nazývá „všechno dohromady“. Nechce se vám lokalizovat jádro problému, nechce se vám filtrovat klíčové fragmenty kódu. Hodíte na AI 99 % neplatných informací (šumu) a 1 % platných informací (signálu).

AI je jako zesilovač.

• Dáte mu jasnou logiku (signál), zesílí vaši moudrost, spotřebuje se málo tokenů a efekt je dobrý.

• Dáte mu zmatek a nejasnosti, zesílí váš zmatek, tokeny raketově stoupají a produkuje odpad.

III. Řešení: Jak efektivně používat AI a snížit spotřebu tokenů

Chcete-li si udržet peněženku, je důležitější udržet si kontrolu nad inženýrstvím, musíme změnit režim spolupráce s AI.

1. Princip minimálního kontextu

To je první princip programování AI. Vždy dávejte AI pouze minimální sadu kódu, která odpovídá aktuálnímu problému.

V Cursoru dobře využívejte tyto operátory:

• @File: Odkazujte se pouze na relevantní soubory, nikoli na celé složky.

• Ctrl+L Vyberte kód: Pošlete chatu pouze 50 řádků kódu vybraných kurzorem, nikoli celý soubor.

• @Docs: Pro knihovny třetích stran odkazujte na dokumentaci, nenechte ji hádat.

Toto je strukturovaný, opakovaně použitelný SOP, který často používám (udělejte to a tokeny viditelně klesnou):

Smyslem této pasáže je: Při spolupráci s AI dbejte na efektivitu a přesnost. Konkrétní kroky jsou následující:

• Nejprve si ujasněte cíl: Stručně a jasně sdělte AI aktuální problém a požadovaný výsledek, nenechte ji hádat.

• Zjednodušte reprodukci problému: Pokud můžete problém reprodukovat nejjednodušším způsobem, nepoužívejte složitý způsob, vložte co nejméně a klíčový kód, nehromaďte spoustu nesouvisejícího obsahu.

• Poskytněte minimální nezbytné informace: Stačí uvést 1–3 související soubory, klíčové funkce a prvních několik řádků chybového zásobníku, není třeba uvádět všechny informace.

• Požadujte vrácení bodů úprav: Nechte AI, aby vám řekla pouze to, co se má změnit a proč, nenechte ji přepisovat celý kód.

• Nakonec to sami zkontrolujte: Proveďte nejjednodušší ověření, abyste se ujistili, že změna neovlivní jiná místa.

Stručně řečeno, použijte co nejméně a nejdůležitější informace, aby AI dělala věci, a ponechte si konečnou kontrolu a úsudek.

2. Také nejdůležitější: Nejprve přemýšlejte, pak zadejte výzvu, nejprve plánujte, pak jednejte

Před stisknutím klávesy Enter se přinuťte na 10 sekund zastavit a zeptejte se sami sebe na tři otázky:

• Jaký problém řeším? (Definujte hranice)

• Kterých klíčových modulů se tento problém týká? (Filtrujte kontext)

• Jak bych to napsal sám? (Poskytněte nápady)

Vy jste 1, AI je 0 za vámi. Pokud 1 nestojí, pak i když je za ním více 0, je to jen nesmyslná spotřeba.

Pár upřímných slov

Příběh o „miliardě tokenů denně“ se možná nestane každému. Ale plýtvání tokeny zažije téměř každý programátor, který používá programování AI.

AI sice usnadňuje programování, ale stále existuje práh. Skutečně to umí používat jen ti, kteří jsou zdatní.

Dříve váš špatný kód „znechucoval“ jen kolegy. Nyní se vaše lenost přímo promění v čísla na účtu a potrestá vás prudce rostoucími náklady. Takže nebuďte "ten, kdo se zbavuje odpovědnosti". Buďte AI architekt, který hluboce přemýšlí, přesně se vyjadřuje a jedná až po plánování. To je také naše největší nenahraditelnost v této době.