وقتی مدلهای جدید هوش مصنوعی از راه میرسند، معمولاً اولین واکنش این است که دستورالعملهای بیشتری به آنها بدهیم؛ فایلهای طولانیتر بنویسیم، مهارتهای بیشتری تعریف کنیم و برای هر موقعیت چندین قانون و توضیح آماده داشته باشیم. اما ظاهراً این رویکرد دیگر همیشه جواب نمیدهد.
با ورود GPT-۶ Astra، توسعهدهندگان باید بخشی از دستورالعملهایی را که طی یک سال گذشته به محیط کاری خود اضافه کردهاند، دوباره بررسی کنند. فایلهای AGENTS.md، ساختار Skills و حتی پرامپتهایی که برای هدایت مدل نوشته شدهاند، ممکن است بیش از آنکه کمککننده باشند، فضای کانتکست را شلوغ کنند و دست مدل را ببندند.
این تغییر تا حد زیادی نتیجه پیشرفت دستیارهای برنامهنویسی است. مدلهایی مانند Codex حالا در انجام بسیاری از کارهایی که قبلاً به توضیح قدمبهقدم، چارچوببندی دقیق و دستورالعملهای طولانی نیاز داشتند، توانمندتر شدهاند. به همین دلیل، دستورالعملی که زمانی برای جلوگیری از اشتباه مدل ضروری به نظر میرسید، ممکن است امروز فقط مانعی اضافه باشد.
در چنین شرایطی، مسئله دیگر این نیست که چطور مدل را با جزئیات بیشتری هدایت کنیم؛ بلکه باید ببینیم کدام دستورالعملها واقعاً لازم هستند و کدامیک فقط از گذشته به جا ماندهاند. گاهی بهترین کاری که میتوان برای یک مدل جدید انجام داد، اضافهکردن یک دستورالعمل تازه نیست؛ حذف دستورالعملی است که دیگر نیازی به آن وجود ندارد.

بهینهسازی مهارتها و افشای تدریجی اطلاعات
مهارتها یا همان Skills در کدکس، در سادهترین تعریف، مجموعهای از پرامپتها هستند که معمولاً در قالب فایلهای Markdown نوشته میشوند و میتوانند در کنار منابع و اسکریپتهای دیگر، یک گردش کار مشخص یا تعامل با یک ابزار خاص را مدیریت کنند. مشکل از جایی شروع میشود که تعداد این مهارتها زیاد شود و توضیحات هرکدام هم بهجای چند خط روشن و مشخص، به دستورالعملهایی طولانی تبدیل شوند.
کدکس برای انتخاب مهارت مناسب باید ابتدا این توضیحات را در پنجره زمینه خود در نظر بگیرد. وقتی حجم اطلاعات زیاد باشد، مدل ناچار است بخشی از آنها را خلاصه کند تا همهچیز در فضای موجود جا شود. همین خلاصهسازی میتواند دقت مدل در تشخیص اینکه کدام مهارت واقعاً برای یک کار مشخص لازم است را کاهش دهد. حتی توضیحات متناقض یا تأکید بیش از حد روی کاربردهای مختلف یک مهارت هم ممکن است باعث شود مدل دستورالعملهایی را بارگذاری کند که ارتباط چندانی با کاری که در حال انجام آن است ندارند.
راهنمای بهروزشده ابزار $skill-creator نیز بر همین موضوع تأکید دارد: توضیح هر مهارت باید تا حد ممکن کوتاه، دقیق و مشخص باشد تا مدل بتواند فقط زمانی سراغ آن برود که واقعاً به آن نیاز دارد. برای مثال، اگر مهارتی برای مدیریت پایگاه داده PostgreSQL ساخته شده است، لازم نیست در توضیحات آن تمام کارهایی که ممکن است با PostgreSQL انجام شوند فهرست شود. یک توضیح مشخص مانند «ایجاد و اعتبارسنجی مایگریشنهای شِمای PostgreSQL؛ ویژه استفاده هنگام افزودن، تغییر یا بررسی استقرار مایگریشن» میتواند برای تشخیص زمان استفاده از مهارت کافی باشد.
این رویکرد به یکی دیگر از مفاهیم مهم در طراحی دستورالعمل برای مدلهای جدید میرسد: «ارائه تدریجی اطلاعات» یا Progressive Disclosure. ایده ساده است. بهجای اینکه همه اطلاعات را از همان ابتدا جلوی مدل بگذاریم، یک سند کوچک و کمحجم میتواند نقش مسیریاب را داشته باشد و فقط در صورت نیاز، مدل را به سراغ اسناد، منابع یا اسکریپتهای تکمیلی بفرستد.
این تغییر نگاه با پیشرفت مدلهای زبانی اهمیت بیشتری پیدا کرده است. مدلهای جدید در درک ابهام، تشخیص منظور و کنار هم گذاشتن اطلاعات توانمندتر شدهاند و به همین دلیل، دستورالعملهای بسیار جزئی و قدمبهقدم همیشه به معنای عملکرد بهتر نیستند. گاهی توضیح دادن هر مرحله، هر استثنا و هر تصمیم احتمالی، بیشتر از اینکه مدل را راهنمایی کند، فضای تصمیمگیری آن را شلوغ میکند.
به همین دلیل، دستورالعملی که زمانی برای مدلهای قدیمیتر ضروری به نظر میرسید، لزوماً برای مدلهای جدید هم مفید نیست. حتی پرامپتها و راهنماهایی که برای مدلهایی مانند GPT-۵.۶ Sol یا Luna با دقت بهینه شده بودند، ممکن است در مدلهای پیشرفتهتر نهتنها مزیتی ایجاد نکنند، بلکه به مانعی برای عملکرد بهتر تبدیل شوند.

بازنگری در فایلهای AGENTS.md و مرزهای تصمیمگیری
دستورالعملهایی که در فایل AGENTS.md مینویسید روی کل پروژه اثر میگذارند، بنابراین باید مداوم آنها را بازبینی و بهروز کنید.
اگر هوش مصنوعی را مجبور کنید برای یک تغییر کوچک، تمام مستندات معماری، دیتابیس و نحوه انتشار پروژه را از اول تا آخر بخواند، فقط حافظه متنی (Context) او را بیدلیل اشغال کردهاید و سرعت کارش را پایین آوردهاید. راه بهتر این است که مستندات را موضوعی و تفکیکشده به او معرفی کنید:
- فایل
architecture.mdفقط برای درک ساختار و حدود سرویسها - فایل
database.mdفقط برای تغییرات دیتابیس - فایل
deployment.mdفقط هنگام آمادهسازی برای انتشار برنامه
از طرفی، مدلهای قدیمی برای اجرا و بررسی تستهای کد نیاز به تذکر و تشویق مداوم داشتند، اما جیپیتی ۶ آسترا (GPT-۶ Astra) این کار را بهطور کاملاً مستقل و هوشمندانه انجام میدهد. این مدل درک بسیار بهتری از مسائل ایمنی دارد و تا از امن بودن یک دستور مطمئن نشود، آن را دستکاری نمیکند.
به همین دلیل، قوانین و محدودیتهای سفتوسختی که قبلاً برای مهار مدلهای قدیمی گذاشته بودید، اکنون فقط باعث توقف بیمورد مدل جدید میشوند. در فضاهای امن (مثل اجرای تستها روی سیستم شخصی خودتان که دسترسی به سرور اصلی ندارد)، میتوانید در فایل AGENTS.md به مدل اجازه دهید خودش کار را جلو ببرد و خطاهایش را بدون نیاز به تأیید گامبهگام شما اصلاح کند.
تعریف دقیق معیار پایان کار در پرامپتها
برخلاف مدل جیپیتی ۵.۶ سول که کارها را بدون توقف و یکنفس ادامه میداد، جیپیتی ۶ آسترا محتاطتر رفتار میکند؛ این مدل ممکن است به محض آمادهکردن اولین نسخه اولیه، دست از کار بکشد و منتظر نظر شما بماند.
برای پیشگیری از این توقفهای زودهنگام، باید شرط پایان کار را همان اول در پرامپت (دستور) خیلی شفاف مشخص کنید.
مثلاً اگر میخواهید مدل کارش را تا آخر انجام دهد، دقیقاً بگویید که باید این گامها را کامل طی کند:
- نوشتن و پیادهسازی اولیه
- بررسی و تست خروجی
- اصلاح خطاهای احتمالی
وقتی تمام مراحل را صراحتاً در درخواست خود قید کنید، هوش مصنوعی کار را تا رسیدن به نتیجه نهایی ادامه میدهد و بین راه بی دلیل متوقف نمیشود.
این خبر بر اساس گزارش منتشرشده در OpenAI تهیه شده است.

