كيف تجعل الذكاء الاصطناعي يكتب كوداً دقيقاً وقابلاً للاختبار؟

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

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

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

العناصر الأربعة لكل أمر برمجي احترافي

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

1. الهدف (Task): ماذا تريد بالضبط؟ "اكتب دالة تتحقق من صحة البريد الإلكتروني" هو هدف واضح. "اكتب لي كوداً" ليس هدفاً، بل دعوة للعشوائية. الهدف يجب أن يكون محدداً، وقابلاً للقياس. إذا كنت تريد إصلاح خطأ، فحدد الخطأ. إذا كنت تريد إضافة ميزة، فحدد الميزة. إذا كنت تريد إعادة هيكلة، فحدد ما الذي تريد إعادة هيكلته.

2. السياق (Context): ما هي المعلومات التي يحتاجها النموذج ليفهم المطلوب؟ هذا يشمل: لغة البرمجة وإصدارها (Python 3.11، JavaScript ES2022، PHP 8.3)، الكود الحالي (إن وجد)، رسالة الخطأ الفعلية، ومتطلبات المشروع. لا تكتفِ بوصف عام مثل "لدي مشكلة في الكود". ألصق الكود، وألصق الخطأ، وحدد الملفات ذات الصلة. كلما كان السياق أوضح، كانت النتيجة أدق.

3. صيغة المخرجات (Output Format): كيف تريد أن يكون الرد؟ هل تريد ملفاً واحداً؟ أم JSON؟ أم جدول تغييرات؟ أم Diff؟ أم اختبارات unit tests؟ تحديد صيغة المخرجات يمنع النموذج من إنتاج كود غير منظم، ويجعل النتيجة أسهل في الدمج مع مشروعك. أيضاً، حدد إن كنت تريد شرحاً بعد الكود، أم لا. بعض النماذج تميل إلى الإطالة، وتحديد الصيغة يقلل من الضوضاء.

4. القيود (Constraints): ما الذي يجب أن يتجنبه النموذج؟ "لا تستخدم مكتبات خارجية"، "لا تغير الواجهة العامة للدوال"، "استخدم أسلوباً وظيفياً بدلاً من الكائنات". القيود تحمي كودك من التغييرات غير المرغوب فيها، وتضمن أن النتيجة تتوافق مع معايير مشروعك. بدون قيود، قد يقترح النموذج حلاً يعمل، لكنه لا يناسب بيئتك.

مثال عملي يجمع العناصر الأربعة:

لاحظ كيف أن كل سطر يضيف معلومة جديدة: الهدف (دالة تحقق)، السياق (JavaScript ES2022)، المخرجات (دالة واحدة)، والقيود (بدون مكتبات، مع اختبارات). هذا الأمر البسيط يعطي نتيجة أفضل بكثير من "اكتب دالة تحقق من البريد".

تقنيات متقدمة ترفع دقة الأكواد

بعد أن فهمنا العناصر الأساسية، حان الوقت للانتقال إلى التقنيات التي ترفع دقة الأكواد إلى المستوى التالي. هذه التقنيات مستخدمة من قبل فرق الهندسة في كبرى الشركات، وتوصي بها OpenAI وGoogle.

1. حدد لغة البرمجة وإصدارها بدقة. لا تقل "Python". قل "Python 3.11". لا تقل "JavaScript". قل "JavaScript ES2022". الإصدار يحدد الميزات المتاحة، والأسلوب المناسب، والمكتبات المسموحة. النموذج الذي لا يعرف الإصدار قد يستخدم ميزات قديمة أو حديثة لا تناسب مشروعك.

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

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

4. استخدم أمثلة Few-shot. قدم مثالاً أو مثالين لمدخل ومخرج صحيح. مثلاً، إذا كنت تريد دالة تنسيق تواريخ، قدم مثالاً: "المدخل: 2026-10-22، المخرج: 22 أكتوبر 2026". الأمثلة تساعد النموذج على فهم التنسيق المطلوب، وتقلل من الافتراضات. حافظ على تنسيق موحد بين الأمثلة، حتى لا يربك النموذج.

5. افصل التعليمات عن السياق. استخدم عناوين Markdown أو وسوم XML مثل <context> و<task> لتوضيح ما هو كود مرجعي وما هو مطلوب تنفيذه. هذا يمنع النموذج من الخلط بين ما يجب تعديله وما يجب الحفاظ عليه.

6. اطلب مخرجات منظمة. حدد إن كنت تريد ملفاً واحداً، أو JSON، أو جدول تغييرات، أو Diff، أو اختبارات unit tests. التنظيم يسهل الدمج، ويقلل من الأخطاء. أيضاً، حدد إن كنت تريد الكود فقط، أم مع شرح، أم مع خطوات تحقق.

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

قالب جاهز لتوليد كود دقيق (انسخه واستخدمه)

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

لاحظ كيف أن القالب يفصل بين الأدوار: <role> يحدد دور النموذج، <context> يوفر المعلومات، <task> يحدد المطلوب، <constraints> يضع الحدود، و<output_format> يحدد شكل الرد. هذا الفصل يمنع الالتباس، ويجعل النتيجة أكثر دقة.

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

أخطاء شائعة يجب تجنبها (وكيف تصححها)

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

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

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

3. مشاركة مفاتيح API أو كلمات المرور أو بيانات العملاء. لا تشارك أي معلومات حساسة في الأوامر. النماذج قد تحتفظ بالمدخلات، وقد تُستخدم للتدريب. استخدم متغيرات بيئية، أو بيانات وهمية (Dummy Data) للاختبار. الأمان مسؤوليتك.

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

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

كيف تتحقق من الكود الناتج قبل استخدامه في الإنتاج؟

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

1. اقرأ الكود وفهمه. لا تنسخ الكود دون أن تفهمه. اقرأ كل سطر، واسأل نفسك: لماذا كتب هذا السطر؟ ماذا يفعل؟ هل هناك طريقة أفضل؟ إذا لم تفهم الكود، فلا تستخدمه. الكود الذي لا تفهمه هو قنبلة موقوتة.

2. شغّل الاختبارات. اطلب من النموذج كتابة اختبارات unit tests، ثم شغّلها. تأكد من أن الاختبارات تغطي الحالات العادية، والحالات الحدية (مدخلات فارغة، أرقام سالبة، قيم كبيرة)، وحالات الفشل (طلبات API فاشلة، مهلة الشبكة). إذا فشل اختبار، أصلح الكود قبل المتابعة.

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

4. راجع الأمان. هل الكود يتعامل مع المدخلات بشكل آمن؟ هل يتحقق من الصلاحيات؟ هل يحمي من هجمات مثل SQL Injection أو XSS؟ الذكاء الاصطناعي قد لا ينتبه لهذه التفاصيل. الأمان مسؤوليتك.

5. راجع التوافق. هل الكود متوافق مع إصدار اللغة والإطار الذي تستخدمه؟ هل يستخدم مكتبات مسموحة؟ هل يتبع أسلوب فريقك؟ التوافق يقلل من مشاكل الدمج لاحقاً.

رسالة أخيرة: الأمر الجيد هو نصف الحل

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

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

مصادر موثوقة

• - OpenAI API - Prompt engineering
• - Gemini API - Prompt design strategies
• - OpenAI Academy - Prompting
• - Anthropic - Building Effective AI Agents