Архитектура стилевого префикса

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

Исправлять нужно, делая класс референсов стилистически однородным по конструкции, чтобы модель на следующей стадии не могла перепутать «стиль, который я тут вижу» и «стиль, который я должна произвести». Каждый промпт класса начинается с одного и того же префикса. Все выходы стилистически выглядят одинаково; различаются только содержимым. Стиль становится константой, а не переменной — а константа не несёт информации, и читатель на следующей стадии естественным образом её игнорирует.

Это и есть архитектура стилевого префикса: каждый промпт класса префиксуется идентичной стилевой строкой, превращая выходы класса в нейтральный, взаимозаменяемый визуальный словарь. Каноничный случай — генерация storyboard в AI-видео-пайплайне. Каждый промпт storyboard — в любом проекте, для любого кадра — префиксуется одной и той же ~50-словной стилевой строкой:

traditional hand-drawn storyboard frame on white paper, clean black ink line art with selective red accent lines for key action and focal points, minimal shading using hatching, professional film storyboard sketch style, no color except black white and red

Форма

Любой промпт класса:
  [ФИКСИРОВАННЫЙ СТИЛЕВОЙ ПРЕФИКС, ~50 слов]
  +
  [описание конкретного кадра, переменное]

Любой выход класса:
  Выглядит стилистически как любой другой выход класса.
  Отличается только содержанием.

Почему важна именно фиксированность

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

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

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

Когда применять

• Когда класс выходов будет потреблён как референс на следующей стадии. Классу нужен узнаваемый, стабильный визуальный почерк.
• Когда вариация стиля загрязнила бы целевое последующее использование. Если стиль гуляет, последующие стадии не смогут чисто отделить «стиль из этого референса» от «композицию из этого референса».
• Когда важна стоимость одного выхода. Рендер всего класса в дешёвом, быстром стиле (line art, wireframe, storyboard) перед дорогим финальным рендером — каноничная экономия.

Когда не применять

• Когда класс — финальный deliverable. Все выходы с фиксированным префиксом выглядят одинаково; если пользователю нужно эстетическое разнообразие, эта архитектура работает против него.
• Когда стиль — одно из исследуемых измерений. Если стиль — творческая переменная, фиксировать его бессмысленно.

Режимы отказа

• Префикс игнорируется при высокой температуре. Некоторые модели слабо учитывают длинные префиксы, когда температура высокая. Контрмера: префикс короткий (~50 слов) и в начале; проверять, что стиль действительно попадает в выход.
• Префикс дрейфует со временем. Сопровождающие правят строку проект за проектом, и согласованность размывается. Контрмера: хранить префикс одной константой и переиспользовать дословно во всех проектах.
• Последующие стадии не отделяют стиль от композиции. Ценность архитектуры зависит от дисциплины последующей стадии. Если стадия стиллов копирует стиль storyboard вместо чтения композиции, выгода теряется. Контрмера: системные промпты последующих стадий должны явно запрещать копирование стиля.

Обобщается

• Wireframe-first генерация UI. Каждый wireframe выглядит одинаково (серые блоки, заполнитель текста); последующие стадии читают их ради раскладки, не визуального лоска.
• Плоско-векторный стиль для систем иконок. Фиксированная палитра + толщина линий на все промпты иконок.
• Единый стиль диаграмм в документации. Каждая архитектурная диаграмма следует одному префиксу; читатель обрабатывает их как информацию, а не как искусство.

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