اگر امروز یک قالب پرامپت موفق را به همکار خود میدهید، احتمالاً با نتایجی مواجه میشوید که با انتظارات شما فاصله دارد. این شکاف ناشی از چیزی است که محمد فرحان حبیب فراز، مهندس ارشد و سرپرست تیم پرامپت در PowerinAI، آن را «دانش ضمنی» مینامد؛ یعنی زمینههایی که در ذهن نویسنده است اما در دستورالعملها نیامده است.
شکاف بین استفاده شخصی و تحویل به تیم
ساخت یک سامانه مستندسازی مناقصه برای استفاده شخصی، یک پروژه است؛ اما تبدیل همان سامانه به قالبی که بقیه تیم بدون نیاز به پرسش و پاسخ بتوانند از آن استفاده کنند، پروژهای کاملاً متفاوت است که فقط لباس مشابهی به تن دارد. در واقع، مهندسی پرامپت (Prompt Engineering) — شبیه هنر سؤال درست پرسیدن از یک مشاور باتجربه برای گرفتن بهترین جواب — در مقیاس تیمی باید از سطح دستورات ساده به سطح انتقال منطق ارتقا یابد. برای درک بهتر این موضوع، میتوان به ۱۰ پرامپت عملیاتی برای جایگزینی مستندات فرآیندی کلی اشاره کرد که نشان میدهد چگونه دستورات دقیق میتوانند جایگزین مستندات مبهم شوند.
تصور کنید پرامپتی بنویسید که از هوش مصنوعی بخواهد «الزامات انطباق را بهطور مستقیم پوشش دهد». برای نویسنده، کلمه «مستقیم» بر اساس دهها نمونه قبلی از آنچه در عمل «مستقیم» تلقی میشود، معنای مشخصی دارد. اما برای یک همکار جدید که در معرض آن نمونهها نبوده است، این یک دستور مبهم است. احتمال زیاد این دستور به گونهای تفسیر میشود که از نظر منطقی قابل دفاع باشد، اما نسبت به هدف واقعی نویسنده، اشتباه باشد.
این شکاف نامرئی اغلب برای ماهها پنهان میماند، زیرا قالب برای نویسنده بهطور کامل کار میکند. مشکل تنها زمانی برملا میشود که برای اولین بار شخص دیگری آن را بهطور مستقل اجرا کند و پاسخی دریافت کند که از نظر فنی از دستورات پیروی کرده، اما هدف زیربنایی را نادیده گرفته است. همانطور که در گزارشی از dev.to اشاره شده است، مسئله این نیست که دستورات بهطور واضح بد نوشته شدهاند، بلکه مشکل این است که آنها برای «یک مخاطب» نوشته شدهاند.
جزئیات قالبهای آماده برای تحویل (Handoff-Ready)
به نقل از فراز، برای پر کردن این شکاف، فرآیند توسعه پرامپت باید از تمرکز بر «قوانین» به تمرکز بر «استدلال» تغییر کند. این گذار شامل چندین تغییر فنی مشخص است:
- تبدیل قوانین به منطق: دستوراتی که فقط یک قانون را میگویند اما دلیل وجود آن قانون را توضیح نمیدهند، جایگزین شدند. برای مثال، قانونی مانند «پاسخها را کوتاه نگه دارید و از زبان بازاریابی بیش از حد بپرهیزید» گسترش یافت. اکنون این دستور بهطور مشخص توضیح میدهد که زبان بازاریاتی در متن یک مناقصه دقیقاً چه شکلی است و چرا این نوع لحن باعث کاهش امتیاز توسط ارزیاب میشود، به جای اینکه صرفاً بگوید این لحن در فضای انتزاعی غیرحرفهای است.
- ایجاد لنگرهای عینی: سیستم اکنون شامل نمونههای صریح از موارد استثنا (Edge Cases) است. این نمونهها صرفاً برای بهبود کلی خروجی اضافه نشدهاند، بلکه به این دلیل هستند که فردی که با حوزه موضوعی آشنا نیست، به حداقل یک لنگر عینی نیاز دارد تا ببیند اجرای درست چگونه است؛ تنها پس از آن است که کاربر میتواند آن الگو را به موقعیتهای جدید و کمی متفاوت تعمیم دهد.
- ترسیم مرزهای توانمندی: سختترین بخش این فرآیند، پذیرش این واقعیت است که «قضاوت موقعیتی» — یعنی دانستن اینکه چه زمانی به دلیل غیرمعمول بودن الزامات یک مناقصه باید از قالب فاصله گرفت — را نمیتوان بهطور کامل در قالب نوشته ثبت کرد. به جای تظاهر به اینکه یک پرامپت میتواند هر سناریویی را مدیریت کند، قالبهای جدید اکنون دستههایی از ساختارهای مناقصه را که در آنها رویکرد استاندارد اغلب نیاز به اصلاح دارد، بهطور صریح علامتگذاری میکنند و به کاربر میگویند که باید مراقب چه مواردی باشد.
این تغییر، پرسش بنیادین مهندسی پرامپت را عوض میکند: بهجای اینکه بپرسیم «آیا این پرامپت وقتی من آن را اجرا میکنم خروجی درست میدهد؟»، باید بپرسیم «آیا این دستور شامل استدلال کافی پشت هر قانون است تا کسی که پیشزمینه و تجربه انباشتهشده من را ندارد، بتواند آن را بهطور صحیح روی مناقصهای که هرگز ندیده است، اجرا کند؟» برای اطمینان از پایداری این خروجیها در مقیاس تیمی، میتوان از تست واحدِ قالبهای پرامپت به عنوان راهکاری برای جلوگیری از افت کیفیت خاموش استفاده کرد.
تأثیرات بلندمدت بر تیم
برای کاربر عملی، این یعنی «جادوی» یک پرامپت با عملکرد بالا، بهندرت در کلمات به تنهایی است، بلکه در قضاوت موقعیتی نویسنده نهفته است. با نام بردن از مرزهای توانمندی هوش مصنوعی زاینده (Generative AI) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — تیمها ریسک «شکستهای خاموش» را کاهش میدهند؛ یعنی زمانی که پاسخ از نظر فنی از دستورات پیروی کرده اما هدف واقعی را گم کرده است.
وقتی این فرآیند بازسازی روی یک قالب پیاده شود، همین انضباط باید در مراحل اولیه توسعه هر قالب بعدی اعمال شود. ساختن با نگاه به «تحویل به تیم» از همان ابتدا، به جای اصلاح قالب پس از وقوع مشکل، شکافهای خروجی را بهطور محسوسی کم میکند. در این حالت، غریزه پرسیدن این سؤال که «آیا این دستور برای کسی که پیشزمینه نویسنده را ندارد منطقی است یا خیر»، به بخشی از اولین پیشنویس تبدیل میشود. همچنین برای کاهش چرخههای تکرار ناشی از ابهامات، میتوان موتور شفافسازی متوالی را برای حذف بازخوردهای تکراری در خروجیها به کار گرفت.
درس واقعی این است که یک قالب پرامپت که برای نویسنده اصلیاش کار میکند و قالبی که برای یک تیم آماده است، دو محصول متفاوت هستند، حتی اگر در تستهای اولیه خروجی یکسانی بدهند. تفاوت در این است که آیا استدلالها بهقدری مرئی هستند که کاربر بتواند آنها را در موقعیتی به کار ببرد که نویسنده هرگز بهطور مشخص پیشبینی نکرده بود.
برای پیادهسازی این رویکرد، با بازبینی موفقترین پرامپتهای خود برای یافتن دستورات «ضمنی» شروع کنید — همانهایی که برای تفسیرشان به تجربه شخصی شما تکیه میکنند — و آنها را با «چرایی» پشت هر قانون جایگزین کنید.
گام بعدی شما
- موفقترین پرامپتهای خود را بازبینی کنید و دستورات «ضمنی» (آنهایی که به تجربه شخصی شما تکیه دارند) را شناسایی کنید.
- برای هر قانون سختگیرانه در پرامپت، یک بخش «چرا» (Why) اضافه کنید تا منطق پشت آن برای دیگران روشن شود.
- فهرستی از موارد استثنایی که مدل در آنها شکست میخورد تهیه کرده و آنها را به عنوان هشدار در قالب پرامپت بگنجانید.
اما مدیریت این قالبها در محیطهای ابری پیچیدگیهای بیشتری دارد — به بررسی ما دربارهی پروتکل MCP برای مدیریت زمینه مدلها مراجعه کنید.
گفتگو