GitHub تتيح إدارة Copilot Code Review عبر واجهات API على ثلاثة مستويات

عندما تضم الشركة عشرات المنظمات ومئات المستودعات، سرعان ما يتحول الضبط اليدوي لمراجعات الذكاء الاصطناعي إلى لعبة حظ. ففي مشروع يراجع Copilot كل pull request، وفي آخر يكون معطلًا، بينما يستخدم في مشروع ثالث خادم MCP لا يعرف عنه فريق الأمن شيئًا. وقد عالجت GitHub هذه الفجوة: باتت إعدادات Copilot Code Review قابلة للإدارة عبر واجهتي REST وGraphQL على ثلاثة مستويات — المؤسسة والمنظمة والمستودع الفردي.

الفائدة العملية واضحة: يمكن تخزين سياسة المراجعة بوصفها شيفرة، والتحقق منها آليًا، ونشرها دفعة واحدة في البيئة بأكملها. ويتوفر التحديث ضمن خطط Copilot Pro وPro+ وMax وBusiness وEnterprise.

كيف يعمل التسلسل الهرمي للإعدادات

يقرر مسؤول المؤسسة ما إذا كان Copilot Code Review مسموحًا به في جميع المنظمات، أم إن كان لكل منظمة حق الاختيار بنفسها. وإذا ثُبّت الإعداد في المستوى الأعلى، فلا يمكن تجاوزه في المستويات الأدنى.

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

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

ما الذي يمكن الحصول عليه الآن من API

أضافت GitHub حقولًا صريحة تتيح تمييز مراجعات Copilot وتعليقاته عن رسائل البشر والتطبيقات الأخرى. ويمكن لـAPI أيضًا إرجاع مستوى التدقيق المستخدم، وتحديد المهارات وخوادم MCP وتعليمات المستخدم التي اعتبرها Copilot مصادر لملاحظة بعينها.

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

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

القيود والخلاصة العملية

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

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

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