دریافت بازبینی کد مهندس ارشد از هر هوش مصنوعی با این پرامپت
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 Review واقعی استفاده میکند، حل میکند.
پرامپت
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 دارد — همه این مدلها پنجره زمینه کافی برای مدیریت فایلهای تا چندصد خط را بدون نیاز به تقسیمبندی دارند.
برای فایلهای بزرگتر، بخش بحرانیترین (تابعی که باگ دارد، کلاس جدید، متد تغییر یافته) را بچسبانید، نه کل فایل را. اگر زمینه اهمیت دارد، یک توضیح کوتاه قبل از کد اضافه کنید: «این یک Middleware Express.js نوشتهشده با Node.js است که احراز هویت را مدیریت میکند. طرح پایگاه داده مرتبط users(id, email, password_hash, role) است.»
چرا ساختار اهمیت دارد
ساختار چهاربخشی نحوه اولویتبندی بازخورد توسط مهندسان با تجربه را منعکس میکند. Critical Issues مسدودکننده هستند — باید قبل از ادغام رفع شوند. Architecture Concerns امروز مسدودکننده نیستند اما در مقیاس بزرگ مسدودکننده میشوند. Improvements برای گذرهای خوشایند هستند. جداسازی این موارد از حالت شکست رایج بازبینی کد هوش مصنوعی جلوگیری میکند که در آن یک نکته ظریف سبک همان وزن یک آسیبپذیری SQL Injection را دارد.
دستور نمایش کد تصحیحشده (نه فقط توضیح رفع) مهمترین محدودیت است. بدون آن، بازبینهای هوش مصنوعی تمایل به اشاره به مشکل دارند — «مدیریت خطا در اینجا میتواند بهبود یابد» — بدون اینکه بگویند چه چیزی تایپ کنید. الزام کد تصحیحشده، خاصبودن را تحمیل میکند.
تطبیق برای زمینههای خاص
برای نتایج بهتر، زمینه را در بالای پرامپت اضافه کنید: زبان و فریمورک، محیط استقرار (Serverless، کانتینرها، Embedded)، محدودیتهای عملکرد یا قراردادهای تیم را مشخص کنید. برای کدهای حساس امنیتی، «به اعتبارسنجی ورودی، SQL Injection، XSS و موارد لبه احراز هویت توجه ویژه داشته باشید» را به بخش Critical Issues اضافه کنید. برای مسیرهای حیاتی عملکرد، «این تابع در تولید ۱۰٬۰۰۰ بار در ثانیه فراخوانی میشود» را اضافه کنید.
پرامپت در هر زبان برنامهنویسی کار میکند. روی Python، TypeScript، Go، Rust، Java و SQL با نتایج سازگار در هر سه مدل مرزی آزمایش شده است.