مهندسی پرامپت (Prompt Engineering) دیگر «نوشتن جملهی جادویی برای AI» نیست. این حوزه به مهندسی نرم‌افزار شبیه‌تر شده: پرامپت را مثل کد نسخهبندی می‌کنید، تست رگرسیون می‌زنید، و برای مکالمات چندتوره قوانین ضد-رانش (Drift-resistance) طراحی می‌کنید. مستر پرامپت، خروجی این تفکر مهندسی است — سندی قابل‌اجرا که در تور پنجم هم از چارچوب خارج نمی‌شود.
مهندسی پرامپت چیست و چه مهارتی واقعاً نیاز دارد؟#
مهندسی پرامپت فرآیند طراحی، آزمون و بهینه‌سازی ورودی‌های متنی برای مدلهای زبانی بزرگ (LLM) است تا خروجی قابلاعتماد و تکرارپذیر تولید شود. این تعریف، «خوش‌نویسی» را حذف میکند و «مهندسی» را جایگزین میکند.
تعریف فنی و جایگاه در چرخه‌ی توسعه‌ی کاربردهای AI#
در چرخه‌ی توسعه‌ی یک کاربردی مبتنی بر مدل زبانی، پرامپت‌نویسی مرحله‌ای است که بین انتخاب مدل و اتصال به رابط کاربری قرار دارد. خروجی این مرحله، مستر پرامپتی است که رفتار سیستم را در تمام جلسات تعریف میکند. Wei et al. در مقاله‌ی «Chain-of-Thought Prompting Elicits Reasoning in Large Language Models» (NeurIPS 2022) نشان دادند که صرف افزودن ساختار استدلال مرحله‌به‌مرحله به پرامپت، دقت پاسخ‌های ریاضی مدلهای بزرگ را به‌طور چشمگیری افزایش میدهد. این یافته نقطه‌ی عطفی بود: پرامپت فقط «دستور» نیست، بلکه معماری تفکر مدل است.
مهارت‌های مورد نیاز: تفکر ساختاری، آزمون و خطای هدفمند، درک محدودیتهای مدل#
سه مهارت هسته‌ای در مهندسی پرامپت وجود دارد:
- تفکر ساختاری: توانایی شکستن یک درخواست پیچیده به اجزای مستقل و قابل‌آزمون.
- آزمون و خطای هدفمند: تغییر یک متغیر در هر آزمایش و ثبت نتیجه — نه تغییر تصادفی کلمات.
- درک محدودیتهای مدل: دانستن اینکه مدلها در مکالمات طولانی فراموش می‌کنند، در ابهام حدس می‌زنند، و بدون مثال، سبک را نمی‌گیرند.
چرا پرامپت‌نویسی «مهارت ثابت» نیست و با هر مدل رفتار متفاوتی دارد#
پرامپتی که روی GPT-4o عالی کار میکند، ممکن است روی Claude 3.5 Sonnet یا Llama 3 خروجی متفاوتی بدهد. تفاوت در آموزش، معماری و تنظیمات سیستمی هر مدل باعث میشود پرامپت‌نویسی مهارتی تطبیقی باشد. هر بار که مدل جدیدی منتشر میشود، پرامپتهای موجود باید بازتست شوند.
مستر پرامپت: سند قابل‌اجرا، نه پرامپت خوب‌نوشته#
مستر پرامپت یک پرامپت ساختارمند و قابل‌استفاده‌ی مجدد است که مثل کد، نسخهبندی میشود، در مکالمات طولانی دوام دارد و در برابر خروج مدل از چارچوب مقاومت میکند. تفاوتش با پرامپت یک‌بارمصرف، در مهندسی‌پذیری آن است.
تفاوت مستر پرامپت با پرامپت یک‌بارمصرف (Disposable Prompt)#
پرامپت یک‌بارمصرف برای یک درخواست خاص نوشته میشود، بعد از یک جلسه دور ریخته میشود، و نیازی به تست مجدد ندارد. مستر پرامپت برای ده‌ها یا صدها جلسه‌ی مشابه استفاده میشود، باید در برابر تنوع ورودی‌های کاربر مقاومت کند، و هر تغییرش باید مستند و قابل‌بازگشت باشد.
ضد-رانش (Drift-resistance): چرا با هر تور احتمال خروج مدل از چارچوب باید کاهش یابد#
در مکالمه‌ی چندتوره، مدل به‌تدریج از دستورالعمل‌های اولیه فاصله میگیرد. این پدیده را «رانش» (Drift) می‌نامند. مستر پرامپت مؤثر باید در تورهای بعدی هم رفتار را کنترل کند. راه‌حل: تکرار قوانین کلیدی در فواصل منظم، محدودکردن دامنه‌ی پاسخ، و تعریف صریح «ممنوعیت‌ها».
قوانین بازگشت (Fallback Rules): وقتی مدل منحرف شد، کاربر چه بنویسد#
قوانین بازگشت، دستوراتی هستند که در خود مستر پرامپت تعریف می‌شوند و به مدل می‌گویند: «اگر از چارچوب خارج شدی، به این حالت برگرد.» مثال: «اگر پاسخ تو بیش از ۳ پاراگراف شد، فقط خلاصه‌ی یک‌خطی بده.» این قوانین، هزینه‌ی دستیِ اصلاح را برای کاربر صفر میکند.
مقایسه‌ی تک‌توره و چندتوره: چرا مکالمه‌ی طولانی چالش کاملاً متفاوتی است#
در مکالمه‌ی تک‌توره، مدل فقط پرامپت را می‌بیند. در مکالمه‌ی چندتوره، مدل تاریخچه‌ی گفتگو را هم پردازش میکند و هر تور جدید، وزن پرامپت اولیه را رقیق میکند. الگوی مشاهده‌شده در پروژههای واقعی: تیم‌هایی که مستر پرامپت‌هایشان را با هر نسخه‌ی جدید مدل تست رگرسیون می‌کنند، نرخ شکست خروجی را به‌طور محسوسی کاهش می‌دهند. تیم‌هایی که این کار را نمی‌کنند، چند هفته بعد متوجه می‌شوند که پرامپت‌ها بی‌صدا خراب شده‌اند.
ساختار ۷-بخشی مستر پرامپت + ۲ نمونه آماده#
هر مستر پرامپت مؤثر ۷ جزء دارد: نقش، هدف، مخاطب، محدودیت‌ها و خط‌قرمزها، فرمت خروجی، مثال‌های مثبت و منفی، و دستورالعمل‌های رفع ابهام. حذف هر جزء، یک نقطه‌ی شکست ایجاد میکند.
توضیح هر ۷ جزء با مثال کوتاه#
- نقش (Role): مدل کیست؟ «تو یک بازبین کد با ۱۰ سال تجربه در Python هستی.»
- هدف (Goal): چه خروجی‌ای می‌خواهیم؟ «باگ‌های امنیتی و مشکلات عملکردی را شناسایی کن.»
- مخاطب (Audience): خروجی برای چه کسی است؟ «برای توسعه‌دهنده‌ی جونیور؛ هر خطا با توضیح ساده و راه‌حل عملی همراه باشد.»
- محدودیت‌ها و خط‌قرمزها (Constraints): چه‌کارهایی ممنوع است؟ «هیچ پیشنهادی بده که نیاز به نصب پکیج جدید داشته باشد.»
- فرمت خروجی (Output Format): ساختار پاسخ چگونه باشد؟ «جدول با ستون‌های: فایل، خط، نوع مشکل، توضیح، راه‌حل.»
- مثال‌های مثبت و منفی (Examples): یک نمونه‌ی مطلوب و یک نمونه‌ی نامطلوب بیاور.
- قوانین رفع ابهام (Ambiguity Resolution): اگر ورودی ناقص بود، مدل چه کند؟ «اگر فایل کامل ارسال نشد، فقط از بخش‌های موجود نظر بده و بخش‌های ناقص را مشخص کن.»
نمونه‌ی ۱: مستر پرامپت تولید محتوای فارسی#
نقش: تو یک نویسنده‌ی محتوای فنی فارسی هستی که مخاطبش توسعه‌دهنده‌های ایرانی با ۲ تا ۵ سال تجربه‌اند.
هدف: از روی سرفصل‌هایی که کاربر می‌فرستد، متن آموزشی بنویس.
مخاطب: توسعه‌دهنده‌ی ایرانی؛ سطح متوسط به بالا؛ زبان محاوره‌ی فنی.
محدودیت‌ها:
- از کلمات انگلیسی فقط برای اصطلاحات فنی استفاده کن و بار اول معادل فارسی بگذار.
- جمله‌ها حداکثر ۲۰ کلمه باشند.
- بدون مقدمه‌چینی شروع کن؛ مستقیم به اصل مطلب بپرداز.
- «در دنیای امروز»، «شایان ذکر است»، «بدون شک» ممنوع.
فرمت خروجی:
- پاراگراف اول: پاسخ مستقیم سرفصل (۴۰ تا ۶۰ کلمه)
- پاراگراف‌های بعدی: بسط با مثال
- هر ۵۰۰ کلمه: یک لیست یا جدول
مثال مثبت:
«Context Window مقدار متنی است که مدل در یک درخواست پردازش میکند. اگر پرامپت و تاریخچه‌ی مکالمه از این سقف عبور کند، مدل قدیمی‌ترین بخش‌ها را حذف میکند.»
مثال منفی:
«در دنیای امروز، Context Window یکی از مفاهیم شایان ذکر است که بدون شک اهمیت زیادی دارد...»
قوانین رفع ابهام:
- اگر سرفصل مبهم بود، یک سؤال بازگشتی بپرس.
- اگر کاربر فقط یک کلمه فرستاد، فرض کن موضوع آن کلمه است و از همان شروع کن.
نمونه‌ی ۲: مستر پرامپت بازبینی کد#
نقش: تو یک Senior Code Reviewer هستی که در پروژههای production با Python و TypeScript کار کرده.
هدف: کدی که کاربر می‌فرستد را از سه منظر بازبینی کن: باگ، امنیت، عملکرد.
مخاطب: توسعه‌دهنده‌ای که می‌خواهد کدش قبل از merge قابل‌استفاده باشد.
محدودیت‌ها:
- فقط مشکلات واقعی را بگو؛ سبک‌نویسی (style) را نادیده بگیر مگر اینکه با خوانایی جدی در تضاد باشد.
- هر مشکل با یک راه‌حل عملی همراه باشد، نه فقط توصیف.
- اگر کد مشکل خاصی ندارد، صریحاً بگو «مشکلی پیدا نشد» و ادامه بده.
- پیشنهاد بازسازی (refactor) نده مگر کاربر درخواست کند.
فرمت خروجی:
جدول با ستون‌های: فایل/تابع، خط، نوع (باگ/امنیت/عملکرد)، شرح مشکل، راه‌حل پیشنهادی.
بعد از جدول: یک پاراگراف خلاصه‌ی وضعیت کلی.
مثال مثبت:
| auth.py | ۴۲ | امنیت | استفاده از == به‌جای hmac.compare_digest برای مقایسه‌ی توکن | از hmac.compare_digest استفاده کن |
مثال منفی:
«کد شما به‌طور کلی خوب است اما می‌توانست بهتر باشد و شاید در آینده...»
قوانین رفع ابهام:
- اگر فایل کامل نیست، فقط از بخش‌های موجود نظر بده و بگو «بخش‌های حذف‌شده بررسی نشد».
- اگر زبان کد مشخص نیست، فرض کن Python است و بگو.
اشتباه رایج: پرامپت بیش‌ازحد مفصل — relevance بر length اولویت دارد#
پرامپت ۲۰۰۰ کلمه‌ای لزوماً بهتر از پرامپت ۵۰۰ کلمه‌ای نیست. هر جملهی اضافی، یک نقطه‌ی ابهام جدید برای مدل می‌سازد. اصل: هر جزء را بنویس، بعد حذف کن اگر بدونش هم خروجی درست است. relevance بر length اولویت دارد.
چه‌کارهایی نباید کرد: اجبار به Persona برای کارهایی مثل ترجمه یا استخراج داده#
برای ترجمه‌ی فنی یا استخراج داده از متن، تعریف Persona («تو یک مترجم ۲۰ ساله هستی») اضافه‌کاری است. مدل نیازی به هویت فرضی ندارد؛ فقط دستور شفاف می‌خواهد. Persona را برای کارهای خلاقانه و سبک‌محور استفاده کنید، نه برای کارهای مکانیکی.
مهندسی پرامپت در برابر Context Engineering و Fine-tuning#
مهندسی پرامپت برای هدایت رفتار مدل با ورودی متنی است؛ Context Engineering برای مدیریت اطلاعاتی که به مدل تزریق میشود؛ Fine-tuning برای تغییر وزن‌های مدل. هر سه ابزارهای مکمل‌اند، نه جایگزین.
جدول مقایسه‌ای: زمان‌بندی، هزینه، مقیاس‌پذیری و کاربرد هر سه#
| معیار | مهندسی پرامپت | Context Engineering | Fine-tuning |
|---|---|---|---|
| زمان پیاده‌سازی | ساعت تا روز | روز تا هفته | هفته تا ماه |
| هزینه | تقریباً صفر | متوسط (زیرساخت retrieval) | بالا (GPU + داده) |
| مقیاس‌پذیری | بالا (هر تغییر = یک ویرایش متن) | متوسط (نیاز به به‌روزرسانی پایگاه دانش) | پایین (هر تغییر = آموزش مجدد) |
| بهترین کاربرد | کنترل رفتار و فرمت | تزریق دانش دامنه‌ای | تغییر سبک و لحن پایه |
| قابل‌بازگشت بودن | بله (نسخهبندی متن) | بله (مدیریت index) | خیر (وزن‌ها تغییر می‌کنند) |
چه‌زمانی پرامپت‌نویسی کافی نیست#
سه نشانه‌ی اصلی:
- کمبود دانش دامنه‌ای: مدل درباره‌ی محصولات شما چیزی نمی‌داند → RAG (Retrieval-Augmented Generation) یا Context Engineering.
- سبک خاص: خروجی مدل «لحن برند» شما را ندارد → Few-shot با ۵ تا ۱۰ مثال، یا Fine-tuning اگر حجم کار بالاست.
- رفتار سیستمی: باید در تمام درخواست‌ها یک قانون ثابت حاکم باشد → System Prompt در API.
نقش RAG در کنار پرامپت‌نویسی#
RAG و پرامپت‌نویسی مکمل‌اند، نه رقیب. RAG اطلاعات را تأمین میکند؛ پرامپت تعیین میکند مدل با آن اطلاعات چه کند. بدون پرامپت خوب، RAG فقط متنی خام در context می‌ریزد. بدون RAG، پرامپت خوب نمی‌تواند دانشی را که مدل ندارد جایگزین کند.
پنجره‌ی زمینه (Context Window) و تأثیرش بر طراحی مستر پرامپت#
هر مدل سقفی برای مقدار متنی که در یک درخواست پردازش میکند دارد. مستر پرامپت هرچه بلندتر باشد، سهم کمتری از context برای تاریخچه‌ی مکالمه و ورودی کاربر باقی می‌ماند. در مدلهایی با context window محدود، مستر پرامپت باید فشرده‌تر باشد و قوانین بازگشت به‌جای تکرار، به ارجاع کوتاه تبدیل شوند.
اشتباهاتی که پرامپت شما را بی‌اثر میکند#
رایج‌ترین اشتباهات: بازنویسی‌ناپذیر بودن پرامپت، فرض یکنواختی رفتار بین مدلها، لیست‌کردن تکنیک‌ها بدون تطبیق با نوع task، و نادیده‌گرفتن drift در مکالمه.
اشتباه ۱: «هرچه پرامپت طولانی‌تر، خروجی بهتر»#
مدل روی جزئیات کم‌اهمیت هم تمرکز میکند. پرامپت ۲۰۰۰ کلمه‌ای با ۱۵ قانون جزئی، احتمالاً بدتر از پرامپت ۵۰۰ کلمه‌ای با ۵ قانون محوری عمل میکند. مدلها در اولویت‌بندی قوانین متناقض یا بیش‌ازحد، ضعیف‌اند.
اشتباه ۲: فرض اینکه پرامپت مؤثر روی یک مدل روی همه جواب میدهد#
پرامپتی که روی GPT-4o با «Let's think step by step» عالی کار میکند، ممکن است روی Claude 3.5 Sonnet بی‌اثر باشد چون Claude ذاتاً استدلال مرحله‌ای را انجام میدهد. پرامپت‌نویسی مدل‌محور است، نه task-محور.
اشتباه ۳: ارائه‌ی لیست ۵۰ تکنیک بدون تطبیق با نوع task#
Chain-of-Thought برای ترجمه بی‌فایده است. Few-shot برای محاسبه‌ی ریاضی ساده نویز است. Persona برای استخراج داده اضافه‌کاری است. تکنیک باید با نوع task تطبیق داده شود، نه اینکه همه را روی هر درخواست بچسبانید.
اشتباه ۴: نادیده‌گرفتن تفاوت تک‌توره و چندتوره#
پرامپتی که در یک درخواست عالی عمل میکند، ممکن است در تور چهارم مکالمه بی‌اثر شود. اگر محصول شما چتبات است، پرامپت باید برای چندتوره طراحی شود — با قوانین بازگشت و محدودیتهای صریح.
اشتباه ۵: کپی‌پیست پرامپت انگلیسی به فارسی بدون بازطراحی ساختاری#
ساختار نحوی فارسی (SOV) با انگلیسی (SVO) متفاوت است. مدلها روی پرامپت انگلیسی آموزش دیده‌اند و ترجمه‌ی تحت‌اللفظی، ابهام‌های ساختاری ایجاد میکند. پرامپت فارسی باید از اول با ساختار فارسی نوشته شود، نه ترجمه‌ی پرامپت انگلیسی.
پرامپت‌نویسی فارسی: چرا ترجمه‌ی مستقیم شکست می‌خورد؟#
ساختار نحوی و انتظارات مدل از پرامپت فارسی متفاوت است؛ ترجمه‌ی مستقیم پرامپت انگلیسی بدون بازطراحی، کیفیت خروجی را افت میدهد. برای مدلهایی با آموزش فارسی قوی، پرامپت فارسی طبیعیتر نتیجه میدهد.
تفاوت‌های ساختاری پرامپت فارسی و انگلیسی#
سه تفاوت اصلی:
- ترتیب اجزا: در انگلیسی فعل بعد از فاعل می‌آید؛ در فارسی فعل معمولاً آخر جمله است. مدل ممکن است «دستور» را در ابتدای جملهی فارسی نبیند.
- حروف اضافه و پسوندی: فارسی با پسوند و چسبان کار میکند؛ انگلیسی با حروف اضافه. ترجمه‌ی تحت‌اللفظی این ساختار را می‌شکند.
- ابهام در اشاره: «آن»، «این»، «خودش» در فارسی مبهم‌تر از انگلیسی است. مدل گاهی نمی‌فهمد به چه چیزی اشاره می‌کنید.
چه‌زمانی پرامپت فارسی بهتر جواب میدهد و چه‌زمانی انگلیسی#
اگر خروجی فارسی می‌خواهید و مدل آموزش فارسی قوی دارد، پرامپت فارسی طبیعیتر است. اگر مدل آموزش فارسی ضعیف دارد یا task شما فنی-بین‌المللی است (کدنویسی، ریاضی)، پرامپت انگلیسی با خروجی فارسی بهتر عمل میکند. تست کنید؛ قاعده‌ی مطلق وجود ندارد.
بازطراحی به‌جای ترجمه: مثال قبل و بعد#
قبل (ترجمه‌ی تحت‌اللفظی): «اگر تو یک نویسنده‌ی فنی هستی، لطفاً یک مقاله درباره‌ی Context Window بنویس که برای مخاطب جونیور باشد.»
بعد (بازطراحی فارسی): «نقش: نویسنده‌ی فنی فارسی. مخاطب: جونیور. موضوع: Context Window. شروع کن با تعریف یک‌خطی. بدون مقدمه.»
در نسخه‌ی بازطراحی‌شده، هر جزء مستقل و بدون وابستگی نحوی است. مدل راحت‌تر اولویت‌ها را می‌فهمد.
نکات پرامپت‌نویسی برای مدلهای فارسی‌زبان#
مدلهایی مثل Ziya یا ParsBERT برای زبان فارسی بهینه‌شده‌اند. برای این مدلها، پرامپت فارسی با ساختار ساده و جملات کوتاه بهتر از پرامپت انگلیسی عمل میکند. نیازمند راستی‌آزمایی: ادعای افت درصدی مشخصی در کیفیت ترجمه‌ی مستقیم — تا منبع معتبری پیدا نشود، به‌صورت کیفی بیان میشود: «افت محسوس در کیفیت خروجی». هر مدل فارسی‌زبان را قبل از استفاده در production با پرامپت فارسی و انگلیسی تست کنید.
کتابخانه‌ی پرامپت و نسخهبندی: مدیریت حرفه‌ای در تیم#
پرامپت‌ها را مثل کد در Git نگه دارید، با هر تغییر مدل تست رگرسیون اجرا کنید، و یک Prompt Library مشترک برای تیم بسازید تا نرخ شکست خروجی کاهش یابد. پرامپت در چت شخصی، پرامپت گمشده است.
ساختار Prompt Library: دسته‌بندی، متادیتا و جستجو#
هر پرامپت در کتابخانه باید این متادیتاها را داشته باشد:
- نام و شناسه‌ی یکتا
- نسخه (v1.0، v1.1، ...)
- مدل هدف و تاریخ آخرین تست
- نوع task (تولید محتوا، بازبینی کد، ترجمه، ...)
- مخاطب (تک‌نفره، تیم، محصول)
- وضعیت (فعال، منسوخ، در حال تست)
نسخهبندی (Versioning): نام‌گذاری، changelog و rollback#
هر تغییر در مستر پرامپت یک نسخه‌ی جدید است. نام‌گذاری: v{major}.{minor} — تغییرات ساختاری major، تغییرات جزئی minor. changelog کوتاه بنویسید: «v2.1: افزودن قانون بازگشت برای مکالمات بیش از ۵ تور». rollback باید یک‌مرحله‌ای باشد؛ اگر نسخه‌ی قبل در Git است، برگرداندن ساده است.
تست رگرسیون پرامپت: چه‌کارهایی باید بعد از هر تغییر مدل انجام شود#
- مجموعه‌ای از ۱۰ تا ۲۰ ورودی تست (test cases) برای هر مستر پرامپت آماده داشته باشید.
- بعد از هر تغییر نسخه‌ی مدل، تمام test cases را اجرا کنید.
- خروجی‌ها را با baseline مقایسه کنید — تغییرات غیرمنتظره = هشدار.
- نتیجه را در changelog ثبت کنید.
- اگر خروجی افت کرد، پرامپت را بازطراحی کنید یا به نسخه‌ی قبل rollback کنید.
ابزارهای مدیریت پرامپت: از Git تا پلتفرم‌های تخصصی#
الگوی مشاهده‌شده در پروژههای واقعی: تیم‌هایی که پرامپت را در چت شخصی نگه می‌دارند، بعد از رفتن یک نفر پرامپت‌هایش را از دست می‌دهند. تیم‌هایی که در Git نگه می‌دارند، حتی بعد از تغییر اعضا، تاریخچه و نسخهبندی را حفظ می‌کنند. ابزارهای تخصصی مثل PromptLayer یا LangSmith برای تست و مانیتورینگ اضافه می‌شوند، اما Git برای شروع کافی است.
مستر پرامپت، یک سند قابل‌اجراست. اگر آن را مثل کد مدیریت نکنید — نسخهبندی، تست، قوانین بازگشت — در تور پنجم مکالمه بی‌اثر میشود و شما متوجه نمی‌شوید. از ساختار ۷-بخشی شروع کنید، دو نمونه‌ی این مقاله را کپی و شخصی‌سازی کنید، و اولین مستر پرامپت‌تان را در Git commit کنید.
اگر می‌خواهید این مهارت را در قالب پروژههای واقعی تمرین کنید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً همین مسیر را طی میکند: از نوشتن اولین مستر پرامپت تا مدیریت کتابخانه‌ی پرامپت در تیم.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.