راهنمای ساده و کامل Prompt Engineering برای مبتدی‌ها

اگر تا حالا با مدل‌های متنی کار کرده‌اید (مثل چت‌بات‌ها) و دیده‌اید گاهی جواب خوب می‌دهند و گاهی نه، مشکل معمولاً خودِ «سؤال شما»ست، نه مدل. در این مقاله با زبان کاملاً ساده می‌فهمیم Prompt Engineering یعنی چه، چطور سؤال‌هایمان را درست بنویسیم و با چند تکنیک مهم، جواب‌ها را دقیق‌تر و قابل‌اعتمادتر کنیم.

Prompt Engineering یعنی چه و چرا مهم است؟

اسم Prompt Engineering (مهندسی پرامپت) ممکن است ترسناک به نظر برسد؛ انگار یک‌سری فوت‌وفن مخفی و کلمه‌جادویی دارد. اما طبق منبع، ماجرا این‌طور نیست.

ایده اصلی این است: پرامپت نوشتن در واقع «فکر کردنِ با ساختار» است. یعنی شما فکرها و خواسته‌هایتان را مرتب و واضح روی متن می‌آورید تا مدل بهتر بفهمد چه می‌خواهید.

مدل فقط متنِ ورودی شما را می‌بیند؛ از نیت و ذهن شما خبر ندارد. مثل این است که برای یک همکار توضیح می‌دهید چه کار کند، با این تفاوت که همکار می‌تواند سؤال بپرسد، اما مدل نه. پس باید همان اول، مسئله، هدف و محدودیت‌ها را تا حد ممکن روشن بگویید.

کسی که پرامپت را خوب می‌نویسد، لزوماً رمز مخفی بلد نیست؛ فقط واضح فکر می‌کند و واضح می‌نویسد. تمام هنر Prompt Engineering همین است.

سه بخش اصلی یک پرامپت خوب

طبق منبع، تقریباً هر پرامپت خوبی سه بخش اصلی دارد. این سه بخش کمک می‌کند سؤال‌هایتان از حالت «گنگ» دربیاید و خروجی کمتر شانسی باشد.

۱. بخش «زمینه» یا Context: مدل باید چه چیزهایی بداند؟

Context یعنی اطلاعات پس‌زمینه‌ای که لازمه مدل بفهمد دقیقاً در چه موقعیتی هستید و با چه داده یا مشکل کار می‌کنید.

مثال‌های زمینه:

• نقش یا تخصصی که می‌خواهید مدل داشته باشد؛ مثلاً: «تو یک برنامه‌نویس ارشد پایتون هستی که می‌خواهد کد را بررسی کند.»
• اطلاعات مهم درباره کاری که می‌کنید؛ مثلاً: «این API (رابط برنامه‌نویسی) جواب را به صورت JSON با فیلدهای X، Y، Z برمی‌گرداند.»
• وضعیت فعلی؛ مثلاً: «این تابعی است که تا حالا نوشته‌ام.»

اگر زمینه را ندهید، مدل مجبور می‌شود حدس بزند. ممکن است فرض کند تازه‌کار هستید، یا فکر کند درباره موضوع دیگری حرف می‌زنید. یک‌ذره زمینه‌دادن، جلوی خیلی از این حدس‌های اشتباه را می‌گیرد.

نمونه زمینه در منبع:

«من دارم برای یک اپ انجام کارها (todo app) یک REST API می‌سازم. هر کار (task) این فیلدها را دارد: id، title، completed، createdAt. از Express.js و PostgreSQL استفاده می‌کنم.»

۲. بخش «دستور» یا Instruction: دقیقاً چه کاری از مدل می‌خواهید؟

Instruction یعنی خواسته اصلی شما. این قسمت باید شفاف باشد، نه کلی.

مثلاً:

• به‌جای «این متن را بهتر کن»، بگویید «این متن را کوتاه‌تر کن و جملات طولانی را به چند جمله ساده‌تر تبدیل کن».
• به‌جای «این کد را درست کن»، بگویید «اشتباه‌های منطقی این تابع را پیدا کن و نسخه اصلاح‌شده را بنویس.»

یک دستور خوب معمولاً شامل این‌هاست:

• نوع کار: مثل خلاصه‌کردن، بازنویسی، رفع‌اشکال، تولید محتوا، پیشنهاد ایده و…
• دامنه کار: روی کدام متن، کدام تابع، کدام لیست؟
• نوع خروجی: مثلاً «به صورت بولت‌پوینت (لیست نقطه‌ای) جواب بده»، یا «خروجی را در قالب JSON بده».

نمونه دستور در منبع:

«تابع validateEmail زیر را بررسی کن. فهرست تمام حالت‌های خاصی (edge cases) را که این تابع درست پوشش نمی‌دهد بنویس، بعد یک نسخه بهتر از این تابع پیشنهاد بده که آن حالت‌ها را هم پوشش دهد. جواب را این‌طور بده: ۱) یک لیست بولت از حالت‌های خاص، ۲) کد بهبود‌یافته.»

۳. بخش «محدودیت‌ها» یا Constraints: خط قرمزها و چارچوب‌ها

Constraints یعنی چیزهایی که می‌خواهید مدل رعایت کند یا از آن‌ها دوری کند. این بخش، خروجی را به سمت چیزی که واقعاً به درد شما می‌خورد، هدایت می‌کند.

انواع رایج محدودیت‌ها:

• طول: مثلاً «کمتر از ۲۰۰ کلمه» یا «فقط یک پاراگراف».
• لحن: مثلاً «مؤدب و حرفه‌ای ولی صمیمی» یا «بدون اصطلاحات سخت».
• فرمت: مثل «فقط JSON، بدون توضیح اضافه» یا «به صورت لیست نقطه‌ای».
• چیزهایی که نمی‌خواهید: مثلاً «از هیچ کتابخانه خارجی استفاده نکن» یا «از APIهای منقرض‌شده استفاده نکن».

نمونه محدودیت در منبع:

«یک ایمیل خوش‌آمدگویی کوتاه برای کاربران تازه بنویس. لحن: گرم ولی نه آبکی. طول: ۳ تا ۴ جمله. از قیمت و فروش چیز دیگری حرف نزن.»

ترکیب سه بخش در یک پرامپت کامل

وقتی زمینه، دستور و محدودیت را کنار هم بگذارید، یک پرامپت کامل‌تر به دست می‌آید.

نمونه‌ای که منبع می‌دهد:

زمینه: «من یک توسعه‌دهنده رابط کاربری هستم که تازه دارد React یاد می‌گیرد. یک کامپوننت دارم که داده‌های کاربر را می‌گیرد و نشان می‌دهد. گاهی API، مقدار user را null برمی‌گرداند.»

دستور: «توضیح بده چرا کامپوننت من وقتی user برابر null است ممکن است کرش (از کار افتادن) کند، و نشان بده چطور می‌توانم با استفاده از optional chaining یا یک guard clause (یعنی شرط اولیه برای جلوگیری از اجرا در حالت خطرناک) مشکل را حل کنم. یک جمله هم بگو کدام روش را ترجیح می‌دهی و چرا.»

محدودیت: «فقط از کامپوننت‌های تابعی (functional components) و hooks استفاده کن. از کلاس‌ها استفاده نکن. توضیح را زیر ۱۰۰ کلمه نگه‌دار.»

در این مثال، مدل دقیقاً می‌داند:

• با چه تکنولوژی و چه مشکلی طرف است (زمینه).
• چه باید انجام دهد و در چه قالبی جواب بدهد (دستور).
• چه چیزهایی مجاز نیست و چه محدودیت‌هایی وجود دارد (محدودیت).

اشتباه‌های رایج در پرامپت نوشتن

منبع چند خطای مهم را نام می‌برد که خیلی‌ها ناخواسته انجام می‌دهند و نتیجه را خراب می‌کند.

۱. فکر کردن این‌که مدل «حدس می‌زند» شما چه می‌خواهید

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

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

۲. پنهان کردن بخش مهم وسط متن طولانی

طبق منبع، مدل‌ها معمولاً به اول و آخر متن بیشتر توجه می‌کنند. اگر نکته اصلی پرامپت را وسط یک پاراگراف بزرگ بنویسید، ممکن است وزنش کمتر شود.

راه بهتر این است که:

• دستور اصلی را یا خیلی اول متن بگویید،
• یا اگر متن طولانی است، آخرِ پرامپت دوباره به‌طور خلاصه تکرارش کنید.

۳. خواستن چند کار متفاوت در یک پرامپت

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

منبع توصیه می‌کند کارهای پیچیده را مرحله‌به‌مرحله جلو ببرید: اول خلاصه، بعد بازنویسی، بعد اصلاح لحن و… هر مرحله را در یک پرامپت جدا بپرسید و نتیجه را پایه مرحله بعدی کنید.

۴. فراموش کردن محدودیت‌های خود مدل

مدل‌ها بسته به آموزش‌شان، روی بعضی چیزها قوی‌تر و روی بعضی چیزها ضعیف‌ترند. منبع چند نکته عمومی می‌گوید:

• مدل‌ها با ساختارهای واضح، الگوهای رایج و حوزه‌هایی که خوب مستند شده‌اند، معمولاً راحت‌تر کار می‌کنند.
• با موضوعات خیلی خاص و تخصصی، عددهای دقیق و چیزهایی که نیاز به داده لحظه‌ای یا خصوصی (مثل دیتابیس شخصی شما) دارند، مشکل بیشتری دارند.

پرامپت‌تان را جوری طراحی کنید که مدل مجبور نباشد کارهایی کند که از توانش خارج است؛ مثلاً به جای «از دیتابیس من گزارش بده»، بگویید «با توجه به این داده‌هایی که در متن می‌فرستم، آن‌ها را تحلیل کن.»

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

منبع چند روش پیشرفته معرفی می‌کند که کمک می‌کند مدل، مخصوصاً در کارهای فکری و چندمرحله‌ای، بهتر جواب بدهد.

Chain of Thought یا «فکر کردن مرحله‌به‌مرحله»

Chain of Thought (که خیلی‌ها به‌اختصار CoT می‌گویند) یعنی شما از مدل می‌خواهید اول منطق و مراحل فکرش را بنویسد و بعد جواب نهایی را بدهد.

مثلاً در یک مسئله ریاضی یا منطقی، به‌جای این‌که فقط بپرسید «جواب چیست؟»، می‌گویید:

«مرحله‌به‌مرحله فکر کن و توضیح بده، بعد در آخر جواب نهایی را بنویس.»

نمونه‌ای که منبع می‌دهد:

«این را حل کن: یک فروشگاه سیب را دانه‌ای ۲ دلار و پرتقال را دانه‌ای ۳ دلار می‌فروشد. اگر ۵ سیب و ۳ پرتقال بخرم، چقدر باید پرداخت کنم؟ منطق خودت را مرحله‌به‌مرحله توضیح بده، بعد جواب نهایی را بنویس.»

این روش کمک می‌کند مدل «کارها را روی کاغذ» انجام دهد، نه این‌که یک‌باره از صفر به جواب بپرد. همین باعث می‌شود در کارهای چندمرحله‌ای، دقت معمولاً بهتر شود.

Few-Shot Learning: یاد دادن با چند مثال

Few-Shot یعنی قبل از این‌که از مدل کاری بخواهید، چند نمونه «ورودی→خروجی» به او نشان می‌دهید تا بفهمد دقیقاً چه الگو و سبک پاسخ را دوست دارید.

مثلاً اگر می‌خواهید همیشه جملات‌تان را به «Title Case» تبدیل کند (یعنی اول هر کلمه بزرگ باشد)، می‌توانید چند نمونه بدهید:

نمونه‌های منبع:

• Input: «the quick brown fox»
  Output: «The Quick Brown Fox»
• Input: «hello world from python»
  Output: «Hello World From Python»
• Input: «a tale of two cities»
  Output: «A Tale of Two Cities»

بعد از این مثال‌ها، ورودی جدید خودتان را می‌دهید و از مدل می‌خواهید خروجی را با همان الگو تنظیم کند. این کار مخصوصاً برای:

• فرمت‌های ثابت (مثلاً همیشه یک نوع لیست یا جدول)،
• لحن‌های خاص در یک حوزه،
• یا کارهایی که توضیح‌دادن‌شان با کلمات سخت است،

خیلی کمک می‌کند.

System Prompt: تعیین رفتار کلی مدل (وقتی امکانش هست)

در بعضی ابزارها، یک بخش جدا وجود دارد که می‌توانید در آن «دستور کلی» برای رفتار مدل تعیین کنید. به این متنِ کلی می‌گویند System Prompt.

System Prompt کاری می‌کند که مدل در کل گفت‌وگو، طبق یک نقش و لحن مشخص رفتار کند؛ مثلاً همیشه ساده توضیح بدهد، همیشه مثال بزند یا همیشه کوتاه جواب بدهد.

نمونه‌ای که منبع می‌دهد:

«تو یک نویسنده فنی هستی. مفاهیم را واضح توضیح می‌دهی، مثال می‌زنی و از اصطلاحات سخت فقط وقتی استفاده می‌کنی که لازم است. وقتی از اصطلاح سخت استفاده می‌کنی، آن را تعریف می‌کنی. جواب‌هایت کوتاه ولی کامل است. اگر کاربر کد خواست، توضیح کوتاهی داخل کد می‌گذاری.»

وقتی چنین System Promptی داشته باشید، دیگر لازم نیست در هر پرامپت عادی دوباره همه این چیزها را تکرار کنید؛ فقط خودِ کار را می‌گویید.

چطور با شناخت مدل، پرامپت بهتری بنویسیم؟

منبع یادآوری می‌کند که مدل‌ها، در اصل، فقط «حدس بعدی» می‌زنند: هر بار یک واحد متن (توکن) را با توجه به قبلی‌ها حدس می‌زنند و جلو می‌روند. آن‌ها از قبل یک برنامه کامل در ذهن ندارند.

این شناخت چند نتیجه مهم دارد:

• کم‌کردن ابهام: اگر پرامپت شما جا برای چند تفسیر مختلف داشته باشد، مدل ممکن است یک مسیر اشتباه را انتخاب کند. با توضیح بیشتر، تعداد مسیرهای «ممکن» را کم کنید.
• دادن ساختار: وقتی می‌گویید «در سه بخش جواب بده: ۱) خلاصه، ۲) تحلیل، ۳) نتیجه»، کار مدل راحت‌تر می‌شود چون فرم جواب از قبل مشخص است.
• خُرد کردن کارهای بزرگ: اگر از مدل بخواهید یک کار عظیم را یک‌جا انجام دهد، باید اطلاعات زیادی را هم‌زمان نگه دارد. تقسیم کار به چند مرحله، فشار را کم می‌کند.
• تکیه بر چیزهای «معلوم»: مثلاً به‌جای «در مورد این پروژه من نظر بده»، کد یا متن پروژه را برایش می‌فرستید تا روی یک چیز مشخص نظر دهد.

به‌طور خلاصه، کسی که پرامپت خوب می‌نویسد، همیشه از خودش می‌پرسد: «چطور می‌توانم حدسِ بعدی مدل را برایش آسان‌تر و روشن‌تر کنم؟» و بر اساس همان، متن پرامپت را طراحی می‌کند.

چطور پرامپت را بهتر کنیم؟ رویکرد «شروع ساده و اصلاح مرحله‌ای»

منبع تأکید می‌کند که لازم نیست از همان اول، پرامپتی کامل و پیچیده بنویسید. بهترین روش این است که:

1. با سه بخش اصلی شروع کنید: زمینه، دستور، محدودیت.
2. خروجی را ببینید و بررسی کنید کجاها مطابق انتظار نیست.
3. یک بخش را در هر بار اصلاح کنید: مثلاً اگر زمینه ناقص بوده، کمی اطلاعات اضافه کنید؛ اگر دستور گنگ بوده، واضح‌ترش کنید؛ یا اگر محدودیت‌ها خیلی سخت یا خیلی آزاد بوده، تنظیم‌شان کنید.

این کار مثل نوشتن یک نسخه اولیه و بعد ویرایش است. پرامپت هم «پیش‌نویس» دارد و با تجربه بهتر می‌شود.

سؤالات متداول

آیا برای Prompt Engineering باید برنامه‌نویسی بلد باشم؟

در منبع، تمرکز بیشتر روی مثال‌های فنی است، ولی خودِ مفهوم Prompt Engineering به برنامه‌نویسی وابسته نیست. اصل ماجرا این است که بتوانید فکر خودتان را منظم، شفاف و مرحله‌به‌مرحله روی متن بیاورید. منبع فقط می‌گوید کسانی که واضح فکر می‌کنند، نتیجه بهتری می‌گیرند؛ لازم نیست برنامه‌نویس حرفه‌ای باشید.

اگر همه چیز را در یک پرامپت بنویسم، حتماً بهتر است؟

منبع می‌گوید نه؛ کارهای زیاد در یک پرامپت، کیفیت هر کار را پایین می‌آورد. بهتر است وظایف مختلف را جدا کنید و برای هر کدام پرامپت مستقل داشته باشید. این توصیه مخصوصاً وقتی مهم است که چند نوع خروجی و چند فرمت مختلف می‌خواهید.

چطور بفهمم زمینه کافی داده‌ام یا نه؟

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

استفاده از Chain of Thought همیشه بهتر است؟

منبع فقط می‌گوید Chain of Thought برای کارهایی که نیاز به استدلال و چند مرحله فکر دارد، معمولاً خروجی را دقیق‌تر می‌کند؛ اما نگفته که همیشه لازم است. برای کارهای ساده مثل «متن را کوتاه کن»، معمولاً نیازی به توضیح مرحله‌به‌مرحله نیست.

اگر ابزار من System Prompt نداشته باشد، چه کار کنم؟

منبع فقط درباره جاهایی صحبت می‌کند که System Prompt در دسترس است. اگر در ابزار شما چنین بخشی وجود ندارد، می‌توانید همان دستورهای کلی رفتار (مثلاً «ساده توضیح بده، مثال بزن») را ابتدای هر پرامپت عادی بنویسید. منبع روش دیگری معرفی نکرده است.

جمع‌بندی و نکته کاربردی

در این مقاله دیدیم Prompt Engineering یک چیز جادویی یا پر از رمز مخفی نیست؛ در اصل یعنی فکرهای خودتان را منظم، واضح و مرحله‌دار روی متن بیاورید تا مدل دقیق‌تر بفهمد چه می‌خواهید. سه بخش زمینه، دستور و محدودیت ستون فقرات هر پرامپت خوب هستند.

یادتان باشد اشتباه‌های رایج مثل کلی‌گویی، قاطی‌کردن چند کار در یک پرامپت و پنهان کردن دستور مهم وسط متن، به‌راحتی کیفیت خروجی را پایین می‌آورد. با تکنیک‌هایی مثل Chain of Thought و Few-Shot می‌توانید برای کارهای پیچیده و فرم‌های خاص، مدل را بهتر راه بیندازید.

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