يمكنك اليوم أن تبدأ مشروع ويب كاملًا بجملة واحدة، لكن جودة النتيجة تعتمد على وصف المنتج والسوق والصفحات والبيانات والرحلة، لا على طلب تصميم جميل فقط.
طلب مثل سو لي landing page حديثة وجميلة قد ينتج صفحة لطيفة، لكنه لا يصف منتجًا قابلًا للاستخدام. منصة حجوزات تحتاج تسجيل حساب، عيادات وأطباء ومواعيد، تأكيدًا وإلغاءً، رسائل نجاح وفشل، Dashboard وقاعدة بيانات وصلاحيات. ابدأ بما يجب أن يفعله المنتج: أبي منصة حجز عيادات في السعودية. المريض يبحث ويحجز، والعيادة تدير الأطباء والمواعيد من dashboard.
ابني لي موقع لحجوزات العيادات في السعودية، خله عربي وإنجليزي، وأبي تسجيل دخول ولوحة تحكم للأطباء.
اذكر السوق وطريقة الاستخدام. جمهور سعودي يستخدم الموقع من الجوال يحتاج تصميمًا mobile-first ولغة وأزرارًا وتواريخ وأرقامًا مناسبة. نظام داخلي لشركة لوجستية في الإمارات يحتاج نبرة وبنية مختلفة. أخبر الوكيل لمن يبني المنتج قبل كتابة الكود.
اكتب كما تتكلم: أبي dashboard للمبيعات فيها الإيرادات والطلبات، خل الـ sidebar collapsible، أو اربط signup بـ Supabase وخلي المستخدم يروح للـ dashboard. Dashboard وAPI وAuth وLogin وSignup وSidebar وModal وDeploy وBuild كلمات طبيعية داخل طلب عربي.
الطلب القوي يذكر نوع المنتج والجمهور والسوق واللغات واتجاه العربية والوظائف والتقنية. مثال: ابني لي SaaS لإدارة الفواتير للشركات الصغيرة في السعودية، عربي وإنجليزي، العربية RTL، مع عملاء وفواتير ومدفوعات، باستخدام Next.js وSupabase. من هنا يمكن تقسيم المشروع بدل إنشائه دفعة واحدة.
في مشروع حقيقي يفهم الوكيل الطلب، ويفحص المشروع، ويحدد الملفات، ويقترح خطة، ثم ينفذ ويشغل الأوامر ويعرض ما تغير. إضافة صفحة أسعار مثلًا قد تشمل route ومكونًا ونسختين لغويتين وRTL وmetadata وnavbar وفحص الهاتف.
لا تحاول بناء كل الاحتمالات في أول طلب. ابدأ بالـ core flow: Home وproducts وproduct details وcart وcheckout، ثم أضف الحسابات والمفضلة والتقييمات ولوحة الإدارة. اطلب: ابدأ بالـ core flow فقط ولا تضف admin الآن.
إذا كان المشروع ثنائي اللغة، قل ذلك قبل بناء النسخة الإنجليزية: المشروع عربي وإنجليزي، العربية RTL والإنجليزية LTR. هكذا تخطط للـ routing وlang وdir وملفات الترجمة وmetadata وlanguage switcher ومكونات تعمل في الاتجاهين.
/pricing
/en/pricingقل: خلي النسخة العربية RTL بالكامل، واستخدم logical CSS properties بدل left/right. أو: خلي الـ sidebar على اليمين بالعربي وعلى اليسار بالإنجليزي، وخلي code blocks والـ email inputs LTR حتى في النسخة العربية.
الموقع العربي قد يحتوي أسماء شركات وروابط وبريدًا وأسماء ملفات وAPI keys وأوامر Terminal. اطلب مراجعة كل places التي تجمع العربي والإنجليزي في السطر نفسه حتى لا ينكسر الاتجاه.
نموذج التسجيل الحقيقي يحتاج حقولًا وvalidation وloading وerror وsuccess وربط auth وredirect. اطلب name وemail وpassword ورسائل بالعربي والإنجليزي، ثم انتقال المستخدم إلى dashboard بعد النجاح.
لا تقل أضف database فقط. صف العلاقات: users وclinics وdoctors وappointments، وكل موعد مرتبط بمستخدم وطبيب وعيادة. ثم اطلب ميزة مثل عرض مواعيد اليوم للعيادة من dashboard.
قد تضم منصة العيادات مريضًا وطبيبًا ومدير عيادة وAdmin. اذكر أن لكل نوع dashboard وصلاحيات وprotected routes مختلفة حتى لا تضطر إلى إعادة بناء بنية الدخول لاحقًا.
المنتج الفعلي يحتاج Skeleton أو Spinner وحالة تحميل، ورسالة خطأ مفيدة مثل تعذر تحميل المواعيد. حاول مرة أخرى، لا Something went wrong فقط. اطلب loading وempty وerror states لكل جدول وتدفق مهم.
عندما يدخل المستخدم Dashboard جديدة ولا توجد بيانات، اعرض شرحًا وزرًا مثل لا توجد فواتير بعد — أنشئ أول فاتورة، بدل جدول فارغ لا يشرح الخطوة التالية.
قل mobile-first واختبر شاشة 375px. اطلب تحويل الـ sidebar إلى drawer على الهاتف، وتحويل جدول الطلبات إلى cards عند الشاشات الصغيرة. لا تؤجل الهاتف إلى نهاية المشروع.
استخدم عبارات واقعية مثل احجز موعدك مع الطبيب المناسب في دقائق، ولديك 8 مواعيد اليوم، وأسماء عربية ومدنًا وأسعارًا مناسبة للسوق. المحتوى الحقيقي يكشف مشاكل التصميم مبكرًا.
العربية ليست تجربة واحدة في كل سوق. قل إن الجمهور سعودي وتريد لغة بسيطة ومهنية، أو إن المنتج B2B في الإمارات وتريد نبرة رسمية أكثر. السوق يؤثر في الكلمات والعملة والأرقام والنبرة.
في منتج للمطورين قد تفضل إبقاء API وGitHub وDeploy وBuild وRepository. أما المنتج غير التقني فقد يحتاج تعريبًا أوسع. القرار مرتبط بالجمهور وليس بقاعدة واحدة.
بعد النسخة الأولى، حدد نطاق التغيير: كبر المسافة بين الـhero والـfeatures، أو حسّن mobile navbar فقط، أو أبرز CTA. التحديد يقلل احتمال تغيير أجزاء لم تطلبها.
يمكنك فتح مشروع قائم وطلب مراجعة RTL في settings أو إضافة نسخة عربية إلى Next.js موجود أو فحص auth قبل التعديل. في المشروع القائم يصبح فهم الملفات والعلاقات جزءًا أساسيًا من العمل.
قبل تغيير كبير، اطلب plan بالملفات التي ستتغير. قد تشمل app/(ar)/pricing/page.tsx وapp/(en)/en/pricing/page.tsx وPricingCard وملفات الرسائل وNavbar. هذا يجعل النطاق واضحًا للمراجعة.
افحص الملفات المتغيرة والـdependencies والـUI والأخطاء والنسختين والـdiff. الذكاء الاصطناعي يسرع العمل، لكنه لا يلغي قرار المنتج والمراجعة البشرية.
بعد إنشاء الكود شغل build وlint وtests وtype checking بحسب المشروع، واطلب إصلاح أي error سببه التغيير. هذا يجعل المهمة أقرب إلى طريقة عمل مطور فعلي.
أرسل TypeError أو وصف mobile menu لا تغلق بعد الضغط على رابط عربي، واطلب تحديد السبب وإصلاحه دون تغيير بقية الـflow. رؤية المشروع والسياق أهم من نسخ الخطأ في محادثة عامة.
ابدأ بطلبات قريبة من العمل اليومي:
صف المنتج والمستخدم واللغات والأدوار والتقنية، ثم قسم العمل: ابدأ بالـauth وقاعدة البيانات، ثم flow الحجز، ثم dashboard العيادة، ثم راجع mobile والعربي والإنجليزي. هذا يحول الفكرة إلى مهام واضحة قابلة للمراجعة.
قل: أريد العربية على المسار الأساسي / والإنجليزية على /en، العربية RTL، استخدم نفس components، لا تترجم API وGitHub، واجعل language switcher يحافظ على الصفحة، وابدأ بخطة. هذه مهمة routing وترجمات واتجاه وmetadata وSEO، وليست ترجمة نصوص فقط.
أنت تحدد المنتج والجمهور وأهم ميزة وما يبنى الآن وما يؤجل وتجربة المستخدم. استخدم Nuwat كشريك تنفيذ يحول القرارات إلى تغييرات حقيقية بدل زر يقول Build my app.
قسم العمل إلى مراحل: راجع البنية، نفذ routing والترجمات، حول layout إلى RTL، راجع forms والمحتوى المختلط، ثم اختبر mobile وbuild. التقسيم يجعل الأخطاء أسهل في الاكتشاف والمراجعة.
راجع الصفحات الأساسية وتسجيل الدخول والبيانات والحالات الفارغة ورسائل الخطأ وRTL والنصوص والمصطلحات واتجاه البريد والكود والنسخة الإنجليزية والـlanguage switcher والهاتف والـforms والـmetadata وconsole والرحلة الكاملة.
القيمة ليست أن الذكاء الاصطناعي ينشئ HTML أسرع، بل أن تشرح ما تريد بالطريقة التي تفكر بها ثم تحوله إلى خطة وصفحات ومكونات وقاعدة بيانات وAuth وRTL وResponsive UI وتغييرات قابلة للمراجعة، دون ترجمة الفكرة إلى الإنجليزية في كل مرة.
لا تحتاج إلى Prompt مثالي. ابدأ كما تتحدث: عندي فكرة SaaS للمطاعم في السعودية، أبي المطعم يدير المنيو والطلبات من dashboard، خله عربي وإنجليزي والعربي RTL، استخدم Next.js وSupabase، وابدأ بخطة وقل لي ما الذي يحتاج إلى تغيير.
تعرّف على طريقة عمل نواة↗