Как писать промпты для ChatGPT 5.5 - полный гайд

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

Как писать промпты для ChatGPT 5.5 - полный гайд

Здесь - всё, что отлично работает. Личность ассистента, outcome-first промпты, управление форматом, grounding, верификационные циклы, reasoning_effort и нюансы более мелких моделей. Готовые блоки, которые можно вставить в системный промпт и проверить прямо сейчас.

GPT-5.5 - что изменилось и как это учитывать

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

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

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

Если вы давно хотели протестировать эту крутую модель, но вам лень заморачиваться с ограничением доступа в РФ и иностранной подпиской - ChatGPT 5.5 доступен через SYNTX AI.

Промокод NEIROSKUF - минус 15% на любой тариф.

Personality - как настроить характер модели

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

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

Пример для сдержанного ассистента, ориентированного на задачу:

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

Пример для выразительного ассистента с характером:

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

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

Preamble: первый видимый ответ

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

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

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

Для агентов с раздельными фазами сообщений - можно точнее:

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

Outcome-first - описывай результат, а не шаги

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

Вместо того чтобы расписывать каждое действие - описывай назначение. Предпочитай это:

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

Избегай абсолютных правил без реальной нужды. Слова ALWAYS, NEVER, must, only - оставляй для истинных инвариантов: правил безопасности, обязательных полей вывода, действий, которые никогда не должны происходить. Для суждений - предпочитай правила принятия решений.

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

Разрешай запрос пользователя за минимальное полезное число итераций с инструментами, но не позволяй минимизации циклов превалировать над корректностью. После каждого результата спрашивай: "Могу ли я ответить на основной запрос пользователя сейчас?" Если да - отвечай.

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

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

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

GPT-5.5 хорошо управляема по формату и структуре. Параметр text.verbosity в Responses API по умолчанию стоит на medium; используй low для более кратких ответов.

Базовый блок для разговорного форматирования:

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

Для редактирования, рерайта или клиентских сообщений - говори, что сохранить, перед тем как просить улучшить стиль:

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

Grounding и цитирование

Когда качество цитирования важно - делай границу источника и формат требования явными. Это снижает фабрикацию ссылок и дрейф формата.

<правила_цитирования> - Цитируй только источники, полученные в текущем рабочем процессе. - Никогда не придумывай ссылки, URL, ID или цитатные фрагменты. - Используй именно тот формат цитирования, который требует хост-приложение. - Прикрепляй цитаты к конкретным утверждениям, которые они поддерживают, а не только в конце. </правила_цитирования>
<правила_обоснования> - Базируй утверждения только на предоставленном контексте или результатах инструментов. - Если источники противоречат друг другу - назови противоречие явно и атрибутируй каждую сторону. - Если контекст недостаточен или нерелевантен - сузь ответ или скажи, что не можешь подтвердить утверждение. - Если утверждение является выводом, а не прямо поддерживаемым фактом - пометь его как вывод. </правила_обоснования>

Бюджет поиска - правила остановки для web search. Говорят модели, когда доказательств уже достаточно:

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

Режим исследования

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

<режим_исследования> - Делай исследование в 3 прохода: 1) Планирование: перечисли 3-6 подвопросов для ответа. 2) Поиск: ищи каждый подвопрос и следуй 1-2 связанным направлениям второго порядка. 3) Синтез: разреши противоречия и напиши финальный ответ с цитатами. - Останавливайся только тогда, когда дополнительный поиск вряд ли изменит вывод. </режим_исследования>

Самопроверка и верификация

Давай модели инструменты для проверки результатов. Для кодинг-агентов:

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

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

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

Верификационный цикл перед любым значимым действием:

<цикл_верификации> Перед финализацией: - Проверь корректность: удовлетворяет ли вывод каждому требованию? - Проверь обоснование: подтверждены ли фактические утверждения предоставленным контекстом или результатами инструментов? - Проверь форматирование: соответствует ли вывод запрошенной схеме или стилю? - Проверь безопасность и необратимость: если следующий шаг имеет внешние побочные эффекты - запроси разрешение сначала. </цикл_верификации>

GPT-5.4 - промпт-паттерны для продакшна

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

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

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

Структура промпта для сложных задач

Роль: [1-2 предложения, определяющие функцию модели, контекст и задачу] # Личность [тон, поведение и стиль взаимодействия] # Цель [видимый пользователю результат] # Критерии успеха [что должно быть истинно перед финальным ответом] # Ограничения [политика, безопасность, бизнес, доказательства и ограничения побочных эффектов] # Вывод [разделы, длина и тон] # Правила остановки [когда повторять, откатываться, воздерживаться, спрашивать или останавливаться]

Компактный структурированный вывод

Для контроля токен-эффективности - явный контракт на вывод:

<контракт_вывода> - Возвращай именно запрошенные разделы в запрошенном порядке. - Если промпт определяет преамбулу, блок анализа или рабочий раздел - не считай их лишним выводом. - Применяй ограничения длины только к тому разделу, для которого они предназначены. - Если требуется формат (JSON, Markdown, SQL, XML) - выводи только этот формат. </контракт_вывода> <контроль_краткости> - Предпочитай лаконичное, информационно плотное письмо. - Не повторяй запрос пользователя. - Держи обновления о прогрессе краткими. - Не сокращай ответ настолько агрессивно, что обязательные доказательства или проверки выпадают. </контроль_краткости>

Политика продолжения по умолчанию

Пользователи часто меняют задачу, формат или тон в середине разговора. Чтобы ассистент оставался согласованным:

<политика_продолжения> - Если намерение пользователя ясно, а следующий шаг обратим и низкорискован - действуй без вопросов. - Спрашивай разрешения только если следующий шаг: (а) необратим, (б) имеет внешние побочные эффекты (отправка, покупка, удаление, запись в продакшн), или (в) требует отсутствующей чувствительной информации или выбора, который существенно изменит исход. - Если действуешь - кратко назови что сделал и что остаётся опциональным. </политика_продолжения>

Для явного обновления задачи в середине разговора:

<обновление_задачи> Только для следующего ответа: - Не выполняй задачу. - Только составь план. - Ограничься 5 пунктами. Все ранние инструкции сохраняются, если не конфликтуют с этим обновлением. </обновление_задачи>

Устойчивость использования инструментов

Для рабочих процессов, где финальное действие зависит от предварительного поиска:

<правила_устойчивости_инструментов> - Используй инструменты всегда, когда они существенно улучшают корректность, полноту или обоснованность. - Не останавливайся раньше времени, когда ещё один вызов инструмента вероятно улучшит результат. - Продолжай вызывать инструменты до тех пор, пока: (1) задача завершена, и (2) верификация пройдена. - Если инструмент возвращает пустые или частичные результаты - повтори с другой стратегией. </правила_устойчивости_инструментов>
<проверки_зависимостей> - Перед выполнением действия проверь, нужны ли предварительные шаги обнаружения, поиска или извлечения. - Не пропускай предварительные шаги только потому, что конечное действие кажется очевидным. - Если задача зависит от вывода предыдущего шага - разреши эту зависимость сначала. </проверки_зависимостей>

Для параллельного поиска:

<параллельные_вызовы_инструментов> - Когда несколько шагов поиска независимы - предпочитай параллельные вызовы для снижения времени ответа. - Не распараллеливай шаги с зависимостями или где один результат определяет следующее действие. - После параллельного поиска - сделай паузу для синтеза результатов перед дополнительными вызовами. - Предпочитай избирательный параллелизм: параллелизируй независимый сбор доказательств, но не спекулятивное использование инструментов. </параллельные_вызовы_инструментов>

Полнота при долгосрочных задачах

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

<контракт_полноты> - Считай задачу незавершённой до тех пор, пока все запрошенные элементы не охвачены или явно не помечены [заблокировано]. - Веди внутренний чеклист необходимых результатов. - Для списков, батчей или пагинированных результатов: определяй ожидаемый охват, отслеживай обработанные элементы, подтверждай покрытие перед финализацией. - Если элемент заблокирован отсутствующими данными - пометь его [заблокировано] и назови точно, чего не хватает. </контракт_полноты>

При пустых или частичных результатах поиска:

<восстановление_при_пустом_результате> Если поиск возвращает пустые, частичные или подозрительно узкие результаты: - не делай немедленного вывода об отсутствии результатов - попробуй хотя бы одну-две запасные стратегии: другие формулировки запроса, более широкие фильтры, предварительный поиск, альтернативный источник или инструмент - только тогда сообщай об отсутствии результатов с указанием того, что было опробовано </восстановление_при_пустом_результате>

Цитирование как требование, а не желание

<правила_цитирования> - Цитируй только источники, полученные в текущем рабочем процессе. - Никогда не придумывай ссылки, URL, ID или цитатные фрагменты. - Используй именно тот формат цитирования, который требует хост-приложение. - Прикрепляй цитаты к конкретным утверждениям, которые они поддерживают, а не только в конце. </правила_цитирования>

Параметр reasoning_effort - как не переплачивать

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

Рекомендуемые дефолты:

  • none - быстрые, чувствительные к стоимости и латентности задачи без необходимости думать.
  • low - задачи с чувствительностью к латентности, где небольшое количество мышления даёт ощутимый прирост точности.
  • medium / high - задачи, которым реально нужно более сильное рассуждение и которые могут поглотить компромисс по задержке и стоимости.
  • xhigh - избегать как дефолт. Подходит для длинных агентных задач, где максимальный интеллект важнее скорости.

На практике большинству команд стоит держаться диапазона none, low, medium. Перед повышением reasoning_effort сначала добавляй <контракт_полноты>, <цикл_верификации> и <правила_устойчивости_инструментов>.

Если модель кажется слишком буквальной или останавливается на первом правдоподобном ответе - сначала попробуй:

<толчок_глубже> - Не останавливайся на первом правдоподобном ответе. - Ищи проблемы второго порядка, крайние случаи и упущенные ограничения. - Если задача критична по безопасности или точности - выполни хотя бы один шаг верификации. </толчок_глубже>

Маленькие модели - gpt-5.4-mini и gpt-5.4-nano

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

GPT-5.4-mini

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

Как промптить: ставь критические правила первыми. Задавай полный порядок выполнения когда инструменты или побочные эффекты важны. Не полагайся на "ты ДОЛЖЕН" в одиночку - используй структурные леса: нумерованные шаги, правила принятия решений, явные определения действий. Разделяй "выполни действие" от "сообщи о действии". Пиши корректный флоу, а не только финальный формат. Определяй поведение при неоднозначности: когда спрашивать, воздерживаться или действовать. Указывай упаковку явно: длина ответа, задавать ли вопрос в конце, стиль цитирования, порядок разделов.

Хороший паттерн для mini (и nano):

  1. Задача
  2. Критическое правило
  3. Точный порядок шагов
  4. Граничные случаи или поведение при уточнении
  5. Формат вывода
  6. Один корректный пример

GPT-5.4-nano

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

Миграция: по одному изменению за раз

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

Стартовые точки при переходе с разных предыдущих версий: с gpt-5.2 и gpt-4.1 начинай с medium, с gpt-4o - с high. Это точки входа, не финальные настройки.

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

Источник - Open Ai

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

6
2
1 комментарий