У меня в проекте все те кейсы встречаются, которые вы описали. Видов (компонентов) модальных окон - 90 штук, а мест где они вызываются наверное где-то под 200. Проекте правда на vue3
Есть только один вопрос, возможно ламерский, но все же.
Все так и есть. В моем случае, у меня в районе 90 UI компонентов из ui-kit либы. Поддерживать их актуальность путем постоянного обновления root файла с инструкциями для LLM - тяжело.
А теперь можно просто генерировать/обновлять документацию по этим компонентам каждый раз, когда в них что-то меняется и хранить рядом в проекте. Для генерации (и в примере выше) для vue vue-docgen-api. Для React есть тоже хорошая либа
Согласен, что хорошо написанный код является отличной документацией. В случае с кодом собственного проекта иногда этого достаточно. Но я заметил, что когда начал документировать баги собственного проекта в виде задач, он начал лучше решать "похожие" случаи.
А в случае, если информация об интерфейсах API лежит например в сваггере на сервере у бэкендеров, или например метаданные о багах сервера в Sentry, то тут LLMке будет прям сильно легче получить более точную информацию о том, что нужно делать дальше.
Приветствую, поделюсь своим опытом, на примере редактора Cursor
Представим, что вы уже подключили существующий mcp сервер (или создали свой). Пример от меня также есть на Github
1) Нужно добавить интерфейс для подключения в .cursor/mcp.json
"ui-kit": {
"command": "npx", // команда для запуска вашего сервера на node js
"args": [ // аргументы для запуска сервера
"tsx",
"mcp/mcp-ui-kit-server/src/server.ts"
],
"cwd": "" // опционально, указываем путь из какой папки запустить команду
}
Допустим, ваш MCP сервер реализует следующий интерфейс для чтения LLMкой (иначе говоря - tools)
| `uikit_list_components` | Список компонентов (фильтр по пакету, категории) | Обзор доступных компонентов |
| `uikit_get_component` | Детали компонента (props, events, slots) | Понять API компонента перед использованием |
| `uikit_search` | Поиск по имени, описанию, категории | Найти нужный компонент |
| `uikit_list_icons` | Список иконок с группировкой | Найти нужную иконку |
| `uikit_generate_usage` | Генерация примера использования | Быстро получить код для копирования |
| `uikit_stats` | Статистика документации | Обзор UI Kit |
После чего, проверяете конфигурацию (что все корректно подключено) в настройках Cursor. `Settings - Cursor Settings - Tools & MCP. Там примерно такая картина должна быть, если статус зеленый - значит Cursor успешно запустил ваш сервер, и все корректно работает.
2) Дальше, в корне файла в AGENTS.md жестко указываете инструкцию, что в случае если задача касается верстки или создания каких-то компонентов использовать mcp-ui-kit-server с развернутым описанием выше указанных tools.
Это кстати можно дополнительно сделать в самой реализации MCP сервера - там есть поле description . Но для примера, скину как эта инструкция реализована у меня.
#### 4. 🎨 mcp-ui-kit-server — Документация UI компонентов
MCP сервер на Node.js для работы с документацией Vue UI компонентов. Предоставляет информацию о props, events, slots компонентов из `@package/ui` и `@package/ai-kit`.
| Инструмент | Описание | Когда использовать |
|------------|----------|-------------------|
| `uikit_list_components` | Список компонентов (фильтр по пакету, категории) | Обзор доступных компонентов |
| `uikit_get_component` | Детали компонента (props, events, slots) | Понять API компонента перед использованием |
| `uikit_search` | Поиск по имени, описанию, категории | Найти нужный компонент |
| `uikit_list_icons` | Список иконок с группировкой | Найти нужную иконку |
| `uikit_generate_usage` | Генерация примера использования | Быстро получить код для копирования |
| `uikit_stats` | Статистика документации | Обзор UI Kit |
**Документируемые пакеты:**
- `@package/ui` — Основная библиотека UI компонентов
- `@package/ai-kit` — Компоненты для AI функциональности
**Примеры использования:**
```
# Список компонентов форм
uikit_list_components(category: "form")
# Список компонентов из ai-kit
uikit_list_components(package: "ai-kit")
# Детали компонента AppButton
uikit_get_component(name: "AppButton")
# Поиск компонентов для модальных окон
uikit_search(query: "modal")
# Список иконок действий
uikit_list_icons(category: "actions")
# Пример использования компонента
uikit_generate_usage(name: "AppInput", framework: "vue")
```
**Когда использовать:**
1. Перед использованием UI компонента — проверь его API через `uikit_get_component`
2. При поиске подходящего компонента — используй `uikit_search` или `uikit_list_components`
3. При работе с иконками — используй `uikit_list_icons`
4. Для быстрого старта — генерируй примеры через `uikit_generate_usage`
---
### 🎯 Стратегия использования MCP серверов
// Тут у меня также указаны инструкции и для других MCP серверов.
5. **При работе с UI компонентами:**
- `uikit_get_component` — узнать API компонента (props, events, slots)
- `uikit_search` — найти подходящий компонент
- `uikit_list_icons` — найти нужную иконку
- `uikit_generate_usage` — получить пример использования
Пример реализации MCP сервера для ui-kit, есть на Github (в статье также есть ссылка)
Также, можно попросить агента тестово запустить команды, что все работает. В Cursor это выглядит вот так
Опять же, исходя из вашего проекта и запросов - инструкции могут быть разными. Нужно играться с инструкциями до тех пор, пока не добьете желаемого результата. Прямо как с джунами в вашей команде =))
Вы в целом правы, но я тут имел ввиду немного другое.
MCP функционал здесь скорей нужен для более "глубокого" погружение в историю проекта. Смысл внутренней базы знаний не в том чтобы описать где/какие папки/сервисы лежат.
А в том, чтобы у LLM была возможность запросить по ключевым словам список уже известных багов в проекте (которые были решены).
Это работает в целом как поиск в каком нибудь трекере jira по задачам/багам. Но в моем случае - трекера нет, и нужно все это хранить в какой-то базе (она может быть любой, но в моем случае это просто папка .local-kb/ Для наглядности приведу пример:
1) Вы получаете багу, фиксите ее. 2) Заводите файл .local-kb/bugs/incorrect-safari-font-renderer-2025-12-28.md 3) Внутри этого файла, примерное такое содержание
---
id: bug-YYYY-MM-DD-short-name
type: bugfix
title: Название бага
date: YYYY-MM-DD
status: completed
tags: []
apps: []
packages: []
files: []
related: []
---
# Название бага
## 🐛 Проблема
Описание проблемы и как она проявлялась.
## 🔍 Причина
Корневая причина бага.
## ✅ Решение
Как был исправлен баг.
## 🧪 Как воспроизвести (было)
Шаги для воспроизведения до фикса.
И при решение задач в будущем, LLM будет опираться на информацию связанную с этой задачей. (Если scope новой баги/задачи попадет под нее).
Поэтому появляется огромный смысл документировать все, что вы делаете в проекте не только в виде кода/комментариев.
Ставлю жирный плюс. Сколько я спецов упустил в 2018-2022 годах, когда мы с HR искали людей на рынке.
Находишь кандидата (кое-как, так как жуткий голод был на кандидатов), общаешься с ним, вроде со всем все решаете, выписываешь оффер (по рынку примерно это было 220к на фронтенд-миддла), с учетом опыта разработчика. И это было в рынке зпшек тех времен.
А потом он приходит с оффером от сбера на 290к, и говорит что пойдет к нам только если мы дадим столько же или больше. И таких случаи были постоянно.
И ведь я уверен, что эти люди шли на нафиг никому не нужные проекты.
Из разряда: Если в контр-страйк вы выбираете играть за контр-террористов, то из вас получится отличный полицейский
Спасибо большое за статью, откликнулось)
У меня в проекте все те кейсы встречаются, которые вы описали. Видов (компонентов) модальных окон - 90 штук, а мест где они вызываются наверное где-то под 200. Проекте правда на vue3
Есть только один вопрос, возможно ламерский, но все же.
Пример из статьи:
В этом случае, разве реактивность у
productIdне теряется? А что если пока была открыта модалка, стейт поменялся?Все так и есть. В моем случае, у меня в районе 90 UI компонентов из ui-kit либы. Поддерживать их актуальность путем постоянного обновления root файла с инструкциями для LLM - тяжело.
А теперь можно просто генерировать/обновлять документацию по этим компонентам каждый раз, когда в них что-то меняется и хранить рядом в проекте. Для генерации (и в примере выше) для vue vue-docgen-api. Для React есть тоже хорошая либа
Идея для стартапа ). Вообще, я как раз делаю что-то подобное, в следующей статье опишу это, и выложу исходный код для пользования.
Согласен, что хорошо написанный код является отличной документацией. В случае с кодом собственного проекта иногда этого достаточно. Но я заметил, что когда начал документировать баги собственного проекта в виде задач, он начал лучше решать "похожие" случаи.
А в случае, если информация об интерфейсах API лежит например в сваггере на сервере у бэкендеров, или например метаданные о багах сервера в Sentry, то тут LLMке будет прям сильно легче получить более точную информацию о том, что нужно делать дальше.
Приветствую, поделюсь своим опытом, на примере редактора Cursor
Представим, что вы уже подключили существующий mcp сервер (или создали свой). Пример от меня также есть на Github
1) Нужно добавить интерфейс для подключения в
.cursor/mcp.jsonДопустим, ваш MCP сервер реализует следующий интерфейс для чтения LLMкой (иначе говоря - tools)
После чего, проверяете конфигурацию (что все корректно подключено) в настройках Cursor. `Settings - Cursor Settings - Tools & MCP. Там примерно такая картина должна быть, если статус зеленый - значит Cursor успешно запустил ваш сервер, и все корректно работает.
2) Дальше, в корне файла в
AGENTS.mdжестко указываете инструкцию, что в случае если задача касается верстки или создания каких-то компонентов использовать mcp-ui-kit-server с развернутым описанием выше указанных tools.Это кстати можно дополнительно сделать в самой реализации MCP сервера - там есть поле
description. Но для примера, скину как эта инструкция реализована у меня.Пример реализации MCP сервера для ui-kit, есть на Github (в статье также есть ссылка)
Также, можно попросить агента тестово запустить команды, что все работает. В Cursor это выглядит вот так
Опять же, исходя из вашего проекта и запросов - инструкции могут быть разными. Нужно играться с инструкциями до тех пор, пока не добьете желаемого результата. Прямо как с джунами в вашей команде =))
В любом случае спасибо за время, что вы мне уделили) Пока возможно действительно есть проблемы с качеством написания, буду стараться.
Приветствую, спасибо что уделили время)
Вы в целом правы, но я тут имел ввиду немного другое.
MCP функционал здесь скорей нужен для более "глубокого" погружение в историю проекта. Смысл внутренней базы знаний не в том чтобы описать где/какие папки/сервисы лежат.
А в том, чтобы у LLM была возможность запросить по ключевым словам список уже известных багов в проекте (которые были решены).
Это работает в целом как поиск в каком нибудь трекере jira по задачам/багам. Но в моем случае - трекера нет, и нужно все это хранить в какой-то базе (она может быть любой, но в моем случае это просто папка
.local-kb/Для наглядности приведу пример:1) Вы получаете багу, фиксите ее.
2) Заводите файл
.local-kb/bugs/incorrect-safari-font-renderer-2025-12-28.md3) Внутри этого файла, примерное такое содержание
И при решение задач в будущем, LLM будет опираться на информацию связанную с этой задачей. (Если scope новой баги/задачи попадет под нее).
Поэтому появляется огромный смысл документировать все, что вы делаете в проекте не только в виде кода/комментариев.
Ставлю жирный плюс. Сколько я спецов упустил в 2018-2022 годах, когда мы с HR искали людей на рынке.
Находишь кандидата (кое-как, так как жуткий голод был на кандидатов), общаешься с ним, вроде со всем все решаете, выписываешь оффер (по рынку примерно это было 220к на фронтенд-миддла), с учетом опыта разработчика. И это было в рынке зпшек тех времен.
А потом он приходит с оффером от сбера на 290к, и говорит что пойдет к нам только если мы дадим столько же или больше. И таких случаи были постоянно.
И ведь я уверен, что эти люди шли на нафиг никому не нужные проекты.
Пока очень сыровато к сожалению, страница гарантировано крашится, если банально тыкнуть в ячейку, нажать CmdOrCtrl+A, а затем CmdOrCtrl+C.
Чтобы потом вылить в production баг с header'ом. (Наведите на пункт каталог, потом наведите мышку на один из выпадающих пунктов, и скрольте вниз)