Чем подробнее ваши промты для AI, тем хуже результат. Разбор нового гайда OpenAI и что он меняет для бизнеса

OpenAI выпустил новый гайд по промтингу для GPT-5.5. Главный тезис: подробные инструкции с императивами «всегда» и «никогда» теперь чаще ухудшают результат, чем улучшают. Я открыл свой рабочий скилл — 663 строки, 36 капитализированных блоков — и нашёл четыре проблемы только в одной секции из 134 слов. Это значит, что промт-стэки, написанные за последний год, скорее всего, работают против вас. Разберём, что именно изменилось, как это влияет на стоимость и качество AI-автоматизации, и что делать прямо сейчас.

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

И вот вопрос, который мало кто задаёт: эти инструкции вообще работают или мешают?

До прошлой недели на этот вопрос отвечали интуитивно. С 2023 года индустрия учила: чем точнее опишешь — тем меньше шансов, что модель напортачит. Это вошло в курсы, статьи, подкасты. Появились шаблоны RICCE, CO-STAR, конструкторы промтов на 50+ полей. Промты росли. Качество — иногда росло, иногда падало, и причину было не отследить.

Я тоже играл в эту игру. Один из моих рабочих скиллов — обработка логов ошибок в продакшене — разросся до 663 строк. 36 блоков с капитализированными требованиями: «CRITICAL REQUIREMENTS», «YOU MUST FOLLOW THESE RULES. NO EXCEPTIONS», «ALWAYS run this FIRST», «MANDATORY», «NEVER ignore errors». Я был доволен — казалось, закрыл все возможные сценарии.

А потом OpenAI выкатил новый гайд по промтингу. Я полез проверять и понял: значительная часть моих инструкций работает против меня. Самое неприятное — это касается не только GPT-5.5. На Claude Opus 4.7, в котором я провожу по 12 часов в день, картина та же.

OpenAI сформулировал пять идей. Я приведу их с короткими комментариями.

Первая. Короткие промты, описывающие результат, обходят промты с пошаговым процессом. Цитата из гайда: «Shorter, outcome-first prompts usually work better than process-heavy prompt stacks». Не «иногда лучше». Usually — в большинстве случаев.

Вторая. Старые промт-стэки нельзя переносить на новые модели. «Avoid carrying over every instruction from an older prompt stack». Промты, написанные под GPT-4 или Claude 3, могут активно мешать GPT-5.5 и Opus 4.7. Это не теория — это явное предупреждение OpenAI.

Третья. Императивы — только для invariants. «Всегда» и «никогда» нужно оставить только для того, что реально нельзя нарушать. «Никогда не удаляй файлы без подтверждения» — это инвариант, его нарушение приведёт к потере данных. «Всегда сначала проанализируй, потом пиши код» — это рекомендация, и её модель должна решать сама. Раньше я не отличал одно от другого. Теперь буду.

Четвёртая. Stop condition обязателен. «Use the minimum evidence sufficient to answer correctly, cite it precisely, then stop». Без явной точки остановки модель уходит в overthinking — продолжает анализ там, где задача уже решена. На больших объёмах это прямой расход токенов и времени.

Пятая. Reasoning effort — не основной рычаг качества. Если результат слабый, не повышайте reasoning effort. Перепишите промт. Это меняет приоритет в работе с моделью: сначала формулировка, потом настройки.

Самый ценный способ показать тезис — на реальном коде. Беру одну секцию из своего рабочего скилла, который три месяца назад казался мне аккуратной инструкцией: «BUG FIXING PRINCIPLES». 134 слова, четыре буллет-блока, четырнадцать пунктов.

Что было написано:

«Найди корневую причину, не симптомы. Если ошибка в функции X, но причина в функции Y — чини Y. Не делай костыли, которые маскируют проблему. Спрашивай "почему это произошло?", пока не дойдёшь до настоящей причины. Никогда не игнорируй ошибки. Качество важнее скорости. Тестируй фикс мысленно — что ещё может сломаться? Ищи похожие паттерны в кодовой базе.»

Перечитал по новым правилам и нашёл четыре проблемы.

Дублирование одной мысли. «Найди причину», «не симптомы», «не костыли», «не патчи» — четыре формулировки одного. Модель получает одну идею в четырёх вариациях и переусиливает её — копает вглубь даже там, где причина очевидна. Это прямой пример того, что OpenAI называет «narrowing the search space».

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

Нет stopping condition. Когда фикс готов? По текущему промту — никогда. «Что ещё может сломаться» можно проверять бесконечно. Модель либо недокапывает, либо перекапывает.

Императивы на judgment calls. «Никогда не игнорируй ошибки» — а в том же скилле дальше идёт таблица из 60 паттернов, которые надо игнорировать автоматически. Промт сам себе противоречит.

Переписал по новым правилам. Получилось 50 слов вместо 134. Без императивов. Просто описание того, что значит «фикс готов», и явная граница — когда останавливаться. На контрольной задаче (реальная ошибка из логов — DNS-резолюция падает на момент рестарта подов) обе модели — Claude Opus 4.7 и GPT-5.5 — выдали лучший результат именно по короткому варианту. Длинный гнал их в overthinking: лезли «улучшать» соседние модули, предлагали рефакторинг.

Для тех, кто внедряет AI в производство, это не философский вопрос. Это четыре прямых статьи расходов.

Первая — стоимость токенов. Каждый запуск промта — это деньги. Если промт раздут вдвое, вы платите вдвое больше за один и тот же результат (или худший). На объёмах в десятки тысяч запусков в месяц это превращается в заметную статью бюджета. Для команды, которая использует AI в продуктовых процессах, экономия на токенах от чистки промтов часто перекрывает зарплату инженера.

Вторая — время инженеров на поддержку. 663-строчный промт — это документ, который требует ревизии при каждой смене поколения модели. А обновления выходят теперь раз в два-три месяца. Если у вас десять таких документов — это десятки часов работы инженера ежеквартально. Outcome-промт на 50-100 строк ревизуется в разы быстрее.

Третья — качество результата. Длинные промты с дублированиями приводят к тому, что модель «гасит» одни инструкции другими, противоречит сама себе или зацикливается на одной мысли. На критических задачах это означает больше ошибок и больше времени на ревью. Конкретно у меня — после перехода на короткие промты количество правок вручную сократилось примерно вдвое на типовых задачах.

Четвёртая — скорость онбординга новых членов команды. Инструкция на 50 строк понятна за 10 минут. Инструкция на 663 строки — за час, и через неделю забывается. Если у вас в команде ротация или вы передаёте проект подрядчикам — это прямая стоимость недопонимания.

Я не пишу здесь конкретный ROI в процентах, потому что у каждой команды свой объём работы с AI и свои тарифы. Но направление очевидно: чистка промтов окупается, причём в нескольких статьях расходов одновременно.

Не верьте мне на слово. Возьмите Google Stitch — публичный сервис от Google, генерирующий UI по описанию. Прогоните одну и ту же задачу с двумя промтами.

Промт А: подробное техническое задание. Размеры, цвета, шрифты, отступы, анимации, кнопки, иконки — всё прописано в миллиметрах.

Промт Б: короткое описание цели и эмоции. Один из работающих вариантов — «экран онбординга для AI-приложения, должен ощущаться лёгким и дружелюбным, цель — чтобы пользователь дошёл до конца за 30 секунд».

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

Этот эффект не уникален для дизайна. Он воспроизводится везде, где задача требует от модели творческого решения внутри ограничений. А таких задач в бизнесе — большинство.

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

Я перестал генерировать промты через AI. Промт пишу руками, а исполнение делегирую модели. Кросс-модельная генерация ломается, и это нужно учитывать в процессах команды.

Гайд OpenAI — про GPT-5.5. Я отдельно сверился с документацией Anthropic для Claude. Тон у Anthropic другой: они не говорят «выкиньте инструкции», они говорят «используйте структуру» — XML-теги, чёткое разделение между данными и задачей, длинные документы в начало, инструкции в конец.

Но если посмотреть их примеры хороших промтов — там нет «всегда» и «никогда». Там описание ожидаемого результата плюс структура. По духу — то же самое. Различие в букве: Claude чуть больше любит структуру, GPT-5.5 — больше доверия модели.

Это значит, что мы видим не точечное обновление одной модели, а тренд индустрии. Команды, которые сейчас перейдут на outcome-промты, получат преимущество и на текущих, и на следующих поколениях моделей.

Чтобы не выглядело как «теперь всё пишем коротко» — три категории, где «всегда» и «никогда» оправданы.

Принцип, который я для себя вывел: ALWAYS/NEVER — для invariants (нарушение приведёт к катастрофе или сломает контракт). Не для preferences (нам так больше нравится).

Чтобы не было вопросов в комментариях.

Везде, где задача требует от модели творческого решения внутри ограничений (а это разработка, дизайн, контент, аналитика, консалтинг) — короткие outcome-промты выигрывают.

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

Гайд OpenAI — публичный, лежит на developers.openai.com. Документация Anthropic — открытый репозиторий на GitHub. Stitch — публичный сервис, эксперимент любой повторит за пять минут. Цифры в кейсе (663 строки, 36 блоков, 134 → 50 слов) — извлекаются grep-командой из реального файла, который я могу показать.

Я не учёный, я практик. Мои наблюдения — рабочие, не исследовательские. Если у вас на проектах картина другая — это нормально, контексты различаются. Но если у вас тоже накоплены промт-стэки за последний год — потратьте день и проведите ревизию по новой рамке. С большой вероятностью обнаружится, за что можно перестать платить.

Если в команде интересно обсудить ревизию промтов или нужен сторонний взгляд — пишите в Telegram @maslennikovig. Канал, где регулярно разбираю кейсы внедрения AI: t.me/maslennikovigor.