Как писать промпты для ChatGPT-6 Astra: новые правила OpenAI

Как писать промпты для GPT-6 Astra: почему длинные навыки и старые инструкции теперь могут мешать

С выходом GPT-6 Astra OpenAI советует пересмотреть старые промпты, Skills и файлы AGENTS.md, накопленные для предыдущих моделей. Причина довольно практическая: Astra требует меньше пошагового контроля, лучше сама определяет нужный контекст и внимательнее соблюдает ограничения, поэтому старые страховочные инструкции могут не помогать, а перегружать контекст, запускать ненужные Skills и преждевременно останавливать работу.

Главный принцип новой настройки можно сформулировать так: описывайте границы и результат, а не расписывайте модели каждый шаг заранее.

Почему старые промпты для GPT-6 Astra стоит пересмотреть

За последний год пользователи coding agents постепенно обрастали инструкциями. Модель однажды не прочитала нужный документ, и в AGENTS.md появилось правило читать его всегда. Пропустила тесты, добавили обязательный прогон всех тестов. Использовала неправильный инструмент, появился ещё один Skill с подробным сценарием.

Каждое такое правило когда-то решало реальную проблему. Потом проблемы остались в промптах, а модели стали другими.

Более сильные модели требуют меньше ручного сопровождения и искусственных подпорок вокруг задачи. Инструкции, полезные для предыдущих поколений, теперь стоит заново проверить, а не автоматически переносить в новый стек.

Здесь появляется неприятный парадокс. Хороший старый промпт может стать плохим не потому, что его логика была ошибочной. Просто часть его правил компенсировала ограничения модели, которых у Astra уже нет или которые проявляются иначе.

Сильной модели не обязательно нужен более сложный промпт. Иногда достаточно более короткого промпта без костылей, накопленных за предыдущий год.

Что такое Skills и почему их стало опасно складывать десятками

OpenAI Skill (или навыки) – это набор инструкций, обычно сохранённый в Markdown. Вместе с ним можно поставлять дополнительные материалы и скрипты, чтобы агент использовал их для определённого рабочего процесса.

Каждый навык имеет название и описание, по которому модель должна понять, когда его использовать. Эти описания попадают в контекст. Когда навыков становится слишком много, Codex приходится ужимать их описания, чтобы всё поместилось. В результате модель видит меньше информации о каждом навыке и хуже определяет, какой действительно подходит текущей задаче.

То есть библиотека из пятидесяти «полезных навыков» вполне способна сделать агента менее точным.

Есть и второй риск. Если описание навыка слишком широкое, Astra начинает активировать его там, где он не нужен.

Плохое описание навыков при любой работе с базами данных, запросами, моделями или хранением данных. Хорошее описание сужает область до создания, изменения и проверки миграций.

Разница небольшая только на бумаге. В первом случае агент получает дополнительную пачку инструкций почти при любой задаче, связанной с базой. Во втором навык загружается именно тогда, когда его правила способны изменить результат.

Хорошее описание Skill отвечает на вопрос «когда включать», а не «что я вообще умею»

Если описание подходит для двадцати разных задач, хотя Skill нужен только в трёх, описание слишком широкое.

Формулировка вроде «используй для работы с контентом, маркетингом, анализом и текстами» практически бесполезна. Она не помогает модели принять решение. Почти любая задача попадает хотя бы в одну категорию.

Намного полезнее описывать событие активации.

Например, вместо «помогает работать с SEO-контентом» лучше написать: «используй при подготовке новой SEO-страницы или аудите существующей страницы под конкретный поисковый запрос».

Меньше пафоса, зато модель понимает границу применения.

Именно этот принцип лежит в рекомендации OpenAI делать описания Skill максимально короткими, сохраняя при этом ясность относительно момента, когда навык действительно нужен.

Не загружайте инструкцию целиком раньше времени

Второй сильный принцип – постепенное раскрытие информации.

Каждый прочитанный файл расходует контекст. Кроме самого объёма появляется ещё одна проблема: документ способен добавить инструкции, вообще не относящиеся к текущей задаче. Чем раньше модель получает лишние правила, тем больше шансов, что они начнут влиять на работу.

Поэтому сложный Skill лучше строить не как огромный Markdown-файл со всеми сценариями сразу.

Корневой документ работает как небольшой маршрутизатор. Он объясняет, какие варианты работы существуют и в какой дополнительный файл нужно идти для каждого варианта. Подробности, скрипты и специальные инструкции подключаются только тогда, когда модель действительно дошла до соответствующей задачи.

В этом подходе есть очень здравый инженерный смысл.

Если агент исправляет цвет кнопки, ему не требуется читать инструкции по деплою, миграциям базы, архитектуре очередей и подготовке релиза. Все документы могут быть важными. Просто не одновременно.

Контекст модели лучше воспринимать как рабочий стол. Если свалить туда все инструкции проекта, нужный документ не становится заметнее.

Почему подробный рецепт теперь способен ухудшить результат

Раньше Skills часто писали как пошаговую инструкцию: сначала открой файл А, потом прочитай Б, затем вызови инструмент В, проверь Г и только после этого переходи дальше.

Для менее сильных моделей такой сценарий помогал удержать процесс.

OpenAI пишет, что современные модели значительно лучше работают с неоднозначностью и нюансами. Поэтому слишком подробная инструкция теперь способна ограничивать Astra там, где раньше действительно помогала.

Это не означает, что алгоритмы больше не нужны.

Если у компании есть обязательная процедура безопасности, миграции или публикации, её по-прежнему нужно описать. Но инструкция «делай именно эти семь шагов при любой похожей задаче» должна существовать из-за требований процесса, а не потому, что год назад модель иначе путалась.

Хороший вопрос при ревизии каждого правила звучит так: это требование нашего процесса или костыль старой модели?

Если правило существует только по второй причине, его пора заново тестировать.

Почему AGENTS.md для Astra лучше делать контекстным

Файл AGENTS.md влияет на работу модели внутри репозитория, поэтому OpenAI советует регулярно пересматривать содержащиеся там инструкции.

Очень показательный пример касается документации.

Старое правило может требовать перед каждым изменением прочитать architecture.md, database.md и deployment.md. Кажется надёжным, пока задача не заключается в исправлении одной опечатки.

Astra уже способна сама определить, какие материалы понадобятся для текущего изменения. Поэтому OpenAI предлагает не заставлять её читать весь набор перед каждой задачей, а объяснить назначение документов: архитектурный файл нужен для границ сервисов, документ базы требуется при изменении схемы, а инструкция деплоя нужна при подготовке публикации.

Получается важный сдвиг.

Старая логика: сначала прочитай всё, потому что я не уверен, что ты поймёшь, что понадобится.

Новая логика: вот карта источников, используй нужный документ тогда, когда задача до него дойдёт.

Контекст становится меньше, работа ускоряется, а нерелевантные инструкции реже вмешиваются в решение.

Не заставляйте Astra перепроверять всё просто по привычке

Предыдущие модели приходилось отдельно подталкивать запускать тесты и проверять собственные изменения. Astra делает это активнее самостоятельно, поэтому старые инструкции способны вызвать избыточное тестирование.

Вот где универсальное «обязательно перепроверь всё три раза» начинает работать против пользователя.

Для изменения одной строки агент способен потратить время на тесты, которые никак не связаны с затронутой областью. Не потому, что Astra плохо понимает задачу, а потому, что пользователь сам оставил старую команду проверять всё подряд.

Лучше определить уровень достаточной проверки.

Например, при локальном изменении прогоняются затронутые тесты. Полная тестовая батарея требуется перед релизом или после изменения системной части. Критические сценарии проверяются независимо от размера правки.

Так инструкция описывает реальное инженерное правило, а не тревожность владельца промпта.

Astra нужно разрешать безопасную самостоятельность

Ещё одно изменение касается границ решений.

Пользователи прошлых моделей могли добавлять жёсткие запреты после случаев, когда агент выполнял действие без достаточного разрешения. С Astra такие ограничения нужно проверить заново, потому что новая модель осторожнее относится к безопасности и может воспринять старый запрет слишком буквально.

Представим правило:

«Никогда не выполняй дополнительных действий без моего явного подтверждения».

Для рискованной операции звучит разумно. Но теперь агент способен остановиться перед повторным запуском безопасного локального теста после собственного исправления.

Работа превращается в переписку:

«Можно исправить?»

«Можно».

«Можно проверить?»

«Можно».

«Тест упал, можно исправить?»

Ну прекрасно, автоматизация века получилась.

OpenAI предлагает явно давать разрешение внутри безопасных рабочих процессов. Модель понимает не только запрет, но и территорию самостоятельности.

Почему Astra иногда останавливается раньше, чем хотелось бы

У GPT-6 Astra есть другая особенность. OpenAI описывает её как более осторожную в вопросе того, насколько далеко нужно продолжать выполнение задачи. Модель способна сделать первую реализацию и вернуться за отзывом, хотя пользователь ожидал полностью готовый результат.

Решение здесь находится не в команде «будь настойчивее».

Нужно заранее определить, что означает завершение задачи.

Если результат должен быть запущен, проверен и исправлен после обнаруженных ошибок, всё это нужно включить в критерий готовности. Если работа заканчивается после первого прототипа и дальше требуется решение человека, это тоже стоит написать.

OpenAI прямо рекомендует задавать границу завершения до начала работы. Если нужен дополнительный исследовательский проход, следует описать, что модель должна исследовать и при каком условии остановиться.

Это полезный принцип далеко за пределами программирования.

Промпт «подготовь анализ конкурентов» не объясняет точку завершения. Промпт «проанализируй пять конкурентов, проверь их действующие предложения по первичным источникам, выдели три устойчивых различия и остановись после проверки каждого вывода ссылкой» уже задаёт финальное состояние.

Как переписать старый промпт под GPT-6 Astra

Вместо того чтобы добавлять ещё одну страницу правил, полезнее провести аудит уже существующей инструкции.

Проверяйте пять вещей: зачем появилось каждое правило, должно ли оно срабатывать всегда, можно ли подключать его только по ситуации, не дублирует ли оно способность Astra и не конфликтует ли оно с другим ограничением.

Особенно подозрительно выглядят абсолютные формулировки вроде «всегда прочитай», «никогда не продолжай», «каждый раз проверь всё», «при любом изменении используй этот Skill».

Иногда абсолютное правило действительно необходимо. Например, перед публикацией. Но слово «всегда» должно появляться из реального требования процесса, а не из плохого опыта с моделью прошлого года.

Готовый промпт для аудита Skills, AGENTS.md и старых инструкций

OpenAI предлагает использовать Astra для аудита накопленных инструкций. Ниже моя рабочая версия такого запроса, построенная непосредственно вокруг проблем из материала OpenAI.

Проведи аудит моих инструкций для GPT-6 Astra.

Я передам тебе Skills, AGENTS.md и рабочие промпты.

Не переписывай их сразу.

Сначала для каждого правила определи:

1. Какую конкретную проблему оно решает.
2. Является ли это требованием рабочего процесса
или костылём для ограничения старой модели.
3. Нужно ли правило применять ко всем задачам.
4. Можно ли активировать его только в конкретном контексте.
5. Дублирует ли оно способность GPT-6 Astra,
которую модель уже выполняет самостоятельно.
6. Конфликтует ли правило с другой инструкцией.
7. Может ли оно вызвать лишнее чтение файлов,
ненужные тесты, преждевременную остановку
или лишний запрос подтверждения.

Отдельно проверь Skills.

Для каждого Skill оцени:
– понятно ли из описания, когда его нужно использовать;
– не слишком ли широкое условие активации;
– можно ли сократить описание;
– стоит ли вынести подробности из корневого файла
в дополнительные документы или скрипты;
– не заставляет ли Skill читать нерелевантный контекст.

Отдельно проверь AGENTS.md.

Найди инструкции вида:
«всегда прочитай»,
«перед каждым изменением»,
«никогда не продолжай без подтверждения»,
«обязательно запусти все тесты».

Для каждой объясни, действительно ли абсолютное правило необходимо.

Затем проверь decision boundaries.

Покажи:
– где Astra должна действовать самостоятельно;
– где требуется подтверждение человека;
– какие безопасные обратимые действия можно разрешить заранее.

После этого проверь критерий завершения работы.

Определи, понятно ли модели:
– какой результат считается готовым;
– должна ли она запускать результат;
– должна ли исправлять найденные ошибки;
– какие тесты достаточно выполнить;
– где необходимо остановиться и вернуть работу человеку.

В финале предложи сокращённую версию инструкций.

Не удаляй правило только потому, что оно длинное.
Удаляй или ослабляй его только тогда, когда можешь объяснить,
почему оно больше не улучшает результат.

Важная деталь этого промпта заключается в последней части. Цель аудита состоит не в том, чтобы сделать AGENTS.md коротким любой ценой. Короткая плохая инструкция ничем не лучше длинной плохой инструкции.

Нужно оставить только правила, у которых есть понятная функция.

Хорошая инструкция для Astra описывает реальные требования работы. Плохая инструкция хранит коллекцию страхов после ошибок моделей предыдущего поколения.

Что я изменю в старых промптах прямо сейчас

Начать можно с абсолютных запретов и обязательных действий. Именно там обычно лежит больше всего накопленной ненужной истории.

Если написано «прочитай всю документацию перед началом», замените это картой документов и условиями использования. Если Skill активируется при любом упоминании широкой темы, сузьте условие до конкретного рабочего события. Если модель обязана запрашивать разрешение перед каждым действием, выделите безопасный диапазон самостоятельной работы.

Затем проверьте точку завершения. Astra должна понимать, нужно ли ей только подготовить первую версию или довести результат до рабочего состояния, включая проверку и исправление найденных проблем.

И только после этого имеет смысл сокращать формулировки.

Слепой подход «Astra умная, удаляем половину промпта» тоже довольно сомнительный. OpenAI не говорит отказаться от инструкций. Компания советует пересмотреть старые предположения и убрать контекст, который перестал приносить пользу.

Нужно ли вообще использовать Skills с GPT-6 Astra

Skills остаются полезными для конкретных рабочих процессов и работы с определёнными приложениями. Проблема начинается, когда навык становится универсальной энциклопедией или его описание заставляет модель активировать Skill слишком часто.

Хороший Skill решает ограниченную задачу, включается по понятному условию и раскрывает дополнительные инструкции только по мере необходимости.

Плохой Skill пытается заранее научить модель всему проекту.

Здесь разница не косметическая. Каждый лишний фрагмент контекста приближает повышает вероятность появления инструкций, не относящихся к текущей работе.

Частые вопросы про промпты и Skills для ChatGPT-6 Astra

Нужно ли переписывать все промпты после перехода на GPT-6 Astra?

OpenAI не требует начинать с чистого листа. Компания рекомендует пересмотреть накопленные инструкции и проверить, нужны ли правила, созданные для предыдущих моделей.

Почему длинные Skills могут мешать Astra?

Названия и описания Skills попадают в контекст модели. При большом количестве навыков описания могут сокращаться, а слишком широкие или конфликтующие формулировки мешают Astra правильно выбрать нужный Skill.

Нужно ли заставлять Astra читать документацию перед каждой задачей?

OpenAI рекомендует привязывать документы к конкретным видам изменений, а не заставлять модель читать весь набор перед каждой правкой. Astra способна сама определить нужный контекст значительно лучше предыдущих моделей.

Нужно ли отдельно просить Astra запускать тесты?

Astra сама более тщательно проверяет свою работу, поэтому старые обязательные инструкции способны привести к лишнему тестированию. Лучше определить уровень проверки для конкретного рабочего процесса.

Почему Astra останавливается после первой версии?

OpenAI отмечает, что новая модель может осторожнее определять границу выполнения задачи. Если требуется полностью рабочий результат, нужно заранее включить запуск, проверку и исправление ошибок в критерий завершения.

Стоит ли делать промпты для Astra короче?

Сокращение полезно только тогда, когда удаляется ненужная или дублирующая инструкция. Главная цель состоит не в минимальном количестве символов, а в чистом контексте без конфликтующих правил.

Главный вывод

GPT-6 Astra меняет не только то, что модель умеет делать, но и то, сколько инструкций ей вообще требуется.

Если ваш AGENTS.md вырос до небольшого романа, Skills активируются по половине задач, а каждый промпт начинается с двадцати правил, накопленных после старых провалов, новая модель даёт хороший повод устроить ревизию.

Сузьте условия активации Skills. Не заставляйте модель читать документацию без причины. Разрешите безопасные действия внутри понятных границ. И заранее определите, что именно считается законченной работой.

Самая полезная мысль звучит довольно неприятно для любителей гигантских промптов: новой модели иногда мешает не недостаток инструкций, а слишком много старых инструкций, которые давно никто не решался удалить.