Рекомендации по промптингу для GPT-5.6 Sol

Используйте это руководство при адаптации промптов, описаний инструментов, инструкций агентов или стеков промптов под GPT-5.6 Sol или семейство GPT-5.6. Дополняйте его актуальным руководством по модели GPT-5.6 для деталей API, лимитов, цен и доступности функций.

GPT-5.6 работает лучше всего, когда промпт задаёт результат, ключевые ограничения, доступные данные и планку завершённости, а затем оставляет модели свободу выбрать эффективный путь.

Удаление повторяющихся инструкций и примеров, а также упрощение описаний инструментов могут повысить качество выполнения задач и эффективность по токенам. В выборке внутренних прогонов оценки кодинг-агента конфигурации с более лёгкими системными промптами улучшили оценки примерно на 10–15%, сократив при этом общее число токенов на 41–66%, а стоимость — на 33–67%. Результаты зависят от нагрузки, поэтому воспринимайте эти диапазоны как ориентировочные и проверяйте изменения на репрезентативных задачах из вашего приложения.

Сначала упрощайте промпты

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

Убирайте:

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

Сохраняйте:

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

Проверьте оставшиеся инструкции на противоречия. Модели класса GPT-5 строго следуют «контракту» промпта, поэтому конфликтующие правила могут вызывать больше нестабильности, чем недостаток деталей.

Промпты «от результата» и условия остановки

Описывайте пункт назначения, а не предписывайте каждый шаг. GPT-5.6 обычно сама выбирает эффективный путь поиска, инструментов или рассуждения, когда промпт объясняет, как выглядит хороший результат.

Предпочтительно:

Решите проблему клиента от начала до конца.

Успех означает:
- принять решение о праве на услугу на основе доступных данных политики и аккаунта
- выполнить все разрешённые действия до ответа
- вернуть completed_actions, customer_message и blockers
- если необходимых данных не хватает, запросить минимально недостающее поле

Избегайте лишних абсолютных правил. Используйте ALWAYS, NEVER, must и only только для настоящих инвариантов — таких как правила безопасности, обязательные поля или действия, которых никогда не должно происходить. Для решений «на усмотрение» — когда искать, спрашивать, использовать инструмент или продолжать итерации — предпочитайте правила принятия решений.

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

Добавляйте условия остановки:

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

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

Личность, взаимодействие и длина ответа

GPT-5.6 по умолчанию склонна быть лаконичнее, чем GPT-5.5. При миграции проверьте, полезны ли ещё общие инструкции по краткости вроде «Будьте лаконичны» или «Пишите коротко». Для некоторых задач они могут быть излишни и иногда делают ответы слишком короткими. Сохраняйте их, когда они надёжно дают нужный вашему приложению вывод.

Для более стабильного контроля между запросами используйте text.verbosity, чтобы задать уровень детализации по умолчанию, а промпт — для требований конкретной задачи. Выберите low, medium или high как уровень детализации по умолчанию. В промпте укажите специфичные для задачи длину, структуру или обязательное содержание. См. Настройка text.verbosity для примера API.

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

• Личность управляет тоном, теплотой, прямотой, формальностью, юмором, эмпатией и «полировкой».
• Стиль взаимодействия управляет тем, когда модель задаёт вопросы, делает допущения, проявляет инициативу, объясняет компромиссы, проверяет работу и справляется с неопределённостью.

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

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

Начинайте с вывода. Приведите данные, необходимые для его обоснования, любую
существенную оговорку и следующее действие. Опустите второстепенные детали
и повторы.

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

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

Широкие ярлыки вроде «дружелюбный» или «эмпатичный» могут быть неоднозначны. Опишите те решения в письме, которые определяют тон вашего продукта: насколько прямо давать ответ, когда признавать проблему и уместны ли заверение или подпись-прощание.

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

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

Для редактирования, переписывания, резюме и клиентских черновиков скажите модели, что сохранить:

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

Определяйте автономию и границы согласования

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

Обычно достаточно компактной политики:

Для запросов ответить, объяснить, проверить, диагностировать или
спланировать — изучите нужные материалы и сообщите результат. Не вносите
изменения, если запрос об этом не просит.

Для запросов изменить, построить или починить — внесите запрошенные
локальные изменения в рамках задачи и запустите соответствующую
неразрушительную валидацию, не спрашивая заранее.

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

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

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

Маршрутизация инструментов

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

Когда корректность зависит от предварительного извлечения или поиска, скажите об этом:

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

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

Если инструмент возвращает пустой, частичный или подозрительно узкий результат, попробуйте один-два осмысленных запасных варианта, прежде чем заключить, что результата нет.

Программный вызов инструментов

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

Множественные, параллельные или зависимые вызовы сами по себе не оправдывают программный вызов инструментов.

Используйте его для:

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

Предпочитайте прямые вызовы инструментов, когда:

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

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

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

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

Элемент program_output и финальное сообщение ассистента message — это отдельные выводы; обязательно тестируйте оба. В теории программа может вернуть правильные записи, а сообщение при этом опустит обязательное поле, цитату или оговорку.

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

Обоснование, цитаты и бюджеты извлечения

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

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

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

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

Для исследования и синтеза:

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

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

Длительные рабочие процессы и состояние

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

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

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

Уплотняйте (compaction) после крупных вех, а не каждый ход. Держите промпт функционально согласованным после уплотнения и относитесь к уплотнённым элементам как к непрозрачному состоянию.

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

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

Уровень усилий рассуждения

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

• Сохраните текущий уровень усилий рассуждения GPT-5.5 или GPT-5.4 как базовую линию.
• Тестируйте ту же настройку и на один уровень ниже на репрезентативных задачах.
• Используйте low для задач, чувствительных к задержке, когда это сохраняет качество.
• Используйте medium как сбалансированную отправную точку.
• Используйте high или xhigh только когда оценки показывают значимый выигрыш.
• Резервируйте max для самых сложных задач с приоритетом качества; не рекомендуйте его повсеместно.

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

Фронтенд и визуальные задачи

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

Для инкрементальных изменений фронтенда:

• изучайте и сохраняйте существующие дизайн-токены, компоненты и паттерны;
• не добавляйте лишних функций или декоративного UI, если это не запрошено;
• сохраняйте адаптивное поведение и ожидаемые состояния;
• отрендерите и проверьте результат перед финализацией.

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

Проверяйте работу перед завершением

Дайте GPT-5.6 доступ к инструментам, которые могут валидировать вывод, и укажите, какая валидация важна.

Для кодинга:

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

Если валидацию нельзя запустить, объясните почему и опишите следующую
лучшую проверку.

Для визуальных артефактов:

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

Для планов реализации включайте требования, названные ресурсы или файлы, переходы состояний или поток данных, проверки валидации, поведение при сбоях, соображения приватности или безопасности и открытые вопросы, существенно влияющие на реализацию.

Предлагаемая структура промпта

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

Role: [функция и контекст модели]

Personality: [тон и стиль взаимодействия]

Goal: [видимый пользователю результат]

Success criteria: [что должно быть верно до финального ответа]

Constraints: [ограничения по политике, безопасности, бизнесу, данным и побочным эффектам]

Tools: [какие инструменты использовать, когда и что не использовать]

Output: [разделы, длина, формат и тон]

Stop rules: [когда повторять, откатываться, воздержаться, спросить или остановиться]

Рабочий процесс миграции промптов

При переносе существующего приложения на GPT-5.6:

1. Переключите модель и сохраните текущий уровень усилий рассуждения.
2. Запустите репрезентативные оценки до изменения промпта.
3. Уберите устаревшие «леса», повторяющиеся инструкции и нерелевантные инструменты.
4. Добавляйте только наименьшую целевую инструкцию, которая исправляет измеренную регрессию.
5. Повторно запускайте оценки после каждого изменения промпта или рассуждения.

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

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

Источник: https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6

По теме

• Статья: Инженерия циклов: 14 шагов от промптера к дизайнеру циклов
• Блог: gpt-5.6-sol без выжженных лимитов: перевод советов Тео из t3.gg
• База знаний: GPT Image — гайд по промптингу для генерации и редактирования изображений

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov