Промпт-инжиниринг для GPT-5.5 — outcome-first подход, личность и валидация

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

Актуальность сведений проверена 5 сентября 2026 года по официальному руководству OpenAI для GPT-5.5.

Целевая архитектура промпта и приложения

Рабочая конфигурация GPT-5.5 состоит из нескольких уровней:

1. Промпт описывает роль, результат, критерии успеха, ограничения и условия остановки.
2. Параметры API управляют глубиной рассуждения и длиной ответа.
3. Описания инструментов объясняют назначение, входные данные, побочные эффекты, безопасность повторного вызова и типичные ошибки.
4. Structured Outputs задаёт проверяемую схему ответа, если приложению нужен строгий формат.
5. Responses API управляет состоянием диалога, результатами инструментов и промежуточными сообщениями.
6. Проверки на репрезентативных примерах позволяют оценить качество, расход токенов и полную задержку сценария.

Стабильные инструкции размещайте в начале запроса, динамический пользовательский контекст — ближе к концу. Это повышает вероятность попадания в кэш промптов. Для повторяющегося трафика используйте prompt_cache_key последовательно и отслеживайте usage.prompt_tokens_details.cached_tokens.

Уровень рассуждения: начинайте с medium и проверяйте low

У GPT-5.5 уровень рассуждения по умолчанию — medium. OpenAI рекомендует его как сбалансированную отправную точку по качеству, надёжности, задержке и стоимости.

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

Личность и стиль сотрудничества отвечают за разное

Для клиентского ассистента задайте два коротких слоя:

• Личность (Personality) определяет звучание: теплоту, прямоту, формальность и допустимый юмор.
• Стиль сотрудничества (Collaboration style) определяет работу: когда задавать вопрос, какие предположения допустимы, насколько проактивно действовать и как обрабатывать риск.

Пример компактного блока:

# Personality
Ты — спокойный и прямой напарник. Пиши уважительно и практично,
без лишней разговорной обвязки.

# Collaboration style
Продвигайся вперёд, если запрос достаточно ясен. Используй контекст
и разумные предположения. Задавай один узкий вопрос, когда ответ
существенно зависит от недостающих данных или действие создаёт риск.
Называй важную неопределённость и проверяй результат доступными средствами.

Эти настройки дополняют цель, правила инструментов и критерии успеха. Они не компенсируют размытый продуктовый контракт.

Промпт от результата (outcome-first) задаёт измеримый результат

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

# Goal
Реши вопрос клиента по доступным данным политики и аккаунта.

# Success criteria
- Решение подтверждено доступными данными.
- Разрешённые действия выполнены до ответа.
- Финальный ответ содержит completed_actions, customer_message и blockers.
- При нехватке доказательств запрошено минимальное недостающее поле.

# Constraints
Не выполняй действия, запрещённые политикой. Не придумывай отсутствующие
данные и не трактуй отсутствие подтверждения как отрицательный факт.

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

Пошаговый сценарий оставляйте там, где точный порядок является частью требований: например, при регламентированной проверке, необратимом действии или протоколе безопасности. Слова ВСЕГДА, НИКОГДА, must и only используйте для настоящих инвариантов. Для поиска, уточнений и повторных попыток формулируйте решающие правила.

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

Бюджет поиска (retrieval budget) ограничивает поиск

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

Повторный поиск оправдан, когда:

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

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

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

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

Преамбула, phase и состояние длинного процесса

В многошаговой задаче короткая преамбула улучшает воспринимаемую скорость интерфейса:

Перед вызовами инструментов отправь видимое сообщение из одного-двух
предложений: подтверди задачу и назови первый шаг.

Для короткого однотурного ответа преамбула обычно создаёт шум.

При работе через Responses API:

• используйте previous_response_id, если API должен хранить состояние между ходами;
• в stateless- и Zero Data Retention-сценариях возвращайте релевантные output items самостоятельно;
• при ручном воспроизведении assistant items сохраняйте исходное значение phase без изменений;
• при уплотнении длинной истории (compaction) сохраняйте выполненные действия, активные предположения, идентификаторы, результаты инструментов, блокеры и следующую цель.

Формат ответа задаётся отдельно от глубины рассуждения

text.verbosity управляет длиной видимого ответа. Значение по умолчанию — medium; для компактного интерфейса проверьте low. Качество рассуждения и длина финального текста настраиваются независимо.

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

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

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

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

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

Валидация завершает работу

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

Для кода:

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

Для агентского сценария проверяйте аргументы инструментов, разрешённые побочные эффекты, обработку ошибок и условия остановки.

Эталонный каркас системного промпта

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

# Personality
[тон и пользовательское впечатление]

# Collaboration style
[уточнения, предположения, проактивность и риск]

# Goal
[видимый результат]

# Success criteria
[проверяемые условия готовности]

# Constraints
[политика, безопасность, доказательства и побочные эффекты]

# Tools
[общие правила, действующие для нескольких инструментов]

# Output
[форма, аудитория и длина]

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

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

Чеклист быстрой проверки

Автоматическая миграция через Codex

OpenAI Docs skill для Codex может применить рекомендуемые изменения к промптам проекта:

$openai-docs migrate this project to gpt-5.5

После автоматической правки проверьте продуктовые инварианты и выполните оценочные прогоны (evals). Для API-сценария обновите model slug на gpt-5.5 и используйте Responses API для задач с рассуждением, инструментами или несколькими ходами.

Источник

• Using GPT-5.5 — OpenAI — рекомендации по миграции, prompting, Responses API, уровню рассуждения, verbosity и инструментам.

Следующий шаг

Контекст-инжиниринг — как собирать рабочий контекст для моделей нового поколения

Связанные материалы

• Статья: Codex, Саркис и два месяца боли: как я наконец-то собрал рабочую инфраструктуру ИИ-агентов
• Блог: GPT-5.5 вышла — OpenAI снова двигает планку и ставит на агентов
• База знаний: OpenAI Responses API — единый интерфейс для агентских приложений

Если вы переводите производственный сценарий на GPT-5.5, полезно отдельно обсудить контракт результата, набор инструментов и тесты на ваших примерах.

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