Как разделить композицию и стиль при работе с референсами

Вы передаёте генератору макет, стилевой референс и изображение объекта. Запрос выполняется без ошибок, но результат похож на безликий сток: объект смещён, место под заголовок исчезло, а несколько визуальных направлений смешались в неопределённый «AI-стиль». В такой ситуации не стоит сразу удлинять prompt. Сначала назначьте каждой картинке конкретную задачу, а затем сравните результат с исходной композицией по пунктам.

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

Главное правило: композицию и внешний вид должны контролировать разные референсы

Не передавайте все изображения как одинаково важные и никак не подписанные. Минимально полезно разделить три роли:

Роль референса	Что он должен контролировать	Что он не должен контролировать
Композиция	Количество объектов, их положение и масштаб, камеру, кадрирование, свободное место	Палитру, материал, характер линий и освещение
Объект	Идентичность, форму и отличительные детали персонажа или предмета	Общую сцену и посторонние элементы фона
Стиль	Палитру, фактуру, зерно, линии, свет и способ рендеринга	Объекты, текст и композицию самого стилевого изображения

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

Почему плоский список часто превращается в усреднённую картинку

Плоский список сообщает системе только одно: «все эти изображения важны». Он не объясняет, зачем нужно каждое из них. Модели или промежуточному агенту приходится угадывать связь: взять цвет из первой картинки, фактуру из второй, случайный объект из третьей и собрать правдоподобный, но нецелевой вариант.

При этом запрос может быть полностью корректным. Авторизация, загрузка файлов, синтаксис и разбор ответа работают, поэтому статус HTTP или сообщение «генерация завершена» не обнаруживают визуальный сбой. В процесс нужна отдельная проверка композиции.

Шаг 1. Составьте контракт роли для каждого изображения

До длинного prompt ответьте на четыре вопроса по каждому файлу:

1. Что обязательно сохранить? Например: объект остаётся в левом нижнем углу, сверху есть место под заголовок, камера расположена низко.
2. Что нужно игнорировать? Например: личность человека, логотип и архитектуру фона на стилевом референсе.
3. Насколько жёсткое это требование? Композиция — обязательное условие, а цвет — пожелание, или наоборот?
4. Кто побеждает при конфликте? Например: расположение из макета важнее расположения объектов на стилевой картинке.

Рабочий контракт может выглядеть так:

Файл	Роль	Сохранить	Игнорировать	Правило конфликта
layout.png	Композиция	Два объекта разного размера, пустое место справа, вид сверху	Цвет и материал	Пространственные отношения имеют высший приоритет
subject.png	Объект	Силуэт и характерные детали	Исходный фон и ракурс	Заменить объект в макете, не меняя его положение
style.png	Стиль	Тёпло-серую палитру, бумажное зерно, мягкие тени	Людей и текст	Перенести только визуальный язык, не копировать содержание

Такая таблица полезнее обозначений «референс 1, 2 и 3», потому что задаёт не только желаемые признаки, но и запреты.

Шаг 2. Передавайте роли и приоритеты, а не один общий список

Поля API у разных инструментов отличаются. Ниже приведена концептуальная структура запроса, а не реальный контракт конкретного сервиса. Она помогает проверить, сохранил ли агент роли до финального вызова:

references:
  - id: layout
    source: layout.png
    role: composition
    preserve: [subject_count, position, scale, camera, negative_space]
  - id: subject
    source: subject.png
    role: identity
    preserve: [shape, distinctive_details]
  - id: style
    source: style.png
    role: appearance
    preserve: [palette, texture, line_quality, lighting]
    exclude: [objects, text, composition]
priority:
  - layout
  - subject
  - style
acceptance_reference: layout.png

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

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

Шаг 3. Если интерфейс не различает роли, работайте в два этапа

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

Этап A: зафиксируйте сцену и объект

Передайте макет и, если нужно, референс объекта. Опишите количество объектов, их положение, камеру, кадрирование и свободное место. Материал и способ рендеринга пока не задавайте. На выходе нужна структурно правильная картинка, даже если она выглядит просто.

Этап B: измените внешний вид, не перестраивая сцену

Возьмите результат этапа A как основу и примените стилевой референс через редактирование или перерисовку. Явно зафиксируйте положение объектов, границы, камеру, кадр и свободное место; менять можно только палитру, фактуру, линии и свет.

При наличии масок откройте для редактирования только нужные области. Если режима редактирования нет, сделайте результат этапа A главным референсом, а стиль — вторичным. Возможность задавать веса проверяйте в актуальной документации инструмента.

Шаг 4. Проведите четыре контрольных запуска

Не меняйте бесконечно один сложный запрос. Зафиксируйте prompt, размеры и остальные управляемые параметры, затем сделайте четыре варианта:

Тест	Вход	Что проверять
A	Только макет	Сохраняются ли количество, положение и масштаб объектов, камера и свободное место
B	Только стиль	Какие именно цвета, фактуры, линии и свет инструмент переносит
C	Макет и стиль одним плоским списком	Появляется ли усреднение, компромисс или чужое содержание
D	Макет и стиль с ролями и приоритетом	Стали ли композиция и внешний вид ближе к своим целям, чем в C

Задача теста — не объявить модель «хорошей» или «плохой». Он показывает, где теряется сигнал: при понимании одной картинки, при объединении нескольких или при формировании параметров агентом. Если A и B работают, C уходит в сторону, а D становится лучше, вероятна неоднозначность ролей. Если D не отличается от C, проверяйте финальный payload или переходите на двухэтапную схему.

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

Шаг 5. Принимайте по макету, а не по впечатлению «выглядит неплохо»

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

Жёсткие условия: ошибка в любом пункте означает отказ

• Количество объектов совпадает с заданием.
• Положение и относительный масштаб соответствуют макету.
• Направление камеры, кадрирование и ракурс сохранены.
• Место под текст или другая отрицательная область осталось свободным.
• Из стилевого референса не перешли лишние объекты, люди или надписи.
• Отличительные признаки основного объекта узнаваемы.

Мягкие условия: по ним выбирают среди прошедших вариантов

• Палитра близка к целевой.
• Фактура и зерно выглядят осмысленно, а не грязно.
• Линии, края и тени соответствуют выбранному визуальному языку.
• Стиль выглядит цельным, а не средним арифметическим нескольких направлений.

Показывайте макет и кандидата рядом и отмечайте «пройдено/не пройдено» по каждому жёсткому условию. Сохраняйте не только итоговую картинку, но и версию запроса, порядок референсов и фактически отправленный агентом payload. Тогда следующий дрейф можно будет воспроизвести.

Что проверять при типичных симптомах

Симптом	Сначала проверьте	Что делать
Стиль выражен, но композиция изменилась	Не стал ли стилевой референс равноправным главным	Повысить приоритет макета или разделить этапы
Композиция верна, но стиль слабый	Нет ли в prompt только абстрактных слов о настроении	Назвать наблюдаемые цвета, материалы, линии и свет
Несколько стилей смешались в типовой вид	Нет ли одновременно конфликтующих стилевых картинок	Выбрать один главный стиль, остальным оставить по одному признаку
В результат попал объект со стилевой картинки	Было ли сказано переносить только внешний вид	Исключить объекты, текст и композицию стилевого референса
Изменения prompt не влияют на результат	Отправил ли агент новые параметры	Сравнить конечные payload, а не только форму наверху
API отвечает успешно, но дрейф повторяется	Не используется ли статус запроса как критерий качества	Добавить жёсткую проверку композиции и контрольные варианты

Минимальный процесс, который можно повторять

1. Оставьте только те референсы, без которых задача не решается.
2. Назначьте каждому изображению одну главную роль, а также правила сохранения, игнорирования и конфликта.
3. Проверьте финальный запрос агента: массив, порядок и роли не должны быть сплющены.
4. Сделайте отдельные базовые запуски для макета и стиля, затем сравните плоский и ролевой варианты.
5. Сначала отбраковывайте по жёстким условиям композиции, потом сравнивайте стиль.
6. Храните вместе кандидаты, референсы, версии запросов и результаты проверки.
7. Если интерфейс не умеет выражать роли, сначала создайте композицию, затем примените стиль.

Смысл метода не в более длинном prompt. У каждого визуального сигнала должен появиться ответственный референс. Пока вы можете ответить, какая картинка чем управляет, кто выигрывает при конфликте и по каким признакам результат принят, набор референсов перестаёт быть стопкой изображений, которую модель должна понять сама.