بهینه‌سازی تکرارشوندهٔ پرامپت؛ چرخه‌ای که خروجی را نزدیک می‌کند

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

چرخهٔ چهارگامی بهینه‌سازی پرامپت

۱. اجرا: پرامپت را روی دو سه ورودی واقعی (نه فرضی) اجرا کنید. ۲. تشخیص: خطا را به یک «نوع» نسبت دهید: مبهم‌بودن وظیفه، نبود قالب، نقص زمینه، یا غلبه لحن نامطلوب. ۳. اصلاح یک متغیر: فقط یک چیز عوض کنید — نقش، قالب، محدودیت یا مثال. تغییر هم‌زمان چند مورد، شما را از علت واقعی بی‌خبر می‌کند. ۴. ثبت: نسخهٔ جدید را با تاریخ ذخیره کنید. بعد از سه نسخه، الگوی بهتر شدن را خواهید دید. برای نگهداری نسخه‌ها کتابخانهٔ پرامپت شخصی را ببینید.

قالب اصلاح ۱ — انتقال خطا به مدل

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

پرامپت فعلی: [پرامپت شما]
خروجی مشکل‌دار (نمونه): [خروجی که ناراحتتان کرد]
مشکل از نظر من: [یک جمله]

قالب اصلاح ۲ — جداسازی علت با اجرای کنترل

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

جدول علائم شایع و نسخهٔ درمان

قواعد طلایی بهینه‌سازی پرامپت

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

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

در تیم، نسخهٔ برنده را «پرامپت مرجع» بنامید و شماره بزنید؛ هر تغییر با تاریخ و دلیل ثبت شود. بدون این قانون، تیم بعد از مدتی به پرامپت‌های قبلی برمی‌گردد چون هیچ‌کس نمی‌داند کدام نسخه بهتر بود. ابزار پیشنهادی ما برای شروع، زنجیرهٔ پرامپت و الگوی نقد در خودانتقادی در پرامپت است.

جمع‌بندی

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

نمونهٔ واقعی: تکامل سه‌نسخه‌ای یک پرامپت

نسخهٔ اول: «برای پست لینکدین‌مان متن بنویس». خروجی: پاراگرافی عمومی با مقدمه‌چینی. تشخیص: خطا از نوع «وظیفهٔ مبهم و نبود مخاطب». اصلاح یک‌متغیره — نسخهٔ دوم فقط مخاطب و هدف اضافه می‌کند: «برای مدیران فروش صنعت بیمه بنویس؛ هدف، ترغیب به دانلود گزارش ماست». خروجی بهتر است اما هنوز قالب ندارد و هر بار شکل متفاوتی می‌گیرد. نسخهٔ سوم فقط قالب را اضافه می‌کند: چهار بخش اجباری (قلاب عددی، تجربهٔ سه‌جمله‌ای، درس عملی، سؤال پایانی) با سقف ۱۲۰ واژه. خروجی اکنون قابل انتشار است. توجه به روند مهم‌تر از خود روند است: هر نسخه فقط یک چیز گرفته، پس دقیقاً معلوم است چه چیزی چه اثری داشت — نسخهٔ دوم ثابت کرد مخاطب، پرگویی را کم می‌کند و نسخهٔ سوم ثابت کرد قالب، نوسان را حذف می‌کند. اگر هر سه تغییر با هم بود، امروز فقط می‌دانستیم «خروجی بهتر شد» و نمی‌دانستیم کدام جزء اثر گذاشته؛ یعنی برای کار بعدی هیچ چیز یاد نگرفته بودیم.

پرسش‌های پرتکرار

چند نسخه معمولاً لازم می‌شود؟

برای اغلب کارها دو تا سه نسخه؛ بعد از آن بازدهی افت می‌کند و باید ساختار کار را بازبین کنید.

بهترین معیار مقایسه دو نسخه چیست؟

خروجی روی پنج ورودی واقعی واحد؛ بدون ورودی ثابت، مقایسه معنا ندارد.

اگر مدل هر بار خروجی متفاوت داد چه کنم؟

دما و تصادفی‌بودن مدل را در نظر بگیرید؛ برای متن‌های قالب‌دار، خروجی پایدار مهم‌تر از خلاقیت است.

بهینه‌سازی برای کارهای یک‌باره هم می‌ارزد؟

نه؛ چرخهٔ اصلاح وقتی ارزش دارد که پرامپت قرار است بارها اجرا شود. برای کار یک‌باره، یک پرامپت خوب بنویسید، دو دور بازخورد بدهید و تمام کنید — نسخه‌بندی سرمایه‌گذاریِ کارهای تکراری است.