Элис Мур почти одобрила панель настроек уведомлений, которую собрал AI‑агент. На скриншоте всё выглядело нормально. Проблемы обнаружились, когда она проверила саму реализацию. Агент взял модальное окно из устаревшей части библиотеки, задал цвет ошибки напрямую HEX‑значением вместо предусмотренного для неё токена. Само окно некорректно работало при управлении с клавиатуры. (Источник: статья «How to Make AI Agents Follow Your Design System» для Builder).

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

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

Договорённости конкретной команды

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

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

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

Дизайн‑система для AI должна быть не только библиотекой компонентов, но и библиотекой правил.

Записано, доступно и применено

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

В документации Claude Code файлы инструкций прямо названы контекстом, а не принудительно исполняемым конфигом. Документация отдельно объясняет, как проверить загрузку файла, и отдельно разбирает случаи, когда, к примеру, Claude Code не следует инструкциям в документации. Наличие CLAUDE.md в проекте само по себе не подтверждает ни того, что нужный файл с инструкцией попал в текущую сессию, ни того, что Claude Code строго исполнит все правила.

Это описание конкретного инструмента. Но оно помогает разделить вопросы, которые часто сливаются в диалогах о степени зрелости и готовности дизайн‑системы к взаимодействию с AI‑агентами.

Есть ли нужное правило?
Получил ли его агент в этой задаче?
Соответствует ли ему результат?

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

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

Лично для себя я считаю инструкцию правильной, если она а) объясняет принятое решение и б) указывает, где искать его реализацию. Соответствие же сгенерированного интерфейса этому решению проверяется отдельно.

Когда описания меняют выбор

В канале Into Design Systems на Medium упоминается кейс дизайна панели инструментов от команды Miro. Агенту поручили собрать её из элементов дизайн‑системы, он выбрал неверные иконки для работы с текстом.

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

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

Схематическая реконструкция по описанию кейса Miro; не скриншот продукта и не точная копия его иконок. Две A обозначают выбор типа шрифта, а B/I/U связаны с жирным начертанием, курсивом и подчёркиванием. Источник: кейс Miro.

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

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

Название помогает найти элемент. Описание назначения помогает понять, подходит ли он для задачи.

У инструкции появляется опора в реализации

В статье для Builder, упоминавшейся в начале, Элис Мур предлагает держать работающие примеры распространённых задач и указывать агенту путь к ним. Когда она всего лишь переименовала свойство кнопки, работающий пример перестал собираться. Текстовая документация осталась прежней.

Часть правил можно усилить проверками. Они способны обнаружить использование устаревшего компонента, неподдерживаемое сочетание свойств или неправильный порядок перехода между элементами при работе с клавиатуры. Проверка может касаться взаимодействия и визуальных свойств, не ограничиваясь тем, компилируется ли код. Значение имеют конкретные условия, заложенные в проверку, и то, была ли эта проверка вообще запущена.

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

Инструкция должна быть частью дизайн‑системы

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

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

Если смотреть на дизайн‑систему как каталог инструкций для AI, то она помогает агенту в работе с решениями, принятыми в команде. Агенту меньше приходится догадываться о правилах по устаревшим legacy‑страницам и компонентам, которые ещё нужны для работы старых страниц.

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

Дизайн‑система как инструкция для AI