Как теперь ставить задачи GPT-5.6: меньше микроменеджмента, больше результата и границ

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

Если модель пропустила требование, добавить еще одно правило. Если задала лишний вопрос, запретить вопросы. Если сделала мало, приказать «думать максимально глубоко». Если вышла за рамки, расписать процесс по шагам.

Так постепенно инструкция превращается в длинный архив прошлых ошибок.

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

Главный принцип новой постановки задачи:

Меньше описывать модели ритуал работы. Точнее задавать результат, границы автономности, критерии готовности и способ проверки.

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

Уровень 1. Как ставить задачу в обычном ChatGPT

Начинайте не с роли, а с результата

Слабый запрос:

Ты лучший эксперт по управлению. Проведи максимально глубокий анализ.

Сильнее:

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

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

Не заставляйте модель выполнять обязательный ритуал

Устаревший шаблон:

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

Такой запрос создает четыре проблемы:

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

Рабочий вариант:

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

Управляйте не длиной, а обязательным содержанием

Фраза «будь максимально кратким» часто приводит к потере оговорок, источников и следующего шага.

Вместо нее лучше написать:

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

Так вы объясняете, что можно сократить, а что нельзя потерять.

Разрешайте обратимые допущения

Абсолютный запрет «ничего не предполагай» заставляет модель задавать вопросы даже там, где можно безопасно продолжить.

Рабочее правило:

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

Задавайте критерии готовности

«Сделай хорошо» не является критерием.

Для статьи критерии могут быть такими:

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

Для документа:

• заполнены обязательные разделы;
• неизвестные параметры помечены TO_CONFIRM;
• числа сверены с источником;
• выводы не противоречат входным материалам.

Просите проверку результата, а не демонстрацию мыслей

Надежность не появляется от длинного рассказа о процессе рассуждения.

Полезнее попросить:

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

Десять анти-паттернов старых запросов

1. Всегда думай шаг за шагом. Заменить на критерии качества и проверку.
2. Всегда сначала показывай подробный план. План нужен только для реально многошаговой задачи.
3. Всегда задавай вопросы. Уточнение нужно только при существенной неоднозначности.
4. Никогда ничего не предполагай. Разрешить безопасные и обратимые допущения.
5. Всегда жди подтверждения. Остановки нужны на рисковых действиях, а не после каждого шага.
6. Будь максимально кратким. Указать обязательное содержимое, которое нельзя потерять.
7. Используй максимум интеллекта. Выбирать reasoning в интерфейсе или конфигурации.
8. Дай ровно три варианта. Варианты нужны только при реальном выборе и trade-offs.
9. Повтори одно правило в нескольких разделах. Оставить единый источник правды.
10. Сделай все максимально подробно. Задать нужный уровень глубины и конкретный формат.

Десять примеров «до - после»

1. Исследование

До:

Исследуй тему максимально глубоко и подробно. Ничего не пропускай.

После:

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

2. Письмо

До:

Напиши идеальное продающее письмо как лучший копирайтер мира.

После:

Напиши письмо после демо. Цель - получить конкретный ответ о следующем шаге. Тон спокойный, без давления. До 120 слов. Укажи, что уже понятно, что осталось согласовать и какой ответ нужен.

3. Совещание

До:

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

После:

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

4. Документ

До:

Сделай ТЗ максимально полным.

После:

Подготовь ТЗ, которое разработчик сможет выполнить без уточнений. Включи scope, exclusions, интеграции, критерии приемки, тестирование и rollback. Недостающие бизнес-параметры пометь TO_CONFIRM.

5. Анализ бизнеса

До:

Думай как стратег и найди все точки роста.

После:

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

6. Код

До:

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

После:

Исправь указанную ошибку. Не меняй соседнюю архитектуру без необходимости. Сохрани перечисленную функциональность. Запусти релевантные тесты и перечисли измененные файлы.

7. Краткий ответ

До:

Ответь максимально коротко.

После:

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

8. Неоднозначная задача

До:

Сначала задай мне все вопросы.

После:

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

9. Проверка

До:

Будь точным и не ошибайся.

После:

Перед финалом сверь каждое число с источником, проверь соответствие формату и перечисли неподтвержденные утверждения.

10. Reasoning

До:

Используй максимальное размышление и Pro.

После:

В ChatGPT выбери подходящий режим в интерфейсе. В API настрой reasoning.effort и при необходимости reasoning.mode, а в тексте оставь цель, ограничения и критерии результата.

Компактный шаблон запроса для GPT-5.6

Цель:
<какой результат нужен>

Аудитория и контекст:
<кто будет использовать результат и что важно знать>

Обязательные требования:
- <что нельзя потерять>
- <какие факты или источники обязательны>
- <что запрещено>

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

Критерии готовности:
- <критерий 1>
- <критерий 2>
- <критерий 3>

Формат:
<структура и длина>

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

Чек-лист самопроверки запроса

Перед отправкой проверьте:

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

Уровень 2. Custom GPTs, Codex и API-агенты

Для агента одного хорошего пользовательского запроса недостаточно. Нужно разделить уровни управления.

Поведение - в instructions или policy layer

Правила вроде «не отправлять письмо без подтверждения», «не менять production» или «опираться сначала на файлы проекта» должны находиться в управляющей инструкции, AGENTS.md, skill или guardrail.

Knowledge-файл лучше использовать как справочник, а не как единственное место для поведения.

Изменяемые факты - в файлы и инструменты

Цены, лимиты, регламенты, клиенты и текущие статусы быстро устаревают.

Их лучше получать через:

• retrieval;
• файлы;
• базы данных;
• API;
• коннекторы;
• MCP.

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

Reasoning и Pro - в конфигурацию

Официальная guidance OpenAI рекомендует управлять effort параметром. Для GPT-5.6 доступны уровни от none до max. При миграции полезно сохранить текущий baseline и сравнить его с уровнем ниже.

Если в Responses API нужен Pro mode, он включается через reasoning.mode: "pro", а не фразой внутри запроса.

Инструменты - только релевантные

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

Для конкретного run лучше отдавать только те tools, которые действительно могут понадобиться. Описания должны быть короткими, точными и согласованными со schema.

Границы автономности - явно

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

Нужно разделить:

• безопасные read-only действия;
• локальные обратимые изменения;
• внешние записи;
• финансовые действия;
• разрушительные операции;
• расширение scope.

Первые две категории часто можно разрешить автономно. Остальные требуют approval в зависимости от процесса.

Completion criteria

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

Например:

• выполнены все acceptance criteria;
• тесты прошли;
• нет необработанных ошибок;
• подготовлен итоговый артефакт;
• перечислены ограничения;
• external action не выполнен без approval.

Без stop conditions агент либо остановится рано, либо продолжит улучшать результат без конца.

Validation и evals

Фраза «будь точным» не заменяет тесты.

Для повторяемого агента нужны:

• golden examples;
• regression cases;
• проверки схемы;
• graders;
• trace review;
• метрики полноты, точности и стоимости;
• порог pass/fail.

Что оставить, удалить, переписать и перенести

Оставить

• бизнес-цель;
• аудиторию;
• hard constraints;
• безопасность;
• требования к доказательности;
• формат результата;
• критерии приемки.

Удалить

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

Переписать

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

Перенести в параметры

• модель;
• reasoning effort;
• Pro mode;
• verbosity;
• reasoning context.

Перенести в инфраструктуру

• approval flow;
• sandbox;
• доступы;
• schema;
• routing;
• feature flags;
• monitoring;
• rollback;
• evals.

Добавить

• autonomy policy;
• approval boundaries;
• completion criteria;
• validation;
• escalation rules;
• измеряемые критерии качества.

Компактный шаблон инструкции агента

<MISSION>
Выполнять <бизнес-задача> для <аудитория>.

<SCOPE>
Входит: <scope>.
Не входит: <out of scope>.

<OUTCOME>
Готовый результат: <deliverable>.

<HARD_CONSTRAINTS>
- <критичное ограничение>
- <критичное ограничение>

<AUTONOMY_POLICY>
Разрешено автономно: чтение, локальные обратимые действия, анализ и проверка.
Требуется approval: внешние записи, destructive actions, расходы и расширение scope.

<TOOLS>
Используй только релевантные инструменты. Не повторяй завершенные вызовы.

<EVIDENCE_AND_VALIDATION>
Проверяй результат по <источники/тесты/рубрика>.

<COMPLETION_CRITERIA>
Задача завершена, когда <условия done>.

<OUTPUT_CONTRACT>
<формат результата>

<ESCALATION>
Эскалируй только при blocker, approval boundary или отсутствии критичного входа.

Важная граница

Более короткая инструкция не является автоматически лучшей.

Цель миграции - не минимизировать количество символов. Цель - убрать prompt debt и разместить каждое требование в правильном управляющем слое.

Новая модель не отменяет дисциплину. Она меняет ее место:

меньше процедурного текста, больше явной политики автономности, конфигурации и проверок.

Следующая статья - о том, как превратить эти принципы в программу миграции примерно 50 агентов.

Навигация по серии

• Предыдущая статья: Почему одна задача расходует 1%, а другая 10%
• Следующая статья: Как пересобрать около 50 агентов после выхода GPT-5.6
• Страница всей серии

FAQ

Нужно ли теперь писать только короткие промты?

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

Нужно ли перестать просить модель планировать?

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

Можно ли текстом попросить включить максимальный reasoning?

В обычном ChatGPT режим выбирается в интерфейсе. В API reasoning настраивается параметрами. Текстовая просьба не является надежной заменой конфигурации.

Почему нужны evals, если модель стала умнее?

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

Источники и границы выводов

Материал подготовлен по состоянию на 10 июля 2026 года. Функции, доступность и лимиты OpenAI могут меняться. Перед операционным решением стоит проверять актуальную документацию.

• GPT-5.6: Frontier intelligence that scales with your ambition
• GPT-5.6 in ChatGPT
• OpenAI model guidance
• OpenAI prompt guidance
• Reasoning models
• Codex models
• Codex rate card
• Projects in ChatGPT
• Deep research in ChatGPT
• Scheduled Tasks in ChatGPT

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