مهندسی پرامپت مهارتی نیست که با تکرار قوی‌تر میشود؛ دارایی‌ای فرسایشی است. هر بار که مدل به‌روز میشود، پرامپتی که دیروز دقیق کار می‌کرد امروز رفتار متفاوتی نشان میدهد. بیشتر تیم‌ها وقتشان را صرف بهینهسازی پرامپت می‌کنند درحالی‌که مشکل در لایه‌ی دیگری است. این راهنما مشخص میکند مستر پرامپت را چطور بسازید، کِی متوقف شوید و کِی اصلاً سراغش نروید.
مهندسی پرامپت چیست و چه فرقی با مهندسی زمینه دارد؟#
مهندسی پرامپت طراحی ورودی متنی مدل زبانی (LLM) است؛ مهندسی زمینه (Context Engineering) اما مدیریت کل ورودی مدل — اسناد بازیابی‌شده، تاریخچه گفتگو، خروجی ابزارها — را در بر می‌گیرد. مستر پرامپت تنها یک جزء از این کل است، نه خودِ کل.
اکثر منابع فارسی این دو مفهوم را یکی می‌دانند. این اشتباه هزینه‌ی عملی دارد: کسی که فکر میکند مشکل از پرامپت است، پرامپت را دستکاری میکند درحالی‌که مشکل در پنجره‌ی زمینه (Context Window) یا کیفیت اسناد بازیابی‌شده است.
مهندسی پرامپت ساختاردهی پرامپت سیستمی (System Prompt) و پرامپت کاربری (User Prompt) برای هدایت رفتار مدل است. تنظیم دقیق (Fine-tuning) اما تغییر وزن‌های داخلی مدل را هدف می‌گیرد. این دو ابزار متفاوت‌اند و جایگزین یکدیگر نیستند.
ساختار مستر پرامپت: 5 جزء که بدون آن‌ها پرامپت ناقص است#
مستر پرامپت یک پرامپت ساختاریافته با 5 جزء ضروری است: نقش، زمینه، محدودیت، نمونه و قالب خروجی. حذف هر یک از این اجزا، پرامپت را از حالت قابل‌نگهداشت خارج میکند و آن را به یک جمله‌ی آزمایشی تبدیل میکند.
جزء 1 — نقش (Role): تعیین رفتار، نه نمایش شخصیت#
«تو یک متخصص 20 ساله با تجربه‌ی بی‌نظیر هستی» بی‌فایده است. نقش باید رفتار مورد انتظار را دقیق تعریف کند: «تو یک ویراستار فنی هستی. هر جمله‌ای که بیش از 25 کلمه دارد را بشکن. اصطلاح فنی را در اولین استفاده داخل پرانتز توضیح بده.»
جزء 2 تا 5 — زمینه، محدودیت، نمونه و قالب#
زمینه (Context) اطلاعاتی است که مدل بدون آن نمی‌تواند تصمیم درست بگیرد. محدودیت (Constraints) آنچه نباید انجام شود را مشخص میکند. نمونه (Few-shot Example) یک یا دو ورودی-خروجی برای کالیبراسیون است. قالب خروجی (Output Format) ساختار دقیق پاسخ مورد انتظار را تعیین میکند.
دو نمونهی آماده برای کپی و شخصیسازی:
نمونه 1 — خلاصهسازی سند:
نقش: تو یک خلاصه‌نویس فنی هستی. فقط اطلاعاتی را بنویس که مستقیماً در متن منبع آمده.
زمینه: این سند یک گزارش فنی داخلی است. مخاطب، تیم مهندسی با پیش‌زمینه‌ی فنی است.
محدودیت: هیچ اطلاعاتی اضافه نکن. هیچ نتیجه‌گیری‌ای از خودت درنیاور. اگر بخشی از سند مبهم است، بنویس «مبهم» و توضیح بده چرا.
نمونه: ورودی: «سیستم X در بار 500 کاربر همزمان، 3 ثانیه تأخیر نشان داد.» → خروجی: «تأخیر: 3 ثانیه | شرط: 500 کاربر همزمان | سیستم: X»
قالب خروجی: جدول 3 ستونه با ستون‌های «موضوع»، «یافته»، «شرط/محدوده».
نمونه 2 — تولید کد:
نقش: تو یک توسعه‌دهنده‌ی Python هستی که فقط کد قابل‌اجرا می‌نویسید، نه توضیح.
زمینه: پروژه از FastAPI استفاده میکند. دیتابیس PostgreSQL است. ORM: SQLAlchemy 2.0.
محدودیت: هیچ import اضافی نکن. هیچ توضیحی بالای کد ننویس. فقط کد. اگر نیاز به توضیح هست، آن را در docstring داخل تابع بگذار.
نمونه: ورودی: «endpoint برای دریافت کاربر بر اساس email» → خروجی: @router.get("/users") def get_user(email: str = Query(...)) -> User: ...
قالب خروجی: فقط یک code block. هیچ متن دیگری قبل یا بعد از آن.
چرا پرامپت جواب نمی‌دهد؟#
پرامپت جواب نمی‌دهد وقتی طولانی‌تر از آن است که مدل دستورهای میانی را ببیند، وقتی دستورهایش با هم تناقض دارند، یا وقتی نقش‌بازی بی‌هدف توهم‌زایی (Hallucination) را تشدید میکند. دستکاری temperature هم جای اصلاح ساختار پرامپت را نمی‌گیرد.
پدیده‌ی Lost in the Middle — معرفی‌شده توسط Liu et al. (2023) — نشان میدهد مدل‌های زبانی اطلاعات میانی context را بدتر از ابتدا و انتها بهکار می‌گیرند. اگر پرامپت شما طولانی است، دستورهای کلیدی را در ابتدا و انتها بگذارید، نه وسط.
نقش‌بازی بدون هدف مشخص، مدل را به نمایش شخصیت سوق میدهد نه پاسخ دقیق. «تو متخصص هستی» بدون تعریف رفتار، فضای پاسخ را اشغال میکند بدون آنکه رفتار مدل را هدایت کند.
الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی: پرامپت‌هایی که در یک مدل جواب می‌دهند و در مدل دیگر شکست می‌خورند، معمولاً به instructions میانی وابسته‌اند. این دقیقاً همان آسیب‌پذیری Lost in the Middle است.
4 تکنیک پرامپت‌نویسی و محدوده‌ی مؤثر هرکدام#
تکنیک‌های اصلی شامل بدون‌نمونه (Zero-shot Prompting)، نمونه‌محور (Few-shot Prompting)، زنجیره تفکر (Chain of Thought) و تجزیه (Decomposition) هستند. انتخاب درست آن‌ها به نوع تسک و مدل مورد استفاده بستگی دارد، نه به «بهترین بودن» مطلق.
بدون‌نمونه، نمونه‌محور و زنجیره تفکر#
بدون‌نمونه برای تسک‌های ساده و مدل‌های قوی که الگو را از آموزش قبلی می‌شناسند مناسب است. نمونه‌محور برای تسک‌هایی که قالب خروجی خاص دارند و مدل آن را از آموزش قبلی نمی‌شناسد. زنجیره تفکر — معرفی‌شده توسط Wei et al. (2022) — برای تسک‌های منطقی و ریاضی مؤثر است.
نکته‌ی مهم: در مدل‌های reasoning مانند OpenAI o1، تکنیک‌های زنجیره تفکر سنتی غیرضروری شده‌اند. این مدل‌ها خودشان تفکر را مدیریت می‌کنند؛ اضافه کردن «قدم‌به‌قدم فکر کن» به پرامپت آن‌ها بی‌اثر یا حتی مضرب است.
تجزیه و خودسازگاری#
Anthropic در راهنمای رسمی خود توصیه میکند تسک پیچیده را به مراحل کوچک‌تر بشکنید. خودسازگاری (Self-consistency) — گرفتن چند پاسخ و انتخاب رایج‌ترین — برای تسک‌هایی که خروجی واحد دارند مؤثر است اما هزینه‌ی API را چند برابر میکند.
| تکنیک | نوع تسک مناسب | مدل مناسب | محدودیت |
|---|---|---|---|
| بدون‌نمونه | تسک ساده، قالب استاندارد | مدل‌های قوی (GPT-4o, Claude 3.5) | برای قالب‌های خاص جواب نمی‌دهد |
| نمونه‌محور | قالب خروجی خاص | همه مدل‌ها | مصرف توکن بالا |
| زنجیره تفکر | منطق، ریاضی، تحلیل | مدل‌های بدون reasoning داخلی | در مدل‌های reasoning غیرضروری است |
| تجزیه | تسک چندمرحلهای پیچیده | همه مدل‌ها | نیاز به orchestration |
| خودسازگاری | خروجی واحد با دقت بالا | همه مدل‌ها | هزینه‌ی API چند برابر |
3 دسته تسک که پرامپت‌نویسی در آن‌ها شکست می‌خورد#
برای سه دسته تسک، مهندسی پرامپت ابزار اشتباه است: تسک‌های دانش‌محور (RAG بهتر است)، تسک‌های ساختاریافته با دقت عددی (کدنویسی بهتر است)، و تسک‌هایی که خروجی 100% تکرارپذیر می‌خواهند (deterministic pipeline).
نیاز به دانش به‌روز: مدل نمی‌تواند با پرامپت بهتر، اطلاعاتی که ندارد بسازد. اینجا RAG (Retrieval Augmented Generation) ابزار درست است، نه پرامپت طولانی‌تر. ادعای «پرامپت جایگزین کدنویسی» یک anti-pattern است؛ کد دقیق‌تر و قابل‌تکرارتر از هر پرامپتی عمل میکند.
نیاز به تکرارپذیری مطلق: temperature و sampling ذاتی مدل، خروجی را stochastic میکند. هیچ پرامپتی این را حل نمی‌کند. باید از deterministic pipeline استفاده کرد.
نقش پرامپت در اکوسیستم ایجنت هوش مصنوعی (AI Agent): مهندسی پرامپت به‌تنهایی برای ایجنتهای چندمرحلهای کافی نیست. باید در کنار tool design و orchestration قرار بگیرد. پرامپت خوب در یک ایجنت بد، خروجی بد تولید میکند.
نگهداشت مستر پرامپت و معیار توقف#
مستر پرامپت یک دارایی فرسایشی است که با هر آپدیت مدل ممکن است رفتار آن تغییر کند. معیار توقف مشخص: اگر تغییر پرامپت بیش از 2 بار متوالی خروجی را معنادار تغییر نداد، مشکل از پرامپت نیست و باید به لایه‌های دیگر — context، tool، model selection — رجوع کرد.
چرا پرامپت با آپدیت مدل می‌شکند؟#
مدل‌ها آپدیت می‌شوند و رفتار آن‌ها تغییر میکند. پرامپتی که دیروز دقیق کار می‌کرد، امروز ممکن است دستورهایش را نادیده بگیرد یا تفسیر متفاوتی از آن‌ها داشته باشد. این ذاتی مدل‌های زبانی است، نه باگ.
راه‌حل عملی: مستر پرامپتها را در version control نگه دارید. یک test suite با چند خروجی مورد انتظار بسازید. بعد از هر آپدیت مدل، تست‌ها را اجرا کنید. اگر رفتار تغییر کرد، پرامپت را بازنگری کنید — نه اینکه پرامپتهای قدیمی را بدون تست بهکار ببرید.
معیار «به‌اندازه بودن» پرامپت#
اگر پرامپت شما بیش از 1500 توکن دارد و هنوز رفتار مدل را کنترل نمی‌کند، مشکل از پرامپت نیست. چارچوب تشخیص over-engineering: پرامپت را حذف کنید و فقط نقش + محدودیت بگذارید. اگر خروجی تغییر نکرد، پرامپت شما over-engineered بود.
ابزارهای مدیریت پرامپت: PromptLayer برای ردیابی و نسخهبندی، DSPy برای بهینهسازی خودکار، و LangChain برای orchestration در ایجنت‌ها. انتخاب بستگی به مقیاس و نیاز پروژه دارد.
Temperature و top-p اهرم مکمل‌اند، نه جایگزین پرامپت خوب. اگر پرامپت ساختار ندارد، هیچ تنظیمی آن را نجات نمی‌دهد. اگر پرامپت خوب است، temperature فقط تنوع خروجی را کنترل میکند.
مهندسی پرامپت یک ابزار است، نه یک فلسفه. بسازید، تست کنید، نگهداشت کنید. وقتی شکست، متوقف شوید و لایه‌ی بالاتر را بررسی کنید. اگر میخواهید این مهارت را در پروژه‌های واقعی تمرین کنید و با کسانی که روزانه ایجنت و اتوماسیون می‌سازند هم‌مسیر شوید، دوره‌ی «ساخت AI Agent با N8N» در کامیونیتی اسکول دقیقاً همین مسیر را طی میکند.
دیدگاه‌ها
برای گذاشتن دیدگاه وارد شو
دیدگاه‌ها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.