Все статьи

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

Cursor IDE для 1С — настройка контекста и правил

Cursor IDE для 1С — это не «просто еще один редактор с автокомплитом». Настоящая ценность появляется после того, как вы настроите контекст: какие объекты конфигурации агент видит, какие модули считает связанными, на какие правила опирается при генерации BSL-кода. Без такой настройки типичная ERP-конфигурация превращает Cursor в дорогого генератора правдоподобных галлюцинаций.

Проблема известна каждому, кто пробовал использовать ИИ-агента в 1С: конфигурация — это не плоский набор файлов, а граф связанных сущностей. Документ ссылается на справочники, общие модули, регистры, подписки на события, формы и менеджеры объектов. Cursor без внешней системы извлечения контекста пытается угадать зависимости. Результат — переполненное контекстное окно, перерасход токенов и выдуманные методы вроде ОстаткиЗаказа.Получить которых не существует.

Почему Cursor не работает с 1С «из коробки»

Cursor отлично понимает Python, TypeScript или Go, потому что для них есть AST-парсеры и графы вызовов. BSL и XML-конфигурация в таком виде не поддерживаются. Cursor не знает, что Документы.ЗаказКлиента.СоздатьДокумент() возвращает модуль объекта со своей областью данных, что КэшироватьДанные лежит в другом общем модуле, а подписка на событие срабатывает не из вызывающего кода, а из подсистемы.

Поэтому разработчики делают две типичные ошибки:

  • Добавляют в промпт огромные XML-выгрузки конфигурации. Это быстро переполняет окно контекста и делает агента неработоспособным.
  • Ограничиваются файлом текущей формы и теряют модуль менеджера, общие модули и подписки. В результате Cursor пишет код с опорой на «среднестатистическую 1С», а не на вашу конфигурацию.

Решение — локальный граф зависимостей, который отдаёт агенту только нужный срез кода. Для этого в Cursor подключается MCP-сервер. [Grafon](https://grafonbase.ru) строит такой граф для всей конфигурации 1С и предоставляет его через протокол MCP.

Архитектура работы Cursor, Grafon и правил

Поток данных выглядит так:

  • Cursor получает задачу пользователя и активирует MCP-инструменты.
  • Cursor вызывает инструменты grafon_*, чтобы найти связанные с задачей модули, процедуры и объекты метаданных.
  • Графон выполняет локальный поиск по предварительно построенному графу связей и возвращает компактный контекст — сигнатуры, список зависимых модулей, фрагменты кода.
  • Cursor применяет правила из .cursor/rules, в которых описаны стандарты 1С, и генерирует или изменяет BSL-код.

Правила здесь играют роль управляющей логики. Они запрещают агенту выходить за пределы контекста, полученного из Графона, и заставляют его использовать реальные имена методов, а не фантазировать.

Шаг 1. Подключение MCP-сервера Графон

Клиент MCP в Cursor настраивается в файле .cursor/mcp.json. Система автоматически подхватывает его при следующем запуске сессии. Пример конфигурации:

{
  "mcpServers": {
    "grafon": {
      "command": "grafon",
      "args": [
        "--mcp",
        "--project",
        "D:/1C/ERP/Configuration"
      ]
    }
  }
}

Точный флаг --project актуален для конкретной версии Графона; важна идея: MCP-сервер запускается локально и не отправляет данные конфигурации наружу.

После запуска Cursor сам обнаружит инструменты вида:

  • grafon_get_object_dependencies — связанные модули и объекты для документа, справочника, регистра;
  • grafon_find_symbol — поиск процедуры, функции или переменной в конфигурации;
  • grafon_get_module_signature — каркас модуля с сигнатурами без лишнего кода;
  • grafon_get_dependants — обратные связи: кто вызывает данный метод или подписывается на событие.

Эти инструменты — не «ещё одна база знаний», а точечный механизм извлечения. Cursor обращается к ним только по необходимости, а не скачивает всю конфигурацию.

Шаг 2. Настройка правил в .cursor/rules

Правила Cursor — это markdown-файлы с метаданными в начале. Для 1С-команды удобно создать файл .cursor/rules/1c-context.mdc с таким содержанием:

---
description: Контекст и ограничения для разработки 1С
globs: ["/*.bsl"]
---
- Запрещено использовать методы, которых нет в контексте MCP.
- Перед генерацией BSL-кода уточни структуру объекта через grafon_get_object_dependencies.
- Если в модуле отсутствует процедура, найди её в другом модуле через grafon_find_symbol.
- Не добавляй в решение XML-файлы конфигурации.
- Для работы с конкретным документом всегда проверяй его модуль менеджера и подписки на события.

Второй файл — .cursor/rules/bsl-style.mdc — отвечает за стиль:

---
description: Правила оформления и архитектуры BSL
globs: ["/*.bsl"]
---
- Используй русскоязычные имена процедур и переменных.
- Для запросов применяй язык запросов 1С, а не SQL.
- Обращение к данным выполняй только через менеджеры объектов или создание запроса.
- Не используй прямое соединение с внешними СУБД.
- При работе с управляемыми формами указывай &НаКлиенте и &НаСервере корректно.

Важно держать правила компактными. Cursor подставляет rules в контекст каждое обращение. Чем больше правил — тем меньше места для фактического кода. Оставляйте только те ограничения, которые исключают типичные ошибки вашей команды.

Шаг 3. Практическая модель контекста: не файлы, а граф

Рассмотрим популярный сценарий: разработчик просит Cursor добавить в документ ЗаказКлиента флаг «Отгрузка разрешена» и провести проверку остатков при проведении.

Если не настроить контекст, Cursor начнет искать по всему проекту остатки, @Codebase, случайные формы и модули. Токены будут потрачены впустую.

С Графоном промпт выглядит так:

Используй grafon_get_object_dependencies для Документ.ЗаказКлиента.
Затем grafon_find_symbol для метода ПроверитьОстатки.
Добавь реквизит ОтгрузкаРазрешена в документ. В модуле менеджера при проведении вызывай проверку остатков, если флаг установлен.

Cursor самостоятельно сделает несколько MCP-запросов и получит список: модуль объекта, модуль менеджера, общие модули с функциями проверки и подписку на событие ПередЗаписью. Только после этого агент сформирует изменения.

Типичный результат генерации BSL после работы с контекстом:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)


Если Не ОтгрузкаРазрешена Тогда
        Возврат;
    КонецЕсли;



Если ОстаткиПоТовару.ПолучитьОстаток(Товар) <= 0 Тогда
        Отказ = Истина;
        Сообщить("Недостаточно остатков для документа " + Ссылка);
    КонецЕсли;



КонецПроцедуры

Если метод ОстаткиПоТовару.ПолучитьОстаток реально существует в подключенном общем модуле, Cursor возьмет его из сигнатуры Графона. Если нет — MCP-ответ покажет ближайшее совпадение, и агент сможет попросить уточнить имя. Это исключает галлюцинации, характерные для «слепой» работы.

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

Для оценки полезно зафиксировать метрики на реальной задаче в конфигурации ERP. Речь не про «мелкий рефакторинг», а про задачу, затрагивающую документ, форму, модуль менеджера и общий модуль проверки остатков.

| Параметр | Без Графона, наивный @Codebase | С Графоном через MCP |
|---|---|---|
| Обрабатываемые файлы | от 500 до 2000 XML и .bsl | 15–40 целевых модулей |
| Размер контекста | 600k–2M токенов | 25k–80k токенов |
| Перерасход токенов | база | снижение в 8–10 раз |
| Время ответа | 90–240 секунд | 10–25 секунд |
| Галлюцинации | частые, метод не из конфигурации | почти отсутствуют |
| Соответствие архитектуре | случайное | гарантируется MCP-графом |

Даже если агент в первом случае случайно угадает имена, он не сможет проверить все побочные эффекты: где именно вызывается документ, какие регистры движутся, на какие подписки влияет новое поведение. Графон выводит эти связи в явный контекст.

Настройка контекста для конкретного типа задачи

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

Работа с формами

Попросите Cursor получить структуру формы через MCP: список реквизитов, команды и используемые общие модули. Не позволяйте агенту «переоткрывать» форму целиком, если изменение локальное. Достаточно найти метод обработчика и связанные функции.

Работа с запросами

Для запроса важно знать, какие поля реально существуют в регистре. Иначе Cursor напишет РегистрНакопления.Остатки.Остатки(…) с неправильными измерениями. Графон возвращает структуру регистра и используемые индексы. Cursor получит поля без необходимости загружать XML-описание измерений.

Работа с печатными формами

Печатные формы в типовых конфигурациях генерируются через общий модуль Печать.МенеджерПечати. Контекст должен включать макет, табличный документ и используемые команды формирования. Графон извлекает набор модулей, которые вызываются из печатной формы, а Cursor остается только адаптировать код под конкретные макеты.

Как измерить эффективность настройки

После внедрения рекомендуем замерять два показателя: количество токенов на успешную задачу и количество исправлений после ревью. Если количество токенов стабильно ниже в 5–10 раз, а BSL-код в 90% случаев не изменяется на ревью — контекст и правила настроены правильно.

Для этого можно добавить в .cursor/rules требование логировать MCP-запросы:

---
description: Диагностика использования графа
globs: ["/*.bsl"]
---
- Начинай задачу с grafon_get_object_dependencies.
- Перед вызовом неизвестного метода обязательно используй grafon_find_symbol.
- В ответе укажи список модулей, полученных через MCP, чтобы ревьюер видел источник контекста.

Это дисциплинирует агента и делает процесс прозрачным для команды.

Ключевые ошибки при настройке

Даже при использовании Графона можно настроить Cursor так, что выгода будет нулевой.

Первая ошибка — пытаться «на всякий случай» добавить весь модуль через @File или @Codebase. Это ломает контекстную экономию. MCP-контекст должен быть единственным источником структурных данных.

Вторая ошибка — перегруженные rules тысячами строк. Идеал — два-три сжатых файла по 10-20 строк, а не энциклопедия корпоративных стандартов.

Третья ошибка — отсутствие валидации BSL после генерации. Cursor не может проанализировать конфликты прав, если вы не передали ему подписки и модули менеджеров. Поэтому после написания кода обязательно используйте grafon_get_dependants, чтобы проверить, какие подписки могут повлиять на новый код.

Итог

Cursor становится эффективным инструментом для 1С только после правильной настройки контекста и правил. Локальный MCP-сервер Графон решает ключевую проблему — превращает гигабайты метаданных в точный граф зависимостей. Cursor получает компактный, актуальный срез конфигурации, не переполняет контекстное окно и не галлюцинирует.

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

Внедрение в команду выглядит просто: подключите MCP-сервер, опишите сжатые правила в .cursor/rules, для каждой новой задачи явно требуйте обращения к графу конфигурации через инструменты grafon_*. После двух-трех итераций вы увидите главный результат: BSL-код, который генерирует Cursor, становится не отличимым от кода опытного разработчика 1С.

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