Как честно сравнить Claude Code и Codex на одном задании по моушн-дизайну
Два привлекательных видео ещё не дают честного сравнения двух агентов для программирования. Один мог получить более качественные материалы, подробный запрос, дополнительный раунд исправлений или доступ к инструментам, которых не было у другого. Сопоставление скриншотов скрывает эти различия.
В моушн-дизайне особенно легко ошибиться таким образом. Модель способна создать эффектный первый кадр и при этом нарушить требования к таймингу. Другая может выдать скромный, но редактируемый проект, который выдержит локальную правку. Что лучше, зависит от работы, которую вы собирались делегировать.
Сравнивая Claude Code и Codex в моушн-графике, начните с одинаковой приёмочной задачи и материалов, затем проверьте точность текста, тайминг, элементы управления и усилия, необходимые для получения пригодного результата. В этом разборе мы проследим за результатом Codex: воспроизведением, сбоем перемотки и его исправлением. Claude Code не удалось авторизовать для парного запуска; сравнение самих моделей остаётся открытым.
Выберите задачу, которая выявит нужную вам способность
«Сделай красивое продуктовое видео» оставляет слишком большой простор для трактовок. Хороший тест содержит реальную коммуникационную задачу и ограниченный технический результат. Например: создать редактируемую шестисекундную сцену с предложением, точным текстом цены, детерминированной перемоткой и общим интервалом для чтения.
Сцена может быть визуально простой и всё же проверять важное поведение. Точный текст проверяет сохранение фактов. Неподвижная выдержка — понимание времени. Перемотка показывает, управляется ли анимация временем или последовательностью, которая работает только при запуске с начала. Локальная правка проверяет, остаётся ли исходник управляемым.
Не перегружайте первый тест всеми возможными функциями. Если включить дикторский текст, музыку, субтитры, данные графиков, несколько форматов кадра и сложный интерфейс, причины сбоев будет трудно определить. Сначала используйте небольшую репрезентативную задачу, затем добавьте вторую для возможностей, которые первая не раскрывает.
Решите, сравниваете ли вы генерацию кода или полный рабочий процесс агентов. В тесте только на код можно уравнять инструменты, отключив их и запросив автономный документ. В тесте рабочего процесса каждому агенту следует разрешить изучать материалы, запускать проект и исправлять ошибки при сопоставимых правах. Это разные эксперименты; объединять их в один рейтинг не следует.
Для команды, выбирающей инструмент, тест рабочего процесса часто полезнее. Ценный результат — не просто исходный код, а корректный, редактируемый материал, полученный практически применимым способом. Но небольшой тест только на код помогает обнаружить требования и проблемы окружения до затрат на масштабное сравнение.
Зафиксируйте задание и материалы
Используйте для обоих запусков дословно одинаковое задание. Сохраните его до обращения к любому агенту. Если неоднозначность обнаружится после первого результата, уточните задание для обоих и считайте новую пару отдельным тестом, а не давайте пояснение лишь одному агенту.
Для локальной пробы из этой статьи требовался автономный HTML-документ размером 1280 на 720. Вымышленная сцена называлась Still Studio и должна была показывать точные формулировки «US$29 per month» и «US$348 billed annually». Обе строки должны были появиться между нулём и 0,8 секунды, оставаться неподвижными до 4,8 секунды и исчезнуть к шестой секунде.
Также требовались видимые элементы Play/Pause и перемотки, начальное состояние на паузе на отметке 2,4 секунды, системный шрифт без засечек, отсутствие удалённых ресурсов и обозначение вымышленного этюда. Эти ограничения позволяли проверять результат и исключали различия из-за внешних изображений или шрифтов.
Текст и соотношение платежей имеют значение. Модель, изменившая годовую сумму, нарушает фактическое требование, даже если её типографика привлекательнее. Модель, которая показывает условие только в конце, нарушает требование ко времени, даже если нужные слова присутствуют в исходнике.
Если вы используете реальные материалы продукта, предоставьте одинаковые копии и сохраните их идентичность. Не позволяйте одному агенту использовать более свежий скриншот или другой логотип. Если материал нельзя распространять, опишите условия доступа и проводите сравнение в разрешённом окружении.
Запишите параметры реально использованного окружения
Название инструмента не определяет всю систему. Запишите версию CLI, модель, указанную в запуске, значимые настройки, доступные инструменты, разрешения и тип сессии: новая или продолженная. Модель по умолчанию может меняться, поэтому сведения из запуска важнее предположений по названию продукта.
Отделяйте доступ к аккаунту от качества модели. Неудачный вход, ограничение запросов или разрыв сети влияют на практический процесс, но ничего не говорят о качестве видео, которое модель так и не создала. Сохраните эти сбои в протоколе, не превращая их в оценку творческих способностей.
Codex использовал авторизацию ChatGPT через провайдера OpenAI. В журнале указаны CLI версии 0.163.0 и модель gpt-6.1-sol; результат представляет собой самостоятельный HTML-документ.
Авторизация и конфигурация требуют отдельного внимания, поскольку могут выбирать разные способы доступа. Обращайтесь к документации самого инструмента и сохраняйте сведения о фактически использованном пути; не включайте токены и личные файлы аккаунта в пакет теста. Документация по авторизации Claude Code
Сохраните исходные результаты до исправлений
Сохраните первый ответ в точности как получили, вместе с заданием и статусом запуска. Если для открытия HTML-документа требуется убрать ограждения блока Markdown, зафиксируйте это преобразование. Не исправляйте синтаксис незаметно, выдавая исправленный результат за первоначальный черновик.
Храните неудачные запросы отдельно от готовых материалов, чтобы протокол различал проблемы настройки и дефекты результата.
При сравнении только кода откройте полученный документ без правок. Проверьте наличие обязательных слов, загрузку без удалённых зависимостей и наличие элементов управления. Затем проиграйте всю последовательность и перейдите напрямую к появлению, выдержке и исчезновению.
В исходнике также есть ползунок и функция отрисовки, зависящая от времени. Последующая проверка поведения показала: элементы управления присутствуют, но работают не полностью. При обычном воспроизведении время продвигалось от начального состояния дальше 3,1 секунды, доходило до шести секунд и останавливалось. Перемотка выявила отдельный дефект: отображаемое время оставалось прежним, вместо того чтобы перейти к запрошенному.
Оценивайте смысл прежде стиля
Начните с обязательных требований. Все ли точные факты присутствуют? Правильно ли они связаны? Может ли зритель прочитать полное утверждение в установленном интервале? Использованы ли предоставленные материалы без выдуманного поведения интерфейса?
Затем проверьте поведение во времени. Перейдите напрямую к середине, началу, границе появления, границе исчезновения и концу. Детерминированная анимация должна давать ожидаемое состояние независимо от пути к этой отметке. Если состояние зависит от проигрывания предыдущих кадров, исходник может оказаться непригодным для надёжного покадрового рендеринга.
Только после этого сравнивайте визуальное качество. Оцените иерархию, интервалы, типографику, согласованность движения и то, насколько композиция помогает сообщению. Привязывайте оценку к заданию. Намеренно сдержанная сцена с предложением не должна проигрывать лишь потому, что другая версия добавляет больше зрелищности.
Используйте небольшую систему критериев с раздельными оценками вместо одной непонятной суммы. Фактическая точность, тайминг, редактируемость, визуальная коммуникация и надёжность передачи могут давать разные результаты. Единый балл скрывает компромисс, который команде действительно нужно понять.
Что на самом деле показала дополнительная проверка
Сбой перемотки воспроизводился после достижения шести секунд. Клавиша Home не возвращала результат к нулю. Отправка событий ввода для 0,8, 4,8 и 5,4 секунды также оставляла результат на шестой секунде. Это важно: редактор должен иметь возможность осмотреть конкретное состояние без повторного проигрывания всей последовательности. Видимой шкалы времени недостаточно.
Причина заключалась в порядке событий. Обработчик ввода вызывал pause() до чтения запрошенного значения ползунка. В этой реализации постановка на паузу также записывала в элемент управления прежнее состояние. Последующее чтение поэтому возвращало старое значение. Математика анимации могла быть верной, а средство её проверки — сломанным.
Автор исправил отдельную копию: сначала прочитал запрошенное значение, затем поставил воспроизведение на паузу и после этого применил значение. Оригинальный результат модели сохранён.
// Preserve the requested value before pause() renders the old state.
const requestedTime = Number(seek.value);
pause();
state.time = Math.max(0, Math.min(motion.duration, requestedTime));
render();
Исправленная копия реагировала на Home и End переходом к нулю и шести секундам. На отметках 0,8 и 4,8 секунды обе строки цены были полностью непрозрачными и без смещения. На 5,4 секунды у обеих была непрозрачность 0,5 и смещение вверх на 18 пикселей.
После прямого редактирования строк contenteditable на US$39 per month и US$468 billed annually обе оставались видимыми на 2,4 секунды. Следующий шаг приёмочного теста — сохранить изменения, перезагрузить документ и отрендерить их.
Проверка отображаемого времени быстрее всего позволяет отличить сбой воспроизведения от сбоя перемотки. Здесь оригинал нормально продвигается при проигрывании, а затем отклоняет запрос конкретного состояния. Исправление меняет порядок в обработчике событий, сохраняя кривые появления и исчезновения. В парном тесте агентов это становится точной задачей: исправить перемотку, сохранить шестисекундную длительность и обе строки цены, затем проверить Home, End и одну промежуточную отметку.
Внесите одинаковую локальную правку
Первый черновик — лишь половина задачи. Дайте обоим успешным запускам одинаковое изменение: например, поменять месячный эквивалент и годовой платёж, сохранить композицию и тайминг и оставить оба утверждения видимыми одновременно. Так вы проверите, может ли агент изменить ограниченную часть без лишнего переписывания остального.
Сохраните оригинальный исходник и сравните с ним новую версию. Проверьте изменения текста, геометрии, тайминга, управления и ссылок на ресурсы. Внешне похожий результат может скрывать сломанную перемотку или сдвинувшийся финал. Большой объём изменений исходника тоже допустим, если поведение корректно, но заслуживает проверки.
Заранее определите допустимый объём исправлений. Если один агент получает три всё более конкретных запроса, а другой — один, сообщите об этом различии, не представляя финальную пару как равноценные первые попытки. Помощь входит в стоимость получения пригодного результата.
В полном тесте рабочего процесса разрешите агентам запускать и проверять собственные результаты при сопоставимых правах. Записывайте реально использованные инструменты и необходимое вмешательство человека. Агент, который замечает и исправляет ошибку загрузки, выполняет полезную работу, незаметную при сравнении скриншотов.
Измеряйте затраты без выдуманной точности
Прошедшее время легко измерить и легко неверно истолковать. Запрос Codex здесь занял около 179 секунд, включая запуск и тайм-ауты обнаружения модели, отмеченные в журнале. Это не чистое измерение скорости генерации. Утверждение «Codex делает анимацию за три минуты» преувеличило бы объём измеренного.
Для более полезного сравнения по возможности разделяйте время настройки, запроса, исправлений, рендеринга и человеческой проверки. Полное время до пригодного результата может значить больше, чем задержка ответа. Быстрый черновик, требующий нескольких тщательных исправлений, иногда обходится дороже по усилиям, чем более медленный, но правильный.
Не выводите денежную стоимость из прошедшего времени или числа токенов без реальных условий оплаты. Использование подписки, тарификация API, кэшированный ввод и настройки модели могут различаться. Если достоверную стоимость получить нельзя, сообщите наблюдаемые сведения об использовании, оставив стоимость неизмеренной.
Включайте сбои в описание процесса, но классифицируйте их. Настройка авторизации отличается от выдачи моделью невалидного кода. Сбой зависимости рендеринга отличается от нечитаемого дизайна. Это различие делает сравнение полезным и для выбора инструмента, и для выбора рабочего процесса вокруг него.
Повторите репрезентативные задачи до широких выводов. Одна небольшая сцена выявляет тип сбоя, но не доказывает общее превосходство агента в продуктовых запусках, технических объяснениях, графиках, локализации и любой будущей работе с анимацией.
Сделайте помощь человека видимой
Честное сравнение должно учитывать действия оператора между запросами. Установка недостающего пакета, поиск материала, исправление имени файла или объяснение ошибки способны существенно улучшить результат. Если помощь невидима, сравнение приписывает человеческий вклад агенту.
Определите, какая помощь входит в тест. В реалистичном процессе оператор вполне может ответить на вопрос о продукте или одобрить доступ к файлу. В контролируемой пробе генерации кода любое ручное исправление исходника меняет оцениваемый материал. Ни один подход сам по себе не ошибочен; проблема — выдавать один за другой.
Сохраните краткий журнал вмешательств. В нём можно указать, что оператор предоставил обеим системам один скриншот, уточнил для обеих формулировку оплаты или починил локальный сервер до открытия результатов. Если исправление понадобилось только одной системе, запишите и это. Дополнительная работа может влиять на решение команды, даже если финальные изображения одинаково хороши.
В повторных запусках отделяйте обучение оператора от качества агента. После первой системы оператор может лучше понять задачу и дать второй более полезные указания. Чередование порядка запусков или фиксация всех входных данных до начала помогает уменьшить такое преимущество. Небольшое локальное исследование не устраняет все источники вариации, но способно сделать их видимыми.
Для моушн-дизайна такая прозрачность особенно ценна: визуальный лоск подталкивает к быстрой оценке. Результат, потребовавший тщательной ручной настройки тайминга, нельзя описывать как нетронутую генерацию с одной попытки. Читатели смогут оценить его, понимая, как он получен.
Опубликуйте результат, который можно проверить
Убедительное сравнение включает задание, набор материалов или инструкции по их получению, описание окружения, исходные результаты, запросы на правки, настройки рендеринга и наблюдения проверок. Читатель должен понимать основание вывода, не полагаясь на привлекательное сравнительное изображение.
Формулируйте результат на уровне требований: точный текст присутствовал в начальном состоянии, воспроизведение дошло до конца, а перемотка до исправления не работала. В последующем парном запуске то же задание и проверки позволят сравнить, как агенты диагностируют и изменяют материал.
Изучите оригинальный результат, независимое исправление и записи проверок поведения.