Prompt را چگونه از منطق کسب‌وکار جدا کنیم؟

مرز اصلی کجاست؟

برای پیدا کردن مرز، هر قطعه از تصمیم را با چهار سؤال بررسی کنید:

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

• آیا این قطعه رفتار زبانی و نحوهٔ پاسخ را تعیین می‌کند یا نتیجهٔ قطعی کسب‌وکار را؟
• آیا تغییر آن نیازمند تأیید مالک محصول، حقوقی، مالی یا امنیتی است؟
• آیا باید با تست قطعی، audit trail و rollback قابل‌بررسی باشد؟
• آیا به دادهٔ جاری، مجوز یا وضعیت transaction وابسته است؟

چه چیزهایی جای خوبی در prompt دارند؟

Prompt برای مشخص‌کردن قرارداد رفتار مدل مفید است. این قرارداد می‌تواند شامل این موارد باشد:

این موارد هم «ساده» نیستند. تغییر لحن می‌تواند تجربهٔ کاربر را عوض کند و تغییر قالب ممکن است مصرف‌کنندهٔ downstream را بشکند. اما از نظر معماری با قانون «این کاربر اجازهٔ refund دارد» یا «مالیات این سفارش چگونه محاسبه شود» یکی نیستند. اولی قرارداد تولید پاسخ است؛ دومی بخشی از واقعیت و policy کسب‌وکار است.

• نقش و هدف: مدل در این workflow چه کمکی می‌کند و برای چه کسی؟
• قالب خروجی: پاسخ باید خلاصه، ساختاریافته، JSON یا شامل بخش‌های مشخص باشد؟
• سبک و لحن: زبان، سطح جزئیات و شیوهٔ بیان چگونه باشد؟
• محدودیت پاسخ: اگر شواهد کافی نیست، مدل چه چیزی بگوید و چه زمانی سؤال بپرسد؟
• نمونه‌ها: چند ورودی و خروجی متنوع برای روشن‌کردن الگو چه شکلی‌اند؟
• ترتیب استفاده از context: مدل از کدام منابع و با چه اولویتی استفاده کند؟

چه چیزهایی نباید فقط در prompt بمانند؟

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

مجوز و دسترسی: این‌که یک کاربر چه چیزی را می‌بیند یا چه actionی می‌تواند انجام دهد، باید از هویت و مجوز سیستم بیاید. جمله‌ای مانند «اطلاعات محرمانه را نشان نده» safeguard مفیدی است، اما policy دسترسی نیست. کنترل باید پیش از تحویل context و دوباره پیش از اجرای action اعمال شود.

وضعیت و transition: سفارش، تیکت، پرونده یا پروژه معمولاً وضعیت‌های مشخص و transitionهای مجاز دارد. مدل می‌تواند وضعیت را دسته‌بندی یا توضیح دهد؛ تغییر رسمی وضعیت باید با منطق domain و ثبت رویداد انجام شود. اگر prompt تنها جایی است که می‌گوید «پس از پرداخت، سفارش را ارسال‌شده کن»، یک نقطهٔ شکست پنهان ساخته‌ایم.

شرط‌های توقف و escalation: در workflowهای حساس، توقف، انتقال به انسان، rollback و محدودیت تکرار نباید فقط توصیهٔ زبانی باشند. این شرط‌ها باید در orchestration یا policy اجرا شوند. مدل می‌تواند دلیل escalation را پیشنهاد کند، اما اختیار نهایی باید در مرزی قابل‌کنترل باشد. بازبینی انسانی در workflowهای AI همین مرز را بر اساس ریسک توضیح می‌دهد.

یک قرارداد تمیز میان سیستم و مدل

به‌جای آن‌که prompt را به دفتر قوانین تبدیل کنیم، یک قرارداد کوچک میان application و model بسازید:

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

• Application context را آماده می‌کند: کاربر، مجوز، وضعیت، دادهٔ مجاز و نتیجهٔ ruleهای قطعی را تعیین می‌کند.
• Prompt رفتار مدل را مشخص می‌کند: نقش، هدف، قالب، محدودیت و روش برخورد با uncertainty را می‌گوید.
• Model پیشنهاد یا توضیح می‌دهد: خروجی باید در قالب مشخص و تا حد ممکن ساختاریافته برگردد.
• Application خروجی را اعتبارسنجی می‌کند: schema، policy، مجوز، دامنه و شرط‌های توقف بررسی می‌شوند.
• انسان یا سیستم action را مالک می‌شود: action کم‌خطر می‌تواند خودکار باشد؛ action حساس باید approval و audit داشته باشد.

مثال فرضی: دستیار فروش و تخفیف

یک فروشگاه B2B را فرض کنید که دستیار AI به کارشناس فروش کمک می‌کند. prompt می‌تواند به مدل بگوید نیاز مشتری را خلاصه کند، سه سؤال بعدی پیشنهاد دهد، لحن حرفه‌ای داشته باشد و اگر داده‌ای ندارد صریح بگوید. این‌ها قرارداد رفتارند.

اما حد تخفیف، سطح مجاز هر کارشناس، وضعیت اعتبار مشتری و ثبت پیشنهاد باید از سیستم فروش و policy نسخه‌پذیر بیاید. application نتیجهٔ این policy را در context قرار می‌دهد. مدل می‌تواند یک متن پیشنهادی تولید کند، ولی سرویس قیمت یا policy engine باید تعیین کند چه عددی مجاز است. اگر action شامل ثبت قرارداد یا ارسال تعهد نهایی است، مرز approval انسانی هم روشن می‌شود.

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

Prompt را چگونه version و تست کنیم؟

جداکردن لایه‌ها بدون مدیریت تغییر کافی نیست. prompt هم artifact محصول است و باید چرخهٔ عمر داشته باشد:

راهنمای OpenAI صریحاً به غیرقطعی‌بودن خروجی و نیاز به تست و evaluation هنگام تغییر prompt یا model version اشاره می‌کند. از این اصل می‌توان یک قاعدهٔ عملی گرفت: prompt را مثل config مهم و کد را مثل محل اجرای منطق قطعی ببینید؛ هر دو versioned هستند، اما مسئولیت یکسانی ندارند.

• prompt را در repository یا registry نسخه‌پذیر نگه دارید، نه در یک پنل بدون history.
• متغیرها و contextهای runtime را از متن ثابت prompt جدا کنید.
• برای خروجی قرارداد، schema و validator داشته باشید.
• dataset ارزیابی را از نمونه‌های عادی، مرزی، خارج از دامنه و پرریسک بسازید.
• تغییر prompt را روی eval، هزینه، latency و تجربهٔ کاربر مقایسه کنید.
• مدل و prompt را به‌صورت یک ترکیب قابل‌شناسایی ثبت کنید؛ تغییر مدل می‌تواند رفتار prompt را عوض کند.
• برای regression و failure case، test و owner داشته باشید.
• اگر نتیجه بد شد، بتوانید به نسخهٔ قبلی prompt یا سطح اختیار قبلی برگردید.

اثر این مرزبندی بر Agile و مدیریت پروژه

وقتی prompt و منطق کسب‌وکار قاطی می‌شوند، backlog هم گمراه‌کننده می‌شود. یک ticket با عنوان «prompt را بهتر کنیم» ممکن است در واقع شامل تغییر policy، دسترسی، تجربهٔ کاربر، schema و آموزش تیم باشد. تفکیک لایه‌ها، کار را قابل‌شناسایی‌تر می‌کند.

AI در این فرایند سرعت تولید و تغییر را بالا می‌برد؛ به‌خصوص وقتی می‌تواند prompt، کد adapter و تست اولیه پیشنهاد کند. همین سرعت خطر را هم بیشتر می‌کند: مرزها سریع‌تر محو می‌شوند و تغییر کوچک راحت‌تر بدون owner منتشر می‌شود. بنابراین definition of done باید علاوه بر کیفیت متن، محل منطق، سطح اختیار، eval و مسیر rollback را هم پوشش دهد.

• در discovery: تیم سؤال می‌کند مدل باید چه کمکی کند و کدام تصمیم از قبل قانون دارد.
• در planning: تغییر prompt، تغییر policy و تغییر کد به taskهای جدا با owner و ریسک جدا تبدیل می‌شوند.
• در delivery: eval و validator کنار feature می‌آیند؛ prompt صرفاً پس از demo دستی پذیرفته نمی‌شود.
• در review: تیم اثر تغییر بر output، policy، مجوز، هزینه و regression را می‌بیند.
• در retrospective: اگر prompt مدام قانون جدید می‌گیرد، نشانهٔ بدهی معماری یا ابهام محصول است.

نشانه‌های prompt آلوده به منطق کسب‌وکار

اگر چند مورد از این نشانه‌ها را می‌بینید، معماری را بازبینی کنید:

• prompt شامل شرط‌های تو‌در‌تو و استثناهای فراوان است.
• اعداد و limitهای کسب‌وکار در چند prompt تکرار شده‌اند.
• تغییر policy بدون انتشار نسخهٔ جدید prompt ممکن نیست یا برعکس.
• برای فهمیدن دلیل تصمیم، باید متن prompt و خروجی مدل را دستی تفسیر کرد.
• تست‌ها فقط چند نمونهٔ متنی‌اند و مجوز یا state transition را بررسی نمی‌کنند.
• مدل مستقیماً ابزار حساس را صدا می‌زند بدون این‌که application policy را دوباره چک کند.
• هیچ owner مشخصی برای prompt، policy، schema و action وجود ندارد.

چک‌لیست اجرایی برای هفتهٔ اول

برای یک workflow واقعی، با این ترتیب شروع کنید:

• همهٔ دستورهای فعلی prompt را استخراج و به «رفتار مدل»، «قانون کسب‌وکار»، «داده» و «action» دسته‌بندی کنید.
• قانون‌های قطعی، مجوزها و transitionها را به ownerهای واقعی برگردانید.
• برای ورودی application و خروجی model یک schema یا قرارداد ساده ثبت کنید.
• مقدارهای متغیر را از prompt ثابت جدا کنید و provenance آن‌ها را نگه دارید.
• چهار گروه نمونهٔ ارزیابی بسازید: معمولی، مرزی، خارج از دامنه و پرریسک.
• یک معیار توقف یا rollback برای خطای مهم و نشت policy تعیین کنید.
• تغییر prompt را با commit، reviewer، eval و نسخهٔ مدل ثبت کنید.
• پس از launch، اصلاح دستی، failure case، latency، هزینه و actionهای برگشت‌خورده را بررسی کنید.

اثر AI بر این فرایند

AI در این موضوع هم ابزار تغییر است و هم بخشی از چیزی که باید کنترل شود. می‌تواند prompt را سریع‌تر تولید کند، مثال بسازد، کد adapter پیشنهاد دهد و failure case پیدا کند؛ این نقش عمدتاً augmentation است. اما سرعت تولید به‌تنهایی دلیل انتقال منطق کسب‌وکار به prompt نیست. trade-off اصلی میان چابکی کوتاه‌مدت و قابلیت تست، audit، portability و rollback در بلندمدت است. معیار بازبینی باید نشان دهد تغییرهای prompt بدون نقض policy، مجوز، schema و outcome منتشر می‌شوند و مالک انسانی هر لایه روشن است.

جمع‌بندی: Prompt را لاغر و سیستم را قابل‌اعتماد نگه دارید

واقعیت عمومی: مستندات رسمی OpenAI و Anthropic بر نقش دستورها، context، معیار موفقیت، snapshot و evaluation در ساخت رفتار پایدارتر مدل تأکید دارند. خروجی مدل غیرقطعی است و با تغییر prompt یا model باید دوباره ارزیابی شود.

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

پیشنهاد حکیم: یک workflow واقعی را انتخاب کنید، prompt را به لایه‌های رفتار، context و خروجی تقسیم کنید و منطق کسب‌وکار را به مسیر قابل‌تست و قابل‌ممیزی منتقل کنید. بعد با eval و rollback جلو بروید. AI زمانی به معماری کمک می‌کند که سرعتش مرز مسئولیت را روشن‌تر کند، نه این‌که قانون‌های پنهان بیشتری داخل یک متن جا بدهد.

منابع اولیه برای بررسی

• راهنمای رسمی OpenAI دربارهٔ prompt engineering، instruction، message role، snapshot و evaluation: https://developers.openai.com/api/docs/guides/prompt-engineering.md — بررسی‌شده در 2026-09-14.
• مستندات رسمی Anthropic دربارهٔ prompt engineering و ضرورت تعریف معیار موفقیت و آزمون تجربی: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview — بررسی‌شده در 2026-09-14.