Целна публика: Програмери кои користат алатки за програмирање со вештачка интелигенција (како Cursor, Windsurf, trae...) и технички менаџери кои немаат познавање за трошоците за вештачка интелигенција.

Основна гледна точка: Токените не се само едноставни единици за наплата, туку и „ресурси за внимание“ и „валута за компјутерска моќ“. Злоупотребата на моделот Agent и игнорирањето на управувањето со контекстот всушност ја прикрива стратешката мрзеливост (неразмислување) со тактичка трудољубивост (овозможување на вештачката интелигенција да се плетка).

Вашите „трошоци за вештачка интелигенција“ може да бидат повисоки од платата

Пред неколку дена, ја проверив мојата сметка за токени. Бев малку изненаден кога ја видов бројката: 10 милиони токени. Забележете, ова не е месечна употреба, туку еден ден.

Мислев дека ова е претерано. Подоцна објавив кратко видео поврзано со пресметката на токените.

Како резултат на тоа, коментарите ми покажаа што значи „небото е граница“.

Следната слика е слика од екранот од евиденцијата за потрошувачка на два милиони токени дневно на корисникот на интернет „Секојдневниот живот на стариот К“:

На почетокот мислев дека можеби е изолиран случај, но кога многу корисници на интернет оставија пораки дека трошат 100 милиони дневно, сфатив дека ова е многу чест феномен.

Што значи 100 милиони токени? Ако се пресмета според вообичаеното ниво на наплата на „некои мејнстрим комерцијални модели“ (наплатата за влез/излез се наплаќа посебно, а заедно грубо се проценува на 10 американски долари / милион токени), тогаш овој ден согорува 1000 долари. Еден ден согорува 7000 јуани. Платата на многу помлади програмери за еден месец можеби не е доволна за вештачката интелигенција да „размислува“ еден ден.

(Забелешка: Цените на различните модели/добавувачи многу варираат, а единечните цени за влез и излез често се различни. Целта овде не е да се пресмета до две децимални места, туку прво да се воспостави „чувство за големина“.)

Ако сакате сами да пресметате, обично постои оваа формула (игнорирајќи ги специјалните правила како што се кеширање/попусти): Цена ≈ (Влезни токени / 1.000.000) × Цена_влез + (Излезни токени / 1.000.000) × Цена_излез

Ова е премногу контраинтуитивно. Секогаш мислиме дека вештачката интелигенција е евтина, а 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 датотеки, само дозволувањето на вештачката интелигенција да го „прочита кодот“ веројатно директно ќе убие 1 милион токени.

2. Ефектот на „лавина“ на токените

Најстрашната работа за потрошувачката на токени не е единечен разговор, туку акумулацијата на контекст во повеќекратни разговори.

Механизмот на LLM е без состојба. За да се осигура дека вештачката интелигенција се сеќава што сте кажале во претходната реченица, системот обично ги испраќа „системските инструкции + историските разговори + фрагментите од датотеки/код што сте ги цитирале + излезот од повикот на алатката (како што се резултатите од пребарувањето, логовите за грешки)“ заедно до моделот. Мислите дека сте поставиле само едно прашање, но всушност постојано плаќате за „целиот контекст пакет“.

• 1-ва рунда: Испратете 10.000 токени, вештачката интелигенција одговара со 1.000.

• 2-ра рунда: Испратете (10.000 + 1.000 + ново прашање), вештачката интелигенција одговара...

• 10-та рунда: Вашиот контекст можеби веќе се проширил на 200.000 токени.

Во тоа време, дури и ако само прашате „помогни ми да сменам име на променлива“, ќе потрошите 200.000 токени. Затоа чувствувате дека не правите ништо, но сметката вртоглаво расте.

Уште полошо е: Режимот Agent „проактивно чита датотеки“. Една реченица „помогни ми да го оптимизирам корисничкиот модул“, можеби прво ќе го скенира релевантниот директориум, потоа ќе ги следи зависностите, потоа ќе ги следи конфигурациите, потоа ќе ги следи тестовите... Не е мрзливо, туку „одговорно според стандардната стратегија“, а стандардната стратегија често е: читај повеќе, пробувај повеќе, повторувај повеќе.

II. Два вида „мрзеливост“ ги уништуваат вашите инженерски способности

По прегледот на оние неколку „браќа од сто милиони“ во областа за коментари, открив дека коренот на наглиот пораст на токените не е само проблемот со механизмот за потрошувачка на вештачката интелигенција, туку е тесно поврзан и со мрзеливоста на луѓето.

Постојат два типични типа на „ментална мрзеливост“.

Мрзеливост прва: Тип на менаџер со слободни раце

Дали го имате и овој менталитет:

• „Овој стар проект е премногу неуреден, премногу сум мрзлив да ја гледам логиката, само ќе му го фрлам на вештачката интелигенција.“

• „Cursor излезе со режим Agent, одлично, нека сам ги поправа грешките.“

Така, ја фрлате целата папка src на Agent и издавате нејасна инструкција: „Помогни ми да го оптимизирам корисничкиот модул.“ Agent почнува да работи:

• Чита 50 датотеки (троши 500.000).

• Открива дека utils е цитиран, па оди да ги чита класите на алатки (троши 200.000).

• Се обидува да направи промени, се појавува грешка, ги чита логовите за грешки (троши 100.000).

• Се обидува да ја поправи, повторно се појавува грешка...

Тој лудо пробува и греши, лудо троши токени. А вие? Вие скролате на вашиот телефон, чувствувајќи се дека сте навистина ефикасни. Вистината е: вие разменувате „псевдо-ефикасност“ за пари, произведувајќи куп код што не можете да го одржувате подоцна.

Попрофесионално кажано, тука има два слоја на загуби:

• Слој на трошоци: Влезните токени стануваат поголеми, бројот на итерации се зголемува, а трошоците се собираат линеарно

• Инженерски слој: Го губите контекстот и моќта за одлучување, а на крајот останува само неконтролиран систем кој е „доволно добар за да работи“

Мрзеливост втора: Тип на фрлање сè во куп

Како му ја давате грешката на вештачката интелигенција кога ќе наидете на грешка? Дали директно го копирате целиот конзола за грешки со Ctrl+A, или директно @Codebase за да дозволите вештачката интелигенција сама да го најде?

Ова се нарекува „фрлање сè во куп“. Премногу сте мрзливи да ја лоцирате суштината на проблемот, премногу сте мрзливи да ги филтрирате клучните фрагменти од кодот. Фрлате 99% од невалидните информации (шум) и 1% од валидните информации (сигнал) во вештачката интелигенција.

Вештачката интелигенција е како засилувач.

• Ако му дадете јасна логика (сигнал), тој ја засилува вашата мудрост, троши помалку токени и има добар ефект.

• Ако му дадете хаос и нејасност, тој го засилува вашиот хаос, токените вртоглаво растат и произведуваат ѓубре.

III. Решение: Како ефикасно да се користи вештачката интелигенција и да се намали потрошувачката на токени

За да го заштитите вашиот паричник, уште поважно е да ја заштитите вашата инженерска контрола, мора да го промениме нашиот модел на соработка со вештачката интелигенција.

1. Принцип на минимален контекст

Ова е првиот принцип на програмирање со вештачка интелигенција. Секогаш давајте му на вештачката интелигенција само минимален сет на кодови што одговараат на тековниот проблем.

Во Cursor, добро искористете ги овие оператори:

• @File: Цитирајте само релевантни датотеки, а не цели папки.

• Ctrl+L** Изберете код**: Испратете само 50 линии код избрани од курсорот до Chat, а не целата датотека.

• @Docs: За библиотеки од трети страни, цитирајте документација наместо да дозволите да погодува.

Ова е структуриран SOP што често го користам и може повторно да се користи (ако го следите, токените ќе паднат видливо):

Оваа реченица значи: Кога соработувате со вештачката интелигенција, треба да обрнете внимание на ефикасноста и прецизноста. Специфичните практики се следниве:

• Прво, разјаснете ја целта: Кажете му на вештачката интелигенција за тековниот проблем и посакуваниот резултат накратко и концизно, не дозволувајте да погодува.

• Рационализирајте ја репродукцијата на проблемот: Ако можете да користите наједноставен метод за да го репродуцирате проблемот, не користете сложени методи, објавете го најмалку и клучниот код, не натрупувајте голема количина на неповрзана содржина.

• Обезбедете минимални потребни информации: Дајте само 1-3 релевантни датотеки, клучни функции и првите неколку линии од стекот за грешки, не користете информации за целата количина.

• Побарајте да ги вратите точките за модификација: Дозволете вештачката интелигенција да ви каже само каде да се смени и зошто да се смени, не дозволувајте да го препише целиот текст во долги пасуси.

• Конечно, сами проверете: Направете ја наједноставната проверка за да се осигурате дека промените не влијаат на други места.

Накратко, користете ги најмалку и најважните информации за да ја натерате вештачката интелигенција да работи и задржете ја конечната контрола и проценка.

2. Исто така, најважното: Прво размислете, потоа Prompt, прво планирајте, потоа дејствувајте

Пред да го притиснете копчето Enter, присилете се да застанете 10 секунди и да си ги поставите следниве три прашања:

• Кој проблем го решавам? (Дефинирајте ги границите)

• Кои основни модули се вклучени во овој проблем? (Филтрирајте го контекстот)

• Како би го напишал сам? (Обезбедете идеи)

Вие сте 1, а вештачката интелигенција е 0 зад неа. Ако 1 не може да се воспостави, без оглед колку 0 има зад неа, тоа е само бесмислена потрошувачка.

Неколку искрени зборови

Приказната за „сто милиони токени дневно“ можеби нема да му се случи на секого. Но, однесувањето на трошење токени речиси секој програмер што користи програмирање со вештачка интелигенција ќе го доживее.

Иако вештачката интелигенција го олеснува програмирањето, сè уште има праг. Оние кои навистина знаат како да го користат ќе бидат како тигар со крилја.

Во минатото, лошиот код што го пишувавте само ќе ги „згрози“ вашите колеги. Сега, мрзеливоста што ја крадете директно ќе се претвори во бројка на сметката, казнувајќи се себеси со вртоглави трошоци. Затоа, не бидете „неактивен менаџер“. Бидете AI архитект кој длабоко размислува, прецизно се изразува и планира пред да дејствува. Ова е исто така нашата најголема незаменливост во оваа ера.