القواعد الجديدة لهندسة السياق لنماذج الجيل الخامس من Claude

سبق أن كتبت عن أفضل السبل لتوجيه أحدث جيل من نماذج Claude 5، والعمل معها بصورة تكرارية لاكتشاف ما تريد بناءه.

لكن عندما ترسل رسالة إلى Claude، لا يكون الموجّه (prompt) سوى جزء صغير من السياق الذي يتلقاه. فجانب كبير من سياقك يُجمع من موجّه النظام (system prompt)، والمهارات، وملفات CLAUDE.md، والذاكرة، ومصادر أخرى. ونحن نطلق على ذلك اسم «هندسة السياق (context engineering)»، وهو يؤثر بدرجة كبيرة في النتائج التي تحصل عليها عند استخدام Claude Code أو عند بناء وكلائك (agents) الخاصين.

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

قد يكون هذا صعبًا على نحو مفاجئ مع تطور قدرات Claude نفسه. ومؤخرًا، لاحظنا قفزة كبيرة في الطريقة التي نوجّه بها أحدث جيل من نماذج Claude. فقد حذفنا أكثر من ٨٠٪ من موجّه النظام في Claude Code للنماذج من قبيل Claude Opus 5 وClaude Fable 5، من دون أن نسجل أي تراجع قابل للقياس في تقييمات (evals) البرمجة لدينا.

وفيما يلي ما تعلمناه عن توجيه هذه الفئة الجديدة من النماذج، وكيف يمكنك الاستفادة منه لتحديث هندسة السياق لديك. وقد وضعنا أفضل هذه الممارسات في الأمر claude doctor؛ استخدم الأمر /doctor داخل Claude Code لضبط حجم مهاراتك وملفات CLAUDE.md بما يلائم الحاجة.

تحرير Claude من القيود

وجدنا، بوجه عام، أننا كنا نفرض قيودًا مفرطة على Claude Code، سواء عبر موجّه النظام أو ملفات CLAUDE.md أو المهارات (Skills).

فعندما نقرأ، على سبيل المثال، سجلات استخدامنا الداخلي لـClaude Code، نرى في الطلب الواحد رسائل متعارضة عدة، مثل «اترك التوثيق على النحو المناسب» أو «لا تضف تعليقات»، بينما تتصادم تعليمات موجّه النظام والمهارات وطلبات المستخدم بعضها مع بعض.

السياق المُجمَّع

موجّه النظام

«اترك التوثيق على النحو المناسب» *

---

المهارات

«لا تضف تعليقات» *

---

طلبك أنت

«اجعله يعمل مثل القديم فحسب» *

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

ومع أن هذه القيود كانت ضرورية في السابق لتجنب أسوأ السيناريوهات، فقد وجدنا لاحقًا أنه يمكن حذف كثير منها وترك النموذج يستعين بالسياق المحيط وبحسن تقديره.

إضافة إلى ذلك، أصبح لدى Claude Code اليوم عدد أكبر بكثير من الأدوات. وكان Claude يعتمد سابقًا على CLAUDE.md بوصفه مصدرًا للذاكرة والمعلومات والإرشاد، أما الآن فلدينا الذاكرة (memory) وميزة Artifacts والمهارات، ويمكن لـClaude استخدامها لاستحداث طرائق جديدة لتحميل السياق ومشاركته بين الجلسات.

سابقًا والآن

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

زوّد Claude بالقواعد	←	زوّد Claude بالأحكام
زوّد Claude بالأمثلة	←	صمّم الواجهات
ضع كل شيء في البداية	←	استخدم الإفصاح التدريجي
كرّر تعليماتك	←	أوصاف بسيطة للأدوات
الذاكرة في ملفات CLAUDE.md	←	الذاكرة التلقائية
مواصفات بسيطة	←	مراجع غنية

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

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

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

ومع ذلك، كانت التعليقات التي يكتبها Claude في النماذج الأقدم كثيرًا ما تكون غير صحيحة من دون هذه الحواجز (guardrails)، وكان علينا قبول هذه المقايضة. أما النماذج الأحدث فتتمتع بقدرة أفضل على التقدير، ويمكنها التعامل مع هذه القرارات جيدًا من دون قواعد صريحة.

وفي موجّه النظام الجديد نقول:

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

كانت القاعدة الأهم لاستخدام الأدوات هي تقديم أمثلة لـClaude على كيفية استخدامها. لكننا وجدنا مع أحدث نماذجنا أن تقديم الأمثلة قد يقيّد النموذج داخل حيز استكشاف معين.

≈٩٬١٠٠ حرف

سابقًا

قوائم «متى تُستخدم»، وأمثلة مشروحة

TodoWrite

"أنشئ قائمة مهام للجلسة الحالية وحدّثها…"

status: pending in_progress completed

مهمة واحدة فقط في in_progress في كل وقت

بدلًا من استخدام الأمثلة، فكّر بدرجة أكبر في تصميم أدواتك ونصوصك البرمجية وملفاتك: ما المعلمات التي يملكها Claude؟ وكيف يمكن جعلها أكثر تعبيرًا؟

في مثال أداة المهام Todo، يكفي إدراج الحالة كتعداد (enum) بين pending وin_progress وcompleted كي يلتقط Claude إشارة إلى طريقة استخدام الأداة. كما أن التعليمة التي تقضي بإبقاء مهمة واحدة فقط في حالة in_progress تساعد على تحديد السلوك المطلوب.

نظرًا إلى تركيز Claude Code على البرمجة، كان موجّه النظام لدينا يتضمن معلومات تفصيلية عن كيفية مراجعة الشيفرة والتحقق منها. ولم تكن هذه المعلومات مطلوبة دائمًا، لكنها كانت حاسمة عندما نحتاج إليها.

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

ولا يقتصر الإفصاح التدريجي على المهارات؛ فنحن نستخدمه أيضًا مع الأدوات. بعض أدواتنا تستخدم «التحميل المؤجل (lazy loading)»، أي أن على الوكيل البحث عن تعريفاتها الكاملة عبر ToolSearch قبل استخدامها. ويسمح لنا ذلك بتوفير عدد أكبر من الأدوات، مثل أدوات Task، من دون أن تشغل مساحة في السياق قبل الحاجة إليها.

يمكن تطبيق النهج نفسه على ملفات CLAUDE.md وSKILL.md لديك. ومن الأفكار الشائعة الخاطئة أن هذه الملفات ينبغي أن تكون مستودعًا مركزيًا لكل ممارسة قد تحتاج إليها، خشية ألا يجدها Claude بغير ذلك. وبدلًا من هذا، فكّر في إنشاء شجرة من الملفات يمكن تحميلها في الوقت المناسب.

كانت نماذج Claude الأقدم تحتاج أحيانًا إلى تكرار التعليمات، أو تميل إلى الإصغاء للتعليمات الموجودة في نهاية نافذة السياق (context window) أكثر من تلك الموجودة في بدايتها. ولذلك كان موجّه النظام يشير أحيانًا إلى الأدوات في نصه الرئيسي، ثم يكرر إرشادات استخدامها داخل وصف الأداة.

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

كنا نشجع المستخدمين في السابق على حفظ الأشياء في ذاكرة Claude باستخدام مفتاح الاختصار # للكتابة تلقائيًا داخل ملف CLAUDE.md. أما الآن، فيحفظ Claude تلقائيًا الذكريات ذات الصلة بالعمل وبالمستخدم.

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

لكننا وجدنا أن Claude أصبح قادرًا على التعامل مع مراجع أكثر تعقيدًا. فبدلًا من ملفات Markdown البسيطة، يستطيع Claude الرجوع إلى مخرجات HTML أنشأتها ميزة Artifacts الجديدة لدينا.

ويمكنك أيضًا تزويد Claude بمراجع على هيئة شيفرة. فقد تكون المواصفة مجموعة اختبارات تفصيلية، أو دالة في قاعدة شيفرة مختلفة يريد Claude نقلها إلى المشروع الحالي.

وتُعد معايير التقييم (rubrics) شكلًا آخر من أشكال المراجع (references). فهي تتيح لـClaude محاولة التحقق من ذوقك أو معاييرك في مجال محدد، مثل معنى التصميم الجيد لواجهة API، وذلك باستخدام سير عمل ديناميكي وتشغيل وكلاء تحقق (verifier agents) يستندون إلى تلك المعايير.

تطبيق ذلك على سياقك

بعد جمع هذه الأفكار كلها، كيف ينبغي أن يبدو السياق الذي تبنيه؟

راجع الرسم في أعلى المقالة: موجّهك شريحة واحدة بين شرائح كثيرة — والمراجع وموجّه النظام وملفات CLAUDE.md والمهارات والذاكرة تشاركه النافذة نفسها.

موجّه النظام

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

ملف CLAUDE.md

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

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

المهارات

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

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

ومن الأفضل أن تجسد المهارات آراء محددة أو معرفة أو أفضل ممارسات تخصك أنت أو فريقك أو منتجك.

المراجع

يمكنك الإشارة إلى الملفات بعلامة @ لإدراجها كمراجع. وتتيح المراجع لـClaude الرجوع إلى معلومات متعمقة عن الخطة الحالية.

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

جرّب التبسيط

قد تحتاج إلى تبسيط موجّه النظام والمهارات وملفات CLAUDE.md، كما فعلنا نحن. وقد أطلقنا أمرًا جديدًا باسم claude doctor لمساعدتك على تنفيذ ذلك تلقائيًا. ولمزيد من التفاصيل عن توجيه النماذج الأكثر تقدمًا على وجه التحديد، راجع الدليل الميداني لـFable.

المصدر: مقال The new rules of context engineering for Claude 5 generation models بقلم Thariq Shihipar، عضو الطاقم الفني في Anthropic — نُشر على مدونة Claude بتاريخ ٢٤ يوليو ٢٠٢٦. الرابط الأصلي. الترجمة والرسوم منقولة عن المقال الأصلي، ونُشرت هنا بغرض إتاحتها لقارئ العربية.