هندسة الأوامر (Prompt Engineering) داخل الأكواد البرمجية

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

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

ما المقصود بهندسة الأوامر داخل التطبيقات البرمجية؟

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

في التطبيقات الجادة، البرومبت يشبه إلى حد بعيد عقداً بين النظام والنموذج. أنت لا تقول للنموذج “اكتب شيئاً جيداً”، بل تحدد له الدور، والمدخلات، وقواعد الإخراج، وما يجب تجنبه، وكيفية التصرف عند نقص البيانات. هذه الفكرة تصبح أكثر وضوحاً إذا كنت قد قرأت تشريح طلب الـ API: الـ Endpoint، الـ Headers، والـ Body، لأن البرومبت هنا يصبح جزءاً من Body المرسل إلى النموذج.

لماذا يفشل كثير من المطورين عند دمج النماذج اللغوية؟

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

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

البنية الصحيحة للبرومبت داخل الكود

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

1) تحديد الدور والهدف

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

2) تعريف المدخلات

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

3) فرض شكل الإخراج

إذا كنت تحتاج استجابة قابلة للمعالجة، فاطلب بنية محددة. بدلاً من طلب “حلل النص”، اطلب “أعد النتيجة بصيغة JSON تحتوي الحقول category وpriority وreply“.

4) وضع القيود التشغيلية

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

مثال عملي: تضمين البرومبت في سكربت JavaScript

في بيئات الإنتاج، يتم غالباً إرسال البرومبت عبر طلب POST إلى خدمة ذكاء اصطناعي. طريقة البناء هنا مهمة جداً، مثل أهمية فهم شرح أفعال الـ HTTP (GET, POST, PUT, DELETE) والفرق بينها قبل تصميم التدفقات المؤتمتة.

const userMessage = "أحتاج استرداد مبلغ بسبب خصم مكرر من البطاقة";
const prompt = `
أنت مساعد دعم فني متخصص في تصنيف الرسائل.
المطلوب:
1. حلل رسالة العميل.
2. استخرج الفئة المناسبة.
3. حدد مستوى الأولوية: low أو medium أو high.
4. أنشئ رداً مختصراً وواضحاً.
5. أعد النتيجة بصيغة JSON فقط دون أي نص إضافي.

القيود:
- لا تخترع معلومات غير موجودة.
- إذا كانت البيانات غير كافية، اذكر ذلك داخل الحقل missing_data.
- اللغة المطلوبة في الرد: العربية.

رسالة العميل:
${userMessage}
`;

async function classifyTicket() {
  const response = await fetch("https://api.example.ai/v1/chat/completions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${process.env.AI_API_KEY}`
    },
    body: JSON.stringify({
      model: "gpt-4.1",
      temperature: 0.2,
      messages: [
        { role: "system", content: "You generate structured support classifications." },
        { role: "user", content: prompt }
      ]
    })
  });

  if (!response.ok) {
    throw new Error(`Request failed with status ${response.status}`);
  }

  const data = await response.json();
  return data;
}

ملاحظة توثيقية:
عند إرسال الطلب إلى أي API خاص بالنماذج، راقب ثلاثة عناصر: Authentication، وحدود الاستهلاك، وشكل الاستجابة. كما يجب تخزين المفاتيح السرية في ملفات آمنة كما شرحنا في أمن البيانات: كيفية تخزين المفاتيح السرية في ملفات .env.

ربط هندسة الأوامر مع الأتمتة متعددة المراحل

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

هذا النوع من السلاسل يمكن بناؤه برمجياً، أو عبر أدوات مثل مقدمة في منصة Make (Integromat سابقاً): بناء سيناريوهات معقدة واستخدام Pipedream للمبرمجين: دمج Node.js مع الأتمتة. لكن حتى في أدوات No-Code، ستظل جودة البرومبت عاملاً حاسماً في نجاح السيناريو.

تدفق عملي مقترح

• استقبال الحدث من نموذج أو متجر أو نظام حجز.
• تنظيف البيانات وتوحيد الحقول المطلوبة.
• بناء Prompt Template ديناميكي.
• إرسال الطلب إلى النموذج عبر POST.
• التحقق من الاستجابة وتحويلها إلى كائنات قابلة للمعالجة.
• تسجيل النتيجة وإطلاق خطوة تالية مثل إشعار أو تحديث قاعدة بيانات.

التحقق، المراقبة، ومعالجة الأخطاء

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

function safeParseAIResponse(content) {
  try {
    const parsed = JSON.parse(content);

    if (!parsed.category || !parsed.priority || !parsed.reply) {
      throw new Error("Missing required fields");
    }

    return parsed;
  } catch (error) {
    return {
      category: "unknown",
      priority: "medium",
      reply: "تعذر تحليل الرسالة آلياً، تم تحويلها للمراجعة البشرية.",
      error: error.message
    };
  }
}

معالجة الأخطاء الحرجة:
إذا فشل الطلب بسبب 429 أو 500، طبّق سياسة Retry with Exponential Backoff. ولمراجعة دلالات الاستجابات، يفيد الرجوع إلى رموز الحالة (HTTP Status Codes): ماذا يخبرك السيرفر بـ 200 أو 404؟، وكذلك تحديد معدل الطلبات (Rate Limiting): كيف تتجنب الحظر من الخوادم.

أفضل الممارسات التي ترفع جودة النتائج

1. افصل بين نص التعليمات الثابتة والبيانات المتغيرة لتسهيل الصيانة.
2. استخدم قيم temperature منخفضة في المهام الحساسة.
3. أنشئ نسخاً متعددة من البرومبت واختبرها على عينات واقعية.
4. سجّل المدخلات والمخرجات مع إزالة البيانات الحساسة لأغراض التحسين.
5. وفّر مسار Fallback عند تعذر الفهم أو فشل الاستجابة.
6. اربط التصميم بالتوثيق الرسمي للخدمة، كما في توثيق الـ API: كيفية قراءة مستندات Swagger و Redoc.

متى تصبح هندسة الأوامر جزءاً من هندسة النظام نفسه؟

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

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

الخلاصة

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

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