مهندسی پرامپت یعنی ساختن یک سیستم لایه‌بندی‌شده برای هدایت مدل زبانی، نه نوشتن یک جمله‌ی هوشمندانه. مستر پرامپت (Master Prompt) در این سیستم، قالبی سهلایه است: ابتدا خروجی مطلوب را توصیف میکند، سپس محدودیت‌ها را می‌گذارد و در انتها task را بیان میکند. این الگوی لایه‌بندی معکوس، برخلاف الگوی خطی رایج، پرامپت را در برابر تغییر مدل مقاوم میکند.
مهندسی پرامپت چیست و چه فرقی با کدنویسی و تنظیم دقیق دارد؟#
مهندسی پرامپت طراحی ورودی متنی برای مدلهای زبانی است تا خروجی قابل‌اتکاء بگیرید. برخلاف کدنویسی، خروجی قطعی نیست و مدل «تفسیر» میکند نه «اجرا». برخلاف تنظیم دقیق (Fine-Tuning)، وزن‌های مدل دست نمی‌خورد و فقط ورودی تغییر میکند.
این تمایز مهم است چون ابزار و ذهنیت هر سه متفاوت است. در کدنویسی، یک سمیکالن گم‌شده یعنی خطای صریح. در مهندسی پرامپت، یک کلمه‌ی مبهم یعنی خروجی متفاوت. در Fine-Tuning، یک داده‌ی ناکافی یعنی مدل بی‌فایده.
مستر پرامپت یک قالب قابلکپی برای استفادهی دستی در چتبات یا API است. پرامپت سیستمی (System Prompt) یک لایهی معماری در درخواست API که رفتار مدل را در سطح session تنظیم میکند. اکثر راهنماهای فارسی‌زبان این دو را یکی فرض می‌کنند، در حالی که کاربرد و جایگاهشان در معماری کاملاً متفاوت است.
جدول زیر سه رویکرد اصلی کار با مدلهای زبانی را مقایسه میکند:
| معیار | مهندسی پرامپت | RAG | Fine-Tuning |
|---|---|---|---|
| هزینه‌ی شروع | پایین‌ترین | متوسط | بالاترین |
| زمان پیاده‌سازی | ساعت | روز | هفته تا ماه |
| مقیاس‌پذیری | محدود به پنجرهی زمینه | مقیاس‌پذیر با پایگاه دانش | مقیاس‌پذیر با داده‌های آموزشی |
| قابل‌بازگشت بودن | بله، با حذف پرامپت | بله، با حذف بازیابی | خیر، وزن‌ها تغییر کرده‌اند |
مستر پرامپت: الگوی لایه‌بندی معکوس که اکثر راهنماها نمی‌گویند#
مستر پرامپت یک قالب ساختاریافته‌ی سهلایه است که ابتدا خروجی مطلوب را توصیف میکند، سپس محدودیت‌ها را می‌گذارد و در انتها task را بیان میکند. برخلاف الگوی خطی رایج که task را اول می‌نویسد، این چیدمان معکوس باعث میشود مدل چارچوب خروجی را قبل از شنیدن دستور داشته باشد.
چرا الگوی خطی شکست می‌خورد؟ وقتی task اول بیاید، مدل آن را در خلأ تفسیر میکند. «یک متن فنی بازنویسی کن» بدون هیچ چارچوبی، یعنی مدل خودش حدس می‌زند مخاطب کیست، لحن چیست و ساختار خروجی چه شکلی باشد. نتیجه ناپایدار است.
در الگوی معکوس، مدل اول می‌فهمد «چه چیزی» باید تولید شود، بعد «چه چیزهایی» نباید باشد، و در انتها «دستور اصلی» را می‌شنود. این ترتیب، فضای تفسیر را کاهش می‌دهد.
سه لایهی مستر پرامپت:
- لایهی خروجی (Output Spec): ساختار، فرمت، طول و مخاطب خروجی را تعریف میکند.
- لایهی محدودیت (Constraints): آنچه نباید در خروجی باشد — اصطلاحات، لحن‌ها، ساختارهای ممنوعه.
- لایهی دستور (Instruction): task اصلی که مدل باید انجام دهد.
نمونه‌ی مستر پرامپت آماده برای بازنویسی محتوای فنی:
Output Spec: یک پاراگراف ۸۰ تا ۱۲۰ کلمه‌ای به فارسی روان، مناسب مخاطب توسعه‌دهنده‌ی با ۲ سال سابقه. ساختار: جمله‌ی اول = نتیجه، جمله‌های بعدی = استدلال و مثال.
Constraints: از اصطلاحات بازاریابی استفاده نکن. جمله‌های بیش از ۲۵ کلمه ننویس. هرگز «در دنیای امروز» یا «شایان ذکر است» شروع نکن. معادل انگلیسی اصطلاح فنی فقط بار اول داخل پرانتز بیاید.
Instruction: پاراگراف زیر را بازنویسی کن:
[متن ورودی]
نقش Negative Examples در مستر پرامپت: نشان دادن یک خروجی نامطلوب و توضیح دلیل آن، مؤثرتر از صرفاً توصیف خروجی مطلوب است. مدل از «چرا این بد است» بیشتر یاد می‌گیرد تا از «این خوب باشد».
هزینه‌ی طول پرامپت: هر توکن اضافه، هزینه‌ی محاسباتی و تأخیر می‌آورد. مستر پرامپت باید با نیاز task متوازن باشد، نه صرفاً طولانی. پرامپتی که task ساده‌ای دارد اما چند صد توکن است، نشانه‌ی طراحی ضعیف است نه دقت بالا.
تکنیک‌های بنیادین: زنجیره‌ی تفکر، چندنمونه‌ای و ایفای نقش#
زنجیره‌ی تفکر (Chain-of-Thought) دقت استدلال را بالا می‌برد، چندنمونه‌ای (Few-Shot) الگوی خروجی را ثابت میکند و ایفای نقش (Role Prompting) لحن و دامنه را تنظیم میکند. هرکدام محدودیت و نقطه‌ی شکست مشخصی دارند که در راهنماهای عمومی کمتر گفته میشود.
زنجیره‌ی تفکر (Chain-of-Thought) و محدودیت‌های واقعی آن#
مقاله‌ی Wei et al. در NeurIPS 2022 نشان داد افزودن مراحل استدلال به پرامپت، دقت مدلهای بزرگ را در مسائل ریاضی و استدلالی به‌طور قابل‌توجهی افزایش می‌دهد. اما این یافته در بافت خاصی اعتبار دارد: مدلهای بدون reasoning بومی.
روی مدلهای reasoning قوی‌تر که خودشان مراحل را می‌سازند، افزودن «Think step by step» اثر چندانی ندارد. روی مدلهای کوچک‌تر گاهی نتیجهی معکوس می‌دهد چون مدل ظرفیت تولید مراحل صحیح را ندارد و فقط فرمت را تقلید میکند.
پاد-الگوی رایج: توصیه‌ی «فقط Think step by step اضافه کن» بهعنوان راه‌حل همیشگی. این توصیه بدون اشاره به نوع مدل، گمراه‌کننده است.
چندنمونه‌ای (Few-Shot) — چند نمونه کافی است؟#
قاعده‌ی عملی از پروژه‌های واقعی: ۲ تا ۵ نمونه معمولاً کافی است. بیش از آن، پنجرهی زمینه (Context Window) اشغال و هزینه‌ی توکن بالا می‌رود بدون بهبود محسوس. اگر ۵ نمونه تفاوتی ایجاد نکرد، مشکل از تعداد نمونه نیست — از کیفیت یا ساختار پرامپت است.
نمونه‌ی پرامپت Few-Shot آماده:
پاراگراف‌های زیر را به سبک مشخص بازنویسی کن:
نمونه ۱ — ورودی: «معماری میکروسرویس شامل سرویس‌های کوچک و مستقل است که هرکدام یک capability را پیاده‌سازی میکند.»
نمونه ۱ — خروجی: «میکروسرویس یعنی شکستن سیستم به قطعات مستقل. هر قطعه یک کار انجام می‌دهد و خودش تصمیم می‌گیرد.
نمونه ۲ — ورودی: «الگوی Circuit Breaker با قطع موقت ارتباط بین سرویس‌ها، از فروپاشی زنجیره‌ای جلوگیری میکند.»
نمونه ۲ — خروجی: «Circuit Breaker مثل فیوز برق است. وقتی یک سرویس خراب شد، ارتباط را قطع میکند تا بقیه سرویس‌ها هم از پا درنیایند.»
نمونه ۳ — ورودی: «[متن جدید]»
خروجی:
ایفای نقش (Role Prompting) و مکانیسم واقعی اثر آن#
مکانیسم واقعی Role Prompting محدودسازی دامنه‌ی واژگان و لحن است، نه «شخصیت‌پردازی». وقتی می‌گویید «تو یک ویراستار حرفهای هستی»، مدل واژگان و ساختار جملات را از فضای ویراستاری انتخاب میکند. اثر واقعی از این محدودسازی می‌آید، نه از «جادوی کلمات».
پاد-الگو: «Act as a world-class expert in quantum physics» بدون توضیح دامنه‌ی مورد نظر. مدل «world-class expert» را تفسیر میکند — گاهی یعنی توضیح ساده، گاهی یعنی فرمول‌نویسی. باید مشخص کنید «expert» یعنی چه: برای چه مخاطبی، با چه سطحی، در چه فرمتی.
چرخه‌ی تست و فرسودگی پرامپت: چرا پرامپت دیروز امروز شکست می‌خورد؟#
فرسودگی پرامپت (Prompt Decay) پدیده‌ای است که در آن، پس از به‌روزرسانی مدل، پرامپتهای قبلی رفتار متفاوت نشان میدهند. راه‌حل، تست رگرسیون منظم و نسخهبندی پرامپت (Prompt Versioning) است. بدون این دو، پرامپتهای شما بی‌صدا خراب می‌شوند.
الگوی تکرارشونده در پروژه‌های واقعی: پرامپتی که روی نسخه‌ی قبلی مدل دقیق کار می‌کرد، پس از به‌روزرسانی، خروجی‌های متفاوت یا نامطلوب تولید میکند. هیچ خطایی دریافت نمی‌کنید. فقط کیفیت خروجی افت میکند. این خطرناک‌تر از یک crash صریح است.
تست رگرسیون روی پرامپت: مجموعه‌ای از ورودی‌های مرجع (Golden Set) که پس از هر تغییر مدل یا ویرایش پرامپت، دوباره اجرا و مقایسه می‌شوند. Golden Set باید شامل حالت‌های لبه (edge cases) باشد، نه فقط حالت‌های معمولی.
نسخهبندی پرامپت: ثبت تاریخ، نسخه‌ی مدل، و نتیجهی تست برای هر تغییر. بدون این، ردیابی علت شکست غیرممکن است. در پروژه‌های واقعی، پرامپت‌ها در فایل‌های جداگانه با نام‌گذاری versioned نگهداری می‌شوند — دقیقاً مثل کد.
الگوی «لایهی تناقض»: در پروژه‌های واقعی، پرامپت‌هایی که بیش از ۳ لایهی instructions متناقض دارند، بدون خطای صریح، رفتار مدل را غیرقابل‌پیش‌بینی می‌کنند. مثلاً لایهی اول بگوید «کوتاه بنویس» و لایهی سوم بگوید «تمام جزئیات را پوشش بده». باید قبل از ارسال، تناقض‌ها دستی بررسی و حذف شوند.
چه زمانی مهندسی پرامپت پاسخ درست نیست؟#
وقتی دانش مورد نیاز در وزن‌های مدل وجود ندارد، RAG لازم است. وقتی رفتار مدل باید به‌طور ساختاری تغییر کند، Fine-Tuning. وقتی task چندمرحله‌ای و پویاست، جریان کاری عاملی (Agentic Workflow). مهندسی پرامپت در هر سه مورد، لایهی تکمیلی باقی می‌ماند نه جایگزین.
جدول تصمیم‌گیری:
| سناریو | ابزار مناسب | نقش پرامپت |
|---|---|---|
| پاسخ در دانش مدل نیست | RAG | تنظیم نحوه‌ی استفاده از اسناد بازیابی‌شده |
| رفتار ساختاری مدل باید عوض شود | Fine-Tuning | تعریف task و format خروجی |
| Task چندمرحله‌ای با تصمیم بین‌مرحله‌ای | Agentic Workflow | تعریف هر گام در زنجیره |
| Task تک‌مرحله‌ای با خروجی مشخص | فقط پرامپت | مستر پرامپت کامل |
مقایسه‌ی هزینه‌ی نسبی: یک پرامپت کوتاه روی task ساده، گاهی بهتر از یک مدل تنظیم‌شده با هزاران نمونه عمل میکند. Fine-Tuning برای taskهایی است که پرامپت به‌طور مداوم شکست می‌خورد و نیاز به تغییر الگوی رفتاری مدل دارید.
ایجنت هوش مصنوعی (AI Agent) و جریان کاری عاملی: وقتی task نیاز به تصمیم‌گیری بین‌مرحله‌ای دارد — مثلاً «اول جستجو کن، بعد اگر نتیجه کافی نبود دوباره جستجو کن» — پرامپت تک‌مرحله‌ای کافی نیست. اینجا پرامپت به لایه‌ای از یک سیستم بزرگ‌تر تبدیل میشود.
مهندسی پرامپت شغل مستقل محسوب میشود؟ مرز آن با طراحی محصول و توسعهی نرمافزار در حال محو شدن است. بهعنوان شغل تماموقت مستقل نادر است، اما بهعنوان مهارت مکمل در نقشهای AI Engineer، Product Manager و Developer، ضروری شده. این واقعیت را اکثر راهنماها نمی‌گویند.
ابزارها و پاد-الگوها: از DSPy تا اشتباهاتی که هزینه‌ی پنهان دارند#
ابزارهایی مانند DSPy، Promptfoo و LangChain چرخه‌ی تست و بهینه‌سازی پرامپت را خودکارسازی می‌کنند. اما پاد-الگوهای رایج — مثل پرامپتهای بی‌پایان، فریم‌ورک‌های مطلق و نادیده‌گرفتن پنجرهی زمینه — اغلب نتیجهی معکوس تولید می‌کنند و هزینه‌ی پنهانشان از صرفه‌جویی ظاهری‌شان بیشتر است.
ابزارهای مدیریت و بهینه‌سازی پرامپت#
DSPy: فریم‌ورک متن‌باز از Stanford NLP که مهندسی پرامپت دستی را به سمت بهینه‌سازی خودکار حرکت می‌دهد. به‌جای نوشتن پرامپت، ماژول تعریف می‌کنید و فریم‌ورک خودش پرامپت را بهینه میکند.
Promptfoo: تست خودکار و مقایسه‌ی خروجی چند پرامپت در برابر چند مدل. مناسب برای Golden Set و تست رگرسیون.
LangChain: ساخت زنجیره‌های پرامپت و اتصال به RAG و ابزارهای خارجی. برای Agentic Workflow و جریان‌های چندمرحله‌ای.
پاد-الگوهایی که در پروژه‌های واقعی تکرار می‌شوند#
این اشتباهات بارها در پروژه‌های مختلف دیده شده‌اند و هزینه‌ی پنهان دارند:
- نادیده‌گرفتن محدودیت پنجرهی زمینه و پرکردن پرامپت با نمونه‌های بی‌پایان Few-Shot. نتیجه: هزینه‌ی توکن بالا و گاهی فراموشی لایه‌های ابتدایی پرامپت.
- ارائه‌ی فریم‌ورک‌ها (RTF، CO-STAR) بهعنوان قانون مطلق بدون تطبیق با نوع task. هر فریم‌ورک برای یک دسته task طراحی شده، نه همه.
- فرض اینکه یک پرامپت خوب روی همه‌ی مدل‌ها کار میکند. Prompt Decay و تفاوت‌های معماری مدل‌ها این فرض را باطل میکند.
- ساخت پرامپت بدون معیار ارزیابی مشخص. اگر نمی‌دانید «خوب» یعنی چه، نمی‌توانید تست کنید.
پرامپتهای آمادهی فروشگاهی قابلاستفادهاند؟ بستگی به task دارد. پرامپتهای عمومی معمولاً بدون شخصیسازی نتیجهی ضعیف میدهند. پرامپتهای domain-specific که با Negative Example و Constraints ساختاریافتهاند، ارزش بیشتری دارند — اما حتی آنها هم بدون تست روی مدل هدف شما اعتبار ندارند.
جمع‌بندی عملی: مهندسی پرامپت مهارتی است که با ساختن سیستم یاد گرفته میشود، نه با حفظ الگو. مستر پرامپت سهلایه، تست رگرسیون با Golden Set، و نسخهبندی — این سه، حداقل‌های حرفه‌ای‌بودن هستند.
اگر می‌خواهید این مهارت را در پروژهی واقعی تمرین کنید و بدون کدنویسی ایده‌تان را به محصول تبدیل کنید، دوره‌ی آفلاین «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول، ۵۳ جلسه‌ی عملی دارد که دقیقاً روی همین ساختار پرامپت‌نویسی، تست و ایجنت‌سازی تمرکز دارد.
دیدگاه‌ها
برای گذاشتن دیدگاه وارد شو
دیدگاه‌ها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.