تزويد وكيل البرمجة بالسياق المناسب

تطلب نقطة نهاية (endpoint) جديدة. ينتجها الوكيل: صحيحة، مختبَرة، مقروءة. لكنه يستخدم requests بينما المشروع كله يعتمد httpx، ويعيد قاموسًا خامًا في حين تعيد مساراتك الاثنا عشر الأخرى مخطط Pydantic، ويكتب رسائل الخطأ بالإنجليزية في قاعدة شيفرة ناطقة بالفرنسية بالكامل. تقضي عشرين دقيقة في إعادة هذه الشيفرة إلى معايير فريقك، وهي عشرون دقيقة كان بإمكانك توفيرها لو كتبت ثلاثة أسطر من السياق في البداية.

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

أي الملفات تعرض

تكفي ثلاث فئات في الغالب الأعم.

الملف المراد تعديله. أمر بديهي، لكن كن دقيقًا في تحديد المنطقة: دالة محددة بالاسم أفضل من ملف من 800 سطر.

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