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

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

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

На первый взгляд кажется, что семантических токенов достаточно. Но они не отвечают на вопросы: какой алиас поставить на фон кнопки, какой на текст, что менять при hover, pressed или disabled, какой отступ у размера m, какое скругление у контейнера. Между семантикой и реальным компонентом остаётся пустота. Дизайнер выбирает стили в макете, но его решение не становится правилом для кода. Компонентные токены закрывают этот разрыв: они фиксируют правила в форме, понятной и дизайну, и разработке. Появляется больше контроля, но и больше ответственности — теперь нельзя сказать «разработчик как-то не так понял», потому что правило записано явно.

Чтобы не описывать всё вручную, мы построили процесс вокруг JSON-экспорта компонента из Pixso. Мы написали плагин, который выгружает техническое описание: имя, тип, размеры, состояния, настройки цвета, обводки, скрытые слои, вложенные элементы. Этот JSON отдаётся ИИ-агенту вместе с базовыми и семантическими токенами, файлом правил token_rules.md и примером-шаблоном. Агент разбирает экспорт, собирает структуру и предлагает алиасы. Финальное решение остаётся за дизайнером: нужно проверить архитектуру, смысл алиасов, спорные случаи и соответствие реальному поведению компонента.

Сам процесс состоит из семи шагов: сформировать JSON-экспорт через плагин; передать агенту экспорт, токены, правила и шаблон; получить черновик; проверить структуру, оси, состояния, алиасы, вложенность и лишние свойства; передать итоговый JSON разработчикам. ИИ берёт на себя механику, но проверка — за человеком.

Ключевое понятие — оси. Это размер, вариант, цветовая схема и состояние. Они формируют путь токена. Ветка размеров хранит геометрию, визуальная ветка строится в порядке: вариант ? цветовая схема ? состояние. От порядка осей зависит итоговое имя токена. Важно не добавлять искусственные оси. Если у компонента один размер, не нужно создавать группу размеров. Скрываемые слои вроде иконок или дополнительных элементов не становятся осями — они управляют видимостью и содержимым, а в токенах описываются как включённые по умолчанию.

После определения осей нужно наполнить ветки свойствами. Здесь важно записать только то, чем команда действительно хочет управлять. Оси отвечают на вопрос «для какой комбинации действует правило», а содержимое — «какое свойство и значение задаём». Затем каждому токену присваивается значение. В поле значения обязательно указываем существующий алиас, а не сырое HEX-значение. Если поставить исходный цвет, при изменении алиаса компонент не обновится. Цепочка должна сохраняться: компонентный токен ссылается на семантический, тот — на базовый.

Агент сопоставляет сырые значения из выгрузки с алиасами системы. Если совпадение однозначное, алиас подставляется автоматически. Если одному значению соответствуют несколько алиасов или точного совпадения нет, нужно проверять вручную. После генерации я загружала итоговый JSON в Tokens Studio — плагин для Figma, который помогает создавать и применять токены. Это удобнее, чем править в VS Code, особенно без опыта работы с кодом. Tokens Studio позволяет проверить, корректно ли подтягиваются алиасы, разрешаются ли ссылки, не воспринимает ли инструмент какое-то имя как служебное.

На первых генерациях ошибок было много. Но после четвёртого-пятого компонента структура устаканилась, и правок стало значительно меньше. Минимальный набор входных данных: компоненты в Pixso или Figma с правильными настройками; плагин для JSON-экспорта; готовый JSON базовых и семантических токенов; умение работать в Tokens Studio. В агентской среде мы создали проект с загруженными документами, на который чат ссылается постоянно: JSON базовых и семантических токенов, пример-шаблон самого сложного компонента и token_rules.md с правилами и ограничениями.

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

Теперь о подводных камнях. Первый — искусственная сложность. Если у компонента один размер, не нужно добавлять группу размеров. Структура без глубокой вложенности легче читается. Расширить токен всегда можно. То же с лишними контейнерами: если слой ничего не добавляет и дизайнер им не управляет, не надо превращать его в отдельную ветку. Токены должны помогать, а не создавать бюрократию.

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

Третий — не превращать каждое свойство в ось. Не все свойства из Pixso или Figma должны попадать в структуру. Свойства вроде видимости или замены иконки не создают отдельные оси. Они управляют содержимым, а не геометрией или цветом.

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

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

А вы пробовали автоматизировать создание компонентных токенов? Что помогло, а что стало узким местом?

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: