Контекст дизайн-системы для ИИ: rules-файлы, MCP и что работает

Если ИИ-агент не знает вашу дизайн-систему, решение кажется очевидным: расскажите ему о ней. На практике передать агенту контекст дизайн-системы можно тремя способами, и каждый ломается по-своему. Rules-файл написать легко, но его выполнение никто не проверяет. Документация в промпте устаревает. Инструмент, который агент вызывает сам, даёт живые ответы, но они хороши ровно настолько, насколько хороши данные за ними.

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

Коротко

• Rules-файлы (AGENTS.md, CLAUDE.md, правила Cursor, инструкции Copilot) дают контекст, но ничего не обязывают. Документация Claude Code говорит об этом прямо.
• MCP позволяет агенту задавать вопросы вашей дизайн-системе прямо во время работы. Инструменты «управляются моделью», а ресурсы представляют собой контекст, который даёт приложение (спецификация MCP).
• GitHub Primer, Atlassian, Storybook и Figma выпустили MCP-серверы для своих дизайн-систем или данных дизайна.
• Проверка, которая ловит пропущенное, должна жить вне модели: в pull request.

Три способа дать агенту контекст

Rules-файлы

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

Ближе всего к общему стандарту AGENTS.md. Он описывает себя как «простой открытый формат для управления агентами, которые пишут код». По его данным, формат используют более 60 000 open-source-проектов. Сейчас за ним присматривает Agentic AI Foundation при Linux Foundation (Linux Foundation, 2025).

Файлы различаются и областью действия. Это важно для дизайн-системы, которая покрывает только часть репозитория:

• AGENTS.md может лежать в любой папке. Если подходят несколько файлов, «приоритет у ближайшего», а «явные запросы пользователя в чате перекрывают всё» (agents.md).
• Правила Cursor применяются в разных режимах: всегда, когда модель сочтёт их уместными, для файлов по шаблону или только при упоминании (Cursor).
• Copilot принимает в инструкциях для отдельных путей шаблон applyTo, поэтому UI-правила можно применить только к папкам компонентов (GitHub).

Правилу дизайн-системы место там, где лежит код интерфейса: в файле в папке приложения или в правиле, которое действует только на файлы компонентов.

Даже несколько строк уже помогают:

## UI
- Build UI from `@acme/ui`. Check its exports before writing a component.
- Never hard-code colours, spacing or radii. Use tokens from `@acme/tokens`.

Ограничение описано в документации самого Claude Code: CLAUDE.md задаёт «контекст, а не обязательную конфигурацию». Агент его читает, но ничто не заставляет агента следовать написанному. Та же документация советует держать каждый файл короче 200 строк.

Документация в промпте

Вставить документацию компонентов в контекст можно, и для одной задачи это сработает. Но такой подход не масштабируется: в дизайн-системе десятки компонентов с пропсами, вариантами и устаревшими частями. Поиск по документации решает проблему объёма, но ответ актуален только на момент последней индексации. А у вставленной вручную копии вообще нет способа обновиться.

Инструмент, который агент вызывает сам

В ноябре 2024 года Anthropic открыла исходный код Model Context Protocol как «новый стандарт подключения ИИ-ассистентов к системам, где живут данные» (Anthropic). Протокол даёт агентам стандартный способ вызывать инструменты во время задачи. Спецификация различает два вида того, что предлагает сервер:

• Инструменты «управляются моделью»: модель сама решает, когда их вызвать. Например, «найди компонент для кнопки с состоянием загрузки».
• Ресурсы «передают данные, которые служат контекстом для языковых моделей», и у каждого есть свой URI. Например, руководство по дизайн-системе, которое загружает клиент.

Дизайн-система ложится на оба вида: поиск и проверки становятся инструментами, а руководства и списки токенов ресурсами. Когда создавался Agentic AI Foundation, Linux Foundation насчитал больше 10 000 опубликованных MCP-серверов (Linux Foundation, 2025).

Что выпускают команды дизайн-систем

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

• GitHub Primer выпускает @primer/mcp, локальный сервер, «который подключает ИИ-инструменты к токенам, компонентам, паттернам, иконкам Primer и не только». Среди его инструментов есть find_tokens и lint_css (Primer).
• Atlassian публикует MCP-сервер (@atlaskit/ads-mcp) и CLI для своей дизайн-системы (Atlassian). В более позднем разборе команда сравнила их на «наборе реальных фронтенд-задач, каждая из которых оценивалась автоматически». CLI справился на 8% быстрее и потратил на 8% меньше токенов модели, чем MCP-сервер (Atlassian, 2026).
• Storybook выпустил MCP-дополнение, которое отдаёт агентам истории и документацию. Пока оно помечено как «в превью» (Storybook).
• Figma держит MCP-сервер для дизайн-файлов и пишет, что «Code Connect поддерживает согласованность сгенерированного кода с вашей кодовой базой» (Figma).

Мы читаем результат Atlassian так: транспорт важен меньше, чем структурированные и актуальные ответы для агента.

Эти серверы отвечают на вопросы агента, пока он пишет код. Совпадает ли результат с системой, нужно проверять отдельным шагом, и место этого шага в pull request.

Что работает: правила, живой инструмент и проверка в pull request

Каждый способ из таблицы где-то ломается. В рабочей схеме слабое место каждого слоя прикрывает следующий:

1. Короткий rules-файл, который указывает на настоящие источники: «сначала проверь @acme/ui; используй токены; спроси инструмент дизайн-системы, прежде чем писать компонент». Он дешёвый, но его никто не проверяет, поэтому детали в него класть не стоит.
2. Инструмент для живых ответов вместо вставленной документации, которая устаревает. Он ищет компоненты и сообщает уровень уверенности, отдаёт токены с их именами в коде и предлагает замены устаревшим компонентам. Агент спрашивает в тот момент, когда ему нужно принять решение.
3. Проверка вне модели, потому что инструмент хорош ровно настолько, насколько хороши его данные, а агент всё равно может его проигнорировать. Правила линтера и бот ревью в pull request ловят обходы, которые пропустили первые два слоя. Они одинаково работают для кода человека и ИИ. Шаблоны поиска есть в заметке о том, как найти зашитые цвета в кодовой базе React.

Третий слой ещё и даёт цифры. Число обходов в каждом pull request показывает, работают ли первые два слоя. Как это считать, показываем в руководстве по измерению здоровья дизайн-системы.

Где здесь FISYCO

Мы строим FISYCO на тех же трёх слоях. Его MCP-сервер отвечает по вашему собственному репозиторию и библиотекам в Figma:

• find_design_system_component возвращает кандидатов с уровнем уверенности;
• get_design_tokens возвращает токены с их именами в CSS и TypeScript;
• get_design_system_rules передаёт агенту правила команды;
• check_ui_code проверяет фрагмент кода до того, как он станет pull request, и выдаёт те же находки, что бот ревью оставляет в самом pull request.

Каждый вызов записывается в журнал, поэтому видно, как часто агенты переиспользовали систему и чего не нашли. Проблему, которую это решает, разбираем в статье «Почему ваш ИИ-агент не знает вашу дизайн-систему».