لماذا تجعل الإدارة التفصيلية وكلاء الذكاء الاصطناعي لديك أكثر غباءً في الواقع

افتح أي ملف system_prompt.txt عشوائي من أي مستودع GitHub حديث اليوم، وماذا سترى؟ في الغالب، ستجد جداراً من النصوص المكتوبة بحالة من الذعر. "لا تفعل X. يجب أن تخرج ثلاث نقاط بالضبط. إياك أن تستخدم هذه المكتبة."

المطورون يتعاملون مع أكثر محركات التفكير (reasoning engines) تطوراً في تاريخ البشرية وكأنها سكريبتات regex هشة وقابلة للكسر.

هذا "البارانويا" أو جنون الارتياب له مبرر تاريخي منطقي. فقبل عام أو عامين فقط، كانت نماذج الـ LLMs الأولى تحتاج إلى توجيه دقيق ومستمر (hand-holding) لمجرد البقاء في صلب الموضوع. لكن الزمن تغير. النماذج الحديثة أصبحت ذكية بشكل لا يُصدق، ومع ذلك ما زلنا نكتب الأوامر (prompts) وكأننا نبرمج مايكروويف من الثمانينيات. نحن نحاول حرفياً برمجة الذكاء بقواعد ثابتة (hardcode intelligence).

حدث شيء مثير للاهتمام مؤخراً في Vercel يثبت هذه النقطة. نشر فريقهم الهندسي تحليلاً لكيفية تحسينهم لمنتج v0، وذكروا خطوة قد تبدو غير منطقية للوهلة الأولى: لقد قاموا بإزالة 80% من الأدوات (tools) الخاصة بالـ agent الخاص بهم.

النتيجة؟ النظام لم ينهار. بل تحسن بشكل ملحوظ. من خلال التخلص من الأدوات المقيدة والقيود الصارمة، قللوا من تشتت النموذج وسمحوا له بالقيام بما يجيده حقاً: التفكير المنطقي لحل المشكلة. احتكاك أقل (Less friction) أدى إلى كود أفضل.

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

عندما تخبر الـ LLM بما يجب عليه فعله خطوة بخطوة، فأنت تجبره على استهلاك انتباهه المحدود (القدرة الحسابية - compute) في محاولة الامتثال للقواعد بدلاً من التركيز على الجودة. أنت تجرده من قدرته على الاستفادة من بيانات تدريبه الهائلة لإيجاد حل أكثر أناقة وذكاءً من الحل الذي قمت بفرضه عليه.

لكي ترى الفرق بوضوح، دعنا نلقي نظرة على الطريقة التي يكتب بها معظم المطورين الـ prompts الخاصة بالـ agents، مقارنة بالطريقة التي يجب أن يكتبوها بها.

الطريقة السيئة (قواعد صارمة):

"اكتب دالة Python لجلب بيانات المستخدم. يجب عليك استخدام مكتبة requests. يجب عليك معالجة الأخطاء باستخدام كتلة try/except. يجب أن تُرجع dictionary يحتوي بالضبط على المفاتيح 'name' و 'email' و 'status'. لا تستخدم async. أضف تعليقات إلى كل سطر."

الطريقة الجيدة (مبادئ وأهداف):

"اكتب دالة Python قوية (robust) لجلب بيانات المستخدم. يُفضل استخدام المكتبات الحديثة والقياسية. يجب أن يكون الكود جاهزاً لبيئة الإنتاج (production-ready)، مما يعني أنه يتعامل مع أعطال الشبكة والحالات الاستثنائية (edge cases) بسلاسة. أعطِ الأولوية لسهولة القراءة والبنية النظيفة على حساب الكود المعقد أو "الذكي". النظام اللاحق (downstream system) يتوقع ملفات تعريف قياسية للمستخدمين (الاسم، البريد الإلكتروني، الحالة)."

هل لاحظت الفرق؟ المثال الأول يعامل الذكاء الاصطناعي وكأنه مطور مبتدئ (junior developer) لا يمكن الوثوق به. بينما المثال الثاني يعامله كمهندس خبير (senior engineer) يفهم الهدف والسياق العام. أنت تخبره بمواصفات المخرجات الجيدة والسبب وراء ذلك، ثم تتراجع خطوة للوراء وتتركه يكتشف الكيفية.

بالطبع، هناك استثناء رئيسي واحد لهذه القاعدة.

عندما تتواصل الـ agents مع agents أخرى — أو عندما يقوم agent في بداية المسار (upstream) بتمرير بيانات إلى محلل قواعد بيانات صارم في نهاية المسار (downstream) — هنا أنت بحاجة إلى صرامة مطلقة. عمليات التسليم بين الآلات (Machine-to-machine handoffs) تتطلب هياكل JSON دقيقة وغير قابلة للتفاوض. لكن عندما يتعلق الأمر بالتفكير المنطقي، وتوليد الأفكار، وحل المشكلات؟ أرخِ قبضتك قليلاً.

إذا كنت ترغب في ترقية مساعدي البرمجة لديك فوراً اليوم، انسخ هذا المقطع والصقه كما هو في ملف claude.md، أو memory.md، أو في الـ system prompt الأساسي للـ agent الخاص بك:

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

توقف عن محاولة الإدارة التفصيلية (micromanage) للآلة. ثق في نماذج الـ LLM الحديثة. إنها أسرع، وأذكى، وأكثر قدرة بشكل لا نهائي عندما نتوقف عن معاملتها كأطفال صغار.