پرامپت‌نویسی برای مدیریت دوره؛ درخواست دقیق برای ساختار درس و تغییرات قابل بازبینی
شش دستور مستقل برای ساختار، عنوان، توضیح و آمادگی انتشار دوره؛ با ورودی روشن، پیش‌نمایش، شرط توقف و کنترل تغییرهای معنایی توسط مدرس.
پرامپت خوب برای مدیریت دوره، فقط نمی‌گوید «دوره را بهتر کن». باید مرجع کار، محدودهٔ تغییر، نتیجهٔ مورد انتظار و نقطهٔ توقف را روشن کند. وقتی دستیار قرار است به ساختار درس‌ها، عنوان‌ها یا آمادگی انتشار کمک کند، درخواست مبهم می‌تواند پیشنهادی تولید کند که از نظر نگارش زیبا اما برای دورهٔ شما نامناسب است. اگر ابزار توان اجرای عملیات هم داشته باشد، ابهام فقط به متن محدود نمی‌ماند. بنابراین بهتر است نخست با پیشنهادِ قابل بررسی شروع کنیم و اجرای هر تغییر را تنها در محدودهٔ امکانات پشتیبانی‌شده، اختیار معتبر و تأیید مشخص پیش ببریم.
در این مقاله شش دستورِ آماده برای کارهای مدیریتی دوره می‌سازیم. این‌ها با پرامپتِ تولید طرح درس فرق دارند: موضوع، آموزش یک مفهوم تازه نیست؛ می‌خواهیم اطلاعات موجود و ساختار کار مدرس را قابل بررسی‌تر کنیم. همهٔ نمونه‌ها برای دورهٔ فرضیِ «مبانی عکاسی با گوشی» هستند و اطلاعات هنرجوی واقعی ندارند. نام منو، شناسه یا عملیات محصول از روی حدس ساخته نمی‌شود. اگر دستیار شما یک عملیات را پشتیبانی نمی‌کند، همان دستور باید فقط پیشنهاد متنی تولید کند و ثبت تغییر از مسیر مجازِ دستی انجام شود. واضح‌بودن درخواست، جای کنترل دسترسی سامانه را نمی‌گیرد.
پیش از درخواست، مرجعِ دوره را مشخص کنید
نام دوره به‌تنهایی همیشه مرجع کافی نیست. ممکن است دو دورهٔ پیش‌نویس با عنوان مشابه داشته باشید یا یک درس در چند مجموعه تکرار شده باشد. بهتر است در محیط دارای ابزار، از مرجع روشن و قابل انتخابِ همان سامانه استفاده کنید؛ در گفت‌وگوی متنی، یک فهرست کوچک و بی‌ابهام از درس‌ها بدهید. لازم نیست اطلاعات خصوصی یا شناسه‌های حساس را در ابزار بیرونی کپی کنید. هدف، جلوگیری از انتخاب نادرست است. اگر ابزار نمی‌تواند تشخیص دهد کدام دوره منظور است، باید سؤال کند و تا روشن‌شدن آن، پیشنهاد را هم با فرض قطعیِ ساختگی ننویسد.
برای نمونهٔ فرضی، سه درس داریم: شناخت نور پنجره، ثابت‌نگه‌داشتن گوشی و عکاسی از یک شیء ساده. مدرس نسخهٔ فعلیِ توضیح هر درس و پیش‌نیاز اعلام‌شدهٔ آن را آماده می‌کند. اگر شرح یک درس ناقص است، همان نقص در ورودی دیده می‌شود؛ لازم نیست برای زیبا به نظر رسیدن فهرست آن را با اطلاعات حدسی پُر کنیم. این کار به دستیار امکان می‌دهد میان «دادهٔ موجود» و «پیشنهاد تکمیلی» فرق بگذارد. هرچه این مرز از ابتدا واضح‌تر باشد، بازبینی نهایی کمتر به پیدا‌کردن جمله‌های ساختگی و برگرداندن تغییر ناخواسته تبدیل می‌شود.
یک قرارداد کوتاه با شش جزء بنویسید
درخواست را می‌توان با شش جزء ساخت: مرجع، هدف، ورودی معتبر، خروجی، محدودیت و شرط توقف. لازم نیست هر بار یک فرم طولانی پر کنید؛ فقط اطلاعاتی را بنویسید که برای همان کار اثر دارد. برای مثال، اگر تنها می‌خواهید توضیح درس بازنویسی شود، بیان اینکه فایل اصلی و دسترسی هنرجویان نباید تغییر کنند مهم است. اگر نتیجه باید جدول مقایسه باشد، آن را مشخص کنید. اگر ابزار برای تکمیل کار به دادهٔ تازه نیاز دارد، از او بخواهید محل کمبود را نشان دهد و حدس را با واقعیتِ دوره مخلوط نکند.
این چارچوب یک طراحی تحریریه برای کار مدرس است، نه دستور جادوییِ تضمین نتیجه. راهنمای رسمی طراحی درخواست Google هم بر دستور روشن، مشخص‌بودن ورودی و اصلاح تکراریِ درخواست بر اساس نتیجه تأکید می‌کند. کاربرد عملی برای ما آن است که نخست یک نمونهٔ کوچک اجرا کنیم و ببینیم آیا خروجی واقعاً قابل استفاده است. افزودن ده‌ها جملهٔ کلی مثل «حرفه‌ای و بی‌نقص باش» معمولاً قراردادِ کار را روشن‌تر نمی‌کند. باید بتوانید یک موردِ قبولی و یک موردِ رد را با همان درخواست توضیح دهید.
دستور اول برای پیدا‌کردن نقص ساختار
«فقط فهرست سه درسِ نمونهٔ دورهٔ عکاسی با گوشی و توضیح‌های تأییدشدهٔ همراهشان را بررسی کن. هدف، پیدا‌کردن وابستگی یا اطلاعات ناقص پیش از انتشار است. خروجی را در جدولی با ستون‌های درس، شاهد موجود، ابهام و سؤال پیشنهادی بنویس. چیزی را در دوره ذخیره نکن و هیچ درس یا فایلی را حذف یا جابه‌جا نکن. اگر توضیح فعلی نشان نمی‌دهد یک پیش‌نیاز واقعاً لازم است، آن را به‌عنوان احتمال مطرح کن و دلیلِ قطعی نساز. فقط از همین ورودی استفاده کن؛ عنوان جذاب یا نام درس را به‌تنهایی شاهدِ سطح دشواری ندان. در پایان، مشخص کن برای تصمیم نهایی کدام اطلاعات از مدرس لازم است.»
این دستور برای مرحلهٔ تشخیص است، بنابراین نتیجهٔ مطلوب آن الزاماً فهرست تغییر نیست. ممکن است دستیار درست تشخیص دهد که بدون دیدن تمرین درس سوم نمی‌توان ترتیب را تأیید کرد. در مثال ما، اگر عکاسی از شیء به مهارت ثابت‌نگه‌داشتن گوشی وابسته است، باید این ارتباط در متن یا تمرین قابل مشاهده باشد. بازبین نباید صرف جملهٔ «بهتر است» را قبول کند. از او بخواهید شاهد را در ورودی نشان دهد و اگر وجود ندارد، آن ردیف را سؤالِ مدرس بداند. این تفاوت، از تبدیل سلیقهٔ مدل به ساختار قطعیِ دوره جلوگیری می‌کند.
دستور دوم برای پیشنهاد عنوان روشن
«برای درسِ مشخص‌شده با توضیح فعلیِ “آشنایی با جهت نور و اثر آن روی سایهٔ یک شیء”، سه عنوان فارسی روشن پیشنهاد بده. هر عنوان باید موضوع درس را دقیق نشان دهد و وعده‌ای فراتر از محتوای داده‌شده نسازد. سطح هنرجو مبتدی است و عنوان باید روی صفحهٔ کوچک هم قابل فهم بماند. خروجی شامل عنوان پیشنهادی، دلیل کوتاه و تفاوتش با عنوان فعلی باشد. قیمت، مدرک، نتیجهٔ شغلی یا مهارتی را که در ورودی نیست اضافه نکن. هیچ عنوانی را ذخیره نکن و متن درس را بازنویسی نکن. اگر عنوان فعلی همین هدف را روشن بیان می‌کند، نگه‌داشتن آن را نیز گزینه‌ای معتبر در نظر بگیر.»
در اینجا معیار، افزایش ادعاییِ نرخ کلیک نیست؛ ما داده‌ای برای چنین نتیجه‌ای نداده‌ایم. مدرس باید ببیند عنوان با نتیجهٔ واقعیِ درس هماهنگ است یا فقط هیجان بیشتری دارد. مثلاً «راز عکاسی حرفه‌ای در چند دقیقه» از ورودیِ محدود ما پشتیبانی نمی‌شود. عنوانی مانند «جهت نور و شکل سایه روی یک شیء» شاید ساده‌تر باشد، اما قرارداد صادقانه‌تری با هنرجو می‌سازد. برای انتخاب نهایی، عنوان را کنار دو درس مجاور بخوانید. روشن‌بودن یک عنوان به‌تنهایی کافی نیست اگر تفاوتش با درس بعدی را پنهان کند یا ترتیب یادگیری را مبهم بسازد.
دستور سوم برای اصلاح توضیح بدون تغییر تعهد
«توضیح همین درس را برای هنرجوی مبتدی در دو بند کوتاه بازنویسی کن. همهٔ واقعیت‌های ورودی باید حفظ شوند: موضوع، پیش‌نیاز اعلام‌شده و تمرینی که واقعاً در درس وجود دارد. عبارت مبهم را روشن کن اما تمرین تازه، زمان پشتیبانی، فایل همراه یا قابلیت محصول اختراع نکن. خروجی را به‌صورت متن فعلی، متن پیشنهادی و فهرست تغییرهای معنایی بنویس. اگر جمله‌ای را نمی‌توان بدون اطلاعات بیشتر دقیق کرد، به‌جای پرکردن آن با حدس، یک سؤال مشخص از مدرس بپرس. این مرحله فقط آماده‌کردن متن برای بازبینی است؛ هیچ فایل، دسترسی، قیمت یا وضعیت انتشار نباید تغییر کند.»
بازبین در این مورد بهتر است جمله‌به‌جمله جلو برود. آیا «در پایان با یک شیء تمرین می‌کنید» واقعاً در درس وجود دارد؟ آیا عبارت «پاسخ استاد دریافت می‌کنید» تعهدی تازه ساخته است؟ اگر متن پیشنهادی جزئیات مفیدی اضافه کرده ولی آن جزئیات هنوز تأیید نشده‌اند، ابتدا دربارهٔ محتوا تصمیم بگیرید و بعد متن را اصلاح کنید. این ترتیب اجازه نمی‌دهد معرفی دوره جلوتر از توان اجرای آموزشگاه حرکت کند. پیشنهاد دستیار می‌تواند جای خالی را آشکار کند، اما پرشدن جای خالی در متن، به معنی ساخته‌شدن آن خدمت در واقعیت نیست.
دستور چهارم برای پیش‌نمایش جابه‌جایی
«در دورهٔ نمونه، فقط امکان جابه‌جاییِ دو درسِ “نور پنجره” و “ثابت‌نگه‌داشتن گوشی” را با توجه به توضیح‌ها و پیش‌نیازهای داده‌شده بررسی کن. ابتدا ترتیب فعلی و ترتیب پیشنهادی را کنار هم بنویس. برای هر درس مشخص کن چه چیزی تغییر می‌کند و چه چیزی باید دست‌نخورده بماند. اگر جابه‌جایی به تمرین، منبع یا دسترسیِ وابسته اثر می‌گذارد، پیش از هر تصمیم آن اثر را فهرست کن. فعلاً عملیات انجام نده. فقط اگر ابزارِ مجازِ همین سامانه چنین تغییری را پشتیبانی می‌کند، پیش‌نمایش دقیق را برای تأیید مدرس آماده کن؛ تأیید این درخواست، مجوز حذف فایل یا انتشار دوره نیست.»
این دستور عمداً میان بررسی و اجرا فاصله می‌گذارد. اگر ابزار فقط متنی است، خروجی باید یک پیشنهاد باقی بماند. اگر ابزارِ عملیاتی دارد، باز هم مرجع دو درس و محدودهٔ تأیید باید روشن باشند. برای مثال، مدرس ممکن است پس از دیدن پیش‌نمایش بفهمد ترتیب فعلی به تمرینِ جلسهٔ زنده وابسته است و پیشنهاد را رد کند. این ردشدن شکستِ فرایند نیست؛ پیش‌نمایش دقیق کار خود را انجام داده و مانع تغییر نامناسب شده است. کیفیت را فقط با تعداد اقدام‌های انجام‌شده نسنجید. گاهی بهترین خروجی، توقفِ مستدل پیش از تغییر است.
دستور پنجم برای یافتن تکرار احتمالیِ درس‌ها
«شرح دو درسِ مشخص‌شده را فقط از نظر تکرارِ هدف و فعالیت مقایسه کن. خروجی سه بخش داشته باشد: چیزهایی که واقعاً مشترک‌اند، تفاوت‌های مستند و سؤال‌هایی که برای تصمیم ادغام لازم است. مشابه‌بودن واژه‌های عنوان را به‌تنهایی دلیل یکی‌بودن محتوا ندان. هیچ‌کدام را حذف، ادغام، بایگانی یا از دید هنرجو پنهان نکن. اگر پیشنهاد ادغام داری، توضیح بده کدام هدف، مثال یا تمرین باید حفظ شود و چه اطلاعاتی هنوز بررسی نشده است. تصمیم نهایی با مدرس است. دربارهٔ میزان کاهش زمان یا افزایش یادگیری، عدد و نتیجه‌ای که در ورودی نداریم نساز.»
این دستور برای جلوگیری از شلوغی ساختار مفید است، اما نباید به پاک‌سازی خودکار فایل‌ها تبدیل شود. دو درس ممکن است واژگان مشترک داشته باشند ولی یکی مفهوم و دیگری کاربرد آن را آموزش دهد. در نمونهٔ عکاسی، درس «دیدن سایه» و «تغییر جهت نور» شاید از یک شیء استفاده کنند، اما فعالیت شناختی‌شان یکی نباشد. معیارِ بررسی باید هدف و کار هنرجو باشد. اگر محتوا واقعاً تکراری است، ابتدا تصمیم بگیرید چه چیزی حفظ می‌شود و با سابقه و لینک‌های مرتبط چه می‌کنید؛ جابه‌جاکردن یا حذف صرفاً با یک شباهت ظاهری انجام نشود.
دستور ششم برای گزارش آمادگی انتشار
«با استفاده از اطلاعات مجازِ فعلیِ دورهٔ نمونه، یک گزارش آمادگی انتشار آماده کن. موارد قابل بررسی را به چهار گروه ساختار درس، اطلاعات معرفی، منابع همراه و مسیر دسترسی تقسیم کن. برای هر ردیف، شاهدِ موجود و وضعیتِ تأییدشده، نیازمند اصلاح یا بررسی‌نشده را جدا بنویس. از نبود داده نتیجه نگیر که موردی درست یا نادرست است. اگر اجرای یک مسیر با حساب هنرجو لازم است، آن را به‌عنوان آزمونِ لازم معرفی کن، نه آزمونِ انجام‌شده. هیچ دوره‌ای را منتشر نکن، پیام نفرست و وضعیت پرداخت یا ثبت‌نام را تغییر نده. در پایان، سه کار بعدی را با دلیل و مسئول انسانیِ پیشنهادی مشخص کن.»
گزارش آمادگی نباید شبیه گواهیِ خودکارِ کامل‌بودن دوره نوشته شود. دستیار ممکن است ببیند توضیحِ پیش‌نیاز وجود دارد، اما این با درست‌بودن علمی آن فرق دارد. یا ممکن است بداند یک فایل ضمیمه شده، اما بازشدن و خوانایی آن روی گوشی هنوز بررسی نشده باشد. بازبین باید ستون «شاهد» را جدی بگیرد. اگر گزارش می‌گوید آزمون شد، باید اجرای واقعی و نتیجهٔ مشخص وجود داشته باشد. وضعیت «بررسی نشده» اطلاعات مفیدی است؛ حذف این برچسب برای زیباترشدن گزارش، تصمیم انتشار را ضعیف‌تر می‌کند و مسئولیت را مبهم می‌سازد.
متنِ بهتر، اجازهٔ بیشتر ایجاد نمی‌کند
در همهٔ این دستورها، محدودیتِ نوشتاری به روشن‌شدن قصد کمک می‌کند، اما مجوز اجرا باید در خود سامانه اعمال شود. درخواست یک هنرجو برای تغییرِ ترتیب عمومی درس‌ها با درخواست مدرسِ صاحب اختیار یکسان نیست. همچنین مدرس مهمان ممکن است اجازهٔ اصلاح متن درس خودش را داشته باشد ولی نتواند مجوزِ همهٔ مخاطبان را تغییر دهد. اگر برای اجرای کار باید رمز مدیر مشترک گرفته شود، مسئله با نوشتن پرامپت دقیق حل نمی‌شود. نقش‌ها و قابلیت‌های قابل استفاده باید از مسیر رسمی محصول مشخص باشند و مطابق همان‌ها کار کنید.
در راهنمای اختیار بیش از حد عامل OWASP، دسترسیِ بیش از نیاز و نبود کنترل اقدام‌های مهم به‌عنوان خطر مطرح می‌شود. کاربرد محدود این اصل در کار مدرس آن است که اختیار هر دستور با هدفش متناسب بماند. برای تشخیص نقص توضیح، نیازی به حذف یا انتشار نداریم. اگر ابزار در پاسخ به چنین دستوری درخواستِ اختیار اضافی می‌کند، باید علت را بررسی کنیم. این پرسش، روند همکاری را روشن می‌کند و اجازه نمی‌دهد سهولت گفت‌وگو با گستردگیِ بی‌حسابِ مجوز اشتباه گرفته شود.
ورودی را برای بازبینی آماده کنیم
پیش از کپی‌کردن اطلاعات، نسخهٔ معتبر را انتخاب کنید. شرح قدیمی و تازهٔ یک درس اگر بدون برچسب کنار هم قرار گیرند، ممکن است پیشنهاد را متناقض کنند. لازم نیست همهٔ آرشیو را برای یک تصمیم کوچک وارد کنید؛ یک بستهٔ محدود شامل متن مرتبط، مرجع و تاریخ بازبینی معمولاً قابل کنترل‌تر است. اگر بخشی از داده خصوصی است، آن را بدون نیاز وارد ابزار نکنید. برای تمرین اولیه از محتوای ساختگی یا کم‌حساسیت استفاده کنید تا بتوانید کیفیت دستور را بسنجید و هم‌زمان مخاطب واقعی را درگیر آزمایش نکنید.
برای مثال، در کارِ پیشنهاد عنوان، فهرست کامل خریداران یا نتیجهٔ تکلیف آنان موضوعیتی ندارد. در گزارش آمادگی انتشار نیز می‌توان از یک حسابِ آزمایشی و وضعیت کلیِ مجاز استفاده کرد. دادهٔ بیشتر همیشه پیشنهاد بهتر نمی‌سازد؛ گاهی فقط دامنهٔ بازبینی را بی‌دلیل زیاد می‌کند. اگر ابزار برای پاسخ به اطلاعاتی نیاز دارد که اجازهٔ دسترسی به آن ندارید، درخواست را محدود یا مسیر مجاز را از مسئول مربوط پیگیری کنید. پرامپت نباید نقش میان‌بُر برای دورزدن اجازه یا انتقالِ بی‌فکرِ دادهٔ سازمان را پیدا کند.
نتیجه را با فهرست تغییرهای معنایی بررسی کنید
در بازنویسیِ مدیریتی، خطر فقط غلط املایی نیست. ممکن است لحن بهتر شود ولی تعهد دوره عوض شود: «مرور می‌کنیم» تبدیل به «مسلط می‌شوید»، یا «تمرین نمونه» تبدیل به «تصحیح فردی» شود. از دستیار بخواهید تغییرهای معنایی را نشان دهد، سپس خودتان متنِ منبع و پیشنهاد را کنار هم بخوانید. فهرستِ مدل هم ممکن است چیزی را جا بیندازد. بازبین باید موضوع، دامنه، پیش‌نیاز، خدمت همراه و محدودیتِ واقعی را مستقل کنترل کند. اگر یکی از این موارد تغییر کرده، دربارهٔ آن تصمیم آموزشی یا تجاریِ جدا لازم است.
یک روش ساده، نشانه‌گذاری سه نوع جمله است: واقعیتِ تأییدشده، پیشنهادِ هنوز تصویب‌نشده و سؤال. نتیجهٔ نهایی نباید این سه را با هم مخلوط کند. اگر قرار است معرفی دوره منتشر شود، جملهٔ پیشنهادی باید یا به واقعیت تبدیل شده و تأیید شده باشد یا از متن عمومی حذف شود. در پیش‌نویس داخلی می‌توان سؤال را نگه داشت، اما نباید همان علامتِ کار ناتمام به صفحهٔ هنرجو برسد. این کار، میان فکرکردن با دستیار و انتشارِ یک وعدهٔ واقعی مرز مشخصی ایجاد می‌کند و بازبینی را هدفمندتر می‌سازد.
پاسخِ نامناسب را با یک اصلاح محدود دنبال کنید
اگر خروجی خوب نیست، همهٔ دستور را با ده‌ها شرط تازه از ابتدا بازنویسی نکنید. نخست علت را نام ببرید: مرجع اشتباه انتخاب شده، قالب خروجی مناسب نیست، متن وعدهٔ تازه ساخته یا ابزار به بخش نامرتبط رفته است. سپس یک اصلاحِ روشن بدهید. مثلاً «فقط ستون عنوان را بازنویسی کن؛ توضیح و تعهدها را تغییر نده». اگر هدف در هر رفت‌وبرگشت عوض شود، مقایسهٔ کیفیت دشوار می‌شود. نگه‌داشتن نسخهٔ ورودی و نتیجهٔ ردشده کمک می‌کند بفهمید کدام تغییرِ درخواست اثر داشته و کدام مشکل همچنان باقی است.
برای بعضی خطاها، تکرار درخواست پاسخ مناسبی نیست. اگر ابزار مرتب درس اشتباه را انتخاب می‌کند یا نتیجهٔ عملیات را نادرست گزارش می‌دهد، باید اجرای تغییر متوقف و مسئله از مسیر پشتیبانی بررسی شود. پاسخِ متنیِ قانع‌کننده نباید این نقص را بپوشاند. همچنین تغییر نسخهٔ منبع یا سطح دسترسی می‌تواند نتیجه را عوض کند؛ اگر یکی از این‌ها تغییر کرده، آن را در برگه ثبت کنید. هدفِ کار با دستیار، رسیدن به خروجی قابل استفاده است، نه ادامه‌دادن نامحدود گفت‌وگو تا بالاخره جمله‌ای دلخواه تولید شود.
اجرای واقعی را با بازخوانی ببندید
وقتی یک عملیاتِ مجاز و پشتیبانی‌شده واقعاً انجام می‌شود، گزارشِ بعد از آن باید از پیشنهادِ اولیه جدا باشد. مدرس باید بداند کدام تغییر ثبت شده، کدام انجام نشده و کدام نیازمند اقدام دیگری است. در نخستین استفاده، نتیجه را در همان دورهٔ نمونه باز کنید و با پیش‌نمایش تأییدشده تطبیق دهید. اگر دسترسی به بازخوانی ندارید، همین محدودیت را ثبت کنید و کار را کاملاً تأییدشده ننامید. وضعیت جزئی و نامعلوم را با یک جملهٔ عمومی «تمام شد» نپوشانید؛ این دقت بخشی از قرارداد سالمِ کار است.
در ابزارِ صرفاً متنی، پایان کار شکل دیگری دارد: پیشنهاد آماده است و هنوز هیچ تغییری در محصول صورت نگرفته است. متنِ مقاله یا گزارش باید همین را بگوید. برای ادارهٔ دوره، تفاوتِ این دو پایان بسیار مهم است، چون ممکن است مدرس بر اساس گزارش دستیار، به هنرجو اطلاع بدهد یا برنامهٔ کلاس را جلو ببرد. یک جملهٔ دقیق از دوباره‌کاری جلوگیری می‌کند. اگر نتیجه باید دستی ثبت شود، مسئول و محل اقدام روشن باشند و پیش از انتشار، همان معیارهایی که برای خروجی خودکار لازم بود دربارهٔ ثبت دستی هم کنترل شوند.
یک پروندهٔ کامل از توضیح مبهم تا متن قابل بررسی
فرض کنید توضیح فعلی چنین است: «در این جلسه نور را یاد می‌گیرید و عکس‌های عالی می‌گیرید. بعد از جلسه تمرین دارید». اطلاعاتِ تأییدشدهٔ مدرس محدودتر و دقیق‌تر است: موضوع درس جهت نور پنجره است؛ در فیلم، یک شیء ثابت از دو زاویه دیده می‌شود؛ تمرین، مقایسهٔ دو عکس از همان نوع شیء است؛ هیچ تصحیح فردی، زمان پشتیبانی یا تضمین کیفیت عکس در این داده اعلام نشده است. ورودیِ دستور سوم باید همین محدودیت‌ها را داشته باشد. مدرس نباید از ابزار انتظار داشته باشد خدمتِ واقعیِ موجود را از روی عبارت مبهم «تمرین دارید» حدس بزند.
یک خروجیِ فرضیِ قابل بررسی می‌تواند بگوید: «در این درس اثر تغییر جهت نور پنجره بر سایهٔ یک شیء را مقایسه می‌کنیم. دو نمونهٔ تصویری را ببینید و تفاوتِ بخش روشن و سایه را با هم بررسی کنید. در تمرینِ همراه، دو عکس از یک شیء ساده با جهت نور متفاوت تهیه کنید و تفاوت را با زبان خودتان توضیح دهید». این متن از نظر نگارش نهایی هم نیاز به خواندن مدرس دارد؛ مثلاً باید مطمئن شود تمرینِ همراه واقعاً به همین شکل آماده است. مثال، گزارش عملکرد ابزار مشخصی نیست و نتیجهٔ تضمین‌شدهٔ یک پرامپت محسوب نمی‌شود.
در فهرست تغییرهای معنایی، «عکس‌های عالی» باید به‌عنوان وعدهٔ حذف‌شده مشخص شود. جملهٔ مربوط به مقایسهٔ دو نمونه از اطلاعات تأییدشده آمده، اما اگر ابزار در خروجیِ دیگر «بازخورد اختصاصی استاد» اضافه کند، آن مورد مردود است. تصمیم نهایی می‌تواند انتشار متنِ اصلاح‌شده یا بازگشت برای آماده‌کردن تمرین باشد. به این ترتیب، دستور فقط واژه‌ها را زیباتر نکرده؛ فاصلهٔ معرفیِ درس و واقعیت اجرا را آشکار کرده است. همین فاصله باید پیش از اقدام عمومی بسته شود و با یک جملهٔ دلنشین زیر متن پنهان نماند.
در تیم، مسئولِ تأیید را از نویسندهٔ درخواست جدا بشناسید
کسی که درخواست را می‌نویسد همیشه مالک همهٔ تصمیم‌های بعدی نیست. دستیار آموزشی ممکن است متن اولیه را آماده کند، مدرسِ تخصصی صحت آن را بسنجد و مدیر دوره دربارهٔ تعهد پشتیبانی تصمیم بگیرد. اگر این نقش‌ها در آموزشگاه شما متفاوت‌اند، گزارش باید روشن کند کدام بخش هنوز تأییدِ چه نقشی را می‌خواهد. تأیید یک متن علمی به معنی تصویبِ قیمت یا زمان پاسخ‌گویی نیست. همچنین کسی که فقط دسترسی بازبینی دارد، نباید برای راحتی اجرای پرامپت از حساب مشترکِ پرقدرت استفاده کند. مسیر رسمیِ محصول باید این نقش‌ها را محترم بشمارد.
برای یک تغییر کوچک، ثبت کوتاه کافی است: مرجع درس، درخواست، نسخهٔ ورودی، پیشنهادِ پذیرفته‌شده، تأییدکننده و نتیجهٔ ثبت. لازم نیست متنِ کامل گفت‌وگو با اطلاعات غیرلازم بین همهٔ همکاران پخش شود. اگر گزارش قرار است برای آموزشِ تیم استفاده شود، نسخهٔ ساختگی یا پاک‌سازی‌شده بسازید. وقتی فرد دیگری کار را تحویل می‌گیرد، باید بفهمد چه چیزی انجام شده و چه چیزی فقط پیشنهاد بوده است. این نظم به‌ویژه هنگام جابه‌جاییِ مسئول دوره یا تغییر برنامهٔ ترم مفید است، چون اجازه نمی‌دهد مرحلهٔ نامعلوم به اشتباه انجام‌شده تلقی شود.
برای قبول‌کردنِ یک الگو، آزمون کوچک داشته باشید
قبل از ذخیرهٔ یک دستور به‌عنوان الگوی همیشگی، آن را با سه ورودی بررسی کنید: شرح کامل، شرح ناقص و مرجعِ مبهم. در حالت کامل، خروجی باید به هدف برسد؛ در حالت ناقص، کمبود را نشان دهد؛ و در حالت مبهم، انتخاب قطعیِ بی‌دلیل نکند. سپس یک ورودی با تعهدِ پشتیبانیِ صریحاً ناموجود بدهید و ببینید آیا آن را حفظ می‌کند یا در متن تازه وعده می‌سازد. این مجموعهٔ کوچک ارزیابیِ عمومی مدل نیست، ولی برای شناخت خطاهای همان دستورِ مدیریتیِ شما ابزار مناسبی است.
نتیجه را با برچسبِ پذیرفته، نیازمند اصلاح و رد ثبت کنید و علت را یک جمله بنویسید. «لحنش را دوست داشتم» برای قبولِ الگویی که ممکن است تعهد دوره را تغییر دهد کافی نیست. در مقابل، ردِ یک خروجی به دلیل انتخابِ مرجع اشتباه اطلاعات دقیق‌تری برای اصلاح درخواست می‌دهد. پس از تغییرِ الگو، همان ورودی‌های قبلی را دوباره بررسی کنید تا مسئلهٔ تازه‌ای ایجاد نشده باشد. هدف ساختن دستورِ طولانی‌تر نیست؛ می‌خواهیم برای نوع کاری که واقعاً تکرار می‌شود، رفتارِ قابل بازبینی و انتظارِ روشن داشته باشیم.
دستورها را با نمونهٔ دورهٔ خودتان نگه دارید
در مجموعهٔ شش دستورِ قابل کپی، نسخهٔ مستقل این الگوها آمده است. پس از استفاده، فقط مواردی را که در عمل مفید بوده‌اند در الگوی داخلی خود نگه دارید. برای هر دستور، یک نمونهٔ ورودیِ مجاز، یک خروجیِ پذیرفته‌شده و دلیل ردِ یک نمونهٔ نامناسب ثبت کنید. این نمونه‌ها از انبوه توصیه‌های کلی برای همکار تازه‌وارد کاربردی‌ترند. اگر ابزار یا قرارداد محصول تغییر کرد، الگو را دوباره امتحان کنید؛ نتیجهٔ خوبِ قدیمی نباید مجوز اعتماد همیشگی به درخواستِ بدون بازبینی باشد.
برای شناخت تفاوت پیشنهاد و اجرا، راهنمای عامل و دستیار آموزشی را بخوانید. اگر مسئلهٔ اصلی تولید محتوای یک جلسه است، طرح درس از یادداشت‌های استاد مرجع نزدیک‌تری است. پیلار دستیار هوشمند موضوع‌های مکمل را کنار هم قرار می‌دهد. برای آزمودن همین گردش کار در دستیار فاکسیمون، از یک دورهٔ نمونه و درخواستِ محدود شروع کنید. پرامپت موفق آن است که خروجی‌اش را بتوان فهمید، بررسی کرد و فقط در مرز مجاز به اقدام تبدیل کرد.
منابع و بررسی بیشتر
- راهبردهای طراحی درخواست در Google AI for Developers، برای اصول روشنی و اصلاح تکراری درخواست؛ بررسی در ۳۱ اکتبر ۲۰۲۶.
- راهنمای اختیار بیش از حد عامل در OWASP، برای تفکیک دستور روشن و مجوز معتبر.
- معرفی فعلی دستیار فاکسیمون، مرجع امکانات معرفی‌شده و نقش بازبینی مدرس؛ شش دستور این مقاله تألیف مستقل تحریریه‌اند.