- يوفر GitHub Copilot SDK نفس الذكاء الاصطناعي الذي يقف وراء Copilot Chat في التطبيقات المخصصة من خلال وقت تشغيل قائم على الجلسات.
- تعتمد عمليات التكامل مع الأجهزة المحمولة على بنية من جانب الخادم باستخدام Copilot CLI و Node.js وبيانات اعتماد آمنة تُدار من جانب الخادم.
- تعتبر الهندسة الفعالة والسريعة وإدارة دورة الحياة القوية أمراً ضرورياً للحصول على ملخصات مفيدة وتجنب تسرب الموارد.
- يضمن التدهور التدريجي والتخزين المؤقت وملخصات الذكاء الاصطناعي عند الطلب أن يكون فرز المشكلات قابلاً للاستخدام وفعالاً من حيث التكلفة حتى عندما يكون الذكاء الاصطناعي غير متاح.
بالنسبة للعديد من القائمين على الصيانة، يعني فتح مستودع نشط على GitHub مواجهة قائمة طويلة من المشكلات العالقة التي قد تبدو لا نهاية لها. تتنافس تقارير الأخطاء، وطلبات الميزات، والأسئلة التي تنتمي في الواقع إلى المناقشات، والتكرارات القديمة، جميعها على جذب الانتباه وتُسبب الكثير من التعقيدات. العبء الذهني الزائد أثناء فرز المشكلات.
توفر حزمة تطوير البرمجيات Copilot من GitHub طريقة لتخفيف جزء من هذا العبء المعرفي من خلال السماح لك بتضمين نفس الذكاء الاصطناعي الذي يدعم Copilot Chat في أدواتك الخاصة. ومن الأمثلة العملية على ذلك تطبيق يُسمى IssueCrush، والذي يستخدم حزمة تطوير البرمجيات لإنشاء ملخصات الذكاء الاصطناعي لمشاكل GitHub حتى يتمكن القائمون على الصيانة من اتخاذ قرار أسرع بشأن ما يجب فعله بكل تذكرة.
من صندوق بريد فوضوي إلى فرز بمساعدة الذكاء الاصطناعي
تعتمد منصة IssueCrush على فكرة بسيطة: عرض المشكلات على شكل بطاقات قابلة للتمرير، وترك مهمة تحليل السياق للذكاء الاصطناعي. في التطبيق، تظهر كل مشكلة على GitHub على شكل بطاقة يمكنك التمرير لليسار لإغلاق المشكلة أو لليمين للاحتفاظ بها. يُرسل إجراء "الحصول على ملخص الذكاء الاصطناعي" تفاصيل المشكلة إلى نظام خلفي مدعوم بحزمة تطوير البرامج (SDK) الخاصة بـ GitHub Copilot، والذي يُعيد شرحًا موجزًا وعمليًا لطبيعة المشكلة وكيفية معالجتها.
بدلاً من قراءة الأوصاف المطولة وسلاسل التعليقات، يمكن للمشرفين إلقاء نظرة سريعة على هذه الملخصات لتحديد ما إذا كان الأمر يحتاج إلى دراسة، أو جاهز للتنفيذ، أو يجب إعادة تعيينه، أو يمكن إغلاقه. يحوّل هذا الأسلوب عملية الفرز المملة التي تشبه البريد الوارد إلى سير عمل أسرع وأكثر تركيزًا. يوفر الذكاء الاصطناعي المرحلة الأولى ولا يزال البشر يتخذون القرار النهائي.
يكمن السر في أن كل هذا مبني على أساس حزمة تطوير البرمجيات Copilot SDK بدلاً من بنية تحتية مخصصة للذكاء الاصطناعي. تكشف حزمة تطوير البرمجيات هذه عن وقت تشغيل الوكيل الذي تم اختباره في بيئة الإنتاج كانت تستخدم سابقًا لتجارب Copilot داخل GitHub نفسه، لذلك لا يتعين على المطورين إعادة اختراع منطق التخطيط أو التنسيق لمجرد إطلاق ميزة الفرز بمساعدة الذكاء الاصطناعي.
وبغض النظر عن هذا التطبيق المحدد، يمكن إعادة استخدام النمط نفسه لأي سير عمل حيث الرسوم البيانية السياقية والمعلومات المنظمة نحتاج إلى تلخيص سريع، سواء كان ذلك لأنظمة تتبع المشكلات الداخلية، أو تقارير الحوادث، أو قوائم انتظار مراجعة التعليمات البرمجية.
لماذا يجب أن يكون برنامج Copilot SDK موجودًا على الخادم
على الرغم من أن تطبيق IssueCrush مبنيّ على React Native، إلا أن حزمة تطوير البرامج (SDK) الخاصة بـ Copilot لا يمكن تشغيلها مباشرةً على الهاتف. تعتمد حزمة تطوير البرامج على... بيئة تشغيل Node.js بالإضافة إلى ملف Copilot CLI الثنائيوالتي تتم إدارتها داخليًا عبر JSON-RPC. لا توفر بيئات الأجهزة المحمولة هذا النوع من الإعداد المتوافق مع Node، لذا يجب أن يكون التكامل موجودًا على خادم خلفي.
عمليًا، يؤدي هذا إلى نمط بسيط من جانب الخادم: يقوم النظام الخلفي بتشغيل عميل واحد من حزمة تطوير البرامج (SDK) الخاصة بـ Copilot، والذي يتواصل داخليًا مع واجهة سطر الأوامر (CLI) الخاصة بـ Copilot، وترسل جميع تطبيقات الجوال طلباتها إلى هذه الخدمة. يوفر هذا التصميم العديد من المزايا المهمة التي تتجاوز مجرد تلبية متطلبات وقت التشغيل.
- A نسخة واحدة من حزمة تطوير البرامج (SDK) مشتركة بين العملاء يتجنب إنشاء اتصال جديد لكل هاتف أو لكل طلب، مما يقلل من النفقات العامة ويحافظ على مركزية عمليات المصافحة للمصادقة.
- تبقى الأسرار على الخادم: لا تظهر الرموز المميزة المتعلقة بـ Copilot أو بيانات اعتماد BYOK (أحضر مفتاحك الخاص) في حزمة React Native، والتي يمكن عكس هندستها بطريقة أخرى.
- يمكن للتطبيق التدهور بسلاسة عند عدم توفر الذكاء الاصطناعيإذا انتهت مهلة خدمة Copilot أو أعادت خطأً، فلا يزال بإمكان الواجهة الخلفية الاستجابة بملخص أساسي يحتوي على البيانات الوصفية فقط بدلاً من الفشل بشكل كامل.
- لأن كل طلب يمر عبر مكان واحد، يمكن للخادم أن يؤدي التسجيل والمراقبة المركزية من المطالبات والاستجابات وفترات الكمون.
لإعداد ذلك، يلزم توفر بعض المتطلبات الأساسية على الخادم: يجب تثبيت واجهة سطر الأوامر Copilot CLI وأن تكون متاحة في مسار النظام (PATH)، وتحتاج البيئة إلى اشتراك GitHub Copilot صالح أو إعداد BYOK، ويجب إكمال عملية المصادقة إما عبر عملية تسجيل دخول من سطر الأوامر أو من خلال متغير بيئي مثل رمز COPILOT_GITHUB.
كيفية عمل تكامل GitHub Copilot SDK
من الناحية التقنية، يتبع برنامج Copilot SDK نهجًا واضحًا، دورة حياة قائمة على الجلسات لتشغيل أنظمة إدارة التعلم. يتضمن التدفق النموذجي بدء تشغيل عميل، وإنشاء جلسة مع نموذج معين، وإرسال مطالبة وانتظار الإجابة، ثم تنظيف كل من الجلسة والعميل بشكل صريح.
النمط الموصى به هو التعامل مع دورة الحياة هذه بدقة شديدة: استدعاء ابدأ أولاً باستخدام start()، ثم أنشئ جلسة باستخدام createSession().وبعد الانتهاء من جميع التفاعلات، يتم استدعاء دالة قطع الاتصال (disconnect()) على الجلسة، ثم دالة الإيقاف (stop()) على العميل. إن وضع هذه الخطوات داخل كتل try/finally ليس مجرد أسلوب برمجي، بل يمنع تسرب الذاكرة والعمليات الذي يصعب تشخيصه بطرق أخرى.
في الواجهة الخلفية لـ IssueCrush، يتم تشغيل عميل Copilot، وإنشاء جلسة باستخدام نموذج مثل gpt-4.1، وتحويل بيانات المشكلة إلى موجه. يتم استرجاع الاستجابة باستخدام دالة تنتظر انتهاء النموذج قبل إرجاعها. بعد استخراج الملخص فقط، يقوم الخادم بتشغيل منطق التنظيف الخاص به، للتأكد من قطع الاتصال بجميع الجلسات المفتوحة وإيقاف العميل.
كما يوضح التكامل كيفية التعامل الآمن استيراد ديناميكي لحزمة تطوير البرامج (SDK). إن استخدام الاستيراد غير المتزامن بدلاً من طلب المستوى الأعلى يسمح للخادم بالبدء حتى في حالة وجود مشكلة مؤقتة في تحميل SDK أو الوصول إلى CLI، مما قد يبسط عملية النشر وتصحيح الأخطاء في بعض البيئات.
تصميم سريع لملخصات القضايا القابلة للتنفيذ
إن مجرد إدخال كم هائل من نصوص القضايا في نظام إدارة التعلم (LLM) غالبًا ما ينتج عنه نتائج متواضعة. يوضح مثال Copilot SDK في IssueCrush ذلك. مطالبات منظمة مبنية من البيانات الوصفية عادة ما تؤدي إلى ملخصات أكثر فائدة.
بدلاً من مجرد دمج نص المشكلة، يقوم النظام الخلفي بإنشاء نموذج يتضمن حقولاً مثل العنوان، والرقم، واسم المستودع، والحالة الحالية، والتصنيفات، وتاريخ الإنشاء، والمؤلف. وهذا يمنح النموذج سياقاً كافياً لتكييف توصياته؛ فعلى سبيل المثال، يمكنه التعامل مع تقرير من مساهم جديد بشكل مختلف عن تقرير مقدم من مسؤول صيانة مخضرم.
يُحدد التوجيه بوضوح شكل المخرجات المطلوبة: ملخص قصير من جملتين أو ثلاث يشرح ماهية المشكلة، ويُحدد المشكلة أو الطلب الرئيسي، ويقترح خطوة تالية مثل "بحاجة إلى تحقيق"، أو "جاهز للتنفيذ"، أو "إغلاق باعتباره مكررًا". بل إنه يُوجه النموذج أيضًا بعدم استخدام تنسيق Markdown، مما يضمن أن يمكن عرض الملخص مباشرة في واجهة المستخدم الخاصة بالهواتف المحمولة دون الحاجة إلى معالجة لاحقة إضافية.
من جانب الاستجابة، يستدعي الخادم دالة SDK التي ترسل الطلب وتنتظر الرد، مع تحديد مهلة زمنية (مثلاً، 30 ثانية). تمنع هذه المهلة المستخدمين من الانتظار إلى أجل غير مسمى للاستجابات البطيئة. قبل قراءة أي خصائص من النتيجة، يتحقق البرنامج من سلسلة الاستجابة بشكل وقائي، للتأكد من وجود الكائنات، حتى لا يتعطل البرنامج بأخطاء من نوع "غير مُعرَّف ليس كائنًا" عند حدوث أمر غير متوقع.
عندما تسير الأمور على ما يرام، يستخرج الخادم ملخص النص ويعيده إلى التطبيق. أما إذا كانت الاستجابة فارغة أو غير صحيحة، فيمكن للخادم الخلفي إظهار خطأ خاص به وتفعيل منطق احتياطي بدلاً من إعادة بيانات غير قابلة للاستخدام إلى العميل.
طبقة خدمة من جانب العميل في React Native
أما بالنسبة لتطبيقات الجوال، فإن التكامل بسيط عمداً. إذ تقوم فئة خدمة مخصصة بتغليف جميع الاستدعاءات إلى الواجهة الخلفية، وتتولى مهاماً مثل فحوصات السلامة، واسترجاع الرموز المميزة، وطلبات الشبكة، وتحديد الأخطاء، بحيث تبقى واجهة المستخدم بسيطة نسبياً.
تُتيح الخدمة طريقةً لإرسال طلبات اختبار الاتصال (ping) إلى نقطة النهاية /health في الواجهة الخلفيةإذا أفاد الخادم بأن دعم مساعد الطيار الآلي مُفعّل، فيمكن للتطبيق عرض زر "ملخص الذكاء الاصطناعي" بأمان. أما إذا لم يكن كذلك، فيمكن إخفاء هذا الزر تمامًا حتى لا يستخدم المستخدمون ميزة معطلة.
لغرض التلخيص، يقرأ العميل رمز GitHub الخاص بالمستخدم من وحدة تخزين آمنة، ويرسل كلاً من الرمز وبيانات المشكلة إلى نقطة نهاية التلخيص المدعومة بالذكاء الاصطناعي في الواجهة الخلفية. قد تحتوي الاستجابة على ملخص عادي مُنشأ بواسطة Copilot، أو ملخص احتياطي، أو خطأ مع علامة "requiresCopilot" في حال عدم امتلاك المستخدم اشتراكًا مناسبًا.
تقوم الخدمة بتحويل تلك الاستجابات إلى كائن نتيجة متسق يتضمن نصًا موجزًا بالإضافة إلى مؤشرات توضح ما إذا كانت النتيجة ناتجة عن الذكاء الاصطناعي أو عن مسار احتياطي. من وجهة نظر واجهة المستخدم، كل ما تحتاجه هو معرفة ما هو النص الذي سيتم عرضه، وما إذا كان سيتم عرض أي رسائل خاصة؟ بخصوص متطلبات الاشتراك.
تدفق واجهة المستخدم والتخزين المؤقت في React Native
في واجهة React Native، تعتمد آلية العمل في الغالب على إدارة الحالة القياسية. فعندما ينقر المستخدم على زر جلب ملخص الذكاء الاصطناعي، يتحقق المكون مما إذا كانت المشكلة الحالية تحتوي بالفعل على ملخص مُنشأ؛ فإذا كان الأمر كذلك، لا يتم إرسال أي طلب شبكة. وإلا، يقوم التطبيق بتعيين علامة تحميل، واستدعاء دالة الخدمة، وتحديث المشكلة في القائمة المحلية بمجرد استلام الملخص.
بمجرد تخزين ملخص في عنصر المشكلة، يستبدل مكون البطاقة الزر بنص الملخص نفسه. إذا قام المستخدم بالتمرير بعيدًا ثم عاد لاحقًا إلى نفس البطاقة، يعرض التطبيق المحتوى المخزن مؤقتًا على الفور بدلاً من استدعاء الواجهة الخلفية مرة أخرى. هذا الأسلوب يقلل من استخدام واجهة برمجة التطبيقات، ويتجنب زمن الاستجابة غير الضروريويجعل واجهة المستخدم أكثر استجابة عند تكرار المشاهدة.
تتيح علامة التحميل للمكون عرض مؤشر تحميل أو حالة معطلة أثناء تشغيل طلب الخادم. يتم تسجيل أي أخطاء من الخدمة ويمكن عرضها من خلال إشعارات أو لافتات أو أنماط واجهة مستخدم أخرى حسب تصميم التطبيق.
تدهور سلس عند توقف الذكاء الاصطناعي عن العمل
لا توجد خدمة ذكاء اصطناعي تعمل بنسبة ١٠٠٪ طوال الوقت، وتُعدّ قيود معدل البيانات أو مشاكل الشبكة من الأمور الشائعة. وقد حرص مثال IssueCrush على تضمين استراتيجية احتياطية لضمان عدم تعطل عملية فرز المشكلات في حال عدم توفر Copilot.
في النظام الخلفي، تُصنّف الأخطاء إلى فئتين رئيسيتين. إذا أشارت الرسالة إلى مشكلة في المصادقة أو الاشتراك، يُعيد الخادم رمز الحالة 403 مع شرح واضح. يلزم الاشتراك في برنامج Copilot بالنسبة لملخصات الذكاء الاصطناعي. يمكن للعميل بعد ذلك عرض الرسائل المناسبة لتلك الحالة.
تُفعّل جميع الأخطاء الأخرى آلية احتياطية تعتمد على البيانات الوصفية. يقوم الخادم بإنشاء ملخص من المعلومات المتوفرة لديه، والتي تشمل عادةً عنوان المشكلة، وقائمة التصنيفات، وربما الجملة الأولى من نص المشكلة إذا كانت قصيرة بما يكفي. وتُشجع ملاحظة ختامية المسؤول على مراجعة تفاصيل المشكلة كاملةً لتحديد الخطوات التالية.
لأن هذا الحل الاحتياطي يُولّد بالكامل من بيانات المشكلة الحالية، فإنه يعمل حتى في حال انقطاع خدمة Copilot أو انقطاع الاتصال بالشبكة. لا يدّعي التطبيق أنه ذكي كنموذج ذكاء اصطناعي في هذا الوضع، ولكنه مع ذلك يُقدّم حلاً أكثر فائدة من مجرد عرض حالة خطأ فارغة.
بالإضافة إلى نقطة نهاية فحص الحالة الصحية وقدرة العميل على إخفاء أو إظهار زر ملخص الذكاء الاصطناعي، فإن هذا يعني أن التجربة الشاملة تظل وظيفية وقابلة للتنبؤ حتى في ظروف الفشل.
ملخصات عند الطلب وتوعية بالتكاليف
ومن الجوانب البارزة الأخرى في التصميم أن الملخصات لا تُنشأ إلا عند طلب المستخدمين لها. لا يقوم النظام الخلفي بحساب ملخصات الذكاء الاصطناعي مسبقًا لكل مشكلة في المستودع، بل ينتظر حتى ينقر أحد المشرفين صراحةً على زر بطاقة معينة.
يُقلل هذا النمط عند الطلب من استخدام موارد الحوسبة ويُساعد في التحكم بتكاليف واجهة برمجة التطبيقات، حيث يُمكن تخطي العديد من المشكلات أو تجاهلها بسرعة دون الحاجة إلى مساعدة الذكاء الاصطناعي. بمجرد إنشاء ملخص لمشكلة ما، يتم تخزينه مؤقتًا في سجل تلك المشكلة داخل التطبيق، مما يضمن عدم تكبّد عمليات العرض المتكررة لطلبات إضافية.
يُعد هذا التوازن بين الراحة واستخدام الموارد ذا أهمية خاصة للفرق التي تعمل على نطاق واسع، حيث يمكن أن يؤدي خلاف ذلك إلى توليد عشرات الآلاف من المشكلات والمستخدمين حجم كبير من طلبات الذكاء الاصطناعي غير الضرورية.
المتطلبات والتبعيات والمنصات المدعومة
من منظور الأدوات، يستخدم النظام الخلفي @github/copilot-sdk تتضمن الحزمة إطار عمل خادم HTTP قياسي مثل Express. يتواصل SDK مع واجهة سطر الأوامر Copilot عبر JSON-RPC، لذا فإن تثبيت واجهة سطر الأوامر وتكوينها بشكل صحيح أمر لا غنى عنه.
يستهدف المثال الحالي بيئة Node.js، ولكن حزمة تطوير البرمجيات Copilot SDK مصممة لتكون متعددة اللغات. فهي تدعم Node.js/TypeScript وPython وGo و.NET، مع دعم منصات إضافية قيد التطوير المستمر. وبغض النظر عن اللغة، ينطبق المفهوم الأساسي نفسه: توفر حزمة تطوير البرمجيات بيئة تشغيل للوكيل يمكن دمجها في أدوات مخصصة دون الحاجة إلى أن يبتكر المطورون طبقة تنسيق خاصة بهم.
تتم عملية المصادقة إما من خلال آليات تسجيل الدخول في واجهة سطر الأوامر أو عبر متغيرات البيئة التي تحتوي على رموز مميزة. في بيئات الإنتاج، تُخزَّن بيانات الاعتماد هذه على الخادم ولا تُعرَض أبدًا للعملاء، وذلك وفقًا لممارسات الأمان القياسية المتبعة في هذا الشأن. مفاتيح واجهة برمجة التطبيقات ورموز الوصول.
دروس عملية من البناء باستخدام Copilot SDK
تتضح عدة نقاط رئيسية من هذا النوع من التكامل. أولاً، إن إبقاء حزمة تطوير البرامج (SDK) الخاصة بـ Copilot على الخادم فقط ليس مجرد متطلب تقني، بل إنه يبسط أيضاً عملية الأمان والنشر من خلال مركزية التكوين وبيانات الاعتماد.
ثانيا، جودة مخرجات الذكاء الاصطناعي الأمر يتعلق أكثر بجودة صياغة السؤال المطروح من كمية النص الخام المُدخل إلى النموذج. إن تضمين بيانات وصفية مُستهدفة، مثل التصنيفات والمؤلف والطوابع الزمنية، يُمكن أن يُحسّن بشكل ملحوظ من فائدة اقتراحات الفرز التي يُولدها الذكاء الاصطناعي.
ثالثًا، تُعد إدارة دورة حياة التطبيق بشكل فعّال أمرًا بالغ الأهمية. قد يكون من السهل إغفال فصل الجلسات وإيقاف العميل بشكل صريح في التجارب الأولية، ولكن تخطي هذه الخطوات قد يؤدي إلى تسرب الذاكرة وبقاء العمليات عالقة في الخدمات طويلة الأمد.
أخيرًا، يُعد التخزين المؤقت والنسخ الاحتياطية من الأنماط الأساسية. فبمجرد الحصول على ملخص جيد، يمنع تخزينه في كائن المشكلة تكرار العمل والتكاليف غير الضرورية. كما يضمن وجود نسخة احتياطية غير مدعومة بالذكاء الاصطناعي للمُشرفين على الصيانة إمكانية مواصلة العمل حتى في حال واجهت الخدمات الخارجية مشاكل.
تُظهر هذه الأنماط مجتمعةً كيف يمكن لـ GitHub Copilot SDK أن يدعم أدوات عملية مثل IssueCrush، مما يمنح الفرق طرق أسرع وأكثر استدامة لإدارة كميات كبيرة من المشكلات دون تحويل عملية الفرز إلى مهمة شاقة للغاية.
