قد تحصل على صفحة تبدو جيدة في لقطة شاشة، لكنها تنهار عند عرضها على الهاتف، أو تجد أن زرًا بسيطًا لا يعمل، أو تقضي وقتًا طويلًا في البحث عن سبب ظهور فراغ غريب في CSS.
في هذه الحالات لا تكمن المشكلة دائمًا في نقص المعرفة البرمجية، بل في طريقة وصف المشكلة لأداة الذكاء الاصطناعي. فالطلب المختصر مثل «أنشئ لي موقعًا جميلًا» يترك تفاصيل كثيرة للتخمين، بينما ينتج البرومبت المنظم إجابة يمكن فحصها وتعديلها وتشغيلها.
في هذا الدليل ستجد مجموعة برومبتات أصلية لتطوير صفحات الويب باستخدام HTML وCSS وJavaScript. لكنها ليست قائمة جاهزة للنسخ فقط؛ فكل برومبت مرتبط بمشكلة عملية، مع طريقة استخدامه وتعديله ومراجعة النتيجة. الفكرة الأساسية هي أن تجعل الذكاء الاصطناعي مساعدًا في التفكير والتنفيذ، لا بديلًا عن اختبار الكود وفهمه.
كيف تكتب برومبتًا مفيدًا لتطوير الويب؟
قبل إرسال أي طلب، اذكر السياق الذي يحتاج إليه المساعد. حدّد نوع الصفحة، والجمهور، والتقنيات المسموح بها، وأسلوب التصميم، والمخرجات التي تريدها. ومن المفيد أيضًا أن تضع قيودًا واضحة، مثل عدم استخدام مكتبات خارجية، أو فصل HTML عن CSS وJavaScript، أو شرح سبب كل تعديل.
إذا كنت تصلح مشكلة، فلا تكتفِ بوصف النتيجة المزعجة. أرفق الكود المعني، واذكر ما توقعت حدوثه وما يحدث فعليًا، وحدد المتصفح أو حجم الشاشة إذا كانت المشكلة مرتبطة بالعرض. كلما قلّ التخمين المطلوب من الأداة، زادت قابلية الإجابة للتحقق.
| العنصر | مثال عملي |
|---|---|
| الهدف | إنشاء صفحة هبوط لخدمة حجز مواعيد |
| التقنيات | HTML دلالي وCSS أصلي وJavaScript دون مكتبات |
| القيود | تصميم متجاوب، ملفات منفصلة، وعدم استخدام صور خارجية |
| المخرجات | الكود، شرح البنية، وخطوات الاختبار |
إنشاء صفحة ويب كاملة من مواصفات واضحة
استخدم هذا البرومبت عندما تملك فكرة الصفحة ومكوناتها، لكنك لا تريد البدء من ملف فارغ. يناسب صفحات الهبوط، وصفحات الخدمات، والنماذج التعريفية الصغيرة التي لا تحتاج إلى إطار عمل.
أريد إنشاء صفحة ويب لخدمة [اسم الخدمة] تستهدف [نوع المستخدم].
استخدم HTML دلاليًا وCSS أصليًا وJavaScript عاديًا دون مكتبات خارجية.
يجب أن تتضمن الصفحة: [اذكر الأقسام بالترتيب].
الهوية البصرية: ألوان [الألوان]، أسلوب [هادئ/احترافي/جريء]، وخط واضح.
اجعل التصميم متجاوبًا بدءًا من الهاتف، مع حالات واضحة للأزرار وحقول النماذج.
قسّم الإجابة إلى ثلاثة ملفات: index.html وstyle.css وscript.js.
بعد الكود، اشرح بنية الصفحة، واذكر افتراضاتك، ثم أضف قائمة اختبار يدوية للهاتف وسطح المكتب.كيف يعمل وكيف تعدله؟
يمنع البرومبت الأداة من اختراع هدف الصفحة أو اختيار بنية عشوائية، لأنه يحدد الجمهور والمكونات والتقنيات والمخرجات. استبدل العناصر بين الأقواس بمعلوماتك، وأضف قيودًا مثل «استخدم وحدات rem» أو «اجعل النصوص قابلة للتعديل من متغيرات CSS». إذا كان لديك محتوى حقيقي، ضعه داخل الطلب بدل استخدام نصوص وهمية؛ فالنص يؤثر في طول البطاقات وتوزيع المساحات.
مثال وفائدة متوقعة
يمكنك كتابة: «أريد صفحة هبوط لمنصة تعليم لغة عربية، تتضمن شريطًا علويًا، قسمًا تعريفيًا، ثلاث مزايا، شهادات مستخدمين، ونموذج اشتراك». ستنتقل من فكرة عامة إلى هيكل قابل للتشغيل، ثم تستطيع مراجعة كل ملف على حدة. لا تعتمد على النتيجة قبل فتحها في المتصفح وفحص الروابط والنموذج وأحجام الشاشة.
نصيحة: اطلب من الأداة أن تضع التعليقات فقط في الأجزاء المهمة. كثرة التعليقات داخل كل سطر قد تجعل الكود أطول دون أن تجعله أوضح.
يجب أن تُظهر الصورة البرومبت كاملًا مع بداية المخرجات التي توضح تقسيم الكود إلى ملفات، ويفضل إخفاء أي بيانات شخصية أو مفاتيح وصول قبل النشر.
تحويل التصميم إلى واجهة Responsive
كثير من الصفحات تبدو مقبولة على شاشة المطور، لكنها تحتاج إلى تمرير أفقي أو تتداخل عناصرها على الهاتف. يساعد هذا البرومبت على تحليل توزيع العناصر وبناء نقاط توقف منطقية بدل إضافة media query عشوائية لكل عرض.
حلّل كود HTML وCSS الآتي، ثم حوّله إلى تصميم متجاوب يبدأ من الهاتف.
المشكلة الحالية هي: [صف السلوك الخاطئ على الهاتف أو الجهاز اللوحي].
لا تغيّر النصوص أو ترتيب الأقسام إلا إذا كان ذلك ضروريًا.
استخدم CSS Grid أو Flexbox حيث يكون مناسبًا، وتجنب تثبيت العرض بالبكسل للعناصر الرئيسية.
اقترح نقاط توقف قليلة ومبررة، واذكر عند كل نقطة ما الذي يتغير.
أعد الكود المعدل كاملًا، ثم اشرح سبب كل تعديل، وأضف خطوات اختبار عند عروض 320 و768 و1440 بكسل.
هذا هو الكود:
[الصق HTML وCSS هنا]طريقة التعديل والاختبار
بدّل وصف المشكلة بمعلومة قابلة للملاحظة، مثل «يتجاوز شريط البطاقات عرض الشاشة عند 375 بكسل». بعد الحصول على التعديل، افحصه في أدوات المطور واستخدم شريط تغيير العرض، ولا تكتفِ بتصغير نافذة المتصفح. راقب الصور، والجداول، والنصوص الطويلة، وحالات التركيز بلوحة المفاتيح.
نصيحة: إذا طلبت «اجعله متجاوبًا» فقط، فقد تحصل على تغييرات واسعة يصعب مراجعتها. اطلب أولًا تحليل سبب المشكلة، ثم اطلب نسخة معدلة؛ هذا يفصل التشخيص عن التنفيذ.
يجب أن تظهر نافذة المعاينة أو أدوات المطور وهي تعرض الصفحة على الهاتف والجهاز اللوحي وسطح المكتب، مع إبراز اختفاء التمرير الأفقي وتحسن ترتيب العناصر.
تشخيص مشاكل CSS بدل تخمين الحل
يناسب حالات مثل عنصر لا يتمركز، أو لون لا يظهر، أو قاعدة CSS لا تطبق، أو تداخل ناتج عن specificity ووراثة الخصائص. الهدف هنا ليس الحصول على «حل سريع» فقط، بل معرفة السلسلة التي أدت إلى المشكلة.
تصرف كمراجع CSS دقيق. أريد تشخيص المشكلة التالية دون إعادة كتابة المشروع كاملًا:
السلوك المتوقع: [ما الذي يجب أن يحدث].
السلوك الفعلي: [ما الذي يحدث].
المتصفح وعرض الشاشة: [المعلومات إن كانت مهمة].
حلّل HTML وCSS المرفقين، وحدد القاعدة أو القواعد التي تمنع النتيجة المطلوبة.
افحص ترتيب القواعد، specificity، inheritance، display، position، overflow، وأبعاد الصندوق.
قدّم أقل تعديل آمن أولًا، ثم اشرح لماذا يعمل. إذا كانت هناك حلول بديلة، قارن بينها.
أضف طريقة تحقق باستخدام DevTools، ولا تقترح !important إلا مع تبرير واضح.
الكود:
[الصق الجزء المتعلق بالمشكلة]لماذا يعطي نتائج أفضل؟
يطلب البرومبت من الأداة البحث في أسباب شائعة بدل إنتاج CSS جديد قد يخفي المشكلة. ويمكنك تقليل نطاق التحليل بإرسال المكوّن المتأثر فقط، ثم إرسال الملف الكامل إذا لم يظهر السبب. عند مراجعة الإجابة، ابحث عن تعديل صغير يمكن عزله واختباره قبل دمجه.
مثال عملي: إذا كان زر داخل بطاقة لا يظهر في المنتصف، أرسل بنية البطاقة وقواعد الحاوية والزر، واذكر أن المحاذاة المطلوبة أفقية وعمودية. قد يتبين أن الحاوية لا تستخدم Flexbox، أو أن ارتفاعها غير محدد، أو أن margin موروثًا يغير النتيجة.
نصيحة: لا تقبل حذف قاعدة CSS لمجرد أنها تبدو غير مهمة. اسأل عن العناصر الأخرى التي قد تتأثر بها، خصوصًا إذا كان المحدد عامًا مثل .container أو button.
بناء تفاعل JavaScript مفهوم وقابل للصيانة
يمكن للذكاء الاصطناعي كتابة قائمة منسدلة أو تحقق من نموذج خلال ثوانٍ، لكن الكود قد يعتمد على محددات هشة أو يتجاهل حالة الخطأ وإمكانية الوصول. يساعد هذا البرومبت على وصف الحالات المطلوبة قبل كتابة الأحداث.
أضف تفاعل JavaScript إلى هذا المكوّن: [اسم المكوّن].
الحالات المطلوبة هي:
1. الحالة الابتدائية: [الوصف].
2. عند تفاعل المستخدم: [النقر/الكتابة/الإرسال].
3. عند الخطأ: [رسالة الخطأ ومكانها].
4. عند النجاح: [النتيجة].
استخدم JavaScript عاديًا، وحدد العناصر بطريقة مستقرة، وتجنب تكرار مستمعي الأحداث.
حافظ على قابلية الاستخدام بلوحة المفاتيح، وأضف ARIA فقط عندما تكون مناسبة.
اكتب HTML الضروري وJavaScript في ملفين منفصلين، ثم اشرح تدفق الحالة واختبارات النجاح والفشل.
لا تدّعِ أن البيانات أُرسلت إلى خادم حقيقي؛ استخدم محاكاة واضحة إن لم يوجد API.
الكود الحالي:
[الصق HTML وJavaScript]استبدل الحالات العامة بتفاصيل دقيقة. في نموذج تسجيل مثلًا، حدد الحقول المطلوبة، وشكل البريد المقبول، ومكان ظهور الرسائل، وما يحدث بعد النجاح. وإذا لم يكن هناك خادم، اطلب محاكاة محلية بدل ترك الكود يوحي بأن التسجيل اكتمل فعلًا.
بعد ذلك اختبر النقر والضغط على Enter والتنقل بمفتاح Tab وإعادة المحاولة بعد ظهور خطأ. اطلب من الأداة شرح كل دالة، لكن لا تضع الشرح داخل الكود إلا في المواضع التي تحتاج إلى توضيح.
يجب أن تُظهر الصورة رسالة تحقق واضحة عند إدخال غير صالح، ثم حالة النجاح بعد إدخال صحيح، مع إظهار أدوات المطور إذا كانت هناك رسالة مهمة في وحدة التحكم.
تحسين تجربة المستخدم وإمكانية الوصول
استخدمه بعد وجود نسخة أولية تعمل. فالأداة تكون أكثر فائدة عندما تراجع واجهة فعلية، لا عندما تطلب منها تحسين فكرة مجردة. ركز على وضوح المهمة، وسهولة القراءة، والتعامل مع الحالات المختلفة.
راجع هذه الصفحة من منظور مستخدم جديد ومن منظور مستخدم يعتمد على لوحة المفاتيح.
الهدف الأساسي للصفحة هو: [الهدف].
الجمهور: [الجمهور].
لا تغيّر الهوية البصرية جذريًا ولا تضف مكتبات.
حدّد أولًا أكبر خمس مشكلات تؤثر في الفهم أو إتمام المهمة، ورتبها حسب الأولوية.
افحص العناوين الدلالية، تسميات الحقول، حالات التركيز، وضوح الأزرار، طول النصوص، التباين، رسائل الخطأ، وسلوك الهاتف.
لكل مشكلة، اقترح تعديلًا قابلًا للتنفيذ، ثم أعطني الكود الخاص بالأجزاء التي تحتاج إلى تغيير فقط.
افصل بين التحسين الضروري والتحسين الاختياري، واذكر ما يجب اختباره يدويًا.
الكود أو الرابط المحلي:
[أرفق الكود أو الصق المكوّن]الفائدة وحدود النتيجة
يساعدك هذا الطلب على تحويل عبارة فضفاضة مثل «اجعل التصميم أفضل» إلى قائمة أولويات. لكنه لا يغني عن اختبار الصفحة مع مستخدمين حقيقيين أو استخدام أدوات فحص متخصصة. اعتبر اقتراحاته فرضيات تحتاج إلى مراجعة، ولا تضف سمات ARIA لمجرد تحسين نتيجة شكلية إذا كان HTML الدلالي يحل المشكلة أصلًا.
نصيحة: اطلب من الأداة تقليل عدد التغييرات في كل جولة. التعديل التدريجي يجعل من السهل معرفة أي تغيير حسّن التجربة وأي تغيير أضر بها.
مراجعة الكود وتحسينه دون كسر الوظائف
راجع هذا المشروع كأنه سيُسلّم لمطور آخر.
لا تعِد كتابة كل شيء، ولا تغيّر السلوك المرئي دون موافقة.
ابحث عن: التكرار، أسماء غير واضحة، محددات CSS واسعة، JavaScript غير ضروري، أخطاء بنيوية، ومشكلات قد تظهر عند اختلاف المحتوى.
قسّم الملاحظات إلى أخطاء مؤكدة، مخاطر محتملة، وتحسينات اختيارية.
لكل تعديل، اشرح أثره ومخاطره، ثم قدّم patch أو مقطعًا صغيرًا بدل ملف ضخم.
ضع قائمة اختبارات للتأكد من أن التنقل، النموذج، الاستجابة، وحالات الخطأ ما زالت تعمل.
الكود:
[الصق الملفات أو الأجزاء المهمة]هذا البرومبت مناسب قبل نشر صفحة أو تسليمها، لأنه يطلب التمييز بين الخطأ المؤكد والاقتراح الشخصي. وإذا كان المشروع كبيرًا، أرسل الملفات على مراحل واطلب من الأداة الاحتفاظ بقائمة افتراضات؛ لا تتوقع أن تفهم كل المشروع من مقطع مبتور.
كيف تتأكد من أن الكود الناتج صالح؟
ابدأ بتشغيل الكود في بيئة معزولة، ثم اختبر المسار الرئيسي للمستخدم. افحص وحدة التحكم بحثًا عن أخطاء JavaScript، وجرّب أحجامًا مختلفة، وغيّر النصوص إلى عبارات أطول، واختبر الحقول الفارغة. بعد كل تعديل، احتفظ بنسخة تعمل حتى تستطيع الرجوع إليها.
يمكن الاستفادة من التوثيق الرسمي لـ HTML في MDN وCSS في MDN وJavaScript في MDN للتحقق من معنى الخصائص وواجهات البرمجة. كما يوفر W3C Markup Validation Service وسيلة لفحص بنية HTML، بينما يقدم web.dev مواد عملية حول إمكانية الوصول. استخدم هذه المصادر للتحقق من الإجابة، لا لإضافة مراجع شكلية إلى المقال.
تذكر أن الذكاء الاصطناعي قد يقترح دالة غير موجودة في بيئتك، أو يخلط بين كود تجريبي وتكامل حقيقي، أو يضع قيمة مناسبة بصريًا لكنها غير مناسبة لمحتواك. لذلك اطلب منه ذكر افتراضاته، واقرأ الكود قبل استخدامه، واختبر كل وظيفة مرتبطة ببيانات أو حسابات أو صلاحيات.
أخطاء شائعة عند استخدام برومبتات تطوير الويب
- إرسال طلب عام جدًا مثل «صمم موقعًا احترافيًا» دون تحديد الهدف والجمهور والمكونات.
- طلب ملف كامل عند وجود مشكلة في سطرين، مما يزيد احتمال إدخال تغييرات غير ضرورية.
- نسخ الكود دون تشغيله أو اختبار الهاتف ولوحة المفاتيح وحالات الخطأ.
- طلب أكثر من مهمة كبيرة في رسالة واحدة، مثل إنشاء التصميم وإضافة قاعدة بيانات وتحسين الأداء دون فصل المراحل.
- الاعتماد على أسماء مكتبات أو خصائص حديثة دون الرجوع إلى توثيقها الرسمي أو معرفة بيئة التشغيل.
- اعتبار الإجابة صحيحة لأنها طويلة أو تبدو منظمة؛ المعيار الحقيقي هو السلوك عند الاختبار.
خطة عملية لاستخدام هذه البرومبتات
ابدأ بالبرومبت الأول لبناء الهيكل، ثم استخدم البرومبت الثاني لفحص الاستجابة. إذا ظهرت مشكلة، انتقل إلى برومبت CSS التشخيصي بدل طلب إعادة التصميم. بعد ذلك أضف التفاعل المطلوب بحالاته، ثم راجع تجربة المستخدم، وأخيرًا نفّذ مراجعة الكود. هذا التسلسل يقلل الخلط بين مشكلة في البنية ومشكلة في التصميم أو JavaScript.
يمكنك أيضًا إنشاء «سجل قرارات» صغير داخل المشروع: ما التقنيات المستخدمة، وما نقاط التوقف، وما السلوك المتوقع لكل مكوّن. عند كل محادثة جديدة، أرسل هذا السياق المختصر. ستصبح الإجابات أكثر اتساقًا، وستتمكن من رفض أي اقتراح يخالف قرارات المشروع.
الخاتمة
أفضل برومبتات الذكاء الاصطناعي لتطوير مواقع الويب ليست الأطول، بل الأكثر تحديدًا وقابلية للاختبار. ابدأ بوصف الهدف والسياق، اطلب مخرجات منظمة، وافصل التشخيص عن التنفيذ. استخدم البرومبتات لإنشاء الصفحة وتحسين استجابتها وتشخيص CSS وبناء تفاعل JavaScript ومراجعة تجربة المستخدم، ثم تحقق من كل نتيجة داخل المتصفح وبالرجوع إلى التوثيق الرسمي.
عندما تتعامل مع الكود الناتج كنقطة بداية قابلة للمراجعة، ستوفر وقتًا حقيقيًا دون أن تفقد السيطرة على مشروعك. أما نسخ الإجابة كاملة دون فهم أو اختبار، فقد يحول المساعدة السريعة إلى أخطاء يصعب اكتشافها لاحقًا.
