مهندسی پرامپت مهارت نوشتن نیست؛ مهارت تصمیم‌گیری است. بزرگ‌ترین اتلاف منابعی که در پروژه‌های واقعی دیده می‌شود، تیم‌هایی‌اند که ماه‌ها پرامپت را بازنویسی می‌کنند، در حالی که مشکلشان اصلاً پرامپت نیست و باید سراغ RAG (Retrieval-Augmented Generation) یا تنظیم دقیق (Fine-tuning) بروند. این مقاله می‌گوید چه بسازید، چه رها کنید و کِی ابزار را عوض کنید.

مهندسی پرامپت چیست و چه فرقی با نوشتن ساده‌ی پرامپت دارد؟#

مهندسی پرامپت (Prompt Engineering) طراحی عمدی و تکرارپذیر ساختار ورودی مدل زبانی بزرگ (Large Language Model) برای کنترل رفتار خروجی است. نوشتن ساده یعنی یک جمله بفرستید و دعا کنید؛ مهندسی یعنی پیش از ارسال، درباره‌ی بافت، محدودیت و فرمت خروجی تصمیم گرفته باشید.

تفاوت عملی در یک واژه خلاصه می‌شود: «تکرارپذیر».

پرامپت‌نویسی ساده یک‌بارمصرف است — برای این مدل، این task، این بار. مهندسی پرامپت یعنی یک ساختار بسازید که اگر مدل را عوض کنید، task را تغییر دهید یا تیم جدیدی بیاید، همان ساختار همچنان کار کند. این تفاوت، تفاوت بین یک ترفند و یک دارایی است.

در چرخه‌ی توسعه‌ی AI، مهندسی پرامپت اولین لایه‌ی کنترل است. قبل از اینکه هزینه‌ی RAG یا fine-tuning را بپردازید، باید مطمئن شوید مشکل واقعاً در پرامپت نیست. اگر با یک ساختار درست، مدل پاسخ قابل‌قبولی می‌دهد، بقیه‌ی ابزارها اضافه‌اند و هزینه‌ی بی‌دلیل‌اند.

مهندسی پرامپت در جایگاه «قبل از مدل‌سازی» قرار دارد. اگر مدل پایه‌اش مشکل دارد، هیچ پرامپتی نجاتش نمی‌دهد. اگر دانش لازم در context window (پنجره‌ی بافت) جا نمی‌شود، پرامپت کافی نیست. اگر task نیاز به رفتار سبکی خاصی دارد که با دستورالعمل متنی قابل‌تحقق نیست، fine-tuning منطقی‌تر است. تشخیص اینکه مشکل در کدام لایه است، ارزشمندتر از هر تکنیک پرامپت‌نویسی است.

موضوعات مرتبطی مثل مدل زبانی بزرگ چیست و ایجنت هوش مصنوعی (AI Agent) چگونه از پرامپت تک‌نوبتی به چندمرحله‌ای تبدیل می‌شود، در مقالات دیگر همین مجموعه پوشش داده شده‌اند.

ساختار مستر پرامپت: ۵ بخش و نه بیشتر#

مستر پرامپت (Master Prompt) پرامپت پایه‌ای است که در system message (پیام سیستمی) قرار می‌گیرد و تمام رفتار مدل را برای یک task مشخص تنظیم می‌کند. الگوی تکرارشونده‌ی آن ۳ تا ۵ بخش است؛ بیشتر از این مدل را گیج می‌کند، کمتر از آن ابهام ایجاد می‌کند.

پنج لایه‌ی مجزا و شفاف که با دقت روی هم قرار گرفته‌اند و یک ساختار واحد و منظم را می‌سازند
هر بخش مستر پرامپت یک لایه‌ی مستقل است؛ حذف یا اضافه‌ی یکی، کل سازه را تغییر می‌دهد

پنج بخش استاندارد:

  1. Role/Goal: مدل کیست و هدف نهایی چیست. نه persona نمایشی، بلکه یک تعریف عملکردی.
  2. Context: دانش زمینه‌ای که مدل بدون آن task را درست انجام نمی‌دهد. مخاطب، دامنه، محدودیت‌های محیطی.
  3. Task: دقیقاً چه کاری باید انجام شود. یک جمله‌ی امری مشخص، نه توصیف کلی.
  4. Constraints/Anti-goals: چه نکند، از چه چیزی پرهیز کند، چه خط قرمزی دارد.
  5. Output Format: خروجی چه شکلی باشد. زبان، فریمورک، طول، ساختار.

چرا بیشتر از ۵ بخش مشکل‌ساز است؟ در پروژه‌های واقعی الگوی تکرارشونده‌ای دیده می‌شود: هر بخش اضافه، یک متغیر جدید به فضای جستجوی مدل اضافه می‌کند. مدل‌های بزرگ در task‌های چندمقیاسی، اگر دستورالعمل‌ها بیش از حد پراکنده باشند، بین اولویت‌ها سرگردان می‌شوند. پنج بخش کافی است چون هر بخش یک بُعد مستقل تصمیم‌گیری را پوشش می‌دهد و همپوشانی بین بخش‌ها فقط نویز می‌سازد.

بخش Anti-goals را جدی بگیرید. بسیاری از پرامپت‌ها فقط می‌گویند «چه بکن»، نه «چه نکن». مشاهده‌ی مکرر در پروژه‌های اعضای کامیونیتی این است: افزودن صریح «این نکند» خروجی قابل‌اتکاتر می‌سازد، چون مدل از مسیرهای کم‌کیفیت که ذاتاً در فضای پاسخ‌دهی‌اش وجود دارند، منصرف می‌شود. بدون Anti-goals، مدل به‌طور پیش‌فرض بدترین الگویی را که در داده‌های آموزش‌دیده‌اش یاد گرفته، بازتولید می‌کند.

تفاوت مستر پرامپت کدنویسی و تولید محتوا در تمرکز بخش‌هاست. در کدنویسی، Output Format و Constraints (زبان، فریمورک، الگوی معماری، ممنوعیت کتابخانه‌های خاص) سنگین‌ترند. در تولید محتوا، Context (مخاطب، لحن، دامنه) و Anti-goals (ممنوعیت کلیشه‌ها، ممنوعیت عبارات ماشینی) مهم‌ترند.

مثال عملی — مستر پرامپت برای تولید محتوای فارسی:

Role: تو یک نویسنده‌ی فنی فارسی‌زبان هستی که مخاطبش توسعه‌دهنده‌های با تجربه است.

Context: مخاطب مقاله، کسی است که با مفاهیم AI آشنایی پایه دارد اما نمی‌خواهد مقدمه‌ی آموزشی بخواند. لحن: مستقیم، مطمئن، بدون تعارف. دامنه: مهندسی پرامپت و توسعه‌ی ایجنت.

Task: یک بخش ۲۰۰ کلمه‌ای درباره‌ی تفاوت zero-shot و few-shot بنویس.

Anti-goals: از عبارت‌های «در دنیای امروز»، «شایان ذکر است»، «بدون شک» استفاده نکن. مقدمه‌ی چرب‌زبان ننویس. هرگز ادعای آماری بدون منبع نکن.

Output Format: فارسی، نیم‌فاصله‌ی درست، پاراگراف‌های حداکثر ۴ خطی، بدون لیست مگر ضروری باشد.

مثال عملی — مستر پرامپت برای بازبینی کد Python:

Role: تو یک senior code reviewer هستی که فقط روی باگ‌های واقعی و مشکلات معماری تمرکز می‌کند، نه style nitpick.

Context: پروژه یک سرویس backend با Python 3.11 است. از FastAPI و Pydantic v2 استفاده می‌شود. naming convention: snake_case برای متغیرها، PascalCase برای کلاس‌ها.

Task: کد زیر را بازبینی کن. فقط مشکلاتی را گزارش بده که در production باعث باگ یا performance issue می‌شوند.

Constraints: کتابخانه‌ی جدید پیشنهاد نده مگر مشکل بدون آن قابل‌حل نباشد. فرض کن نویسنده با PEP 8 آشناست.

Output Format: JSON با فیلدهای severity (critical/warning/info)، file، line، description، suggested_fix.

مهندسی بافت (Context Engineering) تکامل مستر پرامپت است. اگر ساختار پرامپت را می‌سازید ولی خروجی هنوز قابل‌اتکاتر نیست، مشکل احتمالاً در نحوه‌ی تزریق بافت به مدل است، نه در خود پرامپت. این موضوع در مقاله‌ی جداگانه‌ای پوشش داده شده است.

مهندسی پرامپت یا Fine-tuning یا RAG؟ کدام را کِی انتخاب کنید#

مهندسی پرامپت برای task‌هایی کافی است که دانش لازم در context window جا می‌شود و مشکل فقط در ساختار دستورالعمل است. نشانه‌ی عملی: اگر بیش از ۳ بار پرامپت را بازنویسی کرده‌اید و هنوز hallucination (توهم‌زایی) دارید، مهندسی پرامپت ابزار مناسبی نیست و باید سراغ RAG یا fine-tuning بروید.

این تصمیم «کدام بهتر است» نیست. این تشخیص «مشکلم کجاست» است. اگر مشکل دانش است، RAG. اگر مشکل سبک و رفتار است، fine-tuning. اگر مشکل ساختار دستورالعمل است، پرامپت. اشتباه پرهزینه‌تر از آن است که به‌نظر می‌رسد: تیم‌ها پرامپت را بازنویسی می‌کنند در حالی که مشکلشان اصلاً پرامپت نیست و ماه‌ها وقت و هزینه‌ی API را صرف راه‌حلی می‌کنند که هرگز جواب نمی‌دهد.

معیار مهندسی پرامپت RAG Fine-tuning
هزینه‌ی شروع بسیار پایین (فقط زمان) متوسط (نیاز به پایگاه دانش) بالا (نیاز به داده و GPU)
زمان پیاده‌سازیساعت تا چند روز چند روز تا چند هفته چند هفته تا چند ماه
انعطاف در تغییر task بالا (بازنویسی پرامپت) متوسط (بروزرسانی پایگاه دانش) پایین (نیاز به retrain)
مناسب برای task‌های ساده تا متوسط دانش پویا، نیاز به استناد سبک خروجی خاص، task ثابت
نقطه‌ی ضعف context window محدود پیچیدگی زیرساختی ریسک overfitting، هزینه‌ی نگهداری

Fine-tuning چه زمانی منطقی است؟ وقتی task ثابت است، داده‌ی کافی دارید (حداقل چند صد نمونه‌ی باکیفیت)، و نیاز به سبک خروجی خاصی دارید که با دستورالعمل متنی قابل‌تحقق نیست. مثلاً اگر می‌خواهید مدل دقیقاً در یک قالب حقوقی خاص بنویسد و هر بار باید ۵۰۰ کلمه instruction بفرستید، fine-tuning منطقی‌تر است.

RAG چه زمانی منطقی است؟ وقتی دانش پویا و حجم زیاد است. مثلاً مستندات محصولی که هر هفته بروزرسانی می‌شود، یا پایگاه دانشی که در context window جا نمی‌شود. RAG مشکل «دانش» را حل می‌کند، نه مشکل «رفتار».

یک نکته‌ی مهم درباره‌ی مدل‌های reasoning-native: در مدل‌هایی مثل o1 و DeepSeek-R1 که زنجیره‌ی تفکر داخلی دارند، افزودن دستی Chain-of-Thought به پرامپت redundant (اضافی) یا حتی مضر است. این تکنیک برای مدل‌های عمومی بدون قابلیت استدلال صریح طراحی شده است. مستندات و راهنمای استفاده‌ی OpenAI از o1 توصیه می‌کند دستورالعمل‌های صریح CoT حذف شوند.

تکنیک‌های بنیادین تا پیشرفته‌ی مهندسی پرامپت#

تکنیک‌های مهندسی پرامپت از zero-shot و few-shot تا chain-of-thought و self-consistency طیف گسترده‌ای دارند. انتخاب درست به نوع task و مدل هدف بستگی دارد، نه به «بهترین» بودن یک تکنیک. تکنیک بدون تطبیق با task، صرفاً مصرف توکن است.

Zero-shot و Few-shot: چه زمانی نمونه بدهیم و چه زمانی ندهیم#

Zero-shot یعنی بدون نمونه‌ی خروجی، فقط task را توضیح دهید. Few-shot یعنی ۲ تا ۵ نمونه‌ی ورودی-خروجی بدهید تا الگوی موردنظرتان را بفهمد.

قاعده‌ی عملی: اگر task شما الگوی ساختاری خاصی دارد که با توصیف متنی قابل‌انتقال نیست (مثلاً یک فرمت لاگ خاص، یا یک سبک نوشتاری غیررایج)، few-shot بدهید. اگر task ساده و رایج است، zero-shot کافی است و نمونه‌دادن فقط context window را اشغال می‌کند.

در پروژه‌های واقعی الگوی تکرارشونده‌ای وجود دارد: تیم‌ها few-shot اضافه می‌کنند چون «احساس می‌کنند بهتر است»، نه چون task واقعاً به آن نیاز دارد. نتیجه: هزینه‌ی API بالاتر، بدون بهبود محسوس کیفیت. این یکی از پنهان‌ترین اتلاف‌هاست، چون کسی متوجه نمی‌شود.

زنجیره‌ی تفکر (Chain-of-Thought): افزایش دقت استدلالی#

Chain-of-Thought (CoT) یعنی از مدل بخواهید قبل از پاسخ نهایی، مراحل استدلال را بنویسد. پژوهش Wei et al. در ۲۰۲۲ نشان داد این تکنیک در task‌های استدلالی (ریاضی، منطق، تحلیل چندمرحله‌ای) دقت را به‌طور معناداری افزایش می‌دهد.

اما دو محدودیت عملی دارد. اول: در مدل‌های reasoning-native (مثل o1 و DeepSeek-R1) که ذاتاً زنجیره‌ی تفکر داخلی دارند، افزودن دستی CoT redundant است. دوم: در task‌های ساده‌ی طبقه‌بندی یا استخراج، CoT فقط توکن مصرف می‌کند و کمکی نمی‌کند. استفاده از CoT در task‌های غیراستدلالی، یکی از رایج‌ترین اشتباهات پرامپت‌نویسان تازه‌کار است.

خروجی ساختارمند (Structured Output): کنترل فرمت با JSON Schema#

اگر خروجی باید به سیستم دیگری بخورد (API، database، frontend)، پرامپت را با دستورالعمل متنی «لطفاً JSON بده» رها نکنید. از JSON Schema یا format instructions استفاده کنید. مدل‌هایی مثل GPT-4o و Claude 3.5 Sonnet از structured output به‌صورت native پشتیبانی می‌کنند.

مشاهده‌ی مکرر در پروژه‌های اعضای کامیونیتی: دستورالعمل متنی «JSON بده» در مدل‌های قدیمی‌تر اغلب خروجی ناقص یا نامعتبر تولید می‌کند. JSON Schema با تعریف فیلدها و انواع، نرخ اعتبار خروجی را به‌طور چشمگیری بالا می‌برد. اگر خروجی شما به یک parser می‌خورد، بدون Schema، در production به باگ برمی‌خورید.

پرامپت‌نویسی تکراری (Iterative Prompting): چرخه‌ی بهبود#

پرامپت‌نویسی تکراری یعنی یک پرامپت بنویسید، خروجی را ارزیابی کنید، پرامپت را اصلاح کنید، تکرار. این چرخه باید مستند باشد: چه تغییر دادید، چرا، خروجی قبل و بعد چه بود. بدون این مستندسازی، بعد از ۱۰ بار بازنویسی نمی‌دانید کدام تغییر واقعاً مؤثر بوده و کدام فقط جابه‌جایی کلمات بوده است.

مستندات Anthropic ساختار XML-based prompting را برای مدل‌های Claude توصیه می‌کند. یعنی بخش‌های پرامپت را داخل تگ‌های XML بگذارید. مستندات OpenAI تفکیک رفتار در system message و محتوا در user message را پیشنهاد می‌دهد. یک ساختار جادویی یک‌بار‌مصرف وجود ندارد؛ ساختار باید با مدل هدف تطبیق یابد.

اشتباهاتی که هزینه‌ی API و اعتبار خروجی را بالا می‌برند#

رایج‌ترین اشتباهات مهندسی پرامپت — افزودن بی‌دلیل persona، قرار دادن دستورالعمل در user message، و استفاده‌ی بیش‌ازحد از توکن‌های تزئینی — هم کیفیت خروجی را کم و هم هزینه را زیاد می‌کنند. این اشتباهات در پروژه‌های واقعی آن‌قدر تکرار می‌شوند که به «بهترین‌عمل» غلط تبدیل شده‌اند.

اشتباه ۱: افزودن persona به‌عنوان توصیه‌ی عمومی. پژوهش Peng et al. در ۲۰۲۳ نشان داد persona تأثیر ناپایداری دارد و در بسیاری از task‌ها به‌اندازه‌ی توصیه‌شده‌ی بلاگ‌ها مؤثر نیست. «تو یک متخصص ۲۰ ساله هستی» معمولاً فقط توکن مصرف می‌کند. اگر task نیاز به persona دارد، باید مستقیماً بر رفتار خروجی اثر بگذارد، نه صرفاً یک برچسب باشد. توصیه‌ی «همیشه persona بگذار» که در ده‌ها بلاگ تکرار شده، در عمل بی‌اثر است.

اشتباه ۲: قرار دادن دستورالعمل‌های طولانی در user message به‌جای system message. در مکالمات چندنوبتی، user message هر بار به context اضافه می‌شود. یعنی ۵۰۰ کلمه instruction در هر دور تکرار می‌شود و هزینه‌ی API مستقیماً بالا می‌رود. system message یک‌بار ارسال می‌شود و در context باقی می‌ماند. این اشتباه، هزینه‌ی یک مکالمه‌ی ۱۰ نوبتی را بی‌دلیل چند برابر می‌کند.

اشتباه ۳: استفاده‌ی بیش‌ازحد از جداول، بولت‌پوینت و ایموجی در system prompt. تزئینات بصری در پرامپت، context window را بی‌دلیل پر می‌کنند. مدل‌ها با متن ساده و ساختارمند بهتر کار می‌کنند. اگر ۲۰ بولت‌پوینت دارید و فقط ۵ تا مؤثرند، ۱۵ تا فقط توکن مصرف می‌کنند.

اشتباه ۴: ارائه‌ی ساختار جادویی یک‌بارمصرف. «این template را کپی کنید و همه‌جا استفاده کنید» غلط است. ساختار پرامپت باید با task و مدل هدف تطبیق یابد. template‌ای که برای GPT-4o عالی کار می‌کند، ممکن است برای Claude 3 Opus بهینه نباشد.

اشتباه ۵: نسخه‌بندی نکردن پرامپت‌ها. پرامپت‌ها هم مثل کد به version control و test suite نیاز دارند. اگر نمی‌دانید نسخه‌ی قبلی چه بود و چرا عوضش کردید، در production به مشکل برمی‌خورید.

اشتباه ۶: جدا دانستن مهندسی پرامپت از دانش دامنه. بدون domain knowledge، بهترین تکنیک مهندسی پرامپت بی‌ارزش است. کسی که نمی‌داند task واقعاً چه می‌خواهد، نمی‌تواند پرامپت درست بنویسد. پرامپت‌نویسی بدون درک دامنه، حدس‌زدن با توکن‌های بیشتر است.

ابزارها و فریمورک‌های مدیریت پرامپت#

مدیریت نسخه‌ی پرامپت (Prompt Versioning) و ارزیابی تکراری پرامپت بدون ابزار، در پروژه‌های واقعی غیرممکن است. فریمورک‌هایی مثل LangSmith، PromptLayer و DeepEval این چرخه را خودکار می‌کنند. اگر پرامپت شما در production است و تغییرش می‌دهید، بدون ابزار، ریسک شکست دارید.

ابزارهای توسعه#

LangSmith: tracing و debugging پرامپت‌ها در محیط production. PromptLayer: نسخه‌بندی، A/B testing و monitoring پرامپت. Weights & Biases: بیشتر برای مدل‌سازی شناخته می‌شود اما بخش Prompt Management آن برای تیم‌هایی که پرامپت و مدل را همزمان مدیریت می‌کنند مناسب است.

ابزارهای ارزیابی#

DeepEval: فریمورک متن‌باز برای ارزیابی خودکار خروجی LLM با معیارهای سفارشی. promptfoo: تست پرامپت‌ها با ورودی‌های متعدد و مقایسه‌ی خروجی‌ها. HumanEval: بیشتر برای ارزیابی کد تولیدشده استفاده می‌شود اما الگوی آن (fixed test cases + expected output) برای ارزیابی پرامپت هم قابل‌الگو است.

مدیریت نسخه‌ی پرامپت: چطور پرامپت را مثل کد Git-manage کنید#

الگوی عملی: پرامپت‌ها را در یک repository جدا نگه دارید. هر تغییر، یک commit با توضیح «چه عوض شد و چرا». کنار هر نسخه، یک test suite داشته باشید.

test suite پرامپت یعنی حداقل ۵ ورودی نمونه با خروجی مورد انتظار. نه لزوماً خروجی دقیق، بلکه ویژگی‌های کلیدی که خروجی باید داشته باشد. مثلاً: «اگر ورودی X را بدهم، خروجی باید شامل فیلد Y باشد و نباید عبارت Z را داشته باشد».

چه زمانی ابزار لازم نیست؟ اگر پرامپت شما یک‌بارمصرف است (مثلاً یک پرامپت برای یک ایمیل خاص)، ابزار اضافه است. چه زمانی بدون آن پروژه شکست می‌خورد؟ وقتی پرامپت در production است، تیمی روی آن کار می‌کند، و تغییرش باید قابل‌ردیابی و قابل‌تست باشد.

جمع‌بندی عملی#

مهندسی پرامپت ابزار اول است، نه ابزار آخر. اگر task شما در context window جا می‌شود و مشکل در ساختار دستورالعمل است، پرامپت بنویسید. اگر بیش از ۳ بار بازنویسی کردید و هنوز مشکل دارید، احتمالاً مشکل پرامپت نیست. اگر دانش لازم جا نمی‌شود، RAG. اگر رفتار و سبک خاص لازم است، fine-tuning. تشخیص این مرز، مهم‌تر از هر تکنیک پرامپت‌نویسی است.

اگر می‌خواهید این مرزها را در پروژه‌های واقعی لمس کنید و مستر پرامپت‌نویسی را با مدل‌هایی مثل Claude عملاً تمرین کنید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول، ۵۳ جلسه‌ی عملی دارد که دقیقاً روی همین تصمیم‌گیری‌ها تمرکز می‌کند.