Дизайн-система для работы с AI

AI-инструменту для разработки нужна не более красивая библиотека компонентов, а меньше скрытых решений. Всё, что существует только в памяти дизайнера, превращается в догадку: какой серый цвет является семантическим, может ли карточка содержать действие, что происходит на ширине 720 пикселей и как ведёт себя блок без изображения.

Референс Design For AI в Refframe выглядит просто, но для точной реализации всё равно нужны данные, которых нет на скриншоте: файлы шрифта, ширина контента, адаптивная шкала, поведение круглой графики, семантика заголовка и настройки уменьшения движения. Скриншот - доказательство, но не полный контракт.

Определите единый источник для каждого решения

Решите, где живёт каждый тип истины. Токены могут храниться в версионируемом JSON. API компонентов - в коде. Figma остаётся источником композиции и утверждённых вариантов. Контентные и accessibility-правила находятся в документации. Источники должны совпадать, а агент должен знать, какой из них приоритетен при расхождении.

Составьте короткую карту:

• файлы токенов и сгенерированные форматы;
• каталоги компонентов и публичные exports;
• stories и примеры;
• шаблоны страниц;
• источники иконок и шрифтов;
• команды lint, types, tests, build и screenshots;
• владельцы и границы ревью.

Не добавляйте всю историю дизайн-системы в каждый промпт. Дайте компактную карту, затем укажите файлы, относящиеся к задаче.

Экспортируйте типизированные семантические токены

Машиночитаемому токену нужны устойчивое имя, явный тип, значение, описание и алиасы. Формат Design Tokens Community Group описывает типизированные данные и ссылки между токенами. В версии 2025.10 тип должен быть указан явно: инструменту не следует угадывать его по значению.

Разделяйте примитивный и семантический уровни. Примитив хранит blue-600. Семантический action-background-primary ссылается на него. Компоненты по возможности используют семантическую роль, поэтому смена темы не переписывает назначение.

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

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

Описывайте компонент как интерфейс

Для каждого публичного компонента укажите:

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

Скриншот четырёх кнопок не объясняет, является destructive уровнем иерархии, визуальным тоном или типом действия. Контракт объясняет. Используйте одинаковые названия в Figma и коде либо поддерживайте явную таблицу соответствий.

Зафиксируйте границы реализации. Если в проекте уже есть Button, новые экраны должны использовать его, а не создавать копию CSS. Если иконки берутся из одной библиотеки, назовите её. Если шириной контейнера управляет layout-примитив, укажите путь.

Опишите адаптивное поведение

Запишите контейнеры, колонки, gaps, минимальные и максимальные размеры, а также трансформации на брейкпоинтах. Поведение важнее списка координат десктопного макета.

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

Отделяйте правило продукта от исключения одной страницы. Агент должен понимать, является ли крупный hero-заголовок системной ролью или специальным приёмом кампании.

Добавьте контентные и accessibility-ограничения

Компоненты чаще ломаются на настоящем контенте, чем на аккуратных плейсхолдерах. Передайте ожидаемую длину заголовков, локализацию, empty и error states, пропорции изображений, правила обрезки и перенос действий.

Опишите семантический HTML, клавиатурное управление, видимый focus, labels, reduced motion и требования контраста. Это влияет на структуру компонента и не должно откладываться до визуальной полировки.

Покажите принятый и отклонённый результат

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

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

Включите проверку в контракт

Anthropic рекомендует давать Claude Code проверяемые критерии: тесты, скриншоты и ожидаемый результат. Для интерфейса полезна такая последовательность:

1. запустить type check, lint и целевые тесты;
2. отрисовать нужные состояния на заданных ширинах;
3. сравнить скриншоты с утверждённым дизайном;
4. проверить длинный контент, focus, ошибки и отсутствие медиа;
5. перечислить оставшиеся визуальные различия;
6. отправить новые паттерны и токены на человеческое ревью.

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