💻 computer science

VISTA: An End-to-End Benchmark for Visual Spec-to-Web-App Coding Agents

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

المؤلفون الأصليون: JunJia Guo (Joe), Yuhang Yao (Joe), Jiawei (Joe), Zhou, Jingdi Chen

نُشر 2026-05-27

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: JunJia Guo (Joe), Yuhang Yao (Joe), Jiawei (Joe), Zhou, Jingdi Chen

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك توظف فريقاً من مهندسي الروبوتات لبناء منزل مخصص بناءً على رسم تخطيطي رسمته على منديل ورقي. بعض المهندسين بارعون في رسم المنزل ليبدو تماماً مثل رسمك، لكن الأبواب لا تفتح. والبعض الآخر يبني منزلاً يعمل بشكل مثالي (الأضواء تعمل، والأبواب تُقفل)، لكنه لا يشبه رسمك بتاتاً.

VISTA هو "اختبار قيادة" جديد صُمم لمعرفة مدى قدرة وكلاء البرمجة بالذكاء الاصطناعي على بناء هذه المنازل الرقمية (المواقع الإلكترونية) من الصفر، وليس مجرد كتابة سطر واحد من الكود.

إليك تفصيل للورقة البحثية باستخدام تشبيهات بسيطة:

1. المشكلة: فجوة "رسم المنديل"

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

الفجوة: الاختبارات الحالية لم تتحقق مما إذا كان بإمكان الذكاء الاصطناعي التعامل مع الواقع الفوضوي لبناء تطبيق كامل، أو اختيار الأدوات المناسبة (مثل الاختيار بين مواد بناء مختلفة)، أو إصلاح الأخطاء عندما تسوء عملية البناء.

2. الحل: اختبار VISTA

ابتكر المؤلفون VISTA (اختصار لـ Visual Spec-To-App Benchmark). اعتبر هذا الاختبار بمثابة تحدٍ هندسي صارم يتضمن بناء 10 أنواع مختلفة من المباني (مثل موقع حجز سفر، أو مشغل موسيقى، أو لوحة وظائف).

لقد اختبروا الذكاء الاصطناعي تحت خمسة مستويات مختلفة من "المساعدة" لمعرفة مقدار المعلومات التي يحتاجها الذكاء الاصطناعي للنجاح:

المستوى 1 (المنديل): مجرد وصف نصي. يجب على الذكاء الاصطناعي تخمين الأدوات والمظهر.
المستوى 2 (الصورة + أدوات ثابتة): وصف نصي + صورة للهدف، ولكن يجب على الذكاء الاصطناعي استخدام أدوات بناء محددة (مثلاً: "يجب أن تستخدم React").
المستوى 3 (الصورة + أدوات حرة): وصف نصي + صورة، ولكن يمكن للذكاء الاصطناعي اختيار أدواته الخاصة.
المستوى 4 (المخطط + أدوات ثابتة): نص + صورة + مخطط رقمي مفصل (Figma)، ولكن يجب على الذكاء الاصطناعي استخدام أدوات محددة.
المستوى 5 (المخطط + أدوات حرة): الحزمة الكاملة: نص + صورة + مخطط، ويمكن للذكاء الاصطناعي اختيار أدواته الخاصة.

3. نظام الدرجات: كيف نعرف ما إذا كانوا قد قاموا بعمل جيد؟

هذا هو الجزء الأكثر إبداعاً في الورقة. أدرك المؤلفون أن اختبارات الكمبيوتر القياسية (مثل التحقق مما إذا كان الزر قابلاً للنقر) غالباً ما تفشل لأنها جامدة للغاية. لذا، قاموا ببناء نظام تقييم "بشر في الحلقة" (Human-in-the-Loop):

"المقيمون البشريون": قام بشر حقيقيون بمراجعة التصاميم وحددوا بدقة أماكن الأزرار، والروابط، والقوائم التي يجب أن تكون موجودة. كما اختاروا "معالم" (مثل شريط البحث أو زر الدفع) لتعمل كنقاط مرجعية.
"المقيم القائم على الـ DOM": هذا عبارة عن روبوت حكم ذكي. هو لا ينظر فقط إلى الصورة؛ بل ينظر داخل كود الموقع الإلكتروني (الـ DOM).
- الخطوة 1 (الموقع): يتحقق من: "هل زر 'البحث' موجود بالفعل، وهل هو في المكان الصحيح؟"
- الخطوة 2 (السلوك): يتحقق من: "إذا نقرت على هذا الزر، هل سيقوم بالبحث فعلياً؟"
- الخطوة 3 (المرئيات): يستخدم أداة "تشابه بصري" (مثل عين فائقة الذكاء) ليرى ما إذا كان المبنى النهائي يشبه المخطط الأصلي، حتى لو لم تكن البكسلات متطابقة تماماً.

4. ما وجدوه: مقايضة "المظهر مقابل العمل"

عندما اختبروا أربعة أنظمة ذكاء اصطناعي مختلفة، وجدوا بعض الأشياء المفاجئة:

معضلة "جميل لكنه معطل" مقابل "قبيح لكنه يعمل":
- أحد أنظمة الذكاء الاصطناائي (GPT-5.5) كان مذهلاً في جعل الموقع يبدو تماماً مثل الصورة (درجة بصرية عالية)، لكن الأزرار غالباً لم تكن تعمل (درجة وظيفية منخفضة).
- نظام آخر (Claude Opus) بنى مواقع تعمل بشكل مثالي (درجة وظيفية عالية)، لكنها لم تكن تشبه الصورة الأصلية تماماً (درجة بصرية منخفضة).
- الدرس المستفاد: جعل الموقع يبدو جيداً وجعل الموقع يعمل هما مهارتان مختلفتان. يمكن للذكاء الاصطناعي أن يكون بارعاً في إحداهما وسيئاً في الأخرى.
الحرية هي المفتاح:
- أدى الذكاء الاصطناعي أداءً أفضل عندما سُمح له باختيار أدواته الخاصة (ظروف "المجموعة الحرة" - Free Stack). عندما أُجبر الذكاء الاصطناعي على استخدام أدوات محددة قد تكون صعبة، انخفضت الجودة. الأمر يشبه إجبار نجار على بناء منزل باستخدام المطرقة فقط بينما هو في أمس الحاجة إلى منشار.
أسلوب "الجراح" مقابل "فريق الهدم":
- تتبع الباحثون كيف قام الذكاء الاصطناعي بتعديل الكود.
- بعض الأنظمة كانت "جراحين": قاموا بإجراء قطوع وترقيعات صغيرة ودقيقة لإصلاح المشكلات.
- أما البعض الآخر فكانوا "فرق هدم": حيث يقومون بحذف أجزاء ضخمة من الكود وإعادة كتابة الملف بالكامل من الصفر.
- المفاجأة: كونك "جراحاً" لم يعني بالضرورة أن الذكاء الاصطناعي سيبني منزلاً أفضل. "فريق الهدم" (Claude Opus) هو من بنى التطبيقات الأكثر كفاءة، رغم أنه كان يعيد كتابة الملفات باستمرار. لم يكن هناك رابط مباشر بين "كونك حذراً في التعديلات" وبين "بناء تطبيق جيد".

5. لماذا يهم هذا؟

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

فهم تصميم بصري.
اختيار الأدوات المناسبة.
بناء منتج يعمل.
إصلاح أخطائهم بأنفسهم.

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

ملخص تقني: VISTA – معيار شامل لتقييم وكلاء البرمجة من المواصفات المرئية إلى تطبيقات الويب

بيان المشكلة

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

خلط المكدس التقني (Stack Conflagtion): تفرض العديد من المعايسات مكدساً تقنياً موحداً للتنفيذ، مما يخلط بين قدرة النموذج ومدى ملاءمة المكدس.
تجانس المدخلات: عادة ما تثبت المهام نمطاً واحداً من المدخلات (نص، لقطة شاشة، أو ملف تصميم)، متجاهلة طيف الدقة المرئية/الهيكلية المتاحة في المواصفات الواقعية.
التقييم المفكك: تفصل التقييمات غالباً بين النموذج الكبير (LLM) وبين إطار التنفيذ (execution harness)، متجاهلة كيف تؤثر واجهات الحاسوب والوكيل مادياً على الأداء.
عدم استقرار التقييم: الاعتماد على "النموذج كحكم" (LLM-as-judge) أو مقيمي متصفح الويب يؤدي إلى حساسية تجاه صياغة المطالبات وفشل الربط الأرضي (grounding)، خاصة في مهام واجهة المستخدم حيث يمكن للعناصر غير المسماة أن تغير النتائج.

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

المنهجية

بناء المعيار

يحدد VISTA مجموعة مهام تغطي 10 فئات من التطبيقات (مثل التجارة الإلكترونية، حجز السفر، الدردشة) و128 صفحة. يتم اشتقاق الحقيقة الأرضية (ground truth) من تصميمات Figma، المصدرة كصور PNG مصورة وهياكل JSON منقحة لتجنب التلوث من عمليات الزحف الويب الموجودة.

ظروف معلومات المطالبة (Prompt-Information Conditions):
يقيم المعيار الوكلاء عبر خمسة ظروف (C0–C4) تتنوع وفق محورين: الدقة المرئية/الهيكلية وقيد المكدس التقني.

C0: مطالبة نصية فقط؛ يختار الوكيل المكدس بحرية.
C1: نص + لقطات شاشة؛ يحل الوكيل المهمة تحت ثلاثة مكدسات محددة (متوسط).
C2: نص + لقطات شيرة؛ يختار الوكيل المكدس بحرية.
C3: نص + لقطات شاشة + هيكل JSON منقح من Figma؛ يستخدم الوكيل مكدساً واحداً محدداً (قالب مقدم).
C4: نص + لقطات شاشة + هيكل JSON منقح من Figma؛ يختار الوكيل المكدس بحرية.

التعليق البشري (Human Annotation):
للتغلب على قيود الاختبار الآلي في التوليد مفتوح النهايات، قام المؤلفون بالتعليق يدوياً على 3,253 مكوناً تفاعلياً (أزرار، روابط، حقول إدخال) و458 نقطة مرجعية بصرية عبر مجموعة البيانات. وهذا يتيح تقييماً دقيقاً وحتمياً بدلاً من الاعتماد على الربط الأرضي البصري غير المستقر.

مقاييس التقييم

يجمع إطار التقييم بين ثلاث إشارات متكاملة:

درجة الهيكل والوظيفة المرتبطة بـ DOM ( $S$ ): مقياس مشترك يقيس المحاذاة الهيكلية والصحة السلوكية.
- التوطين ( $L_i$ ): يتحقق مما إذا كانت الأهداف التفاعلية موجودة كعناصر DOM حقيقية بالقرب من الإحداثيات المرجعية باستخدام المحاذاة الأفينية ومعايير IoU/المسافة المركزية.
- السلوك ( $B_i$ ): ينفذ فحوصات محددة (التنقل، تبديل الحالة، التعامل مع المدخلات) على العناصر المتطابقة.
- الصيغة: $S = \frac{1}{N} \sum L_i \cdot B_i$ .
الدقة البصرية: يستخدم تشابه الصور القائم على نموذج CLIP لقياس التشابه البصري عالي المستوى بين التطبيق المولد والحقيقة الأرضية من Figma، ويُفسر جنباً إلى جنب مع الدرجات الهيكلية.
كفاءة الوكيل والمسار: يحلل مسارات العمل (الفحص، الكتابة، التحقق، الفشل) ويحدد درجة الفرق الجراحي (Surgical Diff Score). هذا المقياس يحدد نسبة العمل التعديلي المقدم عبر رقع (patches) محلية مقابل إعادة كتابة الملف بالكامل، مما يميز بين سير العمل "الجراحي" وسير العمل "القائم على إعادة الكتابة".

الإعداد التجريبي

قيم المعيار أربعة أنظمة وكلاء من عائلتين من النماذج (GPT-5.4, GPT-5.5) وإطارين عمل (Codex الموجه نحو الرقع؛ وClaude Code مع أدوات Write/Edit/MultiEdit).

النتائج الرئيسية

تأثير ظروف المدخلات

حرية المكدس أمر بالغ الأهمية: تم تحقيق أعلى أداء (الدرجة المشتركة) في ظل ظروف المكدس الحر (C2 وC4). وبينما أدت إضافة المدخلات المرئية (لقطات الشاشة، JSON الخاص بـ Figma) إلى تحسين درجات التوطين، فإن تثبيت المكدس (C1, C3) أدى غالباً إلى تقليل الصحة الوظيفية، مما يشير إلى أن الوكلاء يواجهون صعوبة في تركيب سلوكيات صحيحة فوق هياكل جامدة.
الانفصال بين المرئي والوظيفي: الدرجة البصرية (CLIP) والصحة الوظيفية (Behavior) منفصلتان جزئياً. على سبيل المثال، حقق GPT-5.5 أعلى درجة توطين (0.602) وأعلى درجات CLIP (0.853) ولكنه سجل أدنى درجة سلوك (0.283)، مما يشير إلى أنه يعيد إنتاج الهيكل البصري جيداً ولكنه يفشل في تنفيذ التفاعلات الصحيحة. وعلى العكس من ذلك، حقق Claude Opus أعلى صحة وظيفية (0.336) وأعلى درجة مشتركة (0.261) رغم انخفاض درجات التشابه البصري.

تحليل أسلوب التحرير

تعامد الأسلوب والجودة: أظهرت درجة الفرق الجراحي (التي تقيس التحرير المحلي) ارتباطاً سلبياً ضعيفاً ( $\rho = -0.145$ ) مع نجاح المهمة.
استراتيجيات خاصة بالنماذج:
- Claude Opus: حقق أفضل جودة للمهمة ولكنه اعتمد بشكل كبير على إعادة كتابة الملف بالكامل (حصة إعادة الكتابة 98.8%)، مما يشير إلى استراتيجية "التوليد والاستبدال".
- GPT-5.5: أظهر أعلى درجة فرق جراحي (33.6) ولكن أدنى جودة للمهمة، مما يشير إلى أن أسلوب التحرير "الجراحي" لا يضمن نتائج أفضل.
أنماط سير العمل: كشف تحليل المسار أن نماذج عائلة Claude تظهر انتقالات أقوى من نوع "فحص $\leftarrow$ فحص" و"فشل $\leftarrow$ فحص" (حلقات تشخيصية)، بينما تظهر نماذج عائلة GPT انتقالات أكثر تشتتاً بعد الفشل.

الأهمية والادعاءات

يضع البحث VISTA كقاعدة لتعزيز أبحوان هندسة البرمجيات القائمة على الوكلاء من خلال:

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

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