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

مهندسی پرامپت چیست و چرا «دقیق بنویسید» کافی نیست#

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

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

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

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

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

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

مهندسی پرامپت اولین لایه‌ی تعامل با مدل است — قبل از کدنویسی، قبل از Fine-tuning و قبل از RAG (Retrieval-Augmented Generation). این یعنی ارزان‌ترین و سریع‌ترین مرحله‌ی بهینه‌سازی. اگر پرامپت‌تان بد طراحی شده باشد، هیچ مقدار داده یا GPU نمی‌تواند جبرانش کند.

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

پیش‌نیازهای عملی برای شروع#

  • توانایی تفکیک مسئله به ورودی، خروجی و محدودیت
  • آشنایی با فرمت‌های ساختاریافته مانند JSON و Markdown
  • درک پنجره‌ی بافتی (Context Window) مدل
  • صبر برای تست تکراری و ثبت تغییرات

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

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

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

لایه‌ی هویت (Role Prompting)#

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

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

لایه‌ی وظیفه و محدودیت#

وظیفه یعنی «چه کار کن». محدودیت یعنی «چه کار نکن». این دو را جدا بنویسید. ترکیب‌کردنشان در یک جمله، مدل را گیج می‌کند.

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

لایه‌ی فرمت خروجی و جداکننده‌ها (Delimiters)#

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

لایه‌ی نمونه (Few-shot)#

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

اما یک هشدار: یک مثال خوب بیشتر از ده توضیح عمل می‌کند — فقط اگر مثال واقعاً همان الگویی باشد که می‌خواهید. اگر الگوی مثال با الگوی موردنظر شما فاصله داشته باشد، مدل همان الگوی غلط را یاد می‌گیرد و شما فکر می‌کنید Few-shot اضافه کرده‌اید، درحالی‌که Few-shot غلط اضافه کرده‌اید.

تکنیک‌هایی که خروجی پرامپت را قابل‌اعتماد می‌کنند#

Few-shot Prompting، Chain-of-Thought (CoT)، Role Prompting و Structured Output هر کدام یک نوع شکست خروجی را هدف می‌گیرند؛ ترکیب کورکورانه‌ی همه‌ی آن‌ها پرامپت را شکننده و غیرقابل‌نگهداری می‌کند. هر تکنیک را فقط زمانی اضافه کنید که مشکل مشخصی دارید.

Few-shot Prompting — الگوی Brown et al. (2020) و کاربرد عملی#

مقاله‌ی Brown et al. (2020) با عنوان «Language Models are Few-Shot Learners» نشان داد مدل‌های بزرگ بدون Fine-tuning و فقط با چند مثال در Context، می‌توانند الگو یاد بگیرند. در عمل، این یعنی اگر خروجی مدل از فرمت دلخواه شما فاصله دارد، به‌جای توضیح بیشتر، یک نمونه‌ی کامل ورودی-خروجی اضافه کنید.

Chain-of-Thought — زنجیره‌ی استدلال#

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

Structured Output و توصیه‌ی Anthropic در مستندات خود درباره‌ی تگ‌های XML#

Anthropic در مستندات خود توصیه می‌کند برای ساختاردهی پرامپت از تگ‌های XML استفاده کنید. این الگو مؤثر است چون مدل‌های Claude با تگ‌های XML آموزش دیده‌اند و مرزهای منطقی را بهتر درک می‌کنند. برای مدل‌های OpenAI، JSON Schema یا Markdown هم مؤثرند.

روش عکس‌نویسی پرامپت (Prompt Reverse Engineering)#

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

پرامپت آماده‌ی نمونه — استخراج ساختار از متن: <role>تو یک تحلیلگر داده با تخصص در استخراج ساختار از متون فارسی هستی.</role> <task>متن زیر را به JSON با فیلدهای مشخص‌شده تبدیل کن.</task> <constraints> - فقط از اطلاعات موجود در متن استفاده کن - فیلدهای خالی را null بگذار، حدس نزن - خروجی فقط JSON باشد، بدون توضیح اضافه </constraints> <output_format> { "title": "string", "entities": [{"name": "string", "type": "string"}], "summary": "string (max 100 words)" } </output_format> <input> {{متن_ورودی}} </input>

چه زمانی مهندسی پرامپت کافی نیست؟#

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

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

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

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

  • پرامپت از 2000 توکن عبور کرده و هنوز خروجی ناپایدار است
  • مدل هر بار ساختار خروجی را کمی عوض می‌کند
  • نیاز به دانش سازمانی یا داده‌ی اختصاصی دارید که در آموزش مدل نبوده
  • محدودیت‌ها را صدها بار تکرار کرده‌اید و مدل باز هم نقض می‌کند

هزینه‌ی واقعی هر روش#

مهندسی پرامپت هزینه‌ی زیرساختی ندارد ولی هزینه‌ی زمانی تست و نگهداری دارد. Fine-tuning به داده‌ی آموزشی باکیفیت و دسترسی به GPU نیاز دارد. RAG به یک پایگاه دانش، سیستم Embedding و لایه‌ی جستجو نیازمند است. انتخاب روش، بستگی به مسئله دارد نه به ترند. تیم‌هایی که بدون مسئله‌ی مشخص سراغ RAG می‌روند، زیرساختی می‌سازند که بعداً با آن نمی‌دانند چه کنند.

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

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

الگوی «کلمات جادویی» و چرا شکست می‌خورد#

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

ترکیب همه‌ی تکنیک‌ها بدون هدف#

پرامپت 2000 کلمه‌ای که هم Few-shot دارد، هم CoT، هم Role، هم Structured Output و هم Delimiters، معمولاً شکننده‌تر از پرامپت 300 کلمه‌ای است که فقط مشکل اصلی را هدف گرفته. هر تکنیک اضافه، یک متغیر کنترل‌ناپذیر جدید است.

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

پرامپتی که برای GPT-4 بهینه شده، در Claude رفتار متفاوتی نشان می‌دهد. مدل‌ها متفاوت آموزش دیده‌اند، تفسیر جداکننده‌ها فرق دارد و حساسیت به طول Context متفاوت است. کپی بدون تست روی مدل هدف، یعنی قمار.

عدم سازگاری بین مدل‌ها#

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

پرامپت آماده‌ی نمونه — تولید محتوای ساختاریافته: <role>تو یک نویسنده‌ی فنی هستی که برای توسعه‌دهندگان فارسی‌زبان محتوا تولید می‌کنی.</role> <task>بر اساس موضوع زیر، یک بخش آموزشی با ساختار مشخص بنویس.</task> <structure> 1. پاراگراف پاسخ کوتاه (40-60 کلمه) 2. توضیح با مثال کد 3. نکته‌ی عملی 4. اشتباه رایج </structure> <constraints> - از کلیشه‌های متنی مثل «در دنیای امروز» استفاده نکن - هر ادعا یا باید عددی داشته باشد یا کیفی باشد - کد نمونه باید قابل‌اجرا باشد </constraints> <topic>{{موضوع}}</topic>

چطور پرامپت را تست، نسخه‌بندی و مدیریت کنیم؟#

معیار آماده‌بودن پرامپت (Prompt Readiness): اگر در سه سناریوی ورودی کامل، ناقص و مخرب خروجی قابل‌قبول می‌دهد، آماده است؛ وگرنه هنوز در فاز توسعه. ورودی ناقص و مخرب همان‌جایی‌اند که پرامپت‌های ضعیف لو می‌روند — نه ورودی کامل.

فرآیند تکراری طراحی — از نسخه‌ی اول تا پرامپت پایدار#

  1. نسخه‌ی اول: فقط وظیفه و فرمت خروجی را بنویسید
  2. تست با ورودی واقعی: خروجی را با معیار پذیرش مقایسه کنید
  3. نسخه‌ی دوم: محدودیت‌هایی که مدل نقض کرده را صریح اضافه کنید
  4. تست با ورودی مخرب: داده‌ی ناقص یا غیرمنتظره بدهید
  5. نسخه‌ی سوم: اگر Few-shot لازم است، فقط همان یک مثال را اضافه کنید
  6. ثبت نهایی: نسخه‌ی پرامپت، مدل هدف و تاریخ تست را مستند کنید

معیارهای سنجش — چطور بفهمیم پرامپت بهتر شده یا بدتر#

معیار سنجش باید قابل‌اندازه‌گیری باشد: «آیا خروجی JSON معتبر است؟» قابل‌سنجش است. «آیا خروجی خوب است؟» نیست. هر تغییر در پرامپت را با همان معیار سنجش بسنجید، نه با حس شخصی.

ابزارهای مدیریت پرامپت و نسخه‌بندی پرامپت (Prompt Versioning)#

پرامپت‌ها مثل کد نیاز به سیستم کنترل نسخه دارند. اگر پرامپت‌تان در یک فایل متنی بدون تاریخ و بدون مدل هدف ذخیره شده، با اولین تغییر مدل، نمی‌دانید چه چیزی عوض شده و چرا. ابزارهایی مثل PromptLayer، LangSmith یا حتی Git برای این کار استفاده می‌شوند.

در پروژه‌های واقعی، الگوی قابل‌مشاهده این است: تیم‌هایی که پرامپت‌هایشان در Git نسخه‌بندی می‌شود، هنگام تغییر مدل سریع‌تر مشکل را پیدا می‌کنند چون می‌توانند Diff بگیرند و ببینند کدام لایه پرامپت با کدام نسخه‌ی مدل سازگار نبوده.

جمع‌بندی عملی#

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

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