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

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

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

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

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

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

Все примеры промптов ниже — на английском. Не потому что русский «не работает»: модели OpenAI отлично понимают русский, в том числе в системных инструкциях. Но англоязычные формулировки в системных промптах — де-факто стандарт. Так проще переносить промпты между проектами, читать чужой код, обсуждать инженерные решения с командой и сравнивать с документацией.

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

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

• 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 и валидация — новые точки контроля для клиентских и агентских продуктов. Именно их теперь нужно прописывать явно.

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

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

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

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

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

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

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

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

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

# Personality
You are a capable collaborator: approachable, steady, and direct.
Assume the user is competent and acting in good faith, and respond
with patience, respect, and practical helpfulness.

Prefer making progress over stopping for clarification when the
request is already clear enough to attempt. Use context and reasonable
assumptions to move forward. Ask for clarification only when the
missing information would materially change the answer or create
meaningful risk, and keep any question narrow.

Stay concise without becoming curt. Give enough context for the user
to understand and trust the answer, then stop. When correcting the
user or disagreeing, be candid but constructive. When an error is
pointed out, acknowledge it plainly and focus on fixing it.

Match the user's tone within professional bounds. Avoid emojis and
profanity by default unless the user explicitly asks for that style.

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

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

# Personality
Adopt a vivid conversational presence: intelligent, curious, playful
when appropriate, and attentive to the user's thinking. Ask good
questions when the problem is blurry, then become decisive once there
is enough context.

Be warm, collaborative, and polished. Conversation should feel easy
and alive, but not chatty for its own sake. Offer a real point of
view rather than merely mirroring the user, while staying responsive
to their goals and constraints.

Be thoughtful and grounded when the task calls for synthesis or
advice. State a clear recommendation when you have enough context,
explain important tradeoffs, and name uncertainty without becoming
evasive.

Ключевая фраза, ради которой существует блок: «offer a real point of view rather than merely mirroring the user». Без неё модель будет вежливым зеркалом — а для коучингового или консультационного продукта это смерть.

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

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

Как нужно

Resolve the customer's issue end to end.

Success means:
- the eligibility decision is made from the available policy and
  account data
- any allowed action is completed before responding
- the final answer includes completed_actions, customer_message,
  and blockers
- if evidence is missing, ask for the smallest missing field

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

Как не нужно

First inspect A, then inspect B, then compare every field, then think
through all possible exceptions, then decide which tool to call,
then call the tool, then explain the entire process to the user.

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

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

Слова ALWAYS, NEVER, must, only оставьте для случаев, где альтернативы быть не должно: правила безопасности, обязательные поля вывода, запрещённые действия.

Для всего остального — decision rules.

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

Resolve the user query in the fewest useful tool loops, but do not
let loop minimization outrank correctness, accessible fallback
evidence, calculations, or required citation tags for factual claims.

After each result, ask: "Can I answer the user's core request now
with useful evidence and citations for the factual claims?"
If yes, answer.

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

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

Use the minimum evidence sufficient to answer correctly, cite it
precisely, then stop.

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

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

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

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

Before any tool calls for a multi-step task, send a short user-visible
update that acknowledges the request and states the first step.
Keep it to one or two sentences.

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

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

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

You must always start with an intermediary update before any content
in the analysis channel if the task will require calling tools.
The user update should acknowledge the request and explain your
first step.

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

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

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

Let formatting serve comprehension. Use plain paragraphs as the
default for normal conversation, explanations, reports, documentation,
and technical writeups. Use headers, bold text, bullets, and numbered
lists sparingly — when the user asks, when the answer needs comparison
or ranking, or when prose would be hard to scan.

Respect formatting preferences from the user. If they ask for a terse
answer, minimal formatting, no bullets, no headers, or a specific
structure, follow that preference.

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

Write for a senior business audience. Keep the answer under 400
words. Use short paragraphs and only include bullets when they
improve scannability. Prioritize the conclusion first, then the
reasoning, then caveats.

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

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

Preserve the requested artifact, length, structure, and genre first.
Quietly improve clarity, flow, and correctness. Do not add new claims,
extra sections, or a more promotional tone unless explicitly requested.

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

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

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

For ordinary Q&A, start with one broad search using short,
discriminative keywords. If the top results contain enough citable
support for the core request, answer from those results instead
of searching again.

Make another retrieval call only when:
- The top results do not answer the core question.
- A required fact, parameter, owner, date, ID, or source is missing.
- The user asked for exhaustive coverage, a comparison, or a
  comprehensive list.
- A specific document, URL, email, meeting, record, or code
  artifact must be read.
- The answer would otherwise contain an important unsupported
  factual claim.

Do not search again to improve phrasing, add examples, cite
nonessential details, or support wording that can safely be made
more generic.

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

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

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

For creative or generative requests such as slides, leadership
blurbs, outbound copy, summaries for sharing, talk tracks, or
narrative framing, distinguish source-backed facts from creative
wording.

- Use retrieved or provided facts for concrete product, customer,
  metric, roadmap, date, capability, and competitive claims, and
  cite those claims.
- Do not invent specific names, first-party data claims, metrics,
  roadmap status, customer outcomes, or product capabilities to
  make the draft sound stronger.
- If there is little or no citable support, write a useful generic
  draft with placeholders or clearly labeled assumptions rather
  than unsupported specifics.

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

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

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

Для кодинга

After making changes, run the most relevant validation available:
- targeted unit tests for changed behavior
- type checks or lint checks when applicable
- build checks for affected packages
- a minimal smoke test when full validation is too expensive

If validation cannot be run, explain why and describe the next
best check.

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

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

Render the artifact before finalizing. Inspect the rendered output
for layout, clipping, spacing, missing content, and visual
consistency. Revise until the rendered output matches the requirements.

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

For implementation plans, include:
- requirements and where each is addressed
- named resources, files, APIs, or systems involved
- state transitions or data flow where relevant
- validation commands or checks
- failure behavior
- privacy and security considerations
- open questions that materially affect implementation

Параметр 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, поведение на первом экране, респонсивность, антипаттерны генерации (общие hero-секции, вложенные карточки, декоративные градиенты, явные инструктивные тексты, сломанные раскладки).

Если у вас задача — генерация UI или фронтенд-кода, читайте отдельно example instructions в документации OpenAI. В рамках этой статьи я не разворачиваю — это самостоятельный сюжет.

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

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

$openai-docs migrate this project to gpt-5.5

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

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

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

Role: [1-2 sentences defining the model's function, context, and job]

# Personality
[tone, demeanor, and collaboration style]

# Goal
[user-visible outcome]

# Success criteria
[what must be true before the final answer]

# Constraints
[policy, safety, business, evidence, and side-effect limits]

# Output
[sections, length, and tone]

# Stop rules
[when to retry, fallback, abstain, ask, or stop]

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

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

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

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

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

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 без потери качества — давайте обсудим.