مستر پرامپت یک دستور ثابت نیست؛ یک قالب متغیر است که بخشی از آن هر بار پر میشود. مهندسی پرامپت یعنی طراحی این قالب‌ها، نه حفظ کردن کلمات جادویی. و فرسایش پرامپت (Prompt Decay) یعنی پرامپتی که دیروز عالی کار می‌کرد، امروز با نسخهی جدید مدل رفتار متفاوتی نشان میدهد — و این شکاف، نه در تئوری، در عمل روزانه‌ی تیمهای AI ظاهر میشود.
مهندسی پرامپت چیست و چه فرقی با نوشتن دستور ساده دارد؟#
مهندسی پرامپت (Prompt Engineering) طراحی ساختارمند ورودی‌ها برای مدل‌های زبانی بزرگ (LLM) است تا خروجی قابل‌تکرار و دقیق بگیرید. تفاوتش با نوشتن دستور ساده در این است که یک فرآیند تکرارشونده با قالب مشخص دارد، نه یک جمله‌ی یک‌بارمصرف.
وقتی می‌نویسید «متن را خلاصه کن»، مدل حدس می‌زند چه طولی، چه لحنی، چه مخاطبی مدنظرتان است. وقتی ساختار نقش-زمینه-وظیفه-قالب خروجی را می‌نویسید، آن حدس‌ها را حذف میکنید. مهندسی پرامپت یعنی حذف ابهام از ورودی تا خروجی قابل‌پیش‌بینی شود.
این حوزه پس از انتشار ChatGPT در نوامبر 2022 و GPT-4 در مارس 2023 از یک ترفند به مهارت مستقل تبدیل شد. اما منطق پشت ساختار مهم‌تر از خود ساختار است؛ پرامپتنویسی مجموعه‌ای از کلمات جادویی نیست و هر کسی که این را بگوید، هنوز در مرحله‌ی اول گیر کرده.
مستر پرامپت: قالب متغیر، نه پرامپت ثابت#
مستر پرامپت (Master Prompt) یک قالب قابل‌استفاده‌ی مجدد است که بخش‌هایی از آن ثابت‌اند — نقش، محدودیت‌ها، قالب خروجی — و بخش‌هایی هر بار پر می‌شوند: دادهی ورودی، پارامترهای وظیفه. این تفاوت را تقریباً هیچ منبع فارسی‌زبان صریح توضیح نمی‌دهد.
یک مستر پرامپت خلاصهسازی مقاله سه متغیر دارد: {{عنوان}}، {{متن}}، {{مخاطب}}. بقیه‌ی ساختار ثابت می‌ماند. یعنی مقیاس‌پذیری — می‌توانید صدها مقاله را با یک قالب واحد پردازش کنید بدون اینکه هر بار پرامپت را از صفر بنویسید.
مزیت اصلی قالب متغیر نسبت به پرامپت ثابت: کاهش خطای انسانی، امکان تست رگرسیون، و جداشدن منطق از داده. اگر یکبار قالب را درست طراحی کنید، بقیه‌ی کار پرکردن متغیرهاست. در پروژه‌های تیمی، همین یک تصمیم، ساعت‌ها کار تکراری را حذف میکند.
شما یک خلاصه‌ساز محتوای فنی هستید. مخاطب: {{مخاطب}}. وظیفه: مقاله زیر را در 5 بولت‌پوینت خلاصه کنید. هر بولت حداکثر 15 کلمه. عنوان: {{عنوان}} متن: """ {{متن}} """
اجزای ساختاری یک پرامپت مؤثر#
پرامپت مؤثر پنج جزء دارد: نقش (Role)، زمینه (Context)، وظیفه (Task)، قالب خروجی (Output Format) و محدودیت‌ها (Constraints). هرکدام اگر نباشد، مدل مجبور میشود حدس بزند و خروجی غیرقابل‌پیش‌بینی میدهد.
نقش و زمینه — چرا باید بگویید مدل «کیست» و «چه می‌داند»#
نقش ساده («تو یک ویراستار هستی») تقریباً بی‌اثر است. نقش ساختارمند — «تو ویراستار محتوای فنی هستی، مخاطب‌ات توسعه‌دهنده‌اند، لحن فنی و مختصر» — رفتار مدل را واقعاً تغییر میدهد. زمینه هم همین‌طور: اگر مدل نداند مخاطب کیست یا هدف چیست، خروجی‌اش متوسط و بی‌هویت می‌ماند. اشتباهی که در کلاس‌ها مکرر دیده میشود: نوشتن نقش بدون مخاطب‌شناسی.
وظیفه و قالب خروجی — تفاوت «خلاصه کن» و «در 5 بولت‌پوینت، هرکدام حداکثر 15 کلمه، خلاصه کن»#
وظیفه باید یک فعل مشخص با یک قید کمّی داشته باشد. قالب خروجی هم باید صریح باشد: JSON، جدول، بولت‌پوینت، پاراگراف. مدل‌های زبانی در تفسیر قالب‌های مبهم، خروجی‌های متفاوتی می‌دهند. از Delimiter (جداکننده) مانند سه‌گیومه یا XML tags برای تفکیک دستور از داده استفاده کنید — این توصیه‌ی رسمی OpenAI در Prompt Engineering Guide است.
تفاوت System Prompt و User Prompt در عمل#
System Prompt رفتار ثابت مدل را تعریف میکند: نقش، لحن، محدودیتهای کلی. User Prompt درخواست لحظهای کاربر است. مخلوط‌کردن این دو از رایج‌ترین اشتباهات است و باعث میشود مدل در تفسیر اولویتها گیج شود. نه، دقیق‌تر بگویم: گیج نمی‌شود — اولویتها را بهطور تصادفی اولویت‌بندی میکند و شما نمی‌فهمید چرا.
| نوع پرامپت | زمان نوشتن | هزینهی توکنی | قابلیت نگهداشت | مناسب برای |
|---|---|---|---|---|
| پرامپت ساده | ثانیه‌ای | پایین | ندارد | سوالات یک‌بارمصرف |
| مستر پرامپت | اولین بار طولانی، بعد سریع | متوسط | بالا | تکرار وظیفه در مقیاس |
| پرامپت بیش‌ازحد | طولانی | بالا | کم (شکننده) | هیچ‌چیز |
تکنیک‌های پیشرفته: few-shot و chain-of-thought چه زمانی لازم‌اند؟#
Few-Shot Prompting (پرامپتنویسی چندمثالی) و Chain-of-Thought Prompting (پرامپتنویسی زنجیره‌ی فکر) برای وظایف پیچیده‌ی استدلالی یا الگویی کاربرد دارند. برای کارهای ساده لازم نیستند و فقط هزینهی توکنی را بالا می‌برند. این را بسیاری از راهنماها نمی‌گویند.
Few-Shot در مقاله‌ی GPT-3 (Brown et al., 2020) معرفی شد: مدل بدون fine-tuning و فقط با چند مثال در پرامپت، وظایف جدید را یاد می‌گیرد. معمولاً 2 تا 5 مثال کافی است. بیش از این، هزینهی توکنی را بالا میبرد بدون بهبود محسوس. اگر با 3 مثال مدل درست کار نکرد، احتمالاً مشکل در تعریف وظیفه است نه تعداد مثالها.
Chain-of-Thought توسط Wei et al. (2022) معرفی شد: درخواست «قدم‌به‌قدم فکر کردن» دقت پاسخ‌دهی در مسائل ریاضی و منطقی را افزایش میدهد. برای وظایف ساختارمند ساده، این تکنیک فقط توکن اضافه است. الگویی که در پروژه‌های اعضای کامیونیتی تکرار میشود: اضافهکردن CoT به پرامپتی که فقط باید JSON برگرداند.
وظیفه: از متن زیر، نام محصولات و قیمتشان را استخراج کن و در JSON بده. مثال 1: ورودی: «لپ‌تاپ ایسوس مدل X با قیمت 45 میلیون تومان» خروجی: {"products": [{"name": "لپ‌تاپ ایسوس مدل X", "price": "45 میلیون تومان"}]} مثال 2: ورودی: «هدفون سونی WH-1000XM5 — 12 میلیون تومان» خروجی: {"products": [{"name": "هدفون سونی WH-1000XM5", "price": "12 میلیون تومان"}]} ورودی: {{متن}} خروجی:
فرسایش پرامپت: چرا با هر آپدیت مدل پرامپت‌هایتان می‌شکنند#
فرسایش پرامپت (Prompt Decay) یعنی پرامپتهایی که برای یک نسخهی خاص از مدل بهینه شدهاند، با انتشار نسخهی جدید رفتار متفاوت نشان می‌دهند. این یک مشکل عملی و روزمره است که در نتایج فعلی فارسی‌زبان تقریباً وجود ندارد — و همین، آن را خطرناک‌تر میکند.
مثال ملموس: پرامپتی که در GPT-3.5 خروجی جدولی می‌داد، در GPT-4 همان خروجی را به‌صورت پاراگراف میدهد. مدل جدید رفتارهای متفاوتی در تفسیر دستورالعمل‌ها دارد. بازنویسی کامل معمولاً لازم نیست، اما تست رگرسیون ضروری است.
راهحل عملی: یک مجموعه از ورودیهای ثابت بسازید که بعد از هر آپدیت مدل اجرا و مقایسه می‌شوند. اگر خروجی تغییر کرد، delimiter یا قالب خروجی را اصلاح کنید. در محیط تولید (Production)، مهندسی پرامپت نیاز به تست، A/B testing و monitoring دارد — نه فقط نوشتن و فراموش‌کردن. تیم‌هایی که این را جدی نگرفته‌اند، یک‌شبه با خروجی‌های به‌هم‌ریخته در محصول مواجه شدهاند.
رایج‌ترین اشتباهات در مهندسی پرامپت کدام‌اند؟#
رایج‌ترین اشتباهات در مهندسی پرامپت: توصیه‌ی مبهم «دقیق بنویسید» بدون توضیح ساختار، فرض یک‌بارمصرف‌بودن پرامپت، تبدیل مهندسی پرامپت به کلمات جادویی، پرامپتهای چندصد کلمه‌ای برای کارهای ساده، و نادیده‌گرفتن تفاوت System Prompt و User Prompt.
- «دقیق بنویسید» بدون توضیح اینکه دقیقness یعنی چه و چگونه ساختاردهی شود، یک توصیه‌ی بی‌محتواست.
- هیچ پرامپت «بهینه»ای برای همه‌ی مدل‌ها و همه‌ی نسخه‌ها کار نمی‌کند. این باور را فراموش کنید.
- پرامپتهای طولانی در مدل‌های پولی هزینهی پنهان دارند: هر 100 کلمه‌ی اضافی یعنی توکن‌های ورودی بیشتر یعنی قبض بالاتر.
- Prompt Injection یک حملهی امنیتی است، نه یک تکنیک پرامپتنویسی. ضد prompt injection نیاز به فیلترینگ ورودی و sandboxing دارد.
- «پرامپت جادویی» وجود ندارد. هیچ قالب ثابتی برای همه‌ی مدل‌ها بهینه نیست.
چه زمانی مهندسی پرامپت بیش‌ازحد است؟#
مهندسی پرامپت بیش‌ازحد زمانی است که برای سوالات فکتوئلی ساده، ترجمهی یک‌خطی، یا کارهایی که یک جمله‌ی دستور کافی است، ساختاردهی پیچیده میکنید. این فقط زمان و توکن تلفکردن است. مهندسی پرامپت زمانی ارزش دارد که خروجی باید قابل‌تکرار، قابل‌مقیاس و با قالب مشخص باشد.
سه معیار تصمیم:
- تکرار: آیا این وظیفه را بیش از 3 بار تکرار میکنید؟ اگر نه، پرامپت ساده کافی است.
- هزینه: آیا مدل پولی استفاده میکنید؟ هر 100 کلمه‌ی اضافی در پرامپت یعنی توکن‌های ورودی بیشتر.
- قالب: آیا خروجی باید قالب مشخصی داشته باشد یا فقط «درست» باشد؟ اگر فقط درست کافی است، ساختاردهی نکنید.
مثال ضد: ساخت مستر پرامپت 200 کلمه‌ای برای «میانگین سه عدد را حساب کن». مثال درست: ساخت مستر پرامپت برای تولید 50 توضیح محصول با قالب یکسان و لحن برند.
چگونه پرامپتهایم را نسخه‌بندی و مدیریت کنم؟#
پرامپت‌ها را مانند کد مدیریت کنید: در Git نگهداری، commit message بنویسید، تغییرات را با مدل هدف مستند کنید و برای پروژه‌های تیمی از یک ساختار پوشه‌بندی استاندارد استفاده کنید.
الگویی که در پروژه‌های واقعی تیمهای AI تکرار میشود: پوشه‌ی prompts/ با زیرپوشه بر اساس وظیفه، فایل changelog.md برای ثبت تغییرات، و فرمت commit message که دلیل تغییر را هم بگوید. مثلاً: «پرامپت X: تغییر delimiter از سه‌گیومه به XML tag — دلیل: مدل Y خروجی را اشتباه تفسیر می‌کرد».
تیم‌هایی که پرامپت‌هایشان را در Git نگه می‌دارند، تجربه‌ی بهتری در debug کردن خروجی‌های غیرمنتظره دارند. وقتی می‌دانید کدام تغییر باعث شکستن پرامپت شده، اصلاح سریع است. بدون این، هر باگ یعنی حدس‌زدن.
مهندسی پرامپت یک مهارت یک‌بارمصرف نیست. مستر پرامپت بسازید، تست رگرسیون داشته باشید، و پرامپت‌هایتان را نسخه‌بندی کنید. اگر می‌خواهید این ساختارها را در پروژه‌ی واقعی پیاده کنید — نه فقط تئوری — دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً همین مسیر را از صفر تا محصول طی میکند.
دیدگاه‌ها
برای گذاشتن دیدگاه وارد شو
دیدگاه‌ها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.