AI-first дизайн-системы

Один из примеров подхода на 2026 год — Astryx, open-source дизайн-система Meta на React (компонентная JS-библиотека для интерфейсов) и StyleX (система стилизации от Meta для строгой типизации CSS-свойств компонента). Компания обкатывала её внутри, а затем открыла как «agent-ready» (astryx.atmeta.com). Система пока в бете и требует React 19 или новее. Она напрямую отвечает на вопрос «как сделать дизайн-систему, которую не будет "галлюцинировать" ИИ-агент». Её решения полезно разобрать подробно, потому что это работающая практика, а не абстрактная теория. Пример ниже описан по публичным материалам на момент подготовки текста и содержит специфичные технические детали: конкретные флаги CLI, названия команд, ссылки на документацию. Как и с любым быстро развивающимся инструментом, сверяй конкретику с актуальной документацией перед тем, как применять.

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

Машиночитаемая документация вместо прозы. Агенту не приходится «парсить» текстовую документацию. CLI Astryx отдаёт структурированный JSON-манифест: полный список команд, аргументов, флагов и форматов ответа. Это похоже на OpenAPI-спецификацию для API, стандартный машиночитаемый способ описать, какие запросы принимает и что возвращает API. Агент читает данные, а не пытается понять маркетинговый текст.

CLI как единый интерфейс для человека и агента. Команда npx @astryxdesign/cli init --features agents генерирует файл AGENTS.md (или аналог под конкретный инструмент, например .cursorrules или .cursor/rules/*.mdc для Cursor) с индексом компонентов, поведенческими правилами и справочником команд. Дальше агент работает по одному и тому же API, что и разработчик-человек: astryx component Button, astryx template dashboard --skeleton, astryx manifest --json.

MCP-сервер. Дизайн-система хостит собственный MCP-сервер (astryx.atmeta.com/mcp). К нему может подключиться любой совместимый агент (Claude Code, Cursor и другие) и «вживую» запрашивать компоненты и документацию. Носить весь объём доков в контекстном окне вручную не нужно.

Обязательный трёхшаговый сценарий работы. Документация буквально учит агента не выдумывать структуру с нуля, а идти по шагам. Сначала подобрать готовый шаблон страницы под идею (astryx build "<идея>"). Затем развернуть этот шаблон в проекте (astryx template <name> <path>). И только потом читать свойства конкретного компонента (astryx component <Name>).

Плотный, а не «дружелюбный» формат вывода. Флаг --dense у каждой команды убирает форматирование, рассчитанное на человеческий глаз, и оставляет максимум информации на минимум токенов. Контекстное окно агента ограничено и «дорого», и вежливая многословная документация в нём — потерянное место.

Явные ограничения и антипаттерны прямо в инструкции для агента. Сгенерированный AGENTS.md содержит не только «что можно», но и жёсткие «нельзя»: не использовать голые <div>, не писать инлайн-стили, не подставлять «магические» значения вместо дизайн-токенов.

Composition hints в самом коде. Компоненты сопровождаются JSDoc-аннотациями с примерами правильной композиции. JSDoc — стандартный формат комментариев прямо в коде, который описывает, как использовать функцию или компонент, и который умеют читать и человек, и инструменты. Это не просто список пропсов, а готовые паттерны их совместного использования. Так агент не изобретает сочетания, которые в системе не предусмотрены.

Astryx — показательный, но не единственный способ решить задачу. Три инструмента ниже полезно знать отдельно от конкретного кейса. Они применимы к любой дизайн-системе, а не только к готовым agent-ready системам вроде Astryx:

Storybook и Storybook MCP. Storybook — давно устоявшийся инструмент, где каждый компонент дизайн-системы живёт как изолированная, документированная «карточка» со всеми своими вариантами и состояниями. Исторически он собирался для человека-разработчика, который выбирает нужный компонент глазами. Storybook MCP превращает ту же самую информацию в источник, доступный агенту напрямую по протоколу MCP (тема «Софт: справочник по инструментам»). Агент может запросить, какие компоненты вообще есть и какие у них варианты. Ему не нужно полагаться на то, что он помнит о проекте из контекста разговора, или придумывать компонент заново. Для команды, у которой уже есть Storybook, это часто более быстрый путь к «agent-ready» состоянию, чем строить собственную CLI-обвязку с нуля, как сделала Astryx.

Figma Code Connect. Отдельная функциональность Figma, которая явно связывает конкретный компонент в Figma-файле с конкретным компонентом в реальном кодовом репозитории. Это не просто «похожее имя», а прямая, декларативная привязка. Когда агент через Figma MCP (тема «Вайбкодинг: интерфейсы») читает макет, Code Connect подсказывает ему не «нарисуй что-то похожее на эту кнопку», а «здесь используется именно вот этот Button из вот этого файла с вот такими пропсами». Это тот же принцип «золотых примеров» и «одного источника правды», что и в остальной части темы, только встроенный прямо в Figma, а не собранный вручную. Code Connect есть только на планах Organization и Enterprise; удалённый Figma MCP читает файлы на любом плане, а для записи нужно Full-место.

Общий контекст для всей команды, а не для одного человека. Отдельного инструмента для этого не нужно, достаточно дисциплины. Всё, на что должен опираться агент (AGENTS.md, токены, «золотые примеры» — см. ниже), лежит в репозитории рядом с кодом, а не в личных настройках или в истории чата одного человека. Тогда агент у любого участника команды, в терминале, в IDE или в облачной сессии, стартует с одного и того же актуального контекста. А изменения правил проходят обычное ревью, как любой другой код.

Чужие системы с документацией и компонентами, на которых удобно показывать агенту «хочу так», собраны в Design Systems Surf — это 100+ систем, базовый просмотр бесплатный. Там видно, как разные команды решают именование, токены и документирование компонентов.

Практика Astryx решает в основном инженерную сторону вопроса. Но дизайн-система — в первую очередь дизайнерский артефакт. Вот несколько соображений, которые лучше продумать именно тебе, а не оставлять на откуп разработчикам:

Именование — дизайнерское решение, а не только техническое. Если у компонента есть двусмысленное или «милое» имя вроде SuperCard рядом с обычным Card, агент рано или поздно перепутает их или смешает пропсы одного с другого. Участвуй в согласовании номенклатуры компонентов на этапе создания библиотеки в Figma. Теперь это не только вопрос эстетики нейминга, а вопрос надёжности всей системы под ИИ-агентами.

Токены как единственный источник правды, синхронизированный, а не задокументированный отдельно. Мало написать «используйте токены» в гайдлайне. Если Figma Variables и токены в коде синхронизируются вручную и расходятся, агент в какой-то момент получит из Figma MCP (тема «Вайбкодинг: интерфейсы») значение, которого уже нет в коде, и наоборот. AI-first подход требует одного машиночитаемого источника (JSON/YAML), из которого генерируются и стили Figma, и токены кода. Записать переменные в Figma агент теперь может через Figma MCP (нужно Full-место, см. «Вайбкодинг: интерфейсы»), но для постоянной двусторонней синхронизации с кодом всё равно нужна связка: в Figma — плагин Tokens Studio или Variables REST API (только Enterprise), в код — Style Dictionary.

«Золотые примеры» вместо исчерпывающей документации. Агенты гораздо надёжнее копируют паттерн из одного качественного, полного примера («вот как выглядит правильно собранная страница дашборда»), чем реконструируют его из абстрактного перечисления всех возможных пропсов по отдельности. Дизайн-система выигрывает не от максимально подробных доков, а от небольшого набора канонических, кураторски выверенных «шаблонов страниц». Ровно это Astryx и делает через template --skeleton. Закладывай такие шаблоны в дизайн-систему с самого начала, а не добавляй постфактум.

Гардрейлы как линтинг, а не только как текст инструкции. Агент может проигнорировать написанные в AGENTS.md правила, особенно в длинной сессии, где эти инструкции «выпадают» из контекстного окна (тема «Фундамент»). Поэтому дублируй правила в виде автоматической проверки. Это может быть ESLint/stylelint (программы, которые автоматически проверяют код на соответствие правилам стиля и находят ошибки ещё до запуска) или git-хук (скрипт, который автоматически запускается на определённом шаге git, например перед коммитом, и может его заблокировать). Такая проверка блокирует коммит с инлайн-стилями или произвольным хекс-цветом независимо от того, помнит ли агент про правило в моменте.

Отдельный «агентский» changelog. Люди читают release notes. Агенты не читают, если их специально не научить. Имеет смысл вести версионированный, структурированный лог breaking changes специально для агентов: «проп size переименован в variant, старое значение large теперь lg». Формат должен быть таким, чтобы его можно было скормить агенту при апгрейде зависимости. Тогда он сам мигрирует использования, а не сломает полсистемы одним npm update.

QA-петля именно для ИИ-сгенерированного UI. Раз агент собирает интерфейсы быстро, ревью должно поспевать за этой скоростью. Полезен скрипт, который сравнивает финальные стили с токенами и подсвечивает любое «отвязанное» значение (захардкоженный цвет, случайный отступ) для ручной или второй агентской проверки перед мерджем. Это прямое продолжение темы из темы «Оценка и критика результатов ИИ», применённое конкретно к дизайн-системе.

Всё выше — практика компаний вроде Meta с инженерной командой, которая может позволить себе собственный CLI и MCP-сервер. У соло-дизайнера или фрилансера без разработчиков ничего из этого арсенала может не быть. Это не повод откладывать AI-first подход до «когда-нибудь появится команда». Минимально жизнеспособная версия того же принципа умещается в три файла, которые заводятся за один вечер:

• Один CLAUDE.md/AGENTS.md в корне проекта с конвенциями именования, палитрой и явными «нельзя». У Astryx это генерируется CLI-командой, а здесь просто пишется руками один раз и обновляется по ходу проекта.
• Один файл с токенами (tokens.json или даже просто список в том же CLAUDE.md: цвета в hex, отступы, радиусы). Это единственный источник правды, который агент читает вместо того, чтобы каждый раз подставлять случайные значения.
• Два-три «золотых примера» — не абстрактное описание компонентов, а сохранённый код одной уже хорошо собранной страницы или экрана, на который агент явно может ссылаться: «собери новую страницу в точности как страница из golden-example.tsx, только с другим контентом».

Заведи в этом проекте CLAUDE.md с нашими конвенциями: палитра [вставить hex-коды], отступы [вставить шкалу], шрифты [вставить]. Явно пропиши «нельзя»: не хардкодить цвета, не писать инлайн-стили, не использовать голые div вместо компонентов из shadcn/ui. Возьми за образец вот эту страницу (вставить путь/код) как golden example и сошлись на неё в файле

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

Вот список компонентов моей дизайн-системы (вставить). Проверь имена на двусмысленность — есть ли пары, которые ИИ-агент может перепутать?

Сгенерируй пример AGENTS.md-файла для нашей дизайн-системы: какие правила обязательно включить, чтобы агент не собирал вёрстку на голых div и инлайн-стилях

Опиши, как я мог бы синхронизировать переменные из Figma с токенами в коде, чтобы у обеих сторон был один источник правды

Помоги составить структуру "агентского" changelog для дизайн-системы: какие поля обязательны для каждой записи о breaking change

У нас уже есть Storybook, но нет agent-ready CLI как у Astryx — с чего начать, чтобы агент мог опираться на Storybook напрямую через MCP?

Объясни простыми словами, чем Figma Code Connect отличается от простого совпадения имён компонентов в Figma и в коде