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

مهندسی پرامپت چیست و چه تفاوتی با کدنویسی دارد؟#

مهندسی پرامپت (Prompt Engineering) طراحی دستورالعمل‌های متنی برای مدل‌های زبانی بزرگ (LLM) است تا خروجی قابل‌اعتماد تولید کنند. برخلاف کدنویسی، خروجی قطعی نیست و مدل همان پرامپت را با پاسخ متفاوت اجرا می‌کند؛ بنابراین ارزیابی و تکرار بخشی جدایی‌ناپذیر از فرآیند است.

پرامپت ورودی متنی است که رفتار مدل را بدون تغییر وزن‌ها هدایت می‌کند. تفاوت بنیادی با کدنویسی این است که مدل زبانی تابع نیست؛ ورودی یکسان، خروجی یکسان تضمین نمی‌کند. تفاوت با تنظیمات مدل (Fine-tuning) هم روشن است: پرامپت‌نویسی بدون دسترسی به وزن‌های مدل انجام می‌شود.

مهندسی پرامپت بدون درک دامنه‌ی مسئله (Domain Knowledge) بی‌فایده است. پرامپت خوب ابزار انتقال دانش شماست، نه جایگزین آن. اگر خودتان نمی‌دانید خروجی مطلوب چه شکلی است، هیچ ساختار پرامپتی شما را نجات نمی‌دهد. این اشتباه در کلاس‌های مبتدیان بارها تکرار شده: تمرکز صرف روی قالب پرامپت بدون فهم عمیق مسئله.

مستر پرامپت: قالب پنج‌بخشی که بارها استفاده می‌کنید#

مستر پرامپت (Master Prompt) یک پرامپت ساختاریافته و قابل‌استفاده‌ی مجدد است با پنج بخش ثابت: نقش، زمینه، وظیفه، محدودیت‌ها و فرمت خروجی. این عناصر در مستندات رسمی Anthropic توصیه شده‌اند و برای وظایف تکرارشونده‌ی تیمی طراحی شده است.

هر بخش یک کار مشخص دارد:

  • نقش (Role): هویت و تخصص مورد انتظار از مدل را مشخص می‌کند.
  • زمینه (Context): اطلاعات پس‌زمینه‌ای که مدل برای تصمیم‌گیری نیاز دارد.
  • وظیفه (Task): عمل اصلی با فعل مشخص — «بنویس»، «تحلیل کن»، «مقایسه کن».
  • محدودیت‌ها (Constraints): مرزهای پاسخ و کارهایی که مدل نباید انجام دهد.
  • فرمت خروجی (Output Format): ساختار دقیق پاسخ — جدول، فهرست، JSON و...

قالب آماده‌ی مستر پرامپت#

این قالب را در فایل Markdown خود ذخیره کنید و هر بار بخش‌های متغیر را پر کنید:

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

چه تکنیک‌هایی واقعاً خروجی را بهتر می‌کنند؟#

تکنیک‌هایی مثل Few-shot Prompting، خروجی ساختاریافته (Structured Output) و پرامپت‌نویسی نقش‌محور برای همه‌ی مدل‌ها مؤثرند. اما زنجیره‌ی تفکر (Chain-of-Thought) صریح برای مدل‌های جدیدتر تأثیر چندانی ندارد و گاهی مضر است. پیچیدگی پرامپت باید متناسب با پیچیدگی وظیفه باشد.

مقایسه‌ی Zero-shot و Few-shot#

معیار Zero-shot Prompting Few-shot Prompting
کاربرد وظایف ساده، مدل‌های قدرتمند وظایف الگویی، خروجی‌های ساختاریافته
هزینه (توکن) کم بالا — هر نمونه توکن اضافه دارد
دقت متوسط بالا در وظایف الگویی
ریسک خروجی غیرقابل‌پیش‌بینی اگر نمونه‌ها ضعیف باشند، مدل همان ضعف را تکرار می‌کند

مقاله‌ی Wei et al. در NeurIPS 2022 نشان داد که Chain-of-Thought دقت مدل‌ها را در مسائل ریاضی افزایش می‌دهد. اما مدل‌های جدیدتر ذاتاً استدلال می‌کنند و اضافه‌کردن «step by step» به پرامپت آن‌ها گاهی خروجی را مختل می‌کند. دقیق‌تر بگویم: این تکنیک برای مدل‌هایی که reasoning ذاتی دارند (مثل o1 و o3) نه‌تنها بی‌فایده، بلکه با تداخل در زنجیره‌ی داخلی مدل، دقت را کاهش می‌دهد.

پرامپت معکوس (Reverse Prompting)#

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

بدهی پرامپت: چرا پرامپت‌ها با آپدیت مدل می‌شکنند#

بدهی پرامپت (Prompt Debt) انباشت پرامپت‌های پیچیده و مستندنشده‌ای است که با هر تغییر مدل یا به‌روزرسانی API بدون آزمون از کار می‌افتند. نگهداری‌شان سخت‌تر از کد است چون هیچ تست خودکار مشخصی ندارند.

برجی شفاف که با تغییر پایه‌اش ترک می‌خورد، تصویری از شکنندگی پرامپت‌ها در برابر آپدیت مدل‌های زبانی
هر چه پرامپت وابسته‌تر به رفتار لحظه‌ای مدل باشد، آسیب‌پذیرتر است

چرخه‌ی ساخت و ویرایش بی‌رحم است: هر مدل جدید، تکنیک‌های جبرانی مدل قبلی را بی‌اثر یا مضر می‌کند. مثال مشخص: دستور «think step by step» که برای GPT-3.5 مفید بود، روی مدل‌هایی مثل Claude 3.5 Sonnet که استدلال داخلی دارند، می‌تواند خروجی را مختل کند. پرامپت‌نویسی بین‌مدل (Cross-model Prompting) هم چالش دارد. یک پرامپت بهینه برای GPT-4 لزوماً برای Claude یا Gemini بهینه نیست. تفاوت‌ها در ترتیب‌دهی بخش‌ها، طول بهینه، و نوع دستورات است.

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

اشتباهاتی که پرامپت شما را بی‌اثر می‌کنند#

مهم‌ترین اشتباهات پرامپت‌نویسی: پرامپت‌های مبهم بدون فعل مشخص، دستورات متناقض، بیش‌بارگذاری زمینه (Context Overload)، و باور به اینکه پرامپت بلندتر همیشه بهتر است.

پرامپت مبهم مثل «درباره‌ی هوش مصنوعی بنویس» بدون مخاطب، طول، زاویه و فرمت، خروجی بی‌ارزش تولید می‌کند. دستورات متناقض — مثلاً «کوتاه بنویس» و هم‌زمان «هر جزئیاتی که می‌دانی اضافه کن» — مدل را در دور باطل می‌اندازند.

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

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

نسخه‌بندی و مدیریت کتابخانه‌ی پرامپت شخصی#

کتابخانه‌ی پرامپت باید مثل کد نسخه‌بندی شود: هر پرامپت یک شناسه، تاریخ آخرین آزمون، نسخه‌ی مدل سازگار، و وضعیت (فعال یا منسوخ) داشته باشد. بدون این ساختار، پرامپت‌های مرده روی پرامپت‌های فعال سوار می‌شوند.

ساختار پیشنهادی فایل:

  1. شناسه: نام کوتاه + تاریخ ساخت
  2. مدل سازگار: مثلاً Claude 3.5 Sonnet
  3. تاریخ آخرین آزمون: و نتیجه‌ی آن
  4. وضعیت: فعال / منسوخ / نیازمند بازنگری
  5. یادداشت تغییرات: چه چیزی عوض شد و چرا

برای شروع، یک فایل Markdown با همین ساختار کافی است. ابزارهای تخصصی مثل Prompt Library برای تیم‌های بزرگ‌تر مفیدند، اما برای شروع لازم نیست.

اولویت‌بندی: پرامپت‌های پرکاربرد را زودتر به‌روزرسانی کنید. حذف پرامپت‌های منسوخ هم مهم است — بدهی پرامپت از انباشت پرامپت‌های مرده می‌آید. نگه‌داشتن پرامپت‌های منسوخ به‌عنوان «شاید بعداً به‌درد بخورد» دقیقاً همان کاری است که در codebase با کد commented-out انجام می‌دهید و همه می‌دانید مشکل‌ساز است.

پرامپت‌نویسی فارسی: چه چیزی متفاوت است؟#

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

برای مدل‌های انگلیسی‌محور مثل GPT-4 و Claude: پرامپت انگلیسی + خروجی فارسی معمولاً بهتر کار می‌کند. مدل در زبان خودش بهتر دستور را درک می‌کند.

برای مدل‌های بومی فارسی: پرامپت فارسی بنویسید. ترجمه‌ی پرامپت به انگلیسی خروجی را بی‌کیفیت می‌کند چون این مدل‌ها روی داده‌ی فارسی آموزش دیده‌اند.

چالش‌های ساختاری فارسی هم جدی‌اند: نیم‌فاصله، حروف فارسی «ی» و «ک»، و ترتیب اجزای جمله. در فرمت خروجی صراحتاً بنویسید «فارسی معیار با نیم‌فاصله‌ی درست». بدون این دستور، مدل‌های انگلیسی‌محور حروف عربی «ي» و «ك» را جایگزین می‌کنند و نیم‌فاصله را حذف می‌کنند.

پرامپت تولید تصویر چه فرقی با مدل زبانی دارد؟#

پرامپت‌نویسی برای مدل‌های مولد تصویر مثل Midjourney و DALL-E کاملاً متفاوت است. این مدل‌ها به توصیف بصری، سبک و پارامترهای فنی نیاز دارند — نه ساختار پنج‌بخشی مستر پرامپت. نسبت ابعاد، وزن کلمات، و سبک بصری جایگزین «نقش» و «وظیفه» می‌شوند.

تکنیک‌های مؤثر برای پرامپت تولید تصویر:

  • توصیف صحنه از کل به جزء (سبک ← سوژه ← جزئیات ← نور)
  • استفاده از پارامترهای فنی مثل --ar و --s در Midjourney
  • مشخص کردن سبک مرجع (مثلاً «به سبک Studio Ghibli»)
  • حذف عناصر نامطلوب با --no یا Negative Prompt

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

ارزیابی خروجی: چطور بفهمیم پرامپت کار می‌کند؟#

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

معیارهای ارزیابی: صحت، کامل بودن، رعایت فرمت، لحن، و تکرارپذیری. حداقل چند ورودی متفاوت از سناریوی واقعی تست کنید. مقایسه‌ی A/B دو نسخه‌ی پرامپت روی همان ورودی، تفاوت‌های ظریف را آشکار می‌کند.

مدیریت پنجره‌ی زمینه (Context Window) هم بخشی از ارزیابی است: اولویت‌بندی اطلاعات مهم — مهم‌ترین دستورالعمل‌ها را ابتدا و انتها بگذارید، نه وسط. مدل‌ها اطلاعات میانی را کمتر به یاد می‌آورند.

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

جمع‌بندی عملی#

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

اگر می‌خواهید این ساختار را در پروژه‌های واقعی پیاده کنید — نه فقط روی کاغذ — دوره‌ی آموزش جامع Claude و ابزارهای مشابه در کامیونیتی اسکول دقیقاً همین مسیر را طی می‌کند: از پرامپت‌نویسی تا ساخت ایجنت هوش مصنوعی (AI Agent) و اتوماسیون، بدون کدنویسی.