1С-разработка в ИИ-редакторе

Обновлено 5 сентября 2026 г. · 15 мин чтения

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

Два подхода, которые часто путают

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

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

Конфигуратор такой подход не заменяет. Отладка, тестирование и обновление на поддержке остаются там.

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

Шаг 1: выгрузить конфигурацию в файлы

• Редактор открывает файлы, а не базу, поэтому из Конфигуратора: «Конфигурация» → «Выгрузить конфигурацию в файлы». Получите дерево каталогов с XML-описаниями объектов и модулями `.bsl` рядом.
• Проект EDT уже лежит файлами, открывайте каталог как есть.
• Конфигурация в Git — клонируйте репозиторий, формат тот же, что закоммитили.

Структура после выгрузки выглядит узнаваемо: каталоги `Catalogs`, `Documents`, `InformationRegisters`, `AccumulationRegisters`, `Reports`, `Roles`, `CommonModules`, а в корне `Configuration.xml` и `ConfigDumpInfo.xml`. По этим двум файлам потом строится дерево. У EDT формат другой, конфигурация хранится в `.mdo` внутри `src`, и расширение читает её отдельным кодом.

У каталога с выгрузкой своя жизнь, и с базой он не связан ничем. Правку, которую вы сделали в Конфигураторе после выгрузки, каталог не увидит; правку агента база не увидит, пока вы не загрузите конфигурацию из файлов обратно. Обе дороги проходят через Конфигуратор, и помнить об этом придётся с самого начала, потому что привычка редактора «сохранил и поехали» здесь не работает.

Шаг 2: вернуть привычное дерево метаданных

Голый каталог с XML читать неудобно. Вместо «Справочник Номенклатура» вы видите файл `Номенклатура.xml`. Дерево возвращает расширение **1C Configuration tree** (`whiterabbit.1c-configuration-tree`, репозиторий называется иначе, `MetadataViewer1C`). В Open VSX его нет, ставится `.vsix` со страницы релизов на GitHub, как любое расширение вне каталога.

Перед установкой проверьте, не осталась ли старая версия. Расширение переименовали в 2.10.6, и если у вас стоит `1c-metadata-viewer`, две версии будут конфликтовать. Удалять придётся руками.

Открывать конфигурацию нужно в обычном окне редактора. Наше окно агентов устроено иначе: там работают только расширения без исполняемого кода, то есть темы, грамматики, языки, раскладки клавиш. Дерево метаданных туда не попадает. Подсветка BSL, наоборот, работает, потому что грамматика кодом не считается.

После установки в Проводнике появляется панель с конфигурацией. Подсистемы, Роли, Общие модули, Справочники, Документы, Регистры сведений и накопления, Отчёты — в порядке Конфигуратора и с узнаваемыми иконками.

По клику на объект открывается редактор метаданных с вкладками «Свойства», «Реквизиты», «Табличные части», «Формы», «Команды», «Подсистемы», «XML». Свойства разбираются из XML и показываются полями, как в Конфигураторе.

Одно место, где расширение ломается, стоит знать заранее. На объекте с единственным вложенным потомком построение дерева валится с `TypeError: ... .filter is not a function` — например, на отчёте с одной схемой СКД и без форм. Это баг самого расширения, не редактора. Его парсер принудительно приводит данные к массиву на двух уровнях вложенности, третий не покрыт. На исходниках под тегом 2.10.9 обхода нет — правда, в `package.json` под этим же тегом стоит 2.10.7, так что сверяйтесь со своей сборкой. Лечится просто: добавить объекту вторую сущность или пересобрать выгрузку.

Мы проверили всё это живым запуском 5 сентября 2026 года на синтетической выгрузке из 23 XML-файлов и 12 модулей BSL. Дерево строится, редактор метаданных открывает объекты и корректно показывает свойства общего модуля.

Переименовать реквизит во всей конфигурации: маршрут целиком

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

Сразу про границу нашего опыта. Прогон 5 сентября закрыл только то, что идёт после выгрузки. Сам каталог мы генерировали синтетически, поэтому выгрузку из Конфигуратора и обратную загрузку наш прогон не покрывает. Тестовый каталог мы делали намеренно крошечным, чтобы глазами проверить каждое место. Массовое переименование агентом мы не гоняли вовсе: 23 файла для такой задачи слишком мало, результат ничего бы не доказал.

На выгруженном каталоге та же работа начинается с постановки задачи, и ставят её обычными словами. Например: «В справочнике Номенклатура реквизит СтараяЦена переименован в ЦенаЗакупки. Найди все обращения к нему в модулях и в XML-описаниях и покажи список найденного до того, как править». Без этой фразы агент правит сразу, и разбираться придётся уже с готовым дифом. Агент возвращает список мест, вы смотрите, не попал ли туда одноимённый реквизит соседнего объекта, и только после этого разрешаете правку. Повторять эту фразу в каждом новом чате не обязательно: WorkAI подмешивает такие требования сам, если записать их постоянным правилом — о правилах ниже.

Область поиска задавайте сами. Без указанного каталога агент пойдёт по всему дереву выгрузки, и в список попадут совпадения из демоданных и шаблонов. Насколько это дорого на типовой конфигурации, мы не замеряли.

Проверять после агента надо в трёх местах, и третье опаснее двух первых.

• Диф по каждому модулю. Сюда попадёт похожий реквизит соседнего объекта, если агент переименовал его заодно.
• XML-описание самого реквизита: имя, синоним, тип, длина. XML-описания агенту труднее, там нет кода, за который можно зацепиться.
• Места, где имя реквизита собирается строкой — в тексте запроса, в параметрах формы, в универсальных обработках. Текстовый поиск их находит; при чтении глазами имя реквизита внутри строки запроса не выглядит именем реквизита.

В базу правки уезжают обратно через «Загрузить конфигурацию из файлов». Синтаксический контроль, сравнение-объединение и отладка остаются в Конфигураторе, и это не формальность. Агент правит текст; корректность этого текста в контексте платформы покажет только запущенная база. Шаги с правками и обратной загрузкой описаны по устройству маршрута, и проверять их придётся у себя.

Что даёт агент на выгруженной конфигурации

• Разобрать чужой модуль объекта, не читая процедуру проведения построчно.
• Запрос по описанию словами агент строит на реальной структуре регистров из вашей выгрузки.
• Разнести длинный модуль по методам.
• Добавить обработку ошибок сразу в несколько модулей.
• Сверить, одинаково ли названы служебные процедуры во всех модулях подсистемы.

Общее у этих задач одно. Агент выигрывает там, где надо прочитать много кода и удержать в голове связи между модулями, и слабеет там, где нужен точный синтаксис редкой конструкции платформы. Поэтому первым делом отдавайте ему разбор чужого кода; сочинённое с нуля проверяйте строже.

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

Готовые правила под 1С подключаются без переделки

Правила — это markdown-файлы с постоянными инструкциями, которые агент подмешивает в запрос сам. Для 1С они закрывают ровно ту дыру, из-за которой модель врёт на платформе. Агент не знает, как у вас принято именовать общие модули, какие конструкции не пройдут код-ревью, куда класть новые процедуры и чем серверный контекст отличается от клиентского.

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

Наборы таких правил под 1С уже лежат в открытом доступе, и написаны они под другие редакторы. Переписывать их не придётся. WorkAI читает каталоги правил четырёх чужих экосистем помимо своего, включая открытый формат `AGENTS.md` в корне проекта, и каждый источник вы включаете отдельным переключателем в настройках, в разделе правил для ИИ. Там же видно, сколько файлов нашлось по каждому источнику, и это первое место, куда имеет смысл заглянуть, если правила в проекте лежат, а поведение агента не изменилось.

Ломается всё обычно на двух мелочах. В чужом каталоге правил принято расширение `.mdc`, и обычные `.md` тот редактор игнорирует; мы читаем оба, так что переименовывать файлы не надо. Вторая мелочь злее. Открывающий `---` заголовка обязан стоять самой первой строкой файла без единого отступа, иначе редактор молча не прочитает заголовок целиком, и правило потеряет и описание, и привязку к файлам.

Режимов у правила три. Правило либо работает всегда, либо привязано к маске файлов, либо агент сам решает, читать ли его; режим каждого найденного правила подписан в списке. У своего каталога и у некоторых чужих есть разумный дефолт — файл без заголовка вообще работает всегда. У правил из каталога с расширением `.mdc` дефолта нет: без `applyTo`, `globs`, `alwaysApply` или `description` правилу не к чему привязаться, и оно просто не подключится.

Есть потолок. Он стоит на 64 файлах в один запрос, примерно 128 тысячах символов на одно правило и примерно 512 тысячах на все вместе. Правило на подсистему — и вы у потолка: 64 файла набираются быстрее, чем кажется. Правило, не влезшее в свой потолок, агент получит обрезанным и с пометкой в тексте; файлы сверх 64 в запрос не попадут вовсе.

Живого прогона с 1С-конфигурацией и готовым чужим набором правил у нас нет. Совместимость форматов мы проверили, это факт из кода и документации продукта. Насколько конкретный набор улучшает генерацию BSL именно на вашей конфигурации, мы не мерили и цифр не назовём.

Соседняя задача MCP-сервера — доступ к данным базы

MCP-сервер и выгруженную конфигурацию путают постоянно, хотя задачи у них разные: MCP-сервер для 1С даёт агенту доступ к живой базе — к данным, которых в файлах выгрузки нет вообще.

Границу безопасности каждая из них задаёт своим способом. Файлы на диске агент читает с правами вашей учётной записи в операционной системе. Живая база отдаёт ровно то, что видит пользователь 1С, под которым MCP-сервер в неё ходит, и ограничена составом стандартного интерфейса OData, то есть тем перечнем объектов, который кто-то однажды открыл наружу явным действием. Избирательный состав интерфейса работает не всегда: в режиме совместимости конфигурации 8.3.4 и ниже он не действует, и наружу доступно всё поддерживаемое. Границу задают роли в базе и состав публикации, до настроек редактора дело не доходит.

В каталоге WorkAI два встроенных сервера лежат готовыми карточками и начинают работать только после того, как вы их подключите и введёте ключ; в конфигурацию заранее ничего не пишется. Что решать до подключения — под какой учётной записью сервер ходит в базу, что попало в состав интерфейса OData, как ведёт себя ограничение доступа на уровне записей — разобрано отдельно: что ИИ-агент увидит в вашей базе и как не отдать лишнего.

Какая модель лучше пишет на BSL?

У нас нет ответа. Мы не прогоняли модели на наборе 1С-задач, не считали проценты и рейтинга не публикуем, хотя в такой статье он смотрелся бы органично.

Если ответ нужен именно вам, собственный замер собирается за вечер, и на вашем коде он честнее любого чужого. Возьмите пять задач из своей практики, у которых вы заранее знаете правильный ответ. Дайте каждой модели один и тот же текст задачи, без наводящих правок по ходу. Считайте проверяемое: собрался ли результат без ошибок, есть ли обращения к выдуманным методам общих модулей, верно ли построен запрос на языке запросов, не перепутан ли серверный контекст с клиентским.

16 000 токенов — максимум вывода на бесплатном наборе. Само содержимое набора не стоит на месте: WorkAI Free — это открытые модели, которые платформа подбирает и обновляет сама, дважды в сутки, так что модель, на которой вчера получился рабочий запрос, сегодня может оказаться другой. Замер на одном наборе моделей про другой набор не говорит ничего.

Чего ждать не стоит

Модель знает платформу 1С хуже, чем массовые языки: публичного кода на BSL и языке запросов на порядки меньше, чем на Python. Сравнительного замера у нас нет, и практический вывод из этого один — там, где на Python вы бы уже доверились правдоподобному синтаксису, на 1С придётся открыть синтакс-помощник.

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

Частые вопросы