هل يمنح اقتراح واجهة صلاحية تنفيذ العمليات؟

يمكن للذكاء الاصطناعي أن يقترح ترتيب الشاشة والمعلومات المعروضة والإجراءات المتاحة. أما تطبيق الاقتراح وصحة البيانات وصلاحية التنفيذ فتحتاج إلى قرارات منفصلة. كيف أتعامل مع هذا الحد في Muhit؟

لنتخيّل أننا نريد مراجعة ملاحظة بحثية. نطلب من النظام عرضاً يجمع المصادر ويبيّن ما ينقصها.

يقترح النموذج ملخّصاً وجدولاً للمصادر وبعض الإجراءات. وقد تظهر على الشاشة أزرار مثل «مراجعة الملاحظة» أو «تطبيق التصحيح» أو «نشر».

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

ما يشغلني في جانب توليد الواجهات بالذكاء الاصطناعي في Muhit هو ألّا تبقى هذه الأسئلة معلّقة خلف الشاشة.

يحتاج الاقتراح إلى شكل مفهوم

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

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

يعمل محوّل واجهات JSON في Muhit بوصفه الطبقة التي تحوّل هذا الاقتراح إلى مكوّنات محدّدة. الاتصال بالنموذج مسؤولية التطبيق؛ ولا يتضمّن المحوّل نموذجاً يعمل من تلقاء نفسه أو خدمة لتنفيذ عمليات مستقلة.

يُتحقّق أولاً من التعريف الوارد. فتُفحص أنواع المكوّنات والحقول المطلوبة والقيم المدعومة. ويُعرض التعريف الصالح على الشاشة باستخدام المكوّنات المسموح بها.

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

لكن علينا فهم ما يخبرنا به هذا التحقّق فعلاً.

فكون العنوان مكتوباً بصيغة صحيحة لا يثبت صحة الادّعاء الوارد تحته. واحتواء الجدول على صفوف صالحة لا يثبت أن سجلاته حديثة. ووجود إجراء في التعريف لا يعني أن تنفيذه مسموح.

لا يستطيع تعريف واجهة صالح أن يحسم بمفرده صحة المحتوى أو صلاحية تنفيذ العملية.

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

الطريق من الزر إلى العملية الفعلية

في Muhit، يمكن لإجراء في بطاقة أن يرسل إلى التطبيق حدثاً يحمل معرّفَي المكوّن والإجراء. ويربط التطبيق هذا الحدث بسلوك يعرفه.

فمثلاً، قد يفتح إجراء «مراجعة الملاحظة» تفاصيل سجل يحدّده التطبيق. ولا يقرأ المحوّل اسم الإجراء ليولّد عنواناً من تلقاء نفسه، أو يحفظ بيانات، أو يبدأ عملية نشر.

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

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

هذا المسار ليس نظام نشر يقدّمه Muhit وحده. إنه مثال على سلوك تطبيقي يمكن بناؤه بمكوّنات Muhit.

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

لذلك لا يكفي ربط الصلاحية بظهور الزر على الشاشة. يجب تقييمها أيضاً في الطبقة التي تُنفَّذ فيها العملية.

تناولتُ في المقال الثاني الفرق بين التأكيد المحلي والتخزين الدائم. وينطبق المبدأ نفسه هنا: يجب أن تصف النتيجة التي تعلنها الواجهة نطاق ما حدث فعلاً.

يبدأ تحكّم الإنسان من الفهم

من السهل اختزال التحكّم في زر تأكيد. لكن إن لم يفهم الشخص ما يوافق عليه، فلا يكفي وجود الزر.

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

تشكّل هذه المعلومات سياق القرار.

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

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

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

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

هذا هو الحد الذي أحاول بناءه في Muhit: تحديد مجال اقتراح النموذج بوضوح، مع إبقاء مسؤولية التطبيق وقرار الإنسان ظاهرين.

إمكان توليد شاشة يفتح مجالاً مهماً. أما استخدامها بثقة فيتوقّف على فهم الطريق من الاقتراح إلى النتيجة الفعلية.

حين يستطيع المستخدم أن يقول: «هذا اقترحه النظام؛ وهذا الجزء عدّلته أنا؛ وهذه العملية اخترتها أنا؛ وهذه النتيجة حدثت فعلاً»، تفتح الواجهة مجالاً للإنتاج وتحافظ في الوقت نفسه على أثر القرار.

---

المصدر: عقد واجهات JSON في Muhit ومبادئ التصميم في مصدر التطوير المحلي. الملاحظة البحثية ومسار النشر سيناريوهان توضيحيان لشرح حدود المسؤولية.

مقالات Muhit السابقة: Muhit: ما الذي يجعل الواجهة متّسقة؟ · Muhit: كيف يعمل قرار التصميم على الشاشة؟

مفاهيم الأطلس: التصميم · البرمجيات · السياق · الأنظمة · الذكاء