Как ставить Codex задачи по веб-дизайну
Зачем это изучать
Вы научитесь передавать Codex продуктовый смысл и визуальные ограничения без микроменеджмента, а затем получать результат, который можно объективно принять.
Проверено: 23 августа 2026 года.
Лучший запрос описывает не последовательность кликов Codex, а контракт результата: для кого интерфейс, что человек должен сделать, какие границы нельзя нарушить и какими доказательствами подтвердить готовность.
Семь частей сильного запроса
| Часть | Что указать |
|---|---|
| Результат | страница, поток или компонент и его роль в продукте |
| Пользователь | аудитория, контекст, частота работы и ограничения |
| Сценарий | вход, ключевые шаги, успешный исход и ошибки |
| Визуальный язык | бренд, референсы, дизайн-система, желаемое впечатление |
| Контент | реальные данные, тон, локализация, допустимые заглушки |
| Границы | стек, файлы, зависимости, API, совместимость и запреты |
| Готовность | viewport, состояния, тесты, browser-check и отчёт |
Не перечисляйте десятки абстрактных эпитетов: «современный, премиальный, чистый, wow». Покажите, как они проявляются. Например: «редакционная типографика, спокойная палитра, крупные предметные фотографии, минимум контейнеров и отсутствие декоративных градиентов».
Иерархия референсов
Codex должен применять источники в заданном порядке:
- существующие компоненты, tokens и brand-assets проекта;
- продуктовый brief, реальные данные и пользовательский сценарий;
- проверенные ограничения домена и результаты исследований, если они есть;
- внешние сайты только как указание отдельного принципа, не как макет;
- собственная code-first арт-дирекция Codex в незаданных деталях.
Укажите, что именно брать из каждого референса: плотность, ритм, навигацию, композицию, типографику или характер движения. Просьба «сделай как сайт X» не определяет границы заимствования и создаёт риск копирования.
Промпт для нового сайта
Создай рабочий [тип сайта] для [аудитория]. Главный сценарий: [сценарий].
Успех: [наблюдаемый результат пользователя/бизнеса].
Сначала изучи AGENTS.md, README, стек и существующие UI-ресурсы. Сформулируй
краткий brief и 2–3 действительно разных code-ready визуальных направления.
Для каждого объясни иерархию, типографику, палитру, изображения и движение.
Оцени варианты по связи с продуктом, ясности, выразительности, доступности и
реализуемости; самостоятельно выбери сильнейший и кратко зафиксируй причину.
Сразу в коде реализуй один вертикальный срез с реальным контентом и состояниями
loading/empty/error/success/disabled. Используй существующие компоненты и токены.
Не добавляй зависимости без необходимости.
Не создавай промежуточный макет в Canva, Figma, Photoshop или аналоге. Layout,
design tokens, компоненты, responsive и interaction проектируй в коде.
Поддержи [viewport/браузеры/языки], WCAG 2.2 AA и reduced motion.
Открой результат в браузере, проверь ключевой сценарий, клавиатуру, responsive,
overflow и производительность. Исправь найденное. В финале перечисли изменённые
файлы, выполненные проверки и всё непроверенное.Промпт для существующего интерфейса
Измени [маршрут/компонент/состояние]: [точное наблюдение и ожидаемый результат].
Контекст просмотра: [viewport, тема, локаль, данные].
Сохрани поведение, data flow, маршруты и публичный API. Переиспользуй текущие
компоненты, токены, иконки и layout primitives. Сделай минимальный обоснованный
patch только в нужных файлах.
До изменения открой текущий UI в браузере. После изменения снова проверь тот же
экран и соседние состояния. Остановись после этой одной правки и сообщи, что
изменено и какой browser-check выполнен.Промпт для review
Проведи read-only review [URL/маршрут] по сценарию [сценарий].
Проверь визуальную иерархию, содержание, responsive, клавиатуру, focus,
семантику, состояния, motion и performance.
Для каждого замечания укажи: экран и состояние, наблюдение, пользовательский
риск, доказательство, серьёзность и минимальную рекомендацию. Не исправляй код.
Отдели измеримый дефект от вкусового предложения.Что Codex не должен угадывать
- логотип, права на изображения и лицензию шрифта;
- цену, характеристики, социальное доказательство и юридические обещания;
- целевую аудиторию, если от неё меняется архитектура интерфейса;
- допустимый уровень изменения API, данных или analytics;
- факт прохождения WCAG, usability или performance без проверки.
Если неизвестность влияет только на заменяемую деталь, Codex может сделать явное допущение и продолжить. Если она меняет продукт, бренд, данные или совместимость, нужен узкий вопрос человеку.
Антипаттерны сгенерированного UI
Проверяйте, что интерфейс не скатился в узнаваемые defaults без связи с задачей:
- огромный generic hero вместо рабочего первого экрана;
- вложенные карточки вокруг каждого фрагмента;
- декоративный gradient, glow и стекло без роли в бренде;
- одинаково скруглённые «пилюли» для разных типов управления;
- объяснение интерфейса видимым служебным текстом вместо понятных controls;
- иконки из разных наборов и вручную нарисованные SVG при наличии системы;
- только happy path без loading, empty, error и disabled;
- desktop-макет, сжатый до mobile без перепроектирования приоритетов.
Официальные frontend-инструкции OpenAI предлагают привязывать композицию к домену продукта, сохранять существующую систему, использовать привычные controls и проверять отрендеренный результат. Это хороший baseline, но решения всё равно должны проходить стандарт качества.