هذا البرومبت يمنحك مراجعة كود مهندس أول من أي ذكاء اصطناعي
Why this prompt matters
Generic 'review my code' prompts produce generic responses: vague suggestions, no line references, no prioritisation. This prompt enforces a specific output structure that separates critical bugs from architecture concerns from style improvements — the same mental model a senior engineer uses when reviewing a PR. The 'What's Done Well' section is intentional: it keeps the feedback calibrated and makes it easier to act on criticism when you also know what to preserve.
What we use it for
Developers who want high-quality code review feedback without blocking on a colleague's availability. Works for any language or framework — paste the function, class, or diff and get structured, specific feedback in seconds.
Prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows: **Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions): For each: state the line number, explain precisely why it's a problem, and show the corrected code. **Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain): 1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode. **Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better): Practical, specific suggestions. Reference line numbers. Show before/after where relevant. **What's Done Well**: 2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note. Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why. [PASTE YOUR CODE HERE]
طلب 'راجع الكود الخاص بي' من ذكاء اصطناعي ينتج نفس المخرجات العامة في كل مرة: قائمة أشياء للنظر فيها، بدون أولويات، بدون إشارات للأسطر، ونصائح قد تنطبق على أي قاعدة كود. البرومبت أدناه يحل هذه المشكلة بتطبيق الهيكل الدقيق الذي يستخدمه مهندس أول أثناء مراجعة Pull Request حقيقية.
البرومبت
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows:
**Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions):
For each: state the line number, explain precisely why it's a problem, and show the corrected code.
**Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain):
1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode.
**Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better):
Practical, specific suggestions. Reference line numbers. Show before/after where relevant.
**What's Done Well**:
2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note.
Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why.
[PASTE YOUR CODE HERE]كيفية الاستخدام
استبدل [PASTE YOUR CODE HERE] بالدالة أو الكلاس أو الموديول أو Diff الذي تريد مراجعته. يعمل بشكل أفضل مع Claude Sonnet وGPT-4o وGemini 2.5 Pro — جميعها تمتلك نافذة سياق كافية لمعالجة ملفات تصل إلى بضع مئات من الأسطر دون الحاجة لتقسيمها.
بالنسبة للملفات الأكبر، الصق القسم الأكثر حرجًا (الدالة التي تحتوي على الخلل، الكلاس الجديد، الميثود المعدل) بدلاً من الملف بأكمله. إذا كان السياق مهمًا، أضف وصفًا مختصرًا قبل الكود: 'هذه وسيطة Express.js مكتوبة بـ Node.js تعالج المصادقة. مخطط قاعدة البيانات ذو الصلة هو users(id, email, password_hash, role).'
لماذا يهم الهيكل
يقوم الهيكل المكون من أربعة أقسام بتعيين كيفية ترتيب أولويات المهندسين ذوي الخبرة للتغذية الراجعة. Critical Issues عوائق — يجب إصلاحها قبل الدمج. Architecture Concerns ليست عوائق اليوم لكنها تصبح عوائق عند التوسع. Improvements هي للمرور الاحتياطي. فصل هذه الأمور يمنع وضع الفشل الشائع لمراجعة كود الذكاء الاصطناعي حيث يحصل انتقاد أسلوبي على نفس وزن ثغرة SQL Injection.
التعليمات بإظهار الكود المصحح (وليس مجرد وصف الإصلاح) هو القيد الأهم. بدونها، يميل مراجعو الذكاء الاصطناعي إلى الإشارة إلى المشكلة — 'يمكن تحسين معالجة الأخطاء هنا' — دون إخبارك بما يجب كتابته. إلزام الكود المصحح يفرض التحديد.
التكيف مع السياقات المحددة
أضف سياقًا في أعلى البرومبت للحصول على نتائج أفضل: حدد اللغة والإطار، بيئة النشر (Serverless، حاويات، Embedded)، قيود الأداء، أو اتفاقيات الفريق. بالنسبة للكود الحساس أمنيًا، أضف 'انتبه بشكل خاص للتحقق من الإدخال، SQL Injection، XSS، وحالات المصادقة الحدودية' إلى قسم Critical Issues. بالنسبة للمسارات الحرجة للأداء، أضف 'يتم استدعاء الدالة 10,000 مرة في الثانية في الإنتاج.'
يعمل البرومبت عبر أي لغة برمجة. تم اختباره على Python وTypeScript وGo وRust وJava وSQL بنتائج متسقة عبر النماذج الثلاثة الحدودية.