Looks Right, Works Right: A Project-Level Benchmark for Multi-Screen Mobile App Generation
تقدم هذه الورقة MobileForge، وهو أول معيار على مستوى المشروع لتوليد تطبيقات الهاتف المحمول متعددة الشاشات يقيم النماذج اللغوية الكبيرة متعددة الوسائط عبر البناء، والتنقل، والدقة المرئية، وقابلية الصيانة، والكفاءة، كاشفاً أنه بينما تستطيع النماذج الحالية تجميع التطبيقات والتنقل فيها، إلا أنها لا تزال تعاني من أجل تحقيق تفاعل موثوق وجودة برمجية.
تخيل عالماً يمكنك فيه أن تري حاسوباً مجلداً مليئاً بالصور الفوتوغرافية الملتقطة من هاتف ذكي، فيقوم فوراً بكتابة برنامج الحاسوب الكامل اللازم لبناء ذلك التطبيق بدقة. هذا هو الوعد الذي يقدمه مجال يسمى "من التصميم إلى الكود" (design-to-code)، حيث تحاول الذكاء الاصطناعي ترجمة الصور المرئية إلى التعليمات الوظيفية التي تجعل البرمجيات تعمل. لسنوات، اختبر الباحثون هذه الأنظمة عبر عرض صورة واحدة لصفحة ويب عليها وطلب الكود الخاص لإعادة إنشاء تلك الشاشة الواحدة. وبينما أدت هذه الطريقة إلى نتائج مثيرة للإعجاب للصفحات البسيطة والمنعزلة، إلا أنها تغفل تعقيد البرمجيات في العالم الحقيقي. فالتطبيق المحمول الحقيقي ليس مجرد صورة واحدة؛ بل هو عالم متصل من العديد من الشاشات، وأزرار تنقلك من مكان إلى آخر، وعناصر تصميم مشتركة يجب أن تظل متسقة عبر التجربة بأكملها. ويبقى السؤال: هل يمكن للذكاء الاصطناعي أن ينظر إلى مجموعة كاملة من لقطات الشاشة لتطبيق حقيقي ويبني مشروعاً متعدد الصفحات يعمل بالفعل ويمكن لفريق بشري استخدامه؟
لقد عزم فريق من الباحثين على الإجابة على هذا السؤال باستخدام اختبار جديد يسمى "موبايل فورج" (MobileForge). فبدلاً من مطالبة النماذج ببناء صفحة واحدة، طلبوا منها بناء تطبيقات كاملة من الصفر. جمع الباحثون لقطات شاشة من 29 تطبيقاً حقيقياً وشائع الاستخدام يستخدمه الناس يومياً، تغطي كل شيء من وسائل التواصل الاجتماعي إلى التمويل والملاحة. احتوت هذه التطبيقات على إجمالي 309 شاشة مختلفة. ثم طلبوا من ستة من أكثر نماذج الذكاء الاصطناعي تقدماً المتاحة حالياً النظر إلى هذه الصور وتوليد الكود المصدري الكامل للتطبيقات. ولضمان أن يكون الاختبار عادلاً وصارماً، أنشأ الفريق خريطة مفصلة لكيفية اتصال الشاشات ببعضها البعض، وكتبوا مئات الاختبارات المحددة للتحقق مما إذا كانت التطبيقات الناتجة تعمل بالفعل. ولم يكتفوا بالتحقق مما إذا كان الكود يمكن تجميعه فحسب، بل تحققوا أيضاً مما إذا كانت أزرار التنقل تقود إلى الأماكن الصحيحة، وما إذا كان التصميم المرئي يطابق الصور الأصلية، وما إذا كان الكود نظيفاً بما يكفي ليتمكن مهندسون آخرون من صيانته لاحقاً.
كشفت النتائج عن انقسام واضح بين ما تستطيع هذه النماذج فعله وما لا تزال تعجز عنه. فمن الناحية الإيجابية، تمكن كل نموذج من إنتاج كود يمكن بناؤه في مشروع يعمل. واستطاعت النماذج الأقوى حتى التنقل عبر التطبيقات المولدة والوصول إلى الصفحات الصحيحة بنسبة 92 بالمائة تقريباً. ومع ذلك، فإن الرحلة من تطبيق يعمل إلى تطبيق مثالي لا تزال طويلة. فبينما كان الكود قادراً على التشغيل، غالباً ما انحرفت التفاصيل المرئية عن الصور الأصلية. وعانت النماذج من الحفاظ على اتساق الألوان والتخطيطات عبر الشاشات المختلفة، حيث كانت تعيد إنشاء نفس شريط التنقل بطرق مختلفة قليلاً في كل صفحة بدلاً من استخدام مكون واحد مشترك. وهذا التناقض يعني أنه بينما بدت التطبيقات مشابهة للأصلية، إلا أنها افتقرت إلى الشعور المصقول والموحد الذي يميز المنتج المصمم باحترافية.
ولعل الاكتشاف الأكثر إثارة للدهشة هو أن كون النموذج دقيقاً بصرياً لا يعني بالضرورة أن الكود المكتوب جيد. فالنموذج الذي أنتج التطبيقات الأكثر دقة من الناحية البصرية أنتج كوداً أطول بمرتين وأكثر فوضوية بمرتين من الكود الذي أنتجته النماذج الأخرى. فقد أنشأ العديد من الأجزاء غير المستخدمة وفشل في إعادة استخدام العناصر الشائعة بكفاءة. وفي المقابل، أنتج نموذج آخر كوداً أقصر وأكثر نظافة، مما يسهل على البشر تعديله وصيانته، رغم أن مخرجاته المرئية كانت أقل كمالاً بقليل. ويشير هذا إلى أن الجيل الحالي من الذكاء الاصطناعي لم يتعلم بعد كيفية الموازنة بين المظهر المرئي للجهاز وجودة الهندسة للكود الأساسي. كما اكتشف الباحثون أن النماذج غالباً ما تفشل بطرق يمكن التنبؤ بها؛ فأحياناً يظهر زر على الشاشة لكنه لا يفعل شيئاً عند النقر عليه، وفي أحيان أخرى، يتم تحميل الشاشة لكنها تكون فارغة تماماً، مما يترك المستخدم عالقاً. لم تكن هذه الإخفاقات أعطالاً عشوائية، بل كانت انهيارات محددة في كيفية فهم النماذج للعلاقة بين العنصر المرئي ووظيفته.
ولإجراء هذا الاختبار، اضطر الباحثون إلى ابتكار طرق جديدة لقياس النجاح تتجاوز مجرد المقارنة البصرية البسيطة. فقد طوروا طريقة لاختبار التنقل عبر البدء من نقطة ثابتة ومحددة لكل اختبار، بدلاً من ترك الكمبيوتر يتجول عبر التطبيق في سلسلة، مما منع خطأ واحداً من إفساد عملية التقييم بأكملها. كما أنشأوا نظاماً يقوم فيه حكم من الذكاء الاصطناعي بمقارنة الشاشات المولدة مقابل الصور الأصلية، ولكن مع وضع فحص أمان مدمج لضمان أن الحكم كان منتبهاً بالفعل وليس مجرد يخمن. سمح هذا النهج الصارم برؤية الفروق الدقيقة بين النماذج التي كانت الاختبارات القديمة ستغفل عنها. وتخلص الدراسة إلى أنه على الرغم من أن الذكاء الاصطناعي قد حقق قفزة كبيرة في تحويل الصور إلى كود، إلا أنه ليس مستعداً بعد لاستبدال المصممين والمهندسين البشريين في المشاريع المعقدة متعددة الشاشات. يمكن لهذه التكنولوجيا بناء الهيكل العظمي للتطبيق، لكنها لا تزال تعاني مع "ذاكرة العضلات" الخاصة بالتنقل وتفاصيل التصميم الدقيقة التي تجعل التطبيق يبدو حقيقياً وموثوقاً.
ملخص تقني: يبدو صحيحاً، يعمل بشكل صحيح: معيار على مستوى المشروع لتوليد تطبيقات الهاتف المحمول متعددة الشاشات
1. بيان المشكلة
أظهرت النماذج اللغوية الكبيرة متعددة الوسائط (MLLMs) مؤخراً القدرة على تحويل التصميمات المرئية إلى كود قابل للتنفيذ، وغالباً ما تحقق دقة عالية في المهام ذات الصفحة الواحدة. ومع ذلك، فإن تطبيقات الهاتف المحمول في العالم الحقيقي ليست مجرد شاشة واحدة؛ بل هي مشاريع معقدة تتكون من شاشات متعددة مترابطة، ومكونات مشتركة، ورموز تصميم (design tokens) متسقة، وتنقل وظيفي.
تعتبر معايير التقييم الحالية لتوليد التصميم إلى كود (مثل Design2Code وWebSight وWebCode2M) غير كافية لتقييم التوليد على مستوى المشروع لأنها تعاني من ثلاث قيود رئيسية:
التركيز على الصفحة الواحدة: فهي تقيم صفحات الويب الفردية بمعزل عن بعضها البعض، مما يفشل في تقييم الاتساق عبر الصفحات أو إعادة استخدام المكونات المشتركة.
الافتقار إلى تقييم التنقل: فهي لا تختبر ما إذا كان التوجيه العالمي (global routing) يربط بشكل صحيح بين انتقالات التبويب (tab transitions) وانتقالات الأب-الابن (parent–child transitions) إلى الأهداف المقصودة.
غياب مقاييس القابلية للصيانة: فهي تغفل مؤشرات جودة التسليم الهندسي، مثل معدلات إعادة استخدام المكونات، وانتشار الكود الميت (dead code)، واتساق رموز التصميم.
وبناءً على ذلك، لا يمكن للمعايير الحالية كشف الفجوات بين توليد صفحة واحدة "تبدو صحيحة" وتوليد قاعدة كود برمجية قابلة للبناء و"تعمل بشكل صحيح".
2. المنهجية: معيار MobileForge
لمعالجة هذه الفجوات، قدم المؤلفون MobileForge، وهو أول معيار على مستوى المشروع لتوليد تطبيقات الهاتف المحمول متعددة الشاشات. بُني هذا المعيار على ثلاثة مبادئ تصميمية: الواقعية (باستخدام تطبيقات استهلاكية موجودة في السوق بدلاً من النماذج الاصطناعية)، وتجزئة المشروع (التعامل مع التطبيقات كمجلدات من الشاشات لاختبار الاتساق عبر الصفحات)، والتقييم القابل للتشغيل (التركيز على قابلية البناء والتنقل بدلاً من مجرد محاكاة البكسل بدقة).
2.1 بناء مجموعة البيانات
النطاق: 29 تطبيقاً استهلاكياً حقيقياً عبر 14 فئة (مثل الوسائط، التمويل، التواصل الاجتماعي).
المحتوى: 309 لقطة شاشة تمت مراجعتها بشرياً (بمتوسط 10.7 شاشة لكل تطبيق) و701 مواصفة لاختبار التنقل.
الترميز (Annotation): مسار عمل يتكون من مرحلتين حيث يقوم نموذج رؤية لغوي (VLM) بصياغة أوصاف علاقات الصفحات واختبارات التنقل، يليه مراجعة بشرية. تتضمن مجموعة البيانات أوصافاً مهيكلة باللغة الطبيعية لهياكل التبويب وعلاقات الأب-الابن.
مواصفات الاختبار: مقسمة إلى ثلاث فئات:
وجود الصفحة: التحقق من إمكانية الوصول إلى شاشة معينة عبر مسار (route) محدد.
تنقل التبويب: التحقق من أن عناصر التبويب توجه إلى الشاشات الصحيحة.
تنقل الأب-الابن: التحقق من أن المحفزات (مثل النقر على أيقونة) تنقل إلى شاشات الابن المتوقعة.
2.2 إطار التقييم
يستخدم MobileForge بروتوكول تقييم خماسي المحاور:
البناء (Build): نجاح تجميع المشروع (React 19 + TypeScript + Tailwind) مع صفر أخطاء.
التنقل (Navigation): يُقاس عبر NavPassRate باستخدام اختبار التنقل المعزول للحالة (State-Isolated Navigation Testing). بخلاف عمليات التتبع المتسلسلة القياسية، يبدأ كل اختبار من مسار صفحة مصدر ثابت يتم توفيره مباشرة إلى برنامج تشغيل المتصفح. هذا يمنع تسلسل الأخطاء ويسمح بتحديد دقيق لمسببات الفشل (على سبيل المثال، التمييز بين خريطة المسارات المعطلة وبين عنصر واجهة مستخدم مفقود).
الدقة المرئية (Visual Fidelity): يتم تقييمها باستخدام بروتوكول التقييم المرئي القائم على القائمة والمرجع المرجعي (Anchor-Reference List-Wise Visual Evaluation). يقوم نموذج رؤية لغوي (VLM) بترتيب مخرجات النموذج مقابل بعضها البعض ومع "مرجع" مخفي (لقطة شاشة التصميم الأصلية). يكون الترتيب صالحاً فقط إذا تم وضع المرجع أولاً، كإجراء للتحقق من موثوقية الحكم.
قابلية صيانة الكود (Code Maintainability): تُقاس عبر خمسة مؤشرات: إجمالي عدد أسطر الكود (LoC)، متوسط عدد أسطر الكود لكل ملف، معدل إعادة استخدام المكونات، معدل المكونات الميتة، واتساق الألوان.
الكفاءة (Efficiency): تتبع استهلاك الرموز (tokens)، عدد استدعاءات واجهة برمجة التطبيقات (API)، وقت التنفيذ الفعلي، والتكلفة التقديرية.
2.3 الإعداد التجريبي
النماذج: ستة نماذج لغوية كبيرة متعددة الوسائط رائدة (Claude Opus 4.6, Claude Haiku 4.5, GPT-5, GPT-5 Mini, Gemini 2.5 Pro, Gemini 2.5 Flash).
نظام التشغيل (Harness): نظام وكيل (agentic harness) بـ عميل واحد وثماني أدوات (إدخال/إخراج الملفات، تنفيذ الأوامر) وخطة من ست مراحل (التحليل، التأسيس، المكونات، الصفحات، التجميع، التحقق). يكرر الوكيل العملية حتى 50 مرة لإصلاح أخطاء البناء.
النطاق: 174 عملية تشغيل كاملة (29 تطبيقاً × 6 نماذج).
3. النتائج الرئيسية
3.1 البناء والتنقل
نجاح البناء: وصل إلى حالة التشبع بنسبة 100% عبر جميع النماذج، مما يشير إلى أن النماذج الحالية يمكنها توليد كود قابل للتجميع عندما تُمنح حلقة (تحقق-إصلاح).
التنقل: يظل التنقل التفاعلي غير موثوق. حقق أفضل نموذج (Claude Opus 4.6) معدل نجاح في التنقل بنسبة 92%، بينما تراوحت النماذج الأخرى بين 58% و89%.
أنماط الفشل: كشف تحليل 64 حالة فشل تم تصنيفها بشرياً عن أربعة أنماط مهيمنة:
C1 (صفحة بداية فارغة): 7.8% (حالة شاذة في Gemini 2.5 Flash).
C2 (خطأ في رسم المسارات): 10.9% (الوكيل يعلن عن مسار، لكن الرابط URL يوجه لمسار خاطئ).
C3 (الهدف غير قابل للوصول/محجوب): 32.8% (التصميم يتجاهل الهدف أو يغطيه).
C4 (نقرة غير مستجيبة): 48.4% (الهدف موجود ولكن معالج النقرة مفقود أو غير موصل بشكل صحيح). هذا هو نمط الفشل المهيمن للنماذج القوية (Opus, GPT-5).
3.2 الدقة المرئية
الدقة المرئية لم تصل إلى حالة التشبع. بينما نجاح البناء مثالي، فإن الدرجات المرئية (Borda) تتراوح على نطاق واسع [0.13, 0.91].
يتصدر Claude Opus 4.6 في 26 تطبيقاً من أصل 29.
حتى أفضل النماذج يحصل فقط على 2.99/5 وفقاً لمعيار تقييم نقطي.
العائق الرئيسي هو الاتساق عبر الصفحات (على سبيل المثال، إعادة تنفيذ عناصر التنقل الثابتة داخلياً بدلاً من مشاركتها)، وهو ما تفشل المعايير أحادية الصفحة في اكتشافه.
3.3 قابلية صيانة الكود
هناك انفصال حاد بين الريادة في الدقة المرئية وقابلية صيانة الكود.
يولد Claude Opus 4.6 (القائد في الدقة المرئية) 2.2 ضعف عدد أسطر الكود و2.5 ضعف حجم الملفات مقارنة بـ GPT-5.
يحقق GPT-5 إعادة استخدام أعلى للمكونات (4.23 مقابل 3.83 استيراد) وعدد أقل بكثير من المكونات الميتة (7.8% مقابل 19.9%).
الفرق المجموعات التي تعطي الأولوية لدقة التصميم قد تختار Opus، بينما المجموعات التي تعطي الأولوية للصيانة اللاحقة قد تختار GPT-5.
3.4 المقايضات بين التكلفة والجودة
يظهر تحليل جبهة باريتو (Pare Pareto frontier) أن GPT-5 يهيمن على النماذج متوسطة المستوى في كل من التكلفة والجودة.
يتفوق GPT-5 (0.50 دولار/تطبيق) على Claude Haiku 4.5 (1.40 دولار/تطبيق) وGemini 2.5 Pro (0.64 دولار/تطبيق) في كل من درجة Borda ومعدل نجاح التنقل.
الفارق في التكلفة الذي يصل إلى 19 ضعفاً بين أرخص وأغلى النماذج لا يترجم إلى فارق تناسبي في الجودة.
4. الأهمية والادعاءات
يزعم البحث أن MobileForge هو أول معيار يكشف عن القيود المحددة للنماذج اللغوية الكبيرة متعددة الوسائط في توليد تطبيقات الهاتف المحمول على مستوى المشروع. تكمن أهميته في:
تغيير نموذج التقييم: الانتقة من تشابه الصفحة الواحدة المرئي إلى إطار عمل خماسي المحاور يتضمن البناء، والتنقل، وقابلية الصيانة، والكفاءة.
كشف الفجوات الخفية: إثبات أنه بينما يمكن للنماذج تجميع الكود والوصول إلى الصفحات، إلا أنها تعاني في ربط التنقل التفاعلي، والاتساق عبر الصفحات، وهيكل الكود الفعال.
الابتكار المنهجي: تقديم اختبار التنقل المعزول للحالة لمنع تسلسل الأخطاء، والتقييم القائم على المرجع المرجعي لتحسين موثوقية تقييمات الحكم بواسطة النماذج اللغوية (VLM-as-a-Judge).
الأدلة التجريبية: تقديم دراسة واسعة النطاق (174 عملية تشغيل) تظهر أن النماذج الحالية ليست جاهزة بعد لتوليد تطبيقات متعددة الشاشات بشكل مستقل تماماً وبمستوى إنتاجي، خاصة فيما يتعلق بجانب "يعمل بشكل صحيح" الخاص بالتنقل التفاعلي والقابلية للصيانة.
يخلص المؤلفون إلى أنه بينما تتقدم قدرة "يبدو صحيحاً"، فإن قدرة "يعمل بشكل صحيح" — وتحديداً في التنقل والصيانة — لا تزال تشكل تحدياً كبيراً للمجال.