تیم‌هایی که پرامپت‌هایشان را مثل یادداشت‌های شخصی می‌نویسند، هر بار که مدل آپدیت می‌شود با شکست‌های ناگهانی مواجه میشوند. ساعت‌ها وقت صرف دیباگ رفتار مدل می‌کنند تا توسعه‌ی محصول. ریشه‌ی این مشکل نه بی‌دقتی، بلکه نبود تفکر مهندسی در مدیریت پرامپت است.
مهندسی پرامپت چیست و چرا به یک رشته‌ی مهندسی تبدیل شده؟#
مهندسی پرامپت (Prompt Engineering) طراحی، تست و نگهداشت پرامپتهای تکرارپذیر برای مدل‌های زبانی بزرگ (LLM) است. خروجی‌اش یک مصنوع قابل‌مدیریت (artifact) است که مثل کد باید نسخه‌بندی، تست و در صورت نیاز بازگشت (rollback) شود. تفاوتش با پرامپتنویسی خلاق در همین تکرارپذیری و قابلیت‌سنجش است.
تا پیش از 2023، پرامپتنویسی بیشتر یک مهارت فردی بود. اما وقتی مدلها وارد خط تولید شدند، نیاز به ساختار، نسخه‌بندی و ارزیابی سیستماتیک ظاهر شد. این همان مسیری است که هر ابزار ناپایدار طی میکند: از «هرکس خودش می‌نویسد» به «یک فایل متمرکز با owner مشخص».
تعریف عملیاتی و تمایز با «پرامپتنویسی خلاق»#
پرامپتنویسی خلاق یعنی یک‌بار نوشتن و امیدوار بودن به خروجی خوب. مهندسی پرامپت یعنی نوشتن، تست، اندازه‌گیری، بازطراحی و مستندسازی. معیار تمایز یک سؤال ساده است: اگر فردا مدل عوض شود، آیا می‌دانید کدام بخش از پرامپت شکسته و چرا؟
در گفتگوهای مکرر اعضای کامیونیتی، همین سؤال جواب‌ناپذیر می‌ماند. تیم‌ها پرامپت ۲۰۰ کلمه‌ای دارند، رفتار مدل عوض شده، و کسی نمی‌تواند بگوید کدام خط از آن ۲۰۰ کلمه مقصر است.
جایگاه در چرخه‌ی توسعه‌ی AI#
در چرخه‌ی توسعه‌ی محصول مبتنی بر هوش مصنوعی، مهندسی پرامپت بعد از انتخاب مدل و قبل از استقرار (deployment) قرار میگیرد. انتخاب مدل یک تصمیم معماری است؛ مهندسی پرامپت تصمیم رفتاری است؛ deployment تصمیم عملیاتی. این سه مرحله ownerهای متفاوتی دارند و نباید در یک نفر متمرکز شوند.
چرا موتورهای جستجوی مولد به پرامپت ساختاریافته نیاز دارند#
موتورهای جستجوی مولد (Generative Search Engines) خروجی مدل را مستقیم به کاربر نشان می‌دهند. اگر پرامپت شما ساختار ندارد، خروجی هم ساختار ندارد و در رتبه‌بندی این موتور‌ها جریمه می‌شوید. بهینه‌سازی برای موتورهای مولد (GEO) عملاً یعنی مطمئن شوید پرامپت شما خروجی قابل‌استناد و ساختاریافته تولید میکند.
مستر پرامپت: از پرامپت یک‌خطی تا artifact قابل‌نگهداشت#
مستر پرامپت (Master Prompt) یک پرامپت سیستمی چندبخشی است که نقش، محدوده، فرمت خروجی و مثال‌ها را به‌صورت لایه‌لایه تعریف میکند. باید در فایل جداگانه نگهداری و نسخه‌بندی شود، نه داخل کد hard-code.
تصور کنید یک فایل پیکربندی سرویس را داخل کد اپلیکیشن نوشته‌اید. هر تغییر نیاز به deploy دارد. مستر پرامپت هم همین مشکل را دارد اگر داخل کد باشد. فایل جداگانه یعنی تغییر بدون deploy، یعنی بازبینی (review) قابل‌انجام، یعنی rollback بدون کدنویسی.
آناتومی مستر پرامپت: سیستم، نقش، محدوده، فرمت، مثال، محدودیت#
هر مستر پرامپت قابل‌نگهداشت از شش لایه تشکیل شده است:
- نقش (Role): مدل کیست و چه تخصصی دارد.
- محدوده (Scope): چه کارهایی انجام می‌دهد و چه کارهایی نه.
- فرمت خروجی (Output Format): ساختار دقیق پاسخ.
- مثال‌ها (Examples): حداقل یک ورودی-خروجی نمونه.
- محدودیت‌ها (Constraints): خط‌قرمزهای رفتاری.
- دستورالعمل‌های شکست (Failure Modes): اگر مطمئن نیست چه کند.
لایه‌ی ششم را اکثر راهنماها نادیده می‌گیرند. بدون Failure Mode، مدل در حالت عدم‌اطمینان حدس می‌زند و شما متوجه نمی‌شوید. همین یک لایه، بیشترین تأثیر را روی کاهش هالوسینیشن در تسک‌های فنی دارد.
نمونه‌ی کامل مستر پرامپت#
یک مستر پرامپت واقعی برای تولید محتوای فنی فارسی:
## Role
تو یک نویسنده‌ی فنی فارسی‌زبان با تخصص در حوزه‌ی هوش مصنوعی هستی.
## Scope
- فقط موضوعات مرتبط با مهندسی پرامپت، LLM و ابزارهای AI را پوشش بده.
- اگر سؤال خارج از این محدوده بود، بگو «این موضوع خارج از دامنه‌ی تخصصی من است».
## Output Format
- عنوان: H2
- بلوک پاسخ: پاراگراف اول ۴۰ تا ۶۰ کلمه
- بسط: حداکثر ۴ پاراگراف
- اصطلاح انگلیسی: بار اول با معادل فارسی در پرانتز
## Constraints
- عدد ساختگی ننویس.
- از کلیشه‌های «در دنیای امروز» و «بدون شک» استفاده نکن.
- نیم‌فاصله را رعایت کن.
## Failure Mode
اگر اطلاعات کافی برای پاسخ دقیق نداری، صریحاً بگو «نیاز به راستی‌آزمایی دارد» و حدس نزن.چرا مستر پرامپت را داخل کد hard-code نکنیم؟#
سه دلیل عملی: اول، تغییر پرامپت نباید نیاز به deploy داشته باشد. دوم، بازبینی پرامپت در PR با بازبینی کد متفاوت است و باید در مسیر جداگانه‌ای انجام شود. سوم، اگر 10 سرویس از یک پرامپت استفاده می‌کنند، hard-code یعنی 10 نقطه‌ی شکست مستقل.
فریمورک‌های طراحی پرامپت: RTF، CRISPE و RACE کدام را انتخاب کنیم؟#
هر سه فریمورک ساختار پرامپت را استانداردسازی می‌کنند، اما RTF برای تسک‌های ساده، CRISPE برای نقش‌های پیچیده و RACE برای سیستم‌های چندمرحلهای مناسب‌ترند. انتخاب بستگی به تعداد متغیرهای پرامپت و عمق تصمیم‌گیری دارد.
فریمورک پرامپت یک قالب تکرارپذیر است که اجزای پرامپت را نام‌گذاری میکند. مثل MVC در وب، فریمورک پرامپت هم تفکیک مسئولیت ایجاد میکند. بدون فریمورک، پرامپت‌ها به مرور به یک blob متنی تبدیل میشوند که کسی نمی‌فهمد کدام بخش چه کاری میکند.
جدول مقایسه‌ی سه فریمورک#
| فریمورک | اجزا | بهترین کاربرد | محدودیت |
|---|---|---|---|
| RTF (Role, Task, Format) | 3 جزء | تسک‌های تک‌مرحله‌ای، استخراج داده، خلاصه‌سازی | برای سیستم‌های چندمرحلهای یا نیاز به مثال کافی نیست |
| CRISPE (Capacity and Role, Insight, Statement, Personality, Experiment) | 5 جزء | نقش‌های پیچیده، مشاوره‌ی تخصصی، تولید محتوای بلند | سنگین برای تسک‌های ساده، نیاز به تجربه‌ی پرامپتنویسی |
| RACE (Role, Action, Context, Expectation) | 4 جزء | سیستم‌های چندمرحلهای، ایجنت‌ها، workflowهای اتوماتیک | مدل‌سازی محدودیت‌ها و مثال‌ها را صریح نمی‌کند |
چه زمانی فریمورک لازم نیست و چه زمانی اجباری است؟#
اگر پرامپت شما کمتر از 3 متغیر دارد و خروجی‌اش یک‌بار مصرف است، فریمورک اضافه‌کاری است. اما اگر پرامپت در یک خط تولید استفاده می‌شود، بیش از یک نفر آن را ویرایش میکند، یا باید روی چند مدل تست شود، فریمورک اجباری است.
ترکیب فریمورک‌ها در پروژه‌های واقعی#
در پروژه‌های واقعی، معمولاً RTF را به‌عنوان اسکلت استفاده می‌کنند و اجزای CRISPE یا RACE را به‌صورت اختیاری اضافه می‌کنند. مثلاً یک ایجنت N8N که خروجی JSON تولید میکند، اسکلت RTF دارد ولی بخش Format را با schema دقیق JSON پر میکند که از CRISPE گرفته شده.
یک قضاوت صریح: CRISPE در عمل بیشتر یک ابزار بازاریابی است تا یک فریمورک واقعی. پنج جزء آن مرزهای روشنی ندارند و کاربر بعد از دو هفته نمی‌تواند بگوید «Insight» و «Statement» دقیقاً چه تفاوتی دارند. RACE ساده‌تر و قابل‌استدلال‌تر است.
تکنیک‌های پرامپتنویسی و مرزهای کاربردشان#
Zero-shot، Few-shot، Chain-of-Thought و Role Prompting هرکدام در شرایط خاصی مؤثرند. CoT روی مدل‌های reasoning-native نه‌تنها بی‌فایده بلکه مضر است و role prompting در تسک‌های فنی دقت را کاهش می‌دهد.
این تکنیک‌ها جایگزین هم نیستند، مکملاند. انتخاب غلط یکی از رایج‌ترین اشتباهات تیم‌هایی است که تازه وارد مهندسی پرامپت شده‌اند. مثلاً افزودن «think step by step» به پرامپت o1 عملاً به مدل دستور می‌دهد که reasoning داخلی‌اش را بیرون بکشد — کاری که مدل خودش بهتر انجام می‌دهد.
Zero-shot و Few-shot: چه تعداد نمونه کافی است؟#
Zero-shot یعنی بدون نمونه، فقط دستور. Few-shot یعنی یک یا چند نمونه‌ی ورودی-خروجی داخل پرامپت. در پروژه‌های واقعی، 2 تا 3 نمونه‌ی متنوع معمولاً کافی است. بیشتر از این، پنجرهی زمینه را اشباع میکند و هزینهی توکن بالا می‌رود بدون بهبود محسوس خروجی.
Chain-of-Thought و استثنای مدل‌های reasoning-native#
مدل‌هایی مثل o1، o3 و Gemini 2.0 Thinking که reasoning را درونی‌سازی کرده‌اند، نیازی به CoT صریح ندارند. دستور «مرحله به مرحله فکر کن» روی این مدلها گاهی باعث می‌شود مدل به‌جای reasoning عمیق، یک reasoning سطحی و ساختاریافته تولید کند. این یک الگوی ضدهم (anti-pattern) شناخته‌شده است.
Role Prompting: کجا مؤثر و کجا مضر است؟#
Role prompting وقتی مؤثر است که خروجی نیاز به لحن یا پرسپکتیو مشخص دارد: «تو یک ویراستار محتوای فنی هستی». اما وقتی تسک ذاتاً فنی و بدون نیاز به لحن است — مثلاً استخراج موجودیت (entity) از متن — role prompting میتواند دقت را کاهش دهد چون مدل بخشی از ظرفیتش را صرف حفظ نقش میکند.
Structured Output و Deterministic Prompting#
اگر خروجی پرامپت وارد یک خط لوله (pipeline) خودکار می‌شود، باید deterministic باشد. یعنی همان ورودی، همان خروجی. برای این کار: temperature را صفر کنید، فرمت خروجی را با schema دقیق مشخص کنید، و محدودیت‌های رفتاری را صریح بنویسید.
نمونه‌ی پرامپت few-shot با فرمت JSON#
دستور: از متن ورودی، نام شرکت، محصول و بازه‌ی زمانی را استخراج کن و به‌صورت JSON برگردان.
ورودی نمونه ۱:
«اسکول در سال ۲۰۲۴ دورهی ساخت Ai Agent با N8N را راه‌اندازی کرد.»
خروجی نمونه ۱:
{"company": "اسکول", "product": "دورهی ساخت Ai Agent با N8N", "year": "2024"}
ورودی نمونه ۲:
«تیم فنی Anthropic در فوریه ۲۰۲۵ مدل Claude 3.7 Sonnet را منتشر کرد.»
خروجی نمونه ۲:
{"company": "Anthropic", "product": "Claude 3.7 Sonnet", "year": "2025"}
ورودی جدید:
{TEXT}چطور بفهمم پرامپتم واقعاً کار میکند؟#
ارزیابی پرامپت (Prompt Evaluation) یعنی اجرای پرامپت روی مجموعه‌ای از ورودی‌های شناخته‌شده و مقایسه‌ی خروجی با پاسخ مورد انتظار. بدون مجموعه‌ی آزمون (test suite)، پرامپت شما فقط یک حدس خوب است که روی یک نمونه‌ی تصادفی جواب داده.
طراحی پرامپت با محوریت آزمون (Eval-driven prompt design) یعنی برعکس کار کنید: اول تست بنویسید، بعد پرامپت. این الگو از TDD در مهندسی نرم‌افزار گرفته شده و در پروژه‌های واقعی که پرامپت‌ها در خط تولید هستند، مکرر دیده می‌شود.
الگوی eval-driven prompt design: از تست به طراحی#
مراحل عملی:
- 10 تا 20 ورودی واقعی از داده‌های تولیدی جمع کنید.
- برای هر ورودی، خروجی مورد انتظار را دستی بنویسید.
- پرامپت اولیه را اجرا کنید و خروجی را با مورد انتظار مقایسه کنید.
- اختلاف را تحلیل کنید: مشکل از نقش است، فرمت، یا محدودیت؟
- پرامپت را اصلاح و دوباره اجرا کنید.
- وقتی همهی تست‌ها پاس شدند، پرامپت را نسخه‌بندی کنید.
چه معیارهایی برای سنجش کیفیت خروجی پرامپت مناسب‌اند؟#
معیارها به تسک بستگی دارند، اما چند معیار عمومی وجود دارد: صحت فکت (Factuality)، رعایت فرمت (Format Compliance)، پوشش محدوده (Scope Adherence)، و نرخ هالوسینیشن (Hallucination Rate). برای هر معیار یک روش سنجش مشخص تعریف کنید — خودکار یا انسانی.
اثر دمای پرامپت بر تکرارپذیری#
Temperature یک پارامتر است که میزان تصادفی بودن خروجی را کنترل میکند. برای تسک‌های deterministic (استخراج داده، طبقه‌بندی) temperature صفر یا نزدیک صفر لازم است. برای تسک‌های خلاقانه، temperature بالاتر مجاز است. نکته‌ی مهم: حتی با temperature صفر، مدل‌های بزرگ گاهی خروجی متفاوت تولید می‌کنند. تکرارپذیری مطلق وجود ندارد؛ باید تحمل‌پذیری خطا را در test suite تعریف کنید.
بدهی پرامپت: هزینهی پنهانِ تیم‌هایی که نسخه‌بندی نمی‌کنند#
بدهی پرامپت (Prompt Debt) انباشت پرامپتهای بدساختار و بدون تست است. تیم‌هایی که پرامپت‌هایشان را داخل کد hard-code کرده‌اند، پس از هر آپدیت مدل دچار شکست‌های ناگهانی میشوند و وقت بیشتری صرف دیباگ رفتار مدل می‌کنند تا توسعه.
بدهی پرامپت دقیقاً مثل بدهی فنی (Technical Debt) عمل میکند: کوتاه‌مدت سریع‌تر است، بلندمدت گران‌تر. تیمی که پرامپت‌ها را در 15 فایل مختلف hard-code کرده، نمی‌داند کدام پرامپت کجا استفاده می‌شود، کدام تست‌شده، و کدام با مدل جدید سازگار نیست.
نشانه‌های بدهی پرامپت در پروژه‌های واقعی#
- پرامپت‌ها در 5 فایل مختلف با تغییرات جزئی تکرار شده‌اند.
- هیچ‌کس نمی‌داند کدام پرامپت در کدام endpoint استفاده می‌شود.
- پس از آپدیت مدل، چند endpoint همزمان خراب شده‌اند و دیباگ آن‌ها هفته‌ها طول کشیده.
- پرامپت‌ها فقط در محیط staging تست شده‌اند و در production رفتار متفاوت دارند.
- هیچ changelog یا نسخه‌ای برای پرامپت‌ها وجود ندارد.
الگوی نگهداشت در فایل جداگانه + CI/CD#
الگوی مرسوم در پروژه‌های سالم: هر پرامپت در فایل جداگانه (مثلاً prompts/system.md یا prompts/extraction.yaml) نگهداری می‌شود. این فایل‌ها در repo اصلی هستند. یک pipeline خودکار، هر تغییر در فایل‌های prompts/ را با اجرای test suite بررسی میکند. اگر تست پاس نشد، merge بلاک می‌شود.
نسخه‌بندی پرامپت: changelog و rollback#
هر پرامپت یک version دارد. تغییرات در changelog ثبت میشوند. اگر نسخه‌ی جدید در production مشکل ایجاد کرد، rollback به نسخه‌ی قبلی بدون deploy کد انجام می‌شود. این الگو مستقیماً از نسخه‌بندی معنایی (semantic versioning) نرم‌افزار گرفته شده.
ابزارها و پلتفرم‌های مدیریت پرامپت#
ابزارهایی مثل Promptfoo، LangSmith و Humanloop برای مدیریت، تست و پایش (monitoring) پرامپت‌ها استفاده میشوند. انتخاب ابزار بستگی به اندازه‌ی تیم و پیچیدگی سیستم دارد. برای تیم‌های کوچک، یک فایل markdown در repo با یک اسکریپت تست ساده کافی است.
چه زمانی از مهندسی پرامپت دست بردارم و fine-tuning کنم؟#
وقتی پرامپت به‌محدودیت پنجرهی زمینه (Context Window) برخورد میکند، هزینهی توکن در هر فراخوانی توجیه‌ناپذیر است، یا رفتار مدل ذاتاً باید عوض شود — نه فقط در یک لحظه — وقت fine-tuning است. مهندسی پرامپت و fine-tuning جایگزین هم نیستند.
تفاوت بنیادین: پرامپت رفتار مدل را در لحظه تغییر می‌دهد. fine-tuning ذات مدل را عوض میکند. اگر مشکل شما «حرف زدن به سبک خاص» است، پرامپت کافی است. اگر مشکل شما «نداشتن دانش domain-specific» است، پرامپت حلش نمی‌کند.
معیارهای عملی تصمیم‌گیری: حجم داده، هزینهی توکن، تکرارپذیری#
سه سؤال کلیدی:
- آیا پرامپت شما بیش از 30% پنجرهی زمینه را اشباع میکند؟ اگر بله، fine-tuning یا RAG را بررسی کنید.
- آیا هزینهی توکن هر فراخوانی در مقیاس production توجیه‌پذیر است؟ اگر پرامپت 2000 توکن دارد و روزی 100 هزار فراخوانی دارید، هزینهی پرامپت طولانی میتواند از هزینهی fine-tuning بیشتر شود.
- آیا پرامپت بعد از 20 بار iteration هنوز ناپایدار است؟ اگر بله، مشکل از ذات مدل است نه از پرامپت.
تفاوت مهندسی پرامپت با مهندسی زمینه#
مهندسی پرامپت روی طراحی ورودی مدل تمرکز دارد. مهندسی زمینه (Context Engineering) روی مدیریت کل پنجرهی زمینه تمرکز دارد: چه اطلاعاتی، به‌چه ترتیبی، در چه حجمی، و چه چیزی حذف شود. context engineering شامل تصمیمات RAG، حافظه و اولویت‌بندی اطلاعات است. context engineering را زیرمجموعه‌ی مهندسی پرامپت می‌دانند — که دقیق نیست؛ این دو مکملاند، نه سلسلهمراتبی.
مدل‌های مکمل: پرامپت + RAG + fine-tuning در یک سیستم#
در سیستم‌های واقعی، این سه لایه همزمان وجود دارند. fine-tuning ذات مدل را برای domain تنظیم میکند. RAG دانش به‌روز و قابل‌استناد اضافه میکند. مهندسی پرامپت رفتار در لحظه را کنترل میکند. حذف هر لایه اگر نیاز باشد، هزینهی لایه‌ی بعدی را بالا می‌برد.
مهندسی پرامپت یک رشته‌ی مهندسی است با artifact، بدهی، CI و تصمیم‌گیری هزینه‌ای. مستر پرامپت را در فایل جداگانه نگه دارید، test suite بنویسید، و نسخه‌بندی کنید. اگر این سه کار را انجام می‌دهید، پرامپت شما از یک جمله‌ی جادویی به یک قطعه‌ی نرم‌افزار تبدیل شده.
اگر می‌خواهید این تفکر مهندسی را در ساخت ایجنت و اتوماسیون عملی تمرین کنید، دورهی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی اسکول دقیقاً همین مسیر را از پرامپتنویسی تا ساخت ایجنت پوشش می‌دهد.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.