پرامپت‌های آمادهٔ کدنویسی؛ توضیح، دیباگ، ریفکتور و تست

کدنویسی، جایی است که پرامپت‌نویسی بیشترین بازده فوری را دارد: توضیح کد نامفهوم، شکار باگ، ریفکتور امن و تست‌نویسی. اما خروجی کد از مدل، فقط وقتی قابل استفاده است که پرامپت کدنویسی شما سه چیز را داشته باشد: قرارِ سبک، زمینهٔ کد، و تعریف دقیق «تمام‌شدن».

قانون اول: مدل را در تیم خودتان فرض کنید

برنامه‌نویس جدیدی که وسط پروژه می‌آید چه لازم دارد؟ سبک کدنویسی، قراردادهای پروژه و بافت کد. مدل هم همین. برای همین، پرامپت‌های خوب کدنویسی شامل یک بخش «قواعد» است: نام‌گذاری، مدیریت خطا، حداکثر طول تابع. برای اصول کلی پرامپت، فرمول پرامپت‌نویسی را مرور کنید.

قالب ۱ — دیباگ با بازسازی مشکل

وظیفه: باگ کد زیر را پیدا کن.
زمینه: [زبان] | [کتابخانه/فریم‌ورک] | [نسخه تقریبی]
انتظار من: [رفتار درست]
رفتار فعلی: [رفتار غلط] — خطا: [متن خطا]

قواعد:
۱) اول در یک خط بگو فرضیهٔ اصلی‌ات چیست
۲) بعد دقیقاً علت را نشان بده (شمارهٔ خط/بخش)
۳) دو راه‌حل بده: کم‌تغییر (فوری) و درست‌تر (نیازمند تغییر بیشتر)
۴) بگو چه چیزی را باید تست کنم تا مطمئن شوم درست شد

کد:
[کد شما]

قالب ۲ — ریفکتور بدون تغییر رفتار

وظیفه: بازنویسی کد زیر برای خوانایی و تست‌پذیری؛
رفتار بیرونی نباید عوض شود.

<قواعد_سبک>
- نام‌ها گویا و انگلیسی
- هر تابع زیر ۲۰ خط
- خطاها با پیام روشن برگردند
- کامنت فقط جایی که «چرا» غیربدیهی است
</قواعد_سبک>

خروجی: کد جدید + فهرست تغییرات + یک نمونهٔ تست ساده برای تابع اصلی.
کد فعلی: [کد شما]

قالب ۳ — تولید تست

وظیفه: برای تابع زیر، تست بنویس.
پوشش لازم: حالت عادی | حالت مرزی | ورودی خالی | ورودی غلط
برای هر تست، در یک خط بنویس «چه چیزی را قفل می‌کند».
اگر رفتاری از تابع برایت مبهم بود، اول بپرس — حدس نزن.

تابع: [کد]

جدول خطاهای رایج در پرامپت کد

ابزار و زنجیره

Cursor و ابزارهای داخل-ادیتور، برای تغییرات کوچک سریع‌اند؛ برای معماری و بازبینی، مدل‌های چت با زمینهٔ کامل بهترند. هر خروجی کد را قبل از پذیرش اجرا کنید — دربارهٔ خطاهای مدل، هذیان مدل را بخوانید. برای کارهای چندگامی (اول تست، بعد ریفکتور)، از زنجیرهٔ پرامپت استفاده کنید و برای ابزارهای تخصصی، Cursor چیست را ببینید.

جمع‌بندی

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

مثال عملی: یک باگ واقعی و خروجی قالب دیباگ

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

پرسش‌های پرتکرار

کد مدل را کورکورانه بپذیرم؟

نه؛ اجرا و تست، شرط پذیرش است — مدل گاهی API خیالی می‌سازد.

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

کیفیت پایین‌تر است؛ نمونهٔ کد کارکردی در پرامپت، خیلی کمک می‌کند.

کل پروژه را بدهم یا بخشی؟

بخش مرتبط + یک جملهٔ نقشهٔ کلی؛ کل پروژه معمولاً فقط توکن مصرف می‌کند.

خطا را کامل بفرستم یا خلاصه؟

متن کامل خطا (stack trace) و کدِ مرتبط را؛ نه اسکرین‌شات و نه بازگویی خودتان. بخشی از خطا که «غیرمرتبط» به‌نظر می‌رسد، گاهی همان سرنخ اصلی است و مدل از آن استفاده می‌کند.