• Весь промпт на ролик умещается в один JSON до 3500 символов с однобуквенными ключами
  • Камера живёт в поле c (до 80 символов), содержимое кадра — в поле p (до 250), без дублей
  • Каждый референс явно маппится на сцены, один помечается главным и держит большинство

Обновление, октябрь 2026: текст написан под Seedance 2.0 (апрель 2026); Seedance 2.5 уже поддерживает ролики до 30 с и нативный звук.

Задача

Seedance 2 принимает промпт на весь ролик одним компактным JSON: список референсов, глобальный блок и массив сцен, общий объём ограничен. Написать это руками под реальный проект с шестью кадрами и стопкой референсов означает час борьбы с форматом до первой генерации. К третьей правке глобальные заметки плывут, ID сцен перетасовываются, объём перепрыгивает лимит, и движение камеры оказывается описано дважды, в разных полях.

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

Приём

На вход: сценарий (на любом языке, проза или готовый шот-лист) и пронумерованные референсные стиллы. Опционально — переопределения: другой потолок объёма, целевое число сцен, зафиксированные заметки по одежде и локации. На выходе — один сырой JSON без обрамления и комментариев:

{"refs":[{"img":"1.png","s":"1,3","r":"PRIMARY: chars, interior, light"}],
 "g":"No text/icons, composited. Woman: blue top, jeans. Loft, daylight.",
 "s":[{"id":"1","c":"Floor ROCKET forward, blur streaks, crane up",
       "p":"Camera blasts into loft, walls streak. Two chars small at table."}]}

Правила полей. refs[]: каждому изображению точное имя файла, список ID сцен через запятую и описание того, что с него брать (одежда, интерьер, свет, кадрирование), не длиннее 80 символов. Каждый приложенный референс обязан появиться в refs[]; один помечается как главный (якорь персонажа и локации) и маппится на большинство сцен. g: одна строка до 300 символов с правилами для всех сцен сразу: что композитится отдельно (титры, иконки, UI), лок одежды, лок локации, правила VFX. s[]: на каждую сцену id как строка по порядку, c — для движения камеры (до 80 символов, кинематографическая стенография: dolly, orbit, whip pan, push-in, CRASH stop, motion blur) и p — для того, что видно в кадре (до 250 символов: среда, персонажи, действие, VFX, состояние движения, свет). В p камера не повторяется никогда.

flowchart TD
    J[Один JSON<br/>до 3500 символов] --> R[refs: файл, сцены,<br/>что брать, до 80]
    J --> G[g: глобальные локи<br/>до 300 символов]
    J --> S[s: сцены<br/>по порядку]
    S --> C[c: камера<br/>до 80 символов]
    S --> P[p: что в кадре<br/>до 250, без камеры]
    classDef key stroke:#FF3600,stroke-width:2px
    class P key

Порядок работы:

  1. Проверить входы. Сценарий есть, референсы сосчитаны, имена файлов зафиксированы как есть, переопределения уточнены до генерации.
  2. Разобрать сценарий. Сцена начинается на кате или на дискретном движении камеры; непрерывный проезд через несколько моментов остаётся одной сценой с длинным c. Пометить моменты заморозки, состояния VFX, композитные оверлеи, петли. Залочить одежду, локацию, описания персонажей.
  3. Разобрать каждый референс: одежда, элементы интерьера, положение рук и реквизит, стиль VFX (сетка, пиксели, каркас, частицы, их цвет и покрытие), угол и крупность, цветокор. Выбрать главный.
  4. Собрать refs[], затем g, затем s[]. Именно в этом порядке: глобальные правила не должны повторяться внутри сцен, поэтому они пишутся раньше.
  5. Сосчитать символы. Если весь JSON больше потолка (по умолчанию 3500), сжимать в таком порядке: уплотнить p аббревиатурами (env, VFX, DOF, bg, char, comp), слить соседние сцены с похожей камерой и содержимым, укоротить g, но никогда не удалять заметку о композитных элементах.
  6. Финальный проход: весь текст по-английски независимо от языка сценария, имена собственные и бренды сохранены, JSON валиден, без markdown и пояснений.
flowchart TB
    subgraph a[Разбор]
        direction LR
        A[Проверить<br/>входы] --> B[Разобрать<br/>сценарий]
        B --> C[Разобрать<br/>референсы]
    end
    subgraph b[Сборка]
        direction LR
        D[refs, затем g,<br/>затем s] --> E{Больше<br/>3500?}
        E -->|да| G[Сжать p, слить<br/>сцены, укоротить g]
        G --> E
        E -->|нет| F[Финальный<br/>проход]
    end
    a --> b

Частные случаи. Заморозка персонажей прописывается в каждой затронутой сцене явно, с позой и словами «Zero movement», иначе модель добавит микродвижение. VFX всегда со скоупом («on env NOT on chars»), иначе эффект протекает на актёров. Титры и UI не описываются по содержанию: в g отмечается, что они композитятся отдельно, в p оставляется «empty comp space». Для зацикленного ролика p последней сцены указывает, что финальный кадр совпадает с первым кадром сцены 1, а c реверсирует открывающее движение. Несколько персонажей — по одной залоченной строке одежды на каждого в g.

flowchart LR
    Z[Заморозка<br/>персонажей] --> Z2[Поза и Zero movement<br/>в каждой сцене]
    V[VFX] --> V2[Скоуп: on env<br/>NOT on chars]
    T[Титры и UI] --> T2[g: композит отдельно,<br/>p: empty comp space]
    L[Петля] --> L2[Последний кадр = первый,<br/>c реверсирует]

Почему формат устроен так. Выход потребляет парсер, а не человек, — отсюда JSON без обрамления. Однобуквенные ключи — потому что под потолком 3500 важен каждый байт. Камера отдельно от содержимого — потому что Seedance 2 обрабатывает семантику движения отдельно от кадра, и двойное описание путает обе половины. Список сцен в refs[].s — чтобы одна картинка держала одежду и локацию в нескольких сценах без дублирования.

Обновление, сентябрь 2026. Поле c описывает камеру словами. Для самых динамичных шотов в рекламных проектах 2025–2026 мы задавали её иначе. Окружения сначала собирались и утверждались в статике и только потом анимировались. Для пролётов движение собиралось в Blender: вырезанный живой план ставился на простую 3D-геометрию, и плейбласт задавал камеру и темп. По этому плейбласту Seedance генерировал финальный пролёт, достраивая свет и окружение. Текстовое поле c остаётся для простых движений, а сложную траекторию мы показывали модели черновым 3D, а не описывали.

Где ломается

  • Потолок 3500 символов быстро упирается в ролики длиннее восьми-десяти сцен. Слияние сцен спасает объём, но теряет монтажный ритм; иногда честнее разбить ролик на два промпта и склеить на монтаже.
  • Движение камеры регулярно просачивается в p, особенно когда сценарий описывает его прозой внутри действия. Это самая частая ошибка ревью, и ловится она только глазами.
  • Правило «референс на сцены» работает, пока референсы согласованы между собой. Два стилла с разной одеждой одного персонажа заставят модель выбирать, и лок в g не всегда побеждает картинку.
  • Расширения схемы (поле type, комментарии, вложенные объекты) не входят в контракт и молча ломают парсинг.

Итог

  • Один JSON на ролик: refs[], g, s[], потолок 3500 символов, ключи в одну букву.
  • Камера — в c, содержимое — в p, глобальные локи — в g; ничего не дублируется между полями.
  • Порядок сборки фиксирован: входы, сценарий, референсы, JSON, подсчёт символов, финальный проход.
  • Заморозка, скоуп VFX, композитные пустоты и петли прописываются явно, иначе модель решит сама.

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