راجع فكرة منتج قبل البناء

مراجعة مشكلة المستخدم ونطاق النسخة الأولى والأدلة الناقصة، مع إصلاحات محددة بدل المديح العام.

جهّز البرومبت

قبل توسيع فكرة منتج أو الالتزام بتنفيذها.

النص الجاهز للنسخ

النسخة العربية

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

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

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

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

المسودة:
<مسودة>
{{الصق وصف المشكلة والمستخدم والفكرة والقيود هنا}}
</مسودة>

طريقة الاستخدام

اكتب المشكلة والمستخدم والنسخة الأولى والأدلة المتوفرة.
أرسل البرومبت والمسودة إلى مساعدك، وأجب عن الأسئلة.
تحقق من النقد بالأدلة؛ اختبر الفكرة مع مستخدمين قبل البناء.

المصدر والترخيص والمراجعة

المصدر: prompts.chat · PRD Critic for Early-Stage Startups

ترخيص المصدر: CC0-1.0. تعريب وتكييف: adwatonline.

تنزيل الحزمة والمصدر ZIP · الأصل والترخيص وبيان التعديلات.

مراجعة تحريرية للمدخل والنتيجة المرجعية وحدود الاستخراج. المثال افتراضي محرر؛ لا يمثل مقارنة أداء مستقلة بين نماذج.

آخر مراجعة تحريرية: 2026-10-13

مثال مكتمل

بيانات افتراضية للتوضيح. اضغط «تعبئة مثال افتراضي» لتجهيز المدخل نفسه.

المدخل

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

نتيجة مرجعية محررة

المراجعة تبدأ بأسئلة توضيحية، لأن معلومات حاسمة ناقصة:
1. أي نوع من المتاجر هو المستخدم الأساسي؟
2. ما المثال الفعلي لطلب ضاع أو تأخرت متابعته؟
3. من يتخذ قرار الشراء ويدفع؟
4. أي مهمة واحدة يجب أن تغطيها التجربة الأولى؟
5. كيف سنختبر الطلب قبل بناء النظام؟

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

قارن إجابة مساعدك بالأصل: لا أرقام أو قرارات أو مسؤولون مخترعون. صياغة الإجابة قد تختلف. المثال ليس نتيجة اختبار مستقل لنموذج.