لا تحصل على أفضل ما يقدمه وكيل البرمجة لأن أوامرك ليست محددة بما يكفي. يشرح هذا المقال بالتفصيل كيف تبني الأوامر، وتختار السياق المناسب، وتكتب تعليمات تنتج شيفرة تعمل من المحاولة الأولى.
لا بد أنك شاهدت العروض التوضيحية. يكتب الذكاء الاصطناعي شيفرة مثالية في ثوانٍ، ويسترخي المطوّر في مقعده، وينتهي الأمر. الواقع الذي يواجهه معظم المطورين مختلف: مخرجات غامضة، واستيرادات خاطئة، ومنطق يكاد يعمل لكنه لا يعمل، وردود تخطئ الهدف تماماً. الفجوة بين تلك العروض المصقولة والاستخدام اليومي الفعلي تعود تقريباً بالكامل إلى طريقة كتابة الأوامر. المدخلات الأفضل تنتج مخرجات أفضل بفارق كبير، والقواعد ليست واضحة كما تبدو.
أشيع سوء فهم هو أن وكيل البرمجة "ذكي بما يكفي لمعرفة الحل بنفسه". هذا غير صحيح. وكيل البرمجة محرك تنبؤ، ويتنبأ بناءً على ما تعطيه إياه. تظل قاعدة "ما تدخله يحدد ما تحصل عليه" صحيحة بقسوة حتى مع النماذج المتقدمة.
اطلب من الوكيل "اكتب دالة لمعالجة بيانات المستخدم" وسيكتب شيئاً ما. قد يبدو معقولاً حتى. لكنه سيعالج البيانات الخطأ، بالتنسيق الخطأ، دون معالجة للأخطاء، وبأسماء متغيرات لا تعني شيئاً في قاعدة شيفرتك. الوكيل لم يفشل. أنت من فشل، لأنك قدّمت مواصفات ناقصة.
لا يستطيع الوكيل قراءة أفكارك. لا يستطيع رؤية قاعدة شيفرتك ما لم تُريه إياها. ولا يعرف ما تعنيه كلمة "معالجة" في تطبيقك. كل افتراض يفترضه مجرد تخمين.
عندما ترسل أمراً، يرى النموذج التوكنات فقط. لا نبرة، ولا نية، ولا معرفة مفترضة بالمجال. الفرق بين هذين الأمرين كبير جداً:
سيئ: "اكتب دالة تسجيل دخول"
جيد: "اكتب دالة بلغة Python اسمها authenticate_user(email: str, password: str) -> dict تتحقق من بيانات الاعتماد مقابل قاعدة بيانات PostgreSQL باستخدام bcrypt لمقارنة كلمات المرور. أعِد {success: True, user_id: int} عند النجاح، وأعِد {success: False, error: str} عند الفشل. استخدم المساعد الموجود db_connection() من src/database.py."
يُزيل الأمر الثاني عشرات التخمينات. اللغة، وتوقيع الدالة، وأنواع البيانات، ونوع قاعدة البيانات، ومكتبة التجزئة، وصيغة الإرجاع، وبنية المشروع، كلها محددة. ستكون المخرجات قابلة للاستخدام دون إعادة كتابة.
هذه ليست نظرية. هذه أنماط يستخدمها مطورون يحصلون باستمرار على شيفرة تعمل من المحاولة الأولى أو الثانية من وكلاء الذكاء الاصطناعي.
ابنِ كل أمر غير بسيط على ثلاثة مكونات:
💡 مثال: "أنت مهندس خلفية أول بلغة Python. اكتب وسيط تحديد معدل الطلبات لتطبيق FastAPI. استخدم Redis للتخزين. لا تستخدم أي مكتبات خارجية لتحديد معدل الطلبات. أعِد الوسيط كصنف يمكن تسجيله باستخدام
app.add_middleware()."
هذا الهيكل ذو الأجزاء الثلاثة وحده سيحسّن جودة المخرجات بهامش ملحوظ.
الأوامر بأمثلة قليلة (few-shot) من أقل الأساليب استخداماً في سير عمل البرمجة العملي. بدلاً من وصف ما تريده، أرِه.
إذا أردت دالة تتبع نمطاً محدداً في قاعدة شيفرتك، فألصق دالة مشابهة موجودة كمثال أولاً. قل "اتبع هذا النمط تماماً" ثم صف الدالة الجديدة. سيحاكي الوكيل أسلوب التسمية، ونمط معالجة الأخطاء، وأنماط التسجيل، وصيغة وثائق الدوال، دون أن تضطر إلى سرد كل تلك المتطلبات صراحةً.
بدون مثال: "اكتب دالة مساعدة لتحليل التواريخ من النصوص"
مع مثال:
Here is an existing helper in our codebase:
def parse_currency(value: str) -> Decimal:
"""Parses a currency string like '$1,234.56' into Decimal."""
try:
cleaned = value.replace('$', '').replace(',', '')
return Decimal(cleaned)
except InvalidOperation:
raise ValueError(f"Cannot parse currency: {value!r}")
Write a similar helper called parse_date(value: str) -> date that handles formats:
'YYYY-MM-DD', 'MM/DD/YYYY', and 'DD-Mon-YYYY'.
ستُنتج النسخة الثانية دالة تتناسب مع قاعدة شيفرتك من المحاولة الأولى.
من أكثر العادات ضرراً في التطوير بمساعدة الذكاء الاصطناعي أن تطلب الكثير دفعة واحدة. "ابنِ لي نظام مصادقة كاملاً" ستنتج مخرجات متضخمة وعامة تمسّ بنيتك المعمارية بطرق لا تتوقعها.
قسّم المهام الكبيرة إلى وحدات ذرّية:
| أمر سيئ | أمر أفضل |
|---|---|
| "ابنِ نظام دفع" | "اكتب دالة create_payment_intent" |
| "أعد هيكلة وحدة المستخدم بالكامل" | "أعد هيكلة get_user_by_email لاستخدام async/await" |
| "أضف تسجيلاً إلى التطبيق" | "أضف تسجيلاً منظماً إلى order_service.py" |
| "اكتب اختبارات لواجهة API" | "اكتب اختبارات وحدة باستخدام pytest للمكوّن POST /api/orders" |
نطاق صغير ومخرجات محددة. يمكنك دائماً ربط الأوامر ببعضها.
السياق أقوى أداة متاحة لك. السياق الأكثر صلة يحسّن المخرجات في الغالب. التحدي هو معرفة ما تضمّه وما تستبعده.
على الأقل، ينبغي أن يتضمن كل أمر غير بسيط:
حتى غياب واحد منها ينتج مخرجات تحتاج تصحيحاً كبيراً.
توجد حدود للتوكنات، وحشو الأمر بكل ملف في مشروعك يعطي نتيجة عكسية. يبدأ الوكيل بفقدان التركيز على المهمة الفعلية عندما يُعطى مادة كثيرة غير ذات صلة.
قاعدة عملية: ضمّن فقط ما هو مجاور مباشرةً للتغيير. إذا كنت تعدّل دالة، فألصق الدالة وتبعياتها المباشرة. إذا كنت تصحح مساراً، فألصق معالج المسار والنموذج الذي يستخدمه. استبعد الوحدات غير ذات الصلة.
💡 نصيحة احترافية: استخدم التعليقات لتلخيص ما تفعله الشيفرة المحذوفة.
// The UserService class handles DB reads. It has find_by_id(id) and update(id, data) methods.يمنح هذا الوكيل سطح API دون استهلاك توكنات كثيرة على التنفيذ الكامل.
وكلاء الذكاء الاصطناعي شركاء تصحيح ممتازون عندما يُعطون المدخل الصحيح. الخطأ الشائع هو أن تطلب من الوكيل إصلاح شيء دون أن تمنحه الصورة الكاملة.
قبل أن تطلب من الوكيل إصلاح خطأ، ضمّن حالة إعادة الإنتاج الأدنى. ليس قاعدة الشيفرة كلها، ولا وصفاً للخطأ. الشيفرة الفاشلة الفعلية، والمدخل الذي يُطلقها، ونص الخطأ بالضبط.
أمر ضعيف: "واجهة API الخاصة بي تُرجع أحياناً خطأ 500، هل يمكنك إصلاحه؟"
أمر قوي:
This function throws a KeyError intermittently:
def process_webhook(payload: dict) -> None:
user_id = payload['user']['id'] # crashes when 'user' is absent
update_subscription(user_id)
Error: KeyError: 'user'
Input that triggered it: {"event": "payment.failed", "amount": 49.99}
Fix the function to handle missing 'user' gracefully. If 'user' is absent, log a warning and return early.
يمنح الأمر الثاني الوكيل كل ما يحتاجه. وسيكون الإصلاح صحيحاً ومتّسقاً مع ما تقصده.
ليس كل تفاعل ينبغي أن ينتهي بعبارة"أصلح هذا". أحياناً تحتاج إلى قراءة ما تفعله قطعة شيفرة قبل تغييرها.
اطلب الشرح عندما:
اطلب الإصلاح عندما:
الجمع بين الأمرين في الطلب نفسه ينتج غالباً جداراً من النص يشرح كل شيء ولا يغيّر شيئاً. فافصل بينهما.
ليست كل نماذج اللغة متساوية في مهام البرمجة. الفروق كبيرة، واستخدام النموذج الخطأ لمهمة ما يضيف احتكاكاً إلى سير عملك.
النماذج الأصغر والأسرع ممتازة في:
النماذج الأكبر والأكثر قدرة تستحق التأخير الإضافي في:
الهدف هو مطابقة قدرة النموذج لتعقيد المهمة. استخدام نموذج استدلال متقدم لإعادة تسمية متغير هدر. واستخدام نموذج صغير وسريع لتصميم استراتيجية تخزين مؤقت موزّعة خطأ.
عدة نماذج متاحة على PicassoIA قوية تحديداً في توليد الشيفرة والاستدلال. Claude 4 Sonnet مصمم للبرمجة الدقيقة واتباع التعليمات، ما يجعله من أفضل الخيارات لسير عمل البرمجة بالوكلاء. ويوسّع Claude 4.5 Sonnet هذه القدرة بقدرات تصحيح أقوى عبر لغات متعددة.
للمطورين الذين يريدون استدلالاً قوياً إلى جانب توليد الشيفرة، يتعامل DeepSeek R1 بكفاءة مع تفكيك المشكلات خطوة بخطوة قبل إنتاج المخرجات. ويُعد Kimi K2 Instruct خياراً جيداً آخر، ويحظى بتقييم عالٍ في الاستدلال ومهام البرمجة.
إذا احتجت إلى نماذج متخصصة في الشيفرة، ومدرّبة تحديداً على مجموعات بيانات برمجية، فيستحق Granite 8B Code Instruct 128K وكذلك Granite 20B Code Instruct 8K من IBM الاختبار. كلاهما مضبوط لإكمال الشيفرة واتباع التعليمات في سياق البرمجة.
بالنسبة للمهام العامة التي تجمع بين الكتابة والتحليل وتوليد الشيفرة، يقدّم GPT 5.1 وكذلك Kimi K2.6 قدرات مرنة لبناء الوكلاء. وتحديداً Kimi K2.6 مصمم لمهام الوكلاء الذكيين متعددة الخطوات حيث يجب أن يعمل الاستدلال ومخرجات الشيفرة معاً.
النصائح المجردة صعبة التطبيق. هذه أمثلة ملموسة قبل وبعد توضح كيف تؤثر جودة الأمر مباشرةً على جودة الشيفرة.
قبل: "أعد هيكلة هذه الدالة لتكون أنظف"
بعد:
Refactor the following Python function. Requirements:
1. Extract the database query into a separate helper called _fetch_user_records
2. Replace the nested if/else with early returns
3. Add type annotations to all parameters and return value
4. Do not change the external behavior or function signature
Current code:
[paste function here]
مخرجات الأمر الثاني لا تحتاج إلى أي إعادة كتابة. فهي تتبع متطلباتك المعلنة بدقة لأنك ذكرتها.
الاختبارات مجال يضيف فيه وكلاء البرمجة بالذكاء الاصطناعي قيمة هائلة عند تحفيزهم بشكل صحيح. الأسلوب هو تحديد السلوكيات المطلوب اختبارها، لا مجرد الملف الذي تريد اختباره.
ضعيف: "اكتب اختبارات لخدمة المستخدم"
قوي:
Write pytest tests for UserService.create_user in src/services/user_service.py.
Test these specific cases:
1. Successful creation returns a user dict with 'id', 'email', and 'created_at' keys
2. Duplicate email raises DuplicateUserError
3. Invalid email format raises ValidationError
4. Missing required fields raises MissingFieldError
Mock the database with unittest.mock.patch. Do not write integration tests.
يُنتج الأمر الثاني أربع حالات اختبار مركّزة وذات معنى تغطي أنماط الفشل الواقعية في الدالة، دون أي معالجة لاحقة من جانبك.
مهارة يُستهان بها هي الأوامر التكرارية: تحسين المخرجات دون التخلي عن سياق المحادثة. بدلاً من إعادة التوليد من الصفر عندما تكون المخرجات قريبة من الصحيح، أرسل التصحيح مباشرة:
src/exceptions.py بدلاً من المدمجة"التصحيحات التكرارية تحافظ على ما نجح وتغيّر فقط ما لم ينجح. وهذا أسرع بعدة مراتب من بدء جلسة جديدة في كل مرة تفوّت فيها المخرجات تفصيلة.
الاستخدام الفردي شيء، لكن عندما يتشارك فريق سير عمل البرمجة بالذكاء الاصطناعي، تفصل بضع ممارسات الفرق عالية الإنتاجية عن الفوضوية.
تنشئ أفضل الفرق قوالب أوامر قابلة لإعادة الاستخدام للمهام المتكررة. قد يتضمن قالب "أضف نقطة نهاية API جديدة" عناصر نائبة لمسار نقطة النهاية، وطريقة HTTP، ومخطط الطلب، ومخطط الاستجابة، ومتطلبات المصادقة. يملأ أعضاء الفريق الجدد الفراغات ويحصلون على مخرجات متّسقة ومتوافقة مع النمط في كل مرة.
هذا يلغي التباين الناتج عن أن يطلب خمسة مطورين "الشيء نفسه" بخمس طرق مختلفة تماماً، فيحصلون على خمسة تطبيقات مختلفة في بنيتها.
يجب مراجعة الشيفرة المولّدة بالذكاء الاصطناعي بالدقة نفسها المطبقة على الشيفرة المكتوبة بأيدي البشر. الوكيل لا يعرف متطلبات الأمان، ولا حساسية بياناتك، ولا حالات الحافة في عملك. يكتب شيفرة تبدو صحيحة. ومهمتك أن تتحقق من أنها صحيحة فعلاً.
💡 عادة حاسمة: لا تدمج أبداً شيفرة مولّدة بالذكاء الاصطناعي دون تشغيلها على مجموعة الاختبارات الفعلية لديك. الوكيل يُحسّن لإنتاج شيفرة تُقرأ بسلاسة، لا شيفرة تتعامل مع حالات الحافة الخاصة ببيئة الإنتاج لديك.
وثّق الأوامر التي تنتج نتائج جيدة باستمرار. شاركها في ويكي فريقك أو مستودعه. الأمر الذي يولّد بموثوقية ترحيلات قاعدة بيانات صحيحة لبيئتك التقنية أثمن من أي قطعة شيفرة منفردة يُنتجها. الأمر هو الأصل القابل لإعادة الاستخدام، والشيفرة هي المخرج.
كل نصيحة في هذا المقال قابلة للتطبيق فوراً. لا تحتاج إلى أدوات جديدة. ولا تحتاج إلى تغيير محررك. تحتاج إلى كتابة أوامر أفضل، والأوامر الأفضل تبدأ بالتحديد والبنية والسياق.
تمنحك PicassoIA وصولاً مباشراً إلى النماذج المذكورة هنا، جنباً إلى جنب، دون تبديل المنصات. سواء أردت الاستدلال العميق الذي يقدّمه Claude 4 Sonnet، أو التدريب الخاص بالشيفرة الذي يتميز به Granite 8B Code Instruct 128K، أو قدرات بناء الوكلاء في Kimi K2.6، يمكنك تشغيل الأمر نفسه تماماً على عدة نماذج ومقارنة جودة المخرجات في ثوانٍ.
ابدأ بدالة واحدة تعمل عليها فعلاً الآن. طبّق صيغة الدور + المهمة + القيد. ضمّن الشيفرة الموجودة ذات الصلة كسياق. حدّد صيغة المخرجات المتوقعة. ثم قارن تلك النتيجة بما كان سينتجه أمرك الغامض السابق. الفرق سيكون واضحاً، والعادة ستثبت.
وكيل البرمجة لا يكون فعالاً إلا بقدر التعليمات التي تعطيها له. أعطه تعليمات أفضل، وأطلق برمجيات أفضل.
اختر لغتك
