صمم طريقة عمل ثابتة بشات جي بي تي بدل برومبت طويل

بعد كل الدروس اللي فاتت، نقدر نوصل للفكرة اللي الدليل كله مبني عليها: المستخدم القوي مش هو الشخص اللي عنده Prompt طويل لكل مهمة، هو الشخص اللي عنده Workflow واضح، يعني طريقة عمل تتكرر من غير ما يبدأ من صفحة فاضية كل مرة.

الـPrompt مهم، لكنه مجرد خطوة داخل النظام. ممكن تكتب Prompt ممتاز مرة، لكن لو كل مرة بتنسى المصادر، أو تبدأ التنفيذ قبل ما تفهم المطلوب، أو تعيد نفس التصحيح، النتيجة هتفضل متذبذبة. الـWorkflow الجيد يثبت المراحل اللي لازم تحصل، ويخلي المتغير الحقيقي هو محتوى المهمة نفسها.

ابدأ من Intake قبل أي تنفيذ

الـIntake هو مرحلة جمع المطلوب. قبل ما ChatGPT يكتب أو يحلل أو ينفذ، لازم تكون الصورة الأساسية واضحة: إيه الهدف؟ مين المستفيد؟ إيه القيود؟ إيه المصادر المتاحة؟ إيه المخرج النهائي؟ وهل في معلومة ناقصة لو اتغيرت هتغير النتيجة؟

مش لازم تعمل Form رسمي في كل مرة. أحيانًا خمس أسئلة داخل Chat كفاية. المهم إنك متبدأش التنفيذ وأنت لسه مش عارف المشكلة الحقيقية.

لو المهمة بسيطة، المرحلة دي ممكن تكون سريعة جدًا. لكن في مشروع كبير، الـIntake نفسه ممكن يمنع ساعات شغل في اتجاه غلط.

بعدها جهز الـContext المناسب

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

حدد الحالة الحالية، القرارات المعتمدة، القيود، وأي معلومات لازم ChatGPT يعرفها عشان ما يبدأش من افتراض غلط. لو الـContext مستمر وطويل، Project أو Files غالبًا أنسب من نسخ نفس المعلومات في كل Prompt.

الفكرة إنك تعمل Context صالح للعمل الآن، مش أرشيف كامل لكل ما حدث.

ثبت مصادر الحقيقة قبل التحليل

قبل ما ChatGPT يبدأ يفكر، لازم يكون واضح هو هيبني تحليله على إيه. هل المصدر ملف؟ صفحة رسمية؟ Spreadsheet؟ App متصلة؟ Web Search؟ مجموعة أبحاث؟

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

وفي المشاريع الطويلة، من المفيد جدًا تحدد النسخة المعتمدة من كل مصدر. ملف اسمه final-v7 لا يعني بالضرورة إنه النسخة الحالية، ووجود ثلاثة ملفات لنفس الموضوع بدون توضيح أيهم Canonical بيخلق مشاكل حتى لو ChatGPT قرأهم كلهم.

افصل Analysis عن Execution لما المهمة تستحق

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

مرحلة Analysis دورها فهم المشكلة، اكتشاف الفجوات، مقارنة الخيارات، وتحديد المخاطر أو التعارضات. بعدها تأتي Decision، يعني تحويل التحليل إلى اختيار أو خطة واضحة. بعد كده فقط تبدأ Execution.

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

مثلًا بدل «ابنِ لي خطة كاملة للمشروع واكتب كل المستندات»، ممكن المرحلة الأولى تكون تحليل المتطلبات والمخاطر، بعدها اعتماد Architecture، وبعدها إنشاء الملفات.

القرار لازم يكون ظاهرًا قبل التنفيذ

بعض الـWorkflows تفضل في تحليل مفتوح بدون ما تتحول لقرار. ChatGPT يعرض ثلاثة مسارات ومميزات وعيوب، وبعدها يبدأ التنفيذ كأنه اختار واحدًا ضمنيًا.

الأفضل تثبت القرار: هنمشي على أي مسار؟ إيه اللي تم استبعاده؟ إيه المعيار؟ وهل في جزء مؤجل؟

القرار الظاهر مهم لأنه يتحول لاحقًا إلى مرجع في الـQA والتصحيح. لو النتيجة خرجت عن المسار، تقدر ترجع للقرار بدل ما تعيد النقاش من البداية.

Execution: اختار الأداة حسب نوع العمل

التنفيذ ممكن يكون كتابة داخل Chat، إنشاء ملف، تحليل بيانات، تشغيل Work لمهمة طويلة، استخدام Browser، Skill متخصصة، أو تطبيق متصل. الأداة مش هي الـWorkflow، هي مجرد الوسيلة اللي تنفذ المرحلة.

دي نقطة مهمة لأن ناس كتير تبني الـWorkflow حول الأداة: «عايز أستخدم Work»، «عايز أستخدم Deep Research»، قبل ما تحدد أصلًا طبيعة المهمة. الصح العكس، افهم المرحلة، وبعدها اختار أقل أداة تكفي.

لو المطلوب تعديل فقرة، Chat تكفي. لو المطلوب دراسة متعددة المصادر، Deep Research ممكن يكون أنسب. لو المطلوب تنفيذ سلسلة طويلة وDeliverable نهائي، Work تدخل. مفيش ميزة لازم تستخدمها لمجرد إنها موجودة.

الـQA يرجع للمتطلبات الأصلية

المراجعة مش معناها تسأل ChatGPT «راجع شغلك» وخلاص. الـQA الجيدة تقارن الناتج بالهدف والقيود والمصادر التي بدأت بها.

هل كل المطلوب اتنفذ؟ هل جزء اتغير من غير قصد؟ هل الأرقام مطابقة للمصدر؟ هل Format صحيح؟ هل الملف يفتح؟ هل المخرجات مناسبة للشخص اللي هيستخدمها؟

كل ما كان الـIntake واضح، الـQA تبقى أقوى، لأن عندك معيار تقيس عليه بدل الانطباع العام.

Correction: صحح الطبقة المسؤولة

لو الـQA كشفت مشكلة، متعيدش كل العملية من الصفر تلقائيًا. اسأل المشكلة حصلت فين: Source غلط؟ Context ناقص؟ Decision غير واضح؟ Instruction متعارضة؟ تنفيذ سيئ؟

لو عرفت الطبقة، صححها هي. ده يقلل إعادة العمل، والأهم إنه يمنع المشكلة تتكرر في الدورة التالية.

مثلًا لو الناتج استخدم نسخة قديمة من الملف، المشكلة في Source Selection، مش في جودة الكتابة. ولو كل مرة النتيجة طويلة، يمكن Project Instructions أو Skill تحتاج تعديل، مش النص الحالي فقط.

Knowledge Update: هنا النظام يبدأ يتعلم

بعد التصحيح، اسأل هل الملاحظة محلية ولا قابلة للتكرار. لو هي مجرد خطأ عابر، خلاص. لو ظهرت قاعدة مفيدة، خزّنها في المكان المناسب: Project Instruction، Skill، Memory، أو Source of Truth.

دي المرحلة اللي تفرق بين نظام يتحسن ونظام يعيد نفس الأخطاء. لو أنت كل أسبوع بتقول نفس الملاحظة وما بتحدثش أي طبقة، يبقى الـWorkflow ما اتعلمتش شيء.

لكن برضه متحولش كل تصحيح إلى قاعدة دائمة. اختبر الأول إن المشكلة متكررة وإن القاعدة صالحة لأكثر من حالة.

Archive: ما تسيبش النتيجة النهائية مدفونة في Chat

لو الناتج له قيمة مستقبلية، احفظ النسخة النهائية في مكان واضح. ملف معتمد، Project Source، Library، أو النظام اللي فريقك بيستخدمه.

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

ومن المفيد أحيانًا تحفظ مع الناتج ملخصًا للقرار: ما الذي تم اعتماده، ما المصدر، وما الذي تم استبداله. ده يقلل الالتباس في الدورة القادمة.

Repeat: المرة التالية لا تبدأ من الصفر

الـWorkflow الحقيقي يظهر في التكرار. لما نفس المهمة ترجع، تستخدم الهيكل نفسه لكن ببيانات جديدة. يمكن الـIntake تكون أقصر، والمصادر تتحدث، والـQA تقارن بالنسخة السابقة بدل إعادة تحليل كل شيء.

هنا تبدأ تستفيد من Skills وProjects وTasks، لأنك عندك عملية واضحة تستحق التنظيم أو الأتمتة.

لو أنت لسه كل مرة بتجرب طريقة مختلفة لأنك مش عارف أصلًا الخطوات الأساسية، متستعجلش تعمل Automation. الأول افهم العمل يدويًا، بعدين ثبته.

مثال عملي: تقرير أسبوعي

تخيل إنك كل أسبوع تعمل تقرير أداء لفريق صغير. بدل ما كل أسبوع تقول «اعمل التقرير»، الـWorkflow ممكن تكون كالتالي: تجمع بيانات الأسبوع، تثبت مصادرها، تقارنها بالأسبوع السابق، تحدد أهم التغيرات، تكتب تفسيرًا، تعمل QA للأرقام، وبعدها تحفظ النسخة النهائية وتحدّث أي قرار جديد.

لو العملية اتكررت واستقرت، Skill ممكن تمسك طريقة التحليل، Project يحتفظ بالسياق والملفات، Task تضمن التشغيل في الموعد، وWork تنفذ العملية الطويلة لو فيها مصادر كثيرة. كل طبقة دخلت بعد ما فهمنا الـWorkflow، مش قبلها.

الطريقة الغلط: Prompt ضخم يحاول يحمل النظام كله

لما تحط Intake وSources وRules وFormat وHistory وQA في Prompt واحدة، أنت بتحاول تخلي الرسالة نفسها تقوم بوظيفة Project وSkill وSource وWorkflow في نفس الوقت. ممكن تنجح مرة، لكن إعادة استخدامها هتبقى مرهقة وهشة.

الطريقة الأفضل إنك تثبت ما هو ثابت في طبقته، وتترك الرسالة الحالية فقط للمعلومات المتغيرة في هذه المهمة.

الخلاصة

Prompt واحد ممكن ينجح، لكن Workflow واضحة تقدر تنتج جودة مستقرة مرارًا. اجمع المطلوب، جهز السياق، حدد المصدر، حلل، قرر، نفذ، راجع، صحح، حدث المعرفة، واحفظ النسخة النهائية.

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