عبارة «حسّن المطالبة» ليست خطة اختبار. من دون تعريف للنجاح، قد تجعل الناتج أكثر سلاسة بينما يصبح أقل دقة أو اتساقاً أو سهولة في المراجعة. تمنح حلقة تقييم خفيفة عمل المطالبات الانضباط نفسه الموجود في أي تحسين آخر للمنتج.
حدد المهمة وأنماط الفشل
ابدأ بمهمة المستخدم. ما القرار أو الخطوة التالية التي ينبغي أن يدعمها الناتج؟ حوّل ذلك إلى فحوص يمكن ملاحظتها مثل الدقة، والأقسام المطلوبة، والنبرة، والطول، والتنسيق، والتعامل الآمن مع عدم اليقين. واكتب أيضاً ما يجب ألا يحدث أبداً، مثل اختلاق مراجع أو كشف بيانات خاصة أو تقديم إجابة واثقة عندما لا يذكر المصدر شيئاً.
أنشئ مجموعة اختبارات صغيرة تمثل الواقع
تتضمن المجموعة المفيدة عادةً حالة عادية، وحالة قصيرة أو ناقصة، وحالة صعبة، وحالة يجب رفضها أو تصعيدها إلى إنسان. أبق المدخلات ثابتة عند مقارنة نسخ المطالبة. إذا احتوت المجموعة على أمثلة مثالية فقط، فستحسن عرضاً تجريبياً لا سير العمل الحقيقي.
غير متغيراً واحداً في كل مرة
سجل نسخة المطالبة والنموذج والإعدادات المهمة والمدخل ونتيجة التقييم. عدل تعليمة واحدة أو قيداً واحداً للناتج، ثم شغل المجموعة نفسها مرة أخرى. بهذه الطريقة يصبح السبب والنتيجة أوضح، ولا تتراكم تعديلات طويلة لا يستطيع أحد تفسيرها.
اجمع بين الفحوص الآلية والحكم البشري
تتميز الفحوص الآلية بالبنية، مثل العناوين المطلوبة أو JSON الصحيح أو حد الكلمات أو وجود مرجع للمصدر. لكن المراجعة البشرية ضرورية للفائدة والدقة المعنوية ومدى اتباع نية المهمة. اجعل قائمة التقييم قصيرة بما يكفي ليطبقها زميلان باتساق.
حسّن التعليمات لا المثال وحده
عندما يفشل الناتج، اسأل أي جزء من العقد كان غامضاً. هل تحتاج المطالبة إلى اسم أوضح للمدخل؟ أو مثال مضاد؟ أو قاعدة عند غياب معلومة؟ أو مثال للتنسيق؟ أصلح أصغر تعليمة تعالج الفشل، ثم أعد تشغيل المجموعة كاملة. يكون التحسين موثوقاً فقط عندما يصلح الحالة المستهدفة دون كسر حالة أخرى.
احتفظ بسجل للقرارات
مع كل تغيير منشور، احفظ ما تغير ولماذا، والحالات التي تحسنت أو تراجعت. يحمي السجل الفريق من العودة إلى فشل قديم ويساعد المسؤولين الجدد على فهم المفاضلات. يستطيع PromptVar جمع القالب ومتغيراته وسياق إصداره حتى يصبح الاختبار جزءاً من سير العمل لا جدولاً منسياً.
