داستان کاربر با پرامپت: چطور دقیق بنویسیم؟

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

داستان کاربر (User Story) یکی از پایه‌ای‌ترین ابزارهای تیم‌های محصول است. اما وقتی همین ابزار را به یک مدل زبانی بزرگ (Large Language Model) می‌سپاریم، تجربه‌ای که در پروژه‌های متعدد دیده می‌شود اغلب ناامیدکننده است: خروجی‌ها یا بیش از حد کلیشه‌ای هستند یا آن‌قدر جزئیات بی‌ربط دارند که تیم توسعه نمی‌داند از کجا شروع کند. مسئله، توانایی مدل نیست. مسئله، ساختار پرامپت است. اگر پرامپت را مثل یک قرارداد فنی طراحی کنیم، خروجی هم مثل یک آرتیفکت قابل استفاده در بکلاگ اسپرینت ظاهر می‌شود. 🎯

داستان کاربر چیست و چرا نوشتن آن با پرامپت دشوار است؟

داستان کاربر (User Story) یک توصیف کوتاه و مبتنی بر زبان روزمره از یک نیاز کاربر است که هدفش ایجاد گفت‌وگو میان تیم محصول و تیم توسعه است؛ نه نوشتن یک سند کامل. قالب کلاسیک آن به این شکل است: «به‌عنوان [نقش]، می‌خواهم [هدف]، تا [منفعت]». اما همین قالب ساده، نقطه‌ای است که اکثر پرامپت‌ها در آن شکست می‌خورند.

دلیل اول این است که مدل زبانی، برخلاف یک تحلیلگر کسب‌وکار، زمینه سازمانی، محدودیت‌های فنی تیم و تاریخچه محصول را نمی‌شناسد. دلیل دوم این است که داستان کاربر بدون معیارهای پذیرش (Acceptance Criteria)، بدون اشاره به وابستگی‌ها و بدون تعیین دامنه (Scope)، فقط یک جمله است؛ نه یک آیتم بکلاگ. دلیل سوم، ابهام در تعریف «کاربر» است: آیا منظور نقش انتزاعی است یا یک شخصیت مشخص با رفتار واقعی؟

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

چرا مدل بدون راهنمایی، نیاز کاربر را حدس می‌زند؟

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

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

ساختار استاندارد یک داستان کاربر

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

1. عنوان (Title) که هدف کاربر را در یک عبارت خلاصه می‌کند.
2. روایت (Narrative) که قالب «به‌عنوان... می‌خواهم... تا...» را دنبال می‌کند.
3. معیارهای پذیرش (Acceptance Criteria) که رفتار قابل‌تست را مشخص می‌کنند.
4. وابستگی‌ها (Dependencies) و پیش‌نیازهای فنی.
5. تعریف آماده بودن (Definition of Ready) و تعریف انجام شدن (Definition of Done).

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

چرا خروجی پرامپت‌های ساده کیفیت پایینی دارند؟

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

نخست: نبود نقش دقیق

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

دوم: نبود محدودیت دامنه

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

سوم: نبود معیار سنجش

مدل نمی‌داند «موفقیت» چه معنایی دارد. بنابراین خروجی، فاقد معیارهای قابل‌تست است و تیم QA نمی‌داند چه چیزی را باید بررسی کند.

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

اصول پرامپت‌نویسی برای داستان کاربر

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

اصل یکم: تعریف نقش کاربر با دقت

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

اصل دوم: تعیین قالب خروجی

قالب خروجی را صریح مشخص کنید. اگر می‌خواهید معیارهای پذیرش به شکل Given/When/Then باشند، همین را در پرامپت بنویسید. اگر می‌خواهید وابستگی‌ها جدا فهرست شوند، همین را بخواهید.

اصل سوم: ارائه زمینه محصول

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

اصل چهارم: تعریف موفقیت

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

اصل پنجم: درخواست ارزیابی خود

از مدل بخواهید خروجی خودش را بر اساس چارچوب INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) ارزیابی کند. این تکنیک، کیفیت خروجی را به‌طور محسوس بالا می‌برد.

پرامپت خوب، پرامپتی نیست که طولانی باشد؛ پرامپتی است که هیچ ابهامی برای مدل باقی نگذارد.

ساختار یک پرامپت مؤثر برای داستان کاربر

ساختار زیر، الگویی است که در پروژه‌های واقعی جواب می‌دهد:

Role: You are a senior product owner.
Context: [محصول، کاربران فعلی، مرحله رشد، محدودیت‌های فنی]
Goal: [هدف کسب‌وکاری مشخص]
Output format:
  1. Title
  2. Narrative (As a... I want... So that...)
  3. Acceptance Criteria (Given/When/Then)
  4. Dependencies
  5. Open questions
Constraints:
  - Story must be INVEST-compliant
  - No more than 5 acceptance criteria
  - Explicitly list out-of-scope items
Self-evaluation: Score the output against INVEST.

این ساختار، چهار مزیت ایجاد می‌کند:

• مدل را از حالت «حدس‌زن» خارج می‌کند.
• خروجی را قابل مقایسه بین چند اجرا می‌کند.
• ارزیابی کیفیت را ممکن می‌سازد.
• زمینه لازم برای بازبینی انسانی را فراهم می‌کند.

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

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

وقتی ساختار پایه تثبیت شد، می‌توان از تکنیک‌های پیشرفته برای افزایش دقت استفاده کرد:

زنجیره تفکر (Chain of Thought)

از مدل بخواهید پیش از نوشتن داستان، مراحل استدلال خود را بنویسد. این کار، خطاهای منطقی را آشکار می‌کند. مثال:

Before writing the story:
1. Identify the primary user role.
2. Identify the real underlying need.
3. Identify the business value.
4. Identify edge cases.
Then write the story.

Self-Consistency

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

In-Context Examples (Few-Shot)

دو نمونه داستان کاربر از پروژه خودتان را در پرامپت قرار دهید. مدل سبک تیم شما را یاد می‌گیرد.

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

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

فهرست زیر، پرتکرارترین خطاهاست:

1. نبود نقش مشخص: استفاده از «کاربر» بدون توصیف دقیق.
2. نبود معیار پذیرش: داستان بدون قابلیت تست، آیتم بکلاگ نیست.
3. دامنه بیش از حد بزرگ: داستانی که در یک اسپرینت جا نمی‌شود.
4. نبود وابستگی‌ها: نادیده گرفتن پیش‌نیازهای فنی.
5. نبود تعریف خارج از دامنه: مدل نمی‌داند چه چیزی را نباید شامل شود.
6. اعتماد کورکورانه به خروجی: خروجی مدل همیشه نیاز به بازبینی انسانی دارد.

این خطاها در سایر حوزه‌های پرامپت‌نویسی هم تکرار می‌شوند. مثلاً در چطور با پرامپت ریسک پروژه را تحلیل کنیم؟ نیز همین الگوهای خطا دیده می‌شود.

مثال‌های عملی پرامپت برای داستان کاربر

در ادامه، سه مثال واقعی از پرامپت‌های مؤثر ارائه می‌شود:

مثال یکم: داستان کاربر برای فرآیند پرداخت

Role: Senior Product Owner with e-commerce experience.
Context: A Persian online store with 3,000 monthly orders.
The current checkout has 7 steps and a 62% abandonment rate.
Goal: Reduce abandonment by simplifying the checkout flow.
Write a user story for the "guest checkout" feature.
Output: Title, Narrative, 4 Acceptance Criteria, Dependencies, Out-of-scope.
Constraints: INVEST-compliant, mobile-first.

مثال دوم: داستان کاربر برای داشبورد فروشنده

Role: Product Owner of a multi-vendor marketplace.
Context: Vendors complain about slow order management.
Goal: Provide a bulk-action dashboard.
Write 3 stories, each focusing on a single action (approve, reject, refund).
Each story must have exactly 3 acceptance criteria.

مثال سوم: داستان کاربر برای جستجوی محصول

Role: Product Owner of an online store.
Context: Users often search with Persian typos.
Goal: Improve search tolerance.
Write a story for "fuzzy search with Persian typo correction".
Include a measurable acceptance criterion (e.g., success rate).

برای دیدن نمونه‌های بیشتر در حوزه نیازهای کاربر، مطلب پرامپت نویسی برای نیازهای کاربر چگونه است؟ پیشنهاد می‌شود.

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

آیا می‌توان داستان کاربر را کاملاً به هوش مصنوعی سپرد؟

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

چه مدلی برای نوشتن داستان کاربر مناسب‌تر است؟

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

آیا تعداد معیارهای پذیرش مهم است؟

بله. بیش از ۵ معیار معمولاً نشانه دامنه بیش از حد بزرگ است. داستان باید کوچک و قابل‌تخمین بماند.

چگونه خروجی را ارزیابی کنیم؟

سه معیار کلیدی: قابلیت تست (Testability)، استقلال (Independence)، و ارزش قابل‌سنجش (Measurable Value).

آیا باید پرامپت را ذخیره کنیم؟

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

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

نکات سطح تیم‌های مهندسی ارشد

در تیم‌های بالغ، پرامپت‌نویسی داستان کاربر به یک فرآیند مهندسی تبدیل می‌شود، نه یک کار موردی. چند نکته:

• نسخه‌بندی پرامپت‌ها: هر پرامپت باید در مخزن مشترک تیم نگهداری شود.
• ارزیابی مستمر: خروجی مدل باید در فواصل زمانی مشخص با معیارهای ثابت ارزیابی شود.
• یکپارچه‌سازی با ابزار مدیریت پروژه: پرامپت‌ها می‌توانند به‌صورت خودکار داستان را در جیرا یا ابزار مشابه ایجاد کنند.
• کنترل کیفیت انسانی: خروجی مدل هرگز نباید بدون بازبینی وارد بکلاگ شود.
• پایش رانش مدل: به‌روزرسانی مدل‌ها می‌تواند کیفیت خروجی را تغییر دهد.

این اصول در سایر فرآیندهای تیم محصول نیز کاربرد دارند؛ برای مثال در پرامپت نویسی برای اسپرینت و رترو چگونه است؟ و چگونه با پرامپت نقشه راه محصول بسازیم؟.

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

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

آنچه در عمل اهمیت دارد

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

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

اگر در پروژه‌ای این روش را پیاده کرده‌اید، برایم جالب است بدانم کدام بخش از پرامپت بیشترین تأثیر را روی کیفیت خروجی داشت. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر چارچوب متفاوتی برای تولید داستان کاربر با هوش مصنوعی دارید که می‌تواند برای خواننده بعدی مفید باشد. ✍️

User Story به‌عنوان یک مفهوم پایه در مهندسی نرم‌افزار، توسط Scrum و Extreme Programming معرفی شد و امروزه پایه اکثر چارچوب‌های مدیریت محصول است.