Выбор модели для разработки в 1С: сравниваем топов и open source

Тренды в области разработки ПО

В области разработки ПО наметился тренд на использование больших языковых моделей. Тема сейчас на пике хайпа, с подачи Андрея Карпати (сооснователь OpenAI, бывший директор AI в Tesla) даже получила своё название — вайб-кодинг. Термин родился из твита Карпати в феврале 2025 года, набрал более 4,5 млн просмотров и попал в словарь Collins как слово года.

Лидеры в области — Anthropic и OpenAI, догоняющий их Google, а также стремительно набирающие обороты китайские модели: Kimi, GLM, DeepSeek. CEO Anthropic Дарио Амодеи заявил, что на отдельных командах компании до 90% кода пишется AI (хотя в среднем по компании цифра оценивается ниже). Стартап Cursor (Anysphere Inc.) вырос буквально за пару лет до оценки в $29,3 млрд — это самая быстрорастущая SaaS-компания в истории.

В общем, тема стремительно развивается и на большом хайпе. Но что же в области разработки на 1С? Пока, к сожалению, всё скромнее. Компания 1С выпустила AI-ассистента — 1С:Напарник (бесплатный для подписчиков ИТС до октября 2026). Энтузиасты разрабатывают в Cursor с MCP-серверами для 1С. Есть растущая экосистема инструментов.

Мне стало немного обидно за отечественную разработку, и я решил сделать свою реализацию AI-среды для 1С:EDT. Результаты того, что получилось, я выложил на GitHub в свободный доступ. Скачать и установить плагин можно из моей репы https://github.com/ondysss/codepilot1c-edt там же инструкции по установке. Разработка не коммерческая, веду в свободное от основной работы время. Что умеет плагин:

1. Режим агента как у Cursor (чтение, редактирование, анализ файлов конфигурации)
2. Работа с любыми моделями (OpenAI, Anthropic, Ollama, российские провайдеры)
3. Индексация кодовой базы и поиск с использованием RAG
4. Кастомные MCP-серверы

Модели буду переключать в интерфейсе плагина. 

Сейчас на этом особо останавливаться не буду — вернусь к основной теме статьи. Если лениво читать весь текст целиком, в конце статьи есть итоговая таблица.

Методология тестирования

Модели в обзоре: Claude Opus 4.5 (дорого-богато), Gemini 3 Flash, Grok Code Fast от xAI, GLM-4.7 от Zhipu AI (китайская модель, которую можно развернуть локально), Kimi K2.5, а также отечественные GigaChat Pro от Сбера и YandexGPT 5.1 Pro.

Для начала просто открою проект в EDT и задам простой вопрос — «Что это за проект?». Это позволит понять: может ли модель в общих чертах разобраться, что перед ней, и понимает ли она проекты на 1С. Для теста возьму типовой ЗУП . Хотя в плагине реализована возможность индексации кодовой базы и работа с RAG, для первого теста его использовать не буду — хочу понять, как модель будет обрабатывать ошибки вызова инструментов, да и в целом интересно, как модель будет работать в агентном режиме.

Результаты тестирования: Claude Opus 4.5

Начнём с тяжёлой артиллерии — Claude Opus 4.5. Модель дорогая, но от неё и ожидания соответствующие. Открываю проект ЗУП 3.1.36.75 в EDT, кидаю простой промт — «Изучи текущую конфигурацию, объясни особенности и основные паттерны». Без RAG, без MCP — голый агент с инструментами для работы с файлами. 

Первое, что бросается в глаза — Opus сразу правильно определяет, какие инструменты ему нужны. Он начинает листать файлы проекта: заходит в План видов расчета, План видов характеристик, План Обмена, Бизнес процессы, Определяемые типы — всё чётко, по делу. Да, словил ошибку на RAG («RAG service is not ready»), но это ожидаемо — мы же специально отключили индексацию. Важно другое — модель не зависла на этой ошибке, а спокойно пошла дальше работать с теми инструментами, которые доступны. Это хороший знак для агентного режима.

И вот тут я, честно говоря, немного был удивлен  от результата. Opus выдал очень детальный и по делу анализ конфигурации. Судите сами — он правильно определил, что это ЗУП 3.1.36.75, версию платформы 8.3.24+, режим управляемого приложения, режим использования модальности «Не использовать». Казалось бы, мелочь, но это показывает, что модель реально понимает структуру метаданных 1С, а не просто гадает.

Но самое крутое — это разбор архитектурных паттернов. Opus вычленил систему постфиксов общих модулей БСП — разделение по контексту (Клиент / Сервер / КлиентСервер / ВызовСервера) и по назначению (Переопределяемый, Служебный, ПовтИсп). Нашёл паттерн кэширования через модули с постфиксом ПовтИсп (повторное использование возвращаемых значений — более 100 таких модулей). Переопределяемые модули как механизм расширения БСП описал правильно.

Отдельно порадовало, что Opus знает про БСП (1С:Библиотеку стандартных подсистем) и перечислил входящие механизмы — управление доступом, версионирование объектов, подключаемые команды, электронная подпись и так далее. Также правильно определил все интеграции — обмен с Бухгалтерией 3, универсальный формат, СЭДО ФСС, обмен с банками. Не поленился и кабинет сотрудника описал с бизнес-процессами заявок.

В резюме Opus дал практические рекомендации по доработке — использовать переопределяемые модули как точки входа, не лезть в служебные модули, учитывать контекст исполнения. По сути он выдал то, что мог бы рассказать опытный 1С-архитектор новому разработчику на проекте.

Итого по Claude Opus — впечатляет. Модель реально понимает 1С, знает архитектуру типовых конфигураций, правильно работает с агентными инструментами и адекватно обрабатывает ошибки. Минус пока один — цена, но за такое качество это ожидаемо.

Результаты тестирования: Gemini 3 Flash

Следующий кандидат — Gemini 3 Flash от Google. Тот же промт, те же условия. И тут картина уже другая — Gemini справился, но, скажем так, на уровне «в общих чертах».

Что он правильно определил: да, это ЗУП, да, построен на БСП, есть регистры расчёта и планы видов расчёта. Общие модули с разделением на Клиент / Сервер / ВызовСервера — тоже отметил. Про систему компоновки данных (СКД) в отчётах сказал, про HTTP-сервисы и веб-сервисы упомянул. Даже RLS (ограничение доступа на уровне записей) не забыл — кстати, это Opus пропустил. Так что плюсик Gemini.

Но вот чего не хватает. Во-первых, он не определил точную версию конфигурации — просто «ЗУП» и всё. Во-вторых, и это главное — Gemini не вычленил систему постфиксов БСП (Переопределяемый, Служебный, ПовтИсп). Он упомянул только переопределяемые модули и то в контексте БСП, а не как самостоятельный архитектурный паттерн. Паттерн кэширования через ПовтИсп — мимо.

Интересный момент — Gemini назвал архитектуру ЗУП «микросервисной внутри монолита». Звучит красиво, но если подумать — это не совсем точная характеристика. В 1С нет микросервисов в классическом понимании, это скорее модульная архитектура с подсистемами. Ощущение, что модель пытается натянуть знакомые ей термины из мира веб-разработки на реалии 1С.

Итого по Gemini 3 Flash — базовое понимание 1С есть, конфигурацию опознал, основные механизмы перечислил. Но глубины анализа как у Opus нет — пропущены ключевые архитектурные паттерны ЗУП, нет точного определения версии, есть попытки «притянуть» терминологию из других стеков. Для быстрого обзора «что это за конфа» сойдёт, но для серьёзной работы с кодовой базой маловато.

Результаты тестирования: GLM-4.7 (Zhipu AI)

А теперь кое-что интересное — китайский стартап Zhipu AI и их модель GLM-4.7. Китайцы в последнее время прут как танки в теме AI, посмотрим, что покажет на нашей 1С.

Первое наблюдение по работе с инструментами — GLM пошёл вглубь кода. Начал с glob по Module.bsl файлам, потом полез читать конкретные модули — Модуль менеджера и Модуль Объекта документа НачислениеЗарплаты. По пути словил пару ошибок — попытался прочитать StartModule.bsl, которого нет, потом неправильно составил путь для поиска текста. Но в итоге оправился, расширил поиск и нашёл нужное. То есть с ошибками работает, но не так элегантно как Opus — спотыкается чаще.

Зато по содержанию анализа — тут GLM реально удивил. Он пошёл совсем другим путём, чем Opus и Gemini. Вместо обзора «с высоты птичьего полёта» он залез в код и начал разбирать конкретные паттерны программирования. Во-первых, точно определил версию — ЗУП 3.1.36.75, платформа 8.3.24, всё как у Opus. Во-вторых, нашёл и описал областную структуру кода (#Область ПрограммныйИнтерфейс, #Область СлужебныйПрограммныйИнтерфейс и так далее) — это ни Opus, ни Gemini не упоминали, а это важная штука для понимания, как читать код типовых конфигураций.

Дальше — больше. GLM раскопал паттерн подсистемной архитектуры с опциональностью — когда код проверяет наличие подсистемы через ОбщегоНазначения.ПодсистемаСуществует() и только потом вызывает модуль. Это реально тонкий момент, который показывает, как ЗУП работает с опциональными подсистемами. Привёл конкретный пример из кода — с номерами строк из ManagerModule.bsl. Также нашёл многовидовое проведение документов (начисления, НДФЛ, страховые взносы, бухучёт одновременно), паттерн использования ДополнительныеСвойства для передачи контекста между процедурами, менеджерные модули с ПриЗаполненииОграниченияДоступа — и всё это с конкретными примерами кода из конфигурации.

Итого по GLM-4.7 — приятный сюрприз. Модель показала совершенно другой подход к анализу: вместо обзора архитектуры сверху она полезла в код и разобрала конкретные паттерны программирования с примерами. Для практической работы это может быть даже полезнее, чем высокоуровневый обзор Opus. Минусы — больше ошибок при работе с инструментами и пропуск некоторых архитектурных паттернов БСП. Но в целом — китайцы реально конкурируют, не зря хайп.

Результаты тестирования: Kimi K2.5

Ещё один китаец — Kimi K2.5 от Moonshot AI. Флагман стартапа с триллионом параметров и поддержкой до 100 параллельных агентов. И вот тут, я завис, когда увидел результат.

По работе с инструментами — Kimi действовал очень методично. Начал с корневого каталога, нашёл Configuration.mdo через glob, прочитал его (34 тысячи символов!), потом пошёл по подсистемам, общим модулям, документам, регистрам. Тоже словил ошибку на RAG, но продолжил через поиск текста и листинг каталогов. В целом по инструментам работает уверенно, ошибок меньше, чем у GLM.

Теперь по содержанию — и вот тут начинается самое интересное. Kimi выдал, пожалуй, самый структурированный анализ из всех. Он разложил архитектуру подсистем на пять уровней: Фундамент (СтандартныеПодсистемы) → Ядро (ЗарплатаКадрыПодсистемы) → Расширение (ЗарплатаКадрыРасширеннаяПодсистемы) → Приложение (ЗарплатаКадрыПриложения) → Продукт (ЗарплатаИУправлениеПерсоналом).

Но главное — Kimi нашёл ВСЕ постфиксы модулей (Сервер, Клиент, КлиентСервер, ВызовСервера, Переопределяемый, Служебный, ПовтИсп) — ни одна другая модель не перечислила полный набор. И нашёл вещи, которые все остальные пропустили. Регистры сведений для кадровой истории (ГрафикРаботыСотрудниковИнтервальный) — это важнейший паттерн ЗУП для хранения периодических данных с датами начала и окончания. Функциональные опции — никто до этого про них не вспомнил. Подсистему исправления документов прошлых периодов раскопал. Защиту персональных данных с выделенными модулями нашёл.

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

Итого по Kimi K2.5 — если честно, это лучший результат на данный момент. Модель показала самый полный и структурированный анализ, нашла паттерны, которые пропустили все остальные (функциональные опции, регистры расчета, исправление документов прошлых периодов, защита ПДн), при этом совместила обзор архитектуры с конкретными примерами кода. Для китайской модели результат неожиданно крутой.

Результаты тестирования: Grok Code Fast (xAI)

Следующий кандидат — модель от Илона Маска, Grok Code Fast от xAI. Ну что сказать — тут у нас полный провал, ребята. Grok перепутал русский с английским и в результате вывалил натуральную кашу.

Начнём с самого очевидного — модель зачем-то выдаёт свои внутренние рассуждения в ответ. Видно, как она сама с собой разговаривает на английском: «The query is in Russian», «Keep short and concise», «Output text for communicating with the user» — это называется утечка цепочки рассуждений, и для серьёзного инструмента это залет. Получается, модель не может нормально отделить своё внутреннее «думание» от результата для пользователя.

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

Итого по Grok Code Fast — откровенно слабо. Главная проблема даже не в понимании 1С (хотя и тут всё грустно), а в том, что модель не может нормально сформировать ответ на русском языке. Мешанина из русского и английского, утёкшие внутренние рассуждения, отсутствие структуры — для работы с 1С это просто непригодно. Может, для англоязычного кода Grok и неплох, но с русскоязычной спецификой пока совсем не дружит.

Результаты тестирования: GigaChat Pro (Сбер)

Ну а теперь переходим к отечественному автопрому — GigaChat Pro от Сбера. Тут ожидания были особые — всё-таки российская модель, русский язык родной, 1С тоже наше, должна же она шарить лучше всех, верно? Ну, давайте посмотрим.

По работе с инструментами — GigaChat действовал вполне уверенно. Нашёл Configuration.mdo через glob, прочитал его (34 тысячи символов), пошёл по каталогам документов, регистров сведений, даже в конкретные модули залез — прочитал Модуль Объекта документа ВыдачаЗаймаСотруднику и Модуль менеджера регистра ГрафикРаботыСотрудников. То есть подход скорее как у GLM — полез в конкретный код, а не обозревал сверху.

По содержанию — в целом неплохо. GigaChat правильно определил, что это ЗУП 3.1 для 1С:Предприятие, расписал функционал: кадровый учёт, расчёт зарплаты, взаиморасчёты с сотрудниками, налоги и взносы, отчётность. Нашёл интеграцию с ФНС, ФСС, упомянул кабинет сотрудника. Архитектурные паттерны тоже перечислил — подсистемы, документы с проведением (обработчик ОбработкаПроведения с параметрами Отказ и РежимПроведения, ОбработкаЗаполнения, ОбработкаПроверкиЗаполнения), регистры сведений и накопления, общие модули с БСП. Про RLS (ограничение доступа на уровне записей) не забыл.

Что особенно понравилось — GigaChat нашёл несколько вещей, которые другие модели пропустили. «Машина времени» для расчётов прошлого на основе архивных данных — это реально важный концепт ЗУП, никто до этого про него не писал. Менеджерные модули регистров с процедурой ПриЗаполненииОграниченияДоступа — это GLM тоже нашёл, но GigaChat дополнительно раскрыл, что доступ ограничивается по организации и физлицу. Обработчики обновления для миграции данных между версиями — тоже уникальная находка.

Из минусов — точную версию конфигурации (3.1.36.75) не определил, систему постфиксов модулей БСП (Переопределяемый, Служебный, ПовтИсп) не вычленил, паттерн кэширования через ПовтИсп не нашёл. Но это те же самые пробелы, что и у GLM — по сути модели одного уровня, просто копают в разных местах.

Итого по GigaChat Pro — достойный результат. Модель хорошо понимает 1С и ЗУП, даёт детальный функциональный обзор с уникальными находками («машина времени», обработчики обновления), уверенно работает с инструментами. По глубине анализа — примерно на уровне GLM-4.7, каждая модель нашла что-то своё, но обе уступают Opus и Kimi по полноте архитектурного разбора. Для отечественной модели — вполне достойно, конкурирует с китайцами на равных.

Результаты тестирования: YandexGPT 5.1 Pro

Второй представитель — YandexGPT 5.1 Pro. Ну и тут, если честно, грустная история (Ох Олег, что же ты такое?!). Очень слабо (напомню промт у всех моделей был одинаковый).

Первое, что бросается в глаза — модель вообще не начала работать с инструментами сама. Вместо того чтобы полезть изучать конфигурацию, она спросила «что вас интересует?». Пришлось ей прямым текстом написать «используй доступные тебе инструменты». Ни Opus, ни Kimi, ни GLM, ни GigaChat — никто не переспрашивал, все сразу брались за дело. Для агентного режима это проблема — модель должна сама понимать, что у неё есть инструменты, и ими пользоваться.

После пинка модель всё-таки пошла работать, но сделала всего два вызова — список файлов корневого каталога и список файлов папки «зуп». Всё. Не прочитала Configuration.mdo, не заглянула ни в один модуль, не посмотрела подсистемы, документы, регистры. Для сравнения — Kimi прочитал 34 тысячи символов из Configuration.mdo и потом ещё полез по конкретным модулям.

Ну и результат соответствующий — YandexGPT просто перечислил названия папок (AccumulationRegisters, ManagerModule.bsl, RecordSetModule.bsl) и выдал три общих фразы вместо анализа: «регистры накопления для учёта финансовых данных», «модули управления для обработки данных», «отдельные модули для расчётов». Это не анализ конфигурации, это пересказ оглавления. Ни версии, ни подсистем, ни архитектурных паттернов, ни даже понимания, что это ЗУП.

Итого по YandexGPT 5.1 Pro — самый слабый результат из всех протестированных моделей. Модель не умеет работать в агентном режиме, не понимает, зачем ей инструменты, и выдаёт поверхностный пересказ структуры каталогов вместо анализа. Даже Grok при всей своей каше хотя бы пытался что-то проанализировать. Яндексу тут ещё работать и работать.

Итоги тестирования

Ну что, давайте подводить итоги. Протестировали семь моделей на одном и том же задании — изучить конфигурацию ЗУП 3.1.36.75 в агентном режиме и рассказать про особенности и паттерны. Без RAG, без MCP — голый агент с инструментами для работы с файлами. Результаты получились очень показательными.

Безусловные лидеры — Claude Opus и Kimi K2.5. Обе модели показали глубокое понимание архитектуры 1С, нашли ключевые паттерны ЗУП (систему постфиксов модулей, ПовтИсп), уверенно работали с инструментами. При этом Kimi даже немного удивил — нашёл вещи, которые Opus пропустил (функциональные опции, интервальные регистры, исправление документов прошлых периодов). Для китайской модели — это прямо вау.

Крепкие середняки — GLM-4.7 и GigaChat Pro. Обе модели показали хороший уровень, каждая нашла что-то уникальное: GLM раскопал областную структуру кода и паттерн ПодсистемаСуществует(), GigaChat — «машину времени» и обработчики обновления. Систему постфиксов модулей обе пропустили, но по практической пользе — вполне рабочий вариант.

Gemini 3 Flash — базовый уровень. Конфигурацию опознал, основные механизмы перечислил, даже RLS нашёл. Но глубины нет, ключевые паттерны ЗУП мимо, плюс попытки «притянуть» терминологию из других стеков.

Аутсайдеры — Grok Code Fast и YandexGPT 5.1 Pro. Grok перепутал русский с английским и утопил результат в утёкших внутренних рассуждениях. YandexGPT вообще не понял, зачем ему инструменты, и выдал пересказ оглавления вместо анализа. Обе модели на данный момент непригодны для работы с 1С в агентном режиме.

Главный вывод — для серьёзной работы с 1С в агентном режиме сейчас реально подходят только Opus и Kimi. Если бюджет позволяет — Opus даёт стабильно высокое качество. Если хочется сэкономить — Kimi K2.5 прямо отличная альтернатива. GLM и GigaChat — для задач попроще. Остальные пока мимо.

Итоговая таблица

Плагин доступен на GitHub. Если статья была полезна — поставьте мне звездочку на гитхабе (вам все равно, а мне лишний стимул продолжать разработку плагина), задавайте вопросы в комментариях.

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