موجّه النظام (System Prompt) هو الوصف الوظيفي الذي يقرؤه وكيل الذكاء الاصطناعي قبل كل محادثة. هو الذي يحدد ماذا يفعل الوكيل حين يكون الطلب غامضاً، وحين تتعارض قاعدتان، ومتى يتوقف ويسأل إنساناً. معظم الوكلاء الذين يخطئون في الاستخدام الفعلي لا يعانون من مشكلة في النموذج، بل من موجّه نظام غامض أو متناقض أو مزدحم. يلخّص هذا الدليل ما تنشره Anthropic وOpenAI اليوم عن كتابة موجّهات النظام للوكلاء، ويحوّله إلى قالب عملي، مع أداة فحص مُختبرة بلغة Python تكشف الأخطاء الشائعة قبل أن يكتشفها عملاؤك.
ما الذي تغيّر في 2026: من حيل الصياغة إلى هندسة السياق
كانت هندسة الأوامر في بداياتها تبحث عن عبارات سحرية. أما الإرشادات اليوم فأهدأ. تصف Anthropic موجّه النظام بأنه جزء من هندسة السياق: اختيار أصغر مجموعة مفيدة من المعلومات يراها النموذج في كل خطوة، إلى جانب تعريفات الأدوات والأمثلة وسجل المحادثة والبيانات المسترجعة. ونصيحتها أن تستهدف أقل قدر من المعلومات يصف السلوك المطلوب وصفاً كاملاً. والأقل لا يعني الأقصر، بل يعني أن كل سطر يستحق مكانه.
وتحذّر Anthropic من نمطين للفشل. الأول كتابة منطق جامد من نوع "إذا حدث كذا فافعل كذا" لكل حالة، وهو منطق ينكسر بمجرد أن يختلف الواقع. والثاني إرشادات عامة غامضة تفترض أن النموذج يعرف سياقاً لا يعرفه. والهدف هو "الارتفاع المناسب" بينهما: دقيق بما يكفي لتوجيه السلوك، ومرن بما يكفي ليترك للنموذج مساحة للتقدير. (إن كنت جديداً على كتابة الأوامر عموماً، فابدأ بـدليلنا لكتابة أوامر أفضل.)
تشريح موجّه نظام جيد للوكيل
توصي الشركتان بأقسام واضحة. وتقترح Anthropic استخدام وسوم XML أو عناوين Markdown حتى يميّز النموذج بين التعليمات والخلفية والبيانات. والبنية التي تناسب معظم وكلاء الأعمال من ستة أجزاء:
- الدور: جملة أو جملتان عن هوية الوكيل والغرض منه. عبارة "أنت تحجز المواعيد لعيادة أسنان" أفضل من "أنت مساعد مفيد".
- السياق: الحقائق التي يحتاجها الوكيل ولا يستطيع تخمينها: ساعات العمل، واللغات، ومن هم المستخدمون، وما شكل النتيجة الجيدة.
- الأدوات: متى تُستخدم كل أداة ومتى لا تُستخدم. وتلاحظ Anthropic أنه إذا لم يستطع مهندس بشري تحديد الأداة المناسبة لموقف ما، فلن يستطيع الوكيل أيضاً، لذا اجعل الأدوات قليلة وغير متداخلة. (المزيد في دليلنا عن استدعاء الأدوات بشكل موثوق.)
- القواعد: القيود، مع سبب كل قيد، وترتيب صريح لما يحدث عند تعارضها.
- التصعيد: متى بالضبط يتوقف الوكيل ويسلّم المحادثة لإنسان.
- شكل الرد: صيغة الردود وطولها ولغتها، موصوفة بما يجب فعله.
سبع قواعد من أدلة الشركات نفسها
1. اكتب لزميل ذكي لا يعرف شيئاً عن المشروع
اختبار Anthropic: لو أعطيت الموجّه لزميل كفء لا يعرف شيئاً عن مشروعك، هل سيعرف ماذا يفعل؟ إن كانت لديه أسئلة، فسيكون لدى النموذج أسئلة أيضاً. وضّح الجمهور والهدف ومعنى "انتهت المهمة".
2. اشرح السبب، لا المطلوب فقط
القاعدة المصحوبة بسبب تُعمَّم، والقاعدة المجرّدة لا. ومثال Anthropic نفسها: بدل أن تمنع علامات الحذف (...) فقط، أخبر النموذج أن رده سيُقرأ بصوت عالٍ عبر محرك تحويل النص إلى كلام لا يعرف كيف ينطقها. عندها يتجنب النموذج أشياء أخرى قد يتعثر فيها محرك الكلام أيضاً، دون أن تخبره بها.
3. أزل التناقضات، ورتّب ما يبقى
هذا أغلى خطأ. يحذّر دليل OpenAI لكتابة الأوامر لـGPT-5 من أن التعليمات المتناقضة أو الغامضة قد تضر نماذجها الأحدث القادرة على الاستدلال أكثر من النماذج الأقدم، لأن النموذج يستهلك جهده في محاولة التوفيق بين قاعدتين لا يمكن أن تصحّا معاً. ومثالها موجّه لجدولة مواعيد طبية يقول في موضع إنه لا يجوز الحجز دون موافقة صريحة من المريض، ويقول في موضع آخر إن الحالات العاجلة تُحجز لها تلقائياً أقرب مواعيد اليوم نفسه. ولم يكن الحل نموذجاً أذكى، بل إعادة كتابة القواعد بحيث تكون لإحداها أولوية واضحة، مع توضيح الاستثناء.
4. خفّف الأحرف الكبيرة والتهويل
عبارات مثل "CRITICAL: You MUST" كانت حلاً مؤقتاً لنماذج قديمة كانت تتجاهل التعليمات. أما إرشادات Anthropic الحالية فتقول إن النماذج الأحدث تتبع موجّه النظام بدقة، وإن التهويل صار يدفعها إلى المبالغة، فتطبّق القاعدة في مواضع لم تُقصد لها. استخدم لغة عادية وسبباً واضحاً بدلاً من ذلك.
5. قل ماذا يفعل، لا ما يتجنبه فقط
عبارة "ردّ في جملتين أو ثلاث قصيرة بلغة المريض" أفضل من "لا تكتب رسائل طويلة". التعليمات الإيجابية تعطي النموذج هدفاً، أما السلبية فتغلق باباً واحداً خاطئاً من أبواب كثيرة.
6. أعطه أمثلة جيدة قليلة
توصي Anthropic بثلاثة إلى خمسة أمثلة متنوعة ونموذجية، كل منها داخل وسومه الخاصة، بدل قائمة طويلة من الحالات الاستثنائية. واجعلها مختلفة عن بعضها، وإلا قلّد النموذج النمط الوحيد المشترك بينها.
7. حدّد درجة استقلالية الوكيل
يحتاج الوكيل إلى توجيه صريح عن متى يتصرف ومتى يسأل. يقترح توثيق Anthropic أن تسمح للنموذج بتنفيذ الإجراءات المحلية القابلة للتراجع بحرية، وأن يطلب التأكيد قبل أي شيء يصعب التراجع عنه، مثل حذف البيانات أو إرسال الرسائل أو إنفاق المال. ويذهب دليل OpenAI أبعد في ضبط اندفاع الوكيل: يمكنك تحديد حد لعدد استدعاءات الأدوات، وتعريف متى يتوقف الوكيل عن البحث، وطلب جملة تمهيدية قصيرة تخبر المستخدم بما سيفعله.
أين تضع المستندات الطويلة؟
إذا كان وكيلك يعمل على مواد طويلة (عقود، أدلة استخدام، صفحات قاعدة معرفة)، فضع هذه المواد قرب بداية السياق، وضع تعليماتك وسؤالك في النهاية. وتذكر Anthropic أن هذا قد يحسّن جودة الرد بنسبة تصل إلى 30% في اختباراتها على المدخلات المعقدة متعددة المستندات. وضع كل مستند داخل وسومه الخاصة مع مصدره، حتى يقتبس الوكيل من المستند الصحيح ويشير إليه. (ولمعرفة متى تسترجع المعلومات بدل حشو كل شيء، راجع RAG مقابل السياق الطويل.)
الوكلاء طويلو التشغيل: الموجّه وحده لا يكفي
للمهام التي تستمر ساعات أو تمتد عبر عدة نوافذ سياق، تضيف إرشادات Anthropic ثلاث تقنيات: الضغط (تلخيص المحادثة والبدء من جديد بالملخص)، وتدوين الملاحظات المنظّم (يحتفظ الوكيل بملف تقدّم خارج نافذة السياق، مثل ملف حالة بصيغة JSON مع حفظ نقاط مرجعية في git)، والوكلاء الفرعيين الذين ينجزون عملاً مركّزاً ويعيدون ملخصاً قصيراً. ويجب أن يخبر موجّه النظام الوكيل بوجود هذه الأدوات ومتى يستخدمها. (دليلنا عن ذاكرة وكلاء الذكاء الاصطناعي يشرح ذلك بالتفصيل.)
ما لا مكان له في موجّه النظام أبداً
- الأسرار. مفاتيح API وكلمات المرور والرموز مكانها إعدادات الخادم، حيث يستخدمها كود الأدوات. أي شيء في الموجّه قد يتسرب عبر سؤال ذكي أو ملف سجلات.
- خط دفاعك الوحيد. الموجّه يمكن مجادلته، أما الكود فلا. حدود الإنفاق والصلاحيات والإجراءات الخطرة يجب فرضها في طبقة الأدوات أيضاً، كما يشرح دليلنا عن أمان الوكلاء وحقن الأوامر.
- الحقائق المتغيرة. الأسعار والمخزون والمواعيد تتغير. دع الوكيل يجلبها بأداة بدل كتابتها ثابتة في الموجّه.
مثال مُختبر: أداة فحص لموجّه النظام
تستطيع اكتشاف عدد من هذه المشكلات تلقائياً. السكربت التالي لا يحتاج مفتاح API. يفحص الموجّه بحثاً عن الأقسام الستة، ويبحث عن قاعدتين بـ"دائماً" و"أبداً" تتحدثان عن الشيء نفسه، ويعدّ الأوامر المكتوبة بأحرف كبيرة، وينبّه إلى أي نص يشبه مفتاح API. ويعمل على نسختين من موجّه لحجز مواعيد عيادة أسنان: الأولى فيها نوع التعارض نفسه الموجود في مثال OpenAI الطبي، والثانية إعادة كتابة تتبع القواعد السابقة. والمفتاح في الموجّه الأول مجرد نص وهمي للتوضيح. (الموجّهات في المثال بالإنجليزية، لأن أداة الفحص تبحث عن كلمات إنجليزية مثل always وnever.)
"""A system-prompt linter (no API key needed).
It flags the problems that vendor prompting guides warn about most often:
missing sections, contradictory rules, shouting, and secrets pasted into the prompt.
"""
import re
SECTIONS = ["role", "context", "tools", "rules", "escalation", "output"]
SHOUTING = re.compile(r"\b(CRITICAL|IMPORTANT|MUST|NEVER|ALWAYS)\b")
SECRET = re.compile(r"\bsk-[A-Za-z0-9-]{16,}|\beyJ[A-Za-z0-9_-]{20,}")
STOP = {"with", "without", "that", "this", "then", "them", "they", "your", "from",
"for", "the", "and", "only", "after", "before", "about", "when", "cases"}
def words(sentence):
return {w for w in re.findall(r"[a-z]{4,}", sentence.lower()) if w not in STOP}
def lint(prompt):
issues = []
for name in SECTIONS:
if not re.search(rf"<{name}[ >]|^#+\s*{name}", prompt, re.I | re.M):
issues.append(f"missing section: {name}")
sentences = re.split(r"(?<=[.!?])\s+|\n", prompt)
always = [s for s in sentences if re.search(r"\balways\b", s, re.I)]
never = [s for s in sentences if re.search(r"\bnever\b", s, re.I)]
for a in always:
for n in never:
shared = (words(a) & words(n)) - {"always", "never"}
if len(shared) >= 2:
issues.append(f"possible conflict on {sorted(shared)}:\n"
f" ALWAYS: {a.strip()}\n NEVER: {n.strip()}")
loud = SHOUTING.findall(prompt)
if loud:
issues.append(f"shouting ({len(loud)}x: {', '.join(sorted(set(loud)))}); "
"newer models may overreact, explain the reason instead")
if SECRET.search(prompt):
issues.append("looks like an API key or token; keep secrets out of prompts")
return issues, len(prompt) // 4 # rough estimate: ~4 characters per token
BEFORE = """You are a helpful assistant for a dental clinic.
CRITICAL: You MUST be helpful and NEVER refuse a patient.
Never book an appointment without the patient's explicit consent.
For urgent cases, always book the earliest same-day appointment automatically.
Calendar API key: sk-EXAMPLE-not-a-real-key-0000
"""
AFTER = """<role>You book appointments for a dental clinic by chat.</role>
<context>Patients write in English or Arabic. Opening hours: Sun-Thu, 9:00-17:00.</context>
<tools>find_slots(date) lists free slots. book(slot, patient_id) creates a booking.
The calendar connection is configured outside this prompt.</tools>
<rules>Book only after the patient confirms the exact slot, because a wrong booking
blocks a chair another patient needed. For urgent pain, offer the earliest same-day
slot first and book it once the patient agrees.</rules>
<escalation>Hand over to the front desk for bleeding, swelling or fever,
and whenever the patient asks for a person.</escalation>
<output>Short replies in the patient's language. End with the booked date and time.</output>
"""
for label, prompt in [("BEFORE", BEFORE), ("AFTER", AFTER)]:
issues, tokens = lint(prompt)
print(f"{label}: ~{tokens} tokens, {len(issues)} issue(s)")
for issue in issues:
print(" -", issue)النتيجة، عند التشغيل بتاريخ 2026-10-07:
BEFORE: ~75 tokens, 9 issue(s)
- missing section: role
- missing section: context
- missing section: tools
- missing section: rules
- missing section: escalation
- missing section: output
- possible conflict on ['appointment', 'book']:
ALWAYS: For urgent cases, always book the earliest same-day appointment automatically.
NEVER: Never book an appointment without the patient's explicit consent.
- shouting (3x: CRITICAL, MUST, NEVER); newer models may overreact, explain the reason instead
- looks like an API key or token; keep secrets out of prompts
AFTER: ~188 tokens, 0 issue(s)ماذا غيّرت إعادة الكتابة:
- اختفى التعارض. بدل "أبداً دون موافقة" مع "دائماً تلقائياً"، صارت هناك قاعدة واحدة: احجز بعد أن يؤكد المريض، ولحالات الألم العاجلة اعرض أقرب موعد أولاً. والسبب (الحجز الخاطئ يشغل كرسياً كان مريض آخر يحتاجه) يخبر الوكيل بما يهم.
- لا تهويل. إعادة الكتابة تستخدم جملاً عادية، والحالة العاجلة لها إجراء محدد بدل تحذير بأحرف كبيرة.
- خرج المفتاح. الاتصال بالتقويم موجود في إعدادات الخادم، لا في نص يستطيع النموذج تكراره.
- التصعيد صريح. النزيف أو التورم أو الحمى، أو طلب التحدث مع شخص، كلها تُحوَّل إلى الاستقبال.
- صار أطول، ولا بأس. نحو 190 وحدة نصية بدل 75، لكن كل سطر مضاف يجيب عن سؤال كان الوكيل سيخمّن إجابته.
أداة فحص كهذه مرشّح أولي رخيص، لا دليل على الجودة. فحص التعارض فيها بسيط عن قصد، وسيفوّت تعارضات مصاغة بطريقة مختلفة. الاختبار الحقيقي هو تشغيل الوكيل على محادثات واقعية وتقييم النتائج، كما يشرح دليلنا عن تقييم وكلاء الذكاء الاصطناعي.
قائمة تحقق قبل الإطلاق
- هل يستطيع زميل جديد ذكي أداء المهمة من هذا الموجّه وحده؟
- هل لكل قاعدة سبب مذكور؟
- إذا أمكن أن تتعارض قاعدتان، هل يقول الموجّه أيهما تُقدَّم؟
- هل التعليمات مكتوبة بصيغة ما يجب فعله، وبلغة هادئة؟
- هل توجد من ثلاثة إلى خمسة أمثلة متنوعة، إن كان شكل الرد مهماً؟
- هل يعرف الوكيل أي الإجراءات ينفذها وحده، وأيها يحتاج إنساناً؟
- هل الأسرار والأسعار والحقائق المتغيرة خارج الموجّه؟
- هل اختبرته على محادثات حقيقية، بما فيها المحادثات الصعبة؟
الخلاصة
موجّه النظام الجيد يشبه تكليفاً واضحاً لموظف جديد كفء: من هو، وما الذي يحتاج معرفته، وأي الأدوات يستخدم، وأي القواعد مهمة ولماذا، ومتى يطلب المساعدة، وكيف يبدو الرد. اكتبه بهدوء، وأزل التناقضات، واحتفظ بالأسرار والحدود الصارمة في الكود، واختبره على محادثات حقيقية. وحين يخطئ الوكيل، أصلح التكليف قبل أن تلوم النموذج.
المصادر: Anthropic، "Effective context engineering for AI agents" (سبتمبر 2025، حُدّث في يناير 2026)؛ Anthropic، توثيق أفضل ممارسات كتابة الأوامر لـClaude؛ OpenAI، دليل كتابة الأوامر لـGPT-5. راجعناها في أكتوبر 2026، وإرشادات الشركات تتطور مع كل جيل جديد من النماذج.