Пайплайны и автоматизация: шаблоны, библиотеки промптов, A/B-тесты
Продвинутые промпты для Nano Banana Pro, Veo 3.1 и Kling 3.0 становятся по-настоящему управляемыми не тогда, когда вы нашли «идеальные слова», а когда у вас есть повторяемый процесс: шаблоны, библиотека, версии, тесты, логирование результатов.
В предыдущих статьях курса мы собрали «контракт» генерации:
архитектура цели–ограничения–приоритеты
Style Block (цвет, свет, фактура)
для видео: Camera Block, Blocking Block, Edit Block
для серий: Character Sheet и Object Sheet
для правдоподобия: Scene Block
для стабильности: итерации и отладка по слоямЭта статья показывает, как превратить всё это в производственный пайплайн: так, чтобы серия изображений или клип генерировались не «вручную по вдохновению», а как проект с контролем качества.
!Общая карта процесса: от брифа до библиотеки и A/B-тестов
Зачем нужен пайплайн, если промпт уже продвинутый
Пайплайн решает три типовые проблемы продвинутой генерации:
Повторяемость: вы можете воспроизвести удачный результат через неделю и понять, чем он получился.
Масштабирование: серия из 30 кадров или 10 роликов делается быстрее, потому что меняются только контролируемые переменные.
Сравнимость: вы понимаете, какая правка реально улучшила результат, а какая просто «случайно повезло».Связка с предыдущей статьёй про отладку прямая: пайплайн формализует правило одна итерация — одна гипотеза.
Канонический промпт как единый формат для всех моделей
Чтобы библиотека и тесты работали, нужен один «источник истины» — канонический промпт, который вы храните и версионируете. Затем вы адаптируете его под конкретный интерфейс Nano Banana Pro / Veo / Kling.
Почему это важно
Одна и та же идея, записанная «как текст», в разных системах превращается в разные поля: где-то отдельный негативный промпт, где-то отдельные настройки видео, где-то прикреплённые референсы. Если у вас нет канона, вы не сможете честно сравнивать версии.
Мини-шаблон канонического промпта
Ключ: этот формат совпадает с архитектурой курса и поэтому устойчив к усложнению.
Шаблоны: как «разделить переменное и постоянное»
Шаблон нужен, чтобы 80% стабильных требований не переписывались каждый раз. Вы меняете только переменные: локацию, действие, ракурс, эмоцию, длительность.
Два уровня шаблонов
Базовый шаблон проекта: стиль бренда, запреты, приоритеты качества, базовые паспорта персонажей/объектов.
Шаблоны сцен: типовые сцены, которые повторяются (продукт на столе, герой в коридоре, интерьерный общий план, диалог). Практика: плейсхолдеры и «словарь переменных»
Не усложняйте: достаточно фигурных скобок и списка переменных.
Далее вы создаёте «словарь» значений для переменных под конкретную сцену.
Ошибка шаблонов
Шаблон не должен превращаться в «простыню всего на свете». Если блок не нужен (например, нет персонажей), он должен быть пустым или удаляться, иначе вы сами создадите конфликт требований.
Библиотека промптов: структура, метаданные, поиск
Библиотека промптов — это не папка со случайными текстами, а система, где каждый артефакт можно:
найти
воспроизвести
сравнить
повторно использовать как модульПрактическая основа: хранить всё в репозитории и версионировать как код. Для этого подходит Git.
Минимальная структура проекта
Метаданные: что обязательно фиксировать
| Поле | Зачем нужно | Пример |
|---|---|---|
| id | уникальность и поиск | lab_door_entry_v03 |
| target_model | адаптация под систему | veo31, kling30, nano_banana |
| type | изображение или видео | image / video |
| duration/aspect | воспроизводимость | 9s, 16:9 |
| seed (если есть) | честные сравнения | 123456 |
| refs | привязка стиля/сцены | список файлов/ссылок |
| known_issues | ускоряет отладку | «иногда добавляет текст» |
| success_criteria | объективная проверка | «нет flicker, объект не меняет форму» |
!Понятно, как выглядит единица хранения в библиотеке
Нейминг и версии
Рабочее правило:
scene_key + intent + vNN
пример: office_flashdrive_hide_v07Версия увеличивается только при осмысленной правке. Случайные «ещё одно слово добавил» без гипотезы лучше не версионировать как новую «официальную» версию.
Адаптеры под Nano Banana Pro, Veo 3.1 и Kling 3.0
Чтобы канонический промпт был переносимым, выделите слой адаптации.
Идея адаптера
Канонический промпт хранит смысл и блоки курса.
Адаптер превращает блоки в формат конкретного интерфейса.Пример правил адаптации (концептуально):
NEGATIVE идёт в поле негативного промпта (если оно отдельное), иначе в конец текста как «чего не должно быть».
VIDEO_BLOCKS для Veo/Kling сохраняется как отдельные абзацы с явными маркерами.
Для Nano Banana Pro видео-блоки могут использоваться как раскадровка: вы генерируете ключевые кадры по каждому состоянию блокинга.Цель адаптера не «магия», а одинаковая логика управления для разных моделей.
Автоматизация прогонов: как запускать серии контролируемо
Автоматизация начинается не со скриптов, а с дисциплины: один манифест запуска, фиксированные параметры, единый чеклист оценки.
Манифест прогона
Манифест — это файл (или строка в таблице), который описывает, что именно вы запустили.
Если система не поддерживает seed, вы всё равно фиксируете количество попыток и неизменность промпта, иначе сравнение будет нечестным.
Пакетные вариации: что можно менять безопасно
Лучше менять только параметры, которые вы заранее отметили как вариативные (из статьи про консистентность):
ракурс и крупность в разумных пределах
выражение лица и поза
фон и второстепенный реквизит
уровень детализации фонаОпасные вариации, которые часто ломают непрерывность:
резкая смена оптики и широкие углы вместе с движением камеры
сложные отражающие поверхности и зеркала
много персонажей и активный монтажОценка качества: чеклист и скоркард вместо «нравится/не нравится»
A/B-тесты невозможны без одинакового способа оценки. Самый практичный вариант — чеклист + короткая скоркард-форма.
Базовый чеклист (универсально)
идентичность персонажа/объекта сохранена
лицо и руки без артефактов
нет текста, логотипов, водяных знаков
стиль совпадает: палитра, свет, фактура
сцена правдоподобна: контактные тени, материалы без пластиковостиДля видео дополнительно
нет мерцания света и экспозиции (no flicker)
действие читаемо и соответствует блокингу
нет случайных склеек и «скачков» (если one-take)Вы можете оформить это как таблицу и ставить отметки. Для общей теории полезно понимать, что такое A/B-тестирование: A/B testing.
A/B-тесты промптов: как сравнивать версии честно
A/B-тест в промптинге — это сравнение двух версий промпта при контроле всех прочих условий.
Что считается «честным A/B»
меняется только один фактор (например, только Edit Block)
одинаковое количество попыток на A и на B
одинаковые условия (формат, длительность, референсы)
одинаковый чеклист оценки
по возможности фиксированные seed или заранее заданный список зерёнПример: тестируем монтаж против непрерывности
Гипотеза: «one-take повысит консистентность лица и реквизита по сравнению с 3 кадрами».
A: Edit Block = one-take
B: Edit Block = 3 кадра
всё остальное неизменно, включая Style Block, Sheets, Scene Block, негативный промптДалее вы считаете, сколько удачных результатов на каждой стороне по чеклисту.
Типовые ошибки A/B
менять сразу 2–3 блока и называть это A/B
сравнивать одну удачную генерацию A с одной неудачной B
оценивать по разным критериям («в A смотрю на стиль, в B на движение»)Когда нужен не A/B, а факторный тест
Если вы не понимаете, что именно влияет (камера, свет, негатив, приоритеты), полезнее тестировать по одному фактору в серии мини-A/B. Общая рамка этого подхода относится к методам планирования экспериментов: Design of experiments.
Библиотека модулей: переиспользование блоков как деталей конструктора
Сильная библиотека хранит не только «готовые промпты», но и модули:
Style Block для конкретного бренда
Scene Block для типовых локаций
Character Sheet и Object Sheet
наборы негативных промптов под классы артефактовПрактическая выгода: вы не переписываете промпты, вы собираете их.
Пример: библиотека негативных наборов
negative_anatomy.txt: руки, лицо, лишние пальцы
negative_text.txt: текст, логотипы, водяные знаки
negative_video_artifacts.txt: flicker, shaky camera, jump cutsДальше вы подключаете только те наборы, которые не конфликтуют со стилем.
Как пайплайн связывается с отладкой по слоям
В статье про итерации мы чинили результат вопросом «где болит: цель, стиль, камера, блокинг, монтаж, сцена, sheets, ограничения?». Пайплайн делает этот подход системным:
чеклист оценки заранее привязан к слоям
версия промпта фиксирует одну гипотезу
манифест запуска фиксирует условия
библиотека хранит не только текст, но и результаты и оценкиИтог: вы быстрее приходите к стабильной «базовой версии», а усложнения добавляете контролируемо.
Итог
Пайплайн продвинутых промптов — это мост между «умением писать» и «умением производить серию результатов»:
канонический промпт фиксирует архитектуру курса в одном формате
шаблоны отделяют постоянное от переменного
библиотека с метаданными и версионированием делает результаты воспроизводимыми
автоматизация прогонов через манифесты и пакетные вариации ускоряет работу
A/B-тесты превращают улучшение промптов в управляемый эксперимент, а не в надежду на удачу