لم نعد نكتب المطالبات، صرنا نبني أنظمة تكتب مطالباتها بنفسها

حدث في القطاع أمران في الأسبوع نفسه.

من جهة، انتشر ادعاء أن "هندسة المطالبات ماتت". ومن جهة أخرى، نشرت Anthropic ورشة من سبع وعشرين دقيقة عن كيفية كتابة المطالبات لـ Claude. الأسبوع نفسه، والقطاع نفسه، ورسالتان متعاكستان تمامًا.

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

إجابة سريعة: هندسة المطالبات لا تختفي، بل تغيّر طبقتها. ما مات هو الحيل: لعب الأدوار من نوع "أنت خبير"، وصيغة "فكّر خطوة بخطوة"، وعبارات الإكراميات والتهديد التي تحاول التلاعب بالنموذج. كانت تنفع في ٢٠٢٣ لأن النماذج كانت ضعيفة في اتباع التعليمات. وما لم يمت هو العمل نفسه: أن تقرر ما الذي سيراه النموذج. الفرق أن هذا القرار لم يعد يُتخذ في صندوق محادثة، بل في قاعدة الشيفرة لديك. التعليمات النظامية، وأوصاف الأدوات، وأي مستند يُحمَّل ومتى، وما الذي يدقق مخرجات النموذج. اليوم لا يكاد فشل الوكيل يعني "المطالبة كانت سيئة"، بل يعني "السياق كان خاطئًا".

المحتويات

• الادعاء المنتشر والاقتباس الذي لا يمكن التحقق منه
• الحيل التي ماتت فعلًا
• الطبقة الصاعدة: هندسة السياق
• كيف نفعل ذلك نحن
• ما الذي لم يمت
• أين لا تزال تكتب المطالبات يدويًا
• مسرد المصطلحات
• الأسئلة الشائعة
• قائمة التحقق

الادعاء المنتشر والاقتباس الذي لا يمكن التحقق منه

أشهر صيغة للادعاء المتداول على وسائل التواصل هي عبارة تُنسب إلى أندرو إنغ: "المطالبة ستموت خلال ستة أشهر، وستحل محلها الحلقات والرسوم البيانية".

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

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

ومع ذلك تحت الادعاء ملاحظة حقيقية. الجرعة فقط مبالغ فيها.

الحيل التي ماتت فعلًا

كثير من التقنيات التي كانت تنفع في ٢٠٢٣ صارت اليوم إما بلا أثر وإما ضارة. هذه ماتت فعلًا، وإن كانت لا تزال في مطالباتك فالأولى تنظيفها.

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

الطبقة الصاعدة: هندسة السياق

هنا انتقل العمل بدل أن يتلاشى. وفي القطاع يستقر الاسم على هندسة السياق (context engineering).

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

لذلك حين يفشل وكيل اليوم، لا تكاد المشكلة تكون "المطالبة كُتبت بسوء". بل رأى النموذج الشيء الخطأ، أو لم يرَ ما كان يحتاجه.

التعليمات النظامية

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

أوصاف الأدوات

حين تعطي وكيلًا أداة، يكون حقل description لتلك الأداة مطالبةً. وهو ما يحسم متى يستدعي النموذج الأداة.

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

الكشف التدريجي

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

الحلقات والتقييم

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

كيف نفعل ذلك نحن

هذا القسم ليس نظريًا. في مشاريعنا لا تعيش المطالبات في صندوق محادثة بل في المستودع.

في جذر كل مشروع ملف قواعد يُحمَّل تلقائيًا في كل جلسة ذكاء اصطناعي تعمل على ذلك المشروع. يحوي قواعد الكتابة، وأنماط الأداء، وسلوك الالتزامات، وأي ملف يُقرأ ومتى. مثال:

## قواعد Git والالتزامات

**هدف الالتزام (إلزامي):** حين يقال "التزم"، التزم إلى الفرع
المسحوب حاليًا. لا تفتح فرعًا جديدًا ولا تبدّل الفروع. وإن قيل
"التزم" وأنت على `main`، فالالتزام يذهب إلى `main` مباشرة.
هذا اختيار مقصود.

هذه القاعدة تتجاوز سلوك Claude Code الافتراضي القائل
"افتح فرعًا أولًا إن كان هذا الفرع الافتراضي".

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

وفي الملف نفسه جدول يحدد أي مستند يُقرأ لأي مهمة، ويقول صراحة: "هذه الملفات لا تُحمَّل تلقائيًا، افتحها قبل أن تبدأ". هذا هو الكشف التدريجي في أبسط صوره. لا ننفخ السياق مقدمًا، بل نجلب عند الحاجة.

المثال الثالث أوصاف الأدوات. لدينا خادم MCP يعمل على موقعنا، ووصف كل أداة يفتحها يحدد متى يستدعيها النموذج. وضعنا في رد تعريف الخادم هذه العبارة:

This server is read-only: it cannot submit contact or quote
requests. To start an inquiry, direct the user to the contact
or quote page returned by get_company_info.

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

والقاسم المشترك بين الثلاثة: لا واحد منها رسالة لمرة واحدة. كلها بنية تحتية مُدارة بالإصدارات، ومعاد استخدامها، وتمر بمراجعة. وهذا هو المكان الذي ذهبت إليه هندسة المطالبات.

ما الذي لم يمت

والآن الوجه الآخر للعملة. هذا ما تتخطاه المواد التي تقول "المطالبة ماتت".

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

نشرت Anthropic ورشة مطالبات في الأسبوع نفسه. فإن كان صانعو النموذج ما زالوا يعلّمون كيف تُكتب المطالبات، فعبارة "المطالبة ماتت" سابقة لأوانها على الأقل.

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

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

أين لا تزال تكتب المطالبات يدويًا

الحديث عن بناء الأنظمة لا يعني أن كل شيء سيصير آليًا. ما زلت تجلس وتكتب مطالبة في هذه الحالات:

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

إذن عبارة "لم نعد نكتب المطالبات" ليست دقيقة حرفيًا. الأدق: ننتقل من كتابة مطالبات لمرة واحدة إلى كتابة أنظمة مطالبات تعمل مرة بعد مرة.

مسرد المصطلحات

• هندسة المطالبات: تصميم النص المُدخل للحصول على المخرجات المطلوبة من النموذج.
• هندسة السياق: تصميم كل ما يراه النموذج: التعليمات والمستندات وتعريفات الأدوات والسجل ومخرجات الأدوات.
• التعليمة النظامية: التعليمة الدائمة في البداية التي تحدد دور النموذج وقواعده وحدوده.
• وصف الأداة: النص الذي يخبر النموذج بما تفعله الأداة ومتى تُستدعى. وهو عمليًا مطالبة.
• الكشف التدريجي: جلب المعلومة عند الحاجة بدل تحميلها كلها مقدمًا.
• حلقة الوكيل: نمط عمل ينتج فيه النموذج مخرجات ويقيّمها ويعيد المحاولة مع التصحيح.
• الانعكاس: النمط الذي ينقد فيه النموذج مخرجاته ويراجعها.
• التقييم (eval): اختبار قابل للتكرار يقيس ما إذا كان تغيير مطالبة أو نظام قد أفاد فعلًا.
• تضخم السياق: امتلاء نافذة السياق بمستندات وتعريفات أدوات زائدة يخفض الأداء.

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

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

هل يختفي مسمى مهندس المطالبات؟ كمسمى منفصل، إلى حد بعيد نعم. لكن العمل لا يختفي بل يذوب داخل هندسة البرمجيات. ومن يقوم به اليوم هو عادة من يبني النظام نفسه.

هل ننظف مطالباتنا القديمة؟ نعم. إسناد الأدوار والصياح بأحرف كبيرة و"فكّر خطوة بخطوة" المكتوبة لنماذج قديمة تسبب على النماذج الجديدة تفعيلًا مفرطًا وطولًا بلا داعٍ. احذفها وقِس النتيجة.

ما معنى نظام يكتب مطالباته بنفسه؟ بنية يُجمَّع فيها السياق وقت التشغيل بواسطة النظام ذاته. فهو يقرر أي مستند يُجلب وأي أداة تُستدعى وما الذي يُسأل في الخطوة التالية. وأنت تكتب قواعد هذه القرارات لا الرسائل المفردة.

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

قائمة التحقق

• احذف من مطالباتك إسناد الأدوار والتهديدات وعبارات الإكراميات
• قلّل الصياح بأحرف كبيرة؛ اكتب القاعدة مرة واحدة مع سببها
• احذف "فكّر خطوة بخطوة" على النماذج المفكرة
• انقل التعليمات النظامية من المحادثة إلى المستودع
• راجع ملف القواعد كشيفرة عادية عبر طلب سحب
• عامل أوصاف الأدوات كسياق من الدرجة الأولى وأزل التعارضات
• لا تحمّل كل شيء مقدمًا، اجلب عند الحاجة
• قِس قبل أن تدّعي أن تغييرًا قد أفاد
• عند فشل الوكيل انظر إلى السياق أولًا لا إلى التعليمة
• راجع تعليماتك كلما تغيّر إصدار النموذج

الخلاصة

عبارة "هندسة المطالبات ماتت" نسخة مبالغ فيها من ملاحظة صحيحة. ما مات هو الحيل، وحسنًا أنها ماتت؛ فأكثرها وُجد ليستر نقص النماذج.

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

والنصيحة العملية بسيطة: نظّف الحيل القديمة، وانقل تعليماتك إلى المستودع، وخذ أوصاف الأدوات على محمل الجد، ولا تدّعِ أن تغييرًا نجح دون قياس. ننفذ أعمال معمارية الذكاء الاصطناعي وتكامله ضمن خدمة حلول الذكاء الاصطناعي، والقيادة التقنية ضمن CTO as a Service. ولأثر الذكاء الاصطناعي في تعلّم المطورين راجع مقال أن تكون مطور Junior في عصر الذكاء الاصطناعي.