۱۰ پرامپت عملیاتی برای جایگزینی مستندات فرآیندی کلی

اگر ساعت‌ها وقت خود را صرف نوشتن مستنداتی می‌کنید که هیچ‌کس نمی‌خواند، احتمالاً مشکل از ابزار شما نیست، بلکه از lack of specificity در دستوراتتان است. مدیران عملیات معمولاً ۶۰٪ زمان نویسندگی خود را صرف پیشگیری از هرج‌ومرج می‌کنند، اما خروجی‌های کلی هوش مصنوعی اغلب به دلیل نادیده گرفتن محدودیت‌های دنیای واقعی، بلااستفاده می‌مانند.

طبق گزارشی که ۳۰ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، رمز دستیابی به مستندات کاربردی در یک چارچوب چهاربخشی نهفته است: نقش، زمینه، محدودیت‌ها و خروجی. هوش مصنوعی زاینده (Generative AI) — مثل دستیاری است که هرچه دقیق‌تر به او بگویید چه چیزی را «نباید» بنویسد، نتیجه‌ی حرفه‌ای‌تری می‌گیرد — در این سیستم از حالت یک نویسنده ساده به یک «مجری ساختاری» تبدیل می‌شود. این رویکرد ساختاری در حوزه‌های دیگر نیز به ثمر نشسته است؛ برای مثال، استفاده از چارچوبی مشابه برای حذف ساعات تحلیل مالی نشان می‌دهد که نظم در پرامپت‌نویسی چگونه بهره‌وری مدیران ارشد را متحول می‌کند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی جریان‌های کاری با مدل‌های زبانی اشاره کردیم، تفاوت میان یک متن تبلیغاتی و یک سند عملیاتی در «محدودیت‌ها» است. به طور مثال، درخواست ساده برای «نوشتن یک SOP جذب نیروی جدید» فهرستی کلی می‌دهد که برای هر شرکتی در هر صنعتی کاربرد دارد. اما با حذف مقدمات و اجبار مدل به تحلیل حالت‌های شکست (Failure-mode analysis)، سندی خلق می‌شود که در فشار عملیاتی واقعی دوام می‌آورد.

چارچوب پرامپت‌های با کاربرد بالا

هر پرامپت در این سیستم از ساختار سخت‌گیرانه‌ی زیر پیروی می‌کند تا تداوم و قابلیت اطمینان تضمین شود. این روش نه یک مهندسی پرامپت (Prompt Engineering) پیچیده — که شبیه هنر سؤال درست پرسیدن برای گرفتن بهترین جواب از یک مشاور است — بلکه کاربرد منظمِ «جزئی‌نگری» است:

• نقش (Role): تعریف دقیق هویت مدل (مثلاً مدیر تدارکات یا مهندس ارشد عملیات).
• زمینه (Context): موقعیت خاص یا داده‌های خام (مثلاً یک رشته گفتگو در اسلک).
• محدودیت‌ها (Constraints): قوانین سخت‌گیرانه درباره آنچه مدل نباید انجام دهد. اینجا جایی است که ارزش خلق می‌شود.
• خروجی (Output): قالب دقیق مورد نیاز، بدون حاشیه، پیام خوش‌آمدگویی یا مقدمات.

۱۰ پرامپت تخصصی عملیاتی

۱. SOP با پذیرش بالا: برای فرآیندهای تکرارشونده مثل «تجهیز لپ‌تاپ نیروی جدید».

• هر گام باید با یک فعل شروع شود (مثلاً: کلیک کنید، ارسال کنید).
• منطق تصمیم‌گیری باید در قالب «اگر [شرط] آنگاه [اقدام] در غیر این صورت [اقدام]» باشد.
• هر ۵ گام یک «نقطه بازرسی» (Checkpoint) برای تأیید مسیر قرار می‌گیرد.
• بخش پایانی با عنوان «این فرآیند زمانی غلط است که:» سه حالت شکست را فهرست می‌کند.

۲. تبدیل اسلک به دفترچه راهنما (Runbook): تبدیل گفتگوهای پراکنده حوادث به ابزاری برای پاسخ‌دهندگان بعدی.

• فقط اقدامات انجام شده را استخراج می‌کند و شوخی‌ها یا پیام‌های «در حال بررسی هستم» را حذف می‌کند.
• اقدامات را در ۵ فاز دسته‌بندی می‌کند: تشخیص $\to$ تریاژ $\to$ کاهش اثر $\to$ رفع مشکل $\to$ کالبدشکافی.
• هر اقدام شامل «چه کسی»، «چه کاری» و «برچسب زمانی» است.
• مسیرهای بن‌بست (اقداماتی که جواب ندادند) در بخش «بن‌بست‌ها» قرار می‌گیرند تا درس عبرت شوند.

۳. کارت امتیازدهی تأمین‌کنندگان: برای ارزیابی بدون سوگیریِ ویژگی‌های جذاب اما غیرضروری.

• دقیقاً ۸ معیار با مجموع ۱۰۰ امتیاز؛ هیچ معیاری نباید بیش از ۲۰ امتیاز داشته باشد تا یک عامل بر کل تصمیم مسلط نشود.
• حداقل ۲ معیار باید مبتنی بر ریسک (مثل پایداری مالی یا انتقال داده‌ها) باشند.
• برای هر معیار، تعریف دقیق امتیاز ۵/۵ و ۱/۵ ارائه می‌شود.
• قانون تصمیم‌گیری سخت: «اگر مجموع $\ge$ ۷۰ و هیچ معیار ریسکی زیر ۳ نبود، وارد مذاکره قرارداد شوید».

۴. چک‌لیست‌های آنبوردینگ ضد-هرج‌ومرج: تبدیل فرآیند ورود به سازمان برای نقش‌های خاص (مثلاً مهندس بک‌ند جونیور).

• تقسیم‌بندی زمانی: روز اول (تنظیمات)، هفته اول (تطبیق)، هفته ۲ تا ۴ (اولین مشارکت).
• تخصیص مسئولیت به [نیروی جدید]، [مدیر]، [IT] یا [همکار راهنما].
• دقیقاً ۳ مورد اجتماعی (مثل ناهار تیمی یا گپ قهوه) اجباری است.
• مسیرهای بحرانی با علامت «$\to$ مسدود می‌کند: [نام آیتم]» مشخص می‌شوند.

۵. سند تصمیم‌گیری تک‌صفحه‌ای: جایگزینی اسناد ۵ صفحه‌ای که هیچ‌کس نمی‌خواند (حداکثر ۲۵۰ کلمه).

• بخش‌های اجباری: تصمیم (یک جمله بدون تردید)، زمینه (حداکثر ۳ جمله)، گزینه‌ها (دقیقاً ۳ گزینه با یک مزایا و یک عیب)، منطق (بر اساس موازنه/Trade-off)، هزینه تأخیر در تصمیم و قابلیت بازگشت‌پذیری.

۶. تحویل بین‌تیمی: مدیریت انتقال کار (مثلاً از مهندسی به پشتیبانی مشتری).

• بخش «آنچه انجام نشده است» باید صریح باشد تا از پیش‌فرض‌های غلط جلوگیری شود.
• شناسایی «ناشناخته‌های شناخته‌شده» (Known unknowns) که تیم گیرنده باید بررسی کند.
• تعریف دقیق «پایان کار» (Definition of Done) و کانال‌های تصاعدی (Escalation) با SLA مشخص.

۷. کالبدشکافی بدون سرزنش (Blameless Postmortem): تمرکز بر سیستم‌ها به‌جای افراد.

• خط زمانی دقیق از اولین هشدار تا رفع مشکل، بدون عباراتی مثل «باید می‌کردیم».
• اثرات کمی‌شده (مثلاً ۱۲ هزار دلار ضرر یا ۳۴۰ سفارش ناموفق).
• تکنیک «۵ چرا» (5 Whys) که هرگز به فرد ختم نشود و حتماً به ابزار یا فرآیند برسد.
• حذف کامل کلمه «باید» و جایگزینی آن با اقداماتی مثل «اضافه کردن هشدار برای تأخیر > ۲ ثانیه».

۸. یادداشت جلسات تصمیم‌محور: تبدیل ترانسکریپت‌ها به گزارش نتایج.

• فرمت تصمیمات: «تصمیم گرفتیم [اقدام] را انجام دهیم، چون [دلیل]، از تاریخ [تاریخ]».
• شناسایی شکاف‌ها: اگر دلیلی ذکر نشده باشد، به عنوان «ثبت نشده — پیگیری با [نام شخص]» علامت می‌خورد.
• حذف جملات «بحث کردیم» یا «صحبت شد»؛ تمرکز روی تعهدات.

۹. چک‌لیست شواهد حسابرسی: برای استانداردهایی مثل SOC 2، ISO 27001 یا GDPR.

• نگاشت هر کنترل به شماره و بخش دقیق استاندارد مربوطه.
• دسته‌بندی شواهد بر اساس نوع (سکرین‌شات تنظیمات، خروجی لوگ، تاییدیه امضاشده) برای جمع‌آوری سریع.
• علامت‌گذاری کنترل‌های جدید (🆕) نسبت به حسابرسی قبلی.

۱۰. بررسی‌های فصلی رهبری: اجبار به بهداشت عملیاتی برای جلوگیری از انباشت «زباله‌های فرآیندی» (Cruft).

• معیارهای خروجی (Outcome Metrics) به‌جای معیارهای توهمی (Vanity Metrics).
• بخش «توقف»: اجبار به حذف حداقل یک فرآیند، ابزار یا جلسه قدیمی.
• «شرط‌بندی»: دقیقاً یک ابتکار عملیاتی برای فصل بعد با معیار موفقیت و شرط توقف (Kill Criterion) مشخص.

اعتبارسنجی و آزمایش

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

• تست تداوم: اجرای ۳ باره با ورودی یکسان؛ اگر خروجی‌ها متفاوت بود، محدودیت‌ها سخت‌تر می‌شوند.
• تست استرس: تغییر زمینه (مثلاً تبدیل آنبوردینگ مهندس به فروشنده)؛ اگر ساختار شکست خورد، پرامپت بیش‌برازش (Overfit) شده است.
• تست کلی‌گویی: اگر خروجی به‌گونه‌ای باشد که برای هر شرکتی صدق کند، محدودیت‌های خاص شرکت اضافه می‌شود.

مقیاس‌پذیری پرامپت‌نویسی عملیاتی

این رویکرد، پرامپت‌نویسی را به عنوان کاربرد منظم محدودیت‌ها می‌بیند. برای گسترش این نیاز، کتابخانه‌های تخصصی‌تری نیز طراحی شده‌اند که از پرامپت‌های بهره‌وری توسعه‌دهندگان (۳۰ پرامپت) تا سیستم‌های عملیاتی استارتاپ‌های هوش مصنوعی (۵۰+ پرامپت) را شامل می‌شوند.

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

گام بعدی شما

• مستند عملیاتی که بیشترین نادیده گرفته شده است را شناسایی کنید.
• در پرامپت بعدی برای آن سند، تمام «مقدمات» و «خلاصه‌ها» را صراحتاً ممنوع کنید.
• ساختار «نقش $\to$ زمینه $\to$ محدودیت $\to$ خروجی» را روی یکی از ۱۰ مورد فوق پیاده کنید.

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