При переходе на GPT-6 Astra старые многостраничные промпты и жёсткие правила могут не помочь, а помешать: OpenAI рекомендует сократить описания навыков, подключать документацию по ситуации и заранее объяснять модели, что считать завершённой работой.
Суть события
OpenAI рекомендует пересмотреть инструкции для GPT-6 Astra. По словам сотрудника компании Эрика Провенчера, слишком длинные описания навыков, обязательное чтение множества документов и универсальные правила согласования расходуют контекст и порой заставляют модель завершать задачу раньше, чем ожидал пользователь.
Главный совет звучит почти парадоксально: более способной модели нужно меньше постоянной опеки. Инструкции стоит привязывать к конкретной работе, а критерий готовности формулировать явно. Если результат нужно не только написать, но и запустить, проверить и исправить после теста, всю эту цепочку лучше сразу назвать в задаче.
Детали
Особое внимание OpenAI предлагает уделить skills — хранимым в Markdown инструкциям с ресурсами и скриптами. Их названия и описания попадают в контекст Codex, чтобы агент выбрал подходящий инструмент. Когда навыков слишком много, описания могут сокращаться, а пересекающиеся формулировки мешают модели понять, какой навык нужен.
Практический ориентир — короткая и узкая область применения. Например, навык миграции схемы Postgres должен включаться при создании, изменении или проверке развёртывания миграции, а не при любой работе с базой. Если один навык охватывает несколько процессов, основной файл лучше превратить в краткий навигатор по дополнительным документам и скриптам.
То же относится к AGENTS.md. Требование читать архитектуру, документацию базы и правила развёртывания перед исправлением опечатки — избыточно. OpenAI советует подключать архитектурные материалы при изменении границ сервисов, документы по базе — при работе со схемами, а инструкции по развёртыванию — во время выпуска.
Контекст
Старые ограничения могли появиться не на пустом месте: команды добавляли подтверждения и пошаговые предписания после ошибок предыдущих моделей. Но при смене модели накопленный защитный слой стоит проверить заново. Astra, как утверждает OpenAI, лучше принимает решения, однако способна слишком буквально прочитать прежний запрет и остановиться там, где безопасную рутинную операцию следовало продолжить.
Для локальных тестов на временных данных без доступа к продакшену можно явно разрешить запуск тестов, исправление связанных с задачей ошибок и повторную проверку без нового согласования. Это не призыв убрать контроль вообще, а предложение отделить известные безопасные действия от действительно рискованных. Ранее мы уже разбирали, почему вокруг Astra бизнесу полезнее смотреть на проверяемые свойства и цену, а не только на громкие заявления OpenAI.
Что дальше
Фрилансерам, разработчикам и удалённым командам стоит начать с небольшого аудита: убрать дубли из системных инструкций, сузить описания навыков, заменить обязательное чтение всех документов точечными ссылками и выписать критерии готовности для повторяющихся задач. Затем сравнить на реальной работе число остановок, лишних запросов подтверждения и ручных исправлений.
Не стоит удалять правила одним махом. Лучше менять по одному блоку и сохранять ограничения для продакшена, секретов и необратимых операций. Если более короткий контракт даёт модели достаточно свободы, но оставляет понятную точку завершения, команда экономит контекст и время на сопровождение — без обмена контроля на слепое доверие.
