كيف تمنح وكيل البرمجة بالذكاء الاصطناعي "تعريفًا واضحًا للإنجاز"

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

هذا يجعل تعريفك للإنجاز أعلى شيء يمكنك كتابته تأثيرًا. يتناول هذا الدليل كيف تكتب تعريفًا يستطيع الوكيل التصرّف بناءً عليه فعلًا.

معايير القبول مقابل تعريف الإنجاز

فكرتان مترابطتان يجدر الفصل بينهما:

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

اعتبر معايير القبول بمثابة "هل بنينا الشيء الصحيح"، وتعريف الإنجاز بمثابة "هل بنيناه وفق معاييرنا". يحتاج وكيلك إلى كليهما. (يقدّم Atlassian مدخلًا جيدًا للتفريق بينهما.)

اجعله قابلًا للاختبار، لا مجرد تطلّع

معيار المعيار الجيد: هل يمكن لسكربت — أو للوكيل نفسه — أن يتحقق مما إذا كان صحيحًا؟ عبارة "ينبغي أن يبدو نموذج تسجيل الدخول سريعًا" غير قابلة للتحقق. أعِد صياغتها إلى شيء له حدّ حاسم:

• إرسال بيانات اعتماد صحيحة يعيد التوجيه إلى /dashboard خلال 500 مللي ثانية
• إرسال كلمة مرور خاطئة يُظهر خطأً مضمّنًا ولا ينتقل بعيدًا
• إرسال حقل فارغ يُحظر من جانب العميل قبل أي طلب شبكي
• عمليات الدخول الفاشلة محدودة المعدل عند 5 محاولات في الدقيقة لكل عنوان IP

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

مثال ملموس

قارن بين هذين الطلبين للمهمة نفسها.

الغامض:

أضِف طريقة للمستخدمين لإعادة تعيين كلمة المرور.

مع تعريف للإنجاز:

أضِف تدفّق إعادة تعيين كلمة المرور. الإنجاز يعني:

• نقطة نهاية POST /auth/reset-request تقبل بريدًا إلكترونيًا وتُعيد دائمًا 200 (لا تكشف مطلقًا ما إذا كان البريد موجودًا)
• يُرسَل عبر البريد رمز موقَّع وحيد الاستخدام صالح لمدة ساعة واحدة باستخدام المُرسِل الحالي في src/lib/mail.ts
• نقطة النهاية POST /auth/reset-confirm تتحقق من صحة الرمز، وتفرض سياسة كلمة المرور الحالية، وتُبطل الرمز بعد الاستخدام
• تغطّي الاختبارات: إعادة تعيين صحيحة، رمز منتهي الصلاحية، رمز مُعاد استخدامه، بريد غير معروف
• لا اعتماديات جديدة دون الإشارة إليها أولًا

النسخة الثانية ليست أطول لأنها بيروقراطية — بل هي أطول لأن كل غموض كان الوكيل سيخمّنه أصبح الآن محسومًا. فالخيارات الحسّاسة أمنيًا (عدم تسريب وجود الحساب، وانتهاء صلاحية الرموز، والاستخدام لمرة واحدة) هي أقل ما تريد أن يرتجله الوكيل.

اربط "الإنجاز" بحلقة عمل الوكيل

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

لذا لا تكتفِ بوصف الإنجاز — امنح الوكيل وسيلة للتحقق منه:

• وجّهه إلى أمر الاختبار (npm test، pytest) وأخبره بأن الميزة ليست منجزة حتى تنجح.
• بالنسبة للأمور التي يصعب التحقق منها بالكود — قابلية القراءة، أو اتباع نمط قائم — استخدم تمريرة LLM-as-a-judge: طلبٌ ثانٍ يراجع المُخرَج مقابل معيار جودتك. وقد وجدت Anthropic وغيرها أن ذلك فعّال للفحوص الذاتية الطابع.
• أبقِ الأمن ومبدأ "لا كود نائب/وهمي" ضمن تعريفك للإنجاز الشامل للمشروع بحيث ينطبق على كل تغيير، لا على ما تتذكّر ذكره فقط.

ضعه حيث يراه الوكيل

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

التحوّل دقيق لكنه اللعبة كلها: مع وكيل قادر، تكفّ معايير القبول عن كونها ملاحظة إلى زميل وتصبح المواصفة التي يُبنى الكود وفقها. فاكتبها على هذا الأساس.