Искусственный интеллект уже стал рабочим инструментом для многих разработчиков. В 1С он тоже помогает быстрее разбираться в коде, рефакторить процедуры, писать заготовки новой логики и анализировать технические задания. Но не каждая модель одинаково хорошо справляется именно с задачами 1С.
В этой статье расскажу о своём опыте работы с ИИ и сравню ответы Grok и DeepSeek R1 на конкретной задаче: подключении команд печати через БСП в новом документе 1С:ERP 2.5. Покажу, что предложила каждая модель и насколько полезными оказались ответы. Это не универсальный рейтинг, а практическое сравнение на примере задачи из 1С-разработки
От первых запросов к работе с проектом
Мой первый опыт с DeepSeek был довольно простым: использовал его как помощника для отдельных задач, например работы с XML. Затем попробовал 1С:Напарник в EDT. В основном просил отрефакторить процедуру, отформатировать код или написать документирующий комментарий.
Следующим инструментом стал Cursor. Начал с бесплатной версии и вопросов о том, что делает конкретная процедура. Причём использовал его не только для 1С: в то время я изучал Java, и там он тоже помогал разбираться в коде.
Поворотным оказался эксперимент с задачей, похожей на рабочую. Я описал требования к новому документу в типовой конфигурации и предоставил агенту выгруженные файлы проекта. В ответ получил не просто фрагмент для копирования: агент подготовил документ, формы и программную логику. После этого перешёл на платный тариф и стал пользоваться инструментом активнее.
При этом эксперимент не превратился в повседневную разработку «под ключ». В коммерческих проектах основная помощь ИИ приходилась на анализ и написание кода.
Как я использую ИИ в разработке
Один из полезных для меня сценариев — работа с новой бизнес-логикой. Я передаю задачу, обсуждаю с моделью требования, составляю план и продумываю архитектуру. Затем перехожу к реализации: получаю заготовку кода, перерабатываю её и проверяю результат.
Схема 1. Мой рабочий процесс: модель помогает с решением, доработку и проверку выполняю я.
Отдельное ограничение — конфиденциальность. На коммерческих проектах я не мог просто выгрузить всю конфигурацию и дать агенту работать с ней без ограничений. Поэтому привычный формат оставался таким: получить код, перенести его в конфигурацию, при необходимости изменить и самостоятельно проверить.
Польза для меня не только в том, что модель пишет строки кода. С ней можно разобрать задачу до реализации, обсудить подход и быстрее перейти от требований к конкретному решению. Но принимать результат без собственной проверки я не стал.
Почему я стал искать альтернативы
В сентябре я столкнулся с ограничениями привычного доступа к Cursor. После этого начал использовать OpenRouter и экспериментировать с разными моделями. Однозначной замены, которая одинаково устраивала бы меня во всех задачах, не нашёл: приходилось менять и комбинировать варианты.
К тому моменту у меня сложилось хорошее впечатление о Grok. В моих задачах он удачно работал с контекстом, помогал с логикой, рефакторингом и БСП. От альтернатив хотелось получить сопоставимую помощь.
Однако небольшая правка процедуры и разработка функциональности с использованием библиотечных механизмов — для меня разные проверки. В первом случае бывает достаточно локального изменения. Во втором важно, чтобы модель понимала, как связаны объекты, модули и обработчики. Поэтому для сравнения я выбрал задачу на знание БСП.
Проверка: подключаемые команды печати через БСП
БСП — Библиотека стандартных подсистем. Знание её механизмов и умение быстро подготовить функциональность, похожую на типовую, часто нужны мне на проектах внедрения. Одна задача по печати не охватывает всю разработку на 1С, но для моего сравнения она была показательной.
Обеим моделям я дал одинаковый запрос:
Задача по 1С: разрабатываю новый документ в типовой конфигурации, допустим, 1С:ERP 2.5.
Нужно на форме документа и списка реализовать механизм подключаемой команды печати через БСП и вывод печатных форм.
Каков мой порядок действий? В каких модулях какой код добавлять, что конфигурировать?
Меня интересовала не отдельная процедура, а последовательность подключения: где описать команду, где сформировать печатную форму и что добавить в формы документа и списка.
Далее разбираются два сохранённых ответа и моя оценка их полезности. Названия Grok 4.6 и DeepSeek R1 сохранены по материалам сравнения. Примеры кода и схемы показывают предложения моделей, а не подтверждённую запуском инструкцию для конкретной версии ERP и БСП.
Grok: связал отдельные части решения
Grok начал со связки ПодключаемыеКоманды и УправлениеПечатью. Основную логику предложил разместить в модуле менеджера документа. Сразу посоветовал сверяться с похожим документом той же конфигурации, чтобы не пропустить элементы формы и обработчики.
Описание команды в модуле менеджера
В процедуре ДобавитьКомандыПечати модель добавила команду, задала идентификатор, представление и признак проверки проведения перед печатью:
Фрагмент ответа Grok: описание команды печати
Процедура ДобавитьКомандыПечати(КомандыПечати) Экспорт
КомандаПечати = КомандыПечати.Добавить();
КомандаПечати.Идентификатор = "Накладная";
КомандаПечати.Представление = НСтр("ru = 'Накладная'");
КомандаПечати.ПроверкаПроведенияПередПечатью = Истина;
КонецПроцедуры
Важно, что дальше модель использовала тот же идентификатор «Накладная» в обработке печати. Для меня это признак связного ответа: описание команды не осталось отдельным фрагментом, никак не связанным с последующей реализацией.
Формирование и вывод печатной формы
В процедуре Печать Grok предложил проверить необходимость формирования макета через УправлениеПечатью.НужноПечататьМакет. Затем — сформировать табличный документ и передать его в коллекцию печатных форм:
Фрагмент ответа Grok: обработка печати
Процедура Печать(МассивОбъектов, ПараметрыПечати,
КоллекцияПечатныхФорм, ОбъектыПечати, ПараметрыВывода) Экспорт
Если УправлениеПечатью.НужноПечататьМакет(
КоллекцияПечатныхФорм, "Накладная") Тогда
УправлениеПечатью.ВывестиТабличныйДокументВКоллекцию(
КоллекцияПечатныхФорм,
"Накладная",
НСтр("ru = 'Накладная'"),
СформироватьПечатнуюФормуНакладная(
МассивОбъектов, ОбъектыПечати),
,
"Документ.ВашДокумент.ПФ_MXL_Накладная");
КонецЕсли;
КонецПроцедуры
Само формирование вынесено в СформироватьПечатнуюФормуНакладная. В ней модель показала создание ТабличныйДокумент, задание КлючПараметровПечати и получение макета через УправлениеПечатью.МакетПечатнойФормы. Запрос, обход данных и вывод областей оставлены в комментариях. Это заготовка структуры, а не полностью реализованная печатная форма.
Схема 2. Связи в предложении Grok. Одинаковый идентификатор связывает описание команды и обработку печати; это не полная схема работы БСП.
Подключение к форме документа и форме списка
Ответ не закончился на модуле менеджера. Grok отдельно привёл обработчики формы. Например, при создании и открытии предложил следующие вызовы:
Фрагмент ответа Grok: создание и открытие формы
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
ПодключаемыеКоманды.ПриСозданииНаСервере(ЭтотОбъект);
КонецПроцедуры
&НаКлиенте
Процедура ПриОткрытии(Отказ)
ПодключаемыеКомандыКлиент.НачатьОбновлениеКоманд(ЭтотОбъект);
КонецПроцедуры
Кроме них, модель показала обновление команд при чтении документа, вызов после записи, обработчик Подключаемый_ВыполнитьКоманду, продолжение выполнения на сервере и обновление подключаемых команд. То есть вместо одной кнопки «Печать» описала набор связанных обработчиков.
Для формы списка Grok указал отдельное отличие: в соответствующие вызовы передавать Элементы.Список, а не Объект. Также предложил при необходимости обновлять команды при активации строки списка.
Моя оценка — пять с минусом. Grok понял задачу и описал архитектуру, приведя примеры процедур, которые, на мой взгляд, максимально близки к настоящим.
Минус — за настройку элементов формы. Модель упомянула командную панель, группы и сравнение с рабочим документом, но не расписала, какие именно группы нужно добавить. Поэтому я воспринимаю этот ответ как хорошую основу, а не как готовый функционал, который остаётся только вставить.
DeepSeek R1: подробный ответ, но не тот механизм
Ответ DeepSeek R1 тоже выглядел обстоятельно: подготовка документа, регистрация печатных форм, настройка форм и тестирование. Но за похожей структурой оказалась совсем другая реализация.
Уже на этапе конфигурирования модель предложила найти в свойствах документа такую настройку:
Предложение DeepSeek R1, а не рекомендация к настройке
ПодключаемыеКоманды → ВариантыПодключаемыхКоманд
→ добавить «ПодключаемыеКомандыПечати»Регистрацию печатных форм DeepSeek предложил разместить в модуле объекта и выполнить через ПечатьИОтчеты.ПодключаемыйРегистратор:
Фрагмент ответа DeepSeek R1: спорная регистрация печатных форм
Процедура ПодключитьКомандуПечати(КомандаПечати) Экспорт
ПечатьИОтчеты.ПодключаемыйРегистратор.ЗарегистрироватьПечатныеФормыОбъекта(
Объект.Метаданные(),
ПечатныеФормыДокумента.СписокПечатныхФорм()
);
КонецПроцедуры
Для формы документа модель предложила добавить кнопку «Печать» с таким обработчиком:
Фрагмент ответа DeepSeek R1: предложенный вызов на форме
&НаКлиенте
Процедура Печать(Команда)
ПодключаемыеКомандыПечати.ВызватьКомандуПечати(ЭтотОбъект);
КонецПроцедуры
Для формы списка — вызвать тот же метод, передав выделенные строки. В результате вместо ожидаемой мной схемы подключения получились другой способ регистрации, другие вызовы и фактически сведение работы на форме к кнопке печати.
Моя оценка — два. Это не тот ответ, который я ожидал: по моему впечатлению, DeepSeek здесь в основном додумал код, а не показал знание нужного механизма БСП.
Для разработчика, знакомого с БСП, различие видно по самим предложениям. В ответе Grok я узнаю нужную схему и понимаю, что предстоит дописать. В ответе DeepSeek сначала пришлось бы разбираться, что из предложенного вообще соответствует задаче.
В чём разница двух ответов
Ниже — сопоставление предложений моделей и моей оценки. Это не перечень двух равноправных способов реализации.
Для меня решающим оказался не объём ответа. Обе модели привели код и последовательность действий. Но Grok связал между собой части решения, а DeepSeek предложил конструкцию, которая не соответствует тому механизму, который я хотел использовать.
Что я учитываю при выборе модели
После этого опыта я не стал искать одну модель «для всего». Комментарии, форматирование и небольшие изменения кода — один сценарий. Работа с архитектурой и механизмами БСП — другой. В моих задачах инструмент, который полезен в первом случае, не обязательно даёт подходящий результат во втором.
Словарь терминов к статье
Все комментарии
Чтобы оставить комментарий, необходимо войти или зарегистрироваться.
Пока нет комментариев. Будьте первым!