23 июл. 2025 г.·8 мин
Как ИИ читает макет и намерения, чтобы превращать дизайн в UI‑код
Узнайте, как ИИ выводит макет, иерархию и намерения из дизайна, затем генерирует UI‑код — а также об ограничениях, лучших практиках и советах по ревью.
Узнайте, как ИИ выводит макет, иерархию и намерения из дизайна, затем генерирует UI‑код — а также об ограничениях, лучших практиках и советах по ревью.
«Design to code» ИИ переводит визуальную идею интерфейса — обычно фрейм Figma или скриншот — в исполняемый UI‑код. Цель не в «идеальном коде», а в рабочем первом черновике, который передаёт структуру, стили и базовое поведение, чтобы человек мог доработать его.
В основе система сопоставляет то, что видно, с тем, как обычно строят UI.
ИИ может угадывать распространённые шаблоны: ряд иконок вероятно — тулбар; метка + поле — строка формы; согласованный стиль намекает на компонент. Он также может предположить адаптивность на основе ограничений и отступов.
Но обычно вам нужно явно указывать то, что пиксели не гарантируют: реальные имена компонентов, токены дизайна (цвета/шрифты), состояния (hover/disabled/error), точки перелома и реальные взаимодействия (валидация, цели навигации, аналитика).
Рассматривайте вывод как отправную точку. Ожидайте проверить структуру, заменить ad‑hoc‑стили на токены, согласовать с вашей библиотекой компонентов и итеративно доработать. «Design to code» — ускорение, а не автоматизация, снимающая необходимость дизайнерского и инженерного суждения.
ИИ не может вывести правила продукта из «красивого экрана». Он работает с доказательствами, которые вы даёте: одни входы описывают пиксели, другие — структуру. Эта разница часто определяет, получите ли вы чистый UI‑код или хрупкое абсолютное позиционирование.
Скриншот — самый тонкий ввод: он содержит цвета и формы, но не факты о том, что кнопка отличается от метки, что повторяется и что должно адаптироваться.
По пикселям ИИ должен угадывать границы элементов, текстовые стили, правила отступов и даже то, является ли «карточка» одним компонентом или набором частей. Он также не может вывести ограничения, поэтому адаптивное поведение — в основном догадка.
Когда ИИ может получить доступ к файлу дизайна (или экспорту, сохраняющему структуру), он получает важные метаданные: фреймы, группы, имена слоёв, настройки Auto Layout, ограничения и определения текстов/стилей.
Именно тогда макет становится не только геометрией. Например, фрейм Figma с Auto Layout чётко передаёт намерение: «расположить эти элементы вертикально с gap 16px» — гораздо понятнее, чем скриншот. Последовательные имена слоёв помогают сопоставить элементы с ролями в UI (например, “Button/Primary”, “Nav Item”, “Input/Error”).
Подключённая система дизайна уменьшает количество догадок. Токены (цвета, отступы, типография) позволяют ИИ генерировать код, ссылающийся на общий источник истины, а не на захардкоженные значения. Опубликованные компоненты предоставляют готовые блоки и чётче разграничивают области для повторного использования.
Даже небольшие соглашения — например, именование вариантов (Button/Primary, Button/Secondary) и семантические токены (text/primary вместо #111111) — улучшают маппинг компонентов.
Спеки добавляют «почему» интерфейса: поведение при hover, состояния загрузки и пустоты, правила валидации, клавиатурного поведения и сообщения об ошибках.
Без этого ИИ склонен генерировать статический снимок. С ними вывод может включать хуки взаимодействий, обработку состояний и более реалистичные API компонентов — ближе к тому, что команда сможет отправить в продакшен.
Инструменты design‑to‑code не видят экран как человек; они пытаются объяснить каждый слой правилами макета: ряды, колонки, контейнеры и отступы. Чем яснее эти правила, тем меньше результат будет полагаться на хрупкое позиционирование.
Большинство моделей начинается с поиска повторяющегося выравнивания и равных интервалов. Если несколько элементов имеют одинаковую левую границу, базовую линию или центр, ИИ часто воспринимает их как колонку или трек сетки. Последовательные промежутки (например, паттерн 8/16/24px) подсказывают, что макет можно описать через gap в стеке, gutter в гриде или токенизированные отступы.
Когда отступы слегка варьируются (15px здесь, 17px там), ИИ может заключить, что макет «ручной», и вернуться к абсолютным координатам ради пиксельной точности.
ИИ ищет визуальное «ограждение»: фоны, границы, тени и внутренние пустоты, которые намекают на контейнер. Карточка с фоном и внутренним отступом — явный сигнал для родительского элемента с дочерними.
Далее обычно он отображает структуру в примитивы:
Чистая группировка в файле дизайна помогает отличать родителей от соседей.
Если в дизайне есть ограничения (pin, hug, fill), ИИ использует их, чтобы решить, что растягивается, а что остаётся фиксированным. Элементы с «fill» обычно становятся гибкими по ширине (например, flex: 1), а «hug» — подгоняются под содержимое.
Абсолютное позиционирование появляется, когда модель не может уверенно выразить отношения потоковыми макетами — часто из‑за несогласованных отступов, перекрывающихся слоёв или смещений. Оно может выглядеть верно при одном размере экрана, но ломаться при адаптивности и масштабировании текста.
Использование небольшой шкалы отступов и выравнивание по явной сетке резко повышает шанс, что ИИ создаст чистый flex/grid код вместо координат. Консистентность — это не только эстетика, но и машиночитаемый паттерн.
ИИ не «понимает» иерархию в человеческом смысле; он выводит важность по паттернам, которые обычно её сигнализируют. Чем яснее дизайн передаёт эти сигналы, тем точнее сгенерированный UI соответствует намерениям.
Типография — один из самых сильных признаков. Больший размер, более насыщенный вес, высокий контраст цвета и увеличенный межстрочный интервал обычно указывают на более высокий приоритет.
Например, 32px полужирный заголовок над 16px обычным абзацем — явный паттерн «заголовок + тело». Трудности возникают, когда стили сближаются — два текстовых блока отличаются на 1–2px или используют тот же вес с разными цветами. В таких случаях ИИ может пометить оба как обычный текст или выбрать неверный уровень заголовка.
Иерархия также выводится из пространственных отношений. Элементы, которые ближе друг к другу, выровнены и отделены от остального содержимого пустым пространством, рассматриваются как группа.
Общие фоны (карточки, панели, тонированные секции) действуют как визуальные скобки: ИИ часто интерпретирует их как контейнеры section, aside или обёртку компонента. Неровные отступы или неконсистентное расстояние могут привести к случайной перегруппировке — например, кнопка окажется прикреплённой не к той карточке.
Повторяющиеся паттерны — идентичные карточки, элементы списка, строки или поля форм — сильный признак того, что это повторяемый компонент. Даже небольшие отличия (размер иконки, радиус углов, стиль текста) могут заставить ИИ сгенерировать несколько одноразовых версий вместо одного компонента с вариантами.
Кнопки передают намерение через размер, заливку, контраст и позицию. Залитая кнопка с сильным контрастом обычно трактуется как первичное действие; контурные или текстовые кнопки — вторичные. Если два действия выглядят одинаково по выразительности, ИИ может ошибочно выбрать, какое из них «первичное».
Наконец, ИИ старается перевести иерархию в семантику: заголовки (h1–h6), сгруппированные области (section) и смысловые кластеры (например, «информация о продукте» vs «действия покупки»). Чёткие типографические ступени и единообразная группировка делают этот перевод гораздо надёжнее.
Модели предсказывают назначение, сопоставляя увиденное с паттернами, изученными на множестве UI: знакомые формы, метки, иконография и расположение.
Некоторые расположения сильно намекают на конкретные компоненты. Горизонтальная полоса вверху с логотипом слева и текстовыми пунктами справа скорее всего — навбар. Ряд равной ширины элементов с одним выделенным часто интерпретируется как вкладки. Повторяющиеся блоки с изображением, заголовком и коротким текстом читаются как карточки. Плотные сетки с заголовками и выровненными строками становятся таблицами.
Эти догадки важны, потому что меняют структуру: «вкладка» предполагает состояние выбранности и клавиатурную навигацию, а «ряд кнопок» — возможно, нет.
ИИ ищет подсказки, которые обычно указывают на интерактивность:
Далее он назначает поведения: клик, открытие меню, навигация, отправка, разворачивание/сворачивание. Чем больше дизайн различает интерактивные и статичные элементы, тем точнее результат.
Если дизайн показывает несколько вариантов — hover, active/selected, disabled, error, loading — ИИ может сопоставить их с компонентами со состояниями (например, disabled‑кнопки, сообщения об ошибке, skeleton‑лоадеры). Если состояния не явно представлены, ИИ их часто опускает.
Неоднозначность встречается часто: кликабельна ли карточка или она только информативна? Шеврон декоративен или это контрол раскрытия? В таких случаях уточняйте через имена слоёв, аннотации или отдельные фреймы, показывающие взаимодействие.
Когда ИИ получает правдоподобное чтение макета, следующий шаг — перевод «как выглядит» в «чем является»: семантический HTML, переиспользуемые компоненты и согласованная стилизация.
Большинство инструментов мапит слои и группы дизайна в DOM‑дерево: фреймы становятся контейнерами, текстовые слои — заголовками/абзацами, повторяющиеся элементы — списками или гридом.
Когда намерение ясно, ИИ может назначить более точную семантику — например, верхняя панель становится <header>, логотип и ссылки — <nav>, а кликабельная карточка — <a> или <button>. ARIA‑роли иногда выводятся (например, role="dialog" для модального окна), но лишь при однозначном паттерне; иначе безопаснее оставить простой HTML и TODO для проверки доступности.
Чтобы не сгенерировать один огромный файл, ИИ пытается разбить UI на примитивы:
Сигналы компонента: повторяемость, согласованные паддинги/типография и группируемая кликабельная область. Частые ошибки — слишком мелкое дробление (каждая метка — отдельный компонент) или наоборот — монолитный компонент (весь экран в одном файле).
Генератор обычно выбирает один подход в зависимости от целевой стека или собственных настроек:
Качественный вывод опирается на токены дизайна — цвета, отступы, радиусы, тени — чтобы код оставался согласованным при эволюции дизайна. Строгое следование пиксельной точности часто даёт одноразовые значения (например, 13px отступы, почти одинаковые оттенки серого), которые выглядят верно, но плохо поддерживаются.
Практический баланс: сохранить иерархию и ритм отступов, затем нормализовать в токены и компоненты, которые вы сможете переиспользовать и рефакторить на этапе ревью — см. /blog/how-to-review-and-refactor-generated-ui-code.
Файлы дизайна часто выглядят «готовыми», потому что отрисованы в нескольких фиксированных размерах (например, 1440 и 375). Код не может этого предполагать. Инструмент design‑to‑code должен решить, как UI себя ведёт между этими ширинами, используя смесь подсказок и умолчаний.
Если дизайн включает несколько версий одного экрана (десктоп/планшет/мобильный) и структура согласована, ИИ может сопоставить их и понять, где меняются правила макета. Без вариантов он обычно откатывается к распространённым breakpoint'ам и считает размер фрейма «базовым», что даёт дерганые переходы.
ИИ ищет паттерны: повторяющиеся карточки в гриде, равные промежутки, выравнивание. На основе этого он может решить, что трёхколоночная сетка превращается в две, затем в одну. Трудности возникают, когда дизайн полагается на ручную подгонку — элементы выглядят выровненными, но на самом деле не согласованы.
Большинство макетов используют короткие тексты. Реальные продукты — нет. Сгенерированный код часто задаёт фиксированные ширины/высоты или чрезмерно усекает текст.
Быстрая проверка:
ИИ может сохранить пиксельную обрезку из дизайна, но адаптивному интерфейсу нужны правила: сохранять пропорции, выбирать стратегию кадрирования и решать, когда изображение масштабируется, а когда меняет расположение. Если это не указано, ожидать поведение «fill», которое обрежет важные части.
Перед тем как доверять выводу, просмотрите на очень маленьких, очень больших и промежуточных разрешениях. Если что‑то перекрывается, обрезается или становится нечитаемым, причина обычно в отсутствии намерения макета — а не в «плохом коде». Это сигнал добавить более явные ограничения в дизайн.
ИИ может преобразовать пиксели в UI‑код довольно неплохо, но доступность — это место, где «выглядит правильно» часто расходится с «работает для всех». Многие требования не видны на статическом фрейме, поэтому модели нужны явные сигналы.
Некоторые дружественные к доступности решения видны визуально, и ИИ может отобразить их в лучшем HTML:
Другие требования визуально не очевидны:
Ожидайте пробелы вроде отсутствия связей label/for, неверных уровней заголовков, кликабельных div без поддержки с клавиатуры, слабых фокус‑стилей и иконок без текстового альтернативного описания.
h1 → h2 → h3).header, nav, main, footer) и не задублированы.alt (или alt="" для декоративных).Добавляйте короткую спецификацию, когда есть модалы, выдвижные панели, сложные формы, кастомные селекты, drag‑and‑drop или любые компоненты со сложными состояниями. Даже пара заметок вроде «трапить фокус в модале», «Esc закрывает», «объявлять инлайновые ошибки» существенно повышают качество генерируемого UI‑кода.
ИИ может дать код, который на первый взгляд почти совпадает, но мелкие ошибки накапливаются. Большинство проблем — результат «разумных догадок», когда дизайн не кодирует правила явно.
Распространённая жалоба — несоответствие отступов: кнопки чуть смещены, секции дышат по‑другому или карточки выглядят сжато. Это происходит, когда паддинги для похожих элементов неконсистентны или когда Auto Layout смешан с ручной подгонкой. Модель может вывести общий паттерн (например, «16px везде») и перезаписать исключения — или же сохранить случайные отклонения, которые были ошибочными.
Сгенерированная разметка часто содержит слишком много обёрток. Каждая выявленная визуальная группа превращается в div. Итог — сложнее стилизовать, дебажить и иногда медленнее рендерится. Вы заметите это, когда простая карточка превращается в пять вложенных контейнеров только ради выравнивания иконки и заголовка.
ИИ может дробить компоненты слишком мелко (каждая метка — отдельный компонент) или, наоборот, делать монолиты (весь экран в одном компоненте). Корень проблемы — неочевидные границы: если повторяющиеся паттерны не идентичны, модель не выделит общий компонент.
Типография часто «дрейфует», потому что стили в дизайне не всегда напрямую мапятся в код. Тонкие отличия в line‑height, letter‑spacing или весе могут теряться, а запасные шрифты меняют метрики между окружениями. Поэтому заголовок, который влазил в Figma, внезапно переноcится в коде.
Если hover, focus, error, loading или empty‑состояния не представлены в дизайне, ИИ редко их придумывает. UI может выглядеть верно на статическом скриншоте, но падать при взаимодействии.
Генераторы кода не «видят» ваш дизайн как человек — они читают структурированный файл со слоями, ограничениями, стилями и экземплярами компонентов. Чем чище эта структура, тем меньше ИИ будет гадать (и тем меньше «див‑супа» вам придётся разбирать позже).
Имена слоёв — один из самых сильных сигналов для намерения и маппинга компонентов. Предпочитайте консистентные, описательные шаблоны, которые соответствуют вашей практике разработки:
Button/Primary, Button/SecondaryCard/Product, Card/ArticleForm/Input/Text, Form/CheckboxНе оставляйте всё как “Rectangle 12” или “Group 5” — это толкает ИИ к обобщённым обёрткам вместо переиспользуемых компонентов.
Ручное позиционирование часто превращается в абсолютные координаты в коде. Если вы хотите output в виде flex/grid, дизайн должен вести себя как flex/grid:
Когда дизайн отзывчиво ведёт себя внутри инструмента, сгенерированный UI с большей вероятностью будет адаптивным по умолчанию.
Одинарные цвета, размеры шрифта и нестандарные отступы порождают одноразовый CSS. Вместо этого:
Это повышает согласованность и упрощает рефакторинг в дизайн‑систему позже.
ИИ не может вывести то, чего не видит. Добавьте ключевые варианты: hover/pressed/disabled, состояния ошибок для полей, loading и empty‑варианты.
Когда поведение важно, аннотируйте кратко: «opens modal», «server‑validated», «shows toast on success». Одна строка рядом с компонентом может предотвратить неверный код взаимодействия.
Если вы стандартизируете командный рабочий процесс, зафиксируйте эти соглашения в лёгком чек‑листе и добавьте внутреннюю ссылку, например /blog/design-to-code-checklist.
Сгенерированный ИИ UI‑код лучше рассматривать как первый черновик: он экономит часы, но требует человеческой проверки, чтобы интерфейс вёл себя правильно, оставался поддерживаемым и соответствовал стандартам продукта.
Начните с чтения разметки как скринридер:
<h1> , затем логические <h2> /<h3>).<ul>/<ol>), а не градация div.Если семантика неправильная, правка CSS не спасёт доступность и юзабилити.
Многие генераторы опираются на абсолютное позиционирование или глубокие обёртки, чтобы «совпасть со скриншотом». Это ломается при смене контента.
Предпочитайте правила flex/grid перед координатами и уменьшайте вложенность так, чтобы у каждой обёртки была явная причина существовать (группировка, отступ или граница компонента). Если вы видите повторяющиеся style={{ left, top, width, height }}, перепишите эту область в первую очередь.
Найдите повторяющиеся UI‑паттерны (карточки, строки ввода, элементы навигации) и выделите их в переиспользуемые компоненты. Затем замените захардкоженные значения на токены: отступы, радиусы, типографику и цвета. Если у команды есть руководство по токенам — подстройтесь под него; иначе начните с минимального набора и расширяйте осознанно — см. /blog/design-tokens.
Не нужен тяжёлый тестовый набор, чтобы получить пользу:
Генераторы угадывают намерение. Зафиксируйте правки, которые вы сделали (правила взаимодействия, точки перелома, решение о маппинге компонентов), чтобы следующее поколение кода или другой разработчик не отменили их.
ИИ «design to code» лучше работает, когда вы рассматриваете его как ускоритель, а не автопилот. Быстрые команды выбирают рабочий процесс, соответствующий зрелости их дизайн‑системы и рискам экрана, который они строят.
1) AI‑ассист в инструменте дизайна (плагины Figma): отличен для работы прямо в исходном файле. Быстрое скелетирование при итерации дизайнеров, проще сохранять имена, компоненты и токены в согласии с файлом.
2) Внешние конвертеры (upload/export → code): полезны для воспроизводимого пайплайна по множеству файлов или команд. Быстрее для массовой конверсии, но часто требуется больше усилий по очистке структуры и по подключению взаимодействий.
На практике многие команды комбинируют design‑to‑code с более широким потоком «spec → shipped app». Например, платформы вроде Koder.ai расширяют принцип — превращение намерения в реализацию: можно описать фичу в чате, сгенерировать React‑frontend с Go/Postgres бэкендом (и Flutter для мобильных), затем итерировать с planning mode, snapshot'ами, откатом и экспортом исходников, когда нужно интегрировать с существующим репозиторием.
ИИ хорош для:
Будьте осторожны с:
Рассматривайте каждую генерацию как черновик: проверяйте вывод, фиксируйте повторяющиеся проблемы (именование, отсутствие состояний, неверная семантика), затем обновляйте промпт/спек и соглашения по дизайну. Через несколько итераций качество улучшается значительно.
Перед тем как принять решение, запустите пилот и оценивайте по: точности к макету, переиспользованию компонентов, адаптивности, базовой доступности и времени на рефакторинг. Если сравниваете инструменты и планы — проверьте /pricing.
Это ИИ‑помощник, который переводит визуальный интерфейс (фрейм Figma, экспорт макета или скриншот) в исполняемый UI‑код. Цель — получить рабочий черновик: структуру, ритм отступов и базовое оформление, чтобы разработчик мог переработать это в токены, компоненты и продакшен‑качество.
Обычно он переводит:
Пиксели не содержат всего. Обычно вам нужно указать или предоставить:
Скриншот — это самый «тонкий» ввод: он содержит цвет и геометрию, но не структуру (слои, ограничения, компоненты). Ожидайте больше догадок, больше абсолютного позиционирования и меньше повторно используемого кода.
Файл Figma/Sketch или структурированный экспорт даёт фреймы, имена слоёв, Auto Layout, ограничения и стили — это сигналы, которые помогают получить чистые flex/grid‑макеты и корректные границы компонентов.
ИИ ищет повторяющееся выравнивание и одинаковые промежутки, чтобы выразить интерфейс через правила flex/grid. Если он обнаружит понятный ритм отступов (например, 8/16/24), можно сгенерировать устойчивые стеки и сетки.
Если отступы неконсистентны или элементы слегка смещены, модель часто возвращается к абсолютным координатам, чтобы сохранить точный вид — но это ухудшает адаптивность.
Он ищет визуальные признаки «ограждения»:
Чистое групповое структурирование в инструменте дизайна (фреймы, Auto Layout) значительно упрощает восстановление отношений родитель/дитя в коде.
Абсолютное позиционирование появляется, когда отношения между элементами неочевидны — перекрытия, несогласованные промежутки, ручные подгонки или неочищенные группы. Оно может красиво выглядеть на одном размере экрана, но ломаться при:
Если нужен гибкий результат, сделайте дизайн «поведением как flex/grid» через Auto Layout и ограничения.
Иерархию ИИ выводит по визуальным подсказкам:
Если стили отличаются на 1–2px или шаги иерархии неочевидны, модель может выбрать неправильный уровень заголовка или пометить заголовок как обычный текст.
Он угадывает интерактивность по признакам affordance:
Если карточка может быть кликабельной или просто информационной, уточните это аннотацией или отдельным вариантом — иначе модель может подключить неправильное поведение или вовсе опустить его.
Сделайте быстрый, структурированный проход:
Обращайтесь к результату как к каркасу, а не к окончательному решению, и документируйте предположения, чтобы будущие итерации не их отменяли.