Зорилтот уншигчид: Cursor, Windsurf, trae гэх мэт хиймэл оюун ухааны програмчлалын хэрэгслийг ашиглаж буй хөгжүүлэгчид, мөн хиймэл оюун ухааны зардлын талаар хангалттай ойлголтгүй байгаа технологийн менежерүүд.

Гол санаа: Token бол энгийн төлбөрийн нэгж биш, харин "анхаарлын нөөц" ба "тооцоолох хүчин чадлын валют" юм. Agent загварыг буруугаар ашиглах, контекстийн удирдлагыг үл тоомсорлох нь тактикийн хичээнгүй байдлыг (хиймэл оюун ухааныг дэмий ажиллуулах) стратегийн залхуурал (өөрсдөө бодохгүй байх)-аар халхавчлах явдал юм.

Таны "хиймэл оюун ухааны зардал" таны цалингаас ч өндөр байж магадгүй

Хэд хоногийн өмнө би Token-ийн төлбөрийн жагсаалтаа шалгасан. Тэр тоог хараад би гайхсан: 10 сая Token. Энэ нь нэг сарын хэрэглээ биш, харин нэг өдөр гэдгийг анхаарна уу.

Би үүнийг хэтэрхий гэж бодсон. Дараа нь би Token тооцоолохтой холбоотой богино хэмжээний видео нийтэлсэн.

Үр дүнд нь сэтгэгдлийн хэсэгт "тэнгэрийн гадна тэнгэр бий" гэж юу болохыг би харсан.

Доорх зураг бол "Хөгшин К-ийн өдөр тутмын амьдрал" хэрэглэгчийн нэг өдрийн хоёр зуун сая Token зарцуулсан бүртгэлийн дэлгэцийн зураг юм:

Эхэндээ би үүнийг ганц тохиолдол гэж бодсон, гэхдээ олон хэрэглэгчид өдөрт нэг зуун сая зарцуулдаг гэж хэлэхэд би үүнийг маш түгээмэл үзэгдэл гэдгийг ойлгосон.

Нэг зуун сая Token гэж юу вэ? Хэрэв "зарим гол арилжааны загвар"-ын нийтлэг төлбөрийн хэмжээгээр (оролт/гаралтыг тусад нь төлбөр тооцож, ойролцоогоор 10 доллар / сая Token гэж тооцоолбол) энэ өдөр 1000 доллар шатаасан гэсэн үг. Нэг өдөрт 7000 юань шатаасан. Олон залуу программистуудын нэг сарын цалин хиймэл оюун ухааныг энэ өдөр "бодоход" хүрэлцэхгүй байж магадгүй юм.

(Тайлбар: Өөр өөр загвар/нийлүүлэгчийн үнэ маш их ялгаатай, оролт ба гаралтын нэгжийн үнэ ч бас байнга өөр байдаг. Энд зорилго нь бутархай орны нарийвчлалтай тооцоолох биш, харин эхлээд "хэмжээний мэдрэмж"-ийг бий болгох явдал юм.)

Хэрэв та өөрөө дахин тооцоолохыг хүсвэл ерөнхийдөө энэ томъёог ашиглана (кэш/хөнгөлөлт гэх мэт тусгай дүрмийг үл тоомсорлоно): Зардал ≈ (Оролтын Token / 1,000,000) × Нэгжийн үнэ_in + (Гаралтын Token / 1,000,000) × Нэгжийн үнэ_out

Энэ нь хэтэрхий зөн совингийн эсрэг байна. Бид хиймэл оюун ухааныг хямд гэж үргэлж боддог, OpenAI бүр үнээ бууруулах гэж байна. Гэхдээ яагаад бодит инженерийн практикт Token-ийн хэрэглээ экспоненциал байдлаар дэлбэрч байна вэ?

Өнөөдөр бид бүгдээрээ энэ "Token хар нүх"-ний цаад логикийг гүнзгий задлан шинжилж, хэрхэн хохирлоос зайлсхийх талаар ярилцах болно.

Нэг. Яагаад Token "экспоненциал байдлаар дэлбэрч" байна вэ?

Олон ах дүүс Token-ийн хэмжээний талаар ямар ч ойлголтгүй байна. Тэд боддог: "За, хэд хэдэн код илгээхэд л хангалттай, хэр их байх вэ?"

1. Ойлгогдохуйц тооцоо хийх

Бид эхлээд инженерийн хувьд хангалттай тоон мэдрэмжийг бий болгох хэрэгтэй. Эхлээд үүнийг үхсэн үг гэж хэлье: Token бол үгийн тоо биш, тэмдэгтийн тоо ч биш. Энэ нь загвар текстийг хуваасны дараах "кодчилсон хэсэг" бөгөөд өөр өөр загварууд өөр өөр tokenizer ашигладаг тул зөвхөн завсар өгч болно, "хаана ч ашиглаж болох" тогтмол өгч чадахгүй.

Доорх тоонуудыг "тооцооллын хэмжүүр" гэж үзээрэй (зорилго нь хэмжээг тодорхойлох, зардлыг урьдчилан тооцоолох, хохирлыг зогсоох шийдвэр гаргах):

• 1 хятад ханз: нийтлэг 1–2 Token (давтамж өндөртэй үг 1-д ойр, ховор үг/хослол 2–3-д хүрэхэд хялбар)

• 1 англи үг: нийтлэг 1.2–1.5 Token орчим (ойролцоогоор 1.3 гэж тооцоолж болно)

• 1 мөр код ≈ 10–50 Token (зай, тайлбар, төрлийн мэдэгдэл агуулсан)

• Энгийн бизнесийн логик ≈ 12–20 Token

• Төрлийн тайлбар, interface, JSDoc, 4 зайтай ≈ 20–35 Token

• Их хэмжээний import / чимэглэгч / тайлбартай ≈ 30–50+ Token

• 1 эх сурвалжийн файл (400–600 мөр, орчин үеийн TS/Java төсөл) ≈ 4,000–24,000 Token маш түгээмэл (дундаж ≈ 12,000–18,000)

• 1 дунд хэмжээний төсөл (100–200 эх сурвалжийн файл, зөвхөн src/-ийг тооцно, node_modules/ / үүсгэсэн код агуулаагүй)

• Гол эх сурвалжийн кодыг "бүхэлд нь унших" нь ихэвчлэн сая Token-оос эхэлдэг

• Хэрэв та туршилт, тохиргоо, скрипт, хамаарлын мэдэгдэл, логийг хамтад нь хийвэл хэдэн арван сая Token ч ховор биш

Одоогийн frontend төслүүд нь TypeScript бөгөөд нарийн төвөгтэй Interface тодорхойлолтоор дүүрэн байдаг; эсвэл Java, хэдэн арван мөрийн Import-той байдаг. Эдгээр "загвар код" нь үнэндээ Token алуурчид юм. Дунд хэмжээний төсөл 100 файлтай бол хиймэл оюун ухааныг "кодыг уншуулахад" л 1 сая Token шууд устгаж магадгүй юм.

2. Token-ийн "цасан бөмбөг" эффект

Token-ийн хэрэглээний хамгийн аймшигтай зүйл бол нэг удаагийн яриа биш, харин олон удаагийн ярианы контекст хуримтлагдах явдал юм.

LLM-ийн механизм нь төлөвгүй байдаг. Хиймэл оюун ухааныг таны өмнөх хэлсэн зүйлийг санаж байхын тулд систем нь ихэвчлэн "системийн сануулга + түүхэн яриа + таны иш татсан файл/кодын хэсэг + хэрэгслийн дуудлагын гаралт (жишээлбэл, хайлтын үр дүн, алдааны лог)"-ыг хамтад нь багцалж загварт илгээдэг. Та зөвхөн нэг асуулт асуусан гэж бодож байгаа ч үнэн хэрэгтээ та "бүхэл контекст багцын" төлөө дахин дахин төлбөр төлж байна.

• 1-р шат: 10 мянган Token илгээхэд хиймэл оюун ухаан 1 мянган хариулт өгдөг.

• 2-р шат: (10 мянга + 1 мянга + шинэ асуулт) илгээхэд хиймэл оюун ухаан хариулт өгдөг...

• 10-р шат: Таны Context 200 мянган Token хүртэл томорсон байж магадгүй юм.

Энэ үед та "хувьсагчийн нэрийг өөрчлөхөд тусал" гэж асуухад л 200 мянган Token-ийн төлбөр төлөх болно. Тиймээс та юу ч хийгээгүй гэж бодож байгаа ч төлбөр огцом өсөж байна.

Хамгийн муу нь: Agent загвар нь "файлыг идэвхтэй уншдаг". Та "хэрэглэгчийн модулийг оновчтой болгоход тусал" гэж хэлэхэд эхлээд холбогдох директорыг сканнердаж, дараа нь хамаарлыг хөөж, дараа нь тохиргоог хөөж, дараа нь туршилтыг хөөж болно... Энэ нь залхуураагүй, харин "анхдагч стратегийн дагуу үүрэг хүлээж" байгаа бөгөөд анхдагч стратеги нь ихэвчлэн: илүү унших, илүү оролдох, илүү давтах байдаг.

Хоёр. Хоёр төрлийн "залхуурал" таны инженерийн чадварыг сүйтгэж байна

Сэтгэгдлийн хэсэгт байгаа "нэг зуун сая ах"-уудыг эргэн харж үзсэний дараа Token-ийн огцом өсөлтийн үндэс нь зөвхөн хиймэл оюун ухааны хэрэглээний механизмтай холбоотой төдийгүй хүний залхуурал-тай нягт холбоотой болохыг би олж мэдсэн.

Доор хоёр төрлийн "сэтгэлгээний залхуурал" байна.

Залхуурал нэг: Гараа хумхиад суух хэлбэр

Танд ийм сэтгэлгээ бий юу?

• "Энэ хуучин төсөл хэтэрхий эмх замбараагүй байна, би логикийг нь харах дургүй, шууд хиймэл оюун ухаанд өгье."

• "Cursor Agent загварыг гаргасан, маш сайн байна, өөрөө алдааг засуулъя."

Тиймээс та бүх src хавтасыг Agent-д өгч, бүдэг бүрхэг заавар өгсөн: "Хэрэглэгчийн модулийг оновчтой болгоход тусал." Agent ажиллаж эхэлсэн:

• 50 файл уншсан (500 мянган зарцуулсан).

• utils-ийг иш татсаныг олж мэдээд дахин хэрэгслийн ангиллыг уншсан (200 мянган зарцуулсан).

• Өөрчлөлт оруулах гэж оролдсон, алдаа гарсан, алдааны логийг уншсан (100 мянган зарцуулсан).

• Засах гэж оролдсон, дахин алдаа гарсан...

Энэ нь галзууруулан туршиж, Token-ийг галзууруулан зарцуулж байна. Харин та юу хийж байна вэ? Та утсаа үзэж, үр ашигтай ажиллаж байна гэж бодож байна. Үнэн хэрэгтээ: та мөнгөөрөө "хуурамч үр ашиг" худалдаж авч, дараа нь засварлаж чадахгүй кодын овоолго үүсгэсэн.

Илүү мэргэжлийн хэлээр энд хоёр давхар хохирол байна:

• Зардлын давхарга: Оролтын Token томрох, давталтын тоо нэмэгдэх, төлбөр шугаман байдлаар нэмэгдэх

• Инженерийн давхарга: Та контекст ба шийдвэр гаргах эрхээ алдаж, эцэст нь "ажиллаж байвал болно" гэсэн хяналтгүй систем үлдэнэ

Залхуурал хоёр: Шавар шавхай холих хэлбэр

Алдаа гарсан үед та хиймэл оюун ухаанд хэрхэн өгдөг вэ? Та шууд Ctrl+A хийж бүх алдааны консолыг хуулж, эсвэл хиймэл оюун ухааныг өөрөө олоход @Codebase хийдэг үү?

Үүнийг "шавар шавхай холих" гэж нэрлэдэг. Та асуудлын гол цөмийг тодорхойлох дургүй, гол кодын хэсгийг шүүх дургүй. Та 99% үр ашиггүй мэдээлэл (дуу чимээ) ба 1% үр ашигтай мэдээлэл (дохио)-ыг нэг дор хиймэл оюун ухаанд хийдэг.

Хиймэл оюун ухаан бол өсгөгч шиг.

• Та түүнд тодорхой логик (дохио) өгөхөд таны мэргэн ухааныг өсгөж, Token бага зарцуулж, үр дүн нь сайн байдаг.

• Та түүнд эмх замбараагүй байдал ба бүдэг бадаг зүйл өгөхөд таны эмх замбараагүй байдлыг өсгөж, Token огцом өсөж, хог хаягдал үүсгэдэг.

Гурав. Шийдэл: Хиймэл оюун ухааныг хэрхэн үр ашигтай ашиглах, Token-ийн хэрэглээг бууруулах

Түрийвчээ хамгаалахын тулд хамгийн чухал нь инженерийн хяналтаа хамгаалах явдал бөгөөд бид хиймэл оюун ухаантай хамтран ажиллах загвараа өөрчлөх ёстой.

1. Хамгийн бага контекстийн зарчим

Энэ бол хиймэл оюун ухааны програмчлалын анхдагч зарчим юм. Хиймэл оюун ухаанд зөвхөн тухайн асуудлыг шийдвэрлэхэд шаардлагатай хамгийн бага кодын багцыг өг.

Cursor-т эдгээр үйлдлийг сайн ашиглаарай:

• @File: Бүхэл хавтасыг биш, харин холбогдох файлыг л иш татна.

• Ctrl+L** Кодыг сонгох**: Бүх файлыг биш, харин курсороор сонгосон 50 мөрийг Chat-д илгээнэ.

• @Docs: Гуравдагч талын санг ашиглахдаа таахын оронд баримт бичгийг иш татна.

Энэ бол миний байнга ашигладаг, бүтэцтэй, дахин ашиглах боломжтой SOP юм (та үүнийг дагаж хийвэл Token нүдэнд харагдахуйц буурна):

Энэ үгийн утга нь хиймэл оюун ухаантай хамтран ажиллахдаа үр ашигтай, нарийвчлалтай байх ёстой гэсэн үг юм. Тодруулбал дараах байдлаар хийнэ:

• Эхлээд зорилгоо тодорхой болго: Хиймэл оюун ухаанд тухайн асуудал ба хүссэн үр дүнг товч бөгөөд тодорхой хэлж, өөрөө таах боломж олгохгүй.

• Асуудлыг хамгийн бага хэмжээнд хүртэл багасгах: Асуудлыг хамгийн энгийн аргаар дахин гаргаж чадвал нарийн төвөгтэй аргыг ашиглах шаардлагагүй, хамгийн бага бөгөөд гол кодыг нааж, холбоогүй асар их агуулга овоолохгүй.

• Хамгийн бага шаардлагатай мэдээллийг өгөх: Зөвхөн холбогдох 1-3 файл, гол функц ба алдааны овоолгын эхний хэдэн мөрийг өгөхөд хангалттай, бүх мэдээллийг өгөх шаардлагагүй.

• Өөрчлөлтийн цэгийг буцааж өгөхийг шаардах: Хиймэл оюун ухааныг хаана өөрчлөх, яагаад өөрчлөх ёстойг хэлэхийг хүсч, бүх кодыг их хэмжээгээр дахин бичих боломж олгохгүй.

• Эцэст нь өөрөө хяналт тавих: Өөрчлөлт нь бусад газарт нөлөөлөхгүй байхын тулд хамгийн энгийн баталгаажуулалтыг хийх.

Товчхондоо хамгийн бага, хамгийн чухал мэдээллийг ашиглан хиймэл оюун ухааныг ажиллуулж, эцсийн хяналт ба шийдвэр гаргах эрхээ хадгалах.

2. Хамгийн чухал нь: Эхлээд бодож, дараа нь Prompt хийж, эхлээд төлөвлөж, дараа нь ажиллах

Enter товчийг дарахаасаа өмнө өөрийгөө 10 секунд зогсоож, дараах гурван асуултыг асуу:

• Би ямар асуудал шийдэж байна вэ? (Хил хязгаарыг тодорхойлох)

• Энэ асуудал ямар гол модулиудтай холбоотой вэ? (Context-ийг шүүх)

• Хэрэв би өөрөө бичвэл яаж бичих вэ? (Санаа өгөх)

Та 1, хиймэл оюун ухаан бол ард нь байгаа 0. Хэрэв 1 тогтвортой байхгүй бол ард нь байгаа 0 хэчнээн их байсан ч утгагүй хэрэглээ болно.

Хэдэн үг зүрх сэтгэлээсээ хэлье

"Нэг өдөрт нэг зуун сая Token"-ийн түүх хүн бүрт тохиолдохгүй байж магадгүй юм. Гэхдээ Token-ийг үрэх үйлдэл хиймэл оюун ухааны програмчлалыг ашигладаг бараг бүх программистуудад тохиолддог.

Хиймэл оюун ухаан програмчлалыг илүү хялбар болгосон ч гэсэн босго хэвээр байна. Жинхэнэ хэрэглэж чаддаг хүмүүс жигүүртэй бар шиг болно.

Өмнө нь таны бичсэн муу код зөвхөн хамт ажиллагсдаа "дотор муухайруулдаг" байсан. Одоо таны залхуурсан зүйл шууд төлбөрийн жагсаалтад тоогоор гарч, өссөн зардлаар өөрийгөө шийтгэх болно.Тиймээс "хариуцлагагүй эзэн" бүү хий. Гүн гүнзгий сэтгэж, нарийн илэрхийлж, төлөвлөсний дараа хөдөл AI архитектор хий. Энэ бол бидний энэ эринд орлуулашгүй хамгийн том зүйл юм.