Дизайн-системы, которые говорят с продуктом

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

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

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

Сведения о системе и способ ими пользоваться

Представим обычный запрос к AI-инструменту – собрать страницу на компонентах определённой дизайн-системы. Чтобы выполнить его, агенту нужно знать, какие компоненты доступны и как ими пользоваться.

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

Один из способов дать ему такой доступ – MCP (Model Context Protocol), открытый стандарт взаимодействия AI-приложения с внешними данными и инструментами.

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

В дизайн-системе Mantine для этого описаны несколько способов. Файл llms.txt служит оглавлением документации для AI-инструментов и содержит ссылки на отдельные страницы в Markdown. По этим ссылкам агент может перейти к нужным материалам. Также есть MCP-сервер для поиска и чтения отдельных материалов документации. Через него агент может запросить параметры компонента, найти нужный раздел или получить описание API.

Там же Mantine публикует три skills для агентов, которые помогают создавать формы, собственные компоненты и элементы выбора. Последний skill посвящён работе с Combobox – набором базовых элементов и логики для сборки выпадающих списков, автодополнения и множественного выбора. На этой основе в самой библиотеке построены, например, Select и Autocomplete. Skill объясняет, как собрать свой вариант такого компонента с нужным отображением и поведением.

Skill – набор инструкций, который агент использует для подходящей задачи. Например, работа с формой включает проверку значений и вложенные поля; сборка собственного компонента затрагивает принятый в библиотеке способ расширения. Справочный запрос и инструкция решают разные части задачи. Первый помогает узнать, что есть в системе. Вторая описывает, как с этим работать.

Три скилла при этом не означают трёх самостоятельных агентов. Один исполнитель может читать разные инструкции, получать сведения через MCP и менять код своими инструментами. Количество файлов с инструкциями ничего не говорит о разделении контекстов, прав или ответственности.

Другой подход у дизайн-системы Cloudscape от Amazon. Команда предоставляет Markdown-версии страниц и JSON-описания API компонентов, доступные через llms.txt. Их могут читать AI-инструменты и MCP-серверы. Этот способ подготовки документации сам по себе не требует собственного сервера дизайн-системы. Подготовка знаний для агента и способ их доставки остаются отдельными решениями.

Сведения о компоненте и инструкции по работе с ним отвечают на разные вопросы агента.

Компонент не только нужно выбрать, но ещё и встроить в проект

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

MCP-сервер shadcn позволяет просматривать реестры, искать в них компоненты и добавлять найденное в проект. Реестр здесь можно понимать как каталог готовых элементов. Документация описывает MCP как связку между AI-помощником, реестрами и shadcn CLI – программой для работы через командную строку. Агент переводит запрос человека в операции с реестром, а ресурсы загружаются и устанавливаются в проект.

Отдельный skill shadcn получает локальную конфигурацию через shadcn info --json. В ней есть фреймворк, версия Tailwind CSS, пути импортов, библиотека иконок и установленные компоненты. Tailwind CSS помогает оформлять интерфейс с помощью готовых CSS-классов, которые задают цвета, отступы, размеры и другие свойства элементов. Для поиска предусмотрены и CLI-команды, и MCP-инструменты. Так в разговор с дизайн-системой входит контекст самого продукта. Найти подходящий компонент недостаточно; нужно ещё знать, куда он попадёт и с чем будет работать.

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

Контекст проекта важен и при обновлении существующего интерфейса. Команда Fluent UI Blazor описывает такую задачу для своего MCP-сервера – предоставлять документацию по каждому компоненту при переходе на новую версию библиотеки, с v4 на v5. Здесь агенту помогают разобраться с изменениями API, из-за которых прежний код может потребовать доработки.

У дизайн-системы Carbon описана связка с Figma Make – инструментом, который генерирует код интерфейса по запросу и исходному макету. Дизайнер добавляет фрейм в чат и выбирает Make Kit для Carbon React v11. Make Kit – подготовленный для генерации набор кода, стилей и рекомендаций дизайн-системы. Подключение MCP позволяет Make обращаться к материалам Carbon по ходу работы. Дополнительно применяется skill carbon-builder-figma-make-react с инструкциями по сборке интерфейса на компонентах Carbon. Так макет дополняется сведениями о том, как его реализовать средствами конкретной библиотеки.

У инструментов Carbon MCP разные задачи. docs_search находит рекомендации по использованию компонентов, а code_search – примеры их реализации в коде. get_charts ищет примеры графиков и диаграмм из Carbon Charts. labs_search обращается к экспериментальным компонентам Carbon Labs, их описаниям и примерам. Инструмент code_audit в документации описан как проверка кода на соответствие правилам Carbon – от использования токенов и компонентов до требований к доступности и расположению элементов.

Макет задаёт визуальное и структурное намерение дизайнера, а материалы системы помогают перевести его в код на принятых компонентах. Для команды, развивающей такую интеграцию, это означает дополнительную работу при обновлении библиотеки – сверять инструкции skill, содержимое Make Kit и материалы, доступные через MCP, с новой версией компонентов. Иначе генерация может опереться на устаревший пример или правило. При этом сам факт передачи фрейма ещё не объясняет, как будет оценено соответствие результата исходнику.

Что скрывается за словом «проверка»

Сервер может вернуть агенту правило или результат проверки кода по этому правилу, и это разные типы ответов, даже когда они доступны через одну интеграцию.

В Primer MCP есть компоненты, паттерны, рекомендации по доступности и init для подготовки проекта с Primer React. Здесь интересны два инструмента проверки.

lint_css проверяет использование токенов Primer в CSS. review_alt_text оценивает альтернативный текст изображения с точки зрения практик доступности и соответствия контексту. Это понятные задачи, но наличие инструментов для их выполнения не означает, что вся страница прошла UX-аудит или стала доступной.

Поэтому формулировка «агент проверил интерфейс» может оставлять неясным, что именно он сделал. Можно проверить использование токенов и не заметить неясную иерархию действий. Можно получить рекомендации по доступности, но ещё не применить их к результату.

В моей дизайн-системе Omniground это различие отражено в запросе get_component_audit_contract. Локальный MCP читает сведения из репозитория и возвращает требования к проверке компонента. Саму проверку ещё предстоит выполнить и зафиксировать. Для создания черновика и его проверки в Omniground предусмотрены отдельные специализированные агенты. Их задачи разделены регламентом, самостоятельно одобрять свою работу запрещено. Ответ «всё ОК» даёт агент, который не выполнял проверяемую работу.

Ошибки бывают и в сведениях, которые сам MCP-сервер передаёт агенту. В релизе NYS 1.21.0 команда сообщила об исправлении такой проблемы. Инструмент get_utility_classes предлагал CSS-классы, которых в библиотеке не существовало. Как следует из описания исправления, их названия были записаны в справочнике инструмента, который редактировали вручную и не сверяли автоматически с кодом стилей. Разработчики MCP-сервера исправили справочник и добавили автоматическую проверку – она сравнивает перечисленные в нём классы с теми, что действительно есть в собранных стилях библиотеки. Так проверка охватывает ещё и источник сведений, на которые опирается агент.

Требования к проверке, доступный инструмент и выполненная проверка – это три разных факта, которые лучше не смешивать и не взбалтывать.

Кто задаёт порядок работы

У других интеграций предметом настройки становится весь порядок работы:

• что агент выясняет до изменения кода,

• как выбирает решение

• и когда имеет право считать задачу законченной.

daisyUI Blueprint предлагает агенту готовую последовательность работы над страницей. Это платный MCP-сервер с шестью инструментами. Одни собирают сведения о проекте и загружают правила реализации. Другие задают направление дизайна и структуру страницы. Затем агент получает синтаксис нужных компонентов. Завершает процесс Quality Inspector, заявленный как инструмент проверки исходного кода.

Ролевые названия вроде Creative Director могут создавать впечатление целой команды. Но на сайте так названы MCP-инструменты, к которым обращается подключённый AI-агент. Само название ещё не означает, что за ним стоит отдельный самостоятельный агент. Разработчик также заявляет, что этапы обязательны и пропустить их нельзя. Насколько строго это обеспечено технически, нужно проверять в работе – одного описания продукта для такого вывода недостаточно. Особенность же daisyUI Blueprint в том, что подготовка, композиция и проверка предлагаются как один рабочий процесс.

В документации Salesforce Lightning Design System (SLDS) процесс собирается вокруг самой среды разработки платформы. Agentforce Vibes отвечает за планирование, вызовы инструментов и генерацию кода. Макет приходит из Figma, а Figma MCP и Salesforce DX MCP участвуют в передаче контекста. В описанную среду также входит SLDS Linter – инструмент автоматической проверки HTML и CSS на соответствие правилам SLDS. Он находит, например, устаревшие CSS-классы и неподдерживаемые настройки оформления.

При этом DX MCP намного шире дизайн-системы. В документации SLDS перечислены общие рекомендации, сведения о styling hooks и правила линтера. Styling hooks – предусмотренные системой CSS-переменные для настройки цветов, отступов, типографики и других свойств оформления. Сведения о них помогают агенту понять, какие параметры доступны и как использовать их в коде интерфейса. Установка линтера рядом ещё не доказывает, что он был автоматически запущен и проверил получившиеся файлы.

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

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

Когда интерфейс генерируется прямо во время использования

До сих пор речь шла об агенте, который помогает команде создавать или менять интерфейс продукта. К этому же направлению относятся MCP-серверы для SAPUI5 и Fiori elements. Они дают агентам знания о технологиях SAP, рекомендации и контекст проекта. Но дизайн-система может участвовать и в другом процессе – сборке интерфейса во время работы человека с продуктом.

Именно для этого SAP развивает Compositional Design System. По описанию SAP, специальный сервис учитывает запрос человека, выбирает компоненты из каталога, собирает из них интерфейс и проверяет его по применимым правилам. Результат отображается в работающем приложении. Команде не требуется заранее рисовать каждый возможный вариант экрана.

В каталоге есть базовые компоненты и композиции – описания того, как эти компоненты соединяются. Композицию можно изменить без нового компонентного кода, пока достаточно существующих элементов и возможностей рендерера – средства отображения интерфейса. Сходный принцип передачи интерфейса через описание используется в протоколе A2UI, который я разбирал в статье «A2UI – у Generative UI появился общий язык». Агент сообщает приложению, какие компоненты показать и как связать их с данными, а приложение отображает их средствами своей библиотеки.

Помимо самих элементов SAP хранит правила их выбора и сочетания. Здесь важна мысль, которую я разбирал в статье «DESIGN.md – это не список токенов». Агенту нужны основания для решения – когда компонент уместен и почему его следует использовать в конкретной ситуации.

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

Разница в том, кому и когда нужен результат. Агент-помощник создаёт код для команды, которая готовит продукт к выпуску. Агент внутри работающего продукта собирает интерфейс для человека, решающего свою задачу прямо сейчас. Одного подключения MCP для этого недостаточно – приложению нужны средства сборки и отображения такого интерфейса, а агенту – доступные компоненты и правила их применения.

В рассмотренных примерах дизайн-системы помогают агенту решать разные задачи. Mantine предоставляет документацию и инструкции. Blueprint связывает подготовку, сборку страницы и проверку кода в один процесс. SAP Compositional переносит сборку интерфейса в сам работающий продукт. Наличие MCP само по себе ещё не объясняет, какая из этих задач решена.

В работе над Omniground я тоже опирался на полезные решения других AI-ready дизайн-систем. Из этих примеров видно, что за каждой интеграцией стоят конкретные решения команды. Какие сведения агент получает до изменения кода, какие операции ему доступны, кто проверяет результат – всё это приходится продумывать и поддерживать вместе с компонентами.

Диалог с дизайн-системой тоже нужно проектировать – от вопросов, с которыми приходит агент, до проверки решений, которые он принял на основе её ответов.

Больше материалов ищите на моём канале о Немного Другом Дизайне с AI @someotherdesign