اسکیلهای Codex؛ دستور پخت کارهای تکراری برای ایجنت
هوش مصنوعیخلاصهٔ کاملتر
تو این مقاله اومده که اسکیل تو Codex چیز پیچیدهای نیست: یه فایل مارکداون، معمولاً با اسم skill.md، که دو بخش داره. بالاش یه بخش YAML front matter که اسم اسکیل و شرط فعال شدنش رو تعریف میکنه، و پایینش متن ساده که خود دستورالعمل رو مینویسه. نویسنده بهش میگه دستور پخت: وقتی ایجنت دستور پخت داشته باشه، دیگه لازم نیست یه درخواست مبهم مثل «مرغ درست کن» رو خودش تفسیر کنه و هر روز یه چیز تحویل بده.
نقطهٔ شروع نوشتن یه اسکیل خوب، توضیح فرایند نیست؛ یه نمونهٔ تمامشده از چیزیه که «کار تمومه» یعنی چی. نویسنده میگه اول یه خروجی که ازش راضی هستی رو بردار (یه گزارش آماده، یه شیت فرمتشده، یه مقالهٔ نوشتهشده) و بعد مسیر رو برعکس برو: چه دادهای وارد شد، چه محاسبه و تبدیلی روش انجام شد، چطور فرمت شد، و چی باعث شد همین نسخه خوب از آب دربیاد. جواب همین سؤالها محتوای واقعی فایل اسکیله، چون نویسنده و ایجنت هر دو از یه نمونهٔ مشخص شروع میکنن نه از دو تصویر ذهنی متفاوت.
هر اسکیل هم باید فقط یه کار داشته باشه. اسکیلی به اسم «تیم مارکتینگ رو بگردون» برای قابل اعتماد بودن زیادی گندهست و باید به کارهای جداگونه شکسته بشه: گزارش رو بنویس، آمار رو دربیار، پست شبکهٔ اجتماعی رو بنویس. تست عملیش اینه که اگه نمیتونی کار یه اسکیل رو تو یه جمله بگی، احتمالاً باید بشکنیش.
میزان آزادی ایجنت هم باید با جنس کار جور باشه: کار قطعی مثل جابهجا کردن داده بین شیت و CRM باید مثل چکلیست شمارهدار نوشته بشه، ولی کار قضاوتی مثل تبدیل متن ویدیو به مقاله با دستورهای خشک (اسکرینشات دقیقهٔ یک، درج تو خط ۴۰۰) خروجی بیربط میده و باید فقط معیارهای قضاوت رو توصیف کنه.
چیزی که یه اسکیل رو از «خروجی میده» به «خروجیای که بهش اعتماد داری» میرسونه، مرحلهٔ بازبینیه. الگوی رایجش یه حلقهست: یه ایجنت خروجی رو میسازه، ایجنت دوم (یا همون ایجنت تو یه پاس جدا) اون رو با یه استاندارد میسنجه، بازخورد برمیگرده و این چرخه تا وقتی که کار از خط قرمز کیفیت رد بشه ادامه پیدا میکنه. بازبینی هم دو جوره: بررسی عینی که قانونمحور و اثباتپذیره (مثلاً تعداد مشخصی منبع، یا تأیید هر ادعا توسط یه ایجنت دوم)، و بررسی ذهنی برای وقتی که معیار عددی وجود نداره.
تو حالت ذهنی، اسکیل عملاً ایجنت رو میکنه داور یا همون LLM-as-judge (یعنی مدل خودش کیفیت خروجی رو قضاوت میکنه). چون هیچ عددی برای چک کردن نیست، اسکیل باید اونقدر دقیق توصیف کنه که «خوب» چه شکلیه تا قضاوت بین اجراهای مختلف یکسان بمونه. نویسنده آخرش میگه برای کار واقعاً یهباره، همون پرامپت ساده کافیه؛ ولی برای هر کاری که چند بار تکرار میشه اسکیل نوشتن میارزه، به شرطی که بپذیری فایل اسکیل معمولاً بار اول درست درنمیاد و بعد از چندین دور تست و اصلاح جا میافته.
نکات کلیدی:
- اسکیل یه فایل skill.md با دو بخشه: YAML front matter برای نام و شرط فعال شدن، و بدنهٔ مارکداون برای خود دستورالعمل.
- روش پیشنهادی نوشتن، مهندسی معکوس از یه خروجی تمامشدهست، نه توصیف فرایند از حافظه.
- هر اسکیل یه کار و یه تریگر؛ اگه تو یه جمله جا نشه، باید شکسته بشه.
- کار قطعی دستورالعمل شمارهدار و بسته میخواد، کار قضاوتی معیار باز.
- بازبینی عینی قانونمحوره (تعداد منبع، تأیید فکت)، بازبینی ذهنی با الگوی LLM-as-judge انجام میشه.
- یه فایل اسکیل آمادهٔ استفاده ممکنه دهها بار بازنویسی بشه تا قابل اتکا بشه.
