أبرز النقاط
- حذف 80% من تعليمات النظام في Claude Code أثبت أن النماذج الأحدث تعمل أفضل بتوجيهات أقل
- التحوّل من القواعد الصارمة إلى الاعتماد على حُكم النموذج يقلّل التعارضات ويُسرّع الاستجابة
- تصميم الواجهات التعبيرية بات أهم من تقديم الأمثلة الكثيرة عند بناء أدوات الوكلاء
في تدوينة نشرتها Anthropic يوم 24 يوليو 2026، كشفت الشركة أنها أزالت أكثر من 80% من محتوى system prompt الخاص بأداة Claude Code عند استخدام نماذج الجيل الخامس مثل Claude Opus 5 وClaude Fable 5، دون أي تراجع ملموس في نتائج تقييمات البرمجة. الخلاصة واضحة: النماذج المتقدمة تحتاج توجيهات أقل بكثير مما اعتدنا عليه، وهذا يُعيد تشكيل ما يُعرف بـ «هندسة السياق» أو context engineering.
ما هي هندسة السياق ولماذا تختلف عن كتابة البرومبت؟
حين ترسل رسالة إلى Claude، فإن ما كتبته أنت ليس سوى جزء صغير مما يراه النموذج. الجزء الأكبر يتشكّل من system prompt، وملفات CLAUDE.md، والمهارات المحفوظة (Skills)، والذاكرة، ومصادر سياقية أخرى. تُسمّي Anthropic هذه العملية «هندسة السياق»، وهي تُحدّد جودة المخرجات أكثر مما يفعله البرومبت الفردي.
الفرق الجوهري: البرومبت مصمَّم لطلب واحد محدد، بينما السياق يُستخدَم عبر عشرات الطلبات المختلفة، فلا يمكنه أن يكون بنفس الدقة. السؤال الذي واجه فريق Anthropic: كيف تبني توجيهات عامة صالحة لأي طلب مستقبلي دون أن تعرف ماذا سيكتب المستخدم؟
لماذا حذفت Anthropic 80% من التعليمات؟
راجع الفريق سجلات الاستخدام الداخلي لـ Claude Code، فوجد تعارضات صريحة: تعليمة تقول «أضف توثيقاً عند الحاجة»، وأخرى تقول «لا تكتب تعليقات أبداً». النتيجة: يضطر النموذج للتفكير مطوّلاً في هذه الرسائل المتضاربة قبل أن يقرر ماذا يفعل، ما يُبطئ الاستجابة ويُعقّد السلوك.
كانت تلك القيود ضرورية سابقاً لتفادي سيناريوهات كارثية كحذف الملفات، لكن النماذج الجديدة تملك حُكماً أفضل. يمكنها الآن الاعتماد على السياق المحيط واتخاذ القرار المناسب دون توجيه صريح لكل حالة.
من القواعد الصارمة إلى الحكم الذاتي للنموذج
في الإصدارات القديمة، كانت التعليمات تنص صراحةً على عدم كتابة تعليقات متعددة الأسطر أو إنشاء مستندات تخطيط إلا بطلب المستخدم. المشكلة: بعض الحالات تحتاج فعلاً توثيقاً مطوّلاً، والتعليمة العامة تمنعه.
التوجيه الجديد أبسط بكثير: «اكتب كوداً يشبه الكود المحيط به؛ طابق كثافة التعليقات والتسمية والأسلوب». هكذا يُترك القرار للنموذج بناءً على السياق الفعلي، لا على قاعدة جامدة.
- القاعدة القديمة: لا تكتب تعليقات متعددة الأسطر مطلقاً.
- القاعدة الجديدة: طابق أسلوب الكود المحيط في التعليقات والتسمية.
- النتيجة: مرونة أعلى ودقة أفضل في الحالات الهامشية.
تصميم الواجهات بدلاً من تقديم الأمثلة
كانت أفضل ممارسة سابقة تقول: أعطِ النموذج أمثلة كثيرة على استخدام الأدوات. لكن Anthropic لاحظت أن الأمثلة تحصر النموذج في نطاق استكشاف ضيق. البديل: صمّم واجهات أدواتك لتكون تعبيرية وواضحة المعايير، فيفهمها النموذج دون أمثلة.
مثال بسيط: أداة إدارة المهام (Todo) كانت تستخدم حقل status بقيم محددة مثل pending وin_progress. بدلاً من شرح كل حالة بالأمثلة، يكفي أن تكون الواجهة نفسها واضحة ومعبّرة.
الأدوات الجديدة في Claude Code: الذاكرة والمهارات والـ Artifacts
لم يعد Claude Code يعتمد على ملف CLAUDE.md وحده كمصدر للمعلومات والإرشادات. الآن توجد طبقات إضافية: الذاكرة (memory) لحفظ السياق بين الجلسات، والـ artifacts لمشاركة المخرجات، والمهارات (skills) لتحميل سياق متخصص عند الحاجة.
هذا التعدد يعني أن التوجيهات يمكن أن تتوزّع على مصادر مختلفة، لذا ينبغي تجنّب التكرار والتعارض. أضافت Anthropic أمر /doctor داخل Claude Code لمراجعة ملفات Skills وCLAUDE.md وضبط حجمها تلقائياً.
كيف تطبّق هذه الدروس على وكلائك الخاصين؟
- راجع تعليمات النظام لديك واحذف كل قاعدة لم تعد النماذج الحديثة تحتاجها.
- ابحث عن التعارضات بين مصادر السياق المختلفة (system prompt، ملفات التوثيق، المهارات).
- صمّم واجهات أدواتك لتكون تعبيرية بدلاً من إغراق النموذج بالأمثلة.
- استخدم أمر /doctor في Claude Code لضبط ملفاتك تلقائياً.
- اختبر الأداء بعد كل تقليص للتعليمات؛ النماذج الأحدث غالباً ستتحسّن لا تتراجع.
رأي Logicity
ما فعلته Anthropic يؤكد اتجاهاً أوسع: النماذج الأحدث لم تعد بحاجة إلى «دليل مستخدم» مفصّل داخل system prompt؛ بل تحتاج سياقاً نظيفاً وواجهات واضحة. هذا يُغيّر اقتصاديات بناء الوكلاء: فريق صغير يملك تصميم أدوات جيداً قد يتفوّق على فريق كبير يُراكم تعليمات متضاربة. للمقارنة، أدوات مثل LangChain وCrewAI ما زالت تعتمد على قوالب توجيه طويلة؛ من يتبنّى فلسفة «أقل هو أكثر» مبكراً سيوفّر وقت هندسة ويحصل على سلوك أكثر اتساقاً.
الأسئلة الشائعة
ما الفرق بين prompt engineering وcontext engineering؟
prompt engineering يركّز على صياغة الطلب الفردي، بينما context engineering يشمل كل ما يُحيط بالطلب: تعليمات النظام، الذاكرة، المهارات، والملفات المرجعية التي تُستخدم عبر جلسات متعددة.
هل يعني حذف التعليمات أن النموذج قد يخطئ أكثر؟
وفق اختبارات Anthropic، لم يحدث تراجع في تقييمات البرمجة. النماذج الأحدث تملك حُكماً أفضل وتستطيع الاعتماد على السياق المحيط بدلاً من قواعد صريحة.
كيف أعرف أي تعليمات يمكنني حذفها من system prompt الخاص بي؟
ابدأ بالقواعد التي تتعارض مع بعضها أو مع طلبات المستخدمين الفعلية. استخدم أمر /doctor في Claude Code للحصول على توصيات تلقائية، ثم قِس الأداء بعد كل تغيير.
هل تنطبق هذه الدروس على نماذج أخرى مثل GPT-4 أو Gemini؟
المبدأ العام — تقليل القيود الصارمة للنماذج الأكثر قدرة — منطقي، لكن النسب تختلف. اختبر على نموذجك المستهدف قبل التعميم.
ما أهمية تصميم الواجهات بدلاً من الأمثلة؟
الأمثلة تحصر النموذج في أنماط محددة، بينما الواجهة التعبيرية تسمح له باستكشاف حلول جديدة وفهم القصد من المعايير مباشرة.
هل تحتاج مساعدة في التطبيق؟
إذا كنت تبني وكيلاً ذكياً أو تُحدّث تعليمات النظام لمنتجك، تواصل مع فريق Logicity للحصول على استشارة تقنية سريعة أو مراجعة لملفات context engineering الخاصة بك.
عمر حسن
كاتب تقني وابتكار
أُنتِج هذا المقال بمساعدة الذكاء الاصطناعي وراجعه فريق التحرير في لوجيسيتي. اعرف المزيد في سياسة التحرير.
