أظهرت Wildberries كيف بدأ وكيل AI محلي في كتابة اختبارات وحدات لـ Android

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

من التشكك إلى المهمة

يصف المؤلف مسارًا مألوفًا لدى العديد من المطورين: من الحماس الأولي حول ChatGPT في عام 2023 إلى إرهاق الضجيج الإعلامي والشكوك حول ما إذا كانت الشبكات العصبية تحقق فعلاً مكاسب في الإنتاجية في تطوير المنتجات على نطاق واسع. بعد دراسة المحاضرات والمقالات ودراسات الحالة، توصل إلى استنتاج أكثر واقعية: في قواعد الأكواد الموجودة، عادة لا يتعلق الأمر باستبدال الفريق، بل بمكاسب في الكفاءة بنسبة حوالي 10-20% إذا تم دمج الأداة بشكل صحيح في العملية.

"الفرق بين الموظف المبتدئ والموظف الكبير في استخدام الشبكات العصبية هو

3-4 أشهر."

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

لماذا لم تنجح

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

• التعليمات التفصيلية جدًا أرهقت النموذج وتجاهلت المتطلبات المهمة؛
• أثقلت مخرجات Gradle بعد التجميع وتشغيل الاختبارات السياق وأفسدت الردود اللاحقة؛
• لم تسرع الجلسات المتعددة الحالية الشغل، فقط ضاعفت عدد الاختبارات المكسورة؛
• انتهت محاولات اختبار ViewModels الكبيرة فورًا بفقدان التركيز والحلول الخيالية.

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

ما الذي نجح في النهاية

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

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

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

ماذا يعني هذا

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