Промпты Anthropic и OpenAI: как переносить без регрессий
Практический разбор для разработчиков: почему рекомендации Anthropic и OpenAI по промптам расходятся, что можно переносить между Claude и GPT и где нужны evals, context engineering и model-specific overlay.
Проверено 17 июня 2026 года. Промпты Anthropic и OpenAI нельзя считать взаимозаменяемыми шаблонами. У них может совпадать цель, формат ответа и часть ограничений, но поведение модели, роли в API, работа с инструментами и настройка reasoning устроены по-разному.
Инфоповодом стала публикация на Habr о том, что новые рекомендации Anthropic и OpenAI по промптам расходятся. Сводить это к спору «чей гайд правильнее» бессмысленно: у разных моделей разные привычки, разные API-контракты и разные способы проверять результат. Если нужна база, начните с нашего материала про общие принципы промпт-инжиниринга. Здесь разбираем более узкую задачу: как переносить инструкции между Claude и GPT без регрессий.
Короткий вывод: переносите не текст промпта, а инженерный контракт. Цель, критерии успеха и формат ответа можно держать общими. Всё, что связано с моделью, reasoning, инструментами, памятью, автономностью и проверками, лучше выносить в отдельный слой под конкретного поставщика.
Где именно расходятся советы Anthropic и OpenAI
Anthropic в обзорной странице prompt engineering начинает не с «магических фраз», а с success criteria, evals и выбора модели. Это важный порядок. Компания прямо подводит разработчика к мысли: не каждую проблему надо лечить новым промптом, иногда дешевле поменять модель, тестовый набор или контекст.
Дальше Anthropic делает рекомендации всё более model-specific. В документации есть отдельные страницы для Claude Fable 5 и Claude Opus 4.8. Для Fable 5 акцент смещён на длинные агентные задачи, управление усилием, прогресс-репорты, память и работу с подагентами. Для Opus 4.8 Anthropic отдельно описывает literal instruction following, триггеры tool use и настройку effort. Это уже не универсальный «пиши конкретнее». Это настройка поведения под конкретную модель.
OpenAI в своём guide по prompt engineering разводит reasoning-модели и GPT-модели. Для reasoning-моделей лучше работают короткие high-level goals и меньше лишнего контекста, для GPT-моделей чаще нужны более подробные инструкции и примеры. В актуальном Prompt guidance OpenAI также предлагает держать evals на model snapshots, задавать reasoning effort через API и не превращать промпт в длинную смесь требований, которые лучше вынести в код или тесты.
Отсюда практическая развилка. Если вы переносите промпт Claude в GPT или обратно, нельзя просто заменить название модели. Нужно понять, какие части инструкции описывают задачу, а какие компенсируют особенности конкретной модели.
Что можно переносить, а что нужно переписывать
Удобнее всего думать о промпте как о наборе слоёв. Нижний слой общий: цель, данные, формат и критерии готовности. Верхний слой зависит от модели и поставщика.
| Часть промпта | Можно переносить? | Что делать на практике |
|---|---|---|
| Цель задачи и критерии успеха | Да | Оставьте единый task contract: что считается хорошим ответом, какие источники обязательны, где модель должна остановиться. |
| Формат ответа | Частично | Сохраняйте структуру, но для машинного JSON используйте Structured Outputs, tool schemas или валидацию, а не только просьбу в тексте. |
| Роль, тон и язык | Да, с проверкой | Тон можно переносить, но проверяйте длину и стиль: разные модели по-разному реагируют на просьбы «будь кратким» или «пиши как эксперт». |
| System / developer / user-инструкции | Нет как есть | Сопоставьте роли API. У Claude системная инструкция живёт в отдельном поле system, у OpenAI часть правил часто уходит в instructions или developer message. Подробнее этот слой разбирали в гайде про системные промпты. |
| Reasoning, effort, extended thinking | Нет | Не копируйте фразы вроде «думай дольше» между API. Настраивайте effort, thinking budget или reasoning-параметры штатным способом конкретной платформы. |
| Работа с инструментами | Только после адаптации | Tool use зависит от схем, прав доступа, порядка вызовов и guardrails. Промпт должен ссылаться на реальные инструменты, а не на абстрактные возможности модели. |
| Память, подагенты, долгие агентные циклы | С осторожностью | Эти блоки проверяйте evals. Именно здесь чаще всего появляются регрессии: модель начинает спрашивать лишнее, теряет состояние или преждевременно считает задачу готовой. |
| Safety-правила и отказы | Нет как есть | Не переносите политики отказов дословно. У каждого поставщика своя иерархия правил, а приложение всё равно должно проверять рискованные действия на своей стороне. |
Главная ошибка в миграции: пытаться сохранить «красивый» промпт целиком. Лучше разбить его на общий контракт и vendor overlay. Так вы сможете менять модель без переписывания всей инструкции и быстрее поймёте, где именно появилась регрессия.
Как устроить multi-vendor prompt layer
Рабочая схема для команды выглядит так.
- Сначала опишите общий контракт: задача, входные данные, формат ответа, ограничения, критерии готовности и условия остановки.
- Затем заведите отдельный overlay для Claude, OpenAI и других моделей. В нём должны жить роли API, reasoning-настройки, tool use, память, ограничения длины и специальные инструкции конкретной модели.
- Привяжите каждый overlay к версии модели или model snapshot. Если модель обновилась, тестируйте overlay как изменение кода.
- Соберите небольшой eval-набор: 20-50 реальных запросов, включая плохие входные данные, конфликтующие инструкции и задачи с инструментами.
- Сравнивайте не только «понравился ответ или нет», а конкретные признаки: формат не сломан, источник указан, инструмент вызван только когда нужно, отказ не потерял контекст.
Это похоже на подход из статьи про миграцию промптов без регрессий, только здесь добавляется второй поставщик. Чем больше у вас моделей, тем опаснее держать всё в одном длинном промпте.
Context engineering: промпт уже не главный контейнер
Anthropic в статье про context engineering формулирует сдвиг прямо: работа с LLM всё меньше сводится к подбору слов и всё больше к вопросу, какой контекст попадает к модели в момент ответа. В агентных системах это не только system prompt, но и инструменты, MCP, внешние данные, история сообщений, память и промежуточные результаты.
Для миграции между Anthropic и OpenAI это особенно важно. Две модели могут получить одинаковый текст инструкции, но разный контекст вокруг неё: один набор инструментов, другая история сообщений, другой retrieval, другая память, другие ограничения на вызовы. В результате «тот же промпт» перестаёт быть тем же промптом.
Практический вывод простой: храните prompt text отдельно от context assembly. Если вы тестируете новую модель, фиксируйте не только текст системной инструкции, но и то, какие документы, tool schemas и предыдущие сообщения попали в окно контекста. Иначе вы не поймёте, что именно сломалось.
Почему это уже часть AI-native инженерии
OpenAI в материале Building an AI-Native Engineering Team описывает сдвиг, где агент берёт на себя всё больше механической реализации, а человек чаще задаёт намерение, проверяет архитектуру, ревьюит результат и принимает решение. В такой команде промпт перестаёт быть личной заметкой разработчика. Он становится частью производственного процесса.
Для такой работы нужен не «идеальный универсальный промпт», а управляемый набор инструкций. Разработчик должен понимать, какая часть отвечает за намерение, какая за формат, какая за инструменты, какая за безопасность, а какая просто обходит конкретную слабость модели.
Именно здесь сходятся prompt engineering и AI-native engineering. Если команда хочет менять Claude на GPT, GPT на Claude или держать оба варианта в продукте, промпты надо версионировать, тестировать и ревьюить. Так же, как код.
Чеклист миграции промпта между Claude и GPT
- Зафиксируйте исходную модель, дату проверки и API-поверхность. «Claude» и «GPT» слишком общие названия.
- Разделите инструкцию на общий контракт и модельный overlay.
- Уберите противоречивые абсолюты: «всегда», «никогда», «не спрашивай пользователя ни при каких условиях». Они часто ломаются при переносе.
- Перенесите reasoning-настройки в параметры API, если платформа это поддерживает.
- Проверьте роли сообщений: system, developer, user и отдельные поля вроде
systemу Claude не должны смешиваться механически. - Сверьте tool schemas и права доступа. Модель не должна обещать инструмент, которого нет в текущем контуре.
- Запустите evals на одинаковых входах до и после переноса.
- Отдельно проверьте длинный контекст, отказ, форматированный вывод и задачи с несколькими вызовами инструментов.
- После релиза логируйте не только ошибки модели, но и версию prompt overlay, чтобы регрессию можно было воспроизвести.
Если после переноса модель стала хуже отвечать, не начинайте с переписывания всего текста. Сначала проверьте слой: это проблема цели, формата, reasoning, контекста, инструментов или политики отказов? Такой разбор быстрее, чем ещё десять вариантов одного большого промпта.
FAQ
Почему советы Anthropic и OpenAI по промптам отличаются?
Потому что рекомендации привязаны к моделям, API-ролям, инструментам и способу тестирования. Anthropic сейчас отдельно документирует поведение конкретных Claude-моделей, OpenAI разводит подходы для reasoning-моделей и GPT-моделей. Это разные инженерные поверхности, а не разные версии одной инструкции.
Можно ли копировать промпты Claude в GPT?
Можно копировать только общий смысл: цель, критерии успеха, формат и часть ограничений. Дословный перенос опасен. Роли API, tool use, reasoning-настройки, память и safety-правила нужно адаптировать и проверять на evals.
Когда prompt engineering уже нужно заменять context engineering?
Когда качество ответа зависит не столько от формулировки, сколько от набора документов, инструментов, истории сообщений, памяти и промежуточных результатов. В агентных системах это происходит быстро: промпт остаётся важным, но он уже не единственный рычаг управления.
Источники и дата проверки
Факты и ссылки проверены 17 июня 2026 года. Для статьи использованы:
- Habr: исходный RSS-материал о расходящихся рекомендациях Anthropic и OpenAI
- Anthropic Docs: Prompt engineering overview
- Anthropic Docs: Prompting best practices
- Anthropic Docs: Prompting Claude Fable
- Anthropic Docs: Prompting Claude Opus 4.8
- OpenAI Developers: Prompt engineering
- OpenAI Developers: Prompt guidance
- Anthropic Engineering: Effective context engineering for AI agents
- OpenAI Developers: Building an AI-Native Engineering Team
