Гайд для малышей: как перегнать дизайн из Figma в код

Сегодня такое время, что каждый третий — мега-мастер вайб-кодинга и уже успел сделать горы проектов благодаря AI. Правда, ни одного релиза так и не выпустил, но речь не об этом.

Из каждого утюга я слышу про десятки крутых AI-сервисов, подключаемые skills, агенты-валидаторы и множество других обвесов вокруг вайб-кодинга. Всё это создаёт целый новый мир, вместе с новыми ролями и вакансиями на рынке. Но очень сложно начать делать что-то действительно кайфовое, пока не разберёшься в базе. Что я, собственно, и сделал.

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

Сделав всё по гайду, у тебя получится генерировать как минимум веб-страницу, которая:

🕵 Потыкать готовый лендинг можно тут

🥷 А если понравиться гайд, нужен будет ещё похожий контент про дизайн, AI и продуктовую кухню — залетай в мой TG-канал

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

Где:

У тебя, конечно, может быть своя структура. Главное, чтобы она была системной, потому что обращаться к ней будешь часто.

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

Для дизайна, который меняет цветовое оформление, в Figma-проекте сразу заводим стили по принципу:

Всегда готовь отдельные фреймы под ключевые разрешения: 1920, 1280, 768, 375. Это база. Но ещё важнее, вынести отдельно ключевые блоки, а не только всю страницу целиком. На них будем показывать разные нюансы взаимодействия или весь контент который скрыт (галереи, аккордеоны, карусели).

Такая структура, помогает точечно работать с блоками и не заставлять AI каждый раз анализировать дизайн целиком, достаточно локализовать проблему: «Сейчас работаем только с Menu Default [1920 · Light], нужно исправить…».

В моём кейсе, был следующий набор блоков: Home page, Menu, Download app button, Hero, Price, Feature, Settings, Footer.

Поскольку сегодня AI всё ещё не очень уверенно интерпретирует auto layout и логику слоёв в Figma, некоторые моменты нужно буквально показывать на пальцах. Для этого делаем отдельный layout-фрейм, где показываем:

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

Hover, active, disabled — это тоже отдельный фрейм, на котором важно показать состояния элементов. Можно, конечно, ссылаться на UI Kit. Но на практике проще и гибче сделать отдельный фрейм конкретного блока.

Например, для меню делаем фрейм «Menu Hover [1920 · Light]» и показываем hover у всех элементов сразу. Так AI понимает не только цвет, но и контекст. Это сильно снижает шанс, что он сделает какую-нибудь херню.

Если макет рассчитан на переключение тем — делаем отдельный фрейм. Если цвета нормально заведены в Figma, дальше всё тянется без проблем. У меня с этим почти никогда не было боли.

Всё, база готова. Теперь время переноса. Проверьте, что Figma MCP в вашем проекте включена:

Открываем проект → Dev Mode → Inspect → MCP

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

Тут важно понять, что нужно работать с AI, только поэтапно. Нет смысла закидывать конечную цель «верстай псина», нужно как минимум понимать каждый шаг. AI должен работать строго только над конкретным шагом, иначе: код удалится, сервер сгорит, а вы услышите: «Прости, ты прав, моя вина».

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

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

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

Мы в самом начале работы и лучше сразу зафиксировать правила, чтоб неожиданного не переписывались какие-то блоки, соблюдалось переиспользвание кода и так далее. Для этого делаем запрос на генерацию AGENTS_BASE.md (название может быть любым).

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

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

После анализа, ответов на вопросы, дошлифовки агент-шаблона под ваш проект, у вас на руках уже должа быть работающая страница или экран. Теперь начинается самая муторная часть — итеративная шлифовка. Вы уже видите набор несоответствий и это нормально. Теперь ссылаемся на наши подготовленные фреймы и пишем первую инъекцию правок. Пишем их внятно и понятно, ссылаясь на конкретные фреймы, например:

Думаю схема тут понятна. Ссылаемся на заранее подготовленные состояния блоков или экранов, прописываем что надо исправить. Как-только победили все трудности, переходим к следующему блоку в дизайне. Наша задача пока только заверстать всё как в макете, уточнить логику отображения UI, какие-то мелкие эффекты.

Когда адаптив работает шикарно во всех браузерах, а цветовые темы переключаются, надо поправить ресурсы. Как я писал выше, сейчас из Figma прилетают кривые SVG и растр с плохим качеством. Тут два стула:

1. Руками заменять все ресурсы с исправлением нейминга

2. Делегировать AI, явно прописав, что на что заменять. Причём ссылаться можно как на имя файла, так и на блок, в котором находится файл:

Когда дизайн готов, можно добавлять всё, о чём ты давно мечтал: переключение тем, локализацию, интеграцию. Достаточно ввести запрос. У тебя достаточно контекста и правил, чтобы AI изолированно делал нужный функционал. Если взять для примера локализацию:

Так, шаг за шагом всё получится.

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

Вот тут и есть ловушка. Чем больше ты берёшь на себя, тем сильнее падает внимание к деталям и качеству. В какой-то момент я пропускал тупейшие ошибки, поскольку внимание перестало удерживать всё. Поэтому важно не впадать в истерию «я теперь full-stack everything». Иначе можно тупо выгореть, создавая при этом посредственный результат.