تفاوت بین یک خروجی کد قابل استفاده و یک خروجی که باید از صفر بازنویسی شود، اغلب نه در قدرت مدل، بلکه در ساختار پرامپتی است که برایش نوشتهاید. این درس کامل، چهار پرامپت آمادهٔ کپی برای نوشتن کد، نوشتن تست و رفع باگ در اختیارتان میگذارد، همراه با توضیح اینکه چرا هر بخش از آنها لازم است.
لیست مطالب
چرا ساختار پرامپت مهمتر از طول آن است
یک پرامپت طولانی که فقط توضیح میدهد «چه میخواهید» معمولاً نتیجهٔ ضعیفتری از یک پرامپت کوتاهتر اما ساختاریافته میدهد. مدلهای کدنویسی وقتی بهترین کار را انجام میدهند که علاوه بر هدف، محدودیتها، فرمت خروجی و معیار موفقیت هم مشخص باشد. نبود این عناصر باعث میشود مدل مجبور شود حدس بزند، و حدسهای آن همیشه با انتظار شما یکی نیست.

عناصر یک پرامپت خوب برای کد
| بخش | چرا لازم است |
|---|---|
| زمینه (Context) | مدل بدون دیدن زبان، فریمورک و ساختار فعلی پروژه، فرضیات اشتباه میسازد |
| هدف دقیق | «یک تابع بنویس» مبهم است؛ «تابعی که ورودی X میگیرد و خروجی Y میدهد» دقیق است |
| محدودیتها | کتابخانههای مجاز، سبک کدنویسی، و چیزهایی که نباید تغییر کنند را مشخص میکند |
| فرمت خروجی | مشخص میکند فقط کد بخواهید یا همراه با توضیح، تست یا مراحل اجرا |
| معیار موفقیت | به مدل و به خودتان کمک میکند بفهمید کی نتیجه واقعاً درست است |
پرامپت آماده برای نوشتن کد
از این قالب برای درخواست پیادهسازی یک قابلیت یا تابع مشخص استفاده کنید. جای پرانتزها را با جزئیات پروژهٔ خودتان پر کنید.
زبان و فریمورک پروژه: (مثلاً TypeScript با Node.js). هدف: تابعی بنویس با نام (نام تابع) که ورودی (توضیح ورودی) میگیرد و خروجی (توضیح خروجی) برمیگرداند. محدودیتها: فقط از کتابخانههای موجود در پروژه استفاده کن، کد را بدون وابستگی جدید بنویس، و سبک نامگذاری فعلی پروژه را رعایت کن. حالتهای خطا: برای ورودی نامعتبر (توضیح رفتار مورد انتظار) را برگردان. خروجی مورد انتظار: فقط کد تابع بههمراه یک توضیح کوتاه دربارهٔ منطق آن، بدون تغییر در فایلهای دیگر.
پرامپت آماده برای نوشتن تست
این قالب برای وقتی است که کد آماده دارید و میخواهید پوشش تست مناسبی برایش بنویسید.
این تابع یا ماژول را برایم تست بنویس: (کد یا مسیر فایل). فریمورک تست پروژه: (مثلاً Jest یا PyTest). حالتهایی که باید پوشش داده شوند: مسیر موفق با ورودی معتبر، حداقل دو حالت مرزی (ورودی خالی، مقدار خارج از محدوده)، و یک حالت خطا که باید استثنا یا خروجی مشخص تولید کند. هر تست باید یک سناریوی مشخص را بررسی کند و نام تست باید همان سناریو را توضیح دهد. کد تست را طوری بنویس که بدون تغییر در کد اصلی قابل اجرا باشد.
پرامپت آماده برای رفع باگ
برای رفع باگ، مهمترین چیزی که معمولاً فراموش میشود، دادن پیام خطای دقیق و مراحل بازتولید مشکل است.
این کد با این پیام خطا مواجه میشود: (متن دقیق خطا یا رفتار غیرمنتظره). کد مربوطه: (کد یا مسیر فایل). مراحل بازتولید مشکل: (چه ورودی یا عملی باعث بروز خطا میشود). رفتار مورد انتظار: (توضیح اینکه نتیجهٔ درست باید چه باشد). قبل از اصلاح، علت احتمالی خطا را در یک یا دو خط توضیح بده، سپس فقط تغییرات لازم را اعمال کن و کدی که به مشکل ربطی ندارد را دستنخورده نگه دار.
پرامپت آماده برای ریویو و رفکتور
وقتی کد کار میکند اما میخواهید کیفیت آن را قبل از ادغام نهایی بررسی کنید، این قالب مناسب است.
این کد را از نظر خوانایی، عملکرد و رعایت اصول (زبان یا فریمورک) بررسی کن: (کد یا مسیر فایل). فقط مشکلات واقعی را فهرست کن، نه سلیقههای شخصی بیاهمیت. برای هر مشکل، شدت آن را مشخص کن (بحرانی، متوسط، جزئی) و یک راهحل مشخص پیشنهاد بده. رفتار بیرونی کد نباید تغییر کند؛ فقط ساختار داخلی آن قابل بهبود است.
یک نمونهٔ کوچک از تفاوت خروجی
برای اینکه تفاوت یک پرامپت دقیق را ببینید، به این دو مثال نگاه کنید. درخواست مبهم «یک تابع جمع بنویس» میتواند به امضاهای متفاوتی برسد، اما وقتی نوع ورودی و خروجی را دقیق مشخص کنید، مدل امضای پیشبینیپذیری تولید میکند:
// درخواست دقیق: تابعی که آرایهای از اعداد میگیرد
// و مجموع آنها را بهصورت عدد برمیگرداند
function sumItems(values: Array<number>): number {
return values.reduce((total, current) => total + current, 0);
}
در این مثال، مشخص کردن نوع ورودی بهصورت Array<number> و نوع خروجی بهصورت number، احتمال دریافت امضای نادرست یا رفتار غیرمنتظره در حالتهای مرزی را بهشدت کاهش میدهد.
یک اشتباه رایج در استفاده از این پرامپتها
خیلیها این قالبها را عیناً کپی میکنند اما جای پرانتزها را با جزئیات مبهم پر میکنند؛ مثلاً بهجای نوشتن نوع دقیق ورودی، فقط مینویسند «یک عدد» بدون گفتن اینکه منفی مجاز است یا نه، یا اعشاری هست یا نه. نتیجه این میشود که همان مشکل ابهام، از یک لایه عقبتر، دوباره سر بر میآورد. قاعدهٔ ساده این است: هر جای خالی در این قالبها را طوری پر کنید که انگار دارید به یک همکار تازهکار که هیچ زمینهای از پروژه ندارد توضیح میدهید؛ اگر آن توضیح برای یک انسان کافی و بدون ابهام است، برای مدل هم همینطور خواهد بود.
چند نکتهٔ تکمیلی برای استفادهٔ روزمره
این چهار پرامپت را میتوانید مستقیم کپی و برای پروژهٔ خودتان تنظیم کنید، اما بهترین نتیجه وقتی به دست میآید که آنها را با زمینهٔ واقعی کدبیستان ترکیب کنید؛ یعنی فایل یا بخش مرتبط را واقعاً به مدل نشان دهید، نه فقط توضیح کلامی آن را. برای یادگیری عمیقتر دربارهٔ نحوهٔ کار با ابزارهای کدنویسی هوش مصنوعی در پروژههای واقعیتر، نقشهٔ راه کدنویسی با هوش مصنوعی در roadmap-ai-coding و راهنمای عملی vibe-coding-guide مکمل خوبی برای همین پرامپتها هستند.
جمعبندی
- یک پرامپت خوب برای کد، شامل زمینه، هدف دقیق، محدودیتها، فرمت خروجی و معیار موفقیت است.
- برای نوشتن تست، همیشه مسیر موفق، حالتهای مرزی و حالت خطا را جداگانه درخواست کنید.
- در رفع باگ، پیام خطای دقیق و مراحل بازتولید مشکل را بدهید تا مدل حدس نزند.
- در ریویو و رفکتور، تفکیک شدت مشکلات و ثابت ماندن رفتار بیرونی کد را صریح بخواهید.
- هرچه زمینهٔ واقعی کدبیس را بیشتر به مدل نشان دهید، خروجی قابلاستفادهتر خواهد بود.
