Един ден изгаряне на 100 милиона токена? AI сметките на програмистите наказват „мързеливите“

# **Целева аудитория**: Разработчици, които използват AI инструменти за програмиране (като Cursor, Windsurf, trae...) и технически мениджъри, които не са наясно с разходите за AI. > **Основна идея**: Токените не са просто единици за таксуване, а „ресурс за внимание“ и „изчислителна валута“. Злоупотребата с Agent модели, пренебрегването на управлението на контекста, всъщност е използване на тактическо усърдие (да оставите AI да се лута на сляпо), за да се прикрие стратегически мързел (сами да не мислите). ## **Вашите „AI разходи“ може да са по-високи от заплатата ви** Преди няколко дни проверих сметката си за токени. Бях малко изненадан, когато видях числото: **10 милиона токена.** Забележете, това не е месечна употреба, а **един ден**. Мислех, че това е абсурдно. По-късно публикувах кратко видео за изчисляването на токени. В резултат на това коментарите ми показаха какво означава **„небето над небето“**. Следната снимка на екрана е запис на потреблението на 200 милиона токена за един ден от потребителя „Ежедневието на стария K“:  В началото си помислих, че това може да е изолиран случай, но когато много потребители коментираха, че консумират 100 милиона на ден, разбрах, че това е много често срещано явление. Какво представляват 100 милиона токена? Ако се изчисли по обичайните нива на таксуване на „някои основни търговски модели“ (входните/изходните данни се таксуват отделно, като общо се оценяват грубо на **10 долара / милион токена**), това изгаря **1000 долара** на ден. **Изгаряне на 7000 юана на ден.** Заплатата на много начинаещи програмисти за един месец може да не е достатъчна за „мисленето“ на AI за този един ден. (Забележка: Цените варират значително между различните модели/доставчици, а единичните цени за вход и изход често са различни. Целта тук не е да се изчисли точно до втория знак след десетичната запетая, а първо да се установи „усещане за мащаб“.) > Ако искате сами да преизчислите, обикновено има само една формула (игнорирайки кеширането/отстъпките и други специални правила): `Цена ≈ (ВходниТокени / 1 000 000) × ЕдиничнаЦена_вход + (ИзходниТокени / 1 000 000) × ЕдиничнаЦена_изход` Това е твърде неинтуитивно. Винаги смятаме, че AI е евтин, а OpenAI дори ще намали цените. Но защо в реалното инженерство консумацията на токени експлодира **експоненциално**? Днес ще ви преведем през дълбокия анализ на логиката зад тази „черна дупка на токени“ и как можем да спрем загубите. ## **I. Защо токените „експлодират експоненциално“?** Много братя нямат представа за обема на токените. Те си мислят: „Ами, това е само изпращане на няколко реда код, колко може да бъде?“ ### **1. Да си направим ясна сметка** Първо, трябва да установим количествено възприятие, което е **достатъчно добро за инженерни цели**. Нека да бъдем малко по-категорични: **Токенът не е брой думи, нито брой символи**. Това е „кодиран фрагмент“, след като моделът е разделил текста. Различните модели използват различни токенизатори, така че може да се даде само **интервал**, а не константа, която е „универсална“. Приемете тези числа като „оценка“ (целта е да се прецени мащаба, да се прогнозират разходите и да се вземат решения за спиране на загубите): - **1 китайски йероглиф**: Обикновено 1–2 токена (високочестотните йероглифи са по-близо до 1, а редките йероглифи/комбинации са по-склонни да бъдат 2–3) - **1 английска дума**: Обикновено около 1,2–1,5 токена (можете грубо да оцените с 1,3) - **1 ред код** ≈ 10–50 токена (включително отстъпи, коментари, декларации на типове) - Опростена бизнес логика ≈ 12–20 токена - С анотации на типове, интерфейс, JSDoc, 4 интервала отстъп ≈ 20–35 токена - С голям брой import / декоратори / коментари ≈ 30–50+ токена - **1 изходен файл** (400–600 реда, модерен TS/Java проект) ≈ 4 000–24 000 токена е много често срещано (медиана ≈ 12 000–18 000) - **1 среден проект** (100–200 изходни файла, само `src/`, без `node_modules/` / генериран код) - „Прочитането“ на основния изходен код често започва с **милиони токени** - Ако добавите тестове, конфигурации, скриптове, декларации на зависимости и логове, не е необичайно да достигнете десетки милиони токени Съвременните фронтенд проекти са TypeScript, пълни със сложни дефиниции на интерфейси; или Java, с десетки редове Import. Тези „шаблонни кодове“ всъщност са убийци на токени. Ако един среден проект има 100 файла, само позволяването на AI да „прочете кода“ може директно да унищожи **1 милион токена**. ### **2. Ефектът на „снежната топка“ на токените** Най-ужасното при консумацията на токени не е еднократният разговор, а **натрупването на контекст в многократни разговори**. Механизмът на LLM е **без състояние**. За да може AI да запомни какво сте казали в предишното изречение, системата обикновено изпраща „подсказка на системата + история на разговорите + фрагменти от файлове/код, които сте цитирали + изход от извикване на инструменти (като резултати от търсене, логове за грешки)“ заедно към модела. Мислите си, че сте задали само един въпрос, но всъщност плащате многократно за „целия контекстен пакет“. - **1-ви кръг**: Изпращане на 10 000 токена, AI отговаря с 1 000. - **2-ри кръг**: Изпращане на (10 000 + 1 000 + нов въпрос), AI отговаря... - **10-ти кръг**: Вашият контекст може да се е разраснал до 200 000 токена. В този момент, дори ако просто попитате „помогнете ми да променя името на променлива“, ще консумирате **200 000 токена**. Ето защо смятате, че не правите нищо, но сметката ви се покачва. Още по-лошото е, че **Agent режимът ще „чете файлове активно“**. Ако кажете „помогнете ми да оптимизирам потребителския модул“, той може първо да сканира съответната директория, след това да проследи зависимостите, след това да проследи конфигурацията, след това да проследи тестовете... Той не се опитва да мързелува, той „изпълнява задълженията си според политиката по подразбиране“, а политиката по подразбиране често е: **четете повече, опитвайте повече, итерирайте повече**. ## **II. Два вида „мързел“ унищожават вашите инженерни способности** След преглед на коментарите на онези „братя със 100 милиона“, открих, че коренът на рязкото покачване на токените не е само проблемът с механизма за консумация на AI, но и **мързелът** на хората. По-долу са два типични примера за **„мисловен мързел“**. ### **Мързел първи: Тип „ръководител“** Имате ли и вие това мислене: - *„Този стар проект е твърде разхвърлян, мързи ме да гледам логиката, просто ще го хвърля на AI.“* - *„Cursor пусна Agent режим, чудесно, нека сам да поправи грешките.“* Така че хвърляте цялата `src` папка на Agent и давате неясна инструкция: „Помогнете ми да оптимизирам потребителския модул.“ Agent започва да работи: - Той прочете 50 файла (консумира 500 000). - Той откри, че `utils` е цитиран, и отиде да прочете класовете инструменти (консумира 200 000). - Той се опита да направи промени, получи грешка и прочете логовете за грешки (консумира 100 000). - Той се опита да поправи, отново получи грешка... Той лудо опитва и греши, лудо консумира токени. А вие? Вие превъртате телефона си и смятате, че сте много ефективни. **Истината е: вие разменяте пари за „фалшива ефективност“ и произвеждате куп код, който не можете да поддържате по-късно.** По-професионално казано, тук има две загуби: - **Ниво на разходи**: Входните токени стават по-големи, броят на итерациите се увеличава и разходите се добавят линейно - **Инженерно ниво**: Губите контекста и правото на вземане на решения и накрая остава само неконтролируема система, която „просто работи“ ### **Мързел втори: Тип „всичко накуп“** Как давате грешка на AI, когато срещнете грешка? Копирате ли директно целия конзолен прозорец за грешки с `Ctrl+A` или директно `@Codebase`, за да позволите на AI сам да го намери? Това се нарича **„всичко накуп“**. Мързи ви да локализирате ядрото на проблема, мързи ви да филтрирате ключовите фрагменти от код. Хвърляте 99% от невалидната информация (шум) и 1% от валидната информация (сигнал) на AI наведнъж. **AI е като усилвател.** - Ако му дадете ясна логика (сигнал), той ще усили вашата мъдрост, ще използва по-малко токени и ще има добър ефект. - Ако му дадете объркване и неяснота, той ще усили вашето объркване, токените ще се покачат и ще произведе боклук. ## **III. Решение: Как да използвате AI ефективно и да намалите консумацията на токени** За да запазите портфейла си, по-важно е да запазите **инженерния си контрол**, трябва да променим режима си на сътрудничество с AI. ### **1. Принцип на минимален контекст** Това е първият принцип на AI програмирането. **Винаги давайте на AI минималния набор от кодове, съответстващи на текущия проблем.** В Cursor използвайте добре тези оператори: - **`@File`**: Цитирайте само съответните файлове, а не цялата папка. - `Ctrl+L`** Изберете код**: Изпратете само 50-те реда код, избрани от курсора, на Chat, а не целия файл. - **`@Docs`**: За библиотеки на трети страни цитирайте документацията, вместо да го оставяте да гадае. Това е структуриран, многократно използваем SOP, който често използвам (ако го направите, токените ще паднат видимо): Това означава: Когато си сътрудничите с AI, трябва да обърнете внимание на ефективността и точността. Специфичните практики са следните: - Първо, изяснете целта: Кажете на AI текущия проблем и желания резултат накратко и ясно, не го оставяйте да гадае сам. - Опростете възпроизвеждането на проблема: Използвайте най-простия метод, за да възпроизведете проблема, ако е възможно, и поставете най-малкото и ключово количество код, не трупайте голямо количество несвързано съдържание. - Предоставете минималната необходима информация: Дайте само 1-3 свързани файла, ключови функции и първите няколко реда от стека за грешки, не цялата информация. - Поискайте да върнете точките за промяна: Позволете на AI да ви каже само къде да промените и защо да промените, не го оставяйте да пренаписва целия код в дълги пасажи. - Накрая, проверете сами: Направете най-простата проверка, за да се уверите, че промените не засягат други места. Накратко, използвайте най-малкото и най-важното количество информация, за да накарате AI да свърши работа и запазете окончателния контрол и преценка. ### **2. Също така най-важното: първо мислете, след това подканете, първо планирайте, след това действайте** Преди да натиснете Enter, принудете се да спрете за 10 секунди и си задайте три въпроса: - **Какъв проблем решавам?** (Определете границите) - **Кои основни модули са включени в този проблем?** (Филтрирайте контекста) - **Ако трябваше да го напиша сам, как бих го написал?** (Предоставете идеи) **Вие сте 1, AI е 0 след него.** Ако 1 не може да се задържи, колкото и нули да има след него, това е просто безсмислена консумация. ## **Няколко сърдечни думи** Историята за „100 милиона токена на ден“ може да не се случи на всеки. Но поведението на разхищаване на токени е преживяно от почти всеки програмист, който използва AI програмиране. Въпреки че AI улеснява програмирането, все още има праг. **Тези, които наистина знаят как да го използват, ще бъдат като тигър с крила.** Преди това лошият код, който пишехте, само щеше да „отврати“ колегите ви. Сега мързелът, който проявявате, ще се превърне директно в число в сметката и ще накаже себе си с нарастващи разходи.Така че, не бъдете «безразличен управител». Бъдете дълбоко мислещ, прецизно изразяващ се, планиращ преди да действа AI архитект. Това е и най-голямата ни незаменимост в тази епоха.