بیشتر تیم‌هایی که تازه با مدل زبان بزرگ (LLM) کار می‌کنند، پرامپت را مثل کد می‌نویسند: یک بار می‌نویسند، تست می‌کنند و تمام. نتیجه در production فاجعه‌بار است — خروجی‌های غیرقابل‌پیش‌بینی، هزینه‌های توکنی سرسام‌آور و باگ‌هایی که هیچ‌کس نمی‌داند از کجا آمده‌اند. مهندسی پرامپت پاسخ این آشفتگی است: تبدیل «نویسیدن» به «مهندسی کردن».

مهندسی پرامپت چیست و چرا توصیف آن به‌عنوان «دستور دادن» گمراه‌کننده است#

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

وقتی کسی می‌گوید «به مدل دستور بده»، ذهن را به سمت کدنویسی می‌برد. اما پرامپت کد نیست. مدل وزن‌دهی می‌کند، تفسیر می‌کند و گاهی همان ورودی را دفعه‌ی بعدی متفاوت پردازش می‌کند. این تفاوت ظریف نیست — اگر آن را نادیده بگیرید، پرامپت شما در اولین برخورد با داده‌ی واقعی شکست می‌خورد.

الگوی قرارداد رفتاری چهار جزء دارد:

  • ورودی (Input): چه داده‌ای به مدل می‌رسد و در چه قالبی.
  • خروجی (Output): مدل باید چه چیزی تولید کند و در چه فرمتی.
  • حالت‌های خطا (Error States): اگر ورودی ناقص بود، اگر task قابل‌اجرا نبود، اگر خروجی در بازه‌ی مجاز نبود — مدل چه کند.
  • محدودیت‌ها (Constraints): چه کارهایی ممنوع است، چه لحنی لازم است، چه طولی مجاز است.

پرامپت سیستمی (System Prompt) ستون فقرات این قرارداد است. هویت، مرزها و قوانین کلی مدل را تعریف می‌کند و معمولاً در تمام callها ثابت می‌ماند. پرامپت کاربر (User Prompt) درخواست خاص و داده‌ی ورودی را مشخص می‌کند. اگر این دو را در هم بریزید، کنترل رفتار مدل را از دست می‌دهید. در پروژه‌های اعضای کامیونیتی، بارها دیده شده که تیم‌ها پرامپت سیستمی و کاربر را در یک بلوک متنی می‌نویسند و بعد تعجب می‌کنند چرا مدل در call دوم هویتش را فراموش می‌کند.

چرا پرامپت‌نویسی کافی نیست و مهندسی لازم است#

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

مستر پرامپت چیست و اجزای ساختاری آن کدام‌اند؟#

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

پنج ستون ساختاری مستر پرامپت:

  1. نقش (Role): مدل کیست؟ متخصص چیست؟
  2. زمینه (Context): چه اطلاعاتی از محیط و داده‌ها لازم است؟
  3. دستور (Instruction): دقیقاً چه کاری باید انجام دهد؟
  4. فرمت خروجی (Output Format): خروجی در چه ساختاری باشد؟
  5. محدودیت‌ها (Constraints): چه چیزهایی مجاز نیست؟

قانون ساده برای تفکیک پرامپت سیستمی و کاربر: هر چیزی که ثابت است و هویت مدل را تعریف می‌کند، پرامپت سیستمی است. هر چیزی که برای هر call خاص تغییر می‌کند، پرامپت کاربر است. اشتباه در این تفکیک، پرهزینه‌تر از آن است که به‌نظر می‌رسد — چون مدل هویتش را در میانه‌ی مکالمه از دست می‌دهد و رفتار غیرقابل‌پیش‌بینی نشان می‌دهد.

نمونه‌ی مستر پرامپت برای task دسته‌بندی متن:

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

این پرامپت حالت خطا تعریف کرده (متن کوتاه یا نامفهوم)، فرمت خروجی را بسته (یک خط، بدون توضیح) و مرزها را مشخص کرده. یک پرامپت معمولی این سه را ندارد.

فرآیند تکراری ساخت مستر پرامپت: از دستور خام تا قرارداد رفتاری#

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

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

چرا یک بار نوشتن کافی نیست؟ چون هر دور تست، شکست جدیدی را آشکار می‌کند که در دور قبل قابل‌پیش‌بینی نبود. تکامل یک پرامپت واقعی در چهار تکرار:

  • تکرار ۱ (نسخه‌ی خام): «این متن را دسته‌بندی کن.» — مدل گاهی توضیح اضافه می‌کند، گاهی دسته‌های خودش را اختراع می‌کند.
  • تکرار ۲ (افزودن فرمت): «فقط نام دسته را بنویس.» — توضیحات حذف شدند، اما مدل هنوز دسته‌های خارج از لیست تولید می‌کند.
  • تکرار ۳ (افزودن محدودیت): «فقط از این چهار دسته انتخاب کن.» — خروجی منظم شد، اما متن‌های ناقص باعث رفتار غیرقابل‌پیش‌بینی شدند.
  • تکرار ۴ (افزودن حالت خطا): «اگر متن کمتر از ۳۰ کلمه است، خروجی نامشخص باشد.» — حالا قرارداد کامل است.

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

نمونه‌ی مستر پرامپت برای تولید محتوای سئو:

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

این پرامپت را در اسکول، در بخش مدیریت پرامپت می‌توانید نسخه‌بندی و تست کنید.

الگوهای Few-shot و Chain-of-Thought چه زمانی مؤثرند و چه زمانی نتیجه را بدتر می‌کنند؟#

الگوهای Few-shot Prompting و Chain-of-Thought ابزارهای قدرتمندی‌اند، اما کاربردشان مشروط است. Few-shot برای task‌هایی مؤثر است که الگوی خروجی مشخص دارند؛ Chain-of-Thought فقط روی مدل‌های reasoning-specific بهبود واقعی ایجاد می‌کند و روی مدل‌های کوچک‌تر گاهی خروجی را آلوده می‌کند.

Few-shot: کی لازم است، کی مضر#

Few-shot مؤثر است وقتی مدل باید سبک، فرمت یا منطق خاصی را تقلید کند. مثلاً اگر می‌خواهید مدل به یک فرمت خاص JSON پاسخ دهد، دو نمونه‌ی ورودی-خروجی کافی‌اند. اما اگر task ساده است و مدل قبلاً آن را خوب انجام می‌دهد، افزودن نمونه‌ها فقط توکن مصرف می‌کند و گاهی مدل را گیج می‌کند. این را باید صریح گفت: Few-shot بدون نیاز، پرامپت را ضعیف‌تر می‌کند نه قوی‌تر.

Chain-of-Thought: محدودیت‌های واقعی#

پژوهش Wei et al. نشان داد که افزودن دستوراتی مثل «step by step فکر کن» روی مدل‌های reasoning-specific بهبود قابل‌توجهی دارد. اما این الگو روی مدل‌های کوچک‌تر یا مدل‌هایی که برای reasoning آموزش ندیده‌اند، گاهی خروجی را آلوده می‌کند. مدل شروع به تولید استدلال‌های ساختگی می‌کند که در واقع هیچ تأثیری روی تصمیم نهایی ندارند.

الگوی «فقط بگو think step by step» بدون توجه به نوع مدل، یک ضدالگو است. روی مدل‌های بزرگ reasoning‌محور مؤثر است، روی مدل‌های کوچک و general-purpose گاهی نتیجه را بدتر می‌کند — و بدتر از آن، شما متوجه نمی‌شوید چون خروجی «منطقی» به‌نظر می‌رسد.

نقش دما (Temperature) در ترکیب با الگوها: دمای پایین برای task‌های ساختاریافته (دسته‌بندی، استخراج) و دمای بالاتر برای task‌های خلاقانه (نوشتن، ایده‌پردازی). Few-shot با دمای پایین کار می‌کند؛ Chain-of-Thought با دمای متوسط.

مهندسی پرامپت در برابر Fine-tuning و RAG: جدول تصمیم‌گیری#

مهندسی پرامپت در برابر Fine-tuning و RAG سه ابزار مکمل‌اند، نه جایگزین. مهندسی پرامپت برای task‌های ثابت با داده‌ی کم مناسب است؛ Fine-tuning برای تغییر رفتار بنیادین مدل لازم است؛ و RAG برای دسترسی به دانش جدید. انتخاب بر اساس سه معیار انجام می‌شود: حجم تغییر لازم، در دسترس بودن داده و بودجه‌ی عملیاتی.

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

معیارمهندسی پرامپتFine-tuningRAG
زمان آماده‌سازیساعت تا چند روزهفته‌ها (داده‌سازی + آموزش)روز تا هفته (ایندکس + pipeline)
هزینه‌ی عملیاتیتوکن‌های بیشتر در هر callهزینه‌ی آموزش + inferenceهزینه‌ی جست‌وجو + توکن
انعطاف‌پذیریبالا — تغییر فوریپایین — نیاز به آموزش مجددمتوسط — تغییر در knowledge base
دقت قابل‌انتظاروابسته به مدل پایهبالا برای task‌های محدودبالا برای task‌های دانش‌محور

چه زمانی مستر پرامپت اشتباه است؟ وقتی task متغیر است و هر بار شکل دیگری دارد. وقتی داده‌ی ساختاریافته‌ی کافی برای آموزش ندارید. وقتی دقت موردنیاز با پرامپت قابل‌تحقق نیست و مدل پایه محدودیت ذاتی دارد.

مقایسه‌ی هزینه‌ی توکنی: مستر پرامپت‌های طولانی در هر call هزینه‌ی بیشتری دارند. اگر 500 توکن پرامپت سیستمی دارید و روزانه 1000 call می‌زنید، این هزینه‌ی پنهان است. در چنین حالتی Fine-tuning ممکن است اقتصادی‌تر باشد.

برای جزئیات بیشتر درباره‌ی RAG، مقاله‌ی مرتبط در اسکول را ببینید.

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

رایج‌ترین اشتباهات مهندسی پرامپت سه‌تایی‌اند: Over-specification، پرامپت طولانی بدون ساختار و نادیده‌گرفتن Prompt Injection. هر کدام هزینه‌ی مشخصی دارد — از تولید محتوای رباتیک که کاربر نمی‌خواند تا آسیب‌پذیری امنیتی که پرامپت سیستمی را دور می‌زند. تشخیص زودهنگام این سه، پروژه را از بحران نجات می‌دهد.

Over-specification: وقتی دقت بیش‌ازحد نتیجه را خراب می‌کند#

وقتی هر جزئیات را در پرامپت قید می‌کنید — لحن، طول، تعداد کلمات، ساختار جمله به جمله — مدل فضای تفسیر از دست می‌دهد. خروجی رباتیک و غیرطبیعی تولید می‌شود. هزینه: محتوایی که کاربر نمی‌خواند. پرامپت طولانی بدون ساختار بدتر از پرامپت کوتاه ناقص است؛ چون مدل در انبوه دستورالعمل‌ها، بخش‌های مهم را کم‌وزن‌تر می‌خواند.

Prompt Injection: ریسک امنیتی واقعی#

OWASP Prompt Injection را در ده ریسک برتر LLM طبقه‌بندی کرده است. هر پرامپتی که ورودی کاربر را بدون sanitization مصرف کند، در معرض این حمله است. مهاجم می‌تواند با تزریق دستور در ورودی، پرامپت سیستمی را دور بزند. این ریسک امنیتی، نه صرفاً یک نکته‌ی فنی.

نادیده‌گرفتن حالت‌های خطا#

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

Prompt Decay و نگهداشت: چرا پرامپت شما با تغییر مدل خراب می‌شود#

Prompt Decay پدیده‌ای است که در آن پرامپتی روی یک مدل عالی کار می‌کند، روی نسخه‌ی جدیدتر رفتار متفاوتی دارد. نگهداشت پرامپت نیازمند تست منظم روی مدل‌های جدید، مقایسه با baseline و استراتژی rollback است. بدون این چرخه، هر آپدیت مدل می‌تواند پرامپت شما را بی‌صدا خراب کند.

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

استراتژی تست:

  1. قبل از انتقال به production، پرامپت را روی نسخه‌ی جدید مدل اجرا کنید.
  2. خروجی‌ها را با baseline نسخه‌ی قبلی مقایسه کنید.
  3. در صورت تغییر رفتار، پرامپت را بازنگری کنید — نه مدل را.
  4. نسخه‌ی قبلی پرامپت را برای rollback نگه دارید.

ابزارهای مدیریت پرامپت (Prompt Management) این چرخه را خودکارسازی می‌کنند. مقایسه‌ی کوتاه: LangSmith، PromptLayer و Humanloop هر کدام نسخه‌بندی، A/B testing و پایش خروجی را ارائه می‌دهند. انتخاب بستگی به stack شما دارد.

تکرار پرامپت (Prompt Iteration) بخشی از چرخه‌ی نگهداشت پرامپت است، نه یک مرحله‌ی یک‌بار. هر بار که مدل، task یا داده‌های ورودی تغییر می‌کنند، مستر پرامپت باید بازبینی شود.

چه زمانی مهندسی پرامپت کافی نیست و باید سراغ روش‌های دیگر رفت#

چه زمانی مهندسی پرامپت کافی نیست؟ وقتی task متغیر است، داده‌ی ساختاریافته در دسترس نیست، یا دقت موردنیاز با پرامپت قابل‌تحقق نیست. سه نشانه‌ی خروج از محدوده: شکل task هر بار عوض می‌شود، محدودیت‌ها قابل‌تعریف نیستند، و بعد از چند دور تکرار دقت هنوز زیر حد قابل‌قبول است.

  • نشانه‌ی ۱: task شما هر بار شکل دیگری دارد و نمی‌توانید یک قرارداد رفتاری ثابت بنویسید.
  • نشانه‌ی ۲: داده‌ی ساختاریافته‌ی کافی برای تعریف محدودیت‌ها ندارید.
  • نشانه‌ی ۳: بعد از چند دور تکرار، دقت هنوز زیر حد قابل‌قبول است.

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

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

مهندسی پرامپت چکش همه‌چیز نیست. وقتی پیچ‌گوشتی لازم است، چکش را زمین بگذارید.

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