OpenAI сообщила, что в sample внутренних coding-agent evals более короткие system prompts подняли evaluation score примерно на 10–15%. Одновременно total tokens снизились на 41–66%, а cost на 33–67%. Для команды, которая месяцами наращивала правила поверх правил, это неприятная новость: нейро инструкция может стать хуже именно потому, что в неё добавляли «страховки».
Вывод не в том, что любой промт надо срочно урезать. Это внутренний результат OpenAI на coding-agent evals, а не обещание для каждой модели, задачи или продукта. В опубликованной рекомендации эти диапазоны даны как directional result. Поэтому переносить можно метод проверки, но не сами проценты. Практическая ценность в другом: появился ясный способ выяснить, какие слова действительно защищают качество, а какие лишь повторяют уже сказанное и расходуют контекст.
Платите в рублях за GPT API без наценки на токены через provod.ai
Длина сама по себе не делает инструкцию надёжнее
В работающем system prompt обычно смешаны четыре разных слоя:
- доменный контекст: термины, данные и правила предметной области;
- жёсткие ограничения: security, compliance и запреты;
- границы автономии: где агент отвечает, проверяет, диагностирует, меняет или строит;
- компенсирующие патчи: добавленные после единичного сбоя напоминания, повторы и запреты.
Первые три слоя нельзя вырезать ради красивого числа токенов. Даже компактная политика должна различать ответ, review и диагностику от изменений, сборки и исправлений; внешние записи, разрушительные действия, покупки и существенное расширение задачи требуют подтверждения.
Четвёртый слой обычно лучший кандидат на проверку. OpenAI рекомендует формулировать каждое правило один раз, показывать только релевантные инструменты и делать их описания краткими. Но примеры и stylistic guidance остаются, если в них зашито продуктовое требование или они закрывают измеренный разрыв качества.
В июльском обсуждении r/codex пользователи описывали знакомую картину: старые инструкции, оставшиеся от GPT-5.5, подталкивают GPT-5.6 к overplanning. Автор поста от 11 июля, набравшего 20 голосов на момент фиксации, предлагал отключать поведенческие патчи и возвращать только минимальное правило для воспроизводимого сбоя. Это не доказательство причинности, но полезная гипотеза для аудита.
Где короткий prompt может сломать продукт
Сильное возражение против сокращения справедливо: длинная инструкция иногда является не шумом, а архивом дорогих ошибок. Представьте задачу, в которой базовая версия останавливается перед внешней записью и запрашивает подтверждение. Если после удаления «повторяющейся» группы правил вариант без неё выполняет запись сам, сокращение провалило regression test, даже если стало дешевле и получило более высокую общую оценку.
Удаление из prompt правила согласования или критерия полноты может дать экономию, но только если на том же workload измерены tokens и cost, а требования к approval и полноте результата сохранены. Поэтому проверять нужно не «стал ли ответ короче», а сохранил ли агент обязательное поведение на одинаковом наборе задач. Внутренние диапазоны OpenAI стоит сопоставлять с собственными метриками:
| Что сравнивать | Почему это важно |
|---|---|
| Успех задачи и полнота результата | Экономия не компенсирует пропущенное требование |
| Обязательные доказательства и ограничения | Здесь чаще всего скрыт дорогой регресс |
| Input, cached и output tokens | Процент cache hit не показывает абсолютный расход |
| Latency и cost | Они имеют смысл только при сохранённом качестве |
Эксперимент, который отделяет улучшение от случайности
Начните с текущего рабочего prompt и набора tools. Затем выберите одну группу для удаления: например, повторяющиеся правила, нерелевантные описания инструментов или один компенсирующий патч. Прогоните тот же набор representative tasks и сравните результаты с базовой версией.
Не меняйте одновременно стиль, инструменты, примеры и порог автономии. Если качество просело, вы не поймёте причину. Если выросло, не сможете доказать, что помогло именно сокращение.
Полезный порядок проверки:
- Зафиксируйте baseline: prompt, tools и набор задач.
- Выпишите каждое правило в одну из четырёх групп: контекст, ограничение, граница автономии, патч.
- Уберите только одну группу дублей или нерелевантных описаний.
- Повторите те же evals и проверьте обязательные требования вручную или установленным способом.
- Оставьте изменение только при сохранённом качестве и понятной динамике total tokens, latency и cost.
Тред r/codex от 14 июля, набравший 138 голосов на момент фиксации, хорошо показывает вторую сторону проблемы: даже длинная anti-overengineering инструкция может породить новые противоречия. Это не аргумент против правил, а напоминание, что правило должно соответствовать конкретному риску и проходить проверку на задачах.
Когда stable короткий system prefix отделён от динамической задачи, provod.ai позволяет измерять input, cached и output tokens и сравнивать варианты prompt на одном наборе кейсов. Экономия засчитывается только после подтверждения, что качество не ухудшилось.
Перейти на provod.ai Что для вашего representative workload дороже: сохранить длинный prompt, пока сокращённый вариант хотя бы раз нарушает approval boundary, критерий полноты или обязательное доказательство, или выделить время на regression eval по одному изменению за раз?
provod.ai — корпоративная работа с AI с учётом требований РФ
Для сценариев с персональными данными важна не только модель, но и организация процесса: платформа проектируется с учётом требований российского законодательства, а применимость определяется составом данных и настройками клиента.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Требования к корпоративному процессу не увеличивают тариф модели: стоимость сохраняется 1:1 с официальной ценой провайдера, без собственной наценки provod.ai.
Изучите условия для корпоративного сценария: форма регистрации · цены на модели · защита данных по 152-ФЗ · политика обработки данных