Бриф → сценарий → сцены: пайплайн нарративной обработки
Клиент присылает то, что есть: абзац текста, голосовое, полуготовый сценарий, иногда PDF-презентацию. Storyboard-стадия дальше по пайплайну хочет другого — нумерованный шот-лист с per-shot крупностью, углом, движением, оптикой и светом. Перевод между первым и вторым — это та часть, что всегда уезжает за дедлайн. Вы бегло читаете бриф, пишете половину шот-листа, к третьему пункту теряете нить «зачем этот шот», и всё равно сохраняете. Один и тот же бриф от того же клиента в следующий раз выходит другим — потому что никто не документировал шаги.
Ниже — эти шаги, оформленные как три LLM-стадии, чтобы путь «бриф → шот-лист» был воспроизводимым, а не изобретался под каждый проект заново.
Этот пайплайн — слой нарративной обработки в системе генеративного видео-продакшна. Три стадии превращают свободный клиентский бриф (плюс опциональные файлы knowledge base) в структурированный, редактируемый список сцен с гранулярностью до кадра — готовый к storyboard- и стиллс-генерации дальше по пайплайну.
Стадия 1 — Анализ брифа
Входы
brief— свободный клиентский текст.kbFiles— опциональные файлы knowledge base с предварительно извлечённым текстом (PDF, сценарии, референс-документы, заметки).
Процесс
- Системная роль LLM: профессиональный продакшн-режиссёр.
- Температура: 0.4 (сдвиг к консистентности).
- Щедрый бюджет токенов (~12k) — на выходе структурированный список кадров, не проза.
Выходы
- Project overview — описание стиля, аспект (16:9 / 9:16 / 1:1), оценка хронометража, технические заметки.
- Список кадров — кадры названы по схеме
{номер-сцены}{буква}(1A, 1B, 1C, 2A, 2B, …) с полями:description— семиэлементная проза (субъект + действие, локация, крупность, угол, движение, оптика, свет).type—full-ai|composite|live.duration— секунды (типичный рекламный темп 0.2–0.8).isKeyFrame— опционально,"first"или"last", для сшивки переходов через парные кадры.
Стадия 2 — Парсинг сценария
Для проектов, где пользователь приносит уже написанный сценарий или нарратив вместо брифа. Другая точка входа, та же форма выхода.
- LLM на температуре 0.3 (детерминированность), динамический бюджет токенов под объём сценария.
- LLM определяет логические каты и разбивает их на кадры по той же схеме именования.
- Те же семиэлементные описания, что на Стадии 1.
Стадия 3 — Редактирование сценария
Цикл между «первый драфт» и «то, что нужно пользователю». Отличается от пошагового рефайнинга, который правит один кадр. Эта стадия редактирует список кадров.
Входы
- Текущий список кадров (JSON).
- Инструкция на свободном языке: «добавь крупный план коробки продукта перед сценой 2», «удали кадры 3A–3B, слей 3C в сцену 4».
Поведение
- LLM применяет только запрошенные изменения и сохраняет все остальные поля дословно — это дисциплина сохранения правок.
- Разнообразие камеры: два соседних кадра не должны делить одинаковую крупность.
- Переиндексирует имена кадров, когда добавления или удаления сдвигают буквенную последовательность внутри сцены, — чтобы 2A/2B/2C оставалось непрерывным (никогда не 2A/2C/2D).
Важные дизайн-решения
«Сцена» vs «кадр» — схема scene-letter
Сцена — нарративная единица («утренняя кухня»). Внутри сцены кадры — это визуальные beats, покрывающие её с разных углов. Схема {номер-сцены}{буква} несущая:
- Номер сцены группирует кадры, которые делят локацию, время и continuity.
- Буквенный суффикс упорядочивает кадры внутри сцены.
- Кадры внутри сцены обрабатываются последующими стадиями как серия — они должны оставаться визуально консистентными по всей последовательности.
- Между сценами кадры могут свободно варьироваться.
Семь обязательных элементов описания
Каждое описание кадра — на каждой стадии — содержит одни и те же семь элементов: субъект + действие, локация, крупность, угол, движение, оптика, свет. Это не A.O.C.; это upstream-структура, питающая downstream-A.O.C. Она даёт storyboard-стадии достаточно, чтобы нарисовать, и стиллс-стадии достаточно, чтобы скомпоновать кадр.
isKeyFrame и парные переходы
Кадры с isKeyFrame: "first" и isKeyFrame: "last" явно спарены для сшивки видео-переходов: рендер «first» становится стартовым кадром, рендер «last» — конечным для одного сгенерированного клипа, давая бесшовный морф-переход. Установка этого на этапе брифа — не после генерации — делает согласование пар на следующих стадиях становится автоматическим.
type: full-ai / composite / live
- full-ai — кадр генерируется целиком.
- composite — живое действие на AI-фоне.
- live — реальный материал, без генерации; промпты всё равно генерируются как редакторская подсказка.
type задаётся на этапе брифа/сценария, потому что от него зависит последующая генерация промптов — стиллс-промпт для composite описывает только foreground-субъект, а full-ai-промпт описывает весь кадр. Откладывание этого решения загрязняет каждую последующую стадию.
Почему три стадии, а не одна
Монолитный промпт «бриф → список кадров» соблазнителен, но даёт хрупкий выход. Деление на анализ, парсинг и редактирование даёт три свойства:
- Две точки входа. Одни проекты стартуют с брифа, другие — со сценария. Общая форма выхода позволяет всем последующим стадиям оставаться неинвариантными к источнику.
- Edit-как-стадия. Цикл инструкций редактирования имеет отдельную семантику — сохранять-всё-остальное, переиндексировать имена, держать разнообразие камеры — которая не должна жить в промпте первой генерации.
- Температура на стадию. Анализ терпит немного творческой интерпретации (0.4); парсинг готового сценария не должен ничего выдумывать (0.3); редактирование должно быть почти детерминированным. Одна температура не закрывает все три случая.
Этот пайплайн целиком — та часть системы, которую авторит LLM. Всё, что ниже — storyboards, стиллы, видео — работает с его структурированным выходом, никогда не с исходным брифом.