مهندسی پرامپت (Prompt Engineering) در اکثر راهنماهای فارسی‌زبان یک مهارت یک‌باره معرفی می‌شود: پرامپت خوب بنویسید، تمام. این تصویر غلط است. پرامپت شما با هر به‌روزرسانی مدل ممکن است بشکند، رفتار متفاوتی نشان دهد یا خروجی بی‌ثبات تولید کند. مستر پرامپت (Master Prompt) یک موجودیت زنده با نسخهبندی است؛ مثل کد باید تست، ثبت و نگهداری شود. آنچه در ادامه می‌آید، هزینه‌ی واقعی ساخت و نگه‌داشتن پرامپتی است که واقعاً در production کار کند — نه آنچه در پست‌های آموزشی کوتاه ادعا می‌شود.
مهندسی پرامپت چیست و چه فرقی با تنظیم مدل و RAG دارد؟#
مهندسی پرامپت طراحی و بهینه‌سازی دستورالعمل‌های متنی برای هدایت رفتار مدل زبانی است، بدون آنکه وزن‌های آن دست بخورد. برخلاف فاین‌تیونینگ (Fine-tuning) که مدل را با داده‌ی اختصاصی بازآموزی میکند و برخلاف RAG (Retrieval-Augmented Generation) که اسناد خارجی را به بافت مدل تزریق میکند، اینجا فقط ورودی متنی تغییر میکند.
تمایز عملی سه روش: پرامپت، فاین‌تیونینگ و RAG#
مهندسی پرامپت یعنی تغییر ورودی متنی بدون دست‌زدن به مدل. فاین‌تیونینگ یعنی بازآموزی وزن‌ها با داده‌ی اختصاصی. RAG یعنی تزریق اسناد خارجی به بافت (Context) مدل. این سه روش مکمل‌اند نه رقیب؛ یک مستر پرامپت خوب + RAG مناسب + فاین‌تیونینگ در صورت نیاز، ترکیب بهینه‌ی یک سیستم تولیدی است.
یک ادعای رایج در نتایج فارسی گمراه‌کننده است: «مهندسی پرامپت جایگزین برنامهنویسی است». این درست نیست. پیشنیاز اصلی، تفکر ساختاریافته و درک محدودیتهای مدل است. اما برای کار با API، ابزارهای مدیریت پرامپت و خودکارسازی تست، آشنایی مقدماتی با کدنویسی کمککننده است.
مستر پرامپت یک موجودیت زنده است، نه یک متن در Notion#
مستر پرامپت یک پرامپت مرجع با ساختار ثابت، نسخهبندی و تاریخچه‌ی تغییرات است که تیم‌ها بهجای پرامپتهای پراکنده و تکراری از آن استفاده می‌کنند. تفاوتش با یک قالب پرامپت معمولی در چرخه‌ی حیاتش است: زنده است، تغییر میکند، تست می‌شود و گاهی می‌میرد.
چرا پرامپتهای پراکنده شکست می‌خورند#
مشکل پرامپتهای پراکنده سه‌بعدی است: هر بار از صفر شروع می‌شود، خروجی ناپایدار است و تجربه‌ی تیم ثبت نمی‌شود. الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی Claude اسکول این است: تیمی که پرامپت‌هایش را در چت‌های مختلف نگه می‌دارد، هر بار با تغییر یک کلمه خروجی‌اش عوض می‌شود و کسی نمی‌داند چرا. این وضعیت را «مرگ خاموش» پرامپت مینامند.
پرامپت‌نویسی معکوس: از خروجی شروع کنید نه از پرامپت#
الگویی که در پروژه‌های اعضای کامیونیتی Claude اسکول مکرر دیده شده: ابتدا خروجی مطلوب را خودتان بنویسید، سپس پرامپت را از آن مهندسی معکوس کنید. این روش سریع‌تر از نوشتن پرامپت از صفر به نتیجه می‌رسد چون معیار سنجش از ابتدا مشخص است.
نسخهبندی مستر پرامپت مثل نسخهبندی کد#
هر مستر پرامپت باید شامل چهار فیلد باشد:
- شماره‌ی نسخه (مثلاً v2.3)
- تاریخ تغییر و مدل هدف
- نتیجه‌ی تست (موفق یا ناموفق با دلیل)
- تغییرات نسبت به نسخهی قبل
بدون این ساختار، مستر پرامپت یک متن مرده است. با این ساختار، یک موجودیت قابل‌ردیابی و قابل‌نگهداری می‌شود.
ساختار ۵ لایه‌ای یک پرامپت مؤثر#
ساختار ۵ لایه‌ی یک پرامپت مؤثر شامل نقش (Role Prompting)، زمینه (Context)، محدودیت‌ها (Constraints)، فرمت خروجی (Structured Output) و نمونه (Few-shot Prompting) است. حذف هر لایه کیفیت خروجی را بهطور محسوس کاهش میدهد.
نقش‌دهی و تفکر زنجیره‌ای#
نقش‌دهی یعنی تعیین هویت و تخصص مدل. مثال: «تو یک تحلیلگر مالی با 10 سال تجربه در بازار بورس ایران هستی.» تفکر زنجیره‌ای (Chain-of-Thought) یعنی درخواست استدلال مرحله‌به‌مرحله؛ مؤثر در مسائل منطقی و ریاضی، بی‌فایده در وظایف ساده‌ی طبقهبندی.
نمونه‌دهی کم و پدیده‌ی Lost in the Middle#
افزودن 2 تا 5 نمونهی ورودی-خروجی به پرامپت در وظایف طبقهبندی دقت را بهطور محسوس افزایش میدهد. نکته‌ی عملی مهم: در پرامپتهای طولانی، نمونهها را در ابتدا و انتها بگذارید نه وسط. مطالعه‌ی Liu et al. (2023) نشان داد مدلها محتوای میانی بافت را فراموش می‌کنند — پدیده‌ای که به «Lost in the Middle» معروف است.
خروجی ساختاریافته#
درخواست JSON یا XML مشخص، خطای پارسینگ را در مراحل بعدی حذف میکند. این تفاوت اصلی پرامپت‌نویسی حرفه‌ای با آماتور است. راهنماهای Anthropic بهطور کلی بر تمرکز و کوتاهی system prompt تأکید دارند و توصیه می‌کنند جزئیات را در user prompt بیاورید.
پرامپت آماده‌ی نمونه ۱ — مستر پرامپت تحلیل احساسات فارسی:
نقش: تو یک تحلیلگر احساسات متنی فارسی با تخصص در شبکه‌های اجتماعی هستی.
زمینه: کاربر نظرات و توییت‌های فارسی‌زبان درباره‌ی یک محصول را ارسال میکند.
محدودیت‌ها:
- فقط بر اساس متن ارسالی قضاوت کن
- از حدس‌زدن درباره‌ی نیت کاربر خودداری کن
- اگر متن مبهم است، بنویس «مبهم»
فرمت خروجی: JSON با فیلدهای sentiment (positive/negative/neutral/ambiguous)، confidence (0-1)، و reason (یک جمله)
نمونه:
ورودی: «این اپ بعد از آپدیت جدید اصلاً کار نمی‌کنه، حیف پولی که دادم»
خروجی: {"sentiment": "negative", "confidence": 0.95, "reason": "شکایت مستقیم از عملکرد و ابراز پشیمانی از خرید"}
پرامپت آماده‌ی نمونه ۲ — مستر پرامپت تولید JSON ساختاریافته:
نقش: تو یک استخراج‌کننده‌ی اطلاعات ساختاریافته از متون فارسی هستی.
زمینه: متن‌های خبری و گزارش‌های مالی فارسی به تو داده می‌شود.
محدودیت‌ها:
- فقط اطلاعات صریح موجود در متن را استخراج کن
- اگر فیلدی در متن نیست، مقدارش را null بگذار
- اعداد را به‌صورت عددی بنویس نه رشته
فرمت خروجی: JSON با فیلدهای title، date (YYYY-MM-DD)، entities (آرایه‌ی نام‌ها)، summary (حداکثر ۲ جمله)
نمونه:
ورودی: «شرکت فولاد مبارکه اصفهان در گزارش ۱۴۰۳ خود سود خالص ۱۲۰۰ میلیارد ریال اعلام کرد.»
خروجی: {"title": "گزارش مالی فولاد مبارکه", "date": null, "entities": ["فولاد مبارکه اصفهان"], "summary": "فولاد مبارکه سود خالص ۱۲۰۰ میلیارد ریال در سال ۱۴۰۳ اعلام کرد."}
چگونه پرامپت را تست و بهبود دهم؟#
تست پرامپت یعنی اجرای هدفمند روی چند حالت ورودی، مقایسه‌ی خروجی‌ها با معیار مشخص و اصلاح تکراری — نه بازنویسی تصادفی هر روز. بدون معیار سنجش صریح، تست پرامپت بی‌معناست و وقت تیم را می‌خورد.
چرخه‌ی تکرار: بنویس → تست → بسنج → اصلاح#
- پرامپت اولیه با ساختار ۵ لایه‌ای بنویسید
- 3 تا 5 ورودی نمونه اجرا کنید
- خروجی‌ها را با معیار صریح بسنجید (مثلاً صحت طبقهبندی، رعایت فرمت، یا دقت اطلاعات)
- لایه‌ی ضعیف را شناسایی و اصلاح کنید
- نسخهی جدید را ثبت کنید
اشتباهات رایج که خروجی را خراب میکند#
- ابهام در دستور: مدل دقیقاً همان چیزی میدهد که نوشته‌اید، نه آنچه منظورتان بوده
- نبود نمونهی خروجی: مدل فرمت دلخواه شما را حدس می‌زند
- نبود محدودیت فرمت: خروجی JSON یا ساختار ثابت تولید نمی‌شود
- پرامپت بیش‌ازحد طولانی: دستورالعمل‌های متناقض در متن‌های بلند
- کپی پرامپت از مدل دیگر بدون تطبیق: هر مدل تفسیر متفاوتی از همان دستور دارد
پرامپتهای طولانی: هزینه و ریسک#
مطالعه‌ی Liu et al. (2023) نشان داد که هرچه بافت (Context) بلندتر باشد، احتمال نادیده‌گرفتن اطلاعات میانی بیشتر است. این پدیده در پرامپت‌هایی که نمونهها یا دستورالعمل‌هایشان در بخش میانی قرار دارد، محسوس‌تر است. در API، هر توکن ورودی هزینه دارد؛ پرامپت 2000 توکنی برای 1000 درخواست یعنی 2 میلیون توکن ورودی. این هزینه‌ی تکرارشونده است، نه یک‌باره.
پرامپتدِکی: چرا پرامپتی که دیروز کار می‌کرد امروز شکست می‌خورد؟#
پرامپتدِکی (Prompt Decay) یعنی کاهش اعتبار پرامپت پس از به‌روزرسانی نسخهی مدل. پرامپتی که روی GPT-4o تست شده ممکن است روی نسخهی بعدی رفتار متفاوتی نشان دهد. پرامپت یک قرارداد با مدل خاص است نه یک دستور جهانی.
مکانیزم پرامپتدِکی#
مدلهای زبانی با هر آپدیت در تفسیر دستورالعمل‌ها، اولویت‌دهی به بخش‌های مختلف پرامپت و حتی لحن خروجی تغییر می‌کنند. این تغییر لزوماً بد نیست، ولی پرامپت شما را ناامید میکند.
هزینه‌ی پنهان نگهداری#
مهندسی پرامپت بدون در نظر گرفتن پرامپتدِکی یعنی ساختن چیزی که تاریخ انقضا دارد. الگوی مشاهده‌شده در پروژه‌های واقعی: تیم‌هایی که مستر پرامپت‌هایشان را نسخهبندی و تست‌شده نگه می‌دارند، در آپدیت مدل فقط 20 تا 60 دقیقه تست می‌کنند. بقیه از صفر شروع می‌کنند.
استراتژی مقابله#
- ثبت مدل و نسخه در هر مستر پرامپت
- اجرای خودکار تست‌ها پس از هر آپدیت
- داشتن پرامپتهای جایگزین برای مدلهای مختلف
- مستندسازی تغییرات رفتار مدل نسبت به نسخهی قبل
چه زمانی مهندسی پرامپت کافی نیست و باید سراغ فاین‌تیونینگ بروم؟#
وقتی پرامپت‌نویسی با تمام تکنیک‌ها (few-shot، CoT، نقش‌دهی) به دقت مطلوب نمی‌رسد، یا وقتی شکل خروجی ثابت و تکراری است و پرامپت هر بار باید حجم زیادی دستورالعمل حمل کند، فاین‌تیونینگ انتخاب بهینه‌تر است.
معیارهای تصمیم‌گیری#
| موقعیت | راه‌حل مناسب | دلیل |
|---|---|---|
| دقت پرامپت بعد از 10+ تکرار هنوز زیر حد قابل‌قبول | فاین‌تیونینگ | پرامپت به سقف خود رسیده |
| پرامپت بیش از 2000 توکن دستورالعمل دارد و تکرار می‌شود | فاین‌تیونینگ | هزینه‌ی توکن در هر درخواست |
| داده‌ی تخصصی و انحصاری دارید که در بافت مدل نیست | RAG | اطلاعات بیرون از مدل |
| وظیفه ساده و خروجی ساختاریافته است | مهندسی پرامپت | ساده‌ترین راه، کم‌هزینه‌ترین |
اشتباه رایج: فاین‌تیونینگ قبل از بهینه‌سازی پرامپت#
فاین‌تیونینگ روی پرامپت ضعیف یعنی مدل قوی‌تری که رفتار بدتر را یاد گرفته. اول پرامپت را بهینه کنید، بعد تصمیم بگیرید. این ترتیب را بیشتر تیم‌ها برعکس انجام می‌دهند.
ابزارهای مدیریت پرامپت: کدام برای تیم شما مناسب است؟#
PromptLayer برای ردیابی و آنالیتیکس پرامپت در API، LangSmith برای ارکستراسیون و دیباگ زنجیره‌های پیچیده، و OpenAI Playground برای تست سریع تک‌نفره مناسب است. انتخاب ابزار به اندازه‌ی تیم و پیچیدگی workflow بستگی دارد.
جدول مقایسه‌ی ابزارها#
| ابزار | کاربرد اصلی | مناسب برای | ویژگی کلیدی |
|---|---|---|---|
| OpenAI Playground | تست سریع و تعاملی | تک‌نفره | بدون نیاز به setup |
| PromptLayer | ردیابی و آنالیتیکس | تیم 2 تا 5 نفر | لاگ‌گیری خودکار هر درخواست |
| LangSmith | ارکستراسیون و دیباگ | تیم و سازمان | Trace کامل زنجیره‌ی ایجنت |
پرامپت‌نویسی در چت با پرامپت‌نویسی در API چه فرقی دارد؟#
در رابط چت ChatGPT (نسخهی consumer) system prompt قابلتنظیم نیست؛ در API کاملاً قابل‌کنترل است. استفاده از پرامپتهای consumer chat برای کارهای production بدون در نظر گرفتن determinism و cost یک اشتباه رایج است.
انتخاب ابزار بر اساس اندازه‌ی تیم#
- تک‌نفره: Playground + یک فایل Markdown با نسخهبندی دستی
- تیم 2 تا 5 نفر: PromptLayer یا LangSmith
- سازمان با چندین مدل و چندین تیم: LangSmith + CI/CD برای تست خودکار پرامپت
هزینه‌ی واقعی ساخت مستر پرامپت در یک تیم#
ساخت مستر پرامپت قابل‌نگهداری برای یک تیم 5 نفره معمولاً بین 2 تا 4 هفته زمان می‌برد. این عدد از تجربه‌ی میدانی پروژه‌های اعضای کامیونیتی Claude اسکول به‌دست آمده، نه از یک مطالعه‌ی آکادمیک. اکثر مقالات فارسی «چند دقیقه» می‌گویند؛ آن «چند دقیقه» فقط نوشتن اولین نسخه است، نه ساختن چیزی که در production دوام بیاورد.
شکستن هزینه به مراحل#
- تعریف مسئله و خروجی مطلوب: 2 تا 3 روز
- پرامپت‌نویسی معکوس و ساخت اولیه: 3 تا 5 روز
- تست روی 10+ حالت ورودی: 3 تا 5 روز
- ثبت نسخه و مستندسازی: 1 تا 2 روز
- آموزش تیم و انتقال دانش: 2 تا 3 روز
هزینه‌ی پنهان: نگهداری#
هر آپدیت مدل یعنی 20 تا 60 دقیقه تست و احتمالاً اصلاح پرامپت. این هزینه‌ی تکرارشونده است نه یک‌باره. اگر مدل شما ماهی یک‌بار آپدیت می‌شود، سالانه 4 تا 12 ساعت فقط صرف تست پرامپتها می‌کنید.
چه زمانی هزینه‌ی پرامپت‌نویسی توجیه ندارد؟#
اگر فقط 10 درخواست در ماه دارید، پرامپت‌نویسی حرفه‌ای توجیه اقتصادی ندارد. مستقیم از رابط چت استفاده کنید. سرمایه‌گذاری روی مستر پرامپت وقتی منطقی است که حجم درخواست‌ها و حساسیت خروجی بالا باشد.
مهندسی پرامپت یک مهارت یک‌باره نیست؛ یک فرایند نگهداری مداوم است. مستر پرامپت‌تان را مثل کد نسخهبندی کنید، تست کنید و با هر آپدیت مدل بازبینی کنید. اگر می‌خواهید عمیق‌تر با مدلهای زبانی کار کنید و این چرخه‌ی ساخت-تست-نگهداری را در پروژه‌ی واقعی تجربه کنید، دوره‌ی آموزش جامع Claude و ابزارهای مشابه در کامیونیتی Claude اسکول دقیقاً روی همین کار میکند — از صفر تا ایجنت‌های قابل‌استفاده، بدون کدنویسی.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.