ابنِ نموذجًا أوليًا يعمل لتطبيقك بالذكاء الاصطناعي وضعه بين أيدي الناس

لماذا يخبرك النموذج الأولي العامل أكثر من التصميم الثابت

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

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

حدّد ما يجب أن يثبته النموذج الأولي

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

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

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

كيف تصفه لـ Anticode

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

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

اجعل الأجزاء المحاكاة صريحة

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

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

إدارة الجلسات وتعديل النموذج

1. انشر النموذج الأولي على عنوانه في anticode.dev وأرسل الرابط إلى المختبِرين. لا شيء يحتاج إلى تثبيت.
2. أما لأصحاب المصلحة، فأرسل رابط مراجعة العميل بدلًا من ذلك: يمكنهم فتح المعاينة الحالية دون حساب وترك تعليقات مرتبطة بقسم معيّن. تنتهي صلاحية الروابط بعد 14 يومًا افتراضيًا ويمكنك إلغاؤها.
3. بعد كل جولة، اطلب التغييرات بكلمات بسيطة («انقل زر التبديل إلى كل بطاقة مناوبة»). تُحفظ التعديلات الأخيرة في سجل الإصدارات (حتى عدد تحدده خطتك)، فيمكنك عرض الجولة الأولى والثالثة جنبًا إلى جنب أو العودة إلى السابق.

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

كن واضحًا مع نفسك بشأن الحدود. يعمل النموذج الأولي المعزول على جهاز واحد في كل مرة، لذا لا يستطيع اختبار:

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

حين تصمد الفكرة أمام الاختبار، يكون التصدير إلى Next.js الخطوة نحو منتج حقيقي. يشمل التطبيقات ويمنحك مشروع App Router قياسيًا بلغة TypeScript مع Postgres عبر Prisma، وتسجيل دخول بالبريد الإلكتروني، وأدوار للعملاء والموظفين، ومنطقة إدارة. إنه نقطة بداية سيوسّعها مطوّر، لا تطبيق متعدد المستخدمين مكتمل، ويمكنك دفعه إلى مستودع GitHub تختاره. ويشرح دليل التصدير إلى Next.js ما يحتويه. وإن كنت تحتاج إلى ميزات متعددة المستخدمين جاهزة للإنتاج دون كتابة كود، فقد تناسبك أداة بلا كود مدعومة بخادم أكثر من أي من الخيارين.

أسئلة شائعة

هل هذه أداة لإنشاء نماذج أولية للتطبيقات بالذكاء الاصطناعي أم أداة تصميم؟

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

هل يستطيع المختبِرون استخدامه على هواتفهم؟

نعم. التطبيق المنشور صفحة ويب تعمل في متصفح الهاتف، وكل ما يحفظه يبقى على ذلك الهاتف.

هل أستطيع رؤية ما أدخله المختبِرون؟

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

هل يصبح النموذج الأولي هو التطبيق الحقيقي؟

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