مهندسی پرامپت را بیشتر به‌عنوان «نوشتن دستور خوب» می‌شناسند، اما واقعیت سخت‌تر است: پرامپت یک موجود شکننده است. با هر آپدیت مدل، خروجی می‌تواند بدون هیچ تغییری در ورودی، ساختارش را از دست بدهد. الگوی Failure-Resistant Prompt (پرامپت مقاوم در برابر شکست) تنها راه عملی برای ساخت پرامپتی است که با تغییر مدل نمی‌میرد.

مهندسی پرامپت چیست و چرا پرامپت جادویی وجود ندارد#

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

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

در زنجیره‌ی ابزارهای هوش مصنوعی، مهندسی پرامپت اولین لایه است. قبل از Context Engineering (مهندسی زمینه) و Fine-tuning (تنظیم دقیق) قرار می‌گیرد. اگر با پرامپت‌نویسی به نتیجه نرسیدید، باید به لایه‌های بالاتر بروید، نه اینکه پرامپت را پیچیده‌تر کنید.

یک Anti-pattern رایج که در نتایج جستجو زیاد دیده می‌شود: ادعای «پرامپت جادویی» که هر مدلی را وادار به هر کاری می‌کند. این ادعا رد شده است. اگر مدل ذاتاً توانایی انجام وظیفه را ندارد، پرامپت بهتر هم کمکی نمی‌کند.

مستر پرامپت با System Prompt یکی نیست#

مستر پرامپت (Master Prompt) یک الگوی قابل‌بازاستفاده با متغیرهای جایگزین‌شدنی برای کاربر نهایی است، اما System Prompt لایه‌ی پنهان در API است که رفتار کلی مدل را ثابت می‌کند. این دو از نظر فنی، کاربردی و مخاطب کاملاً متفاوت‌اند و اشتباه گرفتنشان در پروژه‌های واقعی هزینه‌ساز است.

مستر پرامپت قالبی با متغیرهای جایگزین‌شدنی است. مثلاً یک مستر پرامپت برای تولید محتوای بلاگ، بخش‌هایی مثل «موضوع»، «مخاطب» و «لحن» دارد که کاربر مقدارشان را عوض می‌کند. System Prompt در مقابل، در سطح API تنظیم می‌شود و رفتار کلی مدل را برای تمام درخواست‌های یک کاربر یا یک اپلیکیشن ثابت می‌کند.

چرا اکثر مقالات فارسی این دو را یکی فرض می‌کنند؟ چون هر دو «دستور به مدل» هستند. اما خطای این اشتباه عملی است: کسی که فکر می‌کند System Prompt همان مستر پرامپت است، در پروژه‌های واقعی با مدل‌های مختلف، بدون مستندسازی و بدون متغیر، یک دستور ثابت را کپی‌پیست می‌کند و نتیجه‌ی نامنظم می‌گیرد.

نقش Metadata در مستر پرامپت اغلب نادیده گرفته می‌شود. بخش «محدودیت‌ها» و «معیارهای رد» مهم‌تر از بخش «چه بخواه» است. یعنی پرامپت باید صریحاً بگوید چه خروجی‌هایی نامعتبرند.

چرا پرامپتی که دیروز کار می‌کرد، امروز شکست می‌خورد؟#

پرامپتی که دیروز خروجی درست می‌داد، با آپدیت مدل ممکن است امروز ساختار را نادیده بگیرد یا لحن را عوض کند. این پدیده Prompt Drift (رانش پرامپت) نام دارد و راه‌حل عملی آن Pin کردن نسخه‌ی مدل و نگه‌داشتن Golden Test Set (مجموعه‌ی آزمون طلایی) است.

Prompt Drift یک مشکل فنی نیست؛ یک واقعیت عملی است. مدل‌ها با RLHF (یادگیری تقویتی از بازخورد انسانی) تنظیم می‌شوند و هر آپدیت، پارامترهای این تنظیم را عوض می‌کند. نتیجه: پرامپت ثابت، خروجی متغیر.

تفاوت رفتار پرامپت بین مدل‌های مختلف هم به همین ریشه بازمی‌گردد. Claude به تگ‌های XML حساسیت بیشتری دارد و Anthropic استفاده از آن‌ها را توصیه می‌کند. GPT-4 به ساختار Markdown و شماره‌گذاری پاسخ بهتری می‌دهد. Gemini روی دستورهای کوتاه و مستقیم بهتر عمل می‌کند. یک پرامپت بهینه‌شده برای یک مدل لزوماً روی مدل دیگر نتیجه‌ی مشابه نمی‌دهد.

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

ساختار مستر پرامپت شکست‌ناپذیر#

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

فریمورک CO-STAR#

فریمورک CO-STAR شش مؤلفه دارد که هر کدام یک بعد از وظیفه را پوشش می‌دهند:

  • C (Context): زمینه‌ی وظیفه؛ مدل باید بداند در چه بافتی کار می‌کند
  • O (Objective): هدف مشخص و قابل‌اندازه‌گیری
  • S (Style): سبک نگارش
  • T (Tone): لحن
  • A (Audience): مخاطب
  • R (Response): فرمت خروجی

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

فریمورک RTF (Role-Task-Format)#

RTF ساده‌تر است: Role (نقش مدل)، Task (وظیفه)، Format (فرمت خروجی). برای وظایف سریع و یک‌باره کفایت می‌کند.

هشدار عملی: نقش‌دهی بیش‌ازحد برای وظایف فنی دقیق، مدل را به پاسخ‌های نمایشی و کم‌عمق می‌برد. اگر از مدل می‌خواهید کد بنویسد، «تو یک برنامه‌نویس ارشد با ۲۰ سال تجربه هستی» ممکن است نتیجه‌ی بدتری بدهد تا دستور مستقیم و بدون نقش‌دهی.

الگوی Failure-Resistant: بخش fallback و معیارهای رد#

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

## Context
تو یک دستیار نگارش فارسی هستی که برای بلاگ‌نویسان حرفه‌ای محتوا تولید می‌کند.

## Objective
یک پاراگراف ۴۰ تا ۶۰ کلمه‌ای درباره‌ی «{topic}» بنویس که بدون خواندن بقیه‌ی متن کامل و قابل‌فهم باشد.

## Style
- فارسی روان با نیم‌فاصله‌ی درست
- حروف «ی» و «ک» فارسی (نه عربی)
- اعداد با رقم لاتین

## Tone
حرفه‌ای اما صمیمی، بدون کلیشه‌های متنی.

## Audience
خوانندگان عمومی با آشنایی اولیه از هوش مصنوعی.

## Response Format
فقط پاراگراف خروجی، بدون عنوان، بدون مقدمه، بدون توضیح اضافه.

## Constraints
- از عبارات ممنوعه استفاده نکن: «در دنیای امروز»، «شایان ذکر است»، «بدون شک»
- حداکثر ۶۰ کلمه

## Fallback
اگر موضوع «{topic}» برایت ناشناخته است، بنویس: «موضوع مشخص نیست. لطفاً توضیح بیشتری بدهید.» و پاراگراف تولید نکن.
اگر خروجی بیش از ۶۰ کلمه شد، خودت خلاصه‌اش کن و فقط نسخه‌ی نهایی را بده.

تکنیک‌های پیشرفته: Chain-of-Thought، Few-shot و ReAct در عمل#

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

Chain-of-Thought و Self-Consistency#

CoT با افزودن زنجیره‌ی استدلال به پرامپت، مدل را وادار می‌کند مرحله‌به‌مرحله فکر کند. این روش در مقاله‌ی Wei et al. (2022) معرفی شد. Self-Consistency (خودسازگاری) نسخه‌ی پیشرفته‌تر آن است: چند نمونه‌برداری انجام دهید و رأی اکثریت را بگیرید.

هشدار عملی: «think step by step» فقط روی مدل‌های بزرگ جواب می‌دهد. روی مدل‌های کوچکتر مضر است چون ظرفیت استدلالی کافی ندارند و دستور اضافه، attention (توجه) مدل را پخش می‌کند.

مسئله: {math_problem}

قدم به قدم فکر کن:
۱. صورت مسئله را بازنویسی کن و داده‌های کلیدی را استخراج کن.
۲. روش حل را انتخاب و دلیل انتخاب را بنویس.
۳. محاسبات را مرحله‌به‌مرحله انجام بده.
۴. جواب نهایی را چک کن (آیا منطقی است؟).

اگر در هر مرحله به بن‌بست خوردی، روش را عوض کن و دوباره از مرحله‌ی ۲ شروع کن.

جواب نهایی را در یک خط جدا بنویس: **جواب: ...**

Few-shot و Zero-shot#

Few-shot یعنی ارائه‌ی ۱ تا چند نمونه‌ی درون‌متنی در پرامپت. این تکنیک در مقاله‌ی Brown et al. (2020) درباره‌ی GPT-3 معرفی شد. Zero-shot (بدون‌نمونه) فقط دستور است بدون هیچ نمونه‌ای.

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

نظر را به یکی از سه برچسب «مثبت»، «منفی» یا «خنثی» تبدیل کن.

نمونه ۱:
ورودی: «کیفیت محصول عالی بود و بسته‌بندی تمیز رسید.»
خروجی: مثبت

نمونه ۲:
ورودی: «سه هفته طول کشید تا برسه و جعبه‌اش پاره بود.»
خروجی: منفی

نمونه ۳:
ورودی: «محصول رو تحویل گرفتم، فعلاً چیزی نمی‌تونم بگم.»
خروجی: خنثی

حالا این نظر را برچسب بزن:
ورودی: «{user_review}»
خروجی:

Tree of Thoughts و ReAct#

Tree of Thoughts (درخت تفکر) اکتشاف چند شاخه‌ی استدلالی است و در مقاله‌ی Yao et al. (2023) معرفی شد. ReAct ترکیب استدلال زبانی با فراخوانی ابزار است. Meta-Prompting (فراپرامپت‌نویسی) استفاده از مدل برای تولید و بهینه‌سازی پرامپت‌های دیگر است.

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

کِی پرامپت‌نویسی کافی نیست؟#

پرامپت‌نویسی برای وظایف یک‌باره و سبک جواب می‌دهد، اما وقتی وظیفه تکرارشونده است و حجم داده‌ی آموزش‌دهنده دارید، Fine-tuning مناسب‌تر است. وقتی دانش بیرونی لازم است، RAG (بازیابی‌محور تولید) را انتخاب کنید. مرز این سه روش، پیچیدگی وظیفه و تکرارشوندگی آن است.

Context Engineering چیست و چرا مرز آن با مهندسی پرامپت محو شده؟ Context Engineering مدیریت کل ورودی مدل است: System Prompt، تاریخچه‌ی گفتگو، اسناد بازیابی‌شده، ابزارهای در دسترس. مهندسی پرامپت فقط یک جزء از آن است. در ۲۰۲۴-۲۰۲۵ این دو چنان در هم تنیده شده‌اند که عنوان شغلی مستقل Prompt Engineer رو به کاهش است و بیشتر در نقش‌های Context Engineer یا AI Product Engineer ادغام می‌شود.

معیار مهندسی پرامپت Context Engineering Fine-tuning
هزینه‌ی اولیه کم (فقط زمان) متوسط (ساخت پایپ‌لاین) بالا (داده + GPU)
سرعت استقرار دقیقه‌ها چند روز چند هفته
تغییر رفتار ذاتی مدل نه نه بله
مقاومت در برابر Prompt Drift کم متوسط بالا
مناسب برای وظایف یک‌باره و سبک وظایف دانش‌محور الگوهای خروجی ثابت و تکرارشونده
نیاز به داده ندارد داده‌ی مرجع چند صد تا چند هزار نمونه

چک‌لیست تصمیم‌گیری: اگر وظیفه یک‌باره است و خروجی ساختاریافته‌ی ثابت لازم ندارید، پرامپت‌نویسی کافی است. اگر دانش به‌روز یا حجم زیاد لازم است، RAG را انتخاب کنید. اگر الگوی خروجی ثابت و تکرارشونده دارید و می‌خواهید رفتار ذاتی مدل عوض شود، Fine-tuning منطقی است.

دیباگ پرامپت: از کجا بفهمم مشکل کجاست؟#

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

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

مراحل دیباگ ساختارمند:

  1. پرامپت را به بخش‌های مجزا تقسیم کنید (نقش، زمینه، وظیفه، فرمت، محدودیت)
  2. هر بخش را یکی‌یکی حذف کنید و خروجی را مقایسه کنید
  3. Temperature و Token Limit را بررسی کنید؛ مشکل ممکن است از تنظیمات باشد نه از ساختار پرامپت
  4. تعارض بین بخش‌ها را پیدا کنید؛ مثلاً «مختصر بنویس» و «هر جزئیات را بیاور» با هم نمی‌سازند
  5. فرمت خروجی را صریح‌تر کنید؛ ابهام در «خروجی چطور باشد» رایج‌ترین علت شکست است

مدیریت نسخه‌ی پرامپت بدون ابزار گران‌قیمت هم ممکن است. یک فایل Git با Golden Test Set برای پروژه‌های کوچک کفایت می‌کند. PromptLayer و Weights & Biases ابزارهایی برای ردیابی تغییرات و مقایسه‌ی خروجی‌ها در پروژه‌های بزرگ‌تر هستند.

تعداد اصلاح‌های لازم: تجربه‌ی میدانی نشان می‌دهد معمولاً ۳ تا ۵ تکرار اصلاح برای رسیدن به پرامپت پایدار کافی است. اگر بعد از ۵ تکرار هنوز نتیجه مطلوب نیست، احتمالاً مشکل از پرامپت نیست و باید مدل، Temperature یا رویکرد را تغییر دهید.

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