ИИ-режиссура и качество

От источника до сцены: почему сгенерированной новелле нужен режиссёр

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

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

Поэтому генерацию пришлось превратить в производственный конвейер с отдельными ролями: текстовый аналитик, художник, компоновщик, MCP-агент, технический валидатор и ИИ-режиссёр. Главный результат этого конвейера — не изображение. Это проверяемая связь между источником, сценой, ассетами и тем, что игрок действительно видит в Player.

![Схема конвейера Romergo: источник, структура истории, библии непрерывности, ассеты, сборка через MCP и режиссёрская проверка с возвратом на перекомпоновку или перегенерацию](direction-flow)

1. Сначала фиксируем источник, а не начинаем рисовать

На входе может быть обычный текст, HTML, Markdown или текстовый PDF. Сначала агент определяет язык, издание, порядок глав и доступный текстовый слой. Отдельно подтверждаются права на оригинал, конкретный перевод и вложенные изображения: возраст произведения сам по себе не означает, что любой перевод можно публиковать.

Инструменты romergo_inspect_story_source и romergo_plan_story_source помогают построить инвентарь и предварительный план без записи проекта. На этом этапе важно не «улучшать» произведение и не придумывать развилки. Если источник линейный, будущий граф тоже должен оставаться линейным.

2. Текст делится на непрерывные сцены

Граница сцены определяется не размером абзаца, а изменением места, времени, состава участников или действия. Для каждого фрагмента сохраняется точный sourceExcerpt и составляется визуальный контракт:

где и когда происходит действие;
кто физически присутствует, кто говорит и кто слушает;
что персонажи делают, куда смотрят и на что опираются;
какие детали обязаны попасть в кадр;
какие лица должны пережить мобильное кадрирование;
какие признаки связывают сцену с соседними кадрами.

Это уже похоже на режиссёрскую экспликацию. Фраза «сидели к окну спиной» превращается в проверяемое требование к ориентации тел, а не остаётся литературным украшением, которое генератор может проигнорировать.

3. Отдельный аудитор извлекает предметы и их состояния

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

Для каждого предмета появляется запись в реестре непрерывности: каноническое описание, неизменные признаки, владелец, состояние, видимость, число экземпляров и цепочка событий. Например, «тонкое золотое кольцо» до передачи находится у Грея ровно на одной руке и одном пальце; в момент действия оно видно между его пальцами и мизинцем Ассоль; после действия у Грея его больше нет, а у Ассоль оно остаётся на мизинце.

Такая запись важнее общего промпта «сохраняй непрерывность». Она делает деталь адресуемой: проверка знает не только, что кольцо существует, но и где именно оно должно быть на каждом отрезке истории.

4. Временные документы образуют граф производства

Для длинной главы одного промпта недостаточно. Конвейер создаёт набор временных документов, которые ссылаются друг на друга стабильными ID и хешами исходного текста:

карта сцен хранит границы текста и визуальные контракты;
библия персонажей фиксирует лицо, возраст, рост, одежду и характерные позы;
библия локаций хранит геометрию места, свет и постоянные ориентиры;
реестр реквизита описывает предметы, владельцев и изменения состояния;
манифест ассетов связывает сцены с фонами, позами и портретами;
задания генерации повторяют обязательные признаки нужного контракта;
отчёты аудита привязаны к точному рендеру по SHA-256.

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

5. У сцены есть два основных режима изображения

Не всякую сцену надо собирать одинаково.

baked_narrative используется для повествовательных кадров без прямой речи. Персонажи сразу встроены в фон, поэтому свет, контакт с землёй, сидение, лежание и взаимодействие с предметами выглядят естественнее. Вместо одного универсального фона можно создать несколько последовательных иллюстраций.

layered_dialogue нужен для разговора. Фон остаётся стабильным, а говорящие и слушающие позы персонажей существуют как отдельные спрайты. Это позволяет менять реакцию вместе с репликой и сохранять диалоговый интерфейс с правильным именем и портретом.

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

6. Генерация идёт от конкретной сцены

Сначала создаются мастер-референсы персонажей и визуальный стиль мира. Затем сцены обрабатываются по одной. Промпт фона строится из точного отрывка, локационной библии и текущего состояния реквизита. После этого выбирается готовая поза или создаётся новая speaking, listening или action-поза.

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

7. MCP собирает обычный редактируемый проект

После утверждения ассеты импортируются в черновик, а MCP-инструменты создают главы, сцены, текст, граф переходов, таймлайн, музыку и размещение персонажей. Это не одноразовый экспорт картинки: результат остаётся нормальным проектом Romergo, который можно открыть и изменить в Builder.

Каждая запись подтверждается чтением сохранённого состояния. Агент использует romergo_get_chapter, запускает romergo_validate_project и завершает изменение через romergo_verify_quest_change. Проверяются не только ответы инструмента, но и фактически сохранённые связи, медиа и runtime-представление.

8. ИИ-режиссёр смотрит текст и готовый кадр вместе

Финальная проверка проходит не по исходным PNG, а по Player. Глава полностью проигрывается на desktop и в мобильном viewport 390 × 844. На каждом входе в сцену сохраняются кадры на 0, 100 и 500 мс, чтобы переход не мог спрятать чёрный экран, белый фон или на мгновение появившийся старый спрайт.

Для каждого кадра режиссёр получает точный текст, визуальный контракт, сведения о соседней сцене и само изображение. Он проверяет:

соответствует ли место, время, действие и состав персонажей источнику;
стоят, сидят и лежат ли люди на реальной опоре;
соразмерны ли взрослые одного плана и не перекрывают ли смысловые объекты;
логичны ли поза, направление взгляда и взаимодействие;
сохраняются ли локация, одежда и реквизит между сценами;
видны ли нужные лица после мобильного кадрирования;
совпадают ли имя, лицо и персонаж в диалоговой карточке;
не начинается ли заново тот же музыкальный трек.

Важно, что ответ проверки не ограничивается «плохо». Она выбирает действие. Если фон правильный, а спрайт висит в воздухе, нужна другая компоновка через MCP: позиция, масштаб, слой или кадрирование. Если неправильная поза уже нарисована внутри фона, нужна новая генерация. После исправления кадр создаётся и проверяется заново.

Три ошибки, из-за которых появились новые правила

Ошибка 1. Герой буквально сел на героиню

На широком экране композиция могла выглядеть терпимо, но мобильное кадрирование совместило слои: колено Грея оказалось поверх тела спящей Ассоль. Обычная проверка «оба персонажа видны» это пропустила. Режиссёрская проверка должна оценивать опору, глубину и пересечение тел в каждом viewport. Для слоистой сцены это recompose; для уже объединённого изображения — regenerate.

![Мобильный кадр, в котором слой Грея после кадрирования оказался поверх спящей Ассоль](direction-failure-overlap)

Ошибка 2. Одно кольцо превратилось в несколько и меняло руку

Само наличие золотого предмета оказалось слишком слабым условием. В разных изображениях кольцо появлялось на другой руке, другом пальце, а иногда художник рисовал сразу несколько колец. Теперь контракт требует ровно один экземпляр, конкретную анатомическую сторону и палец, а также состояние до, во время и после передачи.

![Девять вырезок с неудачным положением кольца: оно оказывается рядом с пальцем, висит в воздухе или попадает не на тот палец](direction-failure-ring)

Ошибка 3. Персонажи смотрели в окно, хотя текст говорил обратное

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

![Сцена в трактире, где сидящие персонажи обращены к окну вопреки прямому указанию источника](direction-failure-window)

Почему прежние проверки это пропускали

Первые версии проверяли локальные свойства: файл существует, альфа-канал есть, персонаж помещается в кадр, все сцены связаны. Каждая проверка отвечала на свой узкий вопрос, но никто не сопоставлял исходный глагол, итоговую позу, мобильный crop и состояние предмета в едином проходе.

Устойчивость появилась только после четырёх изменений: требования стали извлекаться из точного текста; финальный Player стал контролирующей поверхностью; проверка начала видеть соседние сцены и историю предметов; а любой вердикт стал обязан выбирать конкретный ремонт и затем проверять его повторно независимым прогоном.

Результат — не пачка картинок, а воспроизводимая постановка

Но всё это по-прежнему далеко от полностью автоматической генерации. Человеческая насмотренность, опыт и чувства остаются главным критерием успешности. Думаю, ещё нескоро я смогу уверенно сказать, что генерация стала полностью автономной.

Уже сейчас этот конвейер сохраняет мне много часов — и, надеюсь, сможет сохранять их другим авторам. Оставляйте время для творчества, а сложную техническую работу доверяйте скриптам и ИИ.

Так текстовый файл, HTML или PDF проходит путь от анализа до работающей новеллы: источник задаёт факты, контракты превращают их в проверяемые требования, генерация создаёт нужные представления, MCP собирает редактируемый проект, а режиссёрский проход сравнивает готовую игру с текстом. Только после этого отдельные красивые изображения начинают работать как одна история.

Назад в dev-блог