پرامپت شما بعد از هر آپدیت مدل بی‌اثر میشود، چون مدلهای زبانی بزرگ (LLM) در تفسیر دستورالعمل‌ها رفتار متفاوتی دارند. تکنیک‌هایی مثل تکرار دستورات یا پرامپتهای بسیار بلند که روی مدلهای نسل قبل مؤثر بودند، روی نسل جدید ممکن است اثر معکوس بگذارند. مشکل اصلی نه نوشتن پرامپت، بلکه مدیریت چرخهی عمر آن است: نسخه‌بندی، بازآزمون پس از هر تغییر مدل، و شکستن محدودیتها به لایه‌های مجزا.
مهندسی پرامپت چیست و چه فرقی با پرامپتنویسی ساده دارد#
مهندسی پرامپت (Prompt Engineering) فرآیند طراحی، تست و بهینه‌سازی ساختارمند دستورات ورودی مدل زبانی بزرگ است. پرامپتنویسی ساده یعنی نوشتن یک سؤال و امید به خروجی خوب؛ اما مهندسی پرامپت یعنی ساختن سیستمی که خروجی قابل‌تکرار و اندازه‌گیری‌شده تولید کند. تفاوت در تفکر سیستمی است، نه در طول پرامپت.
تعریف عملی: پرامپت تصادفی در مقابل پرامپت مهندسی‌شده#
فرض کنید می‌خواهید از مدل بخواهید یک ایمیل بازاریابی بنویسد. پرامپت تصادفی این است: «یک ایمیل فروش برای محصولم بنویس.» پرامپت مهندسی‌شده نقش، مخاطب، لحن، ساختار پاراگراف، CTA و محدودیت‌های طول را مشخص می‌کند و یک خروجی قابل‌پیش‌بینی تولید می‌کند.
در پروژه‌های واقعی، الگوی تکرارشونده‌ای دیده میشود: تیم‌هایی که پرامپت‌هایشان را بدون ساختار مشخص می‌نویسند، بعد از چند هفته با خروجی‌های ناسازگار مواجه می‌شوند و وقتشان صرف حدس زدن میرود. تیم‌هایی که پرامپت را مثل کد مدیریت می‌کنند، سریع‌تر خطا را پیدا و اصلاح می‌کنند.
چرا مهندسی پرامپت بدون تفکر ساختاریافته بی‌فایده است#
مهندسی پرامپت بدون توانایی شکستن مسئله به زیرمسئلهها، تبدیل به حفظکردن فرمولهای جادویی میشود. راهنمای رسمی OpenAI Prompt Engineering Guide و مستندات Anthropic هر دو بر یک اصل مشترک تأکید دارند: پرامپت خوب نتیجه‌ی تفکر ساختاریافته است، نه کپی‌کردن قالب آماده.
اگر یک مسئله را به اجزای مستقل تقسیم نکنید، پرامپت شما هم اجزای مستقل نخواهد داشت. خروجی ناپایدار و غیرقابل‌تکرار، اجتناب‌ناپذیر است.
پیشنیازهای واقعی#
- نوشتن فارسی و انگلیسی روان و دقیق
- توانایی شکستن یک مسئله به زیرمسئلهها (تفکر ساختاریافته)
- آشنایی اولیه با محدودیت‌های مدلهای زبانی مثل پنجرهی بافت (Context Window) و سقف تولید توکن
برنامهنویسی پیش‌نیاز نیست، اما برای استفاده از ابزارهایی مثل LangChain در محیط production مفید است.
مستر پرامپت چیست و چرا باید مثل کد نسخه‌بندی شود؟#
مستر پرامپت (Master Prompt) پرامپت مرجع و کاملی است که تمام دستورالعمل‌ها، نقش، قالب خروجی و محدودیت‌های یک تسک را در یک سند واحد جمع می‌کند. تفاوت اصلی‌اش با قالب ثابت این است که نیازمند نسخه‌بندی، changelog و بازآزمون پس از هر تغییر مدل است. مستر پرامپت یک سند زنده است، نه یک فایل فراموش‌شده.
اجزای ساختاری مستر پرامپت#
هر مستر پرامپت مؤثر حداقل پنج لایه دارد: نقش (Role)، بافت (Context)، دستورالعمل (Instructions)، قالب خروجی (Output Format)، و محدودیتها (Constraints). این لایه‌ها باید از هم جدا و قابل‌ارجاع باشند تا وقتی یک بخش شکست، بدانید کدام لایه مشکل دارد.
الگوی تکرارشونده در پروژه‌های واقعی: تیم‌هایی که مستر پرامپتشان را در یک بلوک متنی یکپارچه نوشته‌اند، بعد از آپدیت مدل نمی‌توانند بگویند کدام بخش از پرامپت دیگر کار نمی‌کند. تیم‌هایی که لایهبندی دارند، سریع‌تر عیب‌یابی می‌کنند.
الگوی نسخه‌بندی: چرا بدون changelog بعد از آپدیت مدل نمی‌فهمید چه چیزی شکسته#
وقتی مدل از نسخه‌ی A به نسخه‌ی B تغییر می‌کند، بدون changelog شما فقط می‌بینید که خروجی «بدتر» شده. با changelog می‌بینید که لایه‌ی «قالب خروجی» دیگر تفسیر نمی‌شود و لایه‌ی «محدودیتها» اثر معکوس گرفته. این تفاوت بین حدس‌زدن و عیب‌یابی است.
پرامپتنویسی واگرا: چرا بیش از 3 تا 4 محدودیت همزمان خروجی را ناپایدار می‌کند#
مدلهای زبانی در پردازش محدودیت‌های همزمان ضعیف‌ترند. اگر در یک پرامپت همزمان بگویید «رسمی بنویس»، «زیر 200 کلمه باشد»، «سه بولت‌پوینت داشته باشد»، و «لحن شوخ داشته باشد»، مدل بین این محدودیتها تضاد می‌بیند و خروجی ناسازگار تولید می‌کند. راه‌حل: محدودیتها را به لایه‌های مجزا بشکنید و در نوبت‌های جداگانه اعمال کنید.
پرامپتنویسی معکوس (Reverse Prompting)#
به‌جای اینکه اول پرامپت بنویسید و خروجی را قضاوت کنید، ابتدا خروجی مطلوب را خودتان بنویسید. سپس پرامپتی بسازید که دقیقاً همان خروجی را تولید کند. این روش، شکاف بین «انتظار شما» و «تفسیر مدل» را مستقیماً نشان میدهد.
نمونه‌ی مستر پرامپت با ساختار نسخه‌بندی:
## Meta
Version: 2.1
Last Updated: پس از آپدیت مدل به نسل جدید
Model: [نام مدل]
Changelog: v2.0 → v2.1: حذف تکرار دستورالعمل (اثر معکوس روی مدل جدید)، ساده‌سازی لایه‌ی قالب خروجی
## Role
تو یک نویسنده‌ی محتوای فارسی با تخصص در حوزه‌ی تکنولوژی هستی. مخاطب: توسعه‌دهنده‌های با 2+ سال تجربه.
## Context
موضوع: [متغیر]
هدف: توضیح یک مفهوم فنی در قالب آموزشی، نه تبلیغاتی.
## Instructions
1. با یک تعریف عملی شروع کن، نه مقدمه‌چینی.
2. حداقل یک مثال واقعی از پروژه بیاور.
3. در پایان یک اشتباه رایج و راه‌حلش را ذکر کن.
## Output Format
پاراگراف‌های 2 تا 4 خطی. بدون بولت‌پوینت در بدنه (فقط در صورت ضرورت).
## Constraints
حداکثر 400 کلمه. لحن: مستقیم و بدون تعارف.
| معیار | قالب ثابت | مستر پرامپت زنده |
|---|---|---|
| به‌روزرسانی پس از آپدیت مدل | دستی و بدون ثبت | نسخه‌بندی‌شده با changelog |
| قابلیت عیب‌یابی | نمی‌دانید کدام بخش شکسته | لایه‌بندی‌شده، عیب‌یابی سریع |
| وابستگی به مدل | بالا — با تغییر مدل بی‌اثر میشود | مدیریت‌شده — بازآزمون در هر تغییر |
| قابلیت ارجاع تیمی | فایل Word یا Notion بدون تاریخ | مخزن کد با history |
تفاوت system prompt و user prompt در عمل#
پرامپت سیستم (System Prompt) قواعد ثابت و هویت مدل را تعریف می‌کند و در تمام نوبت‌های مکالمه تکرار میشود. پرامپت کاربر (User Prompt) درخواست خاص هر نوبت گفتگو است. در عمل، مستر پرامپت معمولاً بهعنوان system prompt بارگذاری میشود و user prompt فقط ورودی متغیر را حمل می‌کند.
چه چیزی باید در system prompt باشد و چه چیزی در user prompt#
system prompt: نقش، لحن، قالب خروجی، محدودیت‌های کلی، و دستورالعمل‌های ثابت. user prompt: محتوای متغیر هر تسک مثل متن ورودی، موضوع خاص، یا پارامترهای یک‌بار‌مصرف.
اشتباه رایج: قرار دادن متغیرهای تسک در system prompt#
وقتی متغیرهای هر تسک (مثل متن ورودی یا موضوع خاص) را در system prompt قرار می‌دهید، دو مشکل ایجاد میشود: اول، مدل در مکالمات بعدی همان متغیرها را تکرار می‌کند. دوم، اگر از API استفاده می‌کنید، هر بار باید system prompt جدیدی بفرستید که هزینه‌ی توکن را بالا می‌برد.
تأثیر ترتیب و فاصله‌ی پرامپت‌ها بر دقت مدل#
مطالعه‌ی Liu et al. (2023) پدیده‌ی Lost in the Middle را توصیف می‌کند: مدلها اطلاعات ابتدایی و انتهایی context را بهتر از اطلاعات میانی به‌یاد می‌آورند. در عمل یعنی اگر محدودیت مهمی را وسط پرامپت بلند بگذارید، احتمال نادیده‌گرفتنش بیشتر است.
| معیار | System Prompt | User Prompt |
|---|---|---|
| هدف | تعریف هویت و قواعد ثابت | درخواست خاص هر نوبت |
| تکرار در مکالمه | در تمام نوبت‌ها فعال | فقط یک نوبت |
| متغیر بودن | ثابت (یا با نسخه‌بندی تغییر می‌کند) | هر نوبت متفاوت |
| وابستگی به مدل | تفسیرش بین مدلها متفاوت است | کمتر وابسته به معماری مدل |
چرا پرامپتی که برای یک مدل خوب کار می‌کند برای مدل دیگر بی‌فایده است؟#
مدلهای زبانی بزرگ در معماری، پنجرهی بافت و روش تفسیر دستورالعمل‌ها متفاوت‌اند. تکنیک‌هایی مثل تکرار دستورات که در مدلهای نسل اول مؤثر بودند، در مدلهای نسل جدید ممکن است اثر معکوس داشته باشند. پرامپتهای بسیار بلند در مدلهای با context کوتاهتر باعث از دست رفتن اطلاعات می‌شوند.
وابستگی زمانی تکنیک‌ها: چرا قالب جادویی یک‌بار‌مصرف وجود ندارد#
هر تکنیک مهندسی پرامپت یک عمر مفید دارد. تکرار دستورات برای مدل‌هایی که آموزششان روی تکرار بود مؤثر بود. مدلهای جدید با آموزش روی تنوع، تکرار را «نویز» تفسیر می‌کنند و وزنش را کم می‌کنند. نتیجه: پرامپتی که سال پیش مؤثر بود، امروز ممکن است خروجی را بدتر کند.
تأثیر طول پرامپت بر کیفیت خروجی: پدیده‌ی Lost in the Middle#
در مدلهای با پنجرهی بافت محدود، پرامپت بلند باعث از دست رفتن اطلاعات میشود. حتی در مدلهای جدید با context بزرگ‌تر، پرامپتهای پرحاشیه و بیش از 3 تا 4 محدودیت همزمان، دقت و سازگاری خروجی را کاهش میدهند. پرامپت بلندتر همیشه بهتر نیست — این توصیه‌ی رایج در مهندسی پرامپت، دقیقاً همان چیزی است که باید رد کرد.
استراتژی portability: نوشتن پرامپت‌هایی که با تغییر مدل حداقل آسیب را می‌بینند#
برای نوشتن پرامپتهای قابل‌انتقال بین مدلها، سه اصل را رعایت کنید: اول، دستورالعمل‌ها را ساده و مستقیم بنویسید بدون تکرار. دوم، قالب خروجی را با مثال مشخص کنید نه با توصیف انتزاعی. سوم، محدودیتها را به لایه‌های مجزا بشکنید تا اگر یک لایه روی مدل جدید شکست، بقیه سالم بمانند.
تکنیک‌های پرامپتنویسی پیشرفته: few-shot، chain-of-thought و نقش‌بازی#
نمونه‌های چندتایی (Few-Shot Prompting) با ارائه‌ی چند ورودی-خروجی نمونه، الگوی مورد نظر را به مدل آموزش میدهد. تفکر زنجیره‌ای (Chain-of-Thought Prompting) مدل را وادار به نمایش گام‌های استدلال می‌کند. نقش‌بازی (Role Prompting) با تعریف هویت، لحن و سطح تخصص، خروجی را جهت‌دهی می‌کند. هر سه تکنیک کاربرد مشخصی دارند و جایگزین هم نیستند.
Few-Shot: چه زمانی مفید است و چه زمانی مدل را گیج می‌کند#
Few-shot وقتی مفید است که الگوی خروجی را نمی‌توانید با کلمات توصیف کنید. مثلاً دسته‌بندی متن به برچسب‌های خاص. اما اگر نمونه‌ها متناقض باشند یا تعدادشان زیاد شود، مدل الگوی ضمنی را اشتباه استنباط می‌کند. دو تا سه نمونه‌ی واضح و متنوع، معمولاً بهتر از ده نمونه‌ی یک‌شکل است.
نمونه‌ی Few-Shot برای تسک دسته‌بندی:
دسته‌بندی تیکت‌های پشتیبانی به سه برچسب: bug، feature_request، billing.
ورودی: «وقتی روی دکمه‌ی ذخیره کلیک می‌کنم، صفحه فریز میشود.»
خروجی: bug
ورودی: «کاش امکان داشبورد سفارشی برای نمودارها وجود داشت.»
خروجی: feature_request
ورودی: «فاکتور اسفند اشتباه صادر شده، مبلغ دو برابر است.»
خروجی: billing
ورودی: «[متن تیکت جدید]»
خروجی:
Chain-of-Thought: ارجاع به مقاله‌ی Wei et al. (2022)#
مقاله‌ی Wei et al. (2022) نشان داد که اضافه‌کردن جملاتی مثل «بیا مرحله‌به‌مرحله فکر کنیم» به پرامپت، دقت مدلها را در مسائل ریاضی و منطقی افزایش میدهد. در عمل، این تکنیک برای تسک‌های تحلیلی مفید است که نیاز به استدلال چندمرحله‌ای دارند، نه برای تولید محتوای ساده.
نمونه‌ی Chain-of-Thought برای مسئله‌ی تحلیلی:
سؤال: «اگر نرخ تبدیل landing page از 2% به 3% برسد و ترافیک ماهانه 5000 بازدید باشد، چند مشتری جدید در ماه اضافه میشود؟»
دستورالعمل: قبل از پاسخ، مراحل محاسبه را گام‌به‌گام بنویس. سپس عدد نهایی را مشخص کن.
Role Prompting: چرا «تو یک متخصص هستی» به‌تنهایی کافی نیست#
تعریف نقش بدون جزئیات، مدل را به سمت کلیشه‌ها می‌برد. «تو یک متخصص بازاریابی هستی» خروجی عمومی تولید می‌کند. «تو یک متخصص بازاریابی B2B با 10 سال تجربه در حوزه‌ی SaaS هستی که مخاطبش مدیران فنی هستند» خروجی دقیق‌تر و قابل‌استفاده‌تری تولید می‌کند. نقش باید محدودیت‌های رفتاری داشته باشد، نه فقط عنوان.
XML tagging در مدلهای Claude#
مدلهای Claude از ساختاردهی با تگ‌های XML پشتیبانی می‌کنند. مثلاً <context>، <instructions> و <output_format> به مدل کمک می‌کند مرزهای بخش‌ها را بهتر تشخیص دهد. این رویکرد مخصوص مدلهای Anthropic است و روی مدلهای دیگر لزوماً اثر ندارد.
چرخهی اصلاح پرامپت و ابزارهای تست خودکار#
چرخهی بهینه‌سازی پرامپت شامل نوشتن، تست با ورودی‌های متنوع، ثبت نتایج، و اصلاح لایه‌به‌لایه است. ابزارهایی مانند Promptfoo و LangChain این فرآیند را خودکارسازی می‌کنند و امکان مقایسه‌ی نسخه‌های مختلف پرامپت روی مجموعه‌ی تست ثابت را فراهم می‌آورند. اصلاح پرامپت یک‌باره نیست؛ یک چرخهی تکرارشونده است.
چرخهی عملی: نوشتن → تست → ثبت → اصلاح#
- یک تسک واقعی انتخاب کنید، نه یک تمرین ساختگی.
- خروجی مطلوب را خودتان بنویسید (پرامپتنویسی معکوس).
- پرامپت نسخه 1 را بنویسید و با 5 ورودی مختلف تست کنید.
- در هر تکرار فقط یک متغیر را تغییر دهید (لحن، طول، قالب، یا محدودیت).
- نتایج را در یک جدول ثبت کنید: ورودی، خروجی، مشکل شناسایی‌شده، اصلاح انجام‌شده.
این چرخه را تا زمانی تکرار کنید که خروجی در 5 ورودی مختلف سازگار باشد. معمولاً 3 تا 5 تکرار کافی است، نه ده‌ها بار.
معرفی ابزارها: Promptfoo و LangChain#
Promptfoo برای تست خودکار پرامپت‌ها روی مجموعه‌ی ورودی ثابت طراحی شده و خروجی‌ها را مقایسه می‌کند. LangChain بیشتر برای مدیریت پرامپت در محیط production مناسب است — یعنی وقتی پرامپت بخشی از یک سیستم بزرگ‌تر با چندین ایجنت و ابزار است.
معیارهای موفقیت پرامپت#
سه معیار اصلی: سازگاری (آیا در ورودی‌های مختلف الگوی ثابتی تولید می‌کند؟)، دقت (آیا خروجی از نظر فنی درست است؟)، و تکرارپذیری (آیا با همان پرامپت و همان ورودی، خروجی مشابهی می‌گیرید؟). اگر پرامپت شما در هر سه معیار نمره‌ی قابل‌قبول دارد، آماده‌ی استفاده است.
آیا پرامپتنویسی شغل مستقل است؟#
مرز بین پرامپتنویسی و طراحی سیستم AI در حال محو شدن است. بهعنوان شغل صرفاً پرامپتنویسی، بازار محدود و ناپایدار است. اما بهعنوان مهارت مکمل در کنار طراحی AI، RAG (Retrieval-Augmented Generation) و ارکستراسیون، ارزشمند و رو به رشد است. پرامپتنویسی تنها یک لایه از طراحی سیستم AI است.
اشتباهات رایج و محدودیت‌های مهندسی پرامپت: چه زمانی پرامپت کافی نیست#
اشتباهات رایج شامل توصیه‌ی «هرچه پرامپت بلندتر بهتر»، ادعای تضمین خروجی، و ارائه‌ی قالب جادویی است. در عمل، وقتی نیاز به دانش تخصصی سازمانی دارید RAG و وقتی نیاز به تغییر رفتار بنیادین مدل دارید fine-tuning جایگزین پرامپتنویسی می‌شوند. پرامپت یک ابزار است، نه راه‌حل همه‌چیز.
سه اشتباه رایج و هزینه‌ی هرکدام در پروژه‌های واقعی#
اول: باور «پرامپت بلندتر بهتر است». هزینه: پرامپتهای 2000 کلمه‌ای که در مدلهای با context محدود باعث از دست رفتن اطلاعات می‌شوند و در مدلهای جدید هم دقت را کم می‌کنند. دوم: ادعای «این پرامپت خروجی را تضمین می‌کند». هزینه: تیم‌هایی که بدون تست روی پرامپت اعتماد می‌کنند و بعد از آپدیت مدل با خروجی‌های ناسازگار مواجه می‌شوند. سوم: ارائه‌ی قالب جادویی بدون توضیح منطقش. هزینه: کاربر قالب را کپی می‌کند، روی تسکش کار نمی‌کند، و نتیجه می‌گیرد مهندسی پرامپت بی‌فایده است.
مرز تصمیم معماری: پرامپت در مقابل RAG در مقابل fine-tuning#
پرامپتنویسی برای تعریف رفتار و قالب خروجی مناسب است. RAG وقتی لازم است که مدل به دانش تخصصی سازمانی نیاز دارد که در آموزشش نبوده. fine-tuning وقتی لازم است که می‌خواهید رفتار بنیادین مدل (لحن، سبک، یا توانایی خاص) را تغییر دهید و با پرامپت قابل‌تحقق نیست.
| معیار | پرامپتنویسی | RAG | Fine-tuning |
|---|---|---|---|
| هزینه‌ی شروع | پایین | متوسط (نیاز به زیرساخت بازیابی) | بالا (نیاز به داده و GPU) |
| انعطاف | بالا — هر لحظه قابل تغییر | متوسط — با تغییر دانشbase | پایین — نیاز به آموزش مجدد |
| نیاز به داده | بدون نیاز | مجموعه‌ی اسناد سازمانی | صدها تا هزاران نمونه‌ی آموزشی |
| سرعت اجرا | فوری | سریع (پس از setup) | آهسته (پس از آموزش) |
چرا «تضمین خروجی» با پرامپت ادعای دروغ است#
مدلهای زبانی احتمالاتی‌اند. حتی با بهترین پرامپت، همان ورودی ممکن است خروجی‌های متفاوتی تولید کند. پرامپتنویسی احتمال خروجی مطلوب را افزایش میدهد، نه تضمین. هر ادعای «تضمینی» در مهندسی پرامپت، یا ناشی از عدم‌آشنایی با ماهیت مدل است یا تبلیغاتی.
ممنوعیت bullet point بهعنوان قانون کلی#
در بسیاری موارد، پاراگراف طبیعی خروجی بهتری تولید می‌کند. دستور «همیشه با بولت‌پوینت پاسخ بده» مدل را به سمت فهرست‌های سطحی و بدون عمق می‌برد. بولت‌پوینت برای مقایسه‌ی گزینه‌ها و خلاصه‌سازی مناسب است، نه برای استدلال و توضیح.
مهندسی پرامپت یک مهارت است که با تمرین روی تسک‌های واقعی رشد می‌کند، نه با حفظکردن قالب‌ها. مستر پرامپت‌تان را نسخه‌بندی کنید، بعد از هر آپدیت مدل بازآزمون کنید، و محدودیتها را به لایه‌های مجزا بشکنید. اگر می‌خواهید این مهارت را در کنار ساخت ایجنت‌های عملی تمرین کنید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی اسکول دقیقاً روی همین ترکیب تمرکز دارد: پرامپتنویسی ساختاریافته بهعنوان بخشی از طراحی سیستم AI.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.