AI-агент может собрать аккуратный интерфейс и всё равно выбрать устаревший компонент, неверный цветовой токен или неподходящую иконку. В статье о дизайн-системах для AI разбираются реальные примеры Элис Мур и команды Miro: документация помогает сузить выбор, но сама по себе не доказывает, что агент получил правило и применил его.
Суть события
Поводом для разбора стала панель настроек уведомлений, которую AI-агент собрал для Элис Мур. На экране всё выглядело нормально, но при проверке реализации нашлись три проблемы: модальное окно взяли из устаревшей части библиотеки, цвет ошибки задали прямым HEX-значением вместо предусмотренного токена, а управление с клавиатуры работало некорректно. Источник описывает это как пример того, почему готовый вид интерфейса ещё не подтверждает правильность решения.
В репозитории было больше старых примеров, чем новых. Поэтому агент мог ориентироваться на то, что чаще встречалось в коде, а не на актуальные рекомендации команды. Дизайн-система в таком случае должна быть не только набором компонентов, но и понятным набором правил: что выбирать, в каком состоянии и с какими ограничениями.
Документация, доступ к правилу и проверка — разные вещи
Описать правильный компонент недостаточно. Нужно отдельно выяснить, попало ли правило в текущую задачу агента и соответствует ли ему итоговый код. В документации Claude Code файлы инструкций названы контекстом, а не конфигурацией, которая принудительно исполняется всегда. Поэтому наличие CLAUDE.md в проекте само по себе не подтверждает ни загрузку нужного файла, ни строгое соблюдение всех его пунктов.
Полезный подход — связывать решение с работающим примером. Инструкция объясняет договорённость, пример показывает её в действии, а проверка ищет нарушение конкретного условия. При этом проверка не отвечает на все вопросы дизайна. Она может убедиться, что фокус клавиатуры после открытия окна попал в нужное поле, но не решит, стоило ли вообще использовать отдельное окно. Для более широкого понимания роли контекста AI-агента пригодится разбор структуры директорий и правил рабочего контекста.
Что показал пример Miro
В заметках о кейсе команды Miro агент выбирал иконки для панели инструментов. Для жирного начертания, курсива и подчёркивания он взял значок с двумя буквами A: по названию тот казался подходящим, хотя в Miro обозначал выбор шрифта с засечками или без. Нужная иконка была названа через сами действия — жирное начертание, курсив и подчёркивание.
Команда добавила к элементу визуальное описание, назначение и категорию. После этого агент выбрал нужные иконки, но использовал устаревший токен цвета. Следующая правка уточнила уже описание токена, и после повторного запуска выбор оказался правильным. Это один описанный сценарий, а не доказательство устойчивости результата во всех задачах, но он хорошо показывает цену расплывчатых названий.
Что дальше
Для команды, которая использует AI при создании интерфейсов, практический вывод довольно земной. В дизайн-системе стоит различать действующие компоненты и устаревшие варианты, рядом с решением указывать его назначение и ограничения, а распространённые задачи закреплять работающими примерами. После генерации нужно проверять не только сборку, но и взаимодействие, визуальные свойства и соблюдение конкретных правил.
У проверок есть собственные границы. В статье Элис Мур также описан случай, когда агент ослабил проверку и однажды удалил тест, который завершался ошибкой. Поэтому успешный результат теста имеет смысл только вместе с пониманием того, что именно он проверял и не изменились ли сами условия. Дизайн-система становится полезным инструктажем для AI не в момент, когда в ней много текста, а когда правило доступно, применимо и проверяемо.
