هندسة التلقين (Prompt Engineering): دليل عملي لكتابة أوامر أفضل للذكاء الاصطناعي والمبرمجين

هندسة التلقين (Prompt Engineering) هي المهارة التي تساعدك على تحويل طلب عادي إلى تعليمات واضحة يستطيع نموذج الذكاء الاصطناعي فهمها وتنفيذها بصورة أدق. فإذا كنت تبحث عن كيفية كتابة أوامر الذكاء الاصطناعي بطريقة عملية، فالموضوع لا يتعلق باستخدام كلمات سحرية، بل بفهم المهمة والسياق والقيود وشكل المخرجات، ثم اختبار النتيجة وتحسينها.

في هذا الدليل ستتعلم أساسيات هندسة الأوامر وكتابة البرومبت، ثم تنتقل إلى تقنيات مثل Zero-shot وFew-shot وPrompt Chaining، وطرق تقليل الهلوسة، واختبار الأوامر، واستخدام Structured Outputs. وسترى أيضًا كيف تنتقل من استخدام البرومبت داخل أدوات المحادثة إلى دمجه برمجيًا باستخدام Python وGemini API، مع مبادئ يمكن تطبيقها على نماذج لغوية أخرى مثل ChatGPT وClaude.

الهدف ليس فقط أن تكتب Prompt أفضل، بل أن تتعامل مع Prompt Engineering كعملية تصميم واختبار وتحسين يمكن تكرارها داخل التطبيقات والمشروعات البرمجية.

ملاحظة عن الأمثلة والاختبار: الأوامر والأمثلة في هذا الدليل مكتوبة أساسًا لتوضيح المفاهيم وطريقة التطبيق. تم التحقق من اتصال حي بـ Gemini API بنجاح، بينما تظل بقية الأمثلة التعليمية توضيحية ما لم يُذكر صراحة أنها شُغّلت فعليًا. نجاح الاتصال بالواجهة البرمجية لا يضمن صحة كل استجابة يولدها النموذج، لذلك يجب دائمًا التحقق من المخرجات واختبارها داخل بيئة التطبيق قبل الاعتماد عليها.

ما هي هندسة التلقين (Prompt Engineering) ولماذا تهم المستخدم والمبرمج؟

هندسة التلقين (Prompt Engineering) هي ممارسة تحسين النص الذي تعطيه لنموذج لغوي كبير (LLM) للحصول على الاستجابة المطلوبة. تعرّفها وثائق Amazon Bedrock بهذا المعنى، وتصفها SAP بأنها صياغة أوامر دقيقة توجّه أنظمة الذكاء الاصطناعي نحو استجابات ملائمة. أما البرومبت (Prompt) فهو المدخل النصي الذي تعطيه للنموذج: سؤال أو مهمة أو نص يعمل عليه.

الفرق بين «كتابة سؤال» و«هندسة التلقين» هو الفرق بين محاولة عابرة وتصميم متكرر. السؤال العابر تجرّبه مرة وتعدّله بيدك. أما الـPrompt المصمَّم فيُكتب ليعطي نتيجة مقبولة عبر مدخلات مختلفة، ويمكن تقييمه ومقارنته بنسخة أخرى.

وتزداد أهمية المهارة عند المبرمج لسبب عملي. حين يصبح البرومبت جزءًا من تطبيق، يُنفَّذ مئات المرات أو آلافها، فيتكرر معه أي غموض فيه. لذلك يُعامَل كجزء من الكود: يُكتب بعناية، وتُحفظ نسخه، وتُختبر تعديلاته.

ما المهارات التي يحتاجها مهندس التلقين؟

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

تشريح البرومبت الجيد: المهمة والسياق والقيود وشكل المخرجات

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

المكوّن	وظيفته	مثال برمجي
المهمة (Task)	ما الذي يجب أن يفعله النموذج، بفعل واحد واضح	«راجع هذه الدالة وحدد الأخطاء المحتملة»
المدخل (Input)	المادة التي يعمل عليها النموذج	الكود، أو سجل الخطأ
السياق (Context)	معلومات لا يمكن للنموذج أن يعرفها وحده	إصدار Python، وما تفعله الدالة، وأين تفشل
القيود (Constraints)	ما يجب الالتزام به وما يجب تجنبه	«لا تغيّر توقيع الدالة»
شكل المخرجات (Output format)	كيف تريد أن تكون الإجابة	جدول، أو JSON بحقول محددة
الأمثلة (Examples)	مدخل ومخرج نموذجيان يوضحان النمط المطلوب	مثالان لتصنيف أسطر السجل
تعليمات النظام (System instructions)	قواعد ثابتة تسبق كل طلب، حين تتيحها الواجهة	دور المراجع وقواعد الإجابة الثابتة

وهناك ثلاث ملاحظات تنظيمية تتكرر في إرشادات Google لنماذج Gemini 3: استخدم فواصل واضحة بين أجزاء البرومبت (وسوم شبيهة بـXML أو عناوين Markdown) واختر أحدهما وثبّت عليه. وضع القيود الحرجة وتنسيق المخرجات في تعليمات النظام أو في بداية البرومبت. وعند إدخال سياق طويل، ضع السياق أولًا وسؤالك في النهاية.

هل تنطبق هذه المبادئ على ChatGPT وClaude ونماذج أخرى؟ نعم، المبادئ العامة مثل تحديد المهمة والسياق والقيود والأمثلة وشكل المخرجات مفيدة عند التعامل مع نماذج لغوية مختلفة، بما فيها Gemini وChatGPT وClaude. لكن طريقة تعريف تعليمات النظام (System Instructions)، والأدوات المتاحة، والمخرجات المنظمة (Structured Outputs)، وبعض إعدادات التوليد تختلف بين النماذج وواجهات API؛ لذلك راجع توثيق النموذج الذي تستخدمه عند التطبيق البرمجي.

تنطبق المبادئ العامة مثل تحديد المهمة والسياق والقيود وشكل المخرجات على نماذج مختلفة. وإذا كنت تبدأ مع ChatGPT من الصفر، فراجع دليل استخدام ChatGPT خطوة بخطوة قبل الانتقال إلى تصميم البرومبتات المتقدمة.

مثال قبل وبعد: المهمة نفسها بصياغتين

افترض أن لديك دالة تنهار أحيانًا في بيئة الإنتاج. هذه صياغة شائعة لكنها ناقصة:

الكود هذا فيه مشكلة، أصلحه.

def average(nums):
    return sum(nums) / len(nums)

وهذه صياغة تحدد المهمة والسياق والقيود وشكل الإجابة:

# المهمة
الدالة التالية تنهار أحيانًا في بيئة الإنتاج. حدّد سبب الانهيار المحتمل ثم اقترح إصلاحًا.

# السياق
- Python 3.11، والدالة تستقبل قوائم يرسلها المستخدمون.
- الخطأ الظاهر في السجل: ZeroDivisionError

# الكود
def average(nums):
    return sum(nums) / len(nums)

# القيود
- لا تغيّر اسم الدالة ولا توقيعها.
- اذكر الحالات الحدّية الأخرى إن وُجدت، دون اختلاق حالات لا يدعمها الكود.

# شكل المخرجات
1) السبب في جملتين. 2) الكود المصحّح داخل كتلة كود. 3) حالتا اختبار تثبتان الإصلاح.

الصياغة الثانية لم تعتمد على «كلمات أقوى»، وإنما على معلومات أكثر: الأعراض التي ظهرت، والبيئة، وما يجب ألا يتغير، وما تريد أن تتسلمه. النتيجة لن تكون متطابقة في كل تشغيل، لكنها تصبح أسهل في الحكم عليها لأن المطلوب معروف.

قالب قابل لإعادة الاستخدام

انسخ هذا القالب واستبدل ما بين الأقواس المربعة. احذف الأقسام التي لا تحتاجها.

# المهمة
[فعل واحد واضح: اشرح / راجع / أصلح / اكتب اختبارات]

# السياق
[اللغة والإصدار، والغرض من الكود، وما جرّبته، والبيئة]

# المدخل
[الكود أو السجل أو النص الذي سيعمل عليه النموذج]

# القيود
- [ما يجب الالتزام به]
- [ما يجب تجنبه]
- إن لم تكفِ المعلومات فاذكر ما ينقص بدل التخمين.

# أمثلة (اختياري)
[مدخل ومخرج نموذجيان بنفس التنسيق]

# شكل المخرجات
[جدول / قائمة مرقّمة / JSON بحقول محددة / كتلة كود فقط]

تقنيات هندسة التلقين: من Zero-shot وFew-shot إلى تقسيم المهام

القاعدة العملية: ابدأ بتعليمات واضحة. إن اختلف شكل الإجابة أو تسمياتها عمّا تريد، أضف أمثلة. وإن كانت المهمة كبيرة، قسّمها إلى خطوات. الجدول التالي يلخص التقنيات.

التقنية	ما هي	متى تناسب	حدودها
التلقين دون أمثلة (Zero-shot)	تعليمات بلا أي مثال	مهام واضحة ومألوفة مثل الشرح والتلخيص	قد يختلف شكل الإجابة بين تشغيل وآخر
التلقين بأمثلة (Few-shot)	إضافة أمثلة مدخل/مخرج	عندما يهم الشكل أو التسميات أو الأسلوب	كثرة الأمثلة قد تدفع النموذج إلى تقليدها حرفيًا
سلسلة الأوامر (Prompt chaining)	تقسيم المهمة إلى خطوات، وناتج كل خطوة مدخل للتالية	مهام متعددة المراحل	خطأ في خطوة مبكرة ينتقل إلى ما بعدها، فتلزم نقاط تحقق
سلسلة الأفكار (Chain-of-thought)	طلب خطوات استدلال وسيطة قبل الجواب	مسائل منطقية أو حسابية متعددة الخطوات	قد يحسّن الأداء ولا يضمن الصواب، ويزيد طول الإجابة
شجرة الأفكار (Tree-of-thought)	استكشاف عدة مسارات للحل وتقييمها	مسائل تحتاج تجربة بدائل	تقنية متقدمة، ولا نعرض هنا نتائج أداء لها

Zero-shot وFew-shot: متى تضيف أمثلة؟

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

مثال برمجي: تصنيف أسطر سجل الأخطاء. المثالان يحدّدان أسماء الفئات وشكل الجواب:

صنّف سبب الخطأ في سطر السجل إلى واحدة من: syntax، runtime، network، config.
أجب بكلمة واحدة فقط.

السجل: SyntaxError: invalid syntax (app.py, line 4)
التصنيف: syntax

السجل: ConnectionRefusedError: [Errno 111] Connection refused
التصنيف: network

السجل: KeyError: 'DATABASE_URL'
التصنيف:

التفكير المنظم والمهام متعددة الخطوات

سلسلة الأفكار (Chain-of-thought) تعني أن تطلب من النموذج أو تريه خطوات استدلال وسيطة قبل الجواب النهائي. قدّمت ورقة Wei وزملائه (2022) هذه الفكرة وبيّنت أنها تحسّن الأداء في مسائل الاستدلال متعددة الخطوات. لكن هذا تحسين محتمل وليس ضمانًا: قد تبدو الخطوات منطقية وتنتهي بنتيجة خاطئة، وقد تطيل الإجابة دون فائدة.

ويتغير الأمر مع النماذج الحديثة. بحسب إرشادات Google، تولّد نماذج Gemini 2.5 و3 «تفكيرًا» داخليًا تلقائيًا، فلا يلزم عادةً أن تطلب منها عرض خطوات الاستدلال في الإجابة نفسها. وللمسائل الثقيلة، يمكن لطلب بسيط بأن تفكّر بعمق قبل الإجابة أن يحسّن الأداء على حساب استهلاك أكبر من الرموز (tokens).

لذلك ركّز عمليًا على ما يفيدك في كل الحالات:

• قسّم المهمة: توصي Google بتفكيك المهام المعقدة إلى أوامر أصغر وربط نتائجها. مثال: الأمر الأول يستخرج الدوال المتأثرة، والثاني يقترح التعديل، والثالث يكتب الاختبارات.
• اطلب مخرجات مرحلية قابلة للفحص: افتراضات، ثم خطة، ثم كود.
• أضف نقاط تحقق بينها: أدِر الخطوة التالية فقط بعد مراجعة السابقة.

أما شجرة الأفكار (Tree-of-thought) فهي تقنية أكثر تقدمًا، تستكشف عدة مسارات للحل وتقيّمها. نكتفي بالإشارة إليها هنا، ولا ننسب إليها نتائج أداء محددة.

ماذا عن Temperature وTop-p؟

لا تعتمد النتيجة على صياغة البرومبت وحدها؛ تتيح بعض واجهات النماذج أيضًا إعدادات تتحكم في طريقة توليد الاستجابة. تتحكم temperature في مقدار العشوائية أثناء اختيار الرموز التالية، بينما يحدد top_p نطاق الاحتمالات التي يمكن للنموذج الاختيار منها. هذه الإعدادات ليست بديلًا عن البرومبت الجيد، ولا تعني ببساطة «الإبداع مقابل الدقة» في كل الحالات.

في نماذج Gemini 3.x توصي Google حاليًا بالإبقاء على قيم temperature وtop_p وtop_k الافتراضية في معظم الاستخدامات، لأن تعديلها قد يؤدي أحيانًا إلى سلوك غير متوقع أو تراجع في الأداء. لذلك ابدأ بالإعدادات الافتراضية، وعدّلها فقط عندما يكون لديك سبب واضح واختبار يقيس أثر التغيير.

قوالب أوامر عملية للمبرمجين

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

تنبيه قبل اللصق: احذف من الكود والسجلات أي مفاتيح API أو كلمات مرور أو بيانات عملاء قبل إرسالها إلى أي خدمة ذكاء اصطناعي.

وإذا كنت ما زلت تختار الأداة التي ستستخدم معها هذه البرومبتات في البرمجة، فراجع مقارنتنا بين أفضل أدوات الذكاء الاصطناعي للبرمجة مثل ChatGPT وClaude وGemini وGitHub Copilot.

1. شرح كود موجود

# المهمة
اشرح الكود التالي لمبرمج [مبتدئ / متوسط]، سطرًا بسطر عند الحاجة.

# السياق
اللغة: [اللغة والإصدار] | الغرض المتوقع: [إن عرفته]

# الكود
[الصق الكود]

# القيود
- اشرح ما يفعله الكود فعلًا، لا ما تظن أن كاتبه قصده.
- إن وجدت جزءًا غامضًا فاذكر ذلك صراحة بدل تخمين نيّته.

# شكل المخرجات
ملخص من جملتين، ثم شرح مرقّم للأجزاء الرئيسية.

2. اكتشاف Bug

# المهمة
حدّد السبب الأرجح لهذا الخطأ واقترح إصلاحًا.

# السياق
السلوك المتوقع: [...] | السلوك الفعلي: [...] | رسالة الخطأ: [إن وُجدت]

# الكود
[الصق الكود]

# القيود
- رتّب الأسباب المحتملة من الأرجح إلى الأقل ترجيحًا.
- بيّن كيف أتحقق من كل سبب قبل تعديل الكود.
- لا تعِد كتابة الملف كله؛ أرني الجزء المتغيّر فقط.

# شكل المخرجات
جدول: السبب | دليله في الكود | طريقة التحقق | الإصلاح المقترح

3. مراجعة كود (Code Review)

# المهمة
راجع التغيير التالي كما يراجعه زميل قبل الدمج.

# السياق
[وصف التغيير، ومعايير الفريق إن وُجدت]

# الكود

[diff أو الملف]

# القيود – ركّز على: الأخطاء المنطقية، والحالات الحدّية، والأمان، وسهولة القراءة. – صنّف كل ملاحظة: يجب إصلاحها / يُفضَّل / مجرد رأي. – لا تذكر ملاحظة لا يدعمها الكود المعروض. # شكل المخرجات قائمة مرقّمة: الملف والسطر | الملاحظة | التصنيف | الاقتراح

4. إعادة الهيكلة (Refactoring) مع الحفاظ على السلوك

# المهمة
أعد هيكلة الكود التالي لتحسين [القراءة / تقسيمه إلى دوال / إزالة التكرار] مع بقاء السلوك نفسه.

# الكود
[الصق الكود]

# القيود
- لا تغيّر التوقيعات العامة ولا المخرجات.
- لا تضف مكتبات جديدة.
- اذكر أي موضع قد يتغير فيه السلوك ولو بشكل طفيف.

# شكل المخرجات
1) الكود الجديد داخل كتلة كود. 2) قائمة قصيرة بما تغيّر ولماذا. 3) اختبارات تُظهر أن السلوك لم يتغير.

5. إنشاء اختبارات

# المهمة
اكتب اختبارات وحدة للدالة التالية باستخدام [pytest / Jest / ...].

# الكود
[الصق الكود]

# القيود
- غطِّ الحالة العادية، والحالات الحدّية (قيم فارغة، حدود، أنواع غير متوقعة)، وحالات الفشل المتوقعة.
- سمِّ كل اختبار باسم يصف السلوك المختبَر.
- لا تفترض سلوكًا غير موجود في الكود؛ إن لم يكن سلوك حالة ما واضحًا فاذكر افتراضك.

# شكل المخرجات
ملف اختبار واحد جاهز للتشغيل.

6. تحويل متطلبات إلى خطة تنفيذ

# المهمة
حوّل المتطلبات التالية إلى خطة تنفيذ قابلة للتقسيم إلى مهام.

# السياق
المكدّس التقني: [...] | القيود: [الوقت، الفريق، أنظمة قائمة]

# المتطلبات
[الصق المتطلبات]

# القيود
- ابدأ بالأسئلة أو الافتراضات التي تحتاج تأكيدًا قبل التنفيذ.
- قسّم العمل إلى مهام صغيرة يمكن اختبار كل منها.
- حدّد المخاطر التقنية الرئيسية.

# شكل المخرجات
افتراضات ← مهام مرقّمة بترتيب التنفيذ ← مخاطر

7. تحليل رسالة خطأ (Error / Stack Trace)

# المهمة
حلّل رسالة الخطأ التالية وحدد أين تبدأ المشكلة فعلًا.

# السياق
[البيئة، وما كنت تفعله عند حدوث الخطأ، وأحدث تغيير أجريته]

# سجل الخطأ
[الصق الـStack Trace كاملًا]

# الكود ذو الصلة
[المقاطع التي تظهر في السجل فقط]

# القيود
- ميّز بين السطر الذي ظهر عنده الخطأ والسطر الذي سبّبه.
- إن لم يكفِ السجل لتحديد السبب فاذكر ما يلزمني تزويدك به.

# شكل المخرجات
السبب الأرجح ← الدليل من السجل ← خطوات الإصلاح ← كيف أتأكد أنه أُصلح

كيف تقلل الهلوسة وتزيد قابلية التحكم في النتائج؟

الهلوسة (Hallucination) هي أن ينتج النموذج معلومة تبدو معقولة لكنها خاطئة أو غير مسنودة. في البرمجة تظهر غالبًا على شكل دوال أو معاملات أو مكتبات غير موجودة، أو شرح واثق لسلوك لا يحدث فعلًا. لا يمكن إلغاء الهلوسة بجملة في البرومبت. الممكن هو تقليل احتمالها وتسهيل اكتشافها. وتشير وثائق AWS إلى ثلاثة مسارات: تحسين البرومبت، أو تزويد النموذج ببيانات أوثق عبر الاسترجاع المعزز بالتوليد (RAG)، أو تجربة نموذج آخر.

هذه قائمة تحقق عملية، مرتبة من الأسهل إلى الأشمل:

1. زوّد النموذج بالمصدر. الصق الجزء ذا الصلة من الوثائق أو الكود، ولا تفترض أن النموذج يحفظه. في مثال Google لجهاز الشبكة، أعطت الإجابة نصائح عامة حتى أُضيف دليل الجهاز نفسه إلى البرومبت.
2. قيّد المهمة. اطلب الإجابة من النص المعطى فقط حين يكون هذا هو المطلوب. وتقدم Google مثالًا على تعليمات تقيّد النموذج بالسياق المعروض وتطلب منه أن يذكر أن المعلومة غير متاحة إن لم تكن مكتوبة فيه.
3. أتِح له أن يقول «لا أعرف». أضف قيدًا مثل: «إن لم تكفِ المعلومات فاذكر ما ينقص بدل التخمين».
4. استخدم الربط بمصدر خارجي (Grounding) للمعلومات الحديثة أو النادرة. تذكر Google أن Grounding with Google Search يربط النموذج بمحتوى الويب الحي، وينبغي تفعيله حين يحتاج النموذج إلى وقائع حديثة أو غير شائعة.
5. لا تعتمد على النموذج في الحساب. تنصح Google بتفعيل أداة تنفيذ الكود (Code execution) كلما احتاج النموذج إلى حساب أو عدّ.
6. اطلب مخرجات منظمة إذا كان الناتج سيدخل في كود (انظر ما بعد هذه القائمة).
7. تحقق بعد الاستجابة. شغّل الكود، ونفّذ الاختبارات، وراجع أسماء الدوال والمكتبات في الوثائق الرسمية.

التحكم في الشكل لا يعني صحة المحتوى

تتيح المخرجات المنظمة (Structured Outputs) في Gemini أن تُلزم النموذج بإرجاع JSON يطابق مخططًا (Schema) تحدده. هذا يضبط الشكل: الحقول والأنواع والقيم المسموحة. لكن الوثائق نفسها تنبّه إلى أن الناتج صحيح بنيويًا فقط، وتوصي بالتحقق من القيم داخل تطبيقك ومعالجة الحالات التي يكون فيها الناتج مطابقًا للمخطط لكنه خاطئ دلاليًا.

مثال: قد يرجع النموذج JSON سليمًا يقول إن الخطأ في السطر 40 بينما الكود من ثلاثة أسطر. البنية صحيحة والمحتوى غير صحيح. سترى في قسم Python أدناه كيف تضيف فحصًا بسيطًا لذلك.

اختبار البرومبت وتحسينه بدل تعديله عشوائيًا

لتعرف أن نسخة جديدة من البرومبت أفضل فعلًا، جرّبها على مجموعة ثابتة من الحالات وبمعايير ثابتة، ولا تحكم من تجربة واحدة. تصف Google هندسة التلقين بأنها عملية تكرارية تحتاج إلى تجريب وتعديل بحسب ما يظهر من استجابات، والاختبار المنظم هو ما يحوّل هذا التجريب من انطباع إلى قرار.

1. حدّد الهدف: ماذا يعني «نجاح» الإجابة؟ (مثال: يكتشف الخطأ المزروع، ولا يخترع أخطاء أخرى.)
2. ابنِ مجموعة حالات ثابتة: من 10 إلى 30 حالة تمثل الاستخدام الحقيقي، وتشمل حالات صعبة وحالات لا يوجد فيها خطأ أصلًا. (العدد اقتراح عملي، وليس رقمًا من مصدر.)
3. اكتب معايير التقييم (Rubric): أسئلة بنعم/لا قدر الإمكان.
4. سجّل نسخة البرومبت واسم النموذج وتاريخ التشغيل.
5. شغّل الحالات كلها على النسخة الحالية ودوّن النتيجة.
6. حلّل حالات الفشل: هل السبب غموض في التعليمات؟ أم سياق ناقص؟ أم شكل مخرجات غير محدد؟
7. غيّر شيئًا واحدًا أو تغييرات محددة ثم أعد التشغيل على المجموعة نفسها.
8. قارن النسختين بالمعايير نفسها، واحتفظ بالأفضل.

ويمكن أن يكون سجل التجارب جدولًا بسيطًا بهذه الأعمدة:

النسخة	ما تغيّر	النموذج والتاريخ	الحالات الناجحة من الإجمالي	أبرز حالات الفشل
v1	الصياغة الأساسية	[معرّف النموذج، تاريخ التشغيل]	[عدد الناجح / الإجمالي]	[وصف الحالات الفاشلة]
v2	إضافة قيد «لا تذكر ملاحظة لا يدعمها الكود»	[معرّف النموذج، تاريخ التشغيل]	[عدد الناجح / الإجمالي]	[وصف الحالات الفاشلة]

حدود هذا المنهج: هو اختبار عملي لبرومبتاتك أنت، وليس معيارًا علميًا شاملًا (Benchmark). وتذكر وثائق AWS أن استجابات النماذج قد تتفاوت بين تشغيل وآخر بحكم طبيعة التوليد، لذلك أعد الاختبار عند تغيير النموذج أو إصداره، ولا تعمّم نتيجة مجموعة صغيرة.

Prompting أم Fine-tuning أم مصدر معرفة خارجي؟

ابدأ بالبرومبت. فإذا بقيت المشكلة، فحدّد نوعها: هل ينقص النموذج معلومات (فمصدر خارجي)، أم يحتاج سلوكًا ثابتًا يتكرر عبر آلاف الحالات (فقد يفيد الضبط الدقيق)؟ توصي وثائق Google Cloud بالبدء بالـPrompting لإيجاد أفضل برومبت، ثم الانتقال إلى الضبط الدقيق (Fine-tuning) عند الحاجة لرفع الأداء أو معالجة أخطاء متكررة.

الضبط الدقيق (Fine-tuning) يعني تدريب النموذج على أمثلة تمثل مهمتك. في الضبط الدقيق، تُعدَّل أو تُضاف معاملات للنموذج وفق أسلوب الضبط المستخدم وبيانات التدريب، بهدف تخصيص سلوكه لمهمة أو نمط معين. أما الاسترجاع المعزز بالتوليد (RAG) فيعني جلب معلومات ذات صلة من مصدر خارجي وإضافتها إلى البرومبت وقت الطلب، فيجيب النموذج اعتمادًا عليها.

الخيار	ماذا يغيّر	يناسب عندما	حدوده
البرومبت (Prompting)	التعليمات والسياق والأمثلة في كل طلب	تريد بداية سريعة، أو بياناتك المصنّفة قليلة، أو تجرّب فكرة	قد لا يكفي لمهام معقدة أو لسلوك ثابت مطلوب بدقة عالية
مصدر معرفة خارجي (RAG / Grounding)	المعلومات المتاحة للنموذج وقت الإجابة	المشكلة نقص معلومات أو معلومات متغيّرة (وثائق داخلية، أحداث حديثة)	جودة الإجابة تتبع جودة ما يُسترجع
الضبط الدقيق (Fine-tuning)	سلوك النموذج نفسه عبر التدريب	مهام معقدة أو مميزة لا تكفيها استراتيجيات البرومبت، ولديك بيانات مصنّفة جيدة	يحتاج بيانات عالية الجودة (وثائق Google تشير إلى نحو 100 مثال فأكثر كنقطة بداية)، وتختلف إتاحته بحسب النموذج والخطة

الخيارات لا تتنافس دائمًا، بل تتكامل: قد تستخدم RAG لإدخال المعلومات، وبرومبت جيدًا لتنظيم الإجابة، وضبطًا دقيقًا لسلوك ثابت. ولا تعامل الضبط الدقيق كنسخة «أقوى» تلقائيًا من البرومبت. ذكرت Google أن جودة بيانات التدريب أهم من كميتها، وأن من المهم أن تفهم أين يخطئ النموذج قبل أن تضيف بيانات.

تطبيق عملي: إرسال Prompt من Python باستخدام google-genai

نطبّق هنا ما سبق على مهمة مراجعة كود، ونطلب النتيجة بصيغة JSON منظمة ونتحقق منها في Python. المتطلبات: مفتاح Gemini API، وتثبيت المكتبتين google-genai وpydantic، وإصدار Python الذي تدعمه المكتبة (الكود يستخدم صيغة list[Issue] فيلزم Python 3.9 أو أحدث). ضع المفتاح في متغير بيئة ولا تكتبه داخل الكود.

عن اختيار الواجهة: توصي Google حاليًا باستخدام Interactions API للمشروعات الجديدة. أما generateContent فتُصنَّف كواجهة أقدم (Legacy)، لكنها ما تزال مدعومة بالكامل. نستخدم generate_content في المثال الأساسي أدناه لأنه مباشر ويسهّل فهم العلاقة بين البرومبت والنموذج والاستجابة، ثم نعرض بعده الصيغة الحديثة باستخدام Interactions API. لذلك لا يعني استخدام المثال الأول أن generateContent لم تعد صالحة، كما أن الانتقال إلى Interactions API ليس شرطًا لتطبيق المبادئ الموضحة في هذا الدليل.

ولشرح إعداد المفتاح وتثبيت المكتبة واستخدام Interactions API ومعالجة الأخطاء بشكل أوسع، راجع دليلنا العملي عن ربط Gemini API مع Python باستخدام Google GenAI.

ثبّت المكتبتين:

pip install google-genai pydantic

ثم عرّف المفتاح في متغير البيئة GEMINI_API_KEY. على Linux وmacOS:

export GEMINI_API_KEY="YOUR_API_KEY"

وعلى Windows في PowerShell:

$env:GEMINI_API_KEY="YOUR_API_KEY"

أو في Windows CMD:

set GEMINI_API_KEY=YOUR_API_KEY

تنبيه: استبدل YOUR_API_KEY بمفتاحك، ولا تضع المفتاح مباشرة داخل الكود المنشور أو في مستودع Git. استخدم متغيرات البيئة، أو مدير أسرار (Secret Manager) مناسبًا لبيئة الإنتاج.

ثم الكود:

import os
from typing import Literal

from google import genai
from google.genai import types
from pydantic import BaseModel

# معرّف النموذج في متغير واحد. تحقق منه قبل الاستخدام لأنه يتغير.
MODEL_ID = os.getenv("GEMINI_MODEL", "gemini-3.8-flash")

client = genai.Client()  # يقرأ المفتاح من متغير البيئة GEMINI_API_KEY


class Issue(BaseModel):
    line: int
    severity: Literal["low", "medium", "high"]
    problem: str
    suggestion: str


class Review(BaseModel):
    summary: str
    issues: list[Issue]


CODE = """def average(nums):
    return sum(nums) / len(nums)
"""

SYSTEM = "أنت مراجع كود Python. أجب بالعربية، ولا تذكر مشكلة لا يدعمها الكود المعروض."

PROMPT = f"""# المهمة
راجع دالة Python التالية وحدد الأخطاء المحتملة.

# الكود
{CODE}

# القيود
- إن لم تجد مشكلة فأعد قائمة issues فارغة.
- رقم السطر يبدأ من 1.
"""

response = client.models.generate_content(
    model=MODEL_ID,
    contents=PROMPT,
    config=types.GenerateContentConfig(
        system_instruction=SYSTEM,
        response_mime_type="application/json",
        response_json_schema=Review.model_json_schema(),
    ),
)

# 1) تحقق من البنية والأنواع
review = Review.model_validate_json(response.text)

# 2) تحقق دلالي بسيط: هل رقم السطر موجود فعلًا؟
n_lines = len(CODE.strip().splitlines())
for issue in review.issues:
    if 1 <= issue.line <= n_lines:
        print(f"[{issue.severity}] السطر {issue.line}: {issue.problem}")
    else:
        print("تجاهل ملاحظة برقم سطر غير موجود:", issue)

شكل الناتج المتوقع، على سبيل التوضيح فقط وليس ناتج تشغيل فعلي:

{
  "summary": "الدالة تنهار عند تمرير قائمة فارغة.",
  "issues": [
    {
      "line": 2,
      "severity": "high",
      "problem": "قسمة على صفر عندما يكون طول القائمة صفرًا.",
      "suggestion": "أرجع قيمة افتراضية أو ارفع خطأ واضحًا عند القائمة الفارغة."
    }
  ]
}

عن حالة الاختبار: تم التحقق من اتصال حي بـ Gemini API بنجاح. هذا التحقق يثبت عمل الاتصال بالواجهة البرمجية، لكنه لا يمثل Benchmark للنموذج، ولا مقارنة بين نماذج، ولا قياسًا للسرعة أو الدقة، ولا يعني أن جميع إعدادات ومخرجات المثال الحالي قد خضعت لاختبار شامل. لذلك استمر في التحقق من المخرجات داخل تطبيقك، وخصوصًا صحة القيم دلاليًا إلى جانب صحة بنيتها.

ثلاث نقاط تستحق الانتباه في هذا المثال:

• معرّف النموذج مفصول عن المنطق. تعرض Google حاليًا gemini-3.8-flash نموذجًا مستقرًا في صفحة النماذج (اطُّلع عليها في 21 سبتمبر 2026)، لكن الإصدارات تتوالى بسرعة، فراجع الصفحة قبل الاعتماد على المعرّف.
• لم نضبط temperature أو top_p أو top_k. تنصح إرشادات Google بإبقاء هذه المعاملات على قيمها الافتراضية في نماذج Gemini 3.x، وتحذّر من أن خفضها قد يسبب سلوكًا غير متوقع مثل التكرار أو تراجع الأداء.
• التحقق على مرحلتين. model_validate_json يفحص البنية والأنواع، أما الحلقة الأخيرة فتفحص معنى القيمة (هل السطر موجود؟). البنية السليمة لا تثبت أن المحتوى صحيح.

المسار الحديث للمشروعات الجديدة: توصي Google باستخدام Interactions API في التطوير الجديد، مع استمرار دعم generateContent. إذا كانت المهمة لا تحتاج مخرجات منظمة، يمكن إرسال البرومبت بهذه الصورة:

interaction = client.interactions.create(
    model=MODEL_ID,
    input=PROMPT,
)

print(interaction.output_text)

أما إذا أردت تطبيق Structured Outputs مع Interactions API، فتُمرَّر إعدادات المخرجات من خلال response_format، ويُوضع مخطط JSON داخل الحقل schema. وباستخدام نموذج Review السابق يمكن كتابة الاستدعاء هكذا:

interaction = client.interactions.create(
    model=MODEL_ID,
    input=PROMPT,
    response_format={
        "type": "text",
        "mime_type": "application/json",
        "schema": Review.model_json_schema(),
    },
)

review = Review.model_validate_json(interaction.output_text)

لاحظ أن طريقة تمرير مخطط المخرجات تختلف هنا عن مثال generate_content السابق، الذي يستخدم إعدادات GenerateContentConfig. وفي الحالتين يضمن المخطط بنية الاستجابة المتوقعة، لكنه لا يضمن أن القيم التي يولدها النموذج صحيحة دلاليًا؛ لذلك يبقى التحقق البرمجي من القيم جزءًا ضروريًا من التطبيق. ولأن تفاصيل مكتبة google-genai قد تتغير مع الإصدارات، راجع التوثيق الرسمي عند تحديث المكتبة أو عند ظهور خطأ في معاملات الاستدعاء.

أين ينتهي البرومبت وتبدأ هندسة الـAI Agents؟

بناء وكيل ذكاء اصطناعي (AI Agent) ليس كتابة برومبت أطول. البرومبت جزء من النظام، لكن الوكيل الذي ينفذ مهامه بنفسه يحتاج أشياء لا يوفرها النص وحده: حالة تُحفظ بين الخطوات (State)، وأدوات يستدعيها (Tools)، وصلاحيات تحدد ما يُسمح له بفعله (Permissions)، وتنسيقًا بين الخطوات (Orchestration)، وإعادة محاولة عند الفشل (Retries)، وتحققًا من المخرجات (Validation)، ومراقبة لما جرى (Observability).

إذا أردت الانتقال من تصميم البرومبت إلى بناء نظام ينفذ المهام باستخدام الأدوات والذاكرة والصلاحيات، اقرأ دليلنا عن AI Agents وكيف تعمل وكيف تبني أول وكيل ذكي.

لهذا لا يعوّض تحسين البرومبت عن هندسة النظام. قد يقول برومبتك «لا تحذف أي ملف»، لكن القيد الحقيقي هو أن الوكيل لا يملك صلاحية الحذف أصلًا. الموضوع أوسع من أن يُختصر في قسم، وسنشرح هذا بالتفصيل في دليل مستقل عن AI Agents.

الخلاصة: من الفهم إلى التنفيذ

هندسة التلقين (Prompt Engineering) ليست مجموعة أوامر جاهزة تحفظها، بل طريقة منهجية لتحديد المهمة والسياق والقيود وشكل المخرجات، ثم اختبار النتيجة والتحقق منها وتحسينها. ومع إتقان هندسة الأوامر تصبح قادرًا على الحصول على استجابات أكثر قابلية للاستخدام، سواء كنت تستخدم أدوات المحادثة أو تبني تطبيقًا يعتمد على نماذج اللغة الكبيرة.

إذا كنت تتعلم كيفية كتابة أوامر الذكاء الاصطناعي، فابدأ بمهمة حقيقية لديك، واستخدم قالب كتابة البرومبت الوارد في هذا الدليل، ثم جرّبه على مجموعة حالات ثابتة وعدّل ما يحتاج إلى تحسين. وعند استخدام البرومبت داخل تطبيق، لا تكتفِ بجودة النص؛ أضف التحقق البرمجي، واستخدم المخرجات المنظمة أو المصادر الخارجية عندما تحتاج إليها.

الخطوة التالية: اختر مهمة برمجية واحدة، اكتب لها Prompt واضحًا، اختبره، ثم طبّقه عبر API. بهذه الطريقة تتحول هندسة التلقين من مهارة نظرية إلى جزء فعلي من سير عملك البرمجي.

اقرأ أيضًا

• شرح Gemini AI 2026: ما هو جيميناي وكيفية استخدامه خطوة بخطوة؟
• شرح Claude AI 2026: دليل الاستخدام والبرمجة ومقارنة النماذج
• أفضل أدوات كتابة المحتوى بالذكاء الاصطناعي 2026

أسئلة شائعة عن هندسة التلقين (Prompt Engineering)

تجيب الأسئلة التالية عن نقاط عملية شائعة عند استخدام هندسة التلقين مع نماذج اللغة الكبيرة (LLMs) مثل Gemini وChatGPT وClaude، خاصة عند دمج البرومبتات داخل التطبيقات وواجهات API.

ما الفرق بين User Prompt وSystem Instruction؟

User Prompt هو الطلب الذي يرسله المستخدم في كل تفاعل، بينما تحدد System Instructions قواعد وسلوكًا عامًا للنموذج قبل معالجة الطلب. في التطبيقات تُستخدم تعليمات النظام لضبط الدور والأسلوب والسياسات العامة، لكنها لا تُعد بديلًا عن التحقق البرمجي أو أنظمة الصلاحيات والأمان.

مثلًا، يمكن استخدام System Instruction لجعل النموذج يتصرف كمراجع كود Python ويجيب بالعربية دائمًا، بينما يحتوي User Prompt على الكود أو المهمة المحددة المطلوب تحليلها.

ويمكنك رؤية تطبيق عملي لـSystem Instructions داخل مشروع حقيقي في دليل بناء شات بوت ذكاء اصطناعي باللهجة الخليجية باستخدام Gemini.

هل يمكن استخدام البرومبت نفسه مع ChatGPT وGemini وClaude؟

يمكن عادةً نقل المبادئ الأساسية مثل وضوح المهمة والسياق والقيود والأمثلة وشكل المخرجات بين ChatGPT وGemini وClaude، لكن لا تتوقع نتائج متطابقة. تختلف النماذج وواجهات API في تعليمات النظام والأدوات والمخرجات المنظمة وبعض إعدادات التوليد.

لذلك استخدم البنية العامة نفسها كنقطة بداية، ثم اختبر البرومبت على النموذج الذي سيعمل عليه التطبيق فعليًا وعدّله وفق النتائج.

ما هو Temperature وهل يجب تغييره عند كتابة الكود؟

temperature هو أحد إعدادات التوليد التي تؤثر في مقدار العشوائية أثناء اختيار الرموز التالية في الاستجابة. القيم الأعلى قد تزيد تنوع المخرجات، لكن الإعداد المناسب يختلف حسب النموذج والمهمة؛ لذلك لا توجد قيمة واحدة مثالية لجميع مهام البرمجة.

في نماذج Gemini 3.x من الأفضل البدء بالإعدادات الافتراضية لـtemperature وtop_p وtop_k، ثم تغييرها فقط إذا كان لديك سبب واضح واختبار يقيس أثر التعديل على المهمة الفعلية.

كيف أطلب من الذكاء الاصطناعي إرجاع الكود فقط دون شرح إضافي؟

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

إذا كان الناتج سيدخل مباشرة في تطبيق، فاستخدم Structured Outputs أو مخططًا (Schema) عندما تدعم الواجهة ذلك، ثم تحقّق من البنية والقيم برمجيًا قبل استخدامها.

هل هندسة التلقين مهارة برمجية مستقلة؟

هندسة التلقين ليست لغة برمجة، بل مهارة في تصميم التعليمات والسياق والأمثلة والقيود والمخرجات ثم اختبارها وتحسينها. وتصبح مهمة للمطور عندما تتحول البرومبتات من محادثة عادية إلى جزء متكرر داخل تطبيق أو خدمة تعتمد على نموذج لغوي.

وفي أنظمة AI Agents تمثل هندسة التلقين جزءًا من الحل فقط؛ إذ تحتاج الأنظمة الموثوقة أيضًا إلى أدوات وصلاحيات وحالة (State) وتحقق من النتائج ومراقبة وتنظيم لسير التنفيذ.

هل أحتاج إلى معرفة البرمجة لتعلّم Prompt Engineering؟

لا تحتاج إلى معرفة البرمجة لتعلّم أساسيات هندسة التلقين واستخدامها مع أدوات المحادثة. يمكنك البدء بتحديد المهمة والسياق والقيود وشكل الإجابة، ثم اختبار البرومبت وتحسينه وفق النتائج.

لكن البرمجة تصبح مهمة عندما تريد استخدام البرومبتات عبر API، أو دمجها داخل تطبيق، أو استخدام Structured Outputs، أو التحقق من النتائج آليًا، أو بناء أنظمة ووكلاء ذكاء اصطناعي أكثر تعقيدًا.