7 أمثلة System Prompt لتطبيقات الإنتاج (قوالب 2026 جاهزة للنسخ)

أفضل أمثلة system prompt ليست جمل "أنت مساعد مفيد" التعليمية القصيرة من الدروس التمهيدية. إنها كتل التعليمات المحددة التي تمنع تطبيق الإنتاج من الانهيار في الساعة 2 صباحاً. في خط إنتاج المحتوى الخاص بنا، نُشغّل أكثر من اثني عشر وكيلاً فرعياً (subagent) لـ Claude، كل واحد منها يُوجَّه بواسطة system prompt أعدنا كتابته مراراً بعد أن تسبب في خلل مع Claude Opus 4.8 أو GPT-5. يتخطى هذا المقال العروض التوضيحية الشكلية. ستحصل على 7 system prompts حقيقية جاهزة للنسخ، اثنان منها مأخوذان مباشرة من ذلك الخط الإنتاجي، بالإضافة إلى تشريح اللبنات الست التي يقوم عليها كل system prompt موثوق.

أهم النقاط

• system prompt هو مجموعة تعليمات دائمة (الدور، القيود، شكل المخرجات، ضوابط الحماية) تُضبط مرة واحدة قبل أي رسالة من المستخدم.
• إن كان المحتوى متطابقاً عبر 1,000 طلب، ضعه في system prompt؛ أما المحتوى الخاص بكل طلب فمكانه في دور المستخدم (user turn).
• ست لبنات تبني prompt موثوقاً: الدور، السياق، القيود، شكل المخرجات، ضوابط الحماية، الأمثلة.
• نماذج الاستدلال (سلسلة o، GPT-5، Claude Opus 4.5+) تريد أهدافاً عالية المستوى، لا صياغة "يجب عليك" (you MUST) الحادة.

من ماذا يتكوّن system prompt؟ اللبنات الست الأساسية

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

إليك ما تفعله كل لبنة.

لبنة الدور أهم مما تبدو عليه. توثيق Anthropic يقولها بوضوح: تحديد دور في system prompt يركّز سلوك النموذج ونبرته، و"حتى جملة واحدة تُحدث فرقاً". أما لبنة ضوابط الحماية، فقواعد الرفض والسلامة تستحق تفكيراً حقيقياً؛ نتعمق فيها في دليل ضوابط الحماية لدينا. وإن كنت تُوصّل Claude، توصي Anthropic باستخدام وسوم XML (<instructions>، <context>، <input>) للفصل بين كل نوع من المحتوى حتى لا يخلط النموذج بينها.

إليك هيكلاً جاهزاً للصق يجمع اللبنات الست كلها في قالب واحد:

# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.

# CONTEXT
{Stable facts the model needs on every request.}

# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.

# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}

# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.

# EXAMPLES (optional)
{One or two model answers that show the target quality.}

ست لبنات تُحوّل شعوراً غامضاً إلى مواصفة دقيقة. وهذا يخص طبقة system prompt فقط. أما التقنيات الأوسع (few-shot، chain-of-thought، تسلسل الأوامر)، فراجع دليل هندسة الأوامر لدينا، وأبقِها خارج system prompt نفسه. كذلك يختلف system prompt الخاص بالجلسة عن ملف على مستوى المستودع من تعليمات دائمة على مستوى المشروع مثل CLAUDE.md، الذي يحكم قاعدة الكود بأكملها لا جلسة واحدة عبر API.

7 أمثلة system prompt جاهزة للإنتاج (جاهزة للنسخ واللصق)

إليك 7 أمثلة system prompt يمكنك لصقها في معامل system أو رسالة developer اليوم. يستهدف كل مثال مهمة حقيقية (وكيل، RAG، دعم، برمجة، JSON، مراقبة جودة المحتوى، ترجمة)، ويوضح كل واحد سبب وجود لبناته الأساسية. آخر مثالين يعملان فعلياً في خط إنتاجنا. المستودعات التي تسرّب أوامر Cursor وDevin تثبت وجود الطلب؛ لكن ما لا يقدّمه أحد هو الشرح الذي يوضح سبب وجود كل لبنة.

1. الوكيل المستقل (Autonomous Agent)

حدّد الدور بدقة، ووضّح قواعد الأدوات، وامنحه شرط توقف حتى لا يدخل في حلقة لا نهائية.

You are a research agent. Your only job is to answer the user's
question using the provided tools.

TOOLS: web_search, read_url, calculator.

RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.

STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
  human and explain why.

لماذا ينجح: الدور الضيق مع شرط توقف صريح هو الفارق بين وكيل يُنهي عمله ووكيل يستهلك التوكنات في حلقة لا نهائية. هذا هو جوهر أفضل ممارسات system prompt الجيدة للوكلاء.

2. RAG / الإجابة عبر الاسترجاع

اللعبة كلها في RAG هي منع النموذج من الإجابة اعتماداً على ذاكرته الخاصة. قاعدة واحدة تكفي لتحقيق ذلك.

You answer questions using ONLY the context provided below.

CONTEXT
{retrieved_chunks}

RULES
- If the answer is not in the context, say: "I don't have that
  in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].

OUTPUT
Two to four sentences, plain text, with citations.

لماذا ينجح: "فقط من السياق" مع صيغة استشهاد هو أرخص حارس ضد الهلوسة يمكنك كتابته في system prompt لـ RAG.

3. روبوت دعم العملاء

النبرة، ومسار التصعيد، وقاعدة صارمة تتعلق بالمال، كلها تُبقي روبوت الدعم مفيداً دون أن يَعِد بأشياء لا يستطيع الوفاء بها.

You are a support agent for Northwind's billing team. Be warm,
brief, and factual.

CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.

CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.

GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
  human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.

لماذا ينجح: ضابط الحماية الخاص بالاسترداد والبديل الاحتياطي للتصعيد يوقفان نمطي الفشل اللذين يتسببان في سحب روبوتات الدعم من الإنتاج.

4. مساعد البرمجة

قيّد شكل المخرجات والإصدارات، واجعله يشرح قبل أن يُعدّل أي كود.

You are a coding assistant for a Next.js 15 + TypeScript codebase.

RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.

If a request is ambiguous, ask one clarifying question before editing.

لماذا ينجح: "diff لا ملفات كاملة" مع سقف إصدار يُبقي المساعد داخل حدود مكدّسك التقني. تصميم prompt لوكلاء البرمجة موضوع عميق يستحق دليلاً مستقلاً، لذا أبقينا هذا المثال مختصراً.

5. استخراج بيانات منظّمة / JSON

ضع المخطط (schema) داخل لبنة شكل المخرجات وامنع أي نثر. هذا هو النمط الموثوق لـ structured outputs.

You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.

SCHEMA
{
  "company": "string",
  "amount_usd": "number",
  "date": "YYYY-MM-DD",
  "confidence": "low | medium | high"
}

RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.

لماذا ينجح: مخطط حرفي مع عبارة "JSON صالح فقط" يتفوق دائماً على وصف الشكل بالكلمات. للاطلاع على أنماط الإنفاذ خارج الـ prompt (التحقق من مخطط JSON، الاستخراج القائم على الأدوات)، راجع دليل المخرجات المنظّمة لدينا.

6. وكيل مراقبة جودة المحتوى / Validator (من خط إنتاجنا الفعلي)

هذا المثال يعمل فعلياً في مكدّسنا. system prompt الخاص بوكيل التحقق (validator) لدينا هو مثال على القيود السلبية: يخبر النموذج بالضبط بما لا يجب أن يكتبه، ثم يتحقق سكريبت من القواعد حرفياً.

You are a content QA agent. You check one blog draft against a
fixed style contract.

BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"

FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
  per 500 words of body.

ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
  exits non-zero on any hit. If it fails, the post does not publish.

لماذا ينجح: قائمة حظر مُعدَّدة صراحة مع grep قابلة للإنفاذ بطريقة لا تستطيعها عبارة "تجنّب الكلمات الرنّانة" أبداً. يستطيع النموذج أن يجادل شعوراً غامضاً، لكنه لا يستطيع أن يجادل رمز خروج (exit code) غير صفري.

7. وكيل الترجمة (من خط إنتاجنا الفعلي)

هذا أيضاً من عندنا. prompt وكيل الترجمة هو عقد بشأن شكل المخرجات واكتمالها، مع فحص ذاتي يُجريه النموذج على مخرجاته الخاصة.

You are an expert translator. You translate ONE blog post into ONE
target language.

COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.

DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
  "karşılaştırma" (Turkish), or "developpement" instead of
  "développement" (French), the translation is WRONG. Re-do it.

If you cannot meet the contract, report the problem. Do not ship a
truncated post.

لماذا ينجح: عقد اكتمال مع مثال ملموس على مخرَج خاطئ يلتقط الإخفاقات الصامتة التي تمر عبر عبارة غامضة مثل "ترجم بدقة".

ما تعلّمناه من تشغيل system prompts في الإنتاج

ثلاثة أخطاء (bugs) في system prompt داخل خط إنتاجنا علّمتنا أكثر مما تعلّمنا من أي صفحة توثيق. جاءت الأخطاء الثلاثة كلها من تعليمات بدت سليمة لكنها لم تكن محددة أو قابلة للتحقق. إليك ما تعطّل عبر أكثر من 16 وكيلاً فرعياً (subagent) لـ Claude لدينا، والإصلاح الدقيق الذي ثبت في كل مرة. النمط نفسه يتكرر دائماً: القواعد الناعمة يتم تجاهلها، أما القواعد المحددة والمُتحقَّق منها خارجياً فتثبت.

خطأ المفردات المحظورة. لأسابيع، ظل النموذج يُعيد تسريب leverage وrobust إلى المسودات مهما طلبنا منه بلطف. سطر ناعم مثل "تجنّب الكلمات الرنّانة" لم يُجدِ نفعاً. كان الحل هو المثال رقم 6: قائمة حظر مُعدَّدة صراحة داخل الـ prompt، مع سكريبت يفحص المخرجات بـ grep ويُنهي التنفيذ برمز غير صفري عند أي مخالفة، إلى جانب سقف لعلامات الشرطة الطويلة (em-dash) عند 3 لكل 1,000 كلمة. الدرس: القيود الغامضة يتم تجاهلها؛ أما القيود المُعدَّدة والمُتحقَّق منها خارجياً فتثبت.

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

خطأ المعرّف الثابت (stable ID). هذا هو الخطأ المكلف. كان system prompt يُعيد اشتقاق slug مُعرَّب في كل عملية إعادة ترجمة، مما جعل الناشر يصكّ مستنداً ثانياً منشوراً لكل مقال. أطلقنا 54 مستنداً منشوراً مكرراً في 2026-06-13 ولم نُلغِ نشرها حتى 2026-07-05، أي ثلاثة أسابيع من تشتت قيمة الروابط وعلامات المحتوى المكرر. الإصلاح: تثبيت الهوية صراحة وإعادة استخدام المعرّف الحالي حرفياً. system prompt يُعيد توليد معرّفاته الخاصة بشكل غير حتمي يُنتج نسخاً مكررة؛ صكّ نموذجنا 54 مستنداً منشوراً قبل أن نُثبّت المعرّف.

ما أكثر أخطاء system prompt شيوعاً؟

أكثر أخطاء system prompt شيوعاً هي: تعليمات على شكل جدار من النص، قواعد متناقضة، صياغة سلبية فقط، إقحام سياق خاص بكل طلب داخل prompt ثابت، وتفويت بديل احتياطي (fallback). وعلى نماذج 2026 يظهر خطأ جديد: الأحرف الكبيرة الحادة وصياغة "يجب أن" (you MUST) باتت تُفرط في تحفيز Claude Opus 4.5+.

إليك قائمة الإصلاح السريعة:

• جدار من النص. الإصلاح: قسّمه إلى اللبنات الست وضع المحتوى الثابت أولاً.
• تعليمات متناقضة. الإصلاح: قاعدة واحدة لكل سطر؛ حلّ التعارضات قبل النشر.
• صياغة سلبية فقط. الإصلاح: قل ما يجب فعله، لا ما يجب تجنبه فقط.
• الإفراط في الأحرف الكبيرة و"MUST". على نماذج Anthropic الأحدث، هذا يأتي بنتيجة عكسية. يقول توثيقها الآن إنه بدلاً من كتابة "CRITICAL: You MUST use this tool"، يمكنك استخدام صياغة عادية مثل "استخدم هذه الأداة عندما". نصيحة 2025 أصبحت هي الخطأ اليوم.
• سياق ديناميكي داخل prompt ثابت. أبقِ بيانات كل طلب في دور المستخدم. تحديد ما يذهب إلى أين انضباط قائم بذاته؛ يغطيه دليل هندسة السياق لدينا.
• غياب بديل احتياطي. حدّد دائماً مسار رفض ومسار تصعيد.
• تجاهل الطول والتكلفة. الـ prompts الأطول تضيف زمن استجابة وتكلفة توكنات في كل استدعاء؛ اختصر إلى ما يستحق مكانه فعلاً.

لأساسيات وضوح التعليمات البسيطة، لا يزال مقال أفضل الممارسات من OpenAI قائمة تحقق (checklist) متينة.

كيف تختبر system prompt وتُحسّنه تكرارياً؟

اختبر system prompt بالطريقة نفسها التي تختبر بها الكود. ابنِ مجموعة ذهبية (golden set) صغيرة من المدخلات مع المخرجات المتوقعة، ثم تحقق (assert) من استجابة النموذج مقابلها عند كل تغيير. اختبر A/B لنسختين من الـ prompt على المدخلات نفسها واحتفظ بالنسخة التي تجتاز فحوصات أكثر. التحقق البرمجي يتفوق دائماً على النظر بالعين.

إليك شكل حلقة تقييم (eval loop) بسيطة:

# pseudo eval loop
for case in golden_set:
    out = model(system=PROMPT, user=case.input)
    assert is_valid_json(out)              # format check
    assert case.expected_field in out      # content check
    if case.no_context:
        assert "I don't have that" in out  # refusal check
# ship the prompt version that passes the most cases

grep في المثال رقم 6 هو أرخص تحقق يمكنك تشغيله: لا يكلّف شيئاً ولا يتعب أبداً. مع نمو مكتبة prompts لديك عن حفنة قليلة، أرشِف وأصدِر نسخاً (version) واختبر prompts لديك بأدوات حقيقية مثل أفضل أدوات إدارة البرومبت بدلاً من النسخ واللصق بين الملفات. الفكرة نفسها في أي مقياس: لا تُغيّر أبداً prompt إنتاجياً دون فحص يخبرك إن كنت قد حسّنته أم أفسدته.

system prompt مقابل user prompt مقابل developer message

system prompt يضبط سلوكاً ثابتاً؛ user prompt يحمل المهمة الخاصة بكل طلب؛ أما developer message فهو دور نماذج الاستدلال من OpenAI الذي يحمل تعليمات على مستوى التطبيق، ويُصنَّف فوق رسائل المستخدم في سلسلة القيادة. تستخدم Anthropic معامل system على المستوى الأعلى بدلاً من رسالة role: "system". إليك التقسيم الثلاثي الذي تُخطئه المنافسة عادة.

تُصرّح OpenAI بوضوح عن هذا الترتيب: "رسائل developer هي تعليمات يوفرها مطوّر التطبيق، وتُعطى أولوية فوق رسائل المستخدم". لذا إن حاول مستخدم تجاوز قواعد تطبيقك، تفوز رسالة developer في سلسلة القيادة.

هل تحتاج نماذج الاستدلال إلى system prompts مختلفة؟ (2026)

نعم. نماذج الاستدلال مثل سلسلة o من OpenAI وGPT-5 وClaude Opus 4.5+ تريد أهدافاً عالية المستوى، لا نصوصاً خطوة بخطوة. تُشبّه OpenAI نموذج الاستدلال بزميل عمل أول تثق بتفاصيل عمله، مقابل نموذج GPT الذي يتصرف كموظف مبتدئ يحتاج إلى تعليمات صريحة.

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

لجانب Claude تحوّله الخاص في 2026. بما أن Opus 4.5+ أكثر استجابة لـ system prompt، فإن العادة القديمة في تكديس CRITICAL: وMUST باتت تُفرط في تحفيزه الآن. خفّض حدّة تلك الصياغة إلى لغة عادية. ملاحظة تتعلق بالتكلفة: ضع المحتوى الثابت والمُعاد استخدامه في بداية الـ prompt حتى يعمل التخزين المؤقت للـ prompt (prompt caching) ويُقلّل زمن الاستجابة في الاستدعاءات المتكررة. وإن كان نموذج الاستدلال لديك يقوم بعمل خطوة بخطوة، فإن chain-of-thought prompting موضوع مستقل له دليله الخاص، ولن نُعيد شرحه هنا.

كيف تتعامل Techsy مع هذا

في Techsy، نبني أنظمة وكلاء لعملاء B2B، وprompts وكيلَي التحقق والترجمة أعلاه تعمل فعلياً في ذلك الخط الإنتاجي. نتعامل مع كل system prompt كأنه كود: نُصدر له نسخاً (version)، ونختبره مقابل مجموعة ذهبية، ونفرض القواعد غير القابلة للتفاوض بسكريبت لا بالأمل. إن كنت تنقل ميزة LLM من عرض تجريبي إلى الإنتاج وتريد مساعدة في عمل تكامل الذكاء الاصطناعي، احصل على استشارة مجانية.

عن الكاتب

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

الشريك المؤسس، Techsy.io · LinkedIn

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

ما هو system prompt؟

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

ما الفرق بين system prompt وuser prompt؟

system prompt هو "كيفية التصرف" الثابتة، المتطابقة عبر كل طلب؛ أما user prompt فهو "ماذا يجب أن يفعل" الخاص بكل طلب. قاعدة بسيطة: إن كان المحتوى سيتطابق عبر 1,000 طلب، فمكانه في system prompt، وأي شيء يتغير مع كل استدعاء يذهب إلى دور المستخدم.

ما developer message مقابل system prompt؟

تأخذ نماذج الاستدلال من OpenAI (سلسلة o، GPT-5) رسالة developer بدلاً من رسالة system. وهي تحمل تعليمات على مستوى التطبيق تُصنَّف فوق رسائل المستخدم في سلسلة القيادة، فتفوز إن حاول مستخدم تجاوز قواعدك. تحتفظ Anthropic بمعامل system واحد على المستوى الأعلى بدلاً من رسالة قائمة على role.

كم يجب أن يكون طول system prompt؟

بأقصر ما يمكن مع تغطية الدور والقيود وشكل المخرجات وضوابط الحماية. الـ prompts الطويلة جداً تضيف تكلفة توكنات وزمن استجابة في كل استدعاء، وقد تُفرط في تحفيز استدلال إضافي على Claude Opus 4.5+. إن كان لا بد أن يكون prompt الثابت طويلاً، ضع المحتوى المُعاد استخدامه أولاً حتى يُعوّض التخزين المؤقت للـ prompt التكلفة.

هل تعمل system prompts بالطريقة نفسها في ChatGPT/GPT وClaude؟

المفهوم نفسه، لكن الآليات تختلف. تستخدم OpenAI دور system أو developer داخل مصفوفة الرسائل، بينما تستخدم Anthropic معامل system منفصلاً على المستوى الأعلى وتُفضّل وسوم XML للفصل بين التعليمات والسياق والأمثلة. التعليمات تنتقل بين المزوّدَين، أما آلية التوصيل واصطلاحات التنسيق فلا.

هل يمكنك تغيير system prompt في منتصف المحادثة؟

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

هل أستخدم وسوم XML أم Markdown في system prompt؟

توصي Anthropic باستخدام وسوم XML مع Claude للفصل بين التعليمات والسياق والأمثلة حتى لا يخلط النموذج بينها. أما نماذج OpenAI فتتعامل جيداً مع Markdown والعناوين البسيطة. طابِق اصطلاح المزوّد بدلاً من فرض أسلوب واحد على كليهما، وحافظ على الاتساق داخل الـ prompt الواحد أياً كان اختيارك.

هل تحتاج نماذج الاستدلال إلى system prompts مختلفة؟

نعم. نماذج الاستدلال تريد أهدافاً عالية المستوى، أشبه بإحاطة زميل عمل أول، لا إدارة دقيقة خطوة بخطوة. تخلَّ عن الأحرف الكبيرة الحادة وصياغة "يجب أن" (you MUST) التي تُفرط في تحفيز النماذج الأحدث مثل Claude Opus 4.5+، واذكر الهدف وضوابط الحماية، ودع النموذج يخطط طريقه للوصول إليه.

ما هي مكوّنات system prompt الجيد؟

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