هندسة الأوامر (Prompt Engineering) في 2026: 10 تقنيات ما زالت فعالة (و4 ماتت مع نماذج الاستدلال)

هندسة الأوامر (Prompt Engineering) في 2026: 10 تقنيات ما زالت فعالة (و4 ماتت مع نماذج الاستدلال)

لم تمت هندسة الأوامر (Prompt Engineering) في 2026. بل انقسمت إلى شقين. توثيق OpenAI الخاص بالاستدلال يطلب منك الآن التوقف عن كتابة "think step by step"، وورقة بحثية على arXiv من 2024 (2410.21333) قاست انخفاضاً في الدقة وصل إلى 36.3% عندما فُرضت سلسلة التفكير (chain-of-thought) على مهمة لا تناسبها. هذا هو الجزء الغريب. النصف العفوي من هندسة الأوامر أصبح أسهل، بينما النصف الإنتاجي، ذلك الذي يعمل فعلياً على GPT-5 وClaude، أصبح أكثر صرامة بكثير. يفرز هذا الدليل التقنيات العشر التي ما زالت تستحق وقتك من العادات الأربع التي تقاعدت مع نماذج الاستدلال (reasoning models).

أهم النقاط:

• انقسمت هندسة الأوامر (Prompt Engineering) إلى تلقين عفوي (أسهل) وتلقين إنتاجي (أكثر صرامة) في 2026.
• في reasoning models، يصبح فرض "think step by step" زائداً وقد يخفض الدقة. OpenAI توصي بتجنبه.
• أربع عادات تقاعدت: فرض chain-of-thought، التلقين الانعكاسي بأمثلة قليلة (few-shot)، تعبئة الرد المسبقة (response prefilling)، والضبط اليدوي لـbudget_tokens.
• ما لا يزال يفوز: الوضوح، structured outputs، تفكيك المهمة، والتكرار المبني على التقييم.

ما هي هندسة الأوامر فعلياً في 2026؟

هندسة الأوامر (Prompt Engineering) هي ممارسة تصميم وصقل التعليمات التي تقدّمها لنموذج لغة كبير للحصول على مخرجات دقيقة وذات صلة. تشمل التقنيات الأساسية zero-shot وfew-shot وchain-of-thought وتلقين الدور (role prompting). في 2026 تنقسم إلى مهمتين: تلقين عفوي داخل محادثة، وتلقين إنتاجي داخل نظام.

وهذا ما لم يقله أحد بصراحة حتى هذا العام: إنهما مهارتان مختلفتان تماماً. الحصول على إجابة جيدة في ChatGPT أصبح الآن شبه بديهي، لأن النماذج تتسامح مع الصياغة غير الدقيقة. أما الحصول على إجابة موثوقة من نظام يعمل ألف مرة يومياً، بعشر لغات، دون أي إنسان يراقبه، فهذا أمر مختلف تماماً. هذه المهمة الثانية هي محور هذا الدليل.

نكتب هنا من أجل الفئة الإنتاجية: المطورين ومهندسي الذكاء الاصطناعي الذين يحتاجون تعليمات تصمد على GPT-5 وClaude Opus 4.8 وGemini. أما المقدمة وهذا التعريف والأسئلة الشائعة فتبقى مفهومة لبقية القراء. وإن أردت التصنيف المحايد لكل تقنية معروفة باسمها، فمرجع dair-ai على promptingguide.ai لا يزال أفضل موسوعة على الويب لهذا الغرض. في 2026، هندسة الأوامر ليست مهارة واحدة. إنها مهارتان.

هندسة الأوامر مقابل هندسة السياق: ما الفرق؟

Prompt Engineering تصوغ التعليمة. هندسة السياق (Context Engineering) تصمم كل ما يدخل نافذة السياق حولها: الاسترجاع، والذاكرة، والأدوات، والترتيب. Prompt Engineering مجموعة جزئية من هندسة السياق. هذا الدليل يغطي شق صياغة الأوامر؛ والدليل المرتبط يغطي البقية.

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

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

التقنيات العشر الأساسية لصياغة الأوامر (مرتبة حسب عائد 2026)

التقنيات العشر التي تستحق معرفتها في 2026، مرتبة تقريباً حسب العائد مقابل الجهد: zero-shot، few-shot، تلقين الدور، chain-of-thought، تفكيك المهمة، تسلسل الأوامر، الاتساق الذاتي، structured outputs، قوالب الأوامر، وmeta-prompting. بعضها أدوات يومية أساسية؛ واثنتان منها تتصرفان بشكل مختلف على reasoning models، وهو ما يوضّحه القسم التالي.

الأسماء أدناه تتبع التصنيف الوارد في "The Prompt Report"، وهي مسح منهجي لأكثر من 50 تقنية تلقين. تعامل مع هذه القائمة كصندوق أدوات تسحب منه ما تحتاجه، لا كقائمة تحقق تُنفَّذ من أعلاها إلى أسفلها.

1. Zero-shot

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

# Target: GPT-5 / Claude Opus 4.8
Classify this support ticket as: billing, technical, or account.
Return only the single lowercase label.

Ticket: "My card was charged twice this month."

2. Few-shot

Few-shot يعني أن تُدرج من مثالين إلى خمسة أمثلة لتوجيه الشكل أو السلوك الذي تريده. إنها أسرع طريقة لتثبيت أسلوب مخرجات ينحرف عنه النموذج باستمرار. لكن هناك تحفظاً واحداً: على reasoning models، تقول أفضل ممارسات الاستدلال من OpenAI بأن تجرّب zero-shot أولاً وتضيف الأمثلة فقط إذا ساعدت بشكل قابل للقياس. في نماذج 2026، zero-shot هو الخيار الافتراضي وfew-shot هو الحل الاحتياطي، وليس العكس.

# Target: GPT-5
Extract the product and sentiment. Follow the examples.

Input: "The battery dies in an hour." -> product: battery, sentiment: negative
Input: "Setup took two minutes, loved it." -> product: setup, sentiment: positive
Input: "The screen is gorgeous but it's heavy." ->

3. تلقين الدور والشخصية (Role Prompting)

تلقين الدور يحدّد هوية النموذج قبل أن يجيب، وهو يشكّل النبرة والمفردات والتنسيق أكثر مما يشكّل الاستدلال الخام نفسه. عبارة مثل "أنت محاسب ضرائب أول يراجع إقراراً ضريبياً" تستدعي لغة مختلفة تماماً عن أمر فارغ من أي سياق. حافظ عليه وظيفياً لا مسرحياً. يجب أن يُرمِّز الدور قيوداً حقيقية: الجمهور المستهدف، التنسيق، وما يجب حذفه. مجموعتنا القادمة من أمثلة system prompt ستجمع الأنماط التي نعيد استخدامها أكثر من غيرها.

# Target: Claude Opus 4.8
You are a senior tax accountant. Review the figures below for a
small-business owner who is not an accountant.
Format: 3 bullet points, plain English, flag any number that looks wrong.

4. Chain-of-thought (CoT)

Chain-of-thought يطلب من النموذج أن يعرض خطوات استدلاله قبل الإجابة النهائية. في النماذج التقليدية من طراز GPT ما زالت هذه من أعلى التقنيات قيمة للرياضيات والمنطق والمسائل متعددة الخطوات. لكن على reasoning models قد تصبح زائدة أو حتى ضارة، وهذا ما يتناوله القسم التالي بأرقام حقيقية. مقالنا التفصيلي القادم عن chain-of-thought prompting سيشرح التقنية بكاملها. أما الآن، فتذكّر أنها لم تعد ردة فعل تلقائية تطبّقها على كل شيء.

5. تفكيك المهمة (Task Decomposition)

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

# Target: any 2026 model
Task: draft a product launch email.
Work in order and label each step:
1) Identify the audience and their main objection.
2) Write one subject line that answers that objection.
3) Write a 90-word body.
4) End with a single CTA.

6. تسلسل الأوامر (Prompt Chaining)

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

7. الاتساق الذاتي (Self-consistency)

الاتساق الذاتي يأخذ عينات من الإجابة على السؤال نفسه عدة مرات، ثم يعتمد إجابة الأغلبية. إنه يستبدل tokens إضافية بموثوقية أعلى في مسائل الاستدلال الصعبة حيث يكون التمرير الواحد غير مستقر، لكنك تدفع ثمن ثلاث إلى خمس إجابات كاملة للحصول على إجابة واحدة موثوقة. على reasoning models القوية يتقلص هذا الكسب غالباً، لذا احتفظ بها للمهام الغامضة فعلياً حيث تكون الدقة أهم من الفاتورة.

8. تنسيق المخرجات / Structured Outputs

Structured outputs تعني تقييد الاستجابة بمخطط (schema) بدلاً من الأمل في أن يُعيد النموذج JSON نظيفاً من تلقاء نفسه. هذه التقنية تستحق قسماً خاصاً بها أدناه. الخلاصة في سطر واحد: لا تتوسل للحصول على JSON داخل الأمر، بل قيّد النموذج بمخطط وتوقف عن التخمين.

9. قوالب الأوامر والمتغيرات (Prompt Templates)

القوالب تحوّل أمراً جيداً لمرة واحدة إلى أصل قابل للمعايرة وإعادة الاستخدام: تعليمات ثابتة مع فراغات للأجزاء المتغيرة. هذه هي الطريقة التي تتوقف بها الأوامر عن كونها نصاً عشوائياً وتتحول إلى أصول مُصدَرة (versioned) يمكن اختبارها، وهي القصة التي سنرويها في قسم خط الإنتاج أدناه. ملفات قواعد المشروع القابلة لإعادة الاستخدام، مثل cursor rules التي يحتفظ بها المطورون في مستودعاتهم، ليست سوى قوالب أوامر حية باسم آخر.

10. Meta-Prompting

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

أي تقنيات جعلتها reasoning models اختيارية (أو معطوبة)؟

أربع عادات كانت تُعدّ نصيحة جيدة أصبحت الآن ترتد عكسياً على reasoning models مثل سلسلة o من OpenAI وGPT-5 وأوضاع التفكير في Claude: فرض chain-of-thought صراحة، تكديس few-shot ثقيل كخيار افتراضي، تعبئة الرد المسبقة (response prefilling)، والضبط اليدوي لـbudget_tokens. فreasoning models تفكّر داخلياً بالفعل، لذا كتابة الخطوات نصياً تصبح زائدة، بل وأسوأ من زائدة أحياناً.

كل واحدة منها ماتت لسبب مختلف.

فرض chain-of-thought. أفضل ممارسات الاستدلال من OpenAI واضحة وحاسمة: "تجنّب أوامر سلسلة التفكير"، لأن هذه النماذج تفكّر داخلياً، وبالتالي فإن مطالبتها بـ"think step by step" أمر "غير ضروري" وقد "لا يحسّن الأداء (بل قد يعيقه أحياناً)." ورقة arXiv البحثية 2410.21333 وضعت رقماً لهذا الضرر: انخفاض في الدقة المطلقة يصل إلى 36.3% لنموذج o1-preview مقارنة بـGPT-4o في مهمة يضر فيها التفكير المتعمد خطوة بخطوة فعلياً. ودراسة ثانية، 2412.21187، تُظهر أن reasoning models تُفرط في إنفاق الحوسبة على مسائل بسيطة. توقفنا نحن عن إضافة "think step by step" إلى أوامر reasoning models منذ أشهر، ولم يسوء شيء.

التلقين الانعكاسي بـfew-shot ثقيل. إرشاد OpenAI هو "أبقِ الأوامر بسيطة ومباشرة" و"جرّب zero shot أولاً، ثم few shot إذا لزم الأمر." تكديس الأمثلة بشكل افتراضي أصبح الآن يكلّفك tokens وقد يقيّد نموذجاً قادراً بالفعل. أضف الأمثلة عندما تساعد بشكل قابل للقياس، لا كطقس إحماء روتيني.

تعبئة الرد المسبقة (Response Prefilling). وضع كلمات في فم النموذج لفرض تنسيق معين كان حيلة قياسية سابقاً. على Claude 4.6+ وFable 5 وMythos 5، لم تعد أدوار المساعد المعبأة مسبقاً مدعومة وتُعيد خطأ 400، وفق أفضل ممارسات التلقين من Anthropic. استخدم structured outputs بدلاً منها، وهو ما يتناوله القسم التالي.

الضبط اليدوي الدقيق لـbudget_tokens. ضبط ميزانية tokens التفكير يدوياً أصبح مهملاً (deprecated) هو الآخر (خطأ 400 على Opus 4.7+ وأحدث). نماذج Anthropic تستخدم الآن تفكيراً تكيفياً (adaptive thinking)، وتوجّه الجهد عبر معامل effort بدلاً من كتابة رقم يدوياً. اتخذت OpenAI الخطوة نفسها: رسائل المطوّر (developer messages) هي رسائل النظام الجديدة، وجهد الاستدلال أصبح إعداداً قابلاً للضبط. الحيلة الكلاسيكية، "let's think step by step"، أصبحت الآن، على reasoning models، أحياناً هي ما يجعلها أسوأ.

كيف تحصل على JSON موثوق من LLM في 2026؟

structured outputs المقيدة بمخطط، لا التوسل داخل الأمر. في 2026 الطريق الموثوق هو أن تسلّم النموذج مخطط JSON وتجعل الـAPI يضمن مخرجاً صالحاً وفقه. كتابة "أرجو إرجاع JSON" داخل الأمر أسلوب هش؛ وحيلة التعبئة المسبقة المهملة اختفت تماماً. كل من OpenAI وAnthropic توفران ميزة structured outputs مخصصة لهذا الغرض بالذات.

لماذا "أرجو إرجاع JSON صالح" هشة إلى هذا الحد؟ لأنك تطلب من نظام احتمالي أن يكون دقيقاً نحوياً بشكل كامل اعتماداً على الثقة فقط. تعليق شارد واحد أو فاصلة زائدة في النهاية تكفي لتعطيل المُحلِّل (parser) لديك. Structured Outputs تحلّ هذا على مستوى الـAPI: تُمرّر مخططاً، ويُقيَّد النموذج بمطابقته. وتشير Anthropic إلى أن النماذج الأحدث "يمكنها مطابقة مخططات معقدة بموثوقية عند توجيهها لذلك."

إليك مخطط استجابة صغيراً وواقعياً لمصنّف تذاكر الدعم:

{
  "name": "ticket_classification",
  "schema": {
    "type": "object",
    "properties": {
      "category": { "type": "string", "enum": ["billing", "technical", "account"] },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "summary": { "type": "string", "maxLength": 120 }
    },
    "required": ["category", "priority", "summary"],
    "additionalProperties": false
  }
}

مرّر هذا إلى structured outputs الخاصة بـOpenAI أو Anthropic وستحصل على JSON قابل للتحليل في كل مرة، دون أي حلقة إعادة محاولة. وللاطلاع على النمط الكامل عبر مختلف المزودين، بما في ذلك التحقق عبر Pydantic وZod، راجع دليلنا حول الحصول على JSON موثوق من أي LLM. في 2026 أنت لا تطلب من النموذج JSON. أنت تقيّده بمخطط وتتوقف عن الأمل.

Meta-Prompting: دع النموذج يكتب أمرك

Meta-prompting يعني استخدام LLM لصياغة أو تحسين الأمر الذي ستشغّله فعلياً. إنها أسرع طريق من فكرة أولية إلى أمر عملي، والأدوات مدمجة فعلاً: كل من محسّن الأوامر (prompt improver) من Anthropic ومحسّن الأوامر (prompt optimizer) من OpenAI يعيدان صياغة مسودتك وفق أفضل الممارسات. ابدأ من نسخة الآلة، ثم عدّلها يدوياً.

هل تساعد فعلياً، أم أنها مجرد خدعة استعراضية؟ أجرت Anthropic أرقامها الخاصة: محسّن الأوامر الخاص بها حقق مكسباً في الدقة بنسبة 30% في اختبار تصنيف متعدد التصنيفات، والتزاماً بنسبة 100% بعدد الكلمات في مهمة تلخيص، بحسب تقريرهم الرسمي. ومحسّن الأوامر من OpenAI يؤدي المهمة ذاتها.

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

ورقة غش للتلقين حسب النموذج (OpenAI مقابل Anthropic مقابل Google)

المهمة واحدة، لكن اللهجات ثلاث. OpenAI تريد رسائل المطوّر ودون فرض chain-of-thought. Anthropic تريد وسوم XML، وتفكيراً تكيفياً، ومعامل effort. Gemini من Google تريد ميزانية تفكير (thinking budget). reasoning models هي مخططوك الاستراتيجيون؛ والنماذج التقليدية من طراز GPT هي خيول العمل لديك. طابق التقنية مع الفئة.

الفروق صغيرة لكنها مؤثرة. في OpenAI، حلّت رسائل المطوّر محل رسالة النظام القديمة بدءاً من سلسلة o وما بعدها، وتوجّهك الوثائق بعيداً عن CoT الصريح. في Anthropic، ما زالت وسوم XML الطريقة الموصى بها لهيكلة أمر معقد، والتفكير تكيفي بشكل افتراضي. ملفات الأوامر على مستوى المشروع، مثل ملفات CLAUDE.md التي تحتفظ بها فرق البرمجة في مستودعاتها، تحمل الكثير من هذا الربط الخاص بكل مزود. في Gemini، تسلّم النموذج ميزانية تفكير.

من الأمر إلى خط الإنتاج: القوالب والإصدارات والتقييم

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

إليك كيف يبدو هذا في نظام حقيقي. هذه المدونة تعمل على خط إنتاج محتوى مدعوم بـClaude يضم 17 وكيلاً فرعياً متخصصاً، كل واحد منها دور له أمر منفصل خاص به: باحث، ومنشئ ملخص، وكاتب محتوى، ومدقّق، ومترجم لغوي، وناشر Sanity، ومعالج صور، وغيرها. وعبر ثلاث من هذه المراحل، وهي الملخص والكاتب والمدقّق، نفرض 8 قواعد حماية لمقاومة الكشف. يفحص المدقّق كل مسودة مقابل قائمة حظر لغوي من 52 عبارة، وأي إصابة واحدة تمنع النشر، مدعومة بسكربت فحص لغوي منفصل. شحن خط الإنتاج هذا نحو 194 مقالاً بالإنجليزية عبر 4 مواقع، تُرجم كل واحد منها إلى ما يصل إلى 10 لغات عبر وكلاء متوازيين لكل لغة.

لم يأتِ أي من هذا من صياغة ذكية. بل جاء من التعامل مع الأوامر بوصفها أصولاً مُصدَرة ومحمية ببوابة تقييم، وحادثتان علّمتانا السبب.

الحادثة الأولى كانت خللاً في علامات التشكيل الخاصة بالأبجديات (diacritics). كان أمر الترجمة لدينا يُعيد أحياناً ASCII بدلاً من Unicode، فكانت الكلمة التركية "karşılaştırma" تعود إلينا بصورة "karsilastirma". خلل صامت وقبيح ويسهل تفويته على نطاق واسع. لم يكن الحل جملة أفضل، بل تعليمة أكثر صرامة إضافة إلى بوابة grep تحسب الأحرف الأصلية للغة وتُعيد تشغيل الترجمة تلقائياً إذا وصل العدد إلى صفر. اختبار ارتداد، على أمر.

الحادثة الثانية كانت أسوأ. بدأ أمر إعادة الترجمة يُنتج معرّفات (slugs) محلية مختلفة قليلاً في كل مرة، فأنشأ الناشر مستنداً جديداً تماماً بينما بقي القديم منشوراً حياً. أنتج ذلك 54 مستنداً منشوراً مكرراً، وهو ما فعّل استثناءات التكرار في Google Search Console. كان الحل قاعدة حماية داخل الأمر تفرض إعادة استخدام المعرّف الحالي، إضافة إلى قاعدة "تحقق قبل الإنشاء" في الناشر.

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

أخطاء شائعة في Prompt Engineering (وحلول 2026 لها)

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

راجع القائمة وكن صادقاً بشأن أي منها ترتكبه فعلاً:

• تعليمات غامضة. عبارة "اجعله أفضل" لا تمنح النموذج أي هدف يصوّب نحوه. حدّد ما تعنيه كلمة "أفضل": أقصر، أكثر ودّية، JSON صالح، أقل من 120 كلمة.
• الإفراط في توجيه reasoning models خطوة بخطوة. فرض "think step by step" على نموذج من سلسلة o أو نموذج تفكير هو الخطأ الذي تناولناه أعلاه. دعه يستدل بنفسه؛ ارفع effort بدلاً من ذلك.
• غياب حلقة تقييم. إن لم تستطع معرفة إن كان تغيير الأمر قد ساعد أو أضر، فأنت تخمّن فقط. أضف حالات اختبار وفحص نجاح/فشل.
• تجاهل السلوك الخاص بكل نموذج. الأمر الذي يبدع على GPT-5 قد يحتاج وسوم XML على Claude. راجع ورقة الغش أعلاه.
• حشو الأمر. إقحام المزيد في تعليمة واحدة بينما الفجوة الحقيقية في الاسترجاع أو الذاكرة يعني أنك كنت تحتاج هندسة السياق (context engineering)، لا أمراً أطول.
• الثقة بمدخلات غير موثوقة. محتوى المستخدم والمستندات المسترجَعة قد تحمل تعليمات مخفية. أضف guardrails حولها؛ ومقالنا التفصيلي القادم عن منع حقن الأوامر (prompt injection prevention) يغطي الجانب الأمني بالكامل.

أغلى خطأ في الأوامر خلال 2026 ليس خطأ إملائياً. إنه الشحن دون تقييم كان كفيلاً باكتشاف التراجع.

هل ماتت Prompt Engineering؟ إجابة صريحة لعام 2026

لا. Prompt Engineering لم تمت، بل انقسمت إلى شقين. التلقين العفوي أصبح أسهل لأن النماذج أصبحت أذكى وأكثر تسامحاً. أما التلقين الإنتاجي فأصبح أصعب، لأن الموثوقية وstructured outputs والتقييم أصبحت الآن أهم من الصياغة الذكية. كلمة "هندسة" أصبحت أخيراً تعني ما تقوله فعلاً.

فلماذا إذن يواصل الجميع إعلان موتها؟ لأن النصف المرئي، وهو كتابة طلب داخل ChatGPT، أصبح فعلاً بديهياً. أما النصف الذي لم يصبح أسهل، وهو شحن أمر يصمد عبر آلاف الاستدعاءات وعشر لغات، فلا يصنع عناوين. المهارة الحقيقية في 2026 ليست عبارة سحرية. إنها التقييم، واختيار فئة النموذج (مخطط استراتيجي مقابل خيل عمل)، ومعرفة متى تكون المشكلة قد تجاوزت حجم الأمر وأصبحت هندسة سياق. النصف السهل أصبح أسهل والنصف الصعب أصبح أصعب، وواحد منهما فقط هو من يصنع العناوين.

إن كان هناك درس واحد يُستخلص: 10 تقنيات ما زالت تستحق مكانها، و4 عادات قديمة تكلّفك الآن على reasoning models، والتقييم هو المهارة التي تفصل بين عرض تجريبي ومنتج حقيقي. هل تبني شيئاً يجب أن تصمد فيه الأوامر في بيئة الإنتاج؟ احصل على استشارة مجانية وسنساعدك على إعداد حلقة التقييم أولاً.

عن الكاتب

Mert Batur هو الشريك المؤسس لـTechsy.io، حيث يبني الفريق وكلاء ذكاء اصطناعي وأنظمة أتمتة وخطوط إنتاج صوتية لتوليد العملاء (voice/SDR) لعملاء B2B. يكتب عن مجموعة أدوات LLM التي يستخدمها فريق Techsy فعلياً في بيئة الإنتاج.

المؤهلات: الشريك المؤسس، Techsy.io. تواصل مع Mert عبر LinkedIn.

الأسئلة الشائعة

ما هي Prompt Engineering في سياق الذكاء الاصطناعي التوليدي؟

Prompt Engineering هي ممارسة تصميم وصقل التعليمات التي تقدّمها لنموذج لغة كبير للحصول على مخرجات دقيقة وذات صلة. تشمل تقنيات مثل zero-shot وfew-shot وchain-of-thought وتلقين الدور. في 2026 تنقسم إلى تلقين محادثة عفوي وتلقين إنتاجي صارم داخل نظام.

هل ماتت Prompt Engineering في 2026؟

لا، لم تمت Prompt Engineering في 2026، بل انقسمت. التلقين العفوي أصبح أسهل مع ازدياد تسامح النماذج. أما التلقين الإنتاجي فأصبح أكثر صرامة، لأن structured outputs والتقييم والموثوقية أصبحت الآن أهم من الصياغة الذكية. المهارة لم تختفِ؛ النصف السهل فقط توقف عن الحاجة إليك.

ما الفرق بين Prompt Engineering وهندسة السياق (Context Engineering)؟

Prompt Engineering تصوغ التعليمة؛ وهندسة السياق تصمم كل شيء آخر داخل نافذة السياق: الاسترجاع، والذاكرة، والأدوات، والترتيب. Prompt Engineering هي مجموعة جزئية من هندسة السياق. تحتاج هندسة السياق بمجرد أن تبدأ مدخلاتك بالتغير مع كل طلب، كما في الوكلاء وأنظمة RAG.

هل ما زلت تحتاج chain-of-thought مع reasoning models؟

غالباً لا. على reasoning models مثل سلسلة o من OpenAI وGPT-5 وأوضاع التفكير في Claude، يصبح فرض "think step by step" زائداً لأنها تستدل داخلياً، وتقول OpenAI إن ذلك قد يضر بالأداء. لا يزال chain-of-thought مفيداً على النماذج التقليدية من طراز GPT، لذا طابق التقنية مع الفئة.

هل تتطلب Prompt Engineering برمجة؟

لا، ليس للبدء. يستطيع أي شخص كتابة تعليمات واضحة والحصول على إجابات أفضل من ChatGPT أو Claude. لكن Prompt Engineering الإنتاجية، بتصدير الأوامر وربط structured outputs وبناء حلقات تقييم، هي تخصص خاص بالمطورين. النصف العفوي لا يحتاج أي كود؛ أما النصف الاحترافي فيحتاج ذلك فعلاً.

ما الفرق بين zero-shot وfew-shot؟

zero-shot يعطي تعليمة واضحة دون أي أمثلة؛ وfew-shot يُدرج من مثالين إلى خمسة أمثلة لتوجيه تنسيق المخرجات أو سلوكها. في نماذج 2026، ابدأ بـzero-shot لأنها تتبع التعليمات جيداً، وأضف few-shot فقط عندما تحسّن الأمثلة النتائج بشكل قابل للقياس. few-shot هو الحل الاحتياطي، لا الخيار الافتراضي.

كيف أجعل LLM يُرجع JSON بموثوقية؟

استخدم structured outputs المقيدة بمخطط، لا التوسل داخل الأمر. بدلاً من كتابة "أرجو إرجاع JSON"، مرّر مخطط JSON عبر ميزة Structured Outputs الخاصة بـOpenAI أو Anthropic، والتي تقيّد النموذج بمخرج صالح وقابل للتحليل. حيلة التعبئة المسبقة القديمة أصبحت الآن تُعيد خطأ 400 على نماذج Claude الأحدث.

ما هو Meta-Prompting؟

Meta-Prompting هو استخدام نموذج لصياغة أو تحسين الأمر الذي ستشغّله. أدوات مثل محسّن الأوامر (prompt improver) من Anthropic ومحسّن الأوامر (prompt optimizer) من OpenAI تعيد صياغة مسودتك وفق أفضل الممارسات؛ وقاست Anthropic مكسباً في الدقة بنسبة 30% في أحد الاختبارات. أنتج مسودة أولى، ثم عدّلها يدوياً لتناسب بياناتك.

هل Prompt Engineering مهنة أو وظيفة حقيقية؟

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

كيف يختلف التلقين بين ChatGPT وClaude وGemini؟

المهمة واحدة؛ لكن اللهجة تختلف. OpenAI تستخدم رسائل المطوّر وتوجّهك بعيداً عن chain-of-thought الصريح على reasoning models. Claude من Anthropic تفضّل وسوم XML، والتفكير التكيفي، ومعامل effort. Gemini من Google تستخدم ميزانية تفكير. reasoning models هي مخططات استراتيجية؛ والنماذج التقليدية من طراز GPT هي خيول عمل.

المصادر

• OpenAI: Reasoning best practices
• OpenAI: Structured Outputs
• OpenAI: Prompt optimizer
• Anthropic: Claude prompting best practices
• Anthropic: Structured Outputs
• Anthropic: Prompt improver (docs)
• Anthropic: Prompt improver announcement
• arXiv 2410.21333: Mind Your Step (by Step)
• arXiv 2412.21187: Do NOT Think That Much for 2+3?
• arXiv 2406.06608: The Prompt Report
• Prompt Engineering Guide (dair-ai)