• 3 стадии вместо одного промпта (анализ брифа, парсинг сценария, редактирование списка)
  • У каждой стадии своя температура: 0.4 для анализа и 0.3 для парсинга и правок
  • Имя кадра вида 1A, 1B, 2A несёт структуру, на которой держится консистентность дальше

Задача

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

Хуже того, один и тот же бриф от того же клиента в следующий раз выходит другим, потому что шаги никто не задокументировал. Ниже эти шаги оформлены как три LLM-стадии, чтобы путь от брифа до шот-листа был воспроизводимым, а не изобретался под каждый проект заново.

Приём

Пайплайн принимает свободный бриф (плюс опциональные файлы базы знаний: сценарии, референс-документы, заметки) и отдаёт структурированный, редактируемый список сцен с детализацией до кадра. Каждый кадр описан семью элементами и помечен типом (полностью генеративный, композит с живой съёмкой, живой материал) и длительностью.

Стадия 1. Анализ брифа. Модель в роли продакшн-режиссёра читает бриф и файлы, выдаёт обзор проекта (стиль, аспект, оценка хронометража, технические заметки) и список кадров. Температура 0.4: немного творческой интерпретации допустимо, потому что бриф всегда неполон.

Стадия 2. Парсинг сценария. Для проектов, где пользователь приносит уже написанный сценарий вместо брифа. Другая точка входа, та же форма выхода. Модель находит логические каты и разбивает их на кадры по той же схеме. Температура 0.3: готовый сценарий нельзя додумывать, только структурировать.

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

добавь крупный план коробки продукта перед сценой 2
удали кадры 3A и 3B, слей 3C в сцену 4

Модель применяет только запрошенные изменения и сохраняет всё остальное дословно, следит, чтобы два соседних кадра не делили одинаковую крупность, и переиндексирует имена, когда добавления или удаления сдвигают буквенную последовательность внутри сцены (2A/2B/2C остаётся непрерывным, никогда не 2A/2C/2D). Температура 0.3: редактирование должно быть почти детерминированным.

flowchart LR
    B[Бриф + файлы<br/>базы знаний] --> S1[Стадия 1: анализ<br/>брифа, 0.4]
    C[Готовый<br/>сценарий] --> S2[Стадия 2: парсинг<br/>сценария, 0.3]
    S1 --> L[Список кадров]
    S2 --> L
    L --> S3[Стадия 3:<br/>редактирование, 0.3]
    S3 -.-> L
    I([Инструкция<br/>на обычном языке]) --> S3

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

flowchart TD
    N[Сцена 1:<br/>утренняя кухня] --> A[Кадр 1A]
    N --> B[Кадр 1B]
    M[Сцена 2] --> C[Кадр 2A]
    M --> D[Кадр 2B]
    M --> E[Кадр 2C]

Два решения принимаются уже здесь, а не позже. Первое — тип кадра: от него зависит, что описывает промпт на рендере (композит описывает только передний план, полностью генеративный кадр описывает всё). Второе — парные ключевые кадры для сшивки переходов: первый и последний кадр перехода помечаются в сценарии, чтобы дальше рендер одного стал стартовым, а рендер другого — конечным кадром одного видеоклипа. Откладывание любого из этих решений загрязняет каждую следующую стадию.

flowchart LR
    F[Первый кадр<br/>перехода] -->|рендер: старт| V[Один<br/>видеоклип]
    L[Последний кадр<br/>перехода] -->|рендер: конец| V

Почему три стадии, а не одна. Монолитный промпт «бриф → список кадров» соблазнителен, но даёт хрупкий выход. Разделение даёт три свойства. Две точки входа с общей формой выхода, поэтому всё дальше по пайплайну не зависит от источника. Редактирование как отдельная стадия со своей семантикой (сохранять остальное, переиндексировать, держать разнообразие камеры), которой не место в промпте первой генерации. И температура на стадию: одно значение не закрывает анализ, парсинг и правку одновременно.

Этот каскад — единственная часть системы, которую пишет модель. Всё ниже (storyboard, стиллы, видео) работает с его структурированным выходом и никогда — с исходным брифом.

flowchart LR
    K[Каскад: бриф<br/>до шот-листа] --> O[Структурированный<br/>выход]
    O --> SB[Storyboard]
    O --> ST[Стиллы]
    O --> V[Видео]

Где ломается

  • Анализ брифа при 0.4 иногда придумывает кадры, которых клиент не просил. Это цена интерпретации; стадия редактирования существует, чтобы их убрать, но продюсер должен прочитать первый драфт целиком, а не только начало.
  • Парсинг сценария хорошо находит каты в тексте, написанном сценарно, и плохо — в прозе без явной структуры. Художественный текст лучше подавать как бриф, а не как сценарий.
  • Правило «соседние кадры не делят крупность» — эвристика, а не закон. Когда драматургия требует двух одинаковых планов подряд, инструкция редактирования должна снять правило явно.
  • Тип кадра и парные ключевые кадры задаются человеком. Автоматический выбор пока не решён, и ошибка здесь дорого стоит дальше.

Итог

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

© Александр Никулин. Цитирование — с указанием автора и ссылкой · Версия для LLM