آناتومی یک پرامپت کد خوب؛ زمینه، ورودی، خروجی، محدودیت

خیلی از کسانی که تازه سراغ وایب کدینگ می‌روند، فکر می‌کنند تفاوت یک پرامپت خوب با یک پرامپت بد فقط در ادب یا طول جمله است. اما در عمل، مدل‌های کد مثل یک همکار تازه‌کار رفتار می‌کنند که هیچ پیش‌زمینه‌ای از پروژهٔ شما ندارد؛ هر چیزی که نگویید، حدس می‌زند و حدس‌های او همیشه درست از آب در نمی‌آید. یک پرامپت کد خوب از چهار جزء ثابت تشکیل شده: زمینه (context)، ورودی (input)، خروجی مورد انتظار (output) و محدودیت‌ها (constraints). اگر این چهار جزء را بلد باشید، دیگر مجبور نیستید سه یا چهار بار پرامپت را اصلاح کنید تا مدل بفهمد چه می‌خواهید.

چهار جزء یک پرامپت خوب

۱. زمینه (Context)

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

بد: «یک فرم لاگین بساز.»

خوب: «در پروژهٔ Next.js با TypeScript و Tailwind، یک کامپوننت فرم لاگین بساز که از همان الگوی فرم‌های موجود در پوشهٔ components/forms پیروی کند.»

۲. ورودی (Input)

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

بد: «این تابع را بهینه کن.»

خوب: «این تابع calculateTotal را که آرایه‌ای از آیتم‌ها می‌گیرد و مجموع قیمت را برمی‌گرداند، بهینه کن؛ کد فعلی پایین آمده.»

۳. خروجی مورد انتظار (Output)

باید بگویید خروجی نهایی چه شکلی باید باشد: یک فایل کامل، یک تابع، یک دیف (diff)، یا فقط توضیح؟ بدون این جزء، مدل گاهی کل فایل را دوباره می‌نویسد وقتی شما فقط یک خط تغییر می‌خواستید.

بد: «کدش رو درست کن.»

خوب: «فقط خطوطی که باید تغییر کنند را به‌صورت دیف نشان بده؛ بقیهٔ فایل دست‌نخورده بماند.»

۴. محدودیت‌ها (Constraints)

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

بد: «این بخش را سریع‌تر کن.»

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

اشتباهات رایجی که این چهار جزء را خنثی می‌کنند

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

سه پرامپت آماده برای کپی

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

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

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

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

اگر می‌خواهید این چهار جزء را عمیق‌تر یاد بگیرید و روی مثال‌های واقعی‌تر تمرین کنید، نقشهٔ راه مهندسی پرامپت مسیر گام‌به‌گام آن را نشان می‌دهد. و اگر هنوز با کلیت وایب کدینگ آشنا نیستید، بهتر است اول راهنمای کامل وایب کدینگ را بخوانید.

جمع‌بندی

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