الـ prompt الجيد يخبر النموذج بما تريدونه ويعطيه معلومات كافية ليبدأ. في هذا الفيديو سنعمل على طلب غامض، ونحسّنه من خلال الأسئلة، ونستخدم الأمثلة لنوضّح المُخرَجات التي نحتاجها. وسننظر أيضًا في إعطاء الوكيل هدفًا وفحصًا. كل تغيير في الـ prompt قد يغيّر احتمالات الـ token التالي التي يسحب منها النموذج عيّنته، فغيّروا عن قصد وتحقّقوا إن كان التغيير قد أفاد.
لنبدأ بطلب غامض: «اكتب دالة تعالج البيانات». الطلب يذكر مهمة، لكنه يترك معظم السلوك دون تحديد.
ما صيغة البيانات؟ وأيّ الحقول مهمة فعلًا؟ وماذا يجب أن يحدث عندما تكون المُدخَلات غير سليمة؟ إذا تركنا هذه الأسئلة بلا إجابة، فقد يضع النموذج افتراضاته الخاصة. وكل افتراض موضع قد تختلف فيه النتيجة عمّا قصدناه.
يمكنكم كتابة التفاصيل بأنفسكم. لكن في مهمة فيها عدة قرارات لم تُحسم، قد تكون محادثة قصيرة أسهل. اطلبوا من النموذج أن يطرح عليكم أسئلة قبل أن يكتب الكود. مثلًا: «اطرح عليّ أسئلة حتى تتضح المتطلبات، ثم اكتب الدالة». ويمكنكم أيضًا أن تطلبوا منه تلخيص ما اتفقتم عليه قبل أن يبدأ.
الآن تعود إليكم الثغرات نفسها على شكل أسئلة. ما صيغة البيانات؟ وأيّ الحقول مهمة؟ وماذا يجب أن يحدث مع سطر غير سليم؟ تجيبون عن الأسئلة واحدًا تلو الآخر. النموذج يساعد في إيجاد الثغرات، وأنتم تقرّرون السلوك الذي تريدونه. أضيفوا أي شيء مهم لم يسأل عنه.
بعد الإجابة عن الأسئلة، يصبح الطلب محدّدًا. فهو يسمّي الدالة ووسيطها ونوع القيمة التي تُعيدها، ويحدّد بدقة السلوك الذي نريده. «اقرأ الملف بصيغة JSONL، وتخطَّ أي سطر يتعذّر تحليله». النموذج لم يصبح أذكى. لقد أزلنا التخمين بشأن نوع الدالة ونطاقها وسلوكها، قبل أن يبدأ. والآن يمكننا أن نتحقّق من الكود وفق هذه القرارات.
تخيّلوا أنكم تسلّمون الـ prompt لزميل. إذا احتاج إلى أن يسأل عن المُدخَلات أو المُخرَجات أو القيود، فالنموذج يحتاج إلى هذه المعلومات أيضًا. يمكنكم تقديمها مباشرة، أو التوصّل إليها من خلال الأسئلة. الغموض أحد الأسباب الشائعة للنتائج غير المرغوبة. عندما يفعل النموذج الشيء الخطأ، تحقّقوا مما تركه الـ prompt دون تحديد، إلى جانب التحقّق من صحة التنفيذ نفسه.
المثال الأول كان دالة واحدة، وكانت الأسئلة المفتوحة تدور حول سلوكها. أما المهمة التي نعطيها لوكيل فتحتاج إلى شيئين آخرين. خذوا مثلًا الطلب «حسّن الكود». فهو لا يحدّد ما معنى «أفضل»، لذا على الوكيل أن يخمّن. ولا يقدّم أيضًا طريقة لمعرفة متى يكتمل العمل.
قارنوا ذلك بهذا: «يفشل تسجيل الدخول حين يحوي البريد الإلكتروني أحرفًا كبيرة. أضف اختبارًا يُعيد إنتاج الخطأ، ثم أصلحه». هذا الطلب يحدّد المشكلة ويقدّم فحصًا ملموسًا. الاختبار الذي يفشل قبل الإصلاح وينجح بعده دليل على أن التغيير يعالج الخطأ.
هذا الطلب يترك تفاصيل التنفيذ للوكيل. ولا يفرض تعديلًا سطرًا بسطر. بدلًا من ذلك، تعطونه الهدف ومعه طريقة لمعرفة ما إذا كان العمل قد نجح.
وأضيفوا أي قيود يجب أن يلتزم بها. وإذا كان نهج معيّن مطلوبًا، فقولوا ذلك واشرحوا السبب.
والآن لنأخذ مهمة صغيرة لا علاقة لها بالكود. نريد من النموذج أن يصنّف المشاعر في تقييمات المطاعم. الطلب بلا أمثلة محلولة يُسمّى zero-shot prompting. تصفون المهمة والصيغة التي تريدونها بالكلمات.
أما few-shot prompting فيعني إضافة بضعة أمثلة محلولة أولًا. كل مثال يضع تقييمًا إلى جانب تصنيفه. «أفضل باستا في المدينة» تصنيفه positive. «حساء بارد ونادل فظّ» تصنيفه negative. و«طعام رائع، لكن الانتظار طويل» تصنيفه mixed. نحن لا نعلّم النموذج ما هي المشاعر. فهو يعرف ذلك من تدريبه. الأمثلة تُظهر التصنيفات التي نستخدمها، ومنها mixed، وتُظهر أن الإجابة كلمة واحدة.
من دون أمثلة، قد يجيب النموذج بجملة كاملة، وقد يميل إلى أحد الطرفين: إيجابي أو سلبي. قد تكون الإجابة معقولة، ومع ذلك لا تكون أحد تصنيفاتنا. أما مع الأمثلة، فالردّ كلمة واحدة هي mixed. وهو يتبع النمط الذي قدّمناه.
الأمثلة تُري النموذج كيف تبدو الإجابة المناسبة. وهنا توضّح التصنيفات والصيغة. ابدؤوا ببضعة أمثلة تمثيلية. ثلاثة إلى خمسة أمثلة عدد معقول للبداية، ثم يمكنكم اختبار ما إذا كان المزيد يفيد. ويمكن للأمثلة أيضًا أن توضّح المهمة أو تُظهر كيفية التعامل مع حالة غير مألوفة. اختاروها بحسب ما يحتاج النموذج إلى تعلّمه من هذا الـ prompt.
بعض عادات الكتابة تجعل المهمة أسهل فهمًا. أولًا، قولوا ما تريدون أن ينتجه النموذج. «اكتب نثرًا» أكثر تحديدًا من «لا تستخدم Markdown»، فالعبارة الثانية لا تزال تترك عدة صيغ ممكنة.
ثانيًا، اذكروا السبب عندما يساعد على شرح المطلب. مثلًا، قولوا إن محرّك تحويل النص إلى كلام سيقرأ النص بصوت مسموع. السبب يساعد النموذج على اتخاذ قرار معقول في الحالات ذات الصلة التي لم يخطر لكم أن توضّحوها صراحة.
ثالثًا، وضّحوا الإجراء المطلوب. «غيّر X» يطلب تعديلًا. «اقترح تغييرًا على X» يطلب نصيحة. قولوا ما تقصدونه فعلًا. لا بأس بالتهذيب. المهم أن يتضح هل على الوكيل أن ينفّذ أم يشرح أم ينتظر قراركم.
رابعًا، اطلبوا بنية محدّدة عندما تحتاجونها. إذا أردتم المُخرَجات على شكل وسوم، أو JSON، أو وفق مخطط معيّن، فقولوا ذلك صراحة في الـ prompt. معالجة المُخرَجات المنظَّمة أسهل بكثير على بقية برنامجكم، والتحقّق منها أسهل بكثير عليكم.
خامسًا، اطلبوا من الوكيل تشغيل الفحوصات المناسبة قبل أن يعلن أنه انتهى. عند تغيير الكود، قد يعني ذلك الاختبارات أو أداة فحص الأنواع. انظروا إلى النتائج، بما في ذلك أي شيء لم يتمكّن من تشغيله.
سادسًا، إذا شعرتم أن كتابة prompt مفصّل مُتعِبة، فقولوه بصوتكم. يوفّر Claude Code الإملاء الصوتي لهذا الغرض. اكتبوا /voice لتفعيله، ثم أبقوا مفتاح المسافة مضغوطًا أثناء الكلام. ويوفّره Codex في تطبيق سطح المكتب، لكن ليس في نسخته للطرفية. الكلام يتطلب جهدًا أقل بكثير من الكتابة، لذا ستجدون أن إعطاء prompts أطول وأكثر تفصيلًا أسهل.
يمكنكم استخدام هذه العادات معًا: حدّدوا المهمة، واشرحوا القيود ذات الصلة، وأظهروا الصيغة، واطلبوا الفحوصات. احتفظوا بالأجزاء التي تفيد مشروعكم.
نراكم في الفيديو التالي.