Практический эксперимент по использованию ИИ при обновлении расширений 1С
Об использовании нейросетей для программирования написано уже много. Но большинство сравнений строится на небольших искусственных примерах: написать функцию, исправить ошибку, объяснить запрос или сгенерировать несколько строк кода.
Мне было интереснее проверить ИИ на задаче, с которой разработчик 1С действительно сталкивается в работе: обновление конфигурации, в которой используется крупное расширение.
После обновления основной конфигурации нужно понять, какие изменения появились в типовой, какие собственные доработки есть в расширении и как объединить их так, чтобы не потерять ни новую типовую логику, ни функциональность расширения.
Для эксперимента я сравнил два варианта:
- GigaChat-2-Pro через API;
- Qwen3-Coder 30B локально через Ollama.
Цель была не определить «лучшую нейросеть вообще», а посмотреть, насколько они помогают при разборе реальных конфликтов BSL-кода.
В чём задача
В упрощённом виде для каждого изменённого метода есть три источника:
Типовая конфигурация ДО обновления → Типовая конфигурация ПОСЛЕ обновления → Метод из расширения.
Особенно интересны методы расширений с аннотациями:
&Перед,
&После,
&Вместо,
&ИзменениеИКонтроль.
Самые неприятные случаи — &ИзменениеИКонтроль.
Если типовая процедура после обновления изменилась, а расширение продолжает использовать свой вариант старого метода, возникает вопрос: какие изменения из новой типовой нужно перенести в расширение?
На большом расширении делать это вручную для десятков методов долго и довольно легко что-нибудь пропустить.
Для эксперимента был сделан небольшой анализатор, который без участия LLM:
- находит изменённые методы расширения;
- находит соответствующий метод в старой типовой конфигурации;
- находит тот же метод в новой типовой;
- строит различия;
- формирует возможный вариант адаптации;
- при необходимости формирует альтернативный вариант;
- передаёт результат модели для дополнительного анализа.
При этом нейросеть не должна была писать новый метод «с нуля».
Её задача была выбрать одно из четырёх решений:
- ПРЕДЛОЖЕНИЕ — использовать основной подготовленный вариант;
- АЛЬТЕРНАТИВА — использовать альтернативный вариант;
- НИ ОДИН ИЗ ВАРИАНТОВ — оба кандидата плохие;
- ТРЕБУЕТСЯ РУЧНОЕ РЕШЕНИЕ — однозначно решить автоматически нельзя.
Это важный момент. LLM выступала не генератором произвольного кода, а вторым мнением при разборе уже найденного конфликта.
Почему я вообще сделал отдельный анализатор
При обновлении расширения проблема обычно не в том, чтобы увидеть diff.
Проблема в том, чтобы понять его смысл.
Например, типовая могла:
- изменить сигнатуру вызова;
- добавить новый реквизит;
- поменять сортировку;
- заменить общий модуль;
- удалить старую логику;
- изменить запрос;
- изменить параметры печати.
А расширение в это же место могло добавить:
- собственное поле;
- свою сортировку;
- собственный блок печати;
- #Вставка;
- #Удаление;
- дополнительную бизнес-логику.
Получается классический трёхсторонний merge, но на BSL и с особенностями механизма расширений 1С.
Поэтому идея была простой: сначала максимально много сделать обычным алгоритмом, а уже потом подключать LLM.
Локальный стенд
Qwen3-Coder 30B запускался локально на домашнем компьютере:
- AMD Ryzen 7 7700;
- 32 ГБ оперативной памяти;
- GeForce GTX 1050 Ti 4 ГБ;
- Windows;
- Ollama;
- модель qwen3-coder:30b.
В моём случае использовать GPU не получилось из-за ошибки CUDA/PTX(старая видеокарта), поэтому модель работала полностью на CPU.
Контекст для эксперимента был установлен в 24576 токенов.
Это важно учитывать при сравнении скорости. На современной видеокарте Qwen3-Coder 30B работал бы совершенно иначе.
Здесь проверялся другой практический сценарий: можно ли вообще использовать достаточно крупную локальную code-модель на обычном компьютере без мощной GPU.
Можно.
Но быстро это не назвать.
Тест №1. Условное оформление формы
Первый реальный конфликт — процедура:
УстановитьУсловноеОформлениеФормы
Аннотация расширения:
&ИзменениеИКонтроль
После обновления типовая конфигурация заметно изменила оформление.
Например, старые обращения к ЦветаСтиля были заменены на новые значения ЦветаПалитры.
Вместо:
ЦветаСтиля.ТекстВторостепеннойНадписи
появилось:
ЦветаПалитры.ТекстВторостепеннойНадписиУНФ
Менялись и другие цвета.
Кроме того, вместо ручного создания шрифта через Новый Шрифт(...) типовая стала использовать готовый стиль:
ШрифтыСтиля.ЗаголовокТретьегоУровня
Само по себе обновление несложное.
Но расширение в этой процедуре имело свою логику: один из блоков типового метода был отключён директивами:
#Удаление ... #КонецУдаления
Поэтому просто заменить процедуру на новую типовую нельзя — потеряется доработка расширения.
Правильная адаптация здесь выглядит так:
взять актуальную новую типовую процедуру и сохранить удаление, которое было сделано расширением.
Результат GigaChat
GigaChat-2-Pro выбрал:
ПРЕДЛОЖЕНИЕ
Уверенность модели:
100%
Автоматическая проверка показала, что выбранный вариант содержит:
- 20 из 20 точных изменений новой типовой;
- 3 из 3 изменений расширения.
Время ответа:
3,4 секунды.
То есть в первом тесте GigaChat дал правильное решение практически мгновенно.
Результат Qwen3-Coder 30B
Локальный Qwen3-Coder 30B выбрал тот же вариант:
ПРЕДЛОЖЕНИЕ
Уверенность:
95%
Проверка также показала:
- типовая — 20/20;
- расширение — 3/3.
То есть по качеству решения первый тест обе модели прошли одинаково.
Но время локальной модели было совсем другим.
На одном из итоговых запусков:
- вход — около 12669 токенов;
- ответ — около 802 токенов;
- время — 410,8 секунды.
Это почти 7 минут на CPU.
Именно поэтому здесь важно разделять два вопроса:
может ли локальная модель решить задачу? — да.
комфортно ли использовать 30B-модель на CPU? — уже значительно спорнее.
и
Тест №2. Печатная форма
Второй конфликт оказался намного интереснее.
Метод:
ПечатнаяФорма
Документ:
ПеремещениеЗапасов
Аннотация снова:
&ИзменениеИКонтроль
В расширении этот метод был серьёзно изменён.
Среди собственных доработок присутствовали:
- поле Транзит;
- изменённая сортировка;
- своя работа с макетом;
- обработка ИнтернетЗаказ;
- заполнение Комментарий;
- дополнительные изменения печатной формы.
Одновременно изменилась и типовая конфигурация.
И одно из изменений было небольшим по размеру, но принципиальным по смыслу.
В новой типовой появилось поле:
Партия
Оно стало использоваться в запросе и в вызове функции представления номенклатуры для печати.
Именно на этом изменении два подготовленных кандидата отличались.
Основной ПРЕДЛОЖЕННЫЙ вариант сохранял почти всё, но одно изменение новой типовой потерял.
АЛЬТЕРНАТИВА сохраняла его.
Формальная проверка позже показала:
- ПРЕДЛОЖЕНИЕ — типовая 4/5, расширение 25/25;
- АЛЬТЕРНАТИВА — типовая 5/5, расширение 25/25.
Поэтому правильный выбор здесь — АЛЬТЕРНАТИВА.
Что решил GigaChat
GigaChat-2-Pro выбрал:
АЛЬТЕРНАТИВА
Уверенность:
100%
Время финального теста:
6,4 секунды.
При этом модель указала правильную причину: альтернативный вариант полностью учитывает изменения типовой конфигурации, связанные с полем Партия.
Автоматическая проверка подтвердила:
- ПРЕДЛОЖЕНИЕ — 4/5 изменений типовой;
- АЛЬТЕРНАТИВА — 5/5;
- обе версии сохраняют 25/25 изменений расширения.
То есть во втором, более сложном тесте GigaChat тоже принял правильное решение.
А Qwen3-Coder 30B ошибся
Локальная модель выбрала:
ПРЕДЛОЖЕНИЕ
Уверенность:
95%
И самое интересное:
ручная проверка, по мнению самой модели, не требовалась.
На первый взгляд всё выглядит довольно убедительно.
Но фактически решение было неправильным.
При этом Qwen правильно заметил само изменение типовой.
Модель написала, что:
в функцию ПредставлениеНоменклатурыДляПечати добавлен параметр Партия.
То есть исходную разницу она увидела правильно.
После этого модель сделала неверный вывод и решила, что это изменение уже присутствует в основном предложенном варианте.
Хотя фактически:
- в ПРЕДЛОЖЕНИИ оно отсутствовало;
- в АЛЬТЕРНАТИВЕ присутствовало.
Более того, модель начала объяснять, почему альтернативный вариант хуже.
То есть получилась очень показательная ситуация:
LLM правильно прочитала факты, но неправильно сравнила два итоговых варианта и пришла к противоположному выводу.
И сделала это с уверенностью 95%.
95% уверенности — это не 95% вероятности правильного ответа
Именно после этого теста для меня эксперимент стал действительно интересным.
Если разработчик видит:
Уверенность AI: 95%
и рядом:
Ручная проверка: не требуется
очень легко начать воспринимать результат как вывод статического анализатора.
Но это не так.
Уверенность, которую возвращает LLM, — это не математически проверенная вероятность корректности программы.
Это фактически самооценка модели.
Модель вполне может уверенно ошибаться.
Поэтому после этого случая я добавил дополнительную проверку, которая вообще не использует AI.
Проверяем AI обычным кодом
Логика проверки довольно простая.
Анализатор уже знает:
- что изменилось между старой и новой типовой;
- что изменило расширение;
- какие варианты предлагаются для объединения.
Значит можно проверить:
какие именно найденные изменения присутствуют в каждом кандидате.
Для второго конфликта результат получился следующим:
ПРЕДЛОЖЕНИЕ
Типовая: 4/5
Расширение: 25/25
АЛЬТЕРНАТИВА
Типовая: 5/5
Расширение: 25/25
После этого рекомендация Qwen была автоматически помечена как противоречащая исходному коду.
Дополнительно программа смогла показать конкретное изменение, отсутствующее в выбранном моделью варианте — вызов с ВыборкаСтрокЗапасы.Партия.
То есть система фактически сказала нейросети:
«Ты выбрала ПРЕДЛОЖЕНИЕ, но из исходного кода видно, что АЛЬТЕРНАТИВА сохраняет больше изменений новой типовой. Твою рекомендацию нельзя считать доверенной».
На мой взгляд, это оказался один из самых полезных результатов всего эксперимента.
Результаты сравнения
| Показатель | GigaChat-2-Pro | Qwen3-Coder 30B |
|---|---|---|
| Конфликт №1 | Правильно | Правильно |
| Конфликт №2 | Правильно | Неправильно |
| Ошибка с высокой уверенностью | Нет | Да, 95% |
| Первый тест | ~3,4 сек | ~6–7 минут |
| Второй тест | ~6,4 сек | ~82 сек |
| Работа без интернета | Нет | Да |
| Код полностью локально | Нет | Да |
| Нужны свои вычислительные ресурсы | Нет | Да |
Здесь необходимо сделать важную оговорку.
Два конфликта — это не полноценный benchmark.
По двум примерам нельзя утверждать, что одна модель вообще лучше другой.
Можно сделать только более узкий вывод:
в двух конкретных реальных конфликтах BSL GigaChat-2-Pro принял правильное решение два раза, а Qwen3-Coder 30B — один раз из двух.
Для такого небольшого эксперимента это корректнее, чем объявлять победителя.
Значит локальная LLM не нужна?
Нет.
У локального варианта остаётся очень серьёзное преимущество:
исходный код не покидает компьютер или внутреннюю инфраструктуру компании.
Для многих корпоративных разработок это важнее скорости.
Кроме того, локальная модель:
- не зависит от доступности внешнего API;
- не зависит от тарифа внешнего сервиса;
- не зависит от корпоративного прокси;
- может работать без интернета;
- позволяет самостоятельно выбирать модель и размер контекста.
В моём тесте главный недостаток был в производительности.
30B-модель на Ryzen 7 7700 без GPU работает, но ожидание нескольких минут для каждого большого конфликта не всегда удобно.
С современной видеокартой результаты по скорости были бы совершенно другими.
Поэтому вывод здесь скорее такой:
локальная LLM технически вполне пригодна для анализа BSL, но требования к железу имеют значение.
Что оказалось важнее самой LLM
В начале эксперимента идея была примерно такой:
дадим два варианта кода нейросети и посмотрим, какой она выберет.
Но после второго теста архитектура изменилась.
Получилась следующая цепочка:
старая типовая → новая типовая → расширение → обычный diff-анализ → подготовка кандидатов → мнение LLM → независимая проверка рекомендации → решение разработчика → тестовая база 1С.
То есть нейросеть в итоге перестала быть центральным элементом.
Она стала одним из анализаторов.
И мне кажется, что именно так LLM сейчас безопаснее применять при подобных задачах.
Может ли AI автоматически обновлять расширения 1С
После этих тестов мой ответ:
полностью автоматически — я бы пока не доверял.
LLM действительно хорошо умеет:
- читать большие фрагменты BSL;
- объяснять смысл изменений;
- сравнивать старую и новую логику;
- находить изменения бизнес-правил;
- предлагать вариант объединения;
- обращать внимание разработчика на потенциально опасные места.
Но тот же AI способен выдать:
неправильный вариант;
уверенность — 95%;
ручная проверка — не требуется.
Поэтому конечная цепочка должна выглядеть примерно так:
детерминированная проверка → разработчик → загрузка расширения в тестовую 1С → проверка конфигурации → запуск → функциональные тесты.
Даже если алгоритм показывает:
типовая 5/5, расширение 25/25
это ещё не является доказательством корректности BSL.
Это говорит только о том, что конкретные формально найденные изменения не были потеряны.
Например, невозможно таким сравнением гарантировать:
- корректность новой бизнес-логики;
- правильность типов параметров;
- существование всех объектов метаданных;
- правильность выполнения запроса;
- отсутствие ошибки времени выполнения;
- правильность результата печатной формы.
Последнее слово всё равно остаётся за платформой 1С и тестированием.
Ещё один неожиданный результат
При интеграции GigaChat обнаружилась отдельная техническая мелочь.
Модель возвращала правильный ответ в JSON, но внутри строк с BSL встречались неэкранированные управляющие символы.
Фактически содержание ответа было корректным, но строгий JSON-парсер его отвергал.
После этого пришлось добавить ограниченную нормализацию именно таких символов.
Это хороший пример ещё одной особенности интеграции LLM:
нужно проверять не только смысл ответа модели, но и технический формат ответа.
Нельзя просто предполагать, что если в prompt написано «верни JSON», то полученный текст всегда будет идеальным JSON.
Что в итоге показал эксперимент
Первоначальный вопрос звучал примерно так:
«Что лучше для кода 1С: бесплатный облачный GigaChat или локальный Qwen3-Coder 30B?»
После эксперимента мне кажется, что этот вопрос не самый важный.
Гораздо важнее другой:
можно ли проверить ответ нейросети независимо от самой нейросети?
В моём случае хотя бы частично — да.
И это принципиально меняет подход.
Вместо:
AI решил → применяем
получается:
алгоритм обнаружил проблему → AI предложил мнение → алгоритм проверил AI → разработчик принял решение → 1С проверила результат.
Итог
На двух реальных конфликтах расширения 1С GigaChat-2-Pro показал лучший результат и оказался на порядки быстрее локального Qwen3-Coder 30B, запущенного на CPU.
Но локальная модель тоже довольно хорошо понимала BSL, нашла большую часть изменений и полностью правильно решила первый конфликт.
Второй тест показал самое интересное: модель может правильно понять исходные изменения и всё равно сделать неправильный вывод при выборе итогового решения.
Причём с уверенностью 95%.
Поэтому главный вывод этого эксперимента для меня не в том, какая модель победила.
Главный вывод такой:
LLM полезна как второй аналитик, но не как единственный источник истины.
И, возможно, самая важная функция системы с AI — это вовсе не возможность спросить нейросеть:
«Как исправить код?»
А возможность после её ответа сказать:
«Нет. В этом месте исходный код показывает, что ты ошибаешься».
И только после этого решение должен подтверждать разработчик и реальная тестовая база 1С.
Вступайте в нашу телеграмм-группу Инфостарт