لماذا نحتاج إلى واجهات المستخدم إذا كانت لدينا نماذج اللغة الكبيرة

من سطر الأوامر إلى الواجهة — وبالعكس مرة أخرى

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

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

طريقة طرح السؤال وطريقة تلقي الجواب — مهمتان مختلفتان

عندما يتحدث الناس عن واجهة نماذج اللغة الكبيرة، يتخيلون محادثة: نص ← نص جوابي. لكن في الواقع هما معياران مستقلان. يمكن طرح الطلب صوتياً — فالجمل الطويلة التي تحمل عدة شروط يُنطق بها أسرع من كتابتها على الهاتف. جملة مثل «أرني مشاريع فريقي التي زاد فيها مدة التسليم خلال الشهر الأخير دون أن يتغير نطاق العمل» يمكن قولها دون توقف تقريباً.

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

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

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

أربع طرق لتنفيذ ذلك

الأولى: الواجهة التوليدية المضبوطة (Controlled generative UI)

يوفّر المنتج مجموعة من المكونات: ExpenseChart، ComparisonTable، HotelCards، Map، Confirmation. لا يرسم النموذج الشاشة، بل يختار المكون المناسب، ويحصل على البيانات، ويعيد كائن JSON منظم:

``` { "component": "ExpenseBreakdown", "period": "6m", "data": [...], "groupBy": "category" } ```

يتحكم المصمم والمطور بشكل كامل في المظهر، والسلوك، وإمكانية الوصول، وحالات الخطأ. ولا يفعل النموذج سوى اختيار التمثيل وتمرير البيانات إليه. وهذا النهج مُطبَّق في CopilotKit.

الثانية: وصف تصريحي من وحدات بناء أساسية

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

الثالثة: MCP Apps بواجهة جاهزة

تعيد الأداة واجهة تفاعلية يعرضها العميل داخل iframe معزول. ويمكن استخدام تقنيات الويب العادية: HTML وCSS وJavaScript، وإنشاء نماذج ورسوم بيانية وخرائط وسيناريوهات متعددة الخطوات. ويدعم ذلك عملاء MCP مختلفون، وتطبيقات داخل ChatGPT. وهنا يتحكم مزوّد الأداة في المظهر أكثر من العميل.

الرابعة: التوليد الكامل لـHTML/CSS/JavaScript

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

كيف سيتغير التطوير

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

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