الجمهور المستهدف: المطورون الذين يستخدمون أدوات برمجة الذكاء الاصطناعي (مثل Cursor و Windsurf و trae...) والمديرون التقنيون الذين يفتقرون إلى الوعي بتكاليف الذكاء الاصطناعي.

الرأي الأساسي: Token ليست مجرد وحدة محاسبة بسيطة، بل هي "مورد انتباه" و "عملة قوة حاسوبية". إن إساءة استخدام نمط Agent وتجاهل إدارة السياق هو في الواقع تغطية للكسل الاستراتيجي (عدم التفكير) بالاجتهاد التكتيكي (جعل الذكاء الاصطناعي يتخبط).

قد تكون "نفقات الذكاء الاصطناعي" الخاصة بك أعلى من راتبك

قبل بضعة أيام، راجعت فاتورة Token الخاصة بي. عندما رأيت هذا الرقم، فوجئت قليلاً: 10 ملايين Token. لاحظ أن هذا ليس الاستهلاك الشهري، بل يوميًا.

اعتقدت أن هذا كان شاذًا. في وقت لاحق، نشرت مقطع فيديو قصيرًا متعلقًا بحساب Token.

نتيجة لذلك، أظهر لي قسم التعليقات ما هو "السماء فوق السماء".

الصورة أدناه هي لقطة شاشة لسجل استهلاك 200 مليون Token في يوم واحد للمستخدم "Old K's Daily":

في البداية، اعتقدت أنه قد يكون حالة فردية، ولكن عندما علق العديد من المستخدمين قائلين إنهم يستهلكون 100 مليون يوميًا، أدركت أن هذه ظاهرة شائعة جدًا.

ما هو مفهوم مائة مليون Token؟ إذا تم حسابه وفقًا للمستوى الشائع لـ "بعض النماذج التجارية السائدة" (يتم احتساب رسوم الإدخال/الإخراج بشكل منفصل، ويتم تقديرها بشكل تقريبي عند 10 دولارات أمريكية / مليون Token)، فإن هذا اليوم يحرق 1000 دولار. حرق 7000 يوان صيني في اليوم. قد لا يكون راتب العديد من المبرمجين المبتدئين كافيًا لـ "تفكير" الذكاء الاصطناعي في هذا اليوم.

(ملاحظة: تختلف أسعار النماذج/الموردين المختلفة اختلافًا كبيرًا، وغالبًا ما يختلف سعر الوحدة للإدخال والإخراج. الغرض هنا ليس الحساب بدقة إلى منزلتين عشريتين، ولكن أولاً إنشاء "إحساس بالحجم".)

إذا كنت ترغب في إعادة الحساب بنفسك، فعادة ما تكون هذه هي الصيغة (مع تجاهل التخزين المؤقت/الخصومات والقواعد الخاصة الأخرى): التكلفة ≈ (إدخال Token / 1,000,000) × سعر الوحدة_in + (إخراج Token / 1,000,000) × سعر الوحدة_out

هذا الأمر غير بديهي للغاية. نعتقد دائمًا أن الذكاء الاصطناعي رخيص، بل إن OpenAI ستخفض الأسعار. ولكن لماذا في الهندسة الفعلية، يظهر استهلاك Token تضخمًا أسيًا؟

اليوم، سأقود الجميع لتحليل متعمق للمنطق الكامن وراء "الثقب الأسود Token" هذا، وكيف يجب علينا وقف الخسائر.

أولاً، لماذا "ينفجر" Token بشكل أسي؟

العديد من الإخوة ليس لديهم أي مفهوم عن حجم Token. يعتقدون: "أوه، أليس هذا مجرد إرسال بضعة أسطر من التعليمات البرمجية؟ كم يمكن أن يكون؟"

1. حساب واضح

لنبدأ بإنشاء إدراك كمي قابل للاستخدام هندسيًا. لنكن حاسمين: Token ليس عدد الكلمات، ولا عدد الأحرف. إنه "جزء ترميز" بعد أن يقوم النموذج بتقسيم النص، وتستخدم النماذج المختلفة أدوات تقسيم مختلفة، لذلك لا يمكن إعطاء سوى نطاق، وليس ثابتًا "ينطبق على الجميع".

الأرقام التالية، تعامل معها على أنها "مقياس تقدير" (الغرض هو تحديد الحجم وتقدير التكلفة واتخاذ قرارات وقف الخسائر):

• حرف صيني واحد: شائع في 1-2 Token (الحروف عالية التردد أقرب إلى 1، والحروف/المجموعات النادرة أسهل في الوصول إلى 2-3)

• كلمة إنجليزية واحدة: شائعة في حوالي 1.2-1.5 Token (يمكن أيضًا استخدام 1.3 للتقدير التقريبي)

• سطر واحد من التعليمات البرمجية ≈ 10-50 Token (بما في ذلك المسافة البادئة والتعليقات وإعلانات النوع)

• منطق عمل بسيط ≈ 12-20 Token

• مع تعليقات توضيحية للنوع و interface و JSDoc ومسافة بادئة 4 مسافات ≈ 20-35 Token

• مع عدد كبير من import / الزخارف / التعليقات ≈ 30-50+ Token

• ملف مصدر واحد (400-600 سطر، مشروع TS/Java حديث) ≈ 4,000-24,000 Token شائع جدًا (متوسط ≈ 12,000-18,000)

• مشروع متوسط الحجم (100-200 ملف مصدر، فقط حساب src/، لا يشمل node_modules/ / التعليمات البرمجية التي تم إنشاؤها)

• غالبًا ما يكون "قراءة" التعليمات البرمجية المصدرية الأساسية "نقطة انطلاق" لملايين Token

• إذا تم تضمين الاختبارات والتكوينات والنصوص وإعلانات التبعية والسجلات، فليس من غير المألوف أن يصل إلى عشرات الملايين من Token

مشاريع الواجهة الأمامية الحالية هي TypeScript، مليئة بتعريفات Interface المعقدة؛ أو Java، مع عشرات الأسطر من Import في كل منعطف. هذه "التعليمات البرمجية النموذجية" هي في الواقع قتلة Token. إذا كان لدى مشروع متوسط الحجم 100 ملف، فإن مجرد السماح للذكاء الاصطناعي "بقراءة التعليمات البرمجية" قد يقتل مليون Token مباشرة.

2. تأثير "كرة الثلج" لـ token

إن أكثر ما يخيف في استهلاك Token ليس المحادثة الفردية، بل تراكم السياق في المحادثات المتعددة.

آلية LLM هي عديمة الحالة. لكي يتذكر الذكاء الاصطناعي ما قلته في الجملة السابقة، عادةً ما يقوم النظام بتجميع "مطالبات النظام + المحادثات السابقة + مقتطفات الملفات/التعليمات البرمجية التي أشرت إليها + إخراج استدعاءات الأدوات (مثل نتائج البحث وسجلات الأخطاء)" وإرسالها إلى النموذج. أنت تعتقد أنك طرحت سؤالاً واحدًا فقط، ولكنك في الواقع تدفع بشكل متكرر مقابل "حزمة السياق بأكملها".

• الجولة الأولى: إرسال 10,000 Token، يرد الذكاء الاصطناعي بـ 1,000.

• الجولة الثانية: إرسال (10,000 + 1,000 + سؤال جديد)، يرد الذكاء الاصطناعي...

• الجولة العاشرة: قد يكون السياق الخاص بك قد تضخم بالفعل إلى 200,000 Token.

في هذا الوقت، حتى لو سألت فقط "ساعدني في تغيير اسم متغير"، فإنك تستهلك رسوم 200,000 Token. هذا هو السبب في أنك تشعر أنك لم تفعل أي شيء، لكن فاتورتك ترتفع بسرعة.

والأسوأ من ذلك: نمط Agent "يقرأ الملفات بنشاط". إذا قلت "ساعدني في تحسين وحدة المستخدم"، فقد يقوم أولاً بمسح الدليل ذي الصلة، ثم تتبع التبعيات، ثم تتبع التكوين، ثم تتبع الاختبار... إنه لا يتهرب من المسؤولية، بل "يؤدي واجبه وفقًا للاستراتيجية الافتراضية"، والاستراتيجية الافتراضية غالبًا ما تكون: اقرأ أكثر، وجرّب أكثر، وكرّر أكثر.

ثانيًا، نوعان من "الكسل" يدمران قدراتك الهندسية

بعد مراجعة أولئك "المليونير" في قسم التعليقات، وجدت أن جذر الارتفاع الشديد في Token ليس فقط مشكلة آلية استهلاك الذكاء الاصطناعي، ولكن أيضًا مرتبط ارتباطًا وثيقًا بالكسل البشري.

فيما يلي نوعان نموذجيان من "الكسل الفكري".

الكسل الأول: نوع المدير المتنحي

هل لديك أيضًا هذه العقلية:

• "هذا المشروع القديم فوضوي للغاية، أنا كسول جدًا بحيث لا أستطيع النظر إلى المنطق، فلأرميه مباشرة على الذكاء الاصطناعي."

• "أصدر Cursor نمط Agent، هذا رائع، دعه يصلح الأخطاء بنفسه."

لذلك، تقوم بإلقاء مجلد src بأكمله على Agent، وإصدار تعليمات غامضة: "ساعدني في تحسين وحدة المستخدم." يبدأ Agent في العمل:

• يقرأ 50 ملفًا (يستهلك 500,000).

• يجد أنه يشير إلى utils، ثم يذهب لقراءة فئات الأدوات (يستهلك 200,000).

• يحاول التعديل، ويحدث خطأ، ويقرأ سجلات الأخطاء (يستهلك 100,000).

• يحاول الإصلاح، ويحدث خطأ مرة أخرى...

إنه يجرب ويخطئ بجنون، ويستهلك Token بجنون. وماذا عنك؟ أنت تتصفح هاتفك، وتشعر أنك فعال حقًا. الحقيقة هي: أنك تستخدم المال مقابل "الكفاءة الزائفة"، وتنتج كومة من التعليمات البرمجية التي لا يمكنك صيانتها لاحقًا.

بشكل أكثر احترافية، هناك خسارتان هنا:

• مستوى التكلفة: يزداد إدخال Token، ويزداد عدد التكرارات، وتتراكم الرسوم خطيًا

• المستوى الهندسي: تفقد السياق وسلطة اتخاذ القرار، وفي النهاية لا يتبقى سوى نظام غير قابل للتحكم "يعمل فقط"

الكسل الثاني: نوع كل شيء معًا

عندما تواجه خطأ، كيف ترميه على الذكاء الاصطناعي؟ هل تقوم مباشرة بنسخ Ctrl+A لوحدة تحكم الخطأ بأكملها، أو @Codebase للسماح للذكاء الاصطناعي بالعثور عليها بنفسه؟

هذا يسمى "كل شيء معًا". أنت كسول جدًا بحيث لا يمكنك تحديد جوهر المشكلة، وكسول جدًا بحيث لا يمكنك تصفية مقتطفات التعليمات البرمجية الرئيسية. أنت ترمي 99٪ من المعلومات غير الصالحة (الضوضاء) و 1٪ من المعلومات الصالحة (الإشارة) على الذكاء الاصطناعي.

الذكاء الاصطناعي يشبه المضخم.

• إذا أعطيته منطقًا واضحًا (إشارة)، فإنه يضخم حكمتك، ويتم استخدام عدد قليل من Token، والتأثير جيد.

• إذا أعطيته فوضى وغامضة، فإنه يضخم فوضاك، وترتفع Token بسرعة، وتنتج قمامة.

ثالثًا، الحل: كيفية استخدام الذكاء الاصطناعي بكفاءة وتقليل استهلاك Token

للحفاظ على محفظتك، والأهم من ذلك الحفاظ على السيطرة الهندسية الخاصة بك، يجب علينا تغيير نمط التعاون مع الذكاء الاصطناعي.

1. مبدأ الحد الأدنى من السياق

هذا هو المبدأ الأول لبرمجة الذكاء الاصطناعي. دائمًا ما تعطي الذكاء الاصطناعي الحد الأدنى من مجموعة التعليمات البرمجية المقابلة لحل المشكلة الحالية.

في Cursor، استخدم هذه العوامل بكفاءة:

• @File: أشر فقط إلى الملفات ذات الصلة، وليس المجلد بأكمله.

• Ctrl+L تحديد التعليمات البرمجية: أرسل فقط 50 سطرًا من التعليمات البرمجية التي حددها المؤشر إلى الدردشة، وليس الملف بأكمله.

• @Docs: بالنسبة لمكتبات الطرف الثالث، أشر إلى الوثائق بدلاً من السماح لها بالتخمين.

هذا هو SOP المنظم والقابل لإعادة الاستخدام الذي أستخدمه غالبًا (إذا فعلت ذلك، فسوف تنخفض Token بشكل واضح للعين):

هذا يعني: عند التعاون مع الذكاء الاصطناعي، انتبه إلى الكفاءة والدقة. فيما يلي طرق محددة للقيام بذلك:

• أولاً حدد الهدف: أخبر الذكاء الاصطناعي بإيجاز المشكلة الحالية والنتيجة المرجوة، ولا تدعه يخمن بنفسه.

• تبسيط إعادة إنتاج المشكلة: إذا كان من الممكن إعادة إنتاج المشكلة بأبسط طريقة، فلا تستخدم طريقة معقدة، والصق الحد الأدنى من التعليمات البرمجية الهامة، ولا تكدس الكثير من المحتوى غير ذي الصلة.

• توفير الحد الأدنى من المعلومات الضرورية: ما عليك سوى إعطاء 1-3 ملفات ذات صلة والوظائف الرئيسية والأسطر القليلة الأولى من مكدس الأخطاء، وليس المعلومات الكاملة.

• طلب إرجاع نقاط التعديل: دع الذكاء الاصطناعي يخبرك فقط بمكان التعديل وسبب التعديل، ولا تدعه يعيد كتابة التعليمات البرمجية بأكملها على نطاق واسع.

• أخيرًا، قم أنت بالتحقق: قم بإجراء أبسط تحقق للتأكد من أن التغييرات لا تؤثر على أماكن أخرى.

باختصار، استخدم الحد الأدنى من المعلومات الهامة للسماح للذكاء الاصطناعي بالقيام بالأشياء، والاحتفاظ بالسيطرة النهائية والحكم.

2. والأهم من ذلك: فكر أولاً، ثم اطلب، وخطط أولاً، ثم تصرف

قبل الضغط على Enter، أجبر نفسك على التوقف لمدة 10 ثوانٍ، واسأل نفسك ثلاثة أسئلة:

• ما هي المشكلة التي أحاول حلها؟ (تحديد الحدود)

• ما هي الوحدات الأساسية التي تتضمنها هذه المشكلة؟ (تصفية السياق)

• إذا كنت سأكتبها بنفسي، فكيف سأكتبها؟ (توفير الأفكار)

أنت 1، والذكاء الاصطناعي هو 0 بعد ذلك. إذا لم يتمكن 1 من الوقوف، فمهما كان عدد الأصفار بعد ذلك، فهو مجرد استهلاك لا معنى له.

بضع كلمات من القلب

قد لا تحدث قصة "مائة مليون Token في اليوم" للجميع. لكن سلوك إهدار Token هو تجربة يمر بها كل مبرمج يستخدم برمجة الذكاء الاصطناعي تقريبًا.

على الرغم من أن الذكاء الاصطناعي يجعل البرمجة أسهل، إلا أنه لا يزال هناك عتبة. فقط أولئك الذين يعرفون كيفية استخدامه حقًا سيحصلون على ميزة إضافية.

في الماضي، كانت التعليمات البرمجية السيئة التي كتبتها "تثير اشمئزاز" الزملاء فقط. الآن، الكسل الذي تتهرب منه سيتحول مباشرة إلى أرقام في الفاتورة، ويعاقب نفسك بتكاليف متزايدة.لذا، لا تكن "متفرجًا". كن مهندسًا معماريًا للذكاء الاصطناعي يتمتع بتفكير عميق، وتعبير دقيق، وتخطيط مسبق قبل التنفيذ. هذه أيضًا هي أكبر ميزة لدينا التي لا يمكن الاستغناء عنها في هذا العصر.