چرا فهمیدن Problem قبل از Prompt مهم‌تر است؟

بیشتر شکست‌های کار با مدل زبانی از «مدل بد» نیست؛ از این است که خودمان هنوز نمی‌دانیم موفقیت چیست، بعد از مدل می‌خواهیم آن را حدس بزند. پرامپت مبهم مثل سپردن کار به کارآموز روز اول بدون زمینه، قالب و معیار قبول است.

راهنمای رسمی OpenAI برای کاربران سازمانی دقیقاً همین را می‌گوید: قبل از نوشتن، مسئله را scope کنید — یک خروجی مشخص، زمینه لازم، قالب، و تعریف «خوب». این مقاله همان اصل را برای کار روزمرهٔ نرم‌افزار و دانش ترجمه می‌کند.

پاسخ کوتاه

اول مسئله را تا جایی که بتوانید در دو جمله تعریف موفقیت و مرز کار را بگویید؛ بعد پرامپت بنویسید. اگر «خوب» را خودتان نمی‌توانید توصیف کنید، مدل هم نمی‌تواند پایدار بزند. پرامپت ابزار اجرای تعریف شماست، نه جایگزین فکر کردن به Problem.

پرامپت بدون مسئلهٔ روشن، فقط تولید متن با اعتماد کاذب است.

Problem چیست و Prompt چیست؟

Problem همان نیاز واقعی است: باگ با اثر کاربر، تصمیم محصول، خلاصه برای مدیر، یا استخراج ساختار از سند. Prompt واسطه‌ای است که آن نیاز را برای مدل قابل‌اجرا می‌کند. اگر Problem ناقص باشد، بهتر کردن واژه‌های Prompt معمولاً فقط ظاهر را بهتر می‌کند نه تصمیم‌پذیری را.

نشانهٔ Problem ناقص: هر بار خروجی را «حسّی» رد می‌کنید بدون اینکه بگویید کدام معیار نقض شده؛ یا پرامپت را هی طولانی‌تر می‌کنید تا همهٔ کارها را یک‌جا بخواهد.

چهار سؤال scoping قبل از اولین پرامپت

از الگوی OpenAI Enterprise Prompting Guide:

1. چه زمینه‌ای باید به مدل بدهم تا کار را بفهمد؟ (فایل، API، مخاطب، محدودیت دامنه)
2. تک‌خروجی مورد نظر چیست؟ (خلاصه ۳۰۰ کلمه‌ای، Diff، جدول JSON، پیش‌نویس ایمیل)
3. قالب و تنظیمات غیرقابل‌مذاکره کدام‌اند؟ (طول، لحن، منابع مجاز، ممنوعیت‌ها)
4. با چه چک‌لیستی می‌گویم خوب است؟ (دقت، کامل بودن، ساختار، فرض‌های برچسب‌خورده)

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

چرا یک پرامپت نباید «همه‌کار» باشد؟

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

در مهندسی نرم‌افزار همین اتفاق می‌افتد وقتی می‌نویسید: «کل ماژول پرداخت را بازآرایی کن، تست بنویس، مستند کن، و امنیت را هم درست کن». بهتر است به پرامپت‌های متوالی با تک‌خروجی بشکنید: اول نقشهٔ ریسک، بعد Diff محدود، بعد تست.

الگوی عملی: Context → Instructions → Constraints

ساختار پیشنهادی رسمی (قابل‌تنظیم):

markdown

# Context چه کاری می‌کنید و مدل چه چیزی باید بداند. # Instructions دقیقاً چه خروجی واحدی می‌خواهید. # Additional info / Constraints قالب، مخاطب، ممنوعیت‌ها، معیار قبول، منابع مجاز.

Anthropic و Google هم روی وضوح دستور، مثال، و شکستن کار توافق دارند. تفاوت فروشندگان در جزئیات مدل است؛ اصل scoping مشترک است.

مثال ضعیف در برابر مثال scoped

ضعیف

این سرویس را بهتر کن و اگر لازم بود معماری را هم عوض کن.

بهتر (بعد از فهم Problem)

markdown

# Context سرویس invoice-api روی FastAPI؛ کندی در endpoint ایجاد فاکتور گزارش شده. هدف نسخه: کاهش p95 بدون تغییر قرارداد API عمومی. # Instructions 1) سه فرضیهٔ محتمل گلوگاه را فهرست کن. 2) فقط برای محتمل‌ترین فرضیه یک Diff محدود پیشنهاد بده. # Constraints - فقط مسیرهای app/invoices/* - بدون وابستگی جدید - خروجی: فرضیه‌ها + unified diff - اگر داده کافی نیست، بنویس needs verification

اینجا Problem روشن است: کندی p95 در یک endpoint، با مرز عدم‌شکستن قرارداد. Prompt فقط آن را اجرایی می‌کند.

Problem در محصول در برابر Problem در کد

نشانه‌هایی که باید پرامپت را متوقف و مسئله را بازنویسی کنید

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

Meta-prompting: کمک گرفتن از مدل برای روشن کردن مسئله

OpenAI meta-prompting را توصیه می‌کند وقتی ایده دارید اما صورت‌بندی ندارید: پیش‌نویس درهم را بدهید و بخواهید سؤال بپرسد، شکاف‌ها را پیدا کند، و پرامپت تمیز با سه بخش بسازد. اما اگر مشکل کمبود سند منبع است یا خود نیاز نامشخص است، meta-prompt جایگزین scoping انسانی نمی‌شود.

قانون: مدل می‌تواند به شما در نوشتن دستور کمک کند؛ نمی‌تواند به‌جای شما تصمیم بگیرد مسئلهٔ کسب‌وکار چیست.

اتصال به Acceptance Criteria و Definition of Done

اگر در اسکرام معیار پذیرش دارید، همان را خام وارد بخش Constraints کنید. مدل معیار نانوشته را حدس نمی‌زند. این کار پرامپت را به کارت بکهالگ قفل می‌کند و Review را ساده‌تر می‌سازد — هم‌راستا با عادت هرگز بدون Review منتشر نکنید در مقالهٔ ۱۲۹.

چک‌لیست ۳۰ ثانیه‌ای قبل از ارسال

1. آیا یک خروجی واحد دارم؟
2. آیا مخاطب و قالب مشخص است؟
3. آیا منبع یا زمینهٔ لازم پیوست شده؟
4. آیا معیار قبول در دو جمله هست؟
5. آیا چیزهایی که نباید انجام شود نوشته شده؟

اشتباه‌های رایج

• شروع با نقش‌بازی طولانی به‌جای تعریف کار.
• چسباندن کل مخزن بدون گفتن سؤال.
• درخواست کامل و کوتاه و خلاق و دقیق هم‌زمان بدون اولویت.
• تغییر مدل به‌جای روشن کردن مسئله وقتی خروجی بد است.

ارتباط با مقالات مرتبط

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

اگر عجله دارم، scoping را رد کنم؟

برای کار کم‌ریسک و برگشت‌پذیر گاهی پرامپت سریع کافی است. برای متن مشتری، کد production، یا تصمیم مالی، ۳۰ ثانیه scoping ارزان‌تر از ۳۰ دقیقه پاکسازی است.

آیا همیشه باید سه هدر markdown داشته باشم؟

نه؛ ساختار توصیه است نه قالب اجباری. مهم این است که زمینه، کار، و قید در متن از هم قابل‌تفکیک باشند.

فرق scoping با نوشتن پرامپت طولانی چیست؟

Scoping کم کردن دامنه و تعریف موفقیت است. پرامپت طولانی گاهی دامنه را بزرگ‌تر و متناقض می‌کند.

از مسئلهٔ مبهم تا بریف یک‌صفحه‌ای

یک تمرین مفید قبل از پرامپت: بریف نیم‌صفحه‌ای بنویسید که انسان همکار بتواند بدون سؤال اضافه کار را شروع کند. اگر همکارتان گیج می‌شود، مدل هم گیج می‌شود — فقط مؤدبانه‌تر اشتباه می‌کند.

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

سپس همان بریف را به هدرهای Context / Instructions / Constraints نگاشت کنید. این ترجمه معمولاً کمتر از پنج دقیقه طول می‌کشد و از سه دور اصلاح بی‌هدف جلوگیری می‌کند.

لایه‌بندی کار: کشف، تصمیم، اجرا

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

پیشنهاد عملی: برای هر مرحله یک نشست جدا. خروجی کشف را خودتان تأیید کنید، بعد پرامپت تصمیم را با گزینه‌های محدود بفرستید، بعد اجرای کوچک را با قید فایل و تست بخواهید. مقالهٔ ۱۲۹ همین روح را برای انتشار دارد؛ اینجا همان روح را به خودِ پرامپت می‌آورید.

مثال دوم: پشتیبانی و منبع حقیقت

پرامپت ضعیف پشتیبانی: «به مشتری جواب بده». Problem ناقص است چون سیاست برگشت، لحن برند، و منبع حقیقت مشخص نیست.

بعد از scoping: مشتری می‌پرسد آیا کالای بازشده ظرف ۱۴ روز قابل برگشت است؛ منبع حقیقت صفحهٔ سیاست ۱۴۰۳ است؛ لحن آرام و کوتاه؛ اگر سیاست ساکت بود بگو needs verification و سؤال را برای انسان علامت بزن. حالا Prompt می‌تواند دقیق باشد و hallucinate کمتر آسیب بزند.

مثال سوم: تحلیل داده بدون سؤال کسب‌وکار

درخواست «از این CSV بینش بده» مسئله نیست؛ تور ماهیگیری است. سؤال کسب‌وکار می‌تواند این باشد: «در ۹۰ روز گذشته کدام سه SKU بیشترین نرخ مرجوعی را داشته و آیا با تغییر تأمین‌کننده هم‌زمان بوده؟» خروجی واحد: جدول سه ستونی + دو هشدار دربارهٔ کمبود داده. بدون این، مدل داستان می‌سازد.

ضدالگوی «پرامپت هرچه طولانی‌تر بهتر»

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

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

نقش تیم: چه کسی مسئله را مالک است؟

در تیم‌های محصول، مالک Problem معمولاً PM یا صاحب دامنه است؛ مالک Prompt ممکن است مهندس یا همان PM باشد. اگر کسی مسئله را امضا نکند، پرامپت‌نویسی به مسابقهٔ سلیقه تبدیل می‌شود. یک خط در کارت کار کافی است: «موفقیت یعنی …؛ خارج از محدوده یعنی …».

این تفکیک با مقالهٔ ۱۳۷ هم می‌خواند: شغل پایدار روی مالکیت مسئله و سیستم است، نه روی بازی با واژه‌ها.

اندازه‌گیری اینکه scoping کمک کرده یا نه

• تعداد دورهای اصلاح تا قبول خروجی.
• نرخ موارد needs verification که درست علامت خورده‌اند.
• زمان Review انسانی روی Diff یا متن.
• تعداد دفعاتی که مدل خارج از محدوده رفته است.

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

تمرین پانزده‌دقیقه‌ای

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

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

خلاصه

فهم Problem قبل از Prompt یعنی تعریف موفقیت، تک‌خروجی، زمینه، و قیدها پیش از اولین ارسال. راهنماهای رسمی OpenAI، Anthropic و Google همه به وضوح و محدودهٔ کار تکیه می‌کنند. اول فکر و مرز، بعد دستور؛ بعد راستی‌آزمایی (مقالهٔ ۱۳۹).

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

منابع و مراجع

• OpenAI Cookbook — ChatGPT Enterprise Prompting Guide — https://developers.openai.com/cookbook/examples/chatgpt/chatgpt_prompt_guide/chatgpt_prompt_guide
• OpenAI — Prompt engineering — https://developers.openai.com/api/docs/guides/prompt-engineering
• Anthropic — Prompting best practices — https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices
• Google AI — Prompt design strategies (Gemini API) — https://ai.google.dev/gemini-api/docs/prompting-strategies