برومبتات البرمجة تساعدك على وصف مشكلة الكود بوضوح، وفهم ما ينفذه، ومراجعة إصلاح مقترح قبل دمجه. عبارة «أصلح المشروع» تترك تفاصيل كثيرة مفتوحة؛ أما تقديم اللغة والإصدار ورسالة الخطأ والسلوك المتوقع فيمنح المساعد مادة يمكن فحصها بدل بناء حل على افتراضات.
جمعنا هنا 15 قالبًا عربيًا قابلًا للنسخ لفهم الكود وإصلاح الأخطاء وكتابة اختبارات ذات معنى. تصلح للتخصيص في مساعد محادثة أو مساعد داخل المحرر عندما تتوفر له الملفات المطلوبة. القوالب لا تثبت أن التعديل آمن أو أن الاختبارات نُفذت؛ راجع الفرق وشغّل الفحوص المناسبة في بيئتك.
ما المعلومات التي يحتاجها المساعد قبل كتابة الحل؟
ابدأ بمهمة واحدة وحدود واضحة. حدّد هل تريد تفسيرًا فقط، أم خطة تعديل، أم تغيير ملف معين. إذا كنت تستخدم محادثة عامة، أرفق المقطع الذي يحتاج إلى القراءة؛ ذكر اسم الملف لا يتيح الوصول إليه. وفي مساعد متصل بالمشروع، تأكد من الملفات التي دخلت في السياق بدل افتراض أنه فحص المستودع كاملًا.
| المعلومة | ما الذي تقدمه؟ | مثال تعليمي |
|---|---|---|
| البيئة | اللغة والإطار والإصدارات ذات الصلة | JavaScript في متصفح حديث، دون مكتبات إضافية. |
| السلوك المتوقع | ما المدخل؟ وما الناتج الصحيح؟ | عدّ المهام التي تحمل القيمة المنطقية true فقط. |
| السلوك الفعلي | النتيجة التي رأيتها أو رسالة الخطأ | تُحتسب قيمة نصية مثل “true” كمهمة مكتملة. |
| المادة اللازمة | الدالة وعينة صغيرة وطريقة استدعائها | قائمة مجهلة من أربعة عناصر بدل ملف عملاء كامل. |
| حدود التعديل | ما الملفات والسلوكيات التي يجوز تغييرها؟ | عدّل شرط العد فقط واحتفظ باسم الدالة. |
| التحقق | حالة تكشف المشكلة وحالات تحفظ السلوك | قيم true وfalse و”true” و1 في عينة واحدة. |
احذف مفاتيح الوصول وكلمات المرور والبيانات الشخصية من الأمثلة. لا تحتاج إلى إرسال ملف إعدادات كامل لتفسير شرط داخل دالة. وإذا طلب المساعد معلومة إضافية، قدّم الجزء الذي يوضح المشكلة مع إبقاء الأسماء والعينات قابلة للفهم.
فهم المشروع والكود قبل تعديله
1. قراءة بنية مشروع صغير
متى تستخدمه؟ عند فتح مشروع لا تعرف نقطة تشغيله أو توزيع ملفاته.
هذه شجرة ملفات المشروع [الشجرة]، وهذه ملفات الإعداد والتشغيل المتاحة [المقتطفات]. اشرح نقطة البداية، ومسار وصول الطلب أو الحدث إلى الجزء الرئيس، ووظيفة المجلدات الظاهرة. اربط كل استنتاج بملف قرأته، وميّز ما يحتاج فتح ملف آخر. لا تنشئ ملفات أو تثبت حزمًا أو تغيّر الإعدادات. اختم بثلاثة ملفات تقترح قراءتها لفهم المهمة [المهمة المحددة]، مع سبب اختيار كل ملف.
راجع النتيجة: لا تعتبر تخمين وظيفة مجلد من اسمه قراءةً للكود. افتح ملفات التشغيل التي استند إليها الشرح.
2. شرح دالة مع أمثلة مدخلات ومخرجات
متى تستخدمه؟ إذا احتجت إلى فهم المنطق قبل قبول تعديل.
اشرح الدالة التالية بلغة مناسبة لمطور [المستوى]: [الكود]. حدد المدخلات والناتج والآثار الجانبية إن وجدت، ثم تتبع مثالًا عاديًا وحالة حدية من البيانات التي أقدمها [العينات]. وضح الشروط والتحويلات المؤثرة في النتيجة، ولا تنسب للدالة معالجة أخطاء لا تظهر في الكود. لا تعِد كتابتها الآن. اختم بسؤالين أستطيع الإجابة عنهما بنفسي لأتأكد أنني فهمت سلوكها.
راجع النتيجة: طابق كل خطوة مع سطر فعلي؛ الشرح الذي يصف النية قد يختلف عما ينفذه الشرط.
3. تحويل متطلب غامض إلى عقد سلوك
متى تستخدمه؟ قبل طلب دالة جديدة أو إصلاح قد يغيّر معنى المدخلات.
المتطلب هو [الوصف]، والبيئة [اللغة والإصدار]، وهذه أمثلة المدخلات المتاحة [الأمثلة]. حوّله إلى عقد سلوك: المدخلات المقبولة، والناتج، والتعامل مع القيم الناقصة، والحالات التي تحتاج خطأ واضحًا. اسأل عن القرارات التي تغيّر النتيجة مثل قبول النص بدل الرقم. لا تحسمها نيابة عني ولا تكتب التنفيذ بعد. اقترح حالات قبول قصيرة أراجعها قبل البدء، وبيّن أي تعارض بينها.
راجع النتيجة: احسم معنى «فارغ» أو «صحيح» أو «مكتمل» صراحة؛ الكلمات العامة قد تخفي أكثر من سلوك ممكن.
تشخيص الأخطاء وإصلاحها في نطاق محدود
4. قراءة رسالة خطأ مع السياق
متى تستخدمه؟ عندما تظهر رسالة طويلة ولا تعرف أين تبدأ البحث.
هذه رسالة الخطأ الكاملة بعد إزالة الأسرار [الرسالة]، وهذا المقطع المرتبط بها [الكود]، وهذه طريقة إعادة المشكلة [الخطوات] في بيئة [الإصدارات]. اشرح موضع الفشل الأول المرجح، ثم افصل الملاحظات المؤكدة عن فرضيات السبب. اقترح أقل معلومة أو فحص محلي يميز بين الفرضيات. لا تقفز إلى تحديث جميع الحزم أو إعادة كتابة المشروع، ولا تدّع إعادة إنتاج الخطأ إذا لم تتوفر لك بيئة تشغيل.
راجع النتيجة: ابدأ من موضع الفشل في المسار الذي نفذته فعلًا، لا من آخر سطر في سجل طويل فقط.
5. إنشاء مثال صغير يعيد إنتاج المشكلة
متى تستخدمه؟ إذا اختلط الخطأ بملفات أو خطوات كثيرة.
المشكلة تظهر عند [الوصف والخطوات]، والكود المرتبط [المقتطفات]، والنتيجة المتوقعة [النتيجة]. اقترح مثالًا مصغرًا يحتفظ بالشرط الذي يسبب الخطأ ويزيل الواجهة والاتصالات غير الضرورية. استخدم بيانات مصطنعة واضحة، وحدد ما الذي استُبدل بمحاكاة ولم يعد مختبرًا. لا تغيّر منطق الحالة أثناء تصغيرها. أعطني أمر تشغيل مناسبًا للبيئة الموضحة، وميّز المثال المقترح عن مثال شغّلته وتحققت منه.
راجع النتيجة: يجب أن يبقى الخطأ نفسه قابلًا للظهور؛ مثال لا يحتوي على السبب الأصلي لن يثبت إصلاحه.
6. اقتراح إصلاح بأقل تغيير
متى تستخدمه؟ بعد تحديد السبب وحسم السلوك المطلوب.
أصلح المشكلة التالية [الوصف] في هذا المقطع [الكود] وفق عقد السلوك [الشروط]. اقترح أقل تغيير يعالج السبب، واحتفظ بالأسماء والواجهات العامة والسلوك غير المرتبط بالمشكلة. اعرض الفرق بين القديم والجديد ثم اشرح سبب التعديل وأثره المتوقع. لا تضف اعتمادًا جديدًا أو تغير إعدادات عامة. اذكر الحالات التي ينبغي التحقق منها، ولا تصف الإصلاح بأنه ناجح قبل وجود نتيجة تشغيل موثقة.
راجع النتيجة: راجع الفرق نفسه؛ لا يكفي أن يكون الشرح محدودًا إذا كان التعديل يغيّر وظائف أخرى.
7. تمييز مشكلة البيانات عن مشكلة الكود
متى تستخدمه؟ إذا كانت الدالة تعمل على عينة وتفشل على أخرى.
هذه الدالة [الكود]، وهذه عينة تعمل [العينة] وأخرى تفشل [العينة المجهلة]، والسلوك المطلوب [العقد]. قارن أنواع القيم والحقول الناقصة والترميز والشكل قبل اقتراح تعديل. حدد أين ينبغي التحقق من المدخلات وفق البنية المتاحة، وميّز البيانات المرفوضة عن البيانات المسموح بتطبيعها. لا تحوّل أي نص إلى رقم أو قيمة منطقية تلقائيًا دون قاعدة معتمدة. اقترح رسالة خطأ تساعد على معرفة الحقل المتأثر.
راجع النتيجة: قد يكون الحل رفض قيمة غير صالحة عند الحدود، لا جعل كل قيمة تبدو مقبولة داخل الدالة.
8. فحص اختلاف الإصدارات والواجهات
متى تستخدمه؟ عندما يقترح المساعد دالة غير موجودة في مشروعك.
أستخدم [المكتبة] بالإصدار [الرقم]، وهذه طريقة الاستخدام الحالية ورسالة الخطأ [المادة]. راجع توافق الاقتراح التالي [الاقتراح] مع الإصدار المذكور. اعتمد على مقتطف الوثائق الذي أرفقه [النص والرابط]، أو صرّح بالحاجة إلى تحقق من الوثائق الرسمية. لا تفترض أن مثال أحدث إصدار يعمل هنا. افصل إصلاح الاستخدام الحالي عن خيار الترقية، واذكر ما الذي قد يتغير إن اخترت الترقية لاحقًا.
راجع النتيجة: قارن مع الإصدار المثبت في ملف القفل أو معلومات البيئة، لا مع رقم عشوائي في مقال قديم.
اختبارات تكشف الخطأ وتحفظ السلوك
9. اقتراح حالات اختبار قبل التنفيذ
متى تستخدمه؟ عندما تريد التأكد أن المتطلب قابل للفحص.
هذا عقد الدالة [العقد] وأمثلة استخدامها [الأمثلة] في بيئة [اللغة وأداة الاختبار المتاحة]. اقترح حالات تختبر النتائج المهمة: حالة عادية، وحدًا أدنى وأقصى إن وجدا، ومدخلًا ناقصًا، وحالة تميّز بين تفسيرين محتملين للمتطلب. لكل حالة أعطني المدخل والناتج المتوقع وسبب توقعه من العقد. لا تكتب عشر حالات متطابقة في المعنى، ولا تستنتج الإجابة المتوقعة من التنفيذ الحالي إذا كان هو موضع الشك.
راجع النتيجة: احذف الاختبار الذي يكرر الكود ولا يختبر قرارًا سلوكيًا. راجع التوقعات قبل تشغيلها.
10. كتابة اختبار انحدار لإصلاح محدد
متى تستخدمه؟ إذا أردت حماية سلوك أصابه خطأ معروف.
هذا وصف الخطأ [الوصف]، وهذا الكود قبل الإصلاح وبعده [المقطَعان]، وإطار الاختبار الحالي [الإطار وأمثلة المشروع]. اكتب اختبار انحدار صغيرًا يفشل بسبب المشكلة الأصلية ويمر عند إصلاحها وفق العقد [الشروط]. استخدم إعداد المشروع القائم، وميّز اختبار السلوك العام عن تفاصيل التنفيذ الداخلية. اشرح لماذا يكشف الاختبار المشكلة، ثم اذكر إن كنت قد شغلته فعلًا أو أنه اختبار مقترح فقط.
راجع النتيجة: اختبر أن النسخة القديمة تفشل للسبب الصحيح عندما يكون ذلك عمليًا؛ نجاح النسختين لا يحمي الإصلاح المقصود.
11. تفسير فشل اختبار دون تغيير توقعه عشوائيًا
متى تستخدمه؟ عندما يقترح المساعد تعديل الاختبار حتى يمر.
هذا الاختبار [الكود]، وهذه رسالة الفشل [النتيجة]، وهذا عقد السلوك [الشروط] والتنفيذ [الكود]. حدد هل الخلاف بين المتطلب والاختبار أم بين المتطلب والتنفيذ، مع الاستناد إلى المدخل والناتج الفعلي. لا تغيّر التوقع لمجرد أن البرنامج أعطى قيمة أخرى. اقترح تعديلًا واحدًا بعد بيان سبب الاختيار، واذكر ما إذا كان الفشل متعلقًا بالإعداد أو البيانات أو المنطق.
راجع النتيجة: راجع العقد أولًا؛ الاختبار قد يكون خاطئًا، لكن نتيجة التنفيذ وحدها ليست تعريفًا للسلوك الصحيح.
12. اختبار التعامل مع خدمة خارجية
متى تستخدمه؟ قبل ربط اختبار محلي ببيانات حقيقية أو شبكة متقلبة.
هذه الدالة التي تستدعي [الخدمة] [الكود]، وعقد استجابتها المتاح [الشكل الموثق]. اقترح اختبارات محلية لمحاكاة نجاح الطلب، وفشل الشبكة، واستجابة ناقصة، مع بيانات مصطنعة ودون مفاتيح حقيقية. حدّد ما الذي يثبته الاختبار وما الذي يبقى بحاجة إلى اختبار تكامل مصرح به. لا ترسل طلبات فعلية ولا تعدل الخدمة. استخدم أدوات المحاكاة الموجودة في المشروع بدل إضافة حزمة تلقائيًا.
راجع النتيجة: الاستجابة المصطنعة يجب أن تمثل العقد الحقيقي؛ نجاح المحاكاة لا يثبت الاتصال بالخدمة أو صلاحية الحساب.
تحسين الكود وتسليم تعديل يمكن مراجعته
13. إعادة تنظيم جزء دون تغيير سلوكه
متى تستخدمه؟ إذا كان الكود صعب القراءة لكنه يعمل وفق متطلبات معروفة.
أعد تنظيم هذا الجزء [الكود] لتحسين [الوضوح/إزالة تكرار محدد] فقط. احتفظ بعقد السلوك [الشروط] والواجهات العامة وترتيب الآثار الجانبية. اعرض التغيير المقترح على مراحل صغيرة، واذكر ما الذي قد يغير السلوك ولو بدا تجميليًا. لا تضف ميزة أو اعتمادًا أو تحسنًا مزعومًا في السرعة. اقترح فحوصًا تغطي المسارات المتأثرة بدل إعادة اختبار المشروع كله بلا مبرر.
راجع النتيجة: قارن الناتج والأخطاء والآثار الجانبية؛ نقل سطر قد يغيّر توقيت تنفيذ عملية حتى إن بقيت الأسماء نفسها.
14. تحليل بطء محتمل بخطة قياس
متى تستخدمه؟ عندما يكون هناك انطباع بالبطء دون دليل على موضعه.
المهمة [الوصف] بطيئة عند حجم بيانات [الحجم] في بيئة [البيئة]، وهذا الجزء المشتبه به [الكود]. اقترح خطة قياس صغيرة تحدد الزمن وعدد العمليات أو الطلبات ذات الصلة، ثم فرّق بين تكلفة المعالجة والشبكة والعرض. لا تعلن تسريعًا بنسبة محددة دون قياس، ولا تغيّر الخوارزمية قبل تحديد عنق الزجاجة. اذكر مدخلات ممثلة وحالة كبيرة معقولة، وكيف أقارن النتائج في ظروف متقاربة.
راجع النتيجة: قارن العمل نفسه في البيئة نفسها؛ اختلاف العينة أو الذاكرة المؤقتة قد يفسر جزءًا من الفرق.
15. إعداد ملخص تعديل وتسليم واضح
متى تستخدمه؟ بعد مراجعة الفرق وإكمال الفحوص المناسبة.
هذه المتطلبات الأصلية [المتطلبات]، وهذا فرق التعديل [الفرق]، وهذه نتائج الفحوص الفعلية [الأوامر والنتائج]. اكتب ملخصًا يشرح المشكلة والسلوك بعد التعديل والملفات المتأثرة وكيف تحققنا منها. افصل الفحوص التي نُفذت عن المقترحة، واذكر القيود الباقية دون تضخيم. لا تكتب أن كل الاختبارات نجحت إذا كانت النتيجة غير متاحة، ولا تنسب للتعديل أثرًا على الأداء أو الأمان لم نتحقق منه.
راجع النتيجة: يجب أن يستطيع مراجع لا يعرف المحادثة فهم التغيير وحدود التحقق من هذا الملخص وحده.
مثال توضيحي: عدّ المهام المكتملة بالقيمة الصحيحة
نفترض دالة تستقبل قائمة عناصر، وكل عنصر كائن قد يحمل الحقل done. المطلوب احتساب القيمة المنطقية true وحدها، مع استبعاد القيم الأخرى. هذه مسألة تعليمية أصلية، وليست خطأ اكتشفناه في مشروع مستخدم أو اختبارًا لخدمة مدفوعة.
function countCompleted(tasks) {
return tasks.filter(task => task.done).length;
}الشرط الحالي يستخدم صدق القيمة، لذلك لا يقتصر على true. في العينة التي تضم false وtrue والنص "true" والرقم 1، سيحتسب ثلاث قيم، بينما العقد المطلوب يحتسب واحدة فقط. هذه قراءة لمنطق المثال؛ في المشروع الفعلي يبقى تشغيله ضمن البيئة المناسبة جزءًا من التحقق.
| قيمة done | هل تدخل في العقد؟ | سبب القرار |
|---|---|---|
| true | نعم | قيمة منطقية مطابقة للشرط. |
| false | لا | المهمة غير مكتملة بحسب العقد. |
| “true” | لا | نص، وليس قيمة منطقية. |
| 1 | لا | عدد، ولو كان صادقًا في شرط عام. |
| حقل غير موجود | لا، وفق هذا المثال | تحتاج سياسة المدخلات في مشروعك إلى توضيح مستقل. |
استخدم القالب 3 لحسم الفرق بين النص والقيمة المنطقية، ثم القالب 6 لتضييق التعديل. اقتراح مباشر لهذا العقد هو جعل الشرط task.done === true. أما احتمال احتواء القائمة على null أو عناصر ليست كائنات، فيحتاج قرارًا آخر في عقد المدخلات؛ لا تدّع أن تغيير الشرط عالج كل بنية بيانات ممكنة.
سير عمل عملي للمبتدئ
ابدأ بالشرح إذا لم تفهم الدالة. بعد ذلك اكتب حالة صغيرة توضح ما تتوقعه وما حصل، ثم اطلب تشخيصًا وإصلاحًا محدودًا. راجع فرق الملفات، وشغّل الاختبار الذي يكشف المشكلة والفحوص التي تمس السلوك المتغير. إذا لم تستطع شرح سبب التعديل، ارجع إلى القالب 2 بدل دمجه لأن الاختبار أصبح أخضر.
لتخصيص السياق والقيود عمومًا، ارجع إلى هندسة البرومبتات بالعربي. وإذا كان العمل متعلقًا بالواجهة، تكمل هذه القوالب برومبتات تصميم المواقع العربية وواجهات RTL التي تركز على تجربة الصفحة ومتطلبات العرض.
وعندما تستخدم مساعدًا قادرًا على تعديل مشروع وتشغيله، مثل المسار الموضح في شرح Replit بالعربي، حدّد نطاق العمل قبل التنفيذ. صلاحية تشغيل الكود تختلف عن مجرد اقتراحه داخل محادثة؛ لا تحول طلب تفسير قصير إلى تثبيت حزم أو نشر تطبيق دون حاجة.
أسئلة شائعة عن برومبتات البرمجة
هل يمكن الاعتماد على الكود الذي يولده المساعد مباشرة؟
راجعه وشغّله في بيئة مناسبة قبل دمجه. صحة الصياغة أو غياب رسالة خطأ لا يثبت مطابقة المتطلب، لذلك استخدم مدخلًا متوقعًا وحالة تكشف الخطأ وحدودًا مؤثرة في السلوك.
هل يكفي إرسال رسالة الخطأ وحدها؟
قد تكفي لشرح معناها العام، لكنها غالبًا لا تحسم السبب. أرفق المقطع المعني وطريقة الاستدعاء والإصدار وخطوات إعادة المشكلة، دون نشر أسرار أو بيانات لا تحتاجها المهمة.
هل أطلب اختبارات لكل تعديل بسيط؟
اختر تحققًا يناسب أثر التغيير. إصلاح منطق أو حساب يستفيد من اختبار يكشف الخطأ، بينما تغيير صياغة تعليق قد يكفيه فحص الفرق. تجنب اختبارات تعيد كتابة التنفيذ ولا تفحص سلوكًا مطلوبًا.
هل تعمل القوالب بالعربية مع كود إنجليزي؟
يمكنك وصف المتطلب بالعربية مع إبقاء أسماء الدوال والمتغيرات ورسائل الخطأ كما هي. المهم أن تكون المعلومات والنتائج المتوقعة واضحة، وألا تغير الترجمة اسمًا يحتاج المساعد إلى العثور عليه في الملف.
المصادر ومنهج إعداد القوالب
راجعت AIFekra في 6 نوفمبر 2026 إرشادات GitHub لصياغة برومبتات Copilot وأفضل ممارسات مراجعة اقتراحاته. القوالب ومثال عدّ المهام من إعدادنا؛ ليست منقولة من تلك الوثائق ولا تمثل نتائج مقارنة أداء بين الأدوات.
