Рецепты промптов для генерации изображений Recraft v4.1 для разработчиков

Почему рецепты промптов лучше разовых промптов

Каждая команда, вызывающая API генерации изображений, рано или поздно упирается в одну и ту же стену: промпт отлично выглядящей картинки хранится в истории чата, одноразовом скрипте или в приложении для заметок у кого-то из коллег. Когда требования продукта меняются — «та же иллюстрация, но с фотографичностью» или «добавь заголовок на изображение» — никто не знает, какие слова сработали, поэтому промпт переписывают с нуля, и вывод начинает непредсказуемо меняться.

Рецепты промптов решают эту проблему, относясь к промпту как к небольшому параметризованному документу. Один скелет, несколько заменяемых блоков и короткий список ограничений. Смена стиля становится редактированием одного поля, а не полной перепиской, а значит, вы можете делать diff промптов, рецензировать их в pull request и рассуждать о том, почему изменился вывод.

Рецепты также делают регрессии качества отлаживаемыми. Если изображения внезапно выглядят неправильно, вы можете провести бисекцию: проблема в блоке субъекта, блоке стиля, инструкциях компоновки или списке негативов? С разовыми промптами ответ обычно «во всём сразу».

Это руководство проходит по конкретному скелету для генерации изображений Recraft v4.1 и приводит две наиболее часто используемые разработчиками категории готовых к копированию рецептов: иллюстрация и фотография. Та же структура расширяется на управление компоновкой, текст внутри изображения и списки негативов.

Что на самом деле содержит рецепт

Рассматривайте каждый рецепт как четыре части:

• Фиксированный скелет — упорядоченные блоки, общие для каждого промпта в вашей кодовой базе.
• Заменяемая стилевая лексика — слова, переключающие вывод между иллюстрацией и фотографией.
• Ограничительные клаузы — компоновка, соотношение сторон, рендеринг текста и исключающие инструкции.
• Метка версии — позволяющая проследить промпты в продакшене до точной ревизии, создавшей материал.

Ничего из этого не требует специальных инструментов. Один JSON-файл на рецепт, закоммиченный в репозиторий вместе с кодом, вызывающим API, вполне достаточен.

Скелет промпта: что сохраняется, а что меняется

Скелет ниже намеренно кажется скучным. В этом и смысл — стабильные части никогда не должны требовать редактирования, чтобы внимание сосредоточивалось на изменяющихся частях.

[SUBJECT]        что находится на изображении, описанное простым языком
[STYLE]          лексика среды и рендеринга
[COMPOSITION]    кадрирование, ракурс или компоновка, соотношение сторон
[CONSTRAINTS]    рендеринг текста, цветовые ограничения, запрещающие правила

Какие блоки сохраняются, а какие заменяются

• SUBJECT — сохраняется. Обычно это единственный блок, который должна параметризовать ваша продуктовая логика (название продукта, описание сцены из пользовательского ввода).
• STYLE — заменяется. Различие между иллюстрацией и фотографией почти целиком здесь.
• COMPOSITION — в основном заменяется, но форма инструкций остаётся неизменной (сначала кадрирование, затем соотношение сторон).
• CONSTRAINTS — частично общие. Список негативов и правило «никакого текста, если не указано иное» часто глобальны; инструкции по рендерингу текста зависят от запроса.

Минимальный шаблон как данные

{
  "recipe_id": "product-hero",
  "version": "3",
  "subject": "a ceramic coffee mug on a plain surface",
  "style": "{{style_block}}",
  "composition": "centered, generous negative space above the subject, square aspect",
  "constraints": ["no text in image", "no watermark"],
  "negatives": "{{negative_list_v2}}"
}

Плейсхолдер {{style_block}} — это и есть шов. Остальное либо общее для рецептов, либо предоставляется вызывающей стороной. Когда вы позже добавите третий стиль — скажем, изометрический 3D — вы добавите один стилевой блок, а не новый файл промпта.

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

Рецепт иллюстрации: плоский, векторный и редакционный стиль

Рецепт иллюстрации — отправная точка для большинства команд, потому что иллюстрация хорошо терпит упрощение — это делает её хорошим выбором для тестирования скелета без борьбы с фотореализмом.

Плоская иллюстрация

[SUBJECT] a developer workspace with a laptop, notebook and coffee mug
[STYLE] flat vector illustration, solid fills, no gradients, bold simple shapes, limited four-color palette, clean geometric forms
[COMPOSITION] centered composition, even margins, square aspect
[CONSTRAINTS] no text in image, no shadows, no textures

Слова, задающие этот вид: плоский, сплошные заливки, без градиентов, смелые простые формы. Каждое слово работает. Уберите «без градиентов» — и вы часто увидите, как мягкие тени прокрадываются внутрь.

Векторная иконка

[SUBJECT] a single shield icon with a checkmark
[STYLE] minimal vector icon, uniform stroke weight, rounded line caps, two-tone, high contrast on plain background
[COMPOSITION] centered, icon fills most of the frame, square aspect
[CONSTRAINTS] no text, no background scenery, no gradients

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

Редакционная иллюстрация

[SUBJECT] a person reviewing charts on a large screen
[STYLE] editorial illustration, muted palette, subtle grain, hand-drawn line quality, slightly abstracted human figures, magazine feature style
[COMPOSITION] subject offset to the right, breathing room on the left, landscape aspect
[CONSTRAINTS] no text in image, no photorealism, no logos

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

Совет по настройке: меняйте по одному стилевому прилагательному за раз. Замена «приглушённой палитры» на «яркую палитру» — настоящий эксперимент; замена пяти слов сразу — нет.

Рецепт фотографии: реалистичность, студия и лайфстайл-кадрирование

Рецепты фотографии используют тот же скелет, только лексика другая. Обратите внимание, что блок субъекта почти не меняется — вот и вознаграждение за шаблонизацию.

Чистая студийная съёмка продукта

[SUBJECT] a ceramic coffee mug on a plain surface
[STYLE] professional studio product photography, soft diffused key light, gentle falloff, neutral background, sharp focus, realistic material detail
[COMPOSITION] centered, slight three-quarter angle, generous negative space above, square aspect
[CONSTRAINTS] no text in image, no props, no harsh reflections

Фотографическая лексика группируется вокруг света (мягкий рассеянный, спад), оптики (резкий фокус, глубина резкости) и реалистичности материалов (реалистичные детали материала). Лексика иллюстрации группируется вокруг формы и заливки. Это противопоставление — и есть вся разница между двумя семействами рецептов.

Средовой лайфстайл

[SUBJECT] a person working at a wooden desk near a window
[STYLE] candid lifestyle photography, natural window light, shallow depth of field, warm neutral tones, realistic skin and fabric texture
[COMPOSITION] over-the-shoulder framing, subject left of center, landscape aspect
[CONSTRAINTS] no text in image, no visible brand marks, no exaggerated saturation

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

Превращение рецепта иллюстрации в фотографию

Имея работающий рецепт иллюстрации, преобразование механистично:

1. Замените весь блок [STYLE] на фотографическую лексику.
2. Настройте [COMPOSITION] только если кадрирование отличается (угол важнее в фотографии).
3. Сохраните [SUBJECT] побайтово идентичным.
4. Сохраните глобальные негативы; удалите специфичные для иллюстрации пункты, которые больше не применимы, например «без градиентов».

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

Управление компоновкой и рендерингом текста

Компоновка и текст — две вещи, которые разработчики чаще всего надеются, что модель выведет сама, и именно те две вещи, которые стоит явно прописывать. Относитесь к ним как к отдельным блокам промпта, отделённым от стиля.

Язык позиционирования, который действительно ограничивает

Расплывчато: «баннерное изображение для лендинга».

Явно:

[COMPOSITION] landscape 16:9 frame; subject occupies the right two-thirds;
left third is empty open space suitable for a headline; horizon line at
lower third; nothing enters the left third

Три привычки делают инструкции позиционирования прочнее:

• Сначала назовите кадр, затем опишите размещение («горизонтальный кадр 16:9»).
• Явно определите зарезервированную область и заявите, что ничто в неё не входит. Пустое пространство не является состоянием по умолчанию.
• Привязывайтесь к третям, а не к неизмеримым словам вроде «немного смещено от центра».

Рендеринг текста

Когда вы хотите текст на изображении, изолируйте его в отдельный блок и процитируйте точную строку:

[TEXT] render exactly the words "Ship faster" in a bold sans-serif,
placed in the reserved left third, vertically centered, single line,
high contrast against a plain background. No other text anywhere.

Ключевые моменты, сокращающие итерации:

• Цитируйте буквальную строку — никогда не перефразируйте её в промпте.
• Говорите «точно» и «никакого другого текста» — иначе лишние слова появятся по краям или на предметах.
• Указывайте количество строк («одна строка»), иначе переносы становятся догадкой.
• Указывайте контрастный фон («на сплошном фоне»), чтобы тексту было на что опереться.
• Держите текст полностью отдельно от блока [STYLE]; смешивание затрудняет настройку обоих.

Если запрос требует точной многоэлементной типографики, рассматривайте генерацию текста как отправную точку и планируйте настоящий текстовый слой ниже по потоку. Управление текстом на уровне промпта подходит для коротких заголовков и меток, но не для плотного основного текста.

Списки негативов: что исключать и как версионировать

Список негативов — ваше самое дешёвое средство контроля качества. Вместо описания того, что вы хотите, вы указываете режимы отказа, которые отказываетесь принимать.

Категории, которые стоит исключать

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

• Текстовые артефакты — лишние слова, искажённые глифы, водяные знаки, подписи.
• Артефакты компоновки — обрезанные субъекты, отсечённые конечности, дублирующиеся элементы, загромождённые края.
• Артефакты рендеринга — размытость, полосы, перенасыщенность, резкий HDR-вид, пластиковая кожа.
• Гигиена контента — брендинг, узнаваемые товарные знаки, портреты реальных людей.
• Стилевой дрейф — фотореализм в рецепте иллюстрации, иллюстративность в рецепте фотографии.

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

Держите его коротким и непротиворечивым

Слишком длинные списки негативов дают обратный эффект. Если негатив конфликтует с положительной инструкцией, результат становится нестабильным, и вы не можете определить, какая клауза победила. Два правила:

1. Никогда не отрицайте то, что вы просили. Если блок компоновки требует тени для глубины, не добавляйте глобальное «без теней».
2. Конкретное важнее общего. «Без водяных знаков» действенно; «никакой ерунды» — шум.

Версионируйте списки негативов вместе с промптами

Негативы меняют поведение каждого рецепта, который их цитирует, поэтому они нуждаются в такой же прослеживаемости, как и промпты:

{
  "negative_list_id": "global-v2",
  "entries": ["watermark", "signature", "stray text", "cropped subject", "duplicated elements", "oversaturated colors"]
}

Ссылайтесь на этот список по ID из каждого рецепта и увеличивайте ID при редактировании. Когда качество вывода смещается после деплоя, «изменился ли список негативов?» становится строкой проверки в diff, а не расследованием.

Сравнение с реальным выводом перед запуском

Пока вы не посмотрели на реальный вывод, рецепт — лишь гипотеза. Процесс сравнения ниже намеренно лёгкий — он должен занимать несколько минут, а не спринт.

Процесс

1. Заморозьте всё, кроме одной переменной. Тот же блок субъекта, та же компоновка, те же негативы, и если API предоставляет seed — тот же seed. Меняйте только блок стиля.
2. Сгенерируйте небольшую матрицу. Два-три стилевых варианта с двумя-тремя репрезентативными субъектами обычно достаточно, чтобы выявить плохой рецепт.
3. Сравнивайте параллельно, а не последовательно. Последовательное сравнение влечёт ошибку недавности — последнее изображение кажется лучшим только потому, что оно самое свежее.
4. Оценивайте по требованиям, а не по вкусу. Запишите, для чего предназначен материал (герой-баннер, набор иконок, редакционный заголовок), и проверьте конкретные свойства, которые действительно важны: действительно ли зарезервированное пространство пусто, нет ли лишнего текста, нет ли стилевого дрейфа.
5. Повышайте осознанно. В продуктовый код попадают только те ревизии рецепта, что прошли рецензию, с их меткой версии.

На что обращать внимание

• Согласованность между субъектами. Стилевой блок, работающий на одном субъекте и разваливающийся на другом, ещё не готов.
• Соблюдение ограничений. Остаётся ли зарезервированная левая треть пустой? Появляется ли процитированная точная строка только один раз?
• Кластеризация сбоев. Если один и тот же артефакт появляется в нескольких вариантах, он должен попасть в список негативов, а не в стилевую подстройку.

Храните всё в репозитории

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

Как только рецепт прошёл этот цикл, переключение между иллюстрацией и фотографией для заданного субъекта становится редактированием одного поля — именно ту характеристику сопровождения и должен был дать скелет. Запускайте эти рецепты через единый API для генерации изображений Recraft v4.1 и версионируйте каждую ревизию промпта вместе с кодом, который её вызывает.