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

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

مهندسی پرامپت (Prompt Engineering) طراحی ورودی متنی برای مدل زبانی بزرگ است، بدون دست‌زدن به وزن‌های مدل. برخلاف فاین‌تیونینگ که داده‌ی اختصاصی و GPU می‌خواهد، و برخلاف کدنویسی که منطق را در کد تعریف می‌کند، مهندسی پرامپت منطق را در خودِ متن می‌نویسد. هزینه‌ی شروعش فقط وقت است.

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

وقتی یک ایجنت هوش مصنوعی (AI Agent) می‌سازید، مهندسی پرامپت لایه‌ی بالایی معماری است. زیر آن مدل، ابزارها و داده‌ها قرار دارند. پرامپت بد، حتی با بهترین مدل، خروجی بی‌ثبات تولید می‌کند. پرامپت خوب، مدل متوسط را به سطح قابل‌قبول می‌رساند. این جمله‌ی آخر، بخش قابل‌بحثِ کار است؛ چون «قابل‌قبول» معیار مبهمی است و بهتر است هر تیم خودش خط‌کشی کند.

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

تفاوت بنیادین با فاین‌تیونینگ و RAG از نظر هزینه، زمان و پیش‌نیاز فنی#

فاین‌تیونینگ (Fine-tuning) یعنی تغییر وزن‌های مدل با داده‌های اختصاصی. RAG (Retrieval-Augmented Generation) یعنی اتصال مدل به پایگاه دانش بیرونی. هر سه روش جایگاه متفاوتی در طیف هزینه و پیچیدگی دارند.

روش هزینه‌ی شروع پیش‌نیاز فنی مناسب برای
مهندسی پرامپت کم (فقط زمان) مهارت نوشتاری کارهای عمومی و متوسط
RAG متوسط (زیرساخت داده) مهندسی داده دانش تخصصی و به‌روز
فاین‌تیونینگ بالا (داده + GPU) یادگیری ماشین الگوهای رفتاری خاص

آیا برای شروع مهندسی پرامپت به برنامه‌نویسی نیاز دارید؟#

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

مستر پرامپت یک قرارداد است، نه یک دستور#

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

دو دست در دو طرف میز، یکی با قلم بالای یک سند ساختارمند با مرزهای هندسی، نماد قرارداد میان کاربر و مدل
قرارداد خوب هم مرز مشخص دارد هم شرط و شروط — دقیقاً مثل یک مستر پرامپت

اجزای یک مستر پرامپت: نقش، محدوده، خروجی، محدودیت و شرط شکست#

هر مستر پرامپت مؤثر حداقل پنج جزء دارد:

  1. نقش (Role): مدل در چه جایگاهی پاسخ می‌دهد؟ نه «متخصص باش»، بلکه «تو یک بازرس فنی ساختمان هستی که فقط بر اساس آیین‌نامه‌ی ملی ایران نظر می‌دهی.»
  2. محدوده‌ی مسئله (Scope): چه چیزهایی داخل و چه چیزهایی خارج از مسئولیت مدل است؟
  3. فرمت خروجی (Output Format): ساختار دقیق پاسخ — JSON، جدول، پاراگراف، یا هر چیز دیگر.
  4. محدودیت‌ها (Constraints): چه کارهایی مدل نباید بکند؟ چه لحنی ممنوع است؟
  5. شرط شکست (Failure Condition): اگر مدل مطمئن نیست یا داده کافی ندارد، دقیقاً چه کند؟ «نمی‌دانم» بگوید، سؤال بپرسد، یا خروجی خالی برگرداند.

گام‌به‌گام ساخت مستر پرامپت از صفر تا تست و استقرار#

ساخت مستر پرامپت یک فرایند خطی نیست. چرخه‌ی تکرار دارد. اما نقطه‌ی شروع مشخص است:

  1. مسئله را به‌صورت یک جمله بنویسید.
  2. پنج جزء قرارداد را پر کنید.
  3. روی یک کار واقعی تست کنید.
  4. خروجی را با معیار «آیا از محدوده خارج شده؟» بسنجید.
  5. اگر خارج شده، شرط شکست را سخت‌تر کنید.
  6. اگر درون محدوده مانده ولی فرمت غلط است، بخش Output Format را دقیق‌تر کنید.

محدودیت‌های پنجره‌ی زمینه و تأثیر آن بر پرامپت‌های بلند#

پدیده‌ی Lost in the Middle نشان می‌دهد مدل‌ها اطلاعات میانی پرامپت‌های طولانی را ضعیف‌تر از ابتدایی و انتهایی یاد می‌گیرند. در عمل، مستر پرامپت‌های طولانی بدون ساختاردهی صریح، ریسک از دست رفتن دستورالعمل‌های میانی دارند. اگر پرامپت‌تان از یک صفحه‌ی A4 رد می‌شود، حتماً سرتیتر و شماره‌گذاری بگذارید.

نمونه‌ی پرامپت آماده — ساختار قرارداد برای یک کار واقعی:

نقش: تو یک ویراستار فنی مقالات برنامه‌نویسی هستی.
محدوده: فقط جملات دستوری، اصطلاحات فنی نادرست و ناهمخوانی‌های لحن را اصلاح کن.
خارج از محدوده: محتوا، ساختار مقاله و انتخاب موضوع را تغییر نده.
خروجی: جدول سه‌ستونه — «عبارت اصلی | عبارت اصلاح‌شده | دلیل»
محدودیت: اگر عبارتی مشکوک است ولی مطمئن نیستی، در ستون دلیل بنویس «نیاز به تأیید نویسنده» و آن را تغییر نده.
شرط شکست: اگر ورودی کمتر از 50 کلمه است، فقط بنویس «ورودی کوتاه‌تر از حداقل قابل ویرایش.»

نمونه‌ی پرامپت آماده — مستر پرامپت با خروجی ساختارمند JSON:

نقش: تو یک تحلیل‌گر احساسات متنی هستی.
محدوده: فقط احساس غالب (مثبت/منفی/خنثی) و درجه‌ی اطمینان (0 تا 1) را استخراج کن.
خروجی: JSON با کلیدهای sentiment, confidence, reasoning
محدودیت: reasoning حداکثر 20 کلمه. هیچ توضیح اضافه‌ای خارج از JSON نده.
شرط شکست: اگر متن شامل طعنه یا کنایه است و اطمینانت زیر 0.6 است، sentiment را "ambiguous" قرار بده.

چرا پرامپت من جواب خوب نمی‌دهد و چطور اصلاحش کنم؟#

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

هزینه‌ی پنهان پرامپت بد: چند برابر شدن چرخه‌های بازنگری#

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

هزینه‌ی پنهان فقط زمان نیست. اعتبار API هم می‌سوزد. پرامپت 500 توکنی که سه بار تکرار شود، 1500 توکن مصرف کرده. پرامپت 800 توکنی با ساختار قرارداد، معمولاً یک بار کافی است. تفاوت 700 توکنی، در مقیاس هزاران فراخوانی، به‌مقدار قابل‌توجهی تبدیل می‌شود.

چرخه‌ی تکرار و بهینه‌سازی پرامپت (Iterative Refinement) در عمل#

بهینه‌سازی پرامپت یعنی تغییر هدفمند یک متغیر در هر تکرار. نه تغییر تصادفی کلمات. در هر چرخه، فقط یک جزء قرارداد را عوض کنید و نتیجه را با معیار مشخص بسنجید. اگر دو چیز را هم‌زمان تغییر دهید، نمی‌فهمید کدام مؤثر بوده. این قاعده، ساده‌ترین و بیشترین نقض را دارد.

اشتباهات رایج و الگوهای ضدکارآمد: جادوی کلمات، پرامپت طولانی بدون ساختار، Few-shot بی‌هدف#

سه الگوی ضدکارآمد که در پروژه‌های اعضای کامیونیتی بارها گزارش شده:

  • جادوی کلمات: «Deeply think about this» یا «Take a deep breath». این عبارت‌ها روی مدل‌های جدید اثر معناداری ندارند و فقط فضای توکن می‌گیرند.
  • پرامپت طولانی بدون ساختار: متن پشت سر هم بدون سرتیتر یا شماره‌گذاری. مدل بخش‌هایی را نادیده می‌گیرد.
  • Few-shot بی‌هدف: سه مثال بی‌ربط اضافه کردن فقط به امید بهتر شدن خروجی. اگر مثال‌ها تنوع کار را نشان نمی‌دهند، به مدل سیگنال غلط می‌دهند.

تکنیک‌های بنیادین مهندسی پرامپت: کدام‌ها واقعاً کار می‌کنند؟#

تکنیک‌های Few-shot، Chain-of-Thought و Structured Output مؤثرند اما هرکدام شرایط مدل و کار خاصی دارند. استفاده‌ی کورکورانه از هر سه روی هر مدلی نتیجه‌ی معکوس می‌دهد. انتخاب تکنیک باید بر اساس ماهیت مسئله و ظرفیت مدل باشد، نه بر اساس ترندهای توییتر.

نمونه‌محور (Few-shot) و بدون‌مثال (Zero-shot): چه زمانی مثال لازم است و چه زمانی مانع می‌شود#

Zero-shot وقتی کار می‌کند که مسئله ساده و شناخته‌شده باشد و مدل از پیش آموزش‌های کافی دیده باشد. Few-shot مؤثر است وقتی فرمت خروجی، لحن یا منطق خاصی مد نظر دارید که مدل بدون مثال نمی‌تواند حدس بزند.

اما Few-shot روی کارهای پیچیده‌ی استدلالی گاهی مانع می‌شود. مثال‌های ساده، مدل را به سمت پاسخ‌های ساده‌انگارانه هدایت می‌کنند و عمق استدلال کاهش می‌یابد. دقیق‌تر بگویم: مثال بد از نبودِ مثال خطرناک‌تر است.

زنجیره‌ی تفکر (Chain-of-Thought): فقط روی مدل‌های با ظرفیت استدلالی بالا#

Chain-of-Thought روی مدل‌های بزرگ با ظرفیت استدلالی بالا مؤثر است. روی مدل‌های کوچک، «Think step by step» نتیجه‌ی معکوس می‌دهد چون مدل توانایی اجرای زنجیره‌ی منطقی چندمرحله‌ای را ندارد و فقط توکن اضافه مصرف می‌کند. روی مدل‌های کوچک، Chain-of-Thought اغلب به‌جای کمک، توکن اضافه مصرف می‌کند و خروجی را بدتر می‌کند.

خروجی ساختارمند (Structured Output) و کاهش چرخه‌های بازنگری از طریق تست خودکار#

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

نقش‌آفرینی مؤثر: چرا «Act as an expert» بدون تعریف محدوده اثر ندارد#

«Act as an expert» به‌تنهایی بی‌اثر است چون «متخصص» یک کلمه‌ی مبهم است. مدل نمی‌فهمد در چه حوزه‌ای، با چه سطحی از جزئیات، و با چه محدودیت‌هایی باید پاسخ دهد. نقش بدون محدوده، فقط یک صفت تزئینی است. نقش‌آفرینی مؤثر یعنی جایگزینی صفت مبهم با قید مشخص: نه «متخصص باش» بلکه «فقط بر اساس آیین‌نامه‌ی ملی نظر بده.»

محدوده‌ی مهندسی پرامپت و جایگزین‌های اجتناب‌ناپذیر آن#

مهندسی پرامپت نقطه‌ی شروع عالی است، اما سقف مشخصی دارد. وقتی مسئله به دانش تخصصی عمیق، دقت عددی بالا یا رفتار پایدار در میلیون‌ها فراخوانی نیاز دارد، فاین‌تیونینگ یا RAG جایگزین‌های اجتناب‌ناپذیرند.

مرز بین پرامپت، RAG و فاین‌تیونینگ: تصمیم‌گیری بر اساس هزینه و پیش‌نیاز#

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

مهندسی پرامپت در برابر تزریق پرامپت (Prompt Injection): چه زمانی پرامپت شما آسیب‌پذیر است؟#

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

تفکیک مهندسی پرامپت از طراحی تعامل با AI (AI Interaction Design)#

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

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

مدل‌های GPT-4، Claude، Gemini و Llama در تفسیر ساختار، طول پرامپت و لحن ورودی تفاوت‌های رفتاری دارند. پرامپت پرتابل باید روی حداقل دو مدل تست شود. از عبارت‌های مدل‌محور یا magic words پرهیز کنید.

الگوی تست چندمدلی: A/B Testing پرامپت روی GPT-4 و Claude هم‌زمان#

در عمل، پرامپتی که روی Claude با ساختار XML خروجی تمیز می‌دهد، روی GPT-4 ممکن است همان ساختار را نادیده بگیرد و بالعکس. الگوی A/B Testing پرامپت یعنی: یک پرامپت ثابت، دو مدل مختلف، مقایسه‌ی خروجی بر اساس سه معیار — رعایت محدوده، صحت فرمت، و کیفیت محتوایی. اگر فقط روی یک مدل تست می‌کنید، پرامپت شما به آن مدل قفل شده و مهاجرت به مدل دیگر، پرامپت‌نویسی مجدد است.

ابزارهای مدیریت نسخه و تست خودکار پرامپت#

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

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

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