GitHub يشرح للمبتدئين كيف يُعلّمون Copilot قاعدة الشيفرة: 4 آليات

أصدرت GitHub مادة تعليمية للمبتدئين حول تطبيق Copilot. الموضوع محدود النطاق لكنه عملي: كيف تشرح لمساعد الذكاء الاصطناعي مكوّنات مشروعك والقواعد المتبعة في العمل عليه. يتناول الدليل أربع آليات: التعليمات المخصصة، والمهارات، والوكلاء المخصصون، وخوادم MCP، بما فيها Playwright.

الإعلان قصير، لذلك يعرض ما يلي المنطق العام لهذه الأدوات وفق الوثائق الحالية لـ GitHub. وقد تختلف أسماء الملفات وبنود القوائم في التطبيق نفسه.

المشكلة التي يعالجها الدليل

يعرف أي مساعد ذكاء اصطناعي لغة البرمجة افتراضيًا، لكنه لا يعرف مشروعك. فهو لا يدري أن الاختبارات عندكم تُشغَّل عبر pnpm، وأن الأنماط موجودة في طبقة منفصلة، وأن الوصول المباشر إلى قاعدة البيانات من وحدات التحكم (controllers) ممنوع. والنتيجة أنه يقترح شيفرة تبدو معقولة لكنها لا تجتاز المراجعة. وتصحيح ذلك يدويًا في الدردشة في كل مرة يستغرق وقتًا، ولا تتراكم المعرفة.

يقوم نهج GitHub على نقل السياق من رأس المطوّر إلى المستودع. فتوضع القواعد والأوصاف بجوار الشيفرة، وتُدار إصداراتها في git، وتعمل بالطريقة نفسها لدى كل من يفتح المشروع.

أربع أدوات للضبط والتخصيص

يرتّب الدليل عملية الضبط من الأبسط إلى الأعقد.

• التعليمات. ملف نصي في المستودع، عادةً بصيغة Markdown. يصف المكدّس التقني (stack)، وأوامر البناء والاختبار، وأسلوب الشيفرة، والمحظورات. هذه هي الطبقة الأدنى التي ينبغي إنشاؤها أولًا.
• المهارات (skills). حزم من المعرفة والسيناريوهات لمهمة محددة، مثل تجهيز إصدار أو كتابة ترحيل (migration). تُحمَّل عندما تتطلبها المهمة، ولا تُثقل السياق بصفة دائمة.
• الوكلاء المخصصون. ملفات تعريف منفصلة لكل منها دور وأدوات وقواعد خاصة: مراجع شيفرة، أو كاتب اختبارات، أو كاتب تقني. وبذلك لا تضطر إلى إعادة كتابة الموجّه (prompt) في كل مرة للأعمال المتكررة.
• خوادم MCP. يربط بروتوكول Model Context Protocol أدوات خارجية بـ Copilot. والمثال في المادة هو Playwright: عبره يمكن للوكيل فتح صفحة في المتصفح، وتنفيذ سيناريو مستخدم، والتحقق من النتيجة، بدل التخمين اعتمادًا على الشيفرة.

لماذا يهم هذا الآن تحديدًا

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

لكن لهذا النهج جانبًا آخر. فالتعليمات تتقادم مثل الوثائق. إذا غيّر الفريق أداة الفحص (linter) وبقي ملف القواعد كما هو، سيواصل الوكيل اتباع القواعد القديمة بثقة. كما أن خادم MCP الذي يملك وصولًا إلى المتصفح أو إلى أنظمة خارجية يوسّع سطح الهجوم، ويجب تقييد صلاحياته بالحذر نفسه الذي تُقيَّد به صلاحيات CI.

من أين تبدأ عمليًا

1. اكتب ملف تعليمات قصيرًا: المكدّس التقني، وأوامر التثبيت والبناء والاختبار، ومن 3 إلى 5 قواعد صارمة. يستفيد الوكيل من النصوص القصيرة الدقيقة أكثر من الطويلة. 2. اختبر النتيجة على مهمة صغيرة حقيقية، مثل إصلاح خلل. إذا كرر Copilot الخطأ في الموضع نفسه، فأضف هذه القاعدة إلى الملف. 3. صُغ العمليات المتكررة، مثل المراجعة أو كتابة الاختبارات، في وكلاء أو مهارات منفصلة. 4. اربط خوادم MCP واحدًا تلو الآخر. ابدأ بـ Playwright لفحص الواجهة، وحدّد فورًا النطاقات والإجراءات المسموح له بالوصول إليها. 5. أدرج ملف التعليمات في مراجعة الشيفرة. يجب أن تتغير القواعد مع تغير الشيفرة.

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