كيف تحوّل نموذجاً أولياً بالذكاء الاصطناعي إلى نسخة إنتاجية

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

النموذج الأولي مقابل الإنتاج: ما الذي يتغير فعلاً؟

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

يمضي باقي هذا الدليل عبر كل صف من هذا الجدول.

الخطوة 1: جمّد النطاق واكتب المسارات الرئيسية

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

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

الخطوة 2: اختبر كغريب، ثم اجعل الاختبار قابلاً للتكرار

منشئو التطبيقات بالذكاء الاصطناعي بارعون في إنتاج شيفرة تعمل في المسار السعيد. أما مشكلات الإنتاج فتعيش في المسارات غير السعيدة. اختبر كل مسار رئيسي بالآتي:

• مدخلات سيئة: حقول إلزامية فارغة، واسم من 5000 حرف، وبريد إلكتروني بلا علامة @، وكمية سالبة، وتاريخ في الماضي.
• التحديث ومفتاح الرجوع: أعد تحميل الصفحة في منتصف الدفع؛ واضغط الرجوع بعد إرسال نموذج. هل يُنشأ شيء مرتين؟
• تبويبان، ومستخدمان: سجّل الدخول بحسابين مختلفين، وحاول فتح صفحات الآخر بتغيير المعرّف في الرابط.
• بطيء وصغير: شاشة بحجم الهاتف واتصال بطيء (تستطيع أدوات المطور في المتصفح محاكاته).
• الحالات الفارغة: حساب جديد تماماً دون بيانات. النماذج الأولية غالباً تُبنى ببيانات عينة وتبدو معطلة بدونها.

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

أضف اختبارات آلية من طرف إلى طرف لهذه المسارات: التسجيل بالبريد الإلكتروني، وإنشاء مشروع، ودعوة مستخدم ثانٍ، وإتمام الدفع في وضع الاختبار في Stripe. وأضف أيضاً اختبارات تؤكد أن المستخدم لا يستطيع عرض مشروع مستخدم آخر أو تعديله بتغيير الرابط.

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

الخطوة 3: أساسيات الأمان التي تغفل عنها النماذج الأولية

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

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

طلب يغطي الكثير دفعة واحدة:

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

طلب قائمة أولاً يتيح لك رؤية المشكلات وتحديد ترتيب المعالجة، بدلاً من استلام تغيير ضخم واحد.

الخطوة 4: اعرف متى يتعطل التطبيق — التسجيل والمراقبة

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

1. سجلات الخادم. تأكد من تسجيل الأخطاء مع سياق كافٍ لإعادة إنتاجها: أي مسار، وأي معرّف مستخدم (لا كلمة المرور ولا بيانات البطاقة)، وشكل المدخل. اطلب من الذكاء الاصطناعي إضافة تسجيل منظم إذا كان التطبيق يطبع فقط في الكونسول.
2. تتبع الأخطاء. خدمة مثل Sentry أو أداة مشابهة تلتقط استثناءات الواجهة الأمامية والخلفية، وتجمعها، وترسل لك رسائل بريدية. بالنسبة لتطبيق صغير، غالباً ما تكفي الخطط المجانية لهذه الخدمات؛ راجع الحدود الحالية على مواقعها.
3. فحوصات التوفر. خدمة خارجية تحمّل صفحتك الرئيسية ومسار API مهماً كل بضع دقائق، وتنبهك إذا فشلت. هذا يلتقط المشكلات التي توقف التطبيق عن التسجيل أصلاً.

أضف عادة واحدة: بعد كل إصدار، افتح التطبيق الحي وشغّل قائمة فحص المسارات الرئيسية على الرابط الحقيقي، لا على المعاينة فقط.

الخطوة 5: النسخ الاحتياطية وطريق العودة

هناك شيئان مختلفان يجب حمايتهما، وسهل الخلط بينهما:

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

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

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

الخطوة 6: أداء يصمد على الهاتف

النماذج الأولية تبدو سريعة لأنك المستخدم الوحيد وحجم البيانات صغير. قبل الإطلاق:

• حمّل بيانات بحجم حقيقي. اطلب من الذكاء الاصطناعي إدخال بضعة آلاف من الصفوف لمعرفة أي الصفحات تبطؤ. القوائم غالباً تحتاج إلى ترقيم صفحات، وقاعدة البيانات غالباً تحتاج إلى فهارس على الأعمدة التي تفلترها وترتّبها.
• صغّر الصور. الصور كبيرة الحجم هي السبب الأكثر شيوعاً لبطء تحميل الصفحات. اطلب صوراً مُعادة الحجم ومضغوطة، وتحميلاً مؤجلاً للصور خارج الجزء الظاهر.
• قِس. شغّل Lighthouse في أدوات المطور في Chrome على الرابط الحي في وضع الهاتف. مقاييس Core Web Vitals من Google هدف معقول: أن يظهر أكبر محتوى خلال 2.5 ثانية، وأن يكون التفاعل التالي (INP) 200 ملّي ثانية أو أقل، وأن يكون تحول التخطيط التراكمي (CLS) 0.1 أو أقل.
• انتبه لتأخير «الاستيقاظ». الاستضافة التي تنام عند الخمول توفر المال لكنها تجعل الزيارة الأولى بعد فترة هدوء أبطأ. وهذه مقايضة مقبولة غالباً لتطبيق جديد، لكن يجب أن تعرف أنها تحدث.

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

الخطوة 7: أساسيات التشغيل

بعض الأشياء الصغيرة تفرّق بين تطبيق هواة وتطبيق يثق به الناس:

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

الخطوة 8: تسليم نظيف

عاجلاً أم آجلاً سيعمل شخص آخر على التطبيق: مستقل، أو شريك مؤسس جديد، أو أنت بعد ستة أشهر. اجعل ذلك سهلاً:

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

يستطيع الذكاء الاصطناعي صياغة معظم هذا لك:

اكتب ملف README لهذا المشروع لمطور لم يره من قبل: ما الذي يفعله التطبيق، والتقنيات المستخدمة، وكيف يُشغَّل محلياً، وكل متغير بيئة يقرؤه (الأسماء والغرض فقط)، وكيف تُنظَّم مخططات قاعدة البيانات، وكيف يُنشر.

قائمة الجاهزية للإنتاج

• المسارات الرئيسية مكتوبة ومختبرة، بما فيها «لا يمكن الوصول إلى بيانات شخص آخر»
• تحقق من الصلاحيات والمدخلات على الخادم في كل مسار بيانات
• لا توجد مفاتيح أسرار في شيفرة الواجهة الأمامية؛ وأي مفتاح تسرّب تم تغييره
• حدود معدل على المصادقة وأي شيء يكلّف مالاً
• تتبع للأخطاء وتنبيهات توفر تصل إلى بريد تقرؤه
• نسخ احتياطية لقاعدة البيانات خارج استضافة التطبيق، مع استعادة تجريبية ناجحة واحدة
• تم فحص الترقيم والفهارس ببيانات واقعية الحجم
• نطاق مخصص، ونطاق مُوثّق للإرسال، وسياسة خصوصية
• ملف README وقائمة صلاحيات لمن سيأتي بعدك

العمل مع Mythex

إذا بنيت النموذج الأولي في Mythex، فمعظم هذه الخطوات مجرد طلبات في المشروع نفسه. اكتب /test وسيتصفح Mythex المعاينة الحية كمستخدم ويبلغ عن المسارات المعطلة — انظر اختبار التطبيقات. تُوضع المفاتيح في أسرار المشروع لا في المحادثة، وكل دورة ناجحة للوكيل تحفظ نقطة حفظ لملفاتك يمكنك الرجوع إليها، وينشرك النشر على رابط حي مع الاستضافة وقاعدة البيانات، وتُخصم كلها من رصيد واحد (حدود الاستضافة توضح كيف تنام التطبيقات وقواعد البيانات وتستيقظ). نقاط الحفظ تغطي الملفات لا صفوف قاعدة البيانات، لذا خطط لنسخ البيانات الاحتياطية بنفسك. وفي خطة Pro يمكنك ربط نطاق مخصص، أو تصدير الشيفرة، أو مزامنتها مع مستودع GitHub الخاص بك لتسليمها.

الأسئلة