Инструкция по созданию адаптивного фронтенда по скриншотам с помощью Codex

Преобразуйте скриншоты и визуальные референсы в адаптивный интерфейс с визуальной проверкой результата.

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

Когда это особенно полезно

Какие инструменты использовать

Playwright

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

Базовый промпт для Codex

Промт доступен в карточке - https://promt-hub.ru/prompts/sozdanie-adaptivnogo-frontenda-po-skrinshotam-s-pomoschyu-codex

Введение

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

Если подключён Playwright, Codex может открыть приложение в реальном браузере, сравнить реализацию с вашими скриншотами на разных размерах экрана и затем скорректировать вёрстку или поведение элементов, чтобы результат стал ближе к целевому.

Начинайте с референсов

Давайте Codex максимально понятные визуальные ориентиры.

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

Референсы не обязаны быть идеальными дизайн-макетами. Главное, чтобы они достаточно чётко показывали структуру, отступы, визуальную иерархию и общий стиль, иначе Codex начнёт додумывать сам. А это почти всегда ухудшает результат.

Формулируйте задачу конкретно

Чем точнее вы описываете ожидаемое поведение интерфейса и его стиль, тем лучше итог.

Если вы не зададите явное направление, модель обычно скатится в типовой шаблонный UI. Поэтому, если вам нужен не банальный интерфейс, а что-то ближе к вашему визуальному почерку, надо явно указать:

Чем больше конкретных входных данных вы даёте, тем меньше вероятность получить безликий и усреднённый результат.

Подготовьте дизайн-систему проекта

Codex работает заметно лучше, когда в проекте уже есть понятный слой компонентов.

Если в репозитории есть устоявшаяся дизайн-система, Codex обычно способен использовать её автоматически, а не строить всё с нуля. Но если стек нестандартный или структура проекта неочевидна, лучше явно указать:

Если проект уже зрелый, Codex часто сам понимает, как встроиться. Если проект новый или сырый, лучше не надеяться на догадки и прописать это напрямую.

Просите не копировать картинку буквально, а переводить её в систему проекта

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

Правильный подход такой: Codex должен взять визуальное направление со скриншота и перевести его в реальные сущности проекта:

Это важный момент. Иначе вместо интеграции в текущий продукт вы получите отдельный инородный кусок интерфейса. Эта мысль прямо проговаривается и в PDF на 4 странице.

Используйте Playwright для визуальной проверки

Playwright нужен не только для тестов. В этой задаче он полезен как инструмент визуальной итерации.

С его помощью Codex может:

Нужно, чтобы в Codex был включён интерактивный режим Playwright. Без этого модель будет опираться в основном на код и предположения, а не на реальную визуальную проверку.

Итерации обязательны

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

Важно просить Codex сравнивать результат именно со скриншотами, а не просто проверять, что страница собирается без ошибок.

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

Если на одном скриншоте что-то неясно, дайте дополнительные изображения или короткие пояснения. Это резко уменьшает число неудачных догадок.

Адаптированный follow-up промпт для доработки

[текущее изображение реализации] [эталонное изображение]

Это выглядит неточно. Доработай реализацию так, чтобы она максимально близко соответствовала референсу.

Дополнительно:

Если нужно, уточнение различий: [здесь перечислить, что именно отличается]