Сегодня такое время, что каждый третий — мега-мастер вайб-кодинга и уже успел сделать горы проектов благодаря искусственному интеллекту. Правда, ни одного релиза так и не выпустил, но речь не об этом.
Из каждого утюга я слышу про десятки крутых AI-сервисов, подключаемые навыки, агенты-валидаторы и множество других обвесов вокруг вайб-кодинга. Всё это создает целый новый мир вместе с новыми ролями и вакансиями на рынке. Но очень сложно начать делать что-то действительно качественное, пока не разберёшься в базе. Что я, собственно, и сделал.
Этот гайд — стартовый, для тех, кто хочет на простом примере получить большой результат в кодировании с помощью AI. Как только смогу воспроизвести что-то более сложное с использованием навыков, интеграций и других трендов, будет вторая часть. А пока покажу, как добиться повторяемого процесса генерации дизайна в код, без сложных зависимостей и мучительных усилий.
Сделав всё по гайду, у тебя получится генерировать как минимум веб-страницу, которая:
сделана по дизайну
адаптивна под разные размеры экрана
учитывает retina и non-retina дисплеи
поддерживает локализацию с динамическим переключением языков
и позволяет реализовать другие свои идеи
🕵 Попробовать готовый лендинг можно тут
🥷 А если тебе понравится гайд и понадобится ещё похожий контент про дизайн, AI и продуктовую кухню — залетай в мой TG-канал
1. Необходимые инструменты для старта в вайб-кодинге
Figma с доступом к Dev Mode для подключения Figma MCP
AI-ассистент. Я использовал Cursor с моделью GPT 5.3 Codex (сразу скажу: в бесплатном тарифе нет смысла)
Базовое понимание дизайна и вёрстки
Умение формулировать мысли техническим языком. Ведь AI не умеет читать мысли. Если ты сам не понимаешь, что хочешь получить, он тем более не поймёт
2. Подготовка макета в Figma для успешного проекта
Чтобы процесс можно было воспроизводить снова и снова, нужно соблюдать 5 простых правил. В конечном итоге внутри проекта должна получиться примерно такая структура нейминга фреймов:
%pageName %type [%widthScreen · %theme]Где:
%pageName — название страницы или отдельного блока
%type — тип состояния: default, hover, layout
%widthScreen — ширина экрана
%theme — тема: light, dark
У тебя, конечно, может быть своя структура. Главное, чтобы она была системной, потому что обращаться к ней будешь часто.
Правило 1: Контент и ассеты в дизайне
Дизайн должен содержать финальные тексты и графику. Локализацию сразу делать необязательно. Если вместо графики пока заглушки — окей, но делай их контейнеры сразу в финальных размерах.
Для дизайна, который меняет цветовое оформление, в Figma-проекте сразу заводим стили по принципу:
Light/Primary
Dark/Primary
Правило 2: Брейкпоинты для адаптивного дизайна
Всегда готовь отдельные фреймы под ключевые разрешения: 1920, 1280, 768, 375. Это база. Но ещё важнее — вынести отдельно ключевые блоки, а не только всю страницу целиком. На них будем показывать разные нюансы взаимодействия или весь контент, который скрыт (галереи, аккордеоны, карусели).
Такая структура помогает точечно работать с блоками и не заставлять AI каждый раз анализировать дизайн целиком, достаточно локализовать проблему: «Сейчас работаем только с Menu Default [1920 · Light], нужно исправить…».
В моём кейсе был следующий набор блоков: Home page, Menu, Download app button, Hero, Price, Feature, Settings, Footer.
Правило 3: Логика ресайза для адаптивной верстки
Поскольку сегодня AI всё ещё не очень уверенно интерпретирует auto layout и логику слоёв в Figma, некоторые моменты нужно буквально показывать на пальцах. Для этого делаем отдельный layout-фрейм, где показываем:
что тянется по ширине
что фиксировано
где перенос в колонку
где горизонтальный скролл
где min-width и max-width контейнера
Да, делаем визуальную инструкцию. И да, возможно, уже через пару месяцев это будет не нужно. Но сейчас это решает большую часть проблем и сильно повышает качество результата.
Правило 4: Состояние элементов в интерфейсе
Hover, active, disabled — это тоже отдельный фрейм, на котором важно показать состояния элементов. Можно, конечно, ссылаться на UI Kit. Но на практике проще и гибче сделать отдельный фрейм конкретного блока.
Например, для меню делаем фрейм «Menu Hover [1920 · Light]» и показываем hover у всех элементов сразу. Так AI понимает не только цвет, но и контекст. Это сильно снижает шанс, что он сделает какую-нибудь ошибку.
Правило 5: Переключение тем в дизайне
Если макет рассчитан на переключение тем — делаем отдельный фрейм. Если цвета нормально заведены в Figma, дальше всё тянется без проблем. У меня с этим почти никогда не было боли.
Всё, база готова. Теперь время переноса. Проверьте, что Figma MCP в твоём проекте включена:
Открываем проект → Dev Mode → Inspect → MCP
Server status = Enabled
Image source = Download
Внимание! Ресурсы из Figma часто прилетают в низком качестве, даже SVG. Поэтому часть файлов всё равно придётся заменять руками.
3. Перенос дизайна в код с помощью AI
Тут важно понять, что нужно работать с AI только поэтапно. Нет смысла закидывать конечную цель «верстай, псина», нужно как минимум понимать каждый шаг. AI должен работать строго только над конкретным шагом, иначе: код удалится, сервер сгорит, а вы услышите: «Прости, ты прав, моя вина».
Шаг 1. Фундамент — закладка основ проекта
Сначала закладываем понятный контекст проекта, прописываем структуру, шаги и правила. Пишем свой первый запрос в подобном виде:
Я делаю сайт про %тема.
Нужно поэтапно заверстать его через Figma MCP, ссылка на проект %ссылка
Дизайн-макеты содержат основные брейкпоинты, которые отметил в названии фреймов: Home [1920 · Light] — где «1920» это размер экрана. Полный список брейкпоинтов: 1920, 1280, 768, 375. Ссылка на главную страницу с шириной 1920: %ссылка
Все ресурсы забираем из Figma. Дизайн делаем как в макетах. Анимацию элементов делаем потом. Важно работать не на скринах, а со структурой слоёв
Работать будем этапами. Задавай мне все уточняющие вопросы
Можно сразу описать какие-то фундаментальные навигационные элементы, и на этом шаге лучше остановиться. Подождать, пока ваш любимый AI проанализирует проект, задаст пачку вопросов и поможет разбить работу на шаги.
В этот же момент можно создать агента с правилами, который будет помогать держать контекст, не делать банальные ошибки и сохранять нервные клетки. Это один из самых важных шагов, потому что именно он превращает хаотичный вайб-кодинг в повторяемый процесс.
Шаг 2. Создание агента-шаблона для работы
Мы в самом начале написания кода, и лучше сразу зафиксировать правила, чтобы неожиданно не переписывались какие-то блоки, соблюдалось переиспользование кода и так далее. Для этого делаем запрос на генерацию AGENTS_BASE.md (название может быть любым).
Вот мой пример *.md файла. Прочитай его, удали лишнее и добавь нужное конкретно под твои задачи или сгенерируй файл самостоятельно.
И давайте сразу: писать агента на русском — это абсолютно норм и никак не влияет на качество. Я бы даже сказал, что если ты говоришь на русском, то и пиши правила на нём. Потому что ты создаёшь поведенческий паттерн для агента. Если с английским всё в порядке, то тоже хорошо.
Шаг 3. Соединение кусочков кода и проверка
После анализа, ответов на вопросы, дошлифовки агент-шаблона под проект, на руках уже должна быть работающая страница или экран. Теперь начинается самая трудоемкая часть — итеративная шлифовка. Ты уже видишь набор несоответствий, и это нормально. Теперь ссылаемся на наши подготовленные фреймы и пишем первую инъекцию правок. Пишем их внятно и понятно, ссылаясь на конкретные фреймы, например:
В блоке Feature есть ошибки. Внутри галерея, она прокручивается по горизонтали, все карточки внутри галереи я положил в фрейм %ссылка
Также добавляем +20px внизу контейнера, чтобы scrollbar не наезжал на контент
Думаю, схема тут понятна. Ссылаемся на заранее подготовленные состояния блоков или экранов, прописываем, что надо исправить. Как только победили все трудности, переходим к следующему блоку в дизайне. Наша задача пока только заверстать всё как в макете, уточнить логику отображения UI, какие-то мелкие эффекты.
Шаг 4. Замена актуальной графики и оптимизация ресурсов
Когда адаптив работает шикарно во всех браузерах, а цветовые темы переключаются, надо поправить ресурсы. Как я уже писал выше, сейчас из Figma прилетают кривые SVG и растр с плохим качеством. Тут два варианта:
Руками заменять все ресурсы с исправлением нейминга
Делегировать AI, явно прописав, что на что заменять. Причём ссылаться можно как на имя файла, так и на блок, в котором находится файл:
// Замена внутри блока
В блоке Feature есть List с преимуществами, для них я подготовил нормальные SVG, они должны быть 32х32px. Замени в размеченных мной местах следующие файлы, а старые удали:
- Поддержка 150 валют > ic_unlimList_BENEFIT_24
- Работа оффлайн > ic_offlineMode_16
// Замена конкретного файла
В блоке Hello будет замена 457г483759734 на final-promo-light.png в размере х2 для ретина-экранов
Шаг 5. Добавление новых функций и локализация
Когда дизайн готов, можно добавлять всё, о чём ты давно мечтал: переключение тем, локализацию, интеграцию. Достаточно ввести запрос. У тебя достаточно контекста и правил, чтобы AI изолированно делал нужный функционал. Если взять для примера локализацию:
Теперь делаем локализацию, она будет доступна через кнопку %buttonName, для нее нужно сделать dropdown в общей стилистике.
Для начала сделаем выбор из двух языков: RU, EN. Задай все уточняющие вопросы и приступим
Так, шаг за шагом всё получится.
Важная мысль о возможностях AI в вайб-кодинге
Искусственный интеллект сильно расширяет твои возможности. Это одновременно прекрасно и опасно. Раньше ты делал, например, только дизайн, а теперь ты можешь дополнительно верстать его, локализовать, тянуть цены продукта, делать юридические страницы, шаблоны на основе готового дизайна, анимации и так далее.
Вот тут и есть ловушка. Чем больше ты берёшь на себя, тем сильнее падает внимание к деталям и качеству. Я сам это на себе очень почувствовал. Поэтому важно не впадать в истерию «я теперь full-stack профессионал». Иначе можно очень быстро выгореть, создавая при этом посредственный результат.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…