مهندسی پرامپت برای تیم فنی
«مهندسی پرامپت» عنوان بزرگی برای کاری است که در عمل ساده است: دقیق گفتن اینکه چه می‌خواهید.
و همان‌جا هم مشکل است، چون دقیق گفتن سخت‌ترین بخش هر کار نرم‌افزاری است — با یا بدون هوش مصنوعی.
این مقاله دو موضوع را از هم جدا می‌کند: پرامپت برای کار روزمرهٔ تیم، و پرامپت به‌عنوان بخشی از محصولی که می‌سازید. دومی مسئلهٔ جدی‌تری است.
چه چیزی پرامپت را بهتر می‌کند
زمینه بدهید، نه فقط دستور. «این تابع را بهینه کن» کم است. «این تابع روی جدولی با دو میلیون رکورد اجرا می‌شود و الان چهار ثانیه طول می‌کشد؛ ایندکس‌ها این‌ها هستند» جواب متفاوتی می‌گیرد.
قالب خروجی را مشخص کنید. اگر جواب باید JSON با ساختار مشخص باشد، بگویید — و ساختار را بنویسید.
محدودیت‌ها را بگویید. «از کتابخانهٔ جدید استفاده نکن»، «سازگار با نسخهٔ فعلی بماند»، «فقط همین فایل تغییر کند».
مثال بدهید. یک نمونهٔ ورودی و خروجی درست، از سه پاراگراف توضیح مؤثرتر است.
بگویید چه چیزی نمی‌خواهید. به‌اندازهٔ گفتن آنچه می‌خواهید مهم است — همان اصلی که در نگارش RFP و چطور به تیم فنی بگوییم چه می‌خواهیم هم گفتیم. پرامپت خوب و بریف خوب، یک مهارت‌اند.
کار را بشکنید. درخواستی که ده کار را با هم می‌خواهد، نتیجهٔ متوسطی در همه می‌دهد.
اشتباهاتی که خروجی را غیرقابل اتکا می‌کنند
سؤال جهت‌دار. «چرا این روش بهتر است؟» جوابی می‌گیرد که فرض شما را تأیید کند. «مزایا و معایب این روش در برابر آن چیست؟» جواب مفیدتری می‌دهد.
فرض دانستن چیزی که نگفته‌اید. ابزار قواعد کسب‌وکاری شما را نمی‌داند.
پرامپت طولانی و بی‌ساختار. ده پاراگراف که در آن مهم و بی‌اهمیت قاطی است، بدتر از پنج جملهٔ مرتب عمل می‌کند.
اعتماد به جواب بدون تأیید، به‌ویژه وقتی جواب با اطمینان بیان شده. لحن مطمئن، نشانهٔ درستی نیست.
پرامپت به‌عنوان بخشی از محصول
اینجا ماجرا از یک مهارت شخصی به یک مسئلهٔ مهندسی تبدیل می‌شود.
اگر محصولی می‌سازید که پشتش مدل زبانی است — دستیار پشتیبانی، خلاصه‌ساز، طبقه‌بند — آن پرامپت بخشی از منطق محصول شماست. و باید مثل کد با آن رفتار کنید:
در مخزن کد باشد، نه در پنل مدیریت یا فایل جدا. تغییرش باید در تاریخچه دیده شود.
نسخه‌بندی شود. خروجی‌هایی که با نسخهٔ دوم پرامپت تولید شده‌اند، با نسخهٔ سوم قابل مقایسه نیستند. اگر این را ثبت نکنید، نمی‌فهمید چه چیزی بهبود را ساخته.
در بازبینی کد دیده شود. تغییر یک کلمه در پرامپت می‌تواند رفتار محصول را عوض کند — و بی‌صدا.
تست داشته باشد. مجموعه‌ای از ورودی‌های نمونه با خروجی مورد انتظار، که پس از هر تغییر اجرا شود. بدون این، هر اصلاح پرامپت یک قمار است: چیزی را بهتر می‌کنید و چیز دیگری را می‌شکنید و نمی‌فهمید.
روش سنجش کیفیت این خروجی‌ها در ارزیابی کیفیت هوش مصنوعی آمده.
نکات محصول فارسی
چند چیز که در پروژه‌های داخلی مکرر پیش می‌آید:
زبان پرامپت. برای خروجی فارسی، پرامپت فارسی معمولاً نتیجهٔ طبیعی‌تری می‌دهد — به‌ویژه در لحن. برای دستور فنی، انگلیسی گاهی دقیق‌تر است. آزمایش کنید، فرض نکنید.
لحن را صریح تعیین کنید. رسمی یا صمیمی؟ خروجی بدون این دستور، معمولاً لحنی ترجمه‌ای دارد که فارسی طبیعی نیست. همان تصمیمی که در ریزنوشته گفتیم باید یک بار گرفته شود.
اعداد و تاریخ. اگر خروجی باید تاریخ شمسی یا عدد فارسی داشته باشد، بگویید.
نویسه‌های عربی در ورودی کاربر. «ی» و «ک» عربی و نیم‌فاصله — اگر پیش از ارسال نرمال‌سازی نشوند، تطبیق و جست‌وجو در سامانهٔ شما می‌لنگد. تفصیلش در چالش‌های پردازش زبان فارسی.
امنیت پرامپت
اگر ورودی کاربر وارد پرامپت شما می‌شود، کاربر می‌تواند دستورالعمل شما را دستکاری کند. این را «تزریق پرامپت» می‌نامند و شبیه تزریق SQL است، با یک تفاوت مهم: راه‌حل قطعی ندارد.
چند کاهندهٔ عملی:
- ورودی کاربر را از دستورالعمل جدا نگه دارید و صریح علامت بزنید.
- به خروجی مدل به‌عنوان دادهٔ غیرقابل اعتماد نگاه کنید. اگر خروجی قرار است کاری انجام دهد — کوئری بزند، ایمیل بفرستد، فایلی بخواند — بررسی مجوز باید در کد شما باشد، نه در پرامپت.
- دسترسی مدل را محدود کنید به همان چیزی که واقعاً لازم دارد.
- خروجی را اعتبارسنجی کنید پیش از استفاده.
قاعدهٔ اصلی همان است که در ریسک‌های کد تولیدشده گفتیم: هیچ بررسی امنیتی نباید در جایی باشد که کاربر می‌تواند رویش اثر بگذارد. پرامپت، جای بررسی دسترسی نیست.
چه چیزی را برای تیم بنویسید
به‌جای دورهٔ آموزشی، این سه چیز عملی‌ترند:
۱. کتابخانهٔ پرامپت‌های تیم. آنهایی که جواب داده‌اند، در جایی مشترک. تیمی که هر نفر از صفر شروع می‌کند، ده بار همان کار را می‌کند.
۲. فهرست کارهایی که مجاز نیست. کد امنیتی، دادهٔ مشتری، کد تحت NDA. چهار بند سیاستی که در دستیار کدنویسی نوشتیم.
۳. الگوی پرامپت برای کارهای تکراری تیم، با جای خالی.
و یک نکتهٔ آخر
پرامپت خوب نوشتن، مهارت جدیدی نیست. همان مهارت نوشتن مشخصات دقیق است — که همیشه در این حرفه ارزشمند بوده و همیشه کمیاب.
تیمی که بلد است نیازمندی را روشن بنویسد، پرامپت خوب هم می‌نویسد. تیمی که نیازمندی‌هایش مبهم است، از این ابزارها هم خروجی مبهم می‌گیرد — و مشکل ابزار نیست.