Майя Буто

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

Антон, да, часть наблюдений Codex привязал к конкретным сценам. В отчёте была раскадровка из семи смысловых сцен с таймкодами, ключевыми кадрами и объяснением того, за счёт чего достигается визуальный эффект.
Например, для сцены 0:17,6–0:29,0 он описал трансформацию глобуса в систему ячеек, а для 0:29,0–0:40,0 — последовательное появление карты, маршрута, машины и метрик.
Но общие наблюдения о композиции, визуальном языке, движении камеры и монтаже шли отдельными разделами. Единой структуры «сцена → наблюдение → проверяемый критерий → приоритет» не было.
Получается, исходные данные для такой проверки уже частично существовали, но между анализом и автоматической приёмкой не хватало отдельного этапа формализации критериев. Именно эту архитектурную разницу я и увидела благодаря нашему обсуждению.

Антон, подняла исходный отчёт Codex и посмотрела точнее.
Он разбил 74-секундный референс на 7 смысловых сцен с таймкодами, отдельно выделил 5 наблюдений по визуальному языку и 5 по движению и монтажу. Также разобрал звук, графические исходники и возможные способы реализации через HyperFrames.
Но это был аналитический разбор, а не единый список критериев приёмки. Отдельного ранжирования по важности и выделения блокирующих требований мы не делали.
Поэтому ваш подход как раз интересен: следующий шаг после анализа — превратить наблюдения в критерии, определить их приоритеты и использовать для автоматической проверки результата.

Интересно, что вы проверяете такие сценарии ещё до первого реального заказа. Обратный порядок событий — хороший пример того, почему одной защиты от дублей недостаточно: повторное событие можно распознать, но устаревшее обновление всё равно способно изменить актуальное состояние.
А семь испытаний перед запуском — это уже полноценная практика проверки интеграции. Было бы интересно узнать, какие ещё сценарии вы считаете обязательными перед выходом в production.

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

Антон, спасибо за подробное объяснение! Здесь как раз важна разница между повторной доставкой события и реальным изменением заказа с тем же внешним ID.
Особенно полезен момент с хэшем полезной нагрузки: он позволяет увидеть изменение содержимого, а проверка версии или времени обновления помогает определить, какие данные актуальны. И отдельно интересен случай, когда события приходят не по порядку: более старое обновление не должно перезаписать новое.
Спасибо, что поделились практической реализацией!

На старте был видео-референс и понимание того, какой визуальный результат мне нужен. Но отдельные, формально зафиксированные критерии приёмки короткой сцены я заранее не составляла — требования уточнялись уже после первых попыток. Это действительно ограничение моего эксперимента. Я могла оценить, насколько результат соответствует референсу и моим ожиданиям, но не проводила проверку по заранее установленному набору измеримых критериев.

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

Да, мы пробовали идти поэтапно. Сначала через ChatGPT и Remotion пытались сделать даже короткий, примерно 9-секундный фрагмент. Результат меня не устроил, переделывали, но нужного качества так и не получили.
Затем я перешла к Codex. Он подробно разобрал референс: композицию, движение объектов, переходы, последовательность сцен. После этого начали выстраивать визуальную концепцию поэтапно, получили несколько вариантов и последовательность из пяти концептуальных кадров. Но результат меня снова не устроил.
До анимации и отдельной приёмки каждой сцены в Codex мы уже не дошли. Я остановила эксперимент, потому что слишком много приходилось вмешиваться, объяснять, корректировать и направлять процесс.
Моя цель была не доказать, что с помощью AI вообще нельзя создать такой ролик. Конечно, при дальнейшем участии и доработках его можно было бы сделать. Я проверяла другое — насколько агент способен самостоятельно довести задачу до нужного результата. В моём эксперименте такой автономности я не увидела, поэтому решила больше не тратить на него время.

Спасибо, что поделились своим опытом! Особенно интересно, что Claude у вас уже самостоятельно генерирует клипы и анализирует результат.
При этом апскейл и публикация остаются за человеком. И это как раз то различие, которое я хотела показать в статье: автоматизировать отдельные этапы и довести весь процесс до готового результата без вмешательства — не одно и то же.
Показательно и то, что ограничение возникло не при генерации, а на этапе работы через браузер. В реальных AI-системах такие переходы между инструментами нередко оказываются не менее важными, чем возможности самой модели.