Все статьи

21 сентября 2026 г.

Структура метаданных 1С и контекст для Cursor Rules: как остановить 10-кратный перерасход токенов

Почему типовые конфигурации 1С ломают ИИ-ассистентов

Типовая ERP 2.5 в XML-выгрузке — это 6–9 ГБ файлов, 180 000+ объектов метаданных и сотни тысяч строк на BSL. Розничная УТ 11.5 — стабильно 3–5 ГБ. ЗУП 3.1 — 2,5 ГБ. Скормить это Cursor, Claude Code или Windsurf целиком физически невозможно: контекстное окно даже у 200k-моделей сжимается до нескольких тысяч строк, а стоимость запроса улетает в космос. Разработчик получает агента, который путает Ссылка.Заполнить() с ЗаполнитьЗначенияСвойства(), выдумывает несуществующие реквизиты и переписывает код, который в конфигурации уже есть.

Решение начинается с понимания структуры метаданных и правильной организации контекста через Cursor Rules и MCP.

Как реально устроена структура метаданных 1С в XML

Каждая выгрузка подчиняется строгой иерархии. Корневой файл — Configuration.xml, от него расходятся ветки по видам объектов.

Configuration.xml
├── Catalogs/Справочники.xml
│   └── Номенклатура/
│       ├── Номенклатура.xml         # реквизиты, формы, TabularSections
│       └── Ext/ObjectModule.bsl     # модуль объекта
├── Documents/Документы.xml
│   └── РеализацияТоваровУслуг/
│       ├── Формы/ФормаДокумента/Ext/Form/Module.bsl
│       └── Ext/ManagerModule.bsl
├── CommonModules/ОбщиеМодули.xml
│   └── ОбщегоНазначения/Ext/Module.bsl
└── Subscriptions/ПодпискиНаСобытия.xml

Каждый XML-файл метаданных содержит десятки тысяч строк описания свойств: синонимы на трёх языках, типы, связи, роли, права. Только описание одного справочника Номенклатура в ERP занимает более 40 000 строк XML. Формулы в модулях при этом импортируются через #Область, #Если Сервер и подключают общие модули, о которых агент не знает.

Ключевая проблема: полезной для агента информации в этих гигабайтах — 1–2%. Остальное — мета-описания, GUID, локализации и закомментированный код.

Почему обычный .cursorrules для 1С не работает

Классический подход выглядит так: разработчик пишет .cursorrules, вставляет туда имена общих модулей и надеется, что агент поймёт. Реальность:

# .cursorrules — антипример
- Используй ОбщегоНазначения.ЗначениеРеквизитаОбъекта()
- Соблюдай стандарты 1С:Предприятие 8.3
- Все запросы писать на языке запросов 1С

Агент видит правило, но не видит сигнатуру метода, не знает, какие реквизиты есть у объекта, не понимает подписки на события. Итог — галлюцинации и компиляционный бред. Даже если засунуть в контекст модуль целиком, он потянет за собой весь клубок зависимостей.

Контекст для Cursor Rules: три уровня, которые нужно разделять

Правильно организованный контекст для 1С строится на трёх слоях, и Cursor Rules должен явно указать агенту, как их использовать.

| Уровень | Что содержит | Размер | Как подавать агенту |
|---|---|---|---|
| Статический (правила) | Стандарты, стиль, конвенции проекта | 2–5 КБ | Всегда в .cursorrules |
| Структурный (граф метаданных) | Объекты, реквизиты, подписки, типы | 1–3 МБ | По запросу через MCP |
| Динамический (код) | Модули, формы, запросы | 10–500 МБ | Только точный срез |

Ключ к экономии — не грузить структурный и динамический уровни в rules, а дать агенту инструмент для точечного запроса. Именно это делает MCP-сервер.

MCP-сервер Графон: локальный граф знаний по конфигурации

Графон (https://grafonbase.ru) — локальный инструмент и MCP-сервер, который один раз индексирует XML-выгрузку 1С и строит граф зависимостей: метаданные → модули → методы → вызовы → подписки → запросы. После индексации ИИ-агент обращается не к файлам, а к графу — и получает ровно те сущности, которые релевантны задаче.

Схема работы:

Cursor/Claude Code → MCP-запрос → Графон (локальный граф)
                                     ├── точный срез модулей
                                     ├── сигнатуры методов
                                     ├── связи реквизитов
                                     └── подписки на события
                ← контекст 5–20 КБ вместо 500 МБ

Пример MCP-запроса от агента, когда пользователь просит доработать проведение документа:

{
  "tool": "grafon.resolve_context",
  "arguments": {
    "entry_point": "Document.РеализацияТоваровУслуг.ObjectModule",
    "include": ["calls", "subscriptions", "query_refs"],
    "depth": 2,
    "max_tokens": 12000
  }
}

Ответ Графона — компактный JSON с сигнатурами и телами только тех методов, которые реально вызываются из модуля проведения. Никаких XML, никаких локализаций, никаких чужих подсистем.

Сравнение: без Графона vs с Графоном

Тест на реальной ERP 2.5, задача «добавить контроль остатков в проведение документа РеализацияТоваровУслуг».

| Метрика | Без MCP (сырой контекст) | С Графоном | Выигрыш |
|---|---|---|---|
| Токенов на запрос | 180 000 | 14 500 | ×12,4 |
| Стоимость запроса (Sonnet) | ~$0,55 | ~$0,045 | ×12 |
| Время ответа агента | 90–140 с | 8–14 с | ×9 |
| Галлюцинации методов | 6–10 на сессию | 0–1 | — |
| Точность попадания в реквизиты | 62% | 98% | +36 п.п. |

Практика: настройка проекта 1С под Cursor + Графон

  1. Выгружаете конфигурацию в XML: Конфигуратор → Администрирование → Выгрузить конфигурацию в файлы.
  2. Запускаете индексацию Графона — он строит граф за 3–15 минут в зависимости от размера.
  3. Регистрируете MCP-сервер в Cursor:
{
  "mcpServers": {
    "grafon": {
      "command": "grafon-mcp",
      "args": ["--project", "./erp_xml", "--cache", ".grafon"]
    }
  }
}
  1. Пишете .cursorrules, который явно требует от агента работать через Графон:
# Правила проекта 1С:ERP 2.5
Перед любым изменением BSL-кода вызови MCP-инструмент grafon.resolve_context.
Запрещено угадывать сигнатуры — только данные из графа.
Для поиска аналогов используй grafon.find_similar_methods.
Стиль: стандарты 1С, отступы табами, комментарии перед процедурами.

Теперь агент физически не может «придумать» метод: он либо находит его в графе, либо честно сообщает, что сущность отсутствует.

BSL-пример: как выглядит корректный контекст после резолва

Когда агент получает от Графона срез модуля проведения, он видит только нужную процедуру и её ближайшие зависимости:

&НаСервере
Процедура ОбработкаПроведения(Отказ, РежимПроведения) Экспорт
    // Контроль остатков — добавлено через Grafon context
    Если Не ПроверитьОстаткиНоменклатуры(Отказ) Тогда
        Возврат;
    КонецЕсли;
    
    Движения.Товары.Записывать = Истина;
    Для Каждого СтрокаТовары Из Товары Цикл
        Движение = Движения.Товары.Добавить();
        Движение.Период = Дата;
        Движение.Номенклатура = СтрокаТовары.Номенклатура;
        Движение.КоличествоРег = -СтрокаТовары.Количество;
    КонецЦикла;
КонецПроцедуры


&НаСервере
Функция ПроверитьОстаткиНоменклатуры(Отказ)
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "ВЫБРАТЬ ТоварыОстатки.Номенклатура, ТоварыОстатки.КоличествоОстаток
     |ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки() КАК ТоварыОстатки
     |ГДЕ ТоварыОстатки.Номенклатура В (ВЫБРАТЬ Товары.Номенклатура ИЗ Документ.РеализацияТоваровУслуг.Товары КАК Товары)";
    // ...
КонецФункции

Агент не выдумывает Движения.Товары.Пересчитать(), потому что видит реальный набор свойств регистра из графа.

Итог

Структура метаданных 1С принципиально «враждебна» к LLM: объём XML в сотни раз превышает полезный сигнал. Правильный ответ — не пытаться ужать rules до бесконечности, а разнести контекст по слоям и дать агенту MCP-инструмент. Локальный граф зависимостей, который строит Графон, превращает 180 000 токенов сырого контекста в 14 000 релевантных, устраняет галлюцинации и снижает стоимость одной итерации агента более чем на порядок. Для команд, работающих с ERP, УТ, ЗУП и КА, это не оптимизация, а обязательное условие продуктивного использования Cursor, Claude Code и Windsurf.

Попробовать Графон бесплатно