T-Bank يعلّم وكيل الذكاء الاصطناعي كتابة اختبارات الوحدة لنظام iOS عبر AGENTS.md وSKILL.md

وصف فريق تطوير iOS في T-Bank على منصة Habr كيف درّب وكيل LLM على كتابة اختبارات الوحدة بأسلوب المشروع: بكائنات Mock حقيقية، وأدوات صحيحة، وكود يُجمَّع من المحاولة الأولى. ويقول كاتب المادة، مطوّر iOS أرتيم جيتكو، إن تجريب الموجِّهات لم يُجدِ نفعًا، وإن ما نجح هو منظومة قواعد قائمة على ملفَّي AGENTS.md وSKILL.md. ولا يتضمن العرض التمهيدي أرقامًا مثل نسبة الاختبارات القابلة للتجميع أو عدد الساعات الموفَّرة، وعلى الأرجح بقيت هذه الأرقام داخل المقالة الكاملة.

ما الذي تعطّل في المحاولة الأولى

تُكتب الاختبارات عادةً في نهاية المهمة، حين يكتمل المنطق وتقلّ الحماسة. لذلك فهي مرشّح بديهي لإسنادها إلى وكيل. جرّب T-Bank تكليف ChatLLM بها، وحصل على مجموعة العيوب المعتادة:

• لم يكن الكود يُجمَّع؛
• اخترع النموذج كائنات Mock غير موجودة في المشروع؛
• جرى تجاهل الاتفاقيات المعمارية للفريق؛
• استُخدمت أدوات اختبار غير الأدوات المعتمدة في قاعدة الكود.

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

قواعد بدلًا من الموجِّهات

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

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

أبرز الحقائق من العرض التمهيدي

• المنصة: iOS، اختبارات الوحدة.
• النموذج الأولي: ChatLLM، وقد عُدّت نتيجته دون سياق غير صالحة للاستخدام.
• الأدوات: AGENTS.md وSKILL.md.
• طرح الفريق: القواعد الجيدة أهم من اختيار أذكى نموذج.
• لم تُذكر مقاييس للجودة أو لتوفير الوقت في العرض التمهيدي.

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

كيف تطبّق ذلك لديك

إذا أردت تكرار هذا النهج، فابدأ بتحليل الأخطاء لا بكتابة القواعد. اجمع 10–20 اختبارًا ولّدها الوكيل بشكل سيئ، وصنّف أسبابها: فئة مختلَقة، أو أداة خاطئة، أو بنية معمارية منتهَكة. وكل سبب يتكرر يتحول إلى قاعدة محددة.

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

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