Сегодня UI в продукте — не просто красивая картинка. Это полноценный драйвер роста компании в борьбе за первенство. И не получается относиться к этому как «просто запили мне нормальный UI». Каждый элемент стоит денег и ресурсов разработчиков и дизайнеров. 

В первой части статьи мы посмотрели, как ИИ помогает менять скорость релизов с помощью Claude 4.5 и влиять на результаты бизнеса. А теперь давайте разберёмся, как это сделать с другими инструментами.

Кому и зачем читать эту статью

Будет полезно дизайнерам, инженерам, тимлидам и продактам, которым:

• нужно быстро генерировать и поддерживать UI на Flutter или других фреймворках;

• хочется кроссплатформенности и максимальной автоматизации;

• нужно формализовать процесс: внедрять гайды, контролировать логику, формировать обучающие правила;

• интересно, как работать с MCP (протоколами интеграций) и жить в парадигме «дизайн по подписке»;

• надоело вручную переносить дизайн и фиксить повторяющиеся ошибки.

Почему стоит прочесть её сейчас:

• проекты требуют итеративных изменений, а рутинные задачи занимают всё больше ресурсов;

• растут требования к качеству и однородности интерфейсов;

• увеличивается число супераппов: мультисервисные платформы диктуют стандарты и ускоряют процессы;

• идёт конкуренция между командами и платформами: скорость обновлений напрямую влияет на выживаемость продукта;

• Figma становится отраслевым стандартом, а Cursor — новым мастхэвом для тех, кто хочет делегировать рутину, не теряя в качестве.

Кстати, дальше мы подробнее расскажем, что делать с такими ошибками.

Cursor, Figma, нейросети и MCP

Чтобы понять, как автоматизировать создание UI-компонентов, важно погрузиться в инструменты и протоколы, с помощью которых всё и происходит.

Cursor — AI-помощник для кода и UI

Cursor — IDE на базе VS Code, в котором есть агентный режим «из коробки». Он  умеет читать дизайн и генерировать код, в том числе Flutter-компоненты. Инструмент позволяет:

• вести диалог в формате чата, задавать вопросы и уточнять детали;

• обращаться к внешним источникам (например, Figma-макетам) напрямую;

• интегрировать правила и логику команды в процессе генерации;

• исправлять ошибки и предупреждения, выдаваемые линтерами, автоматически под управлением Makefile и кастомных скриптов.

Cursor помогает получить стартовый рабочий код, который потом можно довести до продакшн-качества.

Figma — стандарт проектирования

Собственно, про Figma знают все. Это графический редактор с мощным набором инструментов для UI/UX:

• центральное хранилище макетов, стилей и компонентов;

• инструменты коллаборации и комментариев;

• dev-режим с возможностью просмотра и копирования CSS, PNG и всей нужной метаинформации;

• возможность экспортировать компоненты и получать API-доступ к стилям, переменным, цветам и иконкам.

Figma-данные в этом ключе предстают как некий источник истины, вокруг которого строится вся автоматика генерации UI.

MCP (Multi-Context Protocol) — протокол интеграции и доступа

MCP — это не просто API, а стандартизованный протокол коммуникации ИИ и внешних систем. В нашем кейсе он:

• обеспечивает Cursor доступ к «живым» данным из Figma;

• позволяет доставать сразу PNG из кеша, а не каждый раз дергать дорогостоящий сетевой API;

• передаёт стили и переменные локально, экономя время и ресурсы;

• обеспечивает синхронизацию между визуальной частью и кодовой базой через стандартизованное взаимодействие.

MCP помогает устранить один из главных недостатков генерации кода по картинке — невозможность видеть и использовать стили и данные из макета напрямую.

Нейросети

Нейросеть в этом кружке инструментов — это, по сути, тот самый мозг, который по запросам и входным данным создает Flutter-компоненты. 

Но просто нейросеть — это далеко не всё. Ей нужны обучающие правила (MD-файлы с описанием правильного и неправильного кода), контролирующий Linter, который взаимодействует с Cursor через make команды, и порядок: изучение контекста → изучение правил → изучение Figma MCP → генерация с последующим анализом и исправлением.

Работа этих компонентов дает реальный результат, а не очередной черновик.

Генерируем UI-компонент по картинке из Figma

Посмотрим на практике, как происходит автоматическая генерация Flutter-компонента с помощью Cursor на базе изображения из Figma.

1. Готовимся к запуску

Берём типичный экран е-кома — главную страницу с программой лояльности — с бонусной картой. В ней содержатся тексты про количество бонусов, иконки, какие-то декоративные элементы. 

Задача — получить единый компонент BonusWidget по изображению PNG из Figma.

Что делаем:

• в Figma в Dev-режиме копируем PNG карточки;

• PNG загружаем в чат Cursor;

• запускаем запрос: «Сгенерируй UI-компонент по изображению».

2. Первые результаты

Cursor нам отвечает, что прочитал изображение и приступает к созданию Flutter-компонента. Уже здесь видно:

• он ищет и выделяет сущности класса-заглушки с ключевыми параметрами: total_bonuses, expiring, expireZ;

• создаёт компонент BonusWidget, хоть и с условным названием;

• вместо вставки иконок генерирует QR-код через CustomPainter, что, вообще-то, достаточно оригинально.

3. Что не получилось

Но несмотря на всю мощь Cursor, результат далёк от прода:

• стиль компонентов размытый и неполный — Cursor просто «угадывает» стили по картинке, без точного маппинга;

• значения частично захардкожены, не всегда используются локализации;

• нейминг элементов и классов интуитивный, но без явной связи с архитектурой проекта;

• в коде встречаются игнор-комментарии (ignore) — а это не на пользу качества;

• частично потерялись декоративные элементы и правильные отступы.

Вот такой первый черновик. Не идеал, скорее, рабочий MVP, который дальше будем отлаживать.

4. Какие уроки стоит извлечь

• Просто закинув картинку в ИИ, вы почти никогда не получите готовый, чистый и полный код.

• Эффективнее всего использовать такую генерацию как базовую стадию разработки — делать первый прототип для наглядности.

• Главное — не лениться работать с контекстом, задавать нейросети правила, логику и обучать на ошибках.

• Автоматизация — не волшебная палочка, а мощный ассистент, которого нужно правильно строить.

Создаём правило, настраиваем линтер, учим нейросеть через обратную связь

Мы говорили об этом в первой части, а теперь расскажем подробнее.

Правила (rules) — главный инструмент управления качеством и предсказуемостью результатов работы ИИ. 

Они задаются в специальной директории .cursor/rules или через настройки ИИ-ассистента и могут быть глобальными (для всех проектов) и специфичными.

Как лучше работать с правилами:

• разделяйте крупные правила на отдельные, которые можно комбинировать — их будет проще поддерживать и расширять;

• формулируйте каждое правило максимально конкретно, избегайте размытых формулировок. Например: «Использовать 2 пробела для отступов», «Не использовать ignore для lint»;

• добавляйте к каждому правилу примеры корректного и некорректного кода и обязательно давайте пояснение причин — такие правила «лучше усваиваются» ИИ и легче применяются на практике;

• прописывайте стиль кода, структуру UI, типовые архитектурные решения, работу с ошибками и документацией;

• правила должны быть короткими (до 500 строк), чтобы не потерять фокус и облегчить обновление.

Типы правил

• Глобальные — действуют во всех проектах пользователя.

• Проектные — хранятся локально в .cursor/rules и подхватываются только в контексте целевого проекта.

• Временные или «memories» — создаются Cursor автоматически на основе истории диалога (например, конкретные околокодовые договорённости).

Настраиваем линтер и автоматизируем контроль

Линтер — например, Surf Lint Rules или кастомные Dart code metrics — второй важнейший фильтр качества после правил. 

• На уровне Makefile/CI/CD прописываем обязательный прогон линтеров после каждой генерации.

• Для ИИ прямо в правилах и промптах задаюём требования: «Не сдавай код с warnings», «Исправляй до 0 ошибок, прежде чем закончить задачу».

• Используем команды make autofix и make analyze для автоматической правки и анализа кода.

Получаем пример автоматизированного цикла: генерация → autofix → analyze → повторная генерация при ошибках.

Обучаем нейросеть через итерации и обратную связь

1. После каждой генерации указываем, что и где не так. Например, «Stack внутри DecoratedBox без размеров — исправь», либо «Добавь описание для Text.rich».

2. После исправления ошибки фиксируем новое правило: «Использовать Text.rich с правильными стилями, объяснить почему».

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

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

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

В общем, качественная автоматизация UI-разработки стоит на 3 китах: формализованные правила для ИИ, строгая линтинговая политика и последовательная обратная связь. Сочетание этих методов уменьшает число ручных доработок, структурирует процесс генерации и помогает растить внутренний стандарт качества не только для людей, но и для нейросети.

Класс-заглушка: что это и зачем нужно

Класс-заглушка — это своеобразный «каркас» UI-компонента. У него есть название, в него передаются Entity (данные для UI) и остальные поля, которые нужны для UI.

Почему класс-заглушка критически важен для генерации:

• снижает риск ошибок, потому что ИИ чётко видит, какие поля доступны, и не пытается «додумывать» или добавлять лишние свойства;

• стабилизирует структуру. Если проект большой, и класс не передан явно, нейросеть часто теряет путь к сущности и генерирует значения, которые не интегрируются с остальным проектом;

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

Стоит отметить, что ИИ сопоставляет поля класса-заглушки с макетом Figma по именам и типам. Чем точнее и проще названия — тем надёжнее маппинг.

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

Для правильной работы важно передавать не только класс-заглушки, но и ссылку на макет Figma или компонент, чтобы нейросеть «поняла», где искать информацию.

Ошибки при генерации

1. ИИ иногда придумывает лишние поля, если не видит класс Entity. Пример — вместо «expireAt» появляется «expirationDate», и компонент перестаёт работать с остальной системой.

2. Могут также потеряться обработчики событий — например, onTap — если они не явно обозначены в каркасе.

3. Бывает, что структура не совпадает с бизнес-логикой — поля карты и макета расходятся. Например, поля сгорающих бонусов не подтягиваются, если их нет в заглушке.

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

Что делать в таких ситуациях

1. Передаём класс-заглушку вместе с макетом: ИИ работает над задачей по заранее подготовленным данным, не испытывая лишних догадок.

2. В промпте вместо «реализуй UI-компонент по изображению» пишем «реализуй этот компонент по изображению, вот его класс-заглушка».

3. Передаём ссылки на части в Figma, особенно если макет большой: это способствует точной обработке стилей и локализации.

4. Проверяем маппинг имён между макетом и классом-заглушкой: корректная синхронность минимизирует ручные исправления.

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

Мастер-запрос в работе с Cursor

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

В отличие от простых запросов вроде «сгенерируй UI-компонент по изображению», мастер-запрос содержит четкий план и порядок действий для нейросети — от изучения правил и контекста до анализа стилей и итоговой генерации кода.

С помощью строгого порядка действий мы избежим потери информации. 

Мастер-запрос задаёт нейросети последовательные этапы изучения входных данных:

1. Изучить правила.

2. Изучить контекст — например, класс-заглушку или макет в Figma.

3. Обратиться к MCP для получения стилей. 

4. И только на этом этапе приступать к созданию UI-компонента.

5. После — минимизировать ошибки генерации — перебросы между этапами дадут Cursor возможность «сверять» результаты и состояния, снижать шанс пропуска важных деталей. Это поможет повысить вероятность соблюдения правил. Потому что если нейросеть сначала загружает все инструкции, при написании кода она будет следовать им, а не пытаться импровизировать.

6. Улучшить читаемость этапов генерации — в диалог с пользователем Cursor информирует, на каком этапе находится, сообщает об отклонениях или проблемах. Так Cursor увидит целостную картину и не будет делать «рывков» кода вслепую. А все обращения к внешним данным начнут отвечать нуждам задачи.

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

Логика диалога и прозрачность работы

Cursor при работе с мастер-запросом не просто «выполняет» действия, он ведёт полноценный диалог:

• отвечает, что изучает контекст;

• подтверждает загрузку правил;

• информирует об обращении к MCP;

• сообщает о найденных несоответствиях;

• просит дополнительную информацию, если что-то неясно.

Это помогает пользователю корректировать процесс и вовремя вносить правки.

Важность ссылок и точной передачи контекста

Мастер-запрос обычно содержит ссылки на ключевые файлы и компоненты. Например, Figma-ссылку на компонент и путь класса-заглушки. Это позволяет Cursor работать с актуальными, согласованными данными, а не полагаться на догадки. Собственно, без этих ссылок генерация часто «размывается» и становится нестабильной.

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

Что такое MCP и почему он важен

MCP (Model Context Protocol) — это стандартизированный протокол, позволяющий Cursor AI получать прямой доступ к информации дизайна в Figma в реальном времени. Вместо того, чтобы работать с обычными API-запросами, MCP работает через локальный сервер и кеш. Что обеспечивает быстрое и безопасное извлечение стилей, переменных и компонентов напрямую из макета.

Это гарантирует, что ИИ получает максимально точные данные о текущем дизайне, и существенно повышает качество генерации UI-компонентов.

Как подключить MCP

1. Получаем API-токен Figma. Пользователь генерирует токен в настройках аккаунта Figma, обеспечивающий права чтения макетов.

2. Настраиваем MCP-сервер в Cursor. В Cursor добавляется MCP-сервер с указанием API-токена и параметров подключения. Для работы требуется локальный запуск WebSocket-сервера, который интегрируется с Figma.

3. Включаем Dev-режим в Figma. Важный этап, позволяющий Cursor получать актуальные данные напрямую из видимого состояния макета, включая PNG, стили, компоненты и переменные.

4. Привязываем компонент. Через ссылку «Copy link to selection» в Figma передается точный адрес компонента, который Cursor анализирует и использует для генерации.

Анализ стилей и переменных

MCP передает Cursor подробную информацию:

• о темах и цветах. Например, Background, Primary, Surface, Icon и другие цвета темы в точном соответствии с именами из Figma;

• об иконках. Cursor получает имена и векторные данные иконок, что позволяет вместо картинок использовать нативные Flutter-виджеты с правильными SVG-форматами или шрифтами;

• об отступах и размерах. MCP предоставляет информацию о расположении элементов, padding и margin, а Cursor старается наиболее точно их воспроизвести.

• о локализации. Если локализация настроена в макете и классе-заглушке, Cursor подтягивает нужные переводы к компонентам.

Интеграция с макетами и кодовой базой

Подключение MCP существенно упрощает интеграцию с кодовой базой, поскольку Cursor получает возможность напрямую соотносить названия компонентов и их полей в проекте с данными из Figma. Благодаря этому обеспечивается автоматическое применение стилистики, согласованной с темой проекта, ведь MCP передаёт точное сопоставление имён цветов и стилей, что особенно важно для сохранения визуальной консистентности. 

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

Подключение MCP — важный шаг к стабильной генерации UI от Cursor AI. Он позволяет получить из Figma точные темы, цвета, переменные и иконки, обеспечивая интеграцию макета с кодовой базой на высоком уровне. MCP снимает ограничения генерации по статичному изображению и превращает процесс в настоящий работающий интерфейс.

Полезные советы

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

1. Игнор-комментарии (ignore)

В коде часто появлялись игнор-директивы для линтера — они снижали качество и надежность. Советуем требовать удаления таких комментариев и писать код так, чтобы линтер был чист.

2. Потеря декоративных элементов 

ИИ иногда не распознает небольшие «украшательные» штуки и не включает их в результат. Как решить? Добавлять подробные описания с цветами и при необходимости отдельные изображения, чтобы Cursor «видел» нужный декор.

3. Нарушение отступов и размеров

Убрать ошибки разметки помогает обратная связь и конкретные команды для исправления параметров размеров.

4. Неправильный нейминг

Cursor иногда придумывал случайные имена для компонентов или параметров. Как решить? Использовать класс-заглушки и дать в промпте точные названия.

Как классно работать с ИИ

1. Объясняйте причину требований. В правилах и диалогах указывайте не только что делать, но и почему. Например: «Используй text.rich, а не RichText, потому что это сохраняет стили лучше».

2. Разбивайте задачи на небольшие шаги. Вместо одного большого запроса давайте серию этапов с проверкой результата на каждом.

3. Используйте ссылки на реальные компоненты и класс-заглушку. Это повышает точность и снижает вероятность придумывания лишнего.

4. Не бойтесь переобучать Cursor. После каждой итерации фиксируйте новые правила, чтобы нейросеть не повторяла ошибки.

5. Постоянно ведите диалог. Вовлекайте Cursor в обсуждение, дайте ему понять контекст, и он будет избегать стандартных ошибок.

Чек-лист по генерации UI с помощью Cursor и MCP

1. Подготовка

   • Убедитесь, что макет в Figma чист и структурирован.

   • Включите Dev-режим, чтобы получить доступ ко всем переменным и стилям.

   • Сгенерируйте или подготовьте класс-заглушку с основными параметрами.

   • Проверьте, что в проекте настроен линтер с понятными правилами.

2. Подключение MCP

   • Настройте MCP-сервер в Cursor с правильным API-токеном Figma.

   • Привяжите нужный компонент Figma через ссылку «Copy link to selection».

3. Формирование промпта

   • Напишите последовательный план действий для Cursor: изучить правила → изучить контекст → обратиться к MCP → сгенерировать код.

   • Укажите ссылку на класс-заглушку и компонент в Figma.

   • Добавьте просьбу исправлять до отсутствия ошибок.

4. Работа с ИИ

   • Передайте промпт и дождитесь первого результата.

   • Читайте ошибки, предупреждения, высылайте обратную связь.

   • Просите убрать игнор-комментарии и добавить недостающие элементы.

   • На каждом этапе фиксируйте новые правила или корректировки.

5. Финал

   • Запустите make autofix и make analyze для окончательной проверки.

   • Сверьте с макетом и проверьте визуальные совпадения.

   • Интегрируйте компонент в основной проект.

Инструкции для правил

1. Определяйте стандарты наименования компонента и параметров.

2. Опишите паттерны использования основных Flutter-виджетов.

3. Определяйте, какие стили нужно подтягивать из Figma, а какие — хардкодить.

4. Запрещайте или ограничивайте использование ignore-комментариев.

5. Регулярно обновляйте правила на основе накопленного опыта.

Как успешно всё это счастье внедрить

1. Внедряйте правила с самого начала. Не ждите, когда ИИ «сам научится». Детализируйте и документируйте требования по стилю, архитектуре и обработке ошибок.

2. Развивайте процесс итеративно. Стартуйте с минимального набора правил и класс-заглушка, затем последовательно добавляйте новые по мере роста проекта и понимания нюансов.

3. Обеспечьте коммуникацию между дизайнерской и разработческой командами. Настраивайте Figma с учетом требований MCP: правильные стили, чистые компоненты, именования.

4. Автоматизируйте проверки. Используйте линтеры с задачами в CI/CD, интегрируйте make-файлы для автофиксов и анализа, чтобы снизить человеческий фактор.

5. Обучайте команду. Проводите внутренние тренинги по работе с Cursor, правилами и промптами, делитесь успешными кейсами.

6. Планируйте постепенное расширение ИИ-инструментов. Используйте MVP-стратегию, начиная с простых компонентов и переходя к более сложным с ростом зрелости процесса.

Один большой итог

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

Тогда инструменты вроде Cursor AI и MCP смогут раскрыть свой полный потенциал: ускорять работу, экономить ресурсы и помогать делать интерфейсы быстрее и качественнее.

Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf Tech.

Присоединяйтесь!