Как генерировать видео через Gemini API и проверять результат по сценарию

Актуальная документация разделяет Gemini Omni Flash для основной мультимодальной генерации и conversational editing через Interactions API и Veo 3.1 для специальных возможностей вроде расширения сцены, контроля последнего кадра и legacy generateContent-процессов. Для анализа готового видео используется другой guide — Video Understanding.

Документация подтверждает механизм, но не создаёт архитектуру безопасности. Авторизацию, allowlist, хранение секретов, приёмочные критерии и откат реализует приложение. Текстовый запрет в промпте полезен как контракт, однако критичное ограничение проверяется обычным кодом непосредственно перед действием.

Что подготовить

Создайте отдельный тестовый проект и ключ с минимальными правами. Секрет держите только в переменной окружения или менеджере секретов. Не помещайте его в браузерный bundle, промпт, Git, URL, скриншот и диагностический вывод.

До вызова заведите таблицу: case_id, input, expected_action, expected_output, actual_action, actual_output, source, status, error_type. Ожидаемый результат записывается заранее. Возьмите минимум десять обезличенных примеров: обычный, пустой, неполный, противоречивый, вредоносный, тайм-аут и повтор.

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

Пошаговая настройка

1. Выберите модель по задаче, а не по узнаваемому названию. Для обычного multi-turn редактирования начните с рекомендованного в документации варианта; специальные функции Veo выбирайте только при необходимости.
2. Разбейте сценарий на проверяемые кадры: объект, действие, камера, свет, фон, звук и запреты. Не смешивайте пять событий в одной фразе.
3. Отправьте prompt по актуальному API выбранной модели. Если операция асинхронная, сохраняйте operation id и опрашивайте с задержкой, не создавая повторную генерацию.
4. Скачайте результат только после terminal success, проверьте контейнер, длительность, дорожки и возможность декодирования.
5. Просмотрите каждый ожидаемый кадр и отметьте бинарные критерии. Псевдотекст, лишний объект или сломанная геометрия — провал конкретного критерия.

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

Копируемый шаблон

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

Общие правила:
1. Используй только переданные источники и разрешённые инструменты.
2. Не угадывай отсутствующие значения.
3. Перед действием проверь путь, тип, идентификатор и права.
4. При конфликте верни status=needs_review и перечисли конфликтующие данные.
5. Не отправляй, не удаляй, не оплачивай и не раскрывай секрет без отдельного подтверждения.
6. Свяжи каждый изменяемый факт с источником, страницей, сегментом или tool result.

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

Реалистичный пример входа и результата

Ожидается один объект во всех кадрах, плавное движение камеры и отсутствие букв. Если на третьей секунде появляется вторая крышка или псевдологотип, версия отклоняется, даже если ролик выглядит эффектно.

Это заранее определённый expected, а не выдуманная статистика. Реальный output сохраните рядом и отметьте расхождения. Если финальный текст правильный, но агент выполнил лишний вызов, открыл чужой домен или изменил файл, тест провален.

Проверка по уровням

Первый уровень — транспорт: ответ получен, идентификатор сохранён, payload читается. HTTP 200 не доказывает смысл. Тайм-аут не равен гарантированному отказу: перед повтором проверьте состояние операции.

Второй — структура: обязательные поля есть, типы совпадают, JSON разбирается, Base64 декодируется, файл открывается, координаты находятся внутри изображения. Неизвестное поле либо отклоняется, либо сохраняется отдельно.

Третий — смысл: каждый факт подтверждается входом, страницей, временным сегментом или tool result. Числа пересчитываются кодом, идентификаторы сравниваются посимвольно. Отсутствующее значение остаётся null, а не превращается в правдоподобную догадку.

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