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

مهندسی پرامپت چیست و چرا «نوشتن سؤال» کافی نیست#

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

تفاوت پرامپت معمولی با پرامپت مهندسی‌شده#

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

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

چرا مدل‌های جدیدتر به پرامپت دقیق‌تر نیاز دارند، نه کمتر#

اینجا یک سوءتفاهم رایج وجود دارد: «مدل قوی‌تر، پرامپت ساده‌تر می‌خواهد». دقیقاً برعکس. مدل‌های قوی‌تر توانایی پیروی از دستور (Instruction-following) بهتری دارند، و دقیقاً به همین دلیل، پرامپت مبهم در مدل قوی‌تر نتیجه‌ی مبهم‌تری تولید می‌کند. مدل‌های قدیمی‌تر چون ظرفیت کمتری داشتند، پرامپت‌های ساده‌تر را «تحمل» می‌کردند؛ مدل‌های جدید انتظار دستور دقیق دارند.

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

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

ساختار یک مستر پرامپت قابل‌بازاستفاده چگونه است؟#

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

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

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

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

فریم‌ورک‌های ساخت پرامپت: CRISPE، CO-STAR و RTF کدام را انتخاب کنیم؟#

هر سه فریم‌ورک اجزای مشابهی دارند اما برای سطوح متفاوتی از پیچیدگی طراحی شده‌اند. RTF (Role, Task, Format) ساده‌ترین است و برای کارهای تک‌مرحله‌ای کافی است. CRISPE (Capacity, Insight, Statement, Personality, Experiment) برای کارهای تحلیلی و چندمرحله‌ای مناسب‌تر است. CO-STAR (Context, Objective, Style, Tone, Audience, Response) بهترین انتخاب برای تولید محتوای بازاریابی و برندینگ است.

انتخاب بین این سه، به بلوغ تیم بستگی دارد نه به «بهترین بودن» یکی. تیمی که هنوز پرامپت‌هایش را نسخه‌بندی نکرده، با RTF شروع کند. تیمی که خروجی‌هایش ناپایدار است، به CRISPE یا CO-STAR نیاز دارد.

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

نمونه‌ی آماده‌ی مستر پرامپت فارسی:

نقش: تو یک متخصص سئوی فارسی‌زبان با ۱۰ سال تجربه هستی.

زمینه: من یک فروشگاه آنلاین لباس زنانه دارم که مخاطب آن زنان ۲۵ تا ۴۰ ساله در تهران هستند.

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

فرمت خروجی: عنوان + پاراگراف مقدمه + ۵ بولت پوینت + یک CTA.

نمونه:
ورودی: «توضیح درباره‌ی شال ابریشم»
خروجی: «شال ابریشم؛ انتخابی که استایل شما را متحول می‌کند / پاراگراف مقدمه / بولت‌ها / CTA»

حالا برای موضوع «[متغیر: موضوع]» پرامپت بالا را اجرا کن.

Chain-of-Thought و Few-shot: دو تکنیک پیشرفته که خروجی را تغییر می‌دهند#

زنجیره‌ی تفکر (Chain-of-Thought) مدل را وادار به گام‌به‌گام استدلال می‌کند و Few-shot با ارائه‌ی نمونه‌های چندتایی الگوی خروجی را مشخص می‌کند؛ اما در مدل‌های بزرگ‌تر Few-shot گاهی نتیجه را بدتر می‌کند، نه بهتر.

Chain-of-Thought: چه زمانی و چگونه استفاده شود#

Chain-of-Thought در کارهایی مفید است که مدل باید چند مرحله‌ی منطقی طی کند: حل مسئله‌ی ریاضی، تحلیل چندمتغیره، یا تصمیم‌گیری با شرایط متعارض. در کارهای ساده‌ی استخراج یا بازنویسی، اضافه‌کردن CoT فقط توکن مصرفی را بالا می‌برد و هیچ کمکی به کیفیت نمی‌کند.

مقاله‌ی Kojima et al. (2022) با عنوان «Large Language Models are Zero-Shot Reasoners» نشان داد که اضافه‌کردن عبارت «Let's think step by step» به پرامپت، دقت مدل را در مسائل چندمرحله‌ای به‌طور قابل‌توجهی افزایش می‌دهد. مقاله‌ی Wei et al. (2022) در NeurIPS نیز با ارائه‌ی نمونه‌های استدلال گام‌به‌گام (few-shot CoT)، همین الگو را تقویت کرد. این یافته‌ها، صنعت پرامپت‌نویسی را متحول کردند.

نمونه‌ی آماده‌ی پرامپت با Chain-of-Thought:

نقش: تو یک تحلیلگر داده‌های مالی هستی.

وظیفه: سودآوری یک محصول را بر اساس داده‌های زیر تحلیل کن.

داده‌ها:
قیمت فروش: [متغیر]
هزینه تولید: [متغیر]
تعداد فروش ماهانه: [متغیر]

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

فرمت خروجی: ابتدا مراحل تحلیل، سپس نتیجه‌ی نهایی در یک جمله.

Few-shot Prompting: چرا در مدل‌های Instruction-tuned تأثیرش کم شده#

در مدل‌های کوچک‌تر، Few-shot (نمونه‌های چندتایی) تقریباً تنها راه آموزش مدل برای یک وظیفه‌ی خاص بود. اما مدل‌های بزرگ با آموزش Instruction-tuning قوی، گاهی الگوی نمونه را به‌جای دستور اصلی دنبال می‌کنند و نتیجه بدتر می‌شود.

اینجا باید یک نکته را اصلاح کنم: Few-shot در مدل‌های جدید «مرده» نیست، بلکه جایگاهش عوض شده. از «ابزار آموزش» تبدیل شده به «ابزار تنظیم فرمت». یعنی برای نشان دادن ساختار خروجی هنوز مفید است، نه برای آموزش مدل.

تکنیک Self-consistency (خودسازگاری): پرامپت را چند بار اجرا کنید و از خروجی‌ها رأی‌گیری کنید. این روش دقت Chain-of-Thought را افزایش می‌دهد اما هزینه‌ی API را چند برابر می‌کند. برای کارهای حساس مثل تحلیل حقوقی یا پزشکی مناسب است، نه برای تولید محتوای روزانه.

چه زمانی مهندسی پرامپت جواب نمی‌دهد و باید سراغ RAG یا Fine-tuning برویم؟#

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

جدول مقایسه‌ای: پرامپت، RAG و Fine-tuning در ۶ معیار#

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

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

  • مدل مرتب اطلاعات قدیمی یا نادرست تولید می‌کند و با محدودیت نمی‌توانید جلوی آن را بگیرید.
  • خروجی مدل به داده‌های داخلی شما (سوابق مشتری، محصولات، قیمت‌ها) نیاز دارد.
  • سبک نوشتاری خاصی دارید که حتی با نمونه‌های Few-shot قابل تقلید نیست.
  • پرامپت شما به بیش از ۲۰۰۰ توکن رسیده و مدل بخش‌هایی را نادیده می‌گیرد.

الگوی مشاهده‌شده: تیم‌هایی که ابتدا با پرامپت شروع می‌کنند و سپس به RAG مهاجرت می‌کنند. این مسیر طبیعی است. پرامپت مهندسی‌شده را به‌عنوان «لایه‌ی اول» نگه دارید و RAG را به‌عنوان «لایه‌ی دوم» اضافه کنید — نه اینکه پرامپت را دور بیندازید.

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

مدل‌های فارسی‌زبان Context Window کوچک‌تر و توانایی پیروی از دستور ضعیف‌تری دارند؛ کپی‌پیست پرامپت انگلیسی حتی با ترجمه‌ی دقیق، نتیجه‌ی ضعیف‌تری نسبت به ساختار انگلیسی + محتوای فارسی می‌دهد. این شکست، زبان‌شناختی نیست، فنی است.

تفاوت رفتاری مدل‌ها: Claude، GPT-4 و Gemini در فارسی#

الگوی مشاهده‌شده در پروژه‌های فارسی‌زبان: Claude به توضیح ساختار خروجی حساس‌تر است — اگر فرمت خروجی را دقیق بنویسید، نتیجه‌ی بهتری می‌دهد. GPT-4 به نقش‌دهی (Role Assignment) پاسخ بهتری نشان می‌دهد — مشخص کردن شخصیت مدل تأثیر بیشتری دارد. Gemini به زمینه‌دهی (Context Priming) واکنش بهتری نشان می‌دهد — پس‌زمینه‌ی غنی‌تر نتیجه‌ی بهتری تولید می‌کند.

حداقل ۲ نسخه‌ی متفاوت از پرامپت اصلی برای مدل‌های مختلف بنویسید. یک پرامپت یکسان برای همه مدل‌ها نتیجه‌ی یکسان نمی‌دهد.

الگوی ترکیبی: ساختار انگلیسی + محتوای فارسی#

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

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

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

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

بلندتر نوشتن، یکسان استفاده‌کردن برای همه مدل‌ها، Few-shot اجباری، پرامپت بدون نسخه‌بندی و توصیه‌های مبهم مثل «شفاف بپرسید» پنج اشتباهی‌اند که در نتایج فارسی‌زبان مکرر دیده می‌شوند. هر کدام، هزینه‌ی مشخصی روی کیفیت خروجی می‌گذارد.

«هرچه بلندتر، بهتر» — چرا در مدل‌های جدید نتیجه‌ی عکس می‌دهد#

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

«مهندسی پرامپت مرده است» — چرا این ادعا نادرست است#

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

هزینه‌ی واقعی هر اشتباه:

  1. بلندنویسی: افت Consistency (ثبات خروجی) — مدل در هر اجرا بخش‌های متفاوتی را اولویت می‌دهد.
  2. پرامپت یکسان برای همه مدل‌ها: افت Adherence (پایبندی به محدودیت) — مدل‌های مختلف محدودیت‌های مختلف را رعایت می‌کنند.
  3. Few-shot اجباری: در مدل‌های Instruction-tuned، مدل الگوی نمونه را به‌جای دستور اصلی دنبال می‌کند.
  4. بدون نسخه‌بندی: پس از چند ماه نمی‌دانید کدام پرامپت چرا بهتر کار می‌کرد و کیفیت افت تدریجی می‌کند.
  5. توصیه‌های مبهم: «شفاف بپرسید» یا «دقیق بنویسید» بدون مثال، عملاً هیچ راهنمایی به مدل نمی‌دهد.

چرخه‌ی عمر پرامپت — گام‌به‌گام:

  1. طراحی: مستر پرامپت را با ۵ جزء بنویسید.
  2. تست: حداقل ۱۰ ورودی متفاوت را اجرا کنید و خروجی‌ها را مقایسه کنید.
  3. ارزیابی: Consistency، Adherence و Relevance را اندازه بگیرید.
  4. نسخه‌بندی: هر تغییر را با تاریخ و دلیل ثبت کنید.
  5. بازنشستگی: نسخه‌های قدیمی را بایگانی کنید تا در صورت نیاز قابل بازیابی باشند.

چگونه بفهمیم پرامپت ما واقعاً بهتر کار می‌کند؟#

ارزیابی پرامپت با سه معیار قابل‌اندازه‌گیری انجام می‌شود: ثبات خروجی (Consistency)، پایبندی به محدودیت‌ها (Adherence) و ارتباط با سؤال اصلی (Relevance)؛ ابزارهایی مثل Promptfoo و LangSmith این فرایند را خودکار می‌کنند. بدون این سه معیار، «بهتر شدن» صرفاً یک حس است، نه یک واقعیت.

معیارهای کمّی ارزیابی پرامپت و نحوه‌ی اندازه‌گیری#

  • Consistency (ثبات خروجی): یک پرامپت را ۵ بار با ورودی یکسان اجرا کنید. چند خروجی از ۵ از نظر ساختاری مشابه‌اند؟ اگر کمتر از ۴ از ۵، پرامپت ناپایدار است.
  • Adherence (پایبندی به محدودیت): از هر ۱۰ محدودیت در پرامپت، چند مورد در خروجی رعایت شده؟ هر محدودیت نقض‌شده یک باگ پرامپت است.
  • Relevance (ارتباط با سؤال): خروجی مستقیماً به درخواست پاسخ می‌دهد یا حاشیه می‌رود؟ این معیار ذهنی است اما با نمونه‌ی مرجع قابل عیاردهی.

ابزارهای مدیریت و تست پرامپت: Promptfoo، LangSmith و PromptLayer#

Promptfoo یک ابزار متن‌باز برای تست خودکار پرامپت‌هاست. پرامپت‌ها را در فایل YAML تعریف می‌کنید، ورودی‌های تست را مشخص می‌کنید و ابزار خروجی‌ها را با معیارهای شما مقایسه می‌کند. LangSmith بیشتر برای تیم‌هایی مناسب است که خط لوله‌ی کامل (pipeline) دارند و می‌خواهند هر مرحله را ردیابی کنند. PromptLayer برای نسخه‌بندی و ثبت تاریخچه‌ی تغییرات پرامپت طراحی شده.

چرخه‌ی A/B تست پرامپت در پروژه‌های واقعی: دو نسخه‌ی پرامپت را با ورودی یکسان اجرا کنید. خروجی‌ها را با معیارهای Consistency و Adherence مقایسه کنید. نسخه‌ی برنده را به‌عنوان نسخه‌ی جدید ثبت کنید. این چرخه را هر بار که پرامپت را تغییر می‌دهید تکرار کنید.

نمونه‌ی پرامپت با ساختار ارزیابی‌پذیر:

نقش: ویراستار محتوای وب فارسی

ورودی: [متن خام]

محدودیت‌ها:
1. طول خروجی: بین ۱۵۰ تا ۲۵۰ کلمه
2. بدون حشو و تکرار
3. جملات حداکثر ۲۰ کلمه
4. لحن: محاوره‌ای و مستقیم
5. بدون عبارت‌های ممنوعه: «بدون شک»، «لازم به ذکر است»، «در دنیای امروز»

فرمت خروجی:
- عنوان: حداکثر ۸ کلمه
- مقدمه: ۲ جمله
- بدنه: ۳ تا ۵ پاراگراف
- نتیجه: ۱ جمله

معیارهای ارزیابی (برای خودتان چک کنید):
□ آیا طول خروجی در بازه‌ی تعیین‌شده است؟
□ آیا همه محدودیت‌ها رعایت شده؟
□ آیا لحن محاوره‌ای حفظ شده؟

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

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