أبرز النقاط
- ابدأ بنموذج متوازن مثل Gemini 3.5 Flash ثم صعّد للنماذج الأكبر عند الحاجة فقط
- استخدم ملفات SKILL.md لتجنب تكرار الشرح في كل محادثة وتوفير التوكنز
- قسّم المهام الكبيرة إلى جلسات منفصلة وأنشئ نقاط حفظ متكررة لتجنب تضخم السياق
لم يعد المطور يكتب كل سطر بنفسه، لكنه أصبح مسؤولاً عن توجيه مساعدات البرمجة بالذكاء الاصطناعي لاستخراج أقصى قيمة من كل توكن. تضخم السياق يرفع زمن الاستجابة، ويدفع النماذج للنسيان أو الهلوسة، ويستنزف الميزانية. في هذا الدليل العملي، نستعرض 11 مبدأ وضعه فريق Google Cloud لضبط استهلاك التوكنز والحفاظ على حلقة تطوير سريعة ودقيقة.
لماذا يهم تحسين التوكنز الآن؟
تتراوح تكلفة الألف توكن في النماذج الرائدة بين 0.01 و0.06 دولار، وقد تبدو ضئيلة حتى تتضاعف مع آلاف الطلبات اليومية. الأهم أن نوافذ السياق الحديثة تتسع لمليون توكن وأكثر، لكن حشوها يعني بطئاً ملموساً وتشتتاً في استجابات النموذج. تحسين التوكنز إذن ليس توفيراً مالياً فحسب، بل ضمانة لجودة المخرجات.
كيف أختار النموذج المناسب للمهمة؟
ابدأ بنموذج متوازن مثل Gemini 3.5 Flash بمستوى استدلال متوسط. راقب تعقيد المهمة أثناء التنفيذ: إن فشلت أو احتاجت خطوات كثيرة أو تصميماً معقداً، صعّد إلى نموذج أكبر أو مستوى استدلال أعلى. هذا التدرج يوفر التوكنز في المهام البسيطة ويحتفظ بالقدرة الحسابية للحالات التي تستحقها فعلاً.
ما دور ملفات SKILL.md في تقليل الاستهلاك؟
بدلاً من شرح سير العمل وقواعد الاختبار وإعدادات البيئة في كل محادثة، غلّف هذه المعلومات في ملفات SKILL.md ونصوص قابلة لإعادة الاستخدام. يُفعّلها الوكيل تلقائياً فتبقى المطالبات نظيفة، ويتجنب البحث في التوثيق أو فحص الكود المحلي دون داعٍ.
كيف تُوظّف السكربتات وأدوات CLI؟
للأعمال المتكررة كتنسيق الملفات أو استخراج بيانات السجلات، اطلب من الوكيل إنشاء أدوات محلية بسيطة. استخدم أدوات CLI الرسمية للإعداد والفحص والاختبار. نفّذ أوامر القراءة فقط لاستكشاف قاعدة الكود قبل الكتابة، فتتجنب حلقات التجربة والخطأ الطويلة.
متى أُفوّض المهام إلى وكلاء فرعيين؟
المهام الثقيلة بالمخرجات، كالبحث المعمق أو فصل الواجهة الأمامية عن الخلفية، فوّضها لوكلاء فرعيين. حين ينتهون، تُطابق النتائج النهائية فقط بدلاً من مراجعة كامل مسار التنفيذ، ما يوفر توكنز وسياقاً ثميناً.
استراتيجية «الفيل والسمكة الذهبية»
اقترح David Rensin نهجاً من مرحلتين: استخدم جلسة طويلة السياق وعالية الاستدلال لتوليد خطة تنفيذ مفصلة، ثم نفّذها في جلسة نظيفة منخفضة التوكنز. أنشئ نقاط حفظ متكررة عبر commits أو artifacts، لتتمكن من إعادة البدء من حالة نظيفة حين يمتلئ السياق.
كيف أُقدّم التحقق مبكراً؟
شغّل البناء المحلي واختبارات الوحدة والوظائف قبل الانتقال لاختبار الواجهة. اطلب من الوكيل تنفيذ اختبار الدخان المكلف في المتصفح قبل التسليم مباشرة. احتفظ بحلقات التحقق الباهظة لنهاية كل مرحلة.
ماذا أفعل حين ينحرف الوكيل؟
إن انحرف الوكيل وعرفت الإصلاح، استخدم زر التراجع في سلسلة التنفيذ أو أعد الملفات لحالتها السابقة. لا تُراكم مطالبات تصحيحية فوق حالة معطوبة، فذلك يُسمم السياق بأكمله.
كيف أكون محدداً دون إدارة تفصيلية؟
التعليمة الواضحة بأخطاء إملائية أفضل من طلب عام مصاغ بإتقان. وجّه الوكيل للملف أو القسم أو الخطأ المطلوب تحديداً، بتعليق مثل:
// SHOULD BE X, NOT Y, FIX THIS
بدلاً من إرساله للبحث في سجل من عشرة آلاف سطر. التعليقات المضمنة توفر توكنز وتُسرّع الإصلاح.
كيف أُحدّث القواعد بدلاً من تكرار التصحيح؟
إن وجدت نفسك تصحح سلوك الوكيل مراراً، حدّث قواعدك العامة في AGENTS.md أو عدّل المهارة. إصلاح التعليمات مرة واحدة يُبقي التغيير دائماً ويوفر توكنز التكرار.
كيف أتجنب الحلقات غير المضبوطة؟
حلقات المراقبة التي تفحص المشاريع بحثاً عن عمل معلق قد تجد تحسينات، لكنها قادرة على استنزاف ميزانية التوكنز بالكامل. إن شغّلت حلقات، ضع حدوداً صارمة وشروط إيقاف. الاستقلالية العالية تتطلب حواجز أضيق وتقييمات أدق. لا تدع الوكلاء يستطلعون الحالة في حلقة؛ استخدم إيقاظاً مدفوعاً بالأحداث.
متى أبدأ جلسة جديدة؟
إن واصلت في الموضوع ذاته، يمكن للوكيل إعادة استخدام السياق الحالي. لكن إن انتقلت لموضوع مختلف، ابدأ محادثة جديدة. الوكيل يُقدم إجابات أفضل بتوكنز أقل حين يسحب السياق الذي يحتاجه فقط.
- ابدأ بنموذج متوازن وصعّد عند الحاجة
- استخدم SKILL.md لتجنب تكرار الشرح
- فوّض المهام الثقيلة لوكلاء فرعيين
- أنشئ نقاط حفظ متكررة
- استخدم التعليقات المضمنة للدقة
- حدّث القواعد بدلاً من تكرار التصحيح
- ابدأ جلسة جديدة لكل موضوع مختلف
الأسئلة الشائعة
ما الفرق بين Gemini Code Assist وGitHub Copilot من حيث التوكنز؟
كلاهما يعتمد على نماذج لغوية كبيرة، لكن Gemini يتيح التدرج بين مستويات استدلال مختلفة ضمن المنتج نفسه، بينما Copilot يعتمد نماذج OpenAI بتسعير ثابت. اختيار الأداة يعتمد على احتياجات الفريق وتكامل المنصة.
كيف أعرف أن السياق أصبح متضخماً؟
علامات التضخم تشمل: ارتفاع زمن الاستجابة، تجاهل الوكيل لتعليمات سابقة، أو ظهور هلوسات. حين تلاحظ ذلك، ابدأ جلسة جديدة أو استعد من نقطة حفظ.
هل تنطبق هذه المبادئ على Claude وChatGPT أيضاً؟
نعم، المبادئ عامة لأنها تتعامل مع بنية نماذج اللغة الكبيرة ذاتها. الفروق تكمن في واجهة المستخدم وأدوات الإدارة، لكن منطق توفير التوكنز يبقى صالحاً.
ما أفضل طريقة لتتبع استهلاك التوكنز في فريق تطوير؟
معظم المنصات توفر لوحة استخدام. يمكن أيضاً تسجيل الطلبات عبر API وتحليلها دورياً لتحديد الأنماط المكلفة وتصحيحها.
رأي Logicity
هذه المبادئ تُحوّل المطور من كاتب كود إلى مُخرج يوجّه وكلاء ذكية. الفرق بين فريق يُتقن إدارة التوكنز وآخر يتجاهلها قد يصل لآلاف الدولارات شهرياً في المشاريع المتوسطة. أدوات مثل Gemini Code Assist وGitHub Copilot Enterprise وCursor تتنافس على هذه الشريحة، والأخيرة تُقدم تسعيراً شهرياً ثابتاً يناسب الفرق التي تخشى فواتير مفتوحة. الاستثمار في ملفات SKILL.md وAGENTS.md يُشبه بناء بنية تحتية: تكلفة أولية تُسترد سريعاً.
هل تحتاج مساعدة في التطبيق؟
إن كنت تبحث عن دعم لتطبيق هذه المبادئ في فريقك أو اختيار الأداة المناسبة لبيئتك، تواصل مع فريق Logicity للاستشارات التقنية.
عمر حسن
كاتب تقني وابتكار
أُنتِج هذا المقال بمساعدة الذكاء الاصطناعي وراجعه فريق التحرير في لوجيسيتي. اعرف المزيد في سياسة التحرير.
