تشريح الـ Prompt — من إيه بيتكوّن

زي ما تطلب شغل من زميل: تقوله المطلوب إيه، تديله المعلومات اللي محتاجها، تحدّدله الممنوعات، وتقوله سلّمهولي إزاي. الموديل بالظبط زيه.

فكّر فيه كـ ticket شغل: عنوان، وصف، acceptance criteria. الموديل بينفّذ أحسن لما الـ ticket مترتّب.

«لخّص النص ده (مهمة) للعملاء غير التقنيين (سياق) في ٣ نقاط بحد أقصى (قيد) على شكل bullet points (صيغة)» — كل جزء واضح لوحده.

الموديل بيقرا الـ prompt كله كنص واحد متواصل، فلو الأجزاء ملخبطة في بعض بيوزّن الحاجات غلط. لما تفصل المهمة والسياق والقيود والصيغة بعناوين أو فواصل واضحة (زي --- أو XML tags)، كل جملة بيبقى ليها دور واضح — وإنت كمان بتقدر تعدّل جزء واحد وقت الـ debugging من غير ما تلمس الباقي. قاعدة عملية: التعليمات في الأول، والبيانات اللي الموديل هيشتغل عليها في الآخر جوه فواصل.

🧪 جرّب بنفسك: هات prompt طويل من شغلك (أو من التمرين المرفق) وقسّمه لأجزائه الأربعة: مهمة، سياق، قيود، صيغة. لو لقيت جزء ناقص، ده غالبًا سبب الردود الملخبطة — كمّله، وشغّل النسختين وقارن.

• بتحط النص اللي الموديل هيشتغل عليه جوه كلام التعليمات من غير فواصل، فبيلخبط بين «البيانات» و«الأوامر».
• بتفترض قيود من غير ما تكتبها («أكيد فاهم إني عايزه قصير») — اللي مش مكتوب في الـ prompt مش موجود.
• بتوصف الصيغة بجملة غامضة زي «رتّبه كويس» بدل ما تدّي مثال واضح للشكل المطلوب.

أي prompt هيتحط في كود أو هيتستخدم أكتر من مرة، وأي prompt عدّى ٣-٤ سطور — التقسيم بيوفّر عليك ساعات debugging بعدين.

سؤال سريع لمرة واحدة في الشات — التقسيم الرسمي هنا overhead من غير مكسب. اكتب سؤالك عادي وخلاص.