ع ▾
Čeština
دخولابدأ مجانًا
الرئيسية › الأدلة › كتابة أوامر الذكاء الاصطناعي: تعليمات واضحة ونتائج قابلة للاختبار

كتابة أوامر الذكاء الاصطناعي: تعليمات واضحة ونتائج قابلة للاختبار

نُشر في · آخر تحديث

تبدأ كتابة أوامر الذكاء الاصطناعي بتحديد النتيجة المطلوبة والسياق والقيود وطريقة التحقق من النجاح. استخدم أمثلة صغيرة ومراجعات محددة، وافصل طلبك عن المواد التي تقدمها للتحليل.

حدد النتيجة قبل كتابة الطلب

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

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

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

قدم سياقًا مختصرًا وأمثلة مفيدة

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

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

عند مشاركة ملف أو صورة، بين ما تريد الاستفادة منه: ترتيب العناصر أو النصوص أو البيانات أو اللون. لا تجعل المرجع الغامض بديلًا عن المطلوب. استخدم بيانات تجريبية واضحة بدل معلومات عملاء حقيقية عندما يكفي المثال. افصل الحقائق المعروفة عن المقترحات، ولا تقدم أرقامًا تقريبية وكأنها نهائية. احتفظ بالموجز الأساسي خارج المحادثة ليسهل تحديثه وإعادة استخدامه دون نقل تفاصيل قديمة إلى مهمة جديدة.

راجع النتيجة وعدل سبب الخلل

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

اكتب التصحيح في ثلاثة أجزاء: ما حدث، وما المتوقع، وكيف يمكن إعادة التجربة. مثلًا: «عند إرسال النموذج بوصف فارغ ظهرت رسالة نجاح؛ المتوقع تنبيه قرب الحقل وعدم إنشاء طلب؛ كرر التجربة ثم تحقق من السجلات». اطلب تغيير هذا السلوك مع عرض ما تغير وطريقة فحصه. إذا كان الخلل في البيانات فلا تكتف بتعديل الرسالة، لأن الواجهة قد تبدو صحيحة بينما يستمر إنشاء سجلات غير مناسبة.

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

افصل المحتوى الخارجي عن سلطة التعليمات

قد يحتوي ملف أو موقع على تعليمات تحاول تحويل المهمة؛ وهذا من مخاطر حقن التعليمات. قدم المواد بوصفها بيانات للتحليل. الفصل النصي يساعد على الوضوح لكنه لا يضمن الحماية. اجعل التحقق من الصلاحيات وضوابط الأدوات خارج النموذج، واقصر الوصول على ما تحتاجه المهمة.

راجع التغييرات غير المتوقعة بعد قراءة محتوى خارجي، ولا تضع الأسرار في الطلب. خصص مراجعة بشرية للعمليات الحساسة. مرجع تعريف المخاطر: https://genai.owasp.org/llmrisk/llm01-prompt-injection/ ومرجع مراجعة تغييرات البرمجة: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html . هذه إجراءات لتقليل الخطر وليست شهادة أمان للتطبيق.

أسئلة

هل الطلب الأطول أفضل؟

ليس بالضرورة؛ أضف التفاصيل التي تغير النتيجة واحذف التكرار. قارن طلبين باستخدام الحالات ومعايير القبول نفسها قبل اعتماد أحدهما.

كيف أطلب تصحيحًا مفيدًا؟

حدد السلوك الفعلي والمتوقع وخطوات إعادة التجربة. أرفق مثالًا مناسبًا واطلب بيان التغيير وطريقة التحقق من النتيجة.

هل أحتاج إلى أسلوب رسمي؟

الوضوح أهم من الرسمية. استخدم لغة تعرفها وأسماء ثابتة للحقول والشاشات، واطلب نتيجة محددة يمكن مراجعتها.

متى أعيد استخدام الطلب؟

بعد حفظ نسخة حققت المعايير في الحالات المختبرة. حدّث السياق والأسماء والمخرجات عند تغير المشروع، ثم أعد الفحص بدل افتراض استمرار الصلاحية.

ابدأ مجانًا القوالب

جاهز تبني فكرتك؟

ابدأ الآن مجانًا — أول تطبيق لك قد يكون جاهزًا خلال دقائق.

ابدأ مجانًا