كيف تستخدم Lovable لبناء تطبيق ويب كامل من وصف نصي

الخطوات

1. 1

   الخطوة 1: قرر هل Lovable يناسب مشروعك قبل ما تبدأ

   Lovable يناسب: شخص ما يبرمج وعنده فكرة تطبيق، فريق يحتاج أداة داخلية بدون ما ينتظر المطورين، أو مشروع MVP تبي تختبره قبل ما تستثمر فيه. ما يناسب: تطبيق فيه منطق أعمال معقد ومخصص، شغل داخل قاعدة كود كبيرة موجودة أصلًا، أو أي موقف تحتاج فيه تكلفة متوقعة بدقة — لأن استهلاك الكريدت صعب تتنبأ فيه مقدمًا.

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

2. 2

   الخطوة 2: ابدأ بوصف واحد مفصل، مو وصف سريع

   روح لـ`lovable.dev`، استخدم الكريدت المجاني اليومي، وصف تطبيقك بفقرة واحدة مفصلة: الهدف، الشاشات الرئيسية، ومين يستخدمه. صف السلوك لا طريقة التنفيذ — مثلًا 'كل مستخدم يشوف طلباته هو بس' أفضل بكثير من ذكر تقنية قاعدة بيانات معينة. وصف مفصل من البداية يكلفك كريدت واحد، ويوفر عليك عشر جولات تصحيح بعدين.

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

3. 3

   الخطوة 3: افتح المعاينة واستخدمه فعليًا قبل ما تعدّل أي شي

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

   ملاحظة: التطبيق اللي تحصله رابط شغال حقيقي، مو مجرد نموذج — شاركه مع أي شخص يجربه معك.

4. 4

   الخطوة 4: اجمع تعديلاتك برسالة واحدة مفصلة

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

   ملاحظة: المعاينة تتحدث مباشرة وأنت تتكلم، فتقدر تشوف أثر كل تعديل قبل ما ترسل الرسالة التالية.

5. 5

   الخطوة 5: صدّر إلى GitHub بدري، واعرف متى توقف

   أنت تملك الكود اللي يولّده Lovable — اربط GitHub وصدّر المشروع كامل كمشروع React وTypeScript عادي، مو صيغة مقفلة عند المنصة. صدّره بدري عشان تصير عندك نسخة مستقلة عن اشتراكك. ولو التطبيق يهمك فعليًا، اربط GitHub من الآن. ولو المنطق بدأ يتعقد وتحتاج تخصيص دقيق، صدّر المشروع وكمّل بمحرر كود حقيقي مثل Cursor — عادة بهذي المرحلة تحتاج تقرأ الكود المولّد نفسه عشان تصف الإصلاح بدقة. ولأي تطبيق فيه مدفوعات أو بيانات مستخدمين حساسة، خلّه يمر على مراجعة مطور قبل الإطلاق؛ Lovable يولّد كود معقول لكنه ما يفكر في نموذج المخاطر الخاص بك.

   ملاحظة: للأدوات الداخلية والنماذج الأولية وصفحات الهبوط والـMVP، ناس فعليًا يطلقون عليها مباشرة — المشكلة تبدأ بس لما ترفع مستوى الحساسية.

أخطاء شائعة — وكيف تتجنبها

❓ أسئلة شائعة

شروحات ذات صلة