Workflow веб-дизайна с Codex

Зачем это изучать

Вы получите повторяемый процесс, в котором Codex исследует продукт, реализует интерфейс короткими срезами и подтверждает качество в настоящем браузере.

Проверено: 23 августа 2026 года.

Сильный результат появляется не из одного длинного промпта. Нужен code-first цикл с наблюдаемыми артефактами: brief, обоснованная арт-дирекция, работающий срез, browser-evidence и решение о приёмке.

Карта процесса

Контекст продукта
    ↓
Сценарий и критерии успеха
    ↓
Аудит существующего UI или 2–3 code-ready гипотезы
    ↓
Оценка по rubric и автономный выбор Codex
    ↓
Минимальный рабочий срез в браузере
    ↓
Одна заметка → одна правка → одна проверка
    ↓
Accessibility / responsive / performance / regression gates
    ↓
Review diff и публикация штатным способом

1. Собрать контекст до генерации

Для существующего проекта Codex сначала читает ближайший AGENTS.md, README, фактический стек, маршруты, компоненты, токены и тестовые команды. Затем открывает текущую страницу в браузере. Скриншот без кода не показывает поведение, а код без браузера не показывает итоговый рендер.

Минимальный пакет контекста:

• аудитория, задача и главный пользовательский путь;
• реальный контент или явно отмеченные заглушки;
• существующие brand-assets, дизайн-система и запрещённые решения;
• поддерживаемые устройства, браузеры, языки и режимы;
• технические ограничения, существующие зависимости и production-маршрут;
• критерий готовности и обязательные доказательства.

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

2. Разделить исследование и решение

Новый продукт или новый визуальный язык

Сначала Codex формирует несколько различимых code-ready направлений: например, редакционное, утилитарное и иммерсивное. Для каждого он кратко задаёт композицию, типографику, palette, плотность, принципы изображений и характер движения. Затем оценивает варианты по связи с продуктом, ясности, визуальной выразительности, доступности и реализуемости и самостоятельно выбирает сильнейший. Промежуточный макет в графическом редакторе не создаётся.

ImageGen применим только для bitmap-assets выбранного направления. Layout, компоненты, responsive и interaction проектируются сразу в коде.

Существующий продукт

Начните с аудита текущего UI. Попросите Codex перечислить используемые токены, компоненты, типовые отступы, breakpoint-поведение и уже существующие паттерны. Для локальной правки сохраняйте архитектуру, data flow и маршруты. Официальный сценарий OpenAI для UI-полировки рекомендует короткий цикл: одна конкретная визуальная заметка, минимальная правка и проверка в браузере.

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

3. Реализовать вертикальный срез

Первый срез должен содержать реальную композицию и поведение, а не каталог изолированных блоков:

1. один ключевой маршрут;
2. рабочее главное действие;
3. реальный или репрезентативный контент;
4. loading, empty, error, success и disabled-состояния;
5. мобильное и широкое представление;
6. клавиатурный путь и видимый focus.

Сначала используйте нативные HTML-элементы, существующие компоненты и CSS возможности платформы. Новую UI-библиотеку, motion framework или icon pack добавляйте только после проверки текущих зависимостей и lock-файла.

4. Вести короткий цикл browser-first

После каждого заметного изменения Codex должен:

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

Формат замечания:

Экран: /checkout, 390 × 844, состояние validation error.
Наблюдение: сообщение ошибки сдвигает CTA ниже sticky-панели.
Риск: пользователь не видит способ продолжить.
Ожидается: CTA остаётся доступным, focus переходит к summary ошибки.
Граница: не менять API формы и desktop-композицию.

Одна заметка — одна сфокусированная правка. После подтверждения переходите к следующей; большой набор несвязанных пожеланий ухудшает причинность review.

5. Зафиксировать доказательства

Финальный отчёт Codex должен разделять факты и оценки:

Что сообщить	Пример доказательства
Поведение	пройденный E2E-сценарий и команда запуска
Рендер	скриншоты заданных viewport и состояний
Доступность	axe-результат плюс ручной keyboard/focus-проход
Производительность	лабораторный отчёт и, если есть, полевые метрики
Регрессии	visual diff либо просмотр затронутых страниц
Код	тесты, lint, typecheck, сборка и итоговый diff

«Выглядит хорошо» не является доказательством. Автоматический зелёный отчёт также не заменяет визуальный и пользовательский review.

6. Превратить повторение в систему

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

• проектное решение — токен или компонент;
• допустимые варианты — story и документация компонента;
• пользовательский путь — browser/E2E-тест;
• визуальная стабильность — baseline screenshot;
• обязательное ограничение — lint, test, CI gate или локальная инструкция.

Подробные форматы запроса находятся в постановке задачи, а полный набор гейтов — в проверке реализации.