فريق هندسي يراجع خطة انتقال من أربعة نماذج ذكاء اصطناعي سيُوقف دعمها إلى ثلاثة بدائل مقترحة عبر الاختبار والتطبيق التدريجي

تعتزم GitHub إيقاف دعم أربعة نماذج في Copilot في 2 أكتوبر 2026: Gemini 3.5 Flash وGemini 3.6 Flash وKimi K2.7 Code وClaude Opus 4.7. ووفق إشعار الشركة، يشمل القرار المحادثة والتعديلات داخل السطر ووضع السؤال ووضع الوكيل وإكمال الشيفرة. لذلك لا يقتصر الأمر على اختفاء أسماء من قائمة النماذج؛ فقد يتأثر أي مسار عمل أو تكامل يطلب أحدها بالاسم، وينبغي تحديثه قبل الموعد.

تقترح GitHub الانتقال من نسختي Gemini إلى Gemini 3.8 Flash، ومن Kimi K2.7 Code إلى Kimi K3، ومن Claude Opus 4.7 إلى Claude Opus 5. لكن وصفها بالبدائل المقترحة لا يعني أنها نسخ مطابقة. قد تختلف جودة النتائج وزمن الاستجابة واستهلاك الرموز والكلفة باختلاف المهمة والمستودع. لذا تبدأ المعالجة السليمة بحصر الاستخدام الفعلي، ثم اختبار البديل في العمل نفسه قبل توسيع نطاق التغيير.

حدّد مواضع الاعتماد على كل نموذج

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

لا تعامل الإعدادات كلها على أنها شيء واحد. ثمة فرق بين نموذج تعيّنه الإدارة للمحادثات الجديدة، ونموذج يختاره المستخدم بنفسه، ووضع Auto الذي يتولى الاختيار. قد تُراجع الإعداد الإداري ويبقى نموذج قديم مثبتاً في تكامل، أو يختار مستخدم نموذجاً مختلفاً في واجهته. لذلك يجب فحص كل مسار على حدة، مع تجربة الحساب والواجهة اللذين يستخدمهما الفريق فعلياً.

منذ 2 سبتمبر، تتيح الإعدادات التي تديرها المؤسسة تعيين أي نموذج متاح نموذجاً افتراضياً للمحادثات الجديدة، كما يمكن تحديد إعداد مختلف بحسب فريق المؤسسة. وأعلنت GitHub أن هذه الخاصية متاحة عموماً لخطتي Business وEnterprise في تطبيق Copilot وواجهة سطر الأوامر وVS Code. لا يثبت ذلك أن السلوك نفسه متاح في واجهات لم يسمها الإعلان؛ فالتحقق ينبغي أن يجري داخل البيئة المستعملة، لا بالاستناد إلى لوحة الإدارة وحدها.

في خطتي Business وEnterprise، لا يكفي أن يظهر البديل في قائمة النماذج المدعومة. قد تمنع سياسة المؤسسة المستخدم من الوصول إليه. يستطيع مالك المؤسسة أن يفرض إعداد النماذج، أو يترك للمنظمة وضع إعدادها الخاص. وإذا لم تحدد المنظمة إعداداً مستقلاً، فإنها تعمل بإعداد الإتاحة الافتراضي المعتمد في المستوى الأعلى. هذه العلاقة الإدارية تستحق التحقق المباشر، لأن ظهور النموذج في الوثائق لا يعني بالضرورة ظهوره في أداة المستخدم.

يتطلب Kimi K3 فحصاً إضافياً. فهو من النماذج ذات الأوزان المفتوحة، وهذه الفئة معطلة افتراضياً في خطتي Business وEnterprise بصرف النظر عن إعداد الإتاحة الافتراضي. يمكن السماح بها صراحة إذا لم توجد قيود أخرى، لكن اقتراح GitHub الانتقال إليها لا يفتحها تلقائياً. قبل اعتمادها، على المسؤول التأكد من السياسة، ثم على مستخدم فعلي التأكد من ظهورها وإمكان تشغيلها في الواجهة المقصودة.

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

افحص الإصدارات قبل أن تبدأ المقارنة

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

جدول الحد الأدنى للإصدارات مؤقت بحسب الوثائق. في 6 سبتمبر، كانت بعض قيم Gemini 3.8 Flash لا تزال غير محددة، بينما ذُكر VS Code 1.131 لـKimi K3 وVS Code 1.128.0 لـClaude Opus 5. هذه المعلومات لقطة قابلة للتبدل وليست ضماناً دائماً. سجّل نسخة المحرر والإضافة عند الاختبار، وارجع إلى الجدول الحي قبل التنفيذ، بدلاً من تحويل الأرقام الحالية إلى قاعدة ثابتة لكل الأدوات.

اختبر المهمة نفسها لا اسم النموذج

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

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

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

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

قِس الكلفة على أساس الاستخدام الفعلي

تختلف أسعار الرموز بين بعض النماذج الحالية والبدائل. وكانت صفحة التسعير في 6 سبتمبر تعرض، لكل مليون رمز، Gemini 3.5 Flash بسعر 1.50 دولار للإدخال و0.15 دولار للإدخال المخزّن مؤقتاً و9 دولارات للإخراج. أما Gemini 3.6 وGemini 3.8 فكانت أسعار كل منهما 0.75 و0.075 و3.75 دولارات للفئات نفسها.

وكانت أرقام Kimi K2.7 هي 0.95 دولار للإدخال و0.19 دولار للتخزين المؤقت و4 دولارات للإخراج، مقابل 3 دولارات و0.30 دولار و15 دولاراً لـKimi K3. وعرضت الصفحة السعر نفسه لـClaude Opus 4.7 وClaude Opus 5: خمسة دولارات للإدخال و0.50 دولار للإدخال المخزّن مؤقتاً و6.25 دولارات لكتابة الذاكرة المؤقتة و25 دولاراً للإخراج.

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

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

نفّذ التغيير على نطاق محدود أولاً

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

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

نفّذ التوسيع على دفعات، وراقب في كل دفعة الأخطاء وزمن الاستجابة واختيار النموذج الفعلي والشكاوى المرتبطة بجودة الناتج. انشر للمستخدمين تعليمات قصيرة تذكر ما تغير، وأين يبلغون عن المشكلة، وما المعلومات اللازمة للتحقق منها. لا تطلب منهم الاكتفاء بعبارة «النموذج أسوأ»؛ يفيد أكثر إرفاق المهمة والواجهة والوقت والنتيجة المتوقعة، مع مراعاة قواعد المؤسسة بشأن مشاركة الشيفرة والبيانات.

راجع المسارات التي لا تظهر في لوحة الإدارة

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

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

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

جدول عمل حتى 2 أكتوبر

في المرحلة الأولى، احصر مواضع الاستخدام وحدد أصحابها والواجهات والخطط والإصدارات. افحص سياسات النماذج، ولا سيما السماح الصريح بالنماذج ذات الأوزان المفتوحة إذا كان Kimi K3 مرشحاً. تأكد من أن كل بديل يظهر لحساب حقيقي في الأداة المقصودة، وافصل بين النموذج الافتراضي والاختيار الصريح ووضع Auto.

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

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

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

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