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

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

Когда вы нанимаете старшего специалиста, вы говорите по-другому: «нужно обработать заявку клиента — вот политика, вот доступ к данным, вот формат ответа». Что делать в каждый момент — он решает сам, потому что вы платите ему именно за это.

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

Эта статья — мой разбор официального Prompt guidance от OpenAI с локализацией под русскоязычного практика. Я не пересказываю оригинал — я объясняю, что важно, что необязательно и где люди реально спотыкаются.

Прежде чем начать: про язык промптов

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

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

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

Глоссарий — чтобы потом не спотыкаться

• Outcome-first промпт — промпт, где описан результат, а не процесс. «Реши проблему клиента» вместо «сначала проверь это, потом то».
• Tool calls — вызовы инструментов: модель не просто отвечает, а вызывает функцию (поиск, БД, API), получает результат и продолжает работать.
• Responses API — современный API OpenAI для агентских сценариев, где модель может многократно вызывать инструменты в рамках одного запроса.
• Phase — параметр в Responses API, который отличает промежуточные апдейты модели от финального ответа.
• Reasoning effort — настройка глубины рассуждения модели: low / medium / high.
• Retrieval budget — правило, которое говорит модели, когда хватит искать и пора отвечать.
• Preamble — короткое первое сообщение модели до того, как она пошла работать с инструментами. Нужно для UX в стриминге.
• Stopping conditions — условия, при которых модель должна остановить итерации и дать финальный ответ.

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

Что изменилось в GPT-5.5 — и почему ваши старые промпты теперь работают хуже

Главное: модель стала лучше сама выбирать путь к ответу. Поэтому промпты, написанные под GPT-4 и GPT-5.4, для неё балласт.

• Короткие outcome-first промпты выигрывают у многослойных стеков инструкций. Огромный системный промпт с десятками правил «сначала / потом / в случае X / в случае Y» теперь скорее мешает, чем помогает.
• Reasoning стал эффективнее. Прежде чем эскалировать с low на medium и с medium на high, проверьте более низкие уровни: для большинства задач они теперь достаточны.
• Преамбулы, phase, replay assistant items остаются критичными для агентских workflow с инструментами. Это пункты, которые трогать не нужно — они работают как раньше.
• Личность, retrieval budget и валидация — новые точки контроля для клиентских и агентских продуктов. Именно их теперь нужно прописывать явно.

Reasoning effort: не эскалируйте раньше времени

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

Личность модели и стиль работы

По умолчанию GPT-5.5 — эффективная, прямая, ориентированная на задачу. Для production-систем это плюс: ответы фокусированные, поведение предсказуемое, никакой болтовни ради болтовни.

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

Personality — как модель звучит

Тон, теплота, прямота, формальность, юмор, уровень эмпатии. Это слой пользовательского опыта.

Collaboration style — как модель работает

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

Эти два слоя нельзя смешивать. Если вы прописываете «модель тёплая и эмпатичная», но не уточняете, должна ли она задавать вопросы или сама принимать решения — получите тёплого, но парализованного ассистента.

Пример: спокойный, task-focused ассистент

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

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

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

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

Что здесь часто пропускают: блок «предпочитай двигаться вперёд, а не останавливаться ради уточнений». Без него модель скатывается в бесконечные уточняющие вопросы, и пользователь злится. С ним — двигается вперёд на разумных предположениях.

Пример: выразительный, коллаборативный ассистент

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

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

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

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

Outcome-first промпт: главное изменение в подходе

Сильнее всего GPT-5.5 работает, когда промпт описывает что должно получиться, а не что нужно сделать.

Как нужно

Реши вопрос клиента от начала до конца.

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

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

Как не нужно

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

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

Жёсткие правила — только для инвариантов

Жёсткие формулировки — ВСЕГДА, НИКОГДА, «обязан», «только» (в англоязычных промптах — ALWAYS, NEVER, must, only) — оставьте для случаев, где альтернативы быть не должно: правила безопасности, обязательные поля вывода, запрещённые действия.

Для всего остального — decision rules (решающие правила, отдающие выбор модели).

Stopping conditions — обязательно

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

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

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

Поведение при нехватке данных

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

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

Преамбула: ускоряем время до первого видимого ответа

В стриминговых интерфейсах пользователь видит тишину ровно столько, сколько модель думает и готовит первый tool call. Для агентских сценариев это могут быть десятки секунд. Воспринимается как «висит».

Решение — заставить модель сначала отправить короткое видимое сообщение, потом уже работать.

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

Когда применять: задача требует более одного шага, есть tool calls, длительный workflow.

Когда не применять: короткие однотурные ответы — преамбула там превратится в шум.

Для агентов с явными message phases можно жёстче:

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

Форматирование вывода

text.verbosity — главная ручка для управления длиной ответа. По умолчанию medium, для коротких ответов — low. С этого стоит начинать тюнинг, прежде чем накручивать инструкции про длину в промпте.

Дефолт для разговорного UI

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

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

Для бизнес-аудитории

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

«Сначала вывод, потом обоснование, потом оговорки» — формула, под которую руководители читают по диагонали. Если у вас B2B-продукт для C-level — встройте её в системный промпт.

Для редактирования и рерайтов

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

Эта инструкция спасает от любимой проблемы LLM: вы говорите «отредактируй мой текст» — модель его удлиняет, добавляет разделы, переписывает под маркетинговый тон. С этой инструкцией — не делает.

Retrieval budget: когда модели хватит искать

Это правила остановки для поиска. Без них агент с доступом к web search или RAG может уйти на 5–10 запросов там, где хватило бы одного.

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

Делай повторный поиск только когда:
- Верхние результаты не отвечают на основной вопрос.
- Не хватает нужного факта, параметра, ответственного, даты, ID или
  источника.
- Пользователь попросил исчерпывающий охват, сравнение или полный
  список.
- Нужно прочитать конкретный документ, URL, письмо, встречу, запись
  или фрагмент кода.
- Иначе в ответе окажется важное неподтверждённое утверждение.

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

Последний абзац — самый важный. Он отрезает «давай ещё поищу для красоты». Именно из-за его отсутствия в legacy-промптах агенты делают по семь поисков на простой вопрос.

Цитирование: что и как подтверждать

Retrieval budget отвечает на вопрос «когда хватит искать», а правила цитирования — на вопрос «что именно нужно подтверждать источником». OpenAI выносит это в отдельный сюжет, и для grounded-продуктов (поддержка, ассистенты по базе знаний, аналитика) это стоит прописывать явно.

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

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

Ключевой принцип тот же, что и в retrieval budget: подтверждай факты, а не формулировки. Если строчку можно сделать чуть более общей и она от этого не теряет смысл — источник для неё не нужен.

Креативные задачи: разделяем факты и креатив

Это правило для слайдов, лидерских блёрбов, маркетинговой копирайтинговой задачи, summary для шаринга, нарративной обвязки.

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

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

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

Валидация: заставьте модель проверять свою работу

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

Для кодинга

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

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

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

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

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

Для планирования

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

Параметр phase для длинных workflow

Это пункт для тех, кто работает с Responses API напрямую. Если используете готовый SDK или интерфейс типа ChatGPT — пропускайте.

В длительных или tool-heavy workflow Responses API использует значения phase у assistant-сообщений, чтобы отличать промежуточные апдейты от финальных ответов:

• phase: "commentary" — промежуточные видимые обновления
• phase: "final_answer" — готовый ответ

Если вы используете previous_response_id, API хранит состояние сам — ничего делать не нужно. Если вы вручную реплеите assistant output items в следующий запрос — сохраняйте оригинальные значения phase без изменений. Иначе модель потеряет контекст того, что она уже сделала.

К user-сообщениям phase не добавляется.

Frontend и интерфейсы

Отдельный кусок оригинального руководства посвящён фронтенду: как просить модель про UI-качество, design-system alignment, поведение на первом экране, привычные контролы, ожидаемые состояния и респонсивность. Если у вас задача — генерация UI или фронтенд-кода, читайте отдельно example instructions в документации OpenAI — это самостоятельный сюжет, который я здесь не разворачиваю.

Но один практический список стоит держать под рукой — типовые дефолты сгенерированного UI, которые лучше явно запрещать в промпте:

• Общие hero-секции — безликий крупный баннер сверху ради «солидности»
• Вложенные карточки — карточка внутри карточки внутри карточки
• Декоративные градиенты — фоновые переливы без функции
• Видимый инструктивный текст — подписи вида «здесь будет ваш контент», утёкшие в финальный UI
• Сломанные раскладки — поехавшие сетки, наезжающие элементы, неработающая адаптивность

Явно перечислите эти пункты как «не делай» — и качество генерации заметно вырастет.

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

Полезный практический инструмент: OpenAI выпустил Docs Skill для Codex, который автоматически переписывает промпты вашего проекта под GPT-5.5. Команда:

$openai-docs migrate this project to gpt-5.5

Это не серебряная пуля — после автоматической миграции промпты всё равно нужно прочитать глазами. Но как стартовая точка для большого legacy-стека — экономит часы.

Каркас системного промпта

OpenAI предлагает следующую структуру. Это не догма — это начальная точка, которую вы адаптируете под продукт.

Role: [1–2 предложения: функция модели, контекст и задача]

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

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

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

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

# Output
[разделы, длина и тон]

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

Главное правило: каждая секция короткая. Если в Constraints у вас 30 правил — половина из них либо устарела, либо должна быть в Goal, либо в Success criteria. Перечитайте.

Пример миграции: было → стало

Покажу на типичной задаче — ассистент поддержки, отвечающий по базе знаний. Вот легаси-промпт в старом стиле:

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

Что здесь не так для GPT-5.5: расписан процесс по шагам, ВСЕГДА навязывает лишний второй поиск, нет критериев результата и условий остановки. Модель будет механически отыгрывать сценарий даже там, где ответ очевиден с первого результата.

То же самое в outcome-first стиле:

# Goal
Реши вопрос пользователя по базе знаний.

# Success criteria
- Ответ опирается на найденные статьи и подтверждён ссылкой на них.
- Если в базе нет ответа — честно скажи об этом и предложи, куда
  обратиться дальше, без выдуманных деталей.

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

# Stop
Как только можешь ответить по сути с опорой на источник —
отвечай, не накручивая лишние итерации.

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

Чек-лист для миграции старого промпта

Вместо заключения

Главное смещение в подходе — от режиссуры процесса к постановке задачи. Раньше мы писали модели сценарий. Теперь пишем ТЗ. Сценарий теперь сужает её возможности; ТЗ — расширяет.

Если из всей статьи запомнить три вещи:

1. Описывайте результат, а не процесс.
2. Жёсткие правила — только для инвариантов; всё остальное — decision rules.
3. Ставьте явные условия остановки — для рассуждения, для поиска, для итераций.

Всё остальное — настройки и оттенки.

Ссылки

• GPT-5.5 Prompting Guide — OpenAI — оригинальное руководство, на основе которого написана эта статья
• Using GPT-5.5 Guide — OpenAI — детали поведения GPT-5.5

По теме

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

Если вы строите продукты на OpenAI API и хотите разобраться, как перевести промпты на GPT-5.5 без потери качества — давайте обсудим.