پرامپت برنامه‌نویسی؛ ۱۰ نمونه برای دیباگ، تست، بازبینی کد و SQL

پرامپت برنامه‌نویسی خوب سه چیز را به هوش مصنوعی می‌دهد: زمینهٔ فنی دقیق (زبان، نسخه، فریم‌ورک)، فقط همان بخشی از کد که به مسئله مربوط است، و تعریف روشن کار؛ مثلاً «رفتار را تغییر نده» یا «اول علت را بگو، بعد اصلاح را». در این راهنما می‌بینید یک پرامپت کدنویسی چه اطلاعاتی لازم دارد، چه چیزهایی را هرگز نباید در آن بگذارید و ۱۰ پرامپت قابل‌کپی برای کارهای رایج برنامه‌نویسی با ChatGPT، Claude یا Gemini.

خروجی مدل را همیشه کد پیشنهادی بدانید، نه کد تأییدشده. هر تغییر را بخوانید، تست‌ها را اجرا کنید و تنها بعد از آن ادغام کنید.

یک پرامپت برنامه‌نویسی چه اطلاعاتی لازم دارد؟

مدل زبانی پروژهٔ شما را نمی‌بیند. هر چیزی که برای فهم مسئله لازم است باید در خود پرامپت باشد، و هر چیزی که لازم نیست فقط حواس مدل را پرت می‌کند. این شش مورد را پیش از ارسال بررسی کنید:

1. زبان و نسخه: «PHP 8.3» با «PHP 7.4» تفاوت جدی دارد. نسخهٔ زبان و کتابخانه‌های اصلی را بنویسید.
2. فریم‌ورک و قراردادهای پروژه: مثلاً Laravel، Django یا React، و اینکه پروژه از چه سبکی پیروی می‌کند.
3. فقط کد مرتبط: تابع یا کلاس درگیر و تعریف چیزهایی که صدا می‌زند. فرستادن کل پروژه معمولاً پاسخ را کلی‌تر می‌کند.
4. متن کامل خطا: پیام خطا و stack trace را کامل کپی کنید، نه خلاصهٔ آن را.
5. رفتار مورد انتظار و رفتار فعلی: «باید فهرست مرتب‌شده برگرداند، اما ترتیب ورودی را برمی‌گرداند» از «کار نمی‌کند» بسیار مفیدتر است.
6. محدودیت‌ها: کتابخانهٔ جدید اضافه نشود، امضای تابع عوض نشود، سازگاری با نسخهٔ فعلی حفظ شود.

امنیت: چه چیزی را هرگز در پرامپت نگذاریم؟

هر متنی که در ابزار هوش مصنوعی می‌گذارید از سیستم شما خارج می‌شود. پیش از ارسال، این موارد را حذف یا جایگزین کنید:

• کلید API، توکن، رمز عبور و رشتهٔ اتصال دیتابیس؛
• فایل‌های .env و پیکربندی‌هایی که اطلاعات محرمانه دارند؛
• داده‌های واقعی مشتری مثل نام، شماره موبایل، ایمیل و سفارش؛
• آدرس سرورها و مسیرهای داخلی که لازم نیستند.

به‌جای مقدار واقعی، جانشین معنادار بگذارید تا مدل ساختار را بفهمد:

DB_PASSWORD=<REDACTED>
API_KEY=<API_KEY>
customer_email = "user@example.com"

اگر کلیدی را اشتباهی فرستادید، آن را باطل کنید و کلید تازه بسازید؛ حذف پیام از گفت‌وگو کافی نیست.

خروجی را چطور بررسی کنیم؟

مدل ممکن است تابعی را صدا بزند که در نسخهٔ شما وجود ندارد، یا حالتی مرزی را جا بیندازد. پیش از پذیرفتن هر پیشنهاد:

• تغییرها را خط‌به‌خط در diff بخوانید و مطمئن شوید چیزی خارج از درخواست عوض نشده است.
• تست‌های موجود را اجرا کنید. اگر تستی برای آن بخش ندارید، اول تست بنویسید.
• نام توابع و کتابخانه‌ها را در مستندات رسمی همان نسخه بررسی کنید.
• برای کد امنیتی، مثل احراز هویت یا پرداخت، بازبینی انسانی را حذف نکنید.

۱۰ پرامپت برنامه‌نویسی قابل‌کپی

بخش‌های داخل کروشه را با اطلاعات پروژهٔ خود جایگزین کنید. این پرامپت‌ها برای ChatGPT، Claude و Gemini نوشته شده‌اند و به ابزار خاصی وابسته نیستند.

۱. توضیح کد ناآشنا

این کد [زبان و نسخه، فریم‌ورک] را توضیح بده.
اول در دو جمله بگو چه کاری انجام می‌دهد. بعد ورودی‌ها، خروجی، اثرهای جانبی (نوشتن در دیتابیس، فراخوانی شبکه) و وابستگی‌ها را بخش‌به‌بخش توضیح بده.
اگر بخشی به کدی بیرون از این قطعه بستگی دارد، صریح بگو و حدس نزن.
کد:
[کد]

۲. پیدا کردن علت خطا

هنگام [کاری که انجام می‌دادم] این خطا را می‌گیرم:
[متن کامل خطا و stack trace]
کد مرتبط: [کد]
محیط: [زبان و نسخه، فریم‌ورک، سیستم‌عامل]
رفتار مورد انتظار: [شرح] — رفتار فعلی: [شرح]
پیش از نوشتن کد، محتمل‌ترین علت‌ها را به ترتیب احتمال بگو و برای هر کدام یک راه بررسی پیشنهاد بده. اگر اطلاعاتی کم است، بپرس.

۳. بازنویسی بدون تغییر رفتار

این تابع را برای خوانایی بازنویسی کن. رفتار بیرونی، امضای تابع و خروجی برای همهٔ ورودی‌ها باید دقیقاً مثل قبل بماند.
کتابخانهٔ جدید اضافه نکن. اگر جایی رفتار فعلی به نظرت باگ است، اصلاحش نکن؛ جداگانه گزارش بده.
در پایان، تغییرها را فهرست کن و بگو کدام تست‌ها برای اطمینان از حفظ رفتار لازم است.
کد: [کد]

۴. نوشتن تست واحد

برای این تابع با [فریم‌ورک تست، مثلاً PHPUnit یا pytest] تست واحد بنویس.
حالت عادی، ورودی خالی، مقادیر مرزی، ورودی نامعتبر و خطاهای قابل انتظار را پوشش بده. نام هر تست باید بگوید چه رفتاری را بررسی می‌کند.
وابستگی‌های بیرونی (دیتابیس، شبکه) را mock کن و توضیح بده چرا.
تابع: [کد]

برای تولید منظم تست‌ها در پروژه‌های بزرگ‌تر، پرامپت تولید تست واحد با پوشش حالت‌های مرزی ساختار کامل‌تری دارد.

۵. بازبینی کد با چک‌لیست

این تغییر را مثل یک بازبین ارشد بررسی کن. زمینه: [هدف تغییر].
به ترتیب اولویت بررسی کن: ۱) امنیت (ورودی کاربر، تزریق SQL، دسترسی‌ها)، ۲) درستی و حالت‌های مرزی، ۳) خطاهای مدیریت‌نشده، ۴) کارایی، ۵) نام‌گذاری و خوانایی.
برای هر مورد: شمارهٔ خط، شدت (بحرانی/مهم/جزئی)، توضیح مشکل و پیشنهاد اصلاح.
اگر موردی پیدا نکردی، بنویس «موردی یافت نشد» و چیزی نساز.
diff یا کد: [کد]

نسخهٔ کامل این روش با اولویت‌بندی یافته‌ها در پرامپت بازبینی کد در سطح سنیور آمده است. محصولات بیشتر در دستهٔ بازبینی کد هستند.

۶. بهینه‌سازی کوئری کند SQL

این کوئری [MySQL 8 / PostgreSQL 16] کند است.
کوئری: [کوئری]
ساختار جدول‌ها و ایندکس‌های فعلی: [CREATE TABLE ...]
خروجی EXPLAIN: [خروجی]
تعداد تقریبی ردیف‌ها: [عدد]
بر اساس همین خروجی EXPLAIN بگو گلوگاه کجاست. پیشنهادها را با دلیل بده: ایندکس جدید، بازنویسی کوئری یا تغییر ساختار. برای هر ایندکس هزینهٔ نوشتن را هم بگو. نتیجهٔ کوئری نباید تغییر کند.

اگر کار با دیتابیس بخش ثابت کار شماست، پرامپت تحلیل و بهینه‌سازی کوئری SQL و دستهٔ دیتابیس و کوئری را ببینید.

۷. ساخت Regex همراه تست

یک عبارت منظم برای [زبان یا موتور regex] بنویس که [شرح الگو] را پیدا کند.
باید این‌ها را بپذیرد: [نمونه‌های درست]
نباید این‌ها را بپذیرد: [نمونه‌های نادرست]
هر بخش regex را توضیح بده و یک جدول از نمونه‌های بالا با نتیجهٔ مورد انتظار بساز. اگر الگو با یک regex قابل‌اعتماد نیست، بگو.

۸. مستندسازی API از روی کد

از روی این کد کنترلر و مدل، مستندات endpointها را بنویس.
برای هر endpoint: متد و مسیر، پارامترها با نوع و الزامی‌بودن، نمونهٔ درخواست، نمونهٔ پاسخ موفق، کدهای خطا و شرط دسترسی.
فقط از رفتاری که در کد دیده می‌شود استفاده کن. هر جا رفتار از کد معلوم نیست، با «نیاز به تأیید» علامت بزن.
کد: [کد]

برای مستندسازی کامل‌تر و یکدست، پرامپت تولید مستندات API از روی کد قالب آماده‌ای دارد.

۹. طراحی یک endpoint جدید

می‌خواهم endpointی برای [کار] در [فریم‌ورک] طراحی کنم.
قراردادهای فعلی API ما: [نمونهٔ یک endpoint موجود]
پیش از کد، این‌ها را پیشنهاد بده: مسیر و متد، ساختار درخواست و پاسخ، اعتبارسنجی ورودی، کدهای خطا، دسترسی‌ها و حالت‌های مرزی (تکرار درخواست، داده ناموجود).
سازگار با قراردادهای فعلی بمان و اگر تصمیمی به اطلاعات بیشتر نیاز دارد، بپرس.

۱۰. نوشتن پیام commit از روی diff

از روی این diff یک پیام commit بنویس.
خط اول: خلاصهٔ کمتر از ۷۲ کاراکتر به زبان [انگلیسی/فارسی] که بگوید چه چیزی تغییر کرد.
بدنه: چرا این تغییر لازم بود و چه اثری دارد، نه فهرست فایل‌ها.
چیزی که در diff نیست اضافه نکن.
diff: [diff]

نسخه‌های پرامپت برای موقعیت‌های مختلف

یک مسئله در موقعیت‌های مختلف اطلاعات متفاوتی لازم دارد. سه پرامپت پرکاربرد بالا را می‌توانید این‌طور با موقعیت خود تطبیق دهید.

دیباگ: خطایی که گاهی رخ می‌دهد

وقتی خطا فقط گاهی دیده می‌شود، متن یک خطا کافی نیست؛ مدل باید الگوی رخ دادن را بداند.

این خطا فقط گاهی رخ می‌دهد: [متن خطا]
دفعات مشاهده: [مثلاً دو بار در روز، بیشتر در ساعت‌های شلوغ]
چه چیزی در زمان خطا مشترک است: [نوع کاربر، حجم درخواست، کار زمان‌بندی‌شده]
کد مرتبط: [کد]
فرضیه‌هایی را که با این الگو سازگارند فهرست کن؛ مثل شرایط رقابتی، timeout یا داده‌ای خاص. برای هر فرضیه بگو چه لاگی اضافه کنم تا درست یا نادرست بودنش معلوم شود. هنوز اصلاح پیشنهاد نکن.

دیباگ: فقط لاگ production در دست است

این بخش از لاگ production است (اطلاعات کاربران حذف شده): [لاگ]
فقط بر اساس همین لاگ بگو ترتیب رویدادها چه بوده و خطا از کدام مرحله شروع شده است. هر جا لاگ کافی نیست، بنویس «از لاگ معلوم نیست» و بگو چه لاگی کمک می‌کند.

تست: کد قدیمی بدون هیچ تستی

در کد قدیمی، هدف اول تست ثبت رفتار فعلی است، حتی اگر رفتار فعلی ایراد داشته باشد. این‌طور هر بازنویسی بعدی قابل بررسی می‌شود.

این تابع قدیمی هیچ تستی ندارد و می‌خواهم بعداً بازنویسی‌اش کنم.
تست‌هایی بنویس که رفتار فعلی را دقیقاً ثبت کنند، حتی اگر به نظرت رفتار درستی نیست. هر جا رفتار مشکوک است، در توضیح تست بنویس «رفتار فعلی؛ نیاز به بررسی».
تابع: [کد]

بازبینی: فقط امنیت

این کد ورودی کاربر را دریافت و در دیتابیس ذخیره می‌کند. فقط از نظر امنیت بررسی کن: تزریق SQL، XSS، دسترسی بدون مجوز، افشای داده در پیام خطا و اعتبارسنجی ورودی.
برای هر یافته یک ورودی نمونه بده که مشکل را نشان دهد. سبک کد و کارایی را بررسی نکن.
کد: [کد]

نمونهٔ کامل: از پرامپت ضعیف تا خروجی قابل استفاده

این مثال آموزشی نشان می‌دهد تفاوت پرامپت در عمل کجا دیده می‌شود. خروجی‌ها خلاصه‌ای از نوع پاسخی است که معمولاً دریافت می‌شود، نه نتیجهٔ آزمایش ثبت‌شده روی مدلی مشخص.

موقعیت: یک تابع PHP مجموع سبد خرید را حساب می‌کند. وقتی کد تخفیف وارد می‌شود، گاهی مبلغ نهایی منفی می‌شود.

پرامپت ضعیف:

این کد درست کار نمی‌کند، درستش کن.
[کل فایل کنترلر سبد خرید]

نوع خروجی که معمولاً می‌گیرید: بازنویسی کل فایل با چند تغییر هم‌زمان (نام‌گذاری، ساختار، اعتبارسنجی) و احتمالاً اصلاح باگ در میان آن‌ها.

نقد این خروجی:

• معلوم نیست کدام تغییر باگ را رفع کرده است، پس نمی‌توانید آن را جدا بررسی کنید.
• رفتارهای دیگر فایل هم ممکن است بی‌صدا عوض شده باشند.
• مدل نمی‌دانسته باگ چیست، پس ممکن است مشکل دیگری را «رفع» کرده باشد.
• چون نسخهٔ PHP گفته نشده، ممکن است از قابلیتی استفاده شود که در سرور شما نیست.

پرامپت بهتر:

محیط: PHP 8.3، Laravel 11.
تابع calculateTotal در زیر مجموع سبد را حساب می‌کند. مشکل: با کد تخفیف ثابت ۵۰۰٬۰۰۰ ریالی روی سبد ۳۰۰٬۰۰۰ ریالی، خروجی ‎-200000 است. انتظار: مبلغ نهایی هرگز کمتر از صفر نشود.
اول علت را در یک جمله بگو. بعد کوچک‌ترین تغییری را بده که این مشکل را رفع کند، بدون تغییر بقیهٔ رفتار تابع. در پایان یک تست PHPUnit برای همین حالت بنویس.
تابع: [فقط تابع calculateTotal]

نوع خروجی مورد انتظار: یک جملهٔ علت (تخفیف ثابت بدون سقف از مجموع کم می‌شود)، یک تغییر چندخطی که مبلغ نهایی را حداقل صفر نگه می‌دارد، و یک تست برای همین حالت.

چرا بهتر است: مسئله با عدد مشخص بازتولید شده، معیار درستی روشن است، دامنهٔ تغییر محدود شده و تست، رفع باگ را قابل بررسی می‌کند. اگر بعداً بخواهید رفتار را تغییر دهید، مثلاً سقف تخفیف را درصدی کنید، آن را در پیام جدا بخواهید.

برای تغییرهای بزرگ، اول برنامه بخواهید

وقتی تغییر چند فایل را درگیر می‌کند، مثل اضافه کردن یک قابلیت یا مهاجرت به نسخهٔ جدید فریم‌ورک، درخواست مستقیم کد معمولاً به پاسخ طولانی و ناقص می‌رسد. اول برنامه بخواهید:

هنوز کد ننویس. برای [هدف] یک برنامهٔ مرحله‌به‌مرحله بده: فایل‌هایی که تغییر می‌کنند، ترتیب تغییرها، ریسک هر مرحله و تستی که بعد از هر مرحله باید اجرا شود. اگر برای تصمیم به اطلاعاتی نیاز داری، فهرست سؤال‌هایت را بده.

برنامه را بخوانید، اصلاح کنید و بعد هر مرحله را در یک پیام جدا بخواهید. هر مرحله را پیش از رفتن به مرحلهٔ بعد تست کنید.

اگر خروجی مشکل داشت، چه چیزی را تغییر دهیم؟

بیشتر خروجی‌های نامناسب به کمبود یا ابهام در پرامپت برمی‌گردند. پیش از شروع گفت‌وگوی تازه، این تغییرها را امتحان کنید:

• از تابع یا متدی استفاده کرده که وجود ندارد: نسخهٔ دقیق زبان و کتابخانه را بنویسید و بخواهید فقط از APIهای مستند همان نسخه استفاده کند. اگر باز هم تکرار شد، امضای تابع‌های موجود را در پرامپت بگذارید.
• کل فایل را بازنویسی کرده: بنویسید «فقط خطوط تغییرکرده را به شکل diff بده» یا «کوچک‌ترین تغییر ممکن».
• پاسخ کلی و آموزشی است، نه مخصوص کد شما: کد واقعی، متن خطا و رفتار مورد انتظار را اضافه کنید.
• کتابخانهٔ جدید پیشنهاد داده: محدودیت «بدون وابستگی جدید» را صریح بنویسید.
• اصلاح، باگ را جابه‌جا کرده: تست شکست‌خورده را همراه خروجی آن بفرستید و بخواهید اول علت شکست را توضیح دهد.
• پاسخ وسط کد قطع شده: کار را کوچک‌تر کنید؛ هر بار یک تابع یا یک فایل.
• با قراردادهای پروژه نمی‌خواند: یک نمونهٔ کوتاه از کد موجود پروژه بدهید و بخواهید از همان سبک پیروی کند.
• گفت‌وگو طولانی شده و مدل جزئیات قبلی را فراموش می‌کند: وضعیت فعلی کد و تصمیم‌های گرفته‌شده را خلاصه کنید و گفت‌وگوی تازه‌ای با همان خلاصه شروع کنید.

اشتباهات رایج در پرامپت برنامه‌نویسی

• «کار نمی‌کند» بدون متن خطا: مدل مجبور می‌شود حدس بزند و معمولاً رایج‌ترین علت را پیشنهاد می‌دهد، نه علت مسئلهٔ شما. پیام خطا، stack trace و ورودی‌ای که خطا را می‌سازد را بفرستید.
• فرستادن کل پروژه: بخش مهم در میان کد نامرتبط گم می‌شود. کد درگیر و تعریف توابعی را که صدا می‌زند بفرستید.
• نگفتن نسخه: پاسخ ممکن است برای نسخهٔ دیگری درست باشد و در پروژهٔ شما خطا بدهد.
• پذیرفتن کد بدون اجرا: کدی که درست به نظر می‌رسد ممکن است در حالت مرزی خطا بدهد. اول تست، بعد ادغام.
• چند کار در یک پیام: رفع باگ، بازنویسی و افزودن قابلیت را جدا بخواهید تا هر diff قابل بررسی بماند و اگر چیزی خراب شد، بدانید از کدام تغییر است.
• گذاشتن اطلاعات محرمانه: پیش از ارسال، کلیدها و داده‌های مشتری را جایگزین کنید.
• اعتماد به توضیح بدون شاهد: اگر مدل علتی را با اطمینان می‌گوید، بخواهید نشان دهد کدام خط کد یا کدام بخش لاگ آن را تأیید می‌کند.
• پذیرفتن ادعای کارایی بدون اندازه‌گیری: اگر گفته شد نسخهٔ جدید سریع‌تر است، قبل و بعد را خودتان اندازه بگیرید؛ مثلاً با EXPLAIN یا زمان اجرای تست.
• نگفتن معیار تمام شدن کار: بنویسید چه زمانی کار تمام است؛ مثلاً «همهٔ تست‌های موجود سبز بمانند و این حالت جدید هم پوشش داده شود».

پرسش‌های پرتکرار دربارهٔ پرامپت برنامه‌نویسی

پرامپت را فارسی بنویسم یا انگلیسی؟

توضیح کار را می‌توانید فارسی بنویسید؛ کد، متن خطا و نام توابع را همان‌طور که هست بگذارید. اگر خروجی‌ای مثل پیام commit یا کامنت کد باید انگلیسی باشد، زبان خروجی را صریح بگویید.

چقدر کد بفرستم؟

حداقل کدی که مسئله را بازتولید می‌کند: تابع درگیر، تعریف کلاس‌ها یا توابعی که صدا می‌زند و ساختار داده‌ای که با آن کار می‌کند. اگر مدل به بخش دیگری نیاز داشت، از او بخواهید بپرسد.

چه زمانی هوش مصنوعی کمک زیادی نمی‌کند؟

وقتی مشکل به وضعیت محیط بستگی دارد، مثل پیکربندی سرور، شبکه یا داده‌ای که نمی‌توانید نشان دهید، مدل فقط می‌تواند فرضیه بدهد. در این حالت از او بخواهید روش بررسی پیشنهاد دهد، نه پاسخ قطعی.

آیا یک پرامپت در همهٔ مدل‌ها نتیجهٔ یکسان می‌دهد؟

خیر. مدل‌ها در سبک پاسخ و طول خروجی تفاوت دارند. ساختار این پرامپت‌ها برای همه قابل استفاده است، اما ممکن است لازم باشد جزئیات را برای ابزار خود تنظیم کنید.

اگر تازه با پرامپت‌نویسی شروع کرده‌اید، آموزش پرامپت‌نویسی اصول کلی را توضیح می‌دهد. نمونه‌های کوتاه‌تر برای کارهای دیگر در ۱۵ پرامپت آماده رایگان هستند و همهٔ محصولات این حوزه در دستهٔ برنامه‌نویسی قرار دارند.