• Каждое описание кадра содержит 7 именованных элементов, но остаётся прозой, а не анкетой
  • Элементы подписываются прямо в тексте, чтобы следующие стадии не извлекали их заново
  • Storyboard читает крупность и угол, стиллы читают субъект и оптику, видео читает движение

Задача

Режиссёр пишет описание кадра так, как сказал бы на площадке: «средний план, женщина за столом, мягкий свет из окна». Где-то указана крупность, где-то оптика, угол не указан никогда. Следующие стадии генеративного пайплайна (storyboard, стиллы, видео) пытаются вытащить из этой фразы параметры камеры и света и промахиваются примерно в половине случаев.

Обратный ход тоже не работает. Если перевести пайплайн на жёсткие JSON-объекты с семнадцатью полями, половина полей остаётся пустой или заполняется словом «default», а режиссёры перестают писать сами. Свободная проза теряет измерения, схема — убивает авторство. Нужен средний путь.

flowchart TD
    P[Свободная проза] --> P1[Теряет измерения:<br/>промах в половине]
    J[JSON на 17 полей] --> J1[Пустые поля,<br/>режиссёры не пишут]
    P1 --> M[Проза с семью<br/>обязательными элементами]
    J1 --> M
    classDef key stroke:#FF3600,stroke-width:2px
    class M key

Приём

Оставить прозу, но сделать небольшой фиксированный набор измерений обязательным в каждом описании. Семь элементов:

  1. Субъект и действие: что видит камера и что оно делает.
  2. Локация: где разворачивается сцена.
  3. Крупность: общий, средний, крупный, деталь.
  4. Угол: на уровне глаз, сверху, снизу, с верхней точки.
  5. Движение: статика, панорама, наезд, орбита.
  6. Оптика: широкоугольная, нормальная, портретная, макро.
  7. Свет: направленный, мягкий, жёсткий, практический, естественный.

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

Женщина за кухонным столом подписывает документ; утренняя кухня.
Крупность: средний крупный. Угол: на уровне глаз.
Движение: медленный наезд. Оптика: эквивалент 50 мм.
Свет: мягкий боковой из окна.

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

Почему проза, а не JSON. Следующие стадии читают описание по-разному, и каждой нужен свой срез:

СтадияКакие элементы читает
StoryboardКрупность, угол, движение (композиция)
СтиллыСубъект, локация, оптика (содержание сцены)
ВидеоДвижение, субъект и действие (моушн)

JSON заставил бы каждого потребителя маппить поля обратно в текст, понятный модели. Проза позволяет измерениям взаимодействовать («широкоугольная оптика с нижней точки и медленный наезд»), тогда как схема хранила бы три разорванных значения. И модели пишут прозу заметно лучше, чем заполняют структурированные поля.

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

flowchart LR
    R([Режиссёр]) -->|пишет руками| D[Семиэлементное<br/>описание]
    M([Модель]) -->|выдаёт| D
    D --> P[Пайплайн:<br/>без потерь]
    D -. читает и правит .-> R

Паттерн обобщается за пределы монтажных листов. Формула одна: небольшой фиксированный набор именованных измерений в форме прозы, покрывающий пространство решений, не схлопываясь в анкету. Тестовые кейсы (вход, ожидаемый выход, предположения, setup, teardown, покрытый edge-case, автор), подзадачи агентного плана (цель, предусловия, действие, ожидаемое состояние, откат, метрика, таймаут), карточки персонажей в сцене. Любая задача вида «список структурированных, но читаемых элементов» выигрывает от того же трюка.

flowchart TD
    F[Именованные измерения<br/>в форме прозы] --> A[Монтажный лист:<br/>7 элементов кадра]
    F --> B[Тест-кейсы]
    F --> C[Подзадачи<br/>агентного плана]
    F --> D[Карточки<br/>персонажей]

Где ломается

  • Частичные описания. Модель пропускает оптику или свет, потому что пользователь их не задал. Контрмера: системный промпт требует все семь; если измерение не указано, модель выбирает разумный дефолт и называет его явно.
  • Утечка измерений. Свет оказывается внутри субъекта («женщина, освещённая тёплым светом»), и storyboard-стадия его не видит. Контрмера: анти-примеры в системном промпте.
  • Сверхсжатие. Описание схлопывается в одно предложение, где все семь упомянуты, но ни одному не дано места. Контрмера: минимум одно предложение или минимальное число слов на элемент.
  • Семь элементов не описывают стиль, цвет и настроение. Это намеренно: эти измерения приходят из референсов на стадии рендера, а не из текста. Если команда начинает дописывать восьмой и девятый элемент, паттерн деградирует обратно в анкету.

Итог

  • Семь обязательных именованных элементов в прозе: обязательное покрытие, свободное выражение.
  • Измерения подписываются в тексте один раз — следующие стадии читают их напрямую и не извлекают повторно.
  • Один и тот же формат пишут и человек, и модель, поэтому кадр можно править на любой стадии.
  • Паттерн переносится на любую задачу формата «монтажный лист»: тесты, планы агентов, карточки персонажей.

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