Claude Code и Cursor на задаче 1С: протокол сравнения и разбор ошибок агентов

Выбор между терминальным агентом и редактором с ИИ редко решается по названию. Решает протокол проверки: одинаковое задание, одинаковая база, одинаковое время и список критериев, который фиксируется письменно. Ниже - такой протокол и разбор ошибок, которые всплывают в сгенерированном коде 1С.

🧱 Задача для сравнения

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

Условный пример задания для прогона:

Напиши код на BSL для отчёта по остаткам товаров на складах.
1. Остатки по всем складам организации на текущую дату.
2. Группировка по номенклатуре, характеристике и серии.
3. В результат попадают только позиции, по которым не было движений
   за последние 30 дней.
4. Результат запроса вывести в таблицу значений с колонками:
   Номенклатура, Характеристика, Серия, Склад, Количество, Сумма.
5. Код должен вставляться в отчёт или обработку без доработок.

Три ловушки в этом задании:

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

🧪 Что фиксировать в прогоне

Критерии записываются до старта, иначе сравнение превращается в спор о впечатлениях.

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

💻 Что проверять в сгенерированном запросе

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

Путаница таблиц остатков и оборотов. У регистра накопления с видом «Остатки» доступны виртуальные таблицы Остатки, Обороты и ОстаткиИОбороты, а у регистра с видом «Обороты» - только Обороты. В типовой конфигурации регистр остатков товаров на складах и регистр движений продаж - разные объекты, и условие «не было движений за период» берётся из оборотной таблицы. Агент, который подставит таблицу остатков вместо оборотов, получит запрос, синтаксически верный и логически бессмысленный.

Параметры виртуальных таблиц. У таблицы остатков их два, у оборотов - четыре:

РегистрНакопления.<ИмяРегистра>.Остатки(<Период>, <Условие>)
РегистрНакопления.<ИмяРегистра>.Обороты(<НачалоПериода>, <КонецПериода>, <Периодичность>, <Условие>)

Суффиксы ресурсов. В таблице Остатки ресурсы получают суффикс Остаток (Количество превращается в КоличествоОстаток), в таблице Обороты - суффикс Оборот. Обращение к несуществующему полю платформа отклонит на этапе разбора запроса, поэтому ошибку видно сразу.

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

Условный пример сводного запроса с соединением остатков и оборотов за период:

ВЫБРАТЬ
    ТоварыНаСкладахОстатки.Номенклатура КАК Номенклатура,
    ТоварыНаСкладахОстатки.Характеристика КАК Характеристика,
    ТоварыНаСкладахОстатки.Серия КАК Серия,
    ТоварыНаСкладахОстатки.Склад КАК Склад,
    ТоварыНаСкладахОстатки.КоличествоОстаток КАК Количество,
    ТоварыНаСкладахОстатки.СуммаОстаток КАК Сумма
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки(, ) КАК ТоварыНаСкладахОстатки
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, , ) КАК Движения
        ПО ТоварыНаСкладахОстатки.Номенклатура = Движения.Номенклатура
            И ТоварыНаСкладахОстатки.Характеристика = Движения.Характеристика
            И ТоварыНаСкладахОстатки.Серия = Движения.Серия
ГДЕ
    Движения.КоличествоОборот ЕСТЬ NULL
    И ТоварыНаСкладахОстатки.КоличествоОстаток <> 0

Имена регистров в примере взяты из типовой конфигурации и проверяются на своей базе: набор регистров зависит от конфигурации и её редакции. Фрагмент не прогнан на платформе и требует локальной проверки - в облаке нет 1С.

🧰 Протокол прогона

1. Копия базы. Работа идёт только на копии: агент с доступом на запись в рабочую базу меняет данные быстрее, чем вы успеваете прочитать диф.
2. Выгрузка метаданных. Инструменту даётся выгрузка конфигурации в файлы. Без неё он угадывает имена по общим шаблонам.
3. Текст задания. Один и тот же файл для обоих инструментов, без подсказок и без примеров кода.
4. Фиксация времени. Секундомер от отправки задания до первого варианта, который проходит проверку синтаксиса.
5. Проверка имён. Каждое имя метаданных и каждый метод сверяются с выгрузкой и синтакс-помощником. Список расхождений пишется построчно.
6. Прогон. Только после проверки имён - запуск на копии базы. Ошибки платформы записываются с текстом сообщения.
7. Разбор. Критерии из таблицы заполняются по каждому инструменту, результат подписывается датой и версиями.

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

🧮 Как считать результат

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

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

🚧 Границы метода

• Один прогон ничего не доказывает. Результат зависит от версии модели, размера выгрузки метаданных, от того, попала ли нужная конфигурация в контекст, и от формулировки задания.
• Инструмент и модель - разные вещи. Один и тот же редактор может работать с разными моделями, и сравнение редакторов без фиксации модели бессмысленно.
• Первый запуск и рабочая сессия - разные режимы. Терминальный агент тратит время на чтение выгрузки при старте, редактор держит индекс между сессиями. Сравнивать нужно оба режима отдельно.
• Документация инструментов меняется. Возможности, о которых идёт речь, - неинтерактивный режим запуска, правила проекта, подключение внешних серверов через MCP - описаны в документации Claude Code и Cursor; перед тестом сверьтесь с актуальной версией справки.

🪤 Ошибки в самом тесте

Разные условия на входе. Разные модели, разный размер выгрузки, разное время - всё это делает результат несравнимым.

Оценка «на глаз». «Код выглядит чище» нельзя предъявить коллеге. Критерии записываются до прогона и проверяются по списку.

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

Работа в рабочей базе. Любой прогон с записью - только на копии. Это относится и к агентам, которые умеют выполнять команды самостоятельно.

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

🏁 Итог

Сравнение ИИ-инструментов на задаче 1С даёт результат, когда задание, база и время совпадают, а критерии записаны до старта. Проверяются имена метаданных, методы BSL, параметры виртуальных таблиц и число итераций до рабочего кода. Запрос к регистрам накопления удобен как пробная задача: в нём сразу видно, читает инструмент контекст конфигурации или подставляет имена по догадке.

Соберите протокол на своей базе и прогоните его на двух задачах. Расскажите в комментариях, какие ошибки в BSL-коде своих агентов вы ловите чаще всего.

📦 Файл к статье

Архив к статье (05.2-companion.zip) лежит в блоке «Файлы» под текстом публикации. Что внутри:

• protokol-sravneniya.md - протокол прогона из семи шагов и таблица критериев для заполнения;
• chek-list-proverki-zaprosa.md - что проверить в сгенерированном запросе до запуска на платформе;
• zapros-ostatki-s-dvizheniyami.bsl - сводный запрос из статьи отдельным файлом;
• tablica-rezultatov.csv - таблица результатов прогона с условными числами для образца.

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

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 28 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S