تريد إنشاء تطبيق ويب عربي يعرض خدماتك أو ينظم عملًا بسيطًا، لكنك لا تعرف كيف تبدأ بكتابة الكود؟ يساعدك شرح Lovable بالعربي على تحويل الفكرة إلى متطلبات واضحة، ثم بناء نسخة أولية وفحصها قبل التفكير في النشر. سنستخدم مثال دليل خدمات قابل للبحث، ونضيف الوظائف على مراحل بدل طلب منصة كبيرة دفعة واحدة.
البداية المناسبة: اطلب واجهة عربية تعمل ببيانات تجريبية، اختبر التصفح والبحث على الهاتف، ثم قرر هل تحتاج تسجيل دخول وقاعدة بيانات. تتيح Lovable البناء بالمحادثة والمعاينة والنشر، لكن ظهور التطبيق لا يعني اكتمال الحفظ أو صلاحيات المستخدمين. راجعنا المصادر الرسمية في 20 أكتوبر 2026؛ الأمثلة التالية مقترحات للتطبيق، وليست نتائج اختبار أجريناه على حساب مدفوع.
إذا لم تحسم الأداة، ارجع إلى مقارنة Lovable وBolt وReplit لإنشاء التطبيقات بالذكاء الاصطناعي. يركز هذا الدليل على استخدام Lovable نفسها، من كتابة أول طلب إلى مراجعة البيانات والنشر وتكاليف التشغيل.
ما هي Lovable وما الذي تستطيع بناءه بها؟
تطبيق ويب من وصف مكتوب
تصف وثائق Lovable المنصة باعتبارها بيئة لبناء تطبيقات الويب بلغة طبيعية. تكتب ما تريد، ثم تراجع التطبيق في المعاينة وتطلب تغييرات. يوجد فرق بين حسابك الشخصي ومساحة العمل والمشروع؛ المشروع يمثل التطبيق، بينما تضم مساحة العمل المشاريع والأعضاء والفوترة والرصيد المشترك.
يمكن أن تبدأ بصفحة لخدمات مستقلة، أو دليل أدوات، أو لوحة لمتابعة الطلبات. المقصود بتطبيق الويب أنه يعمل من المتصفح؛ هذا الشرح لا يتناول بناء ملف APK أو نشر تطبيق أصلي في المتاجر. حدد أولًا ما يحتاجه المستخدم داخل المتصفح، ثم اختر خطوات صغيرة تستطيع الحكم على نجاحها.
ما الذي لا تحسمه الأداة بدلًا منك؟
الأداة لا تعرف شروط خدمتك أو قواعد الوصول التي لم تذكرها. زر «حفظ» قد يعمل في الواجهة بينما تختفي البيانات بعد إعادة التحميل. وصفحة «لوحة الإدارة» قد تكون مجرد شاشة بلا تحقق من هوية المسؤول. لذلك يجب أن تتضمن المتطلبات سلوك التطبيق، لا أسماء صفحاته وألوانه فقط.
ابدأ بفكرة يستطيع شخص واحد تجربتها في دقائق. إذا كان هدفك دليل خدمات، فالنجاح الأول هو العثور على خدمة وقراءة تفاصيلها والوصول إلى وسيلة تواصل صحيحة. الدفع والاشتراكات وإدارة فريق كامل مراحل لاحقة، وليست شروطًا لتقييم ما إذا كانت الفكرة مفيدة أصلًا.
تجهيز فكرة التطبيق قبل أول طلب
حدد المستخدم والوظيفة الأساسية
في مثالنا، المستخدم صاحب مشروع يبحث عن خدمة، وصاحب الدليل يحتاج عرض خدماته بوضوح. سنجهز ست خدمات تجريبية موزعة بين كتابة المحتوى والتصميم والتطوير. لكل خدمة اسم وتصنيف ووصف مختصر ومدة تنفيذ افتراضية. لا نضيف تقييمات أو عملاء أو أرقام إنجازات لم تحدث.
اكتب خارج المنصة ما يجب أن ينجزه الزائر: تصفح الخدمات، والتصفية حسب التصنيف، والبحث بالاسم، وفتح التفاصيل، ثم الانتقال إلى التواصل. وحدد ما لن تفعله النسخة الأولى: لا حسابات، ولا مدفوعات، ولا تخزين بيانات عملاء. هذه الحدود تقلل إعادة العمل وتمنع اختلاف تصورك عن تصور المولد.
ضع شروط قبول يمكن تجربتها
بدل «اجعل التطبيق احترافيًا»، اكتب أن البحث يجب أن يجد الخدمة من جزء من اسمها، وأن التصفية تعرض التصنيف المختار فقط، وأن غياب النتائج يعرض رسالة مفهومة. أضف شرط عدم خروج البطاقات والأزرار عن عرض الهاتف. الآن لديك معايير تستطيع ملاحظتها، وليس انطباعًا عامًا عن جمال الصفحة.
جهّز النصوص التي تريد نشرها لاحقًا، وحدد أي معلومات مؤقتة. إذا وضعت سعرًا تجريبيًا، اكتب داخل النموذج أنه مثال غير معتمد. لا تجعل النص الافتراضي ينتقل إلى النسخة العامة دون مراجعة؛ البيانات التجريبية يجب أن تساعدك على الفحص، لا أن تتحول إلى عرض تجاري غير مقصود.
طريقة استخدام Lovable لإنشاء أول تطبيق
1. افتح المشروع واكتب طلب البداية
ادخل من الموقع الرسمي وسجّل الدخول بالطريقة التي تناسبك. يوضح دليل البداية إنشاء المشروع من وصف، ثم العمل بين المحادثة والمعاينة. اختر Build لتنفيذ النسخة الأولى، وتحقق من مساحة العمل التي سيُحفظ فيها المشروع قبل استخدام رصيدها.
استخدم هذا الطلب المقترح: «أنشئ دليل خدمات عربيًا باتجاه RTL. أضف ست خدمات تجريبية بثلاثة تصنيفات، وحقل بحث بالاسم، وأزرار تصفية، وصفحة تفاصيل لكل خدمة، وزر تواصل تجريبي واضح. اجعل الواجهة مناسبة للهاتف. استخدم بيانات ثابتة فقط؛ لا تضف تسجيل دخول أو قاعدة بيانات أو دفع في هذه المرحلة».
2. افحص ما بُني قبل طلب إضافة أخرى
انتظر اكتمال النسخة ثم جرّب رحلة الزائر كاملة داخل المعاينة. افتح خدمة، وعد إلى القائمة، وغيّر التصنيف، وابحث عن اسم موجود وآخر غير موجود. دوّن ما حدث وما تتوقعه. لا تبدأ بطلب تغيير الألوان إذا كان زر التفاصيل يفتح خدمة مختلفة أو لا يعمل.
إذا أعجبك التصميم، احتفظ به أثناء الإصلاح. مثال طلب واضح: «عند اختيار التصميم تظهر خدمات البرمجة أيضًا. أصلح التصفية فقط، مع الحفاظ على ترتيب الصفحة والألوان والنصوص». الطلب المحدد أسهل في المراجعة من عبارة «أصلح كل شيء واجعل الموقع أفضل» التي تفتح باب تغييرات لا تحتاجها.
3. حسّن النصوص والعناصر المحددة
تذكر الوثائق أدوات اختيار عناصر المعاينة وتعديل النص مباشرة للمهام البصرية الصغيرة. استخدمها عندما تعرف العنصر والصياغة المطلوبين، واطلب من المساعد التعديل عندما يتعلق الأمر بالسلوك أو العلاقة بين الصفحات. راجع المعاينة بعد كل تغيير بدل تجميع قائمة طويلة من التعديلات ثم محاولة معرفة ما تسبب بالمشكلة.
إذا أردت فهم العلاقة بين الواجهة وملفات HTML وCSS وJavaScript، يمكنك متابعة شرح Cursor لبناء أول صفحة ويب ومراجعة الكود. فهم الأساسيات يساعدك على وصف الخلل حتى لو واصلت البناء في Lovable ولم تنتقل إلى محرر مستقل.
تجهيز التطبيق العربي للهاتف
اتجاه القراءة والمساحات
اطلب اتجاه RTL للتطبيق، ثم افحص العناوين والأزرار والقوائم والنص المختلط بالإنجليزية. المحاذاة لليمين وحدها لا تكفي إذا بقي ترتيب الأيقونة والسهم مناسبًا لواجهة إنجليزية. جرّب أسماء خدمات طويلة، ولا تكتفِ بالكلمات القصيرة التي اختارها المولد في أول نسخة.
في الدليل، يمكن عرض بطاقة واحدة في الصف على الهاتف بدل ثلاث بطاقات ضيقة. اجعل زر فتح التفاصيل واضحًا، وحافظ على مسافة بين نهاية الوصف والزر. إذا أضفت جدول أسعار لاحقًا، اطلب احتواءه داخل مساحة قابلة للتمرير دون توسيع الصفحة كلها أو ضغط أسماء الخطط إلى حروف متفرقة.
رسائل الخطأ والحالات الفارغة
لا تقيّم التطبيق بحالة النجاح فقط. ماذا يظهر عند البحث عن خدمة غير موجودة؟ وهل يستطيع الزائر مسح البحث والعودة إلى القائمة؟ أضف نصًا مباشرًا مثل «لم نجد خدمة بهذا الاسم؛ جرّب كلمة أخرى». واستخدم رابطًا أو زرًا واضحًا لإعادة الضبط بدل ترك شاشة فارغة توحي بتوقف التطبيق.
جرّب أيضًا إدخال مسافات قبل الاسم وبعده، وأسماء عربية تحتوي همزات مختلفة إذا كان جمهورك يكتبها بهذه الطرق. ليس مطلوبًا دعم كل اختلاف لغوي منذ البداية، لكن يجب أن تعرف حدود البحث وتصف السلوك الذي تحتاجه. اختبر بنفسك ما إذا كان المولد نفذه كما طلبت.
لتحديد هذه التفاصيل في طلبك، راجع برومبتات تصميم المواقع العربية وواجهات RTL. ستجد قوالب لصفحات الهبوط والنماذج والنصوص المختلطة وفحص الهاتف، يمكنك تخصيصها لمشروعك في Lovable ثم مراجعة التنفيذ.
اختبار قبول قبل توسيع دليل الخدمات
جرّب رحلة زائر لأول مرة
ابدأ من الصفحة الرئيسية دون استخدام معرفتك بمكان الأزرار. ابحث عن خدمة كتابة، وافتح تفاصيلها، ثم عد إلى النتائج. تحقق هل يحتفظ التطبيق بكلمة البحث أم يعيد كل شيء للبداية، وحدد أي السلوكين تريده. جرّب زر الرجوع في المتصفح أيضًا، لأن التنقل داخل المعاينة وحده قد لا يكشف مشكلة روابط الصفحات.
بعد ذلك غيّر اسم خدمة إلى عنوان أطول، واترك وصف خدمة أخرى قصيرًا. يجب أن تبقى البطاقات مقروءة دون أن يعتمد التصميم على تساوي النصوص. إذا احتاج المستخدم إلى التكبير لقراءة المدة أو وسيلة التواصل، فهذه مشكلة تستحق الإصلاح قبل إضافة مزيد من الخدمات، حتى لو كان النموذج الأول جذابًا.
اكتب تقرير خلل يستطيع المساعد تنفيذه
سجل أربع معلومات: الصفحة، والخطوات، والنتيجة الحالية، والنتيجة المطلوبة. مثال: «في صفحة الخدمات على الهاتف، أختار الكتابة ثم أبحث عن تصميم؛ تظهر بطاقات من تصنيفين. المطلوب أن يعمل البحث داخل التصنيف المختار، وأن يظهر زر لمسح البحث». بهذا الوصف يستطيع المولد فهم العلاقة بين ميزتين، ويمكنك إعادة الخطوات نفسها بعد الإصلاح للحكم على النتيجة.
إضافة قاعدة بيانات وتسجيل دخول عند الحاجة
متى تتجاوز البيانات الثابتة؟
عندما تحتاج إضافة خدمات من لوحة تحكم أو حفظ طلبات تتبعها لاحقًا، تصبح قاعدة البيانات مفيدة. توضح وثائق Lovable Cloud وجود خلفية مدمجة تتناول البيانات والمصادقة والتخزين. ويمكن أن تختلف طريقة إعداد المشروع إذا اخترت خدمة خارجية مثل Supabase؛ افهم المسار المختار قبل إضافة جداول وحسابات. وعندما تحتاج إلى إعداد تقارير من بيانات التطبيق، راجع شرح BlazeSQL لسؤال قاعدة البيانات وإنشاء التقارير، وتحقق أولًا من توافق قاعدة مشروعك وإتاحة الاتصال بها.
حدد أولًا ما الذي سيُحفظ: خدمة بمعرف وتصنيف ووصف وحالة ظهور، أم طلب عميل ببيانات تواصل؟ في النسخة التجريبية استخدم سجلات وهمية. واطلب من Lovable شرح مكان التخزين وما إذا كانت البيانات ستبقى بعد تحديث الصفحة وفتح التطبيق من جهاز آخر؛ ثم اختبر ذلك بدل الاكتفاء بالإجابة المكتوبة.
المصادقة تختلف عن صلاحيات البيانات
وجود شاشة تسجيل دخول لا يثبت أن المستخدم لا يستطيع قراءة سجل مستخدم آخر. توضح وثائق الأمان أهمية سياسات RLS للتحكم في الوصول إلى صفوف البيانات. يجب أن تحدد من يقرأ ومن يضيف ومن يعدل؛ إخفاء الزر في الواجهة لا يغني عن فرض الإذن في الخلفية.
إذا أضفت طلبات، جرّب حسابين تجريبيين منفصلين: أنشئ طلبًا بالأول ثم تحقق أن الثاني لا يراه أو يعدله إن كانت هذه القاعدة المطلوبة. اطلب مراجعة المسارات العامة ولوحة المسؤول أيضًا. لا تستقبل طلبات حقيقية قبل مراجعة الوصول والحفظ وطريقة حذف البيانات التي لا تحتاجها.
التراجع عن تعديل ومراجعة الكود
ارجع إلى إصدار واضح بدل ترقيع متكرر
تتيح وثيقة سجل الإصدارات مراجعة نسخ المشروع واستعادتها. قبل تغيير كبير، سجّل النسخة التي كانت تعمل وما الذي اختبرته فيها. إذا عطلت إضافة تسجيل الدخول البحث والتصفح، قارن التغييرات أو استعد نقطة واضحة، ثم أعد التنفيذ بنطاق أصغر.
لا تفترض أن استرجاع واجهة قديمة يعكس كل أثر حدث في خدمة خارجية أو قاعدة بيانات. راجع ما تتضمنه عملية الاستعادة في مشروعك، واحتفظ بنسخة بيانات مناسبة قبل التعديلات المؤثرة. أسماء الإصدارات مفيدة عندما تصف النتيجة، مثل «البحث والتصفية يعملان»، بدل سلسلة أسماء لا تتذكر معناها.
احتفظ بخيار نقل المشروع
تشرح وثائق الملكية والاستضافة إمكانية الاحتفاظ بالكود عبر Git sync والعمل خارج المنصة. نقل الكود لا يعني انتقال قاعدة البيانات والمفاتيح والنطاق تلقائيًا؛ افصل هذه المكونات عند التفكير في استضافة أخرى. واحتفظ بوصف قصير لطريقة التشغيل والخدمات المرتبطة حتى يستطيع مطور مراجعتها لاحقًا.
خطة Lovable المجانية وفهم الرصيد
البناء والتشغيل نوعان مختلفان من الاستخدام
وقت المراجعة، تعرض صفحة التسعير منحة بناء مجانية قدرها خمسة أرصدة يوميًا حتى 30 شهريًا. وتشرح وثائق الاستخدام أن الرصيد قد يغطي البناء وتشغيل Cloud وميزات AI وفق نوع الرصيد والمنح والخطة. لذلك لا تحسب التكلفة من عدد الرسائل وحده.
قد يتوقف البناء عند نفاد حصتك رغم بقاء مشروعك محفوظًا، وقد يستهلك تطبيق منشور موارد تشغيل دون إرسال طلب تطوير جديد. افحص تفاصيل Usage لمعرفة ما استُهلك وفي أي مشروع. الرسائل الواسعة قد تتطلب عملًا أكبر، بينما تصحيح عبارة أو عنصر محدد لا يساوي بناء ميزة متكاملة.
كيف تقلل الإنفاق دون تعطيل التعلم؟
جهّز المتطلبات والأمثلة قبل فتح المحادثة، واجمع المعلومات المتعلقة بالخلل نفسه في طلب واضح. لا تكرر التوليد لتغيير لون تعرف كيف تحدده. وقبل ترقية الخطة، راجع السعر الإجمالي وفترة الفوترة وحصة الرصيد وضوابط الزيادة؛ أسعار الخطط وتفاصيل المنح تتغير، والمرجع النهائي هو العرض الحالي في حسابك.
ضع ميزانية للمحاولات، وسجل ما أنجزته بكل مرحلة: واجهة، وبحث، وحفظ، وصلاحيات، واختبار. إذا استهلكت الإصلاحات معظم الرصيد، فقد تحتاج تبسيط الفكرة أو مراجعة تقنية. الاشتراك الأعلى لا يعوض متطلبات متناقضة أو إضافة مزايا قبل التحقق من أساس التطبيق.
نشر التطبيق وفحص النسخة العامة
المعاينة ليست النسخة التي يراها الزائر
وفق دليل النشر، افتح Publish وراجع العنوان والجمهور وفحص الأمان قبل تأكيد النشر. تتيح المنصة عنوانًا ينتهي بـlovable.app، وتختلف بعض خيارات الوصول والنطاق بحسب الخطة. التعديلات اللاحقة تظهر في المعاينة، لكنها تحتاج Publish changes للوصول إلى النسخة المنشورة.
افتح الرابط النهائي بعد النشر من نافذة غير مسجلة، وكرر البحث والتصفية وفتح التفاصيل. تأكد أن أزرار التواصل لم تعد تجريبية وأن الخدمات غير المعتمدة لا تظهر. وإذا أردت إبقاء التطبيق خاصًا، اختبر أن الوصول مقيّد فعلًا؛ خصوصية المشروع داخل المحرر تختلف عن إمكانية زيارة الموقع المنشور.
متى تحتاج مساعدة مطور؟
استعن بمراجعة تقنية عندما يتعامل التطبيق مع بيانات خاصة أو مدفوعات أو صلاحيات متعددة أو أعطال لا تستطيع تفسيرها. يمكنك الاطلاع على مقارنة مساعدات البرمجة Cursor وCopilot وDevin لفهم مسارات العمل على الكود، لكن امتلاك مساعد إضافي لا يغني عن شخص يفهم المنطق والأمان.
ابدأ في Lovable بوظيفة صغيرة تخدم مستخدمًا واضحًا. اجعل البناء سلسلة من طلب وتنفيذ واختبار، ثم أضف البيانات والحسابات عندما تثبت الحاجة إليها. التطبيق الجيد هو الذي يؤدي المطلوب ويحافظ على بياناته ويمكن صيانته؛ جمال المعاينة خطوة مفيدة، لكنه ليس نهاية العمل.
