قامت Anthropic بإزالة 80% من المطالبة النظامية (system prompt) التي توجه Claude Code وأفادت بعدم حدوث أي انخفاض في قدرته على كتابة الكود. تُظهر هذه التجربة أنه مع زيادة قدرات النماذج اللغوية الكبيرة (LLMs)، يمكن للمطورين تقليص الهياكل الإضافية الضخمة التي يستخدمونها لإبقاء النماذج على المسار الصحيح دون التأثير على الأداء.
لماذا كانت المطالبة مهمة في المقام الأول
عند إطلاق Claude Code، تضمنت مطالبته النظامية عشرات القواعد. كان المهندسون يضيفون أسطرًا جديدة كلما ظهر خطأ برمي، لكنهم نادرًا ما كانوا يزيلون أي شيء يبدو أنه يعمل بشكل جيد. ومع مرور الوقت، نمت المطالبة لتصبح وثيقة متشابكة وساكنة.
الفجوة بين النماذج تتقلص
أخفت تلك القواعد الإضافية "فجوة النموذج" (model gap) – وهي الفرق بين ما يمكن للنموذج فعله وما يتطلبه التطبيق. في عام 2024، كان على المطورين صياغة قيود صارمة لمنع النموذج من، على سبيل المثال، الإفراط في كتابة التعليقات البرمجية. أما اليوم، فيمكن للنموذج نفسه استنتاج الأسلوب المطلوب من تعليمات بسيطة مثل "طابق أسلوب الكود الحالي". لقد تحولت القواعد من وسيلة مساعدة إلى ضجيج غير ضروري.
ما الذي يتغير في هندسة السياق
يعكس تقليص Anthropic تحولاً أوسع في كيفية هيكلة المطورين للمطالبات:
- تعليمات حاسمة لمرة واحدة – اذكر القاعدة مرة واحدة واترك النموذج يحتفظ بها.
- معلمات مدفوعة بالأدوات بدلاً من أمثلة قليلة (few-shot examples) – صف أشكال المدخلات والمخرجات في مخطط الأداة (tool schema) واترك النموذج يملؤها.
- الإفصاح التدريجي – قدم فقط السياق اللازم للخطوة الحالية، وأضف المزيد لاحقاً إذا لزم الأمر.
- نقل التوجيهات الساكنة إلى أوصاف الأدوات – الأشياء مثل "استخدم camelCase للمتغيرات" تنتمي إلى مواصفات الأداة، وليس إلى المطالبة النظامية.
- استبدال القواعد الثابتة بالقواعد الاستدلالية (heuristics) – اترك للنموذج حرية تحديد متى تنطبق القاعدة بدلاً من فرضها بشكل غير مشروط.
تعمل هذه التكتيكات لأن النموذج يعرف بالفعل العديد من الاصطلاحات التي كانت تتطلب تعزيزاً صريحاً في السابق.
خطر الإفراط في التقليص
إن عملية التقليم نفسها التي تفيد النماذج الرائدة (frontier models) قد تضر بالنماذج الأصغر. تشير Anthropic إلى أن نماذج مثل Haiku لا تزال تعتمد على مطالبات أكثر ثراءً للبقاء على المسار الصحيح. قد يؤدي تجريد نموذج أقل قدرة من الكثير من التوجيهات إلى إعادة ظهور الأخطاء التي حاولت المطالبة الأصلية منعها: مثل عدم اتساق التسمية، أو التعليقات المفرطة، أو تجاهل الحالات الحدية (edge cases).
كيفية مراجعة مطالباتك الخاصة
إذا كنت تدير خط إنتاج لتوليد الكود، فإن مراجعة المطالبة يمكن أن تكشف عن الأجزاء الزائدة التي لا فائدة منها. إليك قائمة مرجعية عملية:
- إعادة ضبط كثافة التعليمات – طابق كمية التوجيه مع النموذج الذي تشغله فعلياً.
- حذف التعليمات المكررة – إذا ظهرت قاعدة في كل من المطالبة النظامية ووصف الأداة، فاحتفظ بها مرة واحدة فقط.
- تحويل الأمثلة العملية إلى مخططات (schemas) أكثر ثراءً – استبدل الأمثلة الملموسة بأنواع معلمات محددة أو تعدادات (enums).
- إخراج التفاصيل الموقفية إلى ملفات خارجية – انقل كتل المراجع الكبيرة إلى ملفات منفصلة يمكن للنموذج جلبها عند الطلب.
- حذف القواعد التي تغطي سلوكيات لم تعد موجودة – إذا لم يعد النموذج يضيف تعليقات غير مرغوب فيها، فاحذف قاعدة "عدم إضافة التعليقات".
لا تعتمد على حدسك. استخدم "قاعدة الاختبار الثلاثي" البسيطة: قم بتشغيل خمس مهام برمجية واقعية، وقارن النتائج قبل وبعد كل عملية حذف، وسجل أي تراجع في الأداء.
- خط الأساس (Baseline) – قم بقياس الأداء باستخدام المطالبة الكاملة.
- الحذف (Delete) – قم بإزالة سطر أو كتلة مرشحة للحذف.
- إعادة التشغيل (Re-run) – قم بتنفيذ المهام الخمس نفسها.
إذا تغيرت المخرجات، فقد حددت سطراً لا يزال له تأثير. وإذا لم تتغير، فيمكن حذف السطر بأمان.
ما الذي يجب على المطورين مراقبته لاحقاً
في الوقت الحالي، الخلاصة واضحة: المطالبة النظامية هي وثيقة حية. تعامل مع كل سطر على أنه له عمر افتراضي، وقم بالمراجعة بانتظام، واترك الكفاءة المتزايدة للنموذج تقوم بالعمل الشاق.
المصدر: dev.to/ialijr/your-system-prompt-has-a-shelf-life-maintaining-prompts-as-models-improve-cd9