Перенос промптов между моделями
У вас есть промпт, который прекрасно работает на одной модели. Теперь он нужен вам на другой — клиент живёт в GPT, цель по стоимости толкает вас к открытой модели, или вы A/B-тестируете Claude против Gemini. Хорошая новость, повторяющаяся в документации каждого провайдера: основа хорошего промпта универсальна. Меняется лишь тонкий слой поверхностных соглашений. Эта страница разделяет эти два слоя, чтобы вы могли переносить промпт, не переписывая его, и даёт вам воспроизводимый рабочий процесс миграции плюс переносимый шаблон.
- Понять, какие части промпта переносятся без изменений между Claude, GPT, Gemini и открытыми моделями
- Понять, какие части требуют подстройки под каждую модель — и почему
- Запускать воспроизводимый рабочий процесс миграции вместо переписывания методом проб и ошибок
- Держать переносимый, нейтральный к модели шаблон промпта, который можно специализировать под каждую цель
Ментальная модель: структура переносится, соглашения — нет
Представьте любой промпт как два слоя:
- Слой рассуждения — то, что вы просите, контекст, который вы предоставляете, примеры, желаемый результат. Это про коммуникацию, и она переносится между моделями практически без изменений.
- Слой соглашений — то, как именно данная модель хочет получить эту коммуникацию упакованной: куда идёт системный промпт и насколько строго он соблюдается, предпочитает ли она XML или Markdown, точную схему вызова инструментов, свою многословность и позицию по отказам по умолчанию, какие параметры генерации существуют.
Перенос промпта — это почти никогда не переписывание слоя рассуждения. Это переподгонка слоя соглашений. Уловите это различие правильно — и миграция станет механической, а не загадочной. (О нейтральном к провайдеру способе выбрать цель в первую очередь см. Выбор модели.)
Что переносится без изменений
Всё это справедливо для Claude, GPT, Gemini и основных открытых моделей — документация по лучшим практикам каждого провайдера независимо это рекомендует:
- Чёткая роль + задача + явные инструкции. «Ты — X. Твоя работа — Y. Следуй этим правилам.» Каждый провайдер документирует конструкцию персоны/роли и вознаграждает конкретные, недвусмысленные инструкции вместо расплывчатых.
- Конкретные примеры (few-shot). Показ 2–5 пар вход→выход обучает шаблону надёжнее, чем его описание. Все три основных провайдера явно рекомендуют few-shot примеры; документация Gemini доходит до того, что рекомендует почти всегда их включать.
- Заданный формат вывода. «Верни таблицу Markdown со столбцами X, Y, Z» или «только JSON, без прозы» работает везде. Инструкция переносится, даже если механизм строгого режима отличается (об этом ниже).
- Цепочка рассуждений / «рассуждай перед ответом». Запрос пошагового рассуждения на сложных задачах улучшает результаты между моделями. Одна оговорка, которая действительно зависит от модели: специализированные модели рассуждения/мышления часто делают это внутренне, поэтому явное «думай пошагово» может быть избыточным или даже контрпродуктивным — см. список того, что нужно подстроить.
- Заземление / RAG. «Используй ТОЛЬКО приведённый ниже контекст; если ответа в нём нет, скажи, что не знаешь.» Дисциплина предоставления извлечённого контекста и ограничения модели им универсальна — каждый провайдер документирует заземление в стиле RAG как способ снизить галлюцинации.
- Длинный контекст первым, вопрос последним. Начинайте с документов/данных, заканчивайте инструкцией. Такой порядок помогает между моделями и явно выделен в рекомендациях Gemini.
Если вы усвоили Основы промптинга, вы уже владеете переносимыми 80%.
Что нужно подстраивать под каждую модель
Это слой соглашений — та часть, которая действительно отличается. Переподгоняйте это при переносе:
| Аспект | Что меняется между моделями | Что делать |
|---|---|---|
| Обработка и вес системного промпта | У каждой модели есть системное/разработческое сообщение, но насколько сильно оно перекрывает пользовательский ход — варьируется. Некоторые взвешивают выделенную роль разработчика/системы выше пользовательских инструкций; другие размывают границу. | Не предполагайте, что ваш системный промпт соблюдается с той же силой. Повторно проверьте, что ограничения действительно держатся; поднимайте критические правила выше, если они проскальзывают. |
| XML против Markdown против разделителей | Claude особенно хорошо разбирает XML-теги для разделения инструкций/контекста/примеров; GPT и Gemini принимают XML, но также опираются на заголовки Markdown и разделители. | Сохраняйте какую-то явную структуру; меняйте разновидность под предпочтение цели. Соответствие формата вашего промпта желаемому выводу также подталкивает стиль вывода. |
| Форма JSON вызова инструментов / функций | Цикл (объявляем инструменты → модель запрашивает вызов → вы выполняете → возвращаете результат) идентичен везде; проводной формат — нет — имена полей, как вызовы/результаты размещаются в списке сообщений, и опции строгого режима отличаются. | Никогда не копируйте сырой JSON инструментов между провайдерами. Переотобразите его на схему цели. См. Использование инструментов. |
| Многословность по умолчанию | Новые модели по умолчанию склонны к краткости и ожидают, что вы попросите детали; старые были более болтливыми. | Если вы перенесли промпт, а ответы стали короче/длиннее, задайте многословность явно, а не вините промпт. |
| Позиция по отказам / безопасности | У каждой модели свой порог для отказа или уклонения по пограничным запросам, и они перенастраиваются с каждым релизом. | Повторно тестируйте краевые случаи после переноса. Промпт, который никогда не вызывал отказов на одной модели, может потребовать переформулировки на другой. |
| Предзаполнение ответа (prefill) | Вложить слова в уста ассистента, чтобы навязать формат, — классический рычаг эпохи Claude, но новые модели Claude (4.6+) отклоняют предзаполненный финальный ход ассистента, а поддержка в других местах и вовсе варьируется. | Замените prefill прямой инструкцией («отвечай без преамбулы»), схемой вывода или вызовом инструментов. |
| Стоп-последовательности и max tokens | Все выставляют лимит длины, а большинство — стоп-последовательности, но имена параметров, значения по умолчанию и лимиты отличаются — и некоторые ручки бюджета мышления упраздняются в пользу effort/max_tokens. | Повторно проверьте имена параметров и потолки на цели; не предполагайте, что ваши старые значения переносятся. |
Рабочий процесс миграции
Относитесь к переносу как к короткому, дисциплинированному циклу, а не к переписыванию методом угадывания.
- Прочитайте существующий промпт и мысленно разбейте его: слой рассуждения (роль, задача, контекст, примеры, спецификация вывода) против слоя соглашений (выбор XML/Markdown, prefill, JSON инструментов, параметры). Первый вы сохраните, второй переподгоните.
- Удалите всё, что является соглашением, а не смыслом: XML-теги, которые были просто структурой, ходы prefill, специфичное для модели «думай пошагово», если цель рассуждает внутренне, и старую схему вызова инструментов. Теперь у вас есть чистое, нейтральное ядро.
- Добавьте обратно структуру в предпочитаемой целью разновидности (заголовки Markdown или разделители там, где был XML), задайте системный промпт и проверьте, что он взвешен так, как вы ожидаете, задайте многословность явно и переотобразите определения инструментов на форму JSON цели.
- Выберите 5–15 реальных входов, покрывающих ваши обычные случаи плюс пару краевых/пограничных (чтобы отловить сдвиги в отказах и многословности). Это ваша мерка «до/после» — без неё вы гадаете.
- Запустите оценку на цели. Где выводы отличаются, сначала исправьте слой соглашений (формат, многословность, сила системного промпта), прежде чем трогать слой рассуждения. Большинство расхождений закрывается здесь.
- Держите оба варианта промпта под контролем версий с заметкой о том, что вы изменили и почему. Повторное переключение моделей — или обратно — тогда стоит минут, а не переоткрытия.
:::tip Не переписывайте с нуля Если вы ловите себя на перестройке роли, задачи или примеров — остановитесь: это переносимый слой. Чистый перенос меняет упаковку, а не смысл. :::
Переносимый шаблон промпта
Пишите промпт в нейтральной к модели форме, затем специализируйте только слой соглашений под каждую цель. Это ядро использует лёгкую, универсально понятную структуру (оно чисто читается как Markdown, а теги легко конвертируются в XML для Claude):
Нейтральное к модели ядро промпта — специализируйте слой соглашений под каждую цель
# ROLE
You are {role}.
# TASK
{One clear sentence describing the single goal.}
# RULES
- Use ONLY the information in CONTEXT below. If the answer is not there, say "I don't know" — do not guess.
- Be concise. Respond directly, with no preamble like "Here is..." or "Based on...".
- {Any other hard constraints.}
# OUTPUT FORMAT
{Exact format — e.g. "A Markdown table with columns Name, Value, Source." or "JSON only matching this schema: {...}".}
# EXAMPLES
Input: {example input 1}
Output: {ideal output 1}
Input: {example input 2}
Output: {ideal output 2}
# CONTEXT
{Retrieved documents / data go here — long content first.}
# REQUEST
{The actual user question, last.}Настройки под каждую цель, накладываемые поверх:
- Claude — переместите маркеры разделов в XML-теги (
<role>,<rules>,<context>,<request>); он разбирает их особенно чисто. Не используйте предзаполненный ход ассистента на текущих моделях; полагайтесь на правило «без преамбулы» или на инструмент/схему. - GPT — поместите RULES в системное/разработческое сообщение, чтобы они несли больше веса; заголовки Markdown подходят; используйте режим структурированного вывода / строгого JSON, а не только описание схемы в прозе.
- Gemini — передавайте ROLE + RULES + OUTPUT FORMAT через поле системной инструкции, держите промпт прямым (новые Gemini могут переинтерпретировать многословные промпты), и держите CONTEXT первым, а REQUEST последним.
- Открытые модели (Llama/Mistral/Qwen и т. д.) — следуйте опубликованному чат-шаблону модели в точности и сильнее опирайтесь на явные few-shot примеры и ограничения формата, поскольку следование инструкциям обычно менее надёжно, чем у передовых закрытых моделей.
Быстрая проверка
Проверьте себя
0/3- Промпт — это слой рассуждения (переносится) плюс слой соглашений (переподгоняется под модель) — переносите второй, сохраняйте первый.
- Чёткие роль/задача/инструкции, few-shot примеры, спецификации формата вывода, цепочка рассуждений и заземление RAG переносятся между Claude, GPT, Gemini и открытыми моделями.
- Подстраивайте вес системного промпта, структуру XML против Markdown, JSON вызова инструментов, многословность по умолчанию, позицию по отказам, prefill и параметры длины под каждую цель.
- Запускайте крошечный набор для оценки на реальных входах до/после; исправляйте соглашения, прежде чем трогать рассуждение.
- Держите нейтральный к модели шаблон плюс настройки под каждую цель под контролем версий, чтобы переключение было дешёвым.
- Конкретные поведения дрейфуют с каждым релизом — проверяйте параметры и лимиты в актуальной документации каждого провайдера, никогда по памяти.
Источники и дополнительное чтение
- Обзор prompt engineering — документация Anthropic (Claude) — техники промптинга Claude: ясность, примеры, XML-структурирование, мышление, роли.
- Лучшие практики промптинга Claude — документация Anthropic — настройка под конкретную модель, XML-теги, контроль вывода/многословности и руководство по миграции prefill.
- Лучшие практики prompt engineering — документация API OpenAI (GPT) — роли сообщений/цепочка команд, разделители, few-shot и руководство «модель рассуждения против GPT».
- Вызов функций — документация API OpenAI — схема вызова инструментов и цикл запрос/ответ для отображения.
- Стратегии дизайна промптов — документация API Google Gemini — системные инструкции, few-shot, структурирование, порядок «контекст первым» и параметры вывода/длины.
- Руководство разработчика Gemini 3 — документация API Google Gemini — рекомендации для новых моделей по прямым промптам, многословности по умолчанию и размещению инструкций.
Далее
- Согласуйте глубину мышления между провайдерами → Сравнение моделей рассуждения
- Выберите целевого провайдера нейтрально → Выбор модели
- Переносимые основы → Основы промптинга
- Рычаг структуры Claude → XML-теги
- Переотобразите схему инструментов → Использование инструментов