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

مستر پرامپت یک پرامپت طولانی نیست#

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

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

تفاوت پرامپت معمولی، System Prompt و مستر پرامپت#

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

الگوی شش‌ضلعی#

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

  • نقش (Role): مدل در چه هویتی پاسخ می‌دهد؟
  • هدف (Goal): خروجی نهایی دقیقاً چه مشکلی را حل می‌کند؟
  • زمینه (Context): چه اطلاعاتی مدل باید بداند تا تصمیم درست بگیرد؟
  • محدودیت‌ها (Constraints): چه چیزهایی مجاز نیست؟
  • فرمت خروجی (Output Format): ساختار دقیق پاسخ چیست؟
  • نمونه (Example): حداقل یک ورودی-خروجی کامل.

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

ساختار استاندارد یک مستر پرامپت حرفه‌ای چیست؟#

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

نقش و هدف: مرز بین کمک و ابهام#

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

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

زمینه و محدودیت‌ها#

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

فرمت خروجی#

فرمت خروجی تأثیر مستقیم بر قابلیت استفاده در فرآیندهای بعدی دارد. اگر خروجی را برای یک اسکریپت مصرف می‌کنید، ساختار JSON ضروری است. اگر برای یک انسان است، ساختار Markdown مناسب‌تر است.

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

نقش: تو یک کپی‌رایتر سئو با تجربه‌ی تخصصی در حوزه‌ی تکنولوژی فارسی‌زبان هستی.

هدف: یک پاراگراف 40 تا 60 کلمه‌ای بنویس که پاسخ مستقیم یک پرسش جستجو را بدهد و قابل استخراج به‌عنوان Featured Snippet باشد.

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

محدودیت‌ها:
- از کلمات کلیشه‌ای AI («در دنیای امروز»، «بدون شک»، «لازم به ذکر است») استفاده نکن.
- عدد ساختگی ننویس.
- پاراگراف معمولی باشد، نه لیست.

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

نمونه:
پرسش: مهندسی پرامپت چیست؟
pاسخ: مهندسی پرامپت (Prompt Engineering) طراحی ورودی‌های ساختاریافته برای مدل‌های زبانی بزرگ (LLM) است تا خروجی قابل‌تکرار و دقیق تولید کنند. برخلاف پرامپت‌نویسی ساده، مهندسی پرامپت شامل تعریف نقش، محدودیت، فرمت خروجی و نمونه‌های Few-Shot است و نتیجه‌اش یک مؤلفه‌ی قابل تست در سیستم است.

نمونه‌ی آماده‌ی کپی‌کردنی — مستر پرامپت تحلیل داده:

نقش: تو یک تحلیلگر داده با تخصص در آمار توصیفی و ارائه‌ی بصری هستی.

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

زمینه: داده‌ها از یک فروشگاه آنلاین SaaS با چرخه‌ی فروش B2B هستند. مخاطب تصمیم‌گیرنده، مدیر محصول است نه دیتاساینتیفیس.

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

فرمت خروجی:
{ "findings": [{ "insight": "...", "supporting_data": "...", "action": "..." }], "confidence": "high|medium|low", "missing_data": ["..."] }

نمونه:
داده: نرخ تبدیل ماه اول: 3.2٪، ماه دوم: 4.1٪، ماه سوم: 3.9٪
پاسخ: { "findings": [{ "insight": "نرخ تبدیل در ماه دوم جهش داشته اما در ماه سوم افت جزئی کرده", "supporting_data": "3.2٪ → 4.1٪ → 3.9٪", "action": "بررسی تغییرات ماه دوم (کمپین؟ بهبود UX؟) و تکرار آن" }], "confidence": "medium", "missing_data": ["تفکیک کانال‌ها", "حجم ترافیک"] }

چرا پرامپت طولانی‌تر خروجی دقیق‌تر نمی‌دهد؟#

افزایش طول پرامپت بدون ساختار، نویز زمینه را بالا می‌برد و مدل را از هدف اصلی دور می‌کند. دقت خروجی تابع کیفیت ساختار است نه کمیت کلمات. پرامپت 500 کلمه‌ای بدون فرمت، از پرامپت 50 کلمه‌ای با ساختار شش‌ضلعی ضعیف‌تر است.

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

  1. کپی پرامپت‌های وایرال: پرامپتی که برای تولید عکس طراحی شده، در تحلیل داده شکست می‌خورد. بدون تطبیق با نیاز پروژه، کپی کردن فقط کپی‌برداری است.
  2. دستورات احساسی بدون منطق: «لطفاً با دقت و حوصله و خلاقیت پاسخ بده» به مدل چیزی نمی‌گوید. «خروجی باید شامل سه بخش مجزا باشد» می‌گوید.
  3. نادیده گرفتن Iterative Refinement: اولین نسخه‌ی پرامپت معمولاً ناقص است. بدون چرخه‌ی تست و اصلاح، انتظار خروجی حرفه‌ای بی‌منطق است.
  4. تخلط با Fine-Tuning: مهندسی پرامپت روی ورودی مدل کار می‌کند. Fine-Tuning وزن‌های مدل را تغییر می‌دهد. این دو مکمل‌اند، نه جایگزین.

راهکار عملی: پرامپت مبهم خود را با این الگو شفاف کنید:

Before: «یک مقاله درباره‌ی مهندسی پرامپت بنویس»
After: «نقش: مدرس مهندسی پرامپت. هدف: توضیح تفاوت پرامپت معمولی و مستر پرامپت برای مخاطب فنی. فرمت: سه پاراگراف 50 کلمه‌ای. محدودیت: بدون عدد ساختگی، بدون کلیشه.»

تکنیک‌های پایه: زنجیره‌ی افکار و نمونه‌های کم#

Chain-of-Thought (CoT) مدل را وادار به گام‌به‌گام استدلال می‌کند و Few-Shot Prompting با نمایش نمونه‌های ورودی-خروجی، الگوی مطلوب را به مدل می‌آموزد. هر دو در وظایف پیچیده مکمل یکدیگرند و در مستر پرامپت‌های حرفه‌ای معمولاً با هم استفاده می‌شوند.

Chain-of-Thought: چه زمانی و چگونه#

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

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

Few-Shot Prompting: تعداد و انتخاب#

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

مقایسه‌ی عملی سه تکنیک:

تکنیکزمان استفادههزینه‌ی توکنیپیچیدگی پیاده‌سازی
Role Promptingهر مستر پرامپتکمساده
Few-Shotفرمت‌های خاص و پیچیدهمتوسط تا بالامتوسط
Chain-of-Thoughtاستدلال چندمرحله‌ایبالا (خروجی طولانی‌تر)متوسط

مدیریت پنجره زمینه و کاهش توهم مدل#

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

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

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

تقسیم وظایف (Task Decomposition)#

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

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

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

مهندسی پرامپت را جدی بگیرید، نه طولانی#

مستر پرامپت یک سیستم قابل تست است، نه یک پاراگراف طولانی. الگوی شش‌ضلعی، چرخه‌ی Iterative Refinement و تقسیم وظایف سه ابزار اصلی‌اند. بلندتر نوشتن بدون ساختار، فقط نویز تولید می‌کند.

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