Все примеры и расчеты взяты из личной практики. Статья актуальна на конец августа 2026 года: ИИ-инструменты меняются быстро, часть конкретики устареет в течение года.
Эта статья для моих коллег — программистов 1С, которые про ИИ слышали, но пока не поняли, что с ним делать в ежедневной работе. Здесь только обзор: что такое современные ИИ-инструменты, где они помогают в 1С, где мешают и с какими особенностями придется столкнуться именно нам. Моя позиция: ИИ уже стал рабочим инструментом разработчика 1С, он ускоряет работу, но не сделает ее вместо вас.
Если вы пробовали и остались недовольны результатом, скорее всего, вы пробовали не то. Спросить в чате у российской модели, как написать функцию, и работать с агентом внутри проекта — два разных занятия, и результаты отличаются на порядок.
Термины: LLM, промпт, контекст, агент
Дальше по тексту эти слова встречаются постоянно. Один раз прочитать словарь проще, чем каждый раз спотыкаться на незнакомом термине.
LLM (Large Language Model) — большая языковая модель. По сути математическая функция с миллиардами параметров, которая анализирует и генерирует текст, в том числе программный код. Для программиста 1С это значит, что модель объяснит незнакомый код, найдет ошибку, напишет и переделает процедуру, поможет с запросом и документацией.
Промпт — инструкция или запрос, который вы даете модели. Чем точнее описаны задача и ограничения, тем полезнее результат.
Контекст — информация, которую модель получает вместе с запросом: исходный код, файлы проекта, документация, предыдущая переписка. Чем сложнее задача, тем важнее правильно собрать контекст.
Токен — небольшой фрагмент текста, которым модель оперирует вместо привычных нам букв и слов. Токеном может быть целое слово, часть слова, знак препинания или даже пробел. Для английского текста один токен — это в среднем около 4 символов. В токенах измеряется и объем контекста, и стоимость работы облачной модели.
Контекстное окно — максимальный объем информации, который модель способна учитывать одновременно, измеряется в токенах. В большое окно помещаются и десятки файлов исходников, и куски документации.
Агент — обвязка вокруг модели, которая превращает ее текст в действия. Агент читает и пишет файлы, запускает команды в терминале, выполняет запросы, поэтому способен сам пройти цепочку: найти нужный модуль, изучить код, внести изменения, запустить проверку, исправить найденную ошибку.
Скилл — записанная один раз инструкция, которую ИИ подключает сам, когда берется за задачу определенного типа. Например: как в 1С передать файл с клиента на сервер, как оформить новый объект по стандартам компании. Промпт вы пишете каждый раз заново, а скилл лежит в проекте и подхватывается автоматически.
SDD (Spec-Driven Development) — разработка по спецификации. Сначала для ИИ подробно описывают, что именно должно быть сделано и какие ограничения соблюдать, и только затем модель реализует задачу.
Галлюцинация — ситуация, когда модель уверенно выдает информацию, которая выглядит правдоподобно, но является неправильной. Например, придумывает несуществующую функцию 1С.
Какие модели справляются с 1С
Для практической разработки на 1С сегодня уверенно работают старшие модели Anthropic (Claude), OpenAI (GPT) и xAI (Grok). Они держат в контексте десятки файлов исходников, разбираются в структуре проекта и выполняют задачу из нескольких шагов: найти нужный модуль, прочитать связанный код, внести правку, проверить результат.
Кроме них на слуху Gemini от Google, GLM от китайской Zhipu AI и DeepSeek — тоже китайские модели, популярные в том числе благодаря открытым и относительно доступным вариантам. Номера версий я намеренно не указываю. Модели обновляются несколько раз в год, и любой список конкретных версий может устареть быстрее, чем статья дойдет до читателя.
Чем агент отличается от модели
Модели вы задаете вопрос и получаете ответ. Агент действует: читает файлы проекта, вносит правки, запускает команды, смотрит на результат и делает следующий шаг сам. Вместо вопроса, как написать этот код, вы даете ему проект и задачу.
Важный для нас момент: агент работает с файлами. Готовых интеграций с Конфигуратором нет, поэтому в 1С агенты применяются через внешние инструменты разработки — Cursor, Claude Code, GitHub Copilot и другие. Как именно организовать агенту доступ к конфигурации — вопрос с большим количеством нюансов, он заслуживает отдельного разбора.
Почему не нужна отдельная модель для 1С
Язык 1С — обычный процедурный, ничего экзотического в его синтаксисе нет. Сложность кроется в платформе: в объектной модели, типовых механизмах и учетной логике. А это передается модели через контекст: исходники, документацию, ваши пояснения. Отдельная обученная на 1С модель здесь мало что добавит.
Специфика 1С: кириллица, XML, расширения
Описанные выше принципы универсальны и работают для любого языка. Теперь о том, что касается 1С.
Кириллица дороже. Русские идентификаторы модель дробит на токены мельче английских, поэтому один и тот же по объему модуль на 1С стоит заметно больше токенов, чем сопоставимый код на английском. Так вышло потому, что токенизаторы обучались в основном на английских текстах и русские слова целиком в их словарь не попали. Свою роль играет и то, что символ кириллицы в UTF-8 занимает 2 байта против 1 у латиницы. Следствия два: контекстное окно забивается быстрее и работа облачной модели обходится дороже.
XML отдавать модели не стоит. Метаданные и формы в выгрузке конфигурации лежат в XML, и агент технически способен их править. Делать этого не надо: структура объектов и формы остаются за Конфигуратором или EDT, а модели достается код. Цена ошибки здесь — испорченная конфигурация.
Границы, впрочем, двигаются. Мне несколько раз удавалось корректировать файлы правил обмена, не запуская КД2 вовсе, а коллеги собрали внешнюю обработку полностью с нуля, без Конфигуратора — структуру, форму и код в модулях. Но это удачные эксперименты, а не практика. Доверять модели XML пока рано.
Расширения. Для правки типовых расширение — основной безопасный сценарий. Изменения отделены от поставки, обновление не превращается в разбор конфликтов. Агенту так тоже удобнее: он видит небольшой обособленный набор файлов вместо всей типовой конфигурации.
Документация как контекст. Синтакс-помощник и статьи ИТС — готовый материал для контекста. Если задача касается редкого механизма платформы, дешевле сразу дать модели описание из документации, чем потом проверять придуманное.
Где ИИ ошибается в 1С
1С представлена в обучающих данных скромнее массовых языков, поэтому в специфичных местах модель иногда промахивается. Например, подмешивает в язык запросов 1С конструкции SQL, путает обычные и управляемые формы, ошибается в директивах компиляции. За последнее время ситуация заметно улучшилась, и то, что раньше приходилось переписывать целиком, сейчас чаще требует небольшой правки. Но проверять надо.
Метод, которого нет. GLM понадобился обработчик двойного клика по таблице формы — и она его просто придумала: ДвойнойКлик(). Такого события в платформе нет. Когда я указал на ошибку, модель полезла искать в интернете, ничего подходящего не нашла и придумала следующий несуществующий обработчик. Вывод здесь важнее самого случая: модель не умеет сказать «я не знаю». Она выдает самый правдоподобный вариант, а если правдоподобного нет — все равно выдает.
Возможное невозможно. Grok не знал, как передать файл с клиента на сервер и обратно, и довольно настойчиво убеждал меня, что в 1С это невозможно в принципе. Механизм, который платформа поддерживает штатно много лет. И это при том, что в остальном Grok — из тех моделей, которые реальные задачи тянут. Закончилось тем, что я написал под эту задачу отдельный скилл, и с тех пор вопрос закрыт.
Общее у обоих случаев. Чем реже механизм встречается в открытых источниках, тем выше шанс, что модель либо придумает несуществующий метод, либо станет уверенно отрицать существующий. Оба симптома опознаются мгновенно, если вы знаете платформу, и совершенно незаметны, если вы ее только осваиваете.
Где ИИ реально помогает 1С-разработчику
- анализ конфигурации — что здесь вообще происходит, как связаны объекты, как устроен механизм
- поиск точек входа в незнакомом коде — где начинается обработка документа, откуда вызывается процедура, что сработает при записи
- написание кода — от отдельной процедуры до законченного механизма по описанию
- разбор чужого кода — объяснить логику модуля, который никто не помнит
- рефакторинг — разделить разросшуюся процедуру, привести код к стандартам
- запросы и СКД — собрать запрос по описанию, разобрать чужой на части
- разбор ошибок — по тексту сообщения и фрагменту кода найти причину
- тесты и code review — сгенерировать проверки, посмотреть на код свежим взглядом
Как это выглядит на живой задаче. УТ10 на обычных формах, много лет доработок от разных программистов в разных стилях, от типовой осталось немного. Требовалось научить обработку «Клиент банка» создавать по определенному комментарию в выписке не тот документ, который создает типовой механизм, а другой. Руками я разбирался бы в этой обработке 3–4 дня.
С ИИ ушло 2,5 часа. Час на подготовку — настроить проект, дописать правила, собрать подробный промпт со скриншотами; 10 минут у Grok на то, чтобы разобраться в чужом коде и выдать сразу 4 варианта решения, с рисками каждого и с оглядкой на дальнейшее сопровождение; час на выбор варианта вместе с моделью и перенос кода руками; полчаса на проверку.
Экономия выходит не всегда. На иных задачах ее почти нет, а бывает, что с моделью получается и дольше. Главное, что не пришлось 3 дня держать в голове чужую путаную логику. Когнитивная нагрузка ниже, голова к концу дня свежее. Выгорание же появляется ровно тогда, когда всё наоборот.
Где ИИ помогает хуже
- учетная бизнес-логика — модель не знает вашей методологии учета и договоренностей с заказчиком, поэтому уверенно напишет корректный по синтаксису и неверный по смыслу код (хотя и здесь многое решают контекст и точная постановка)
- работа с формами — интерактивное поведение и раскладка элементов плохо описываются текстом, быстрее сделать руками
- оптимизация под реальные данные — поведение запроса зависит от объемов и индексов конкретной базы, а этого модель не видит
Лучше всего с ИИ работают мидлы
Наблюдение, обидное для джунов и сеньоров. Джун слишком доверяет модели, а часто и не может за ней проверить — для этого надо знать платформу 1C лучше, чем знает ее модель. Сеньор попадает в обратную ловушку. Он держит все под жестким контролем, каждую правку переписывает по-своему и в итоге работает по-старинке, головой и руками, а модель остается для него забавной игрушкой. У мидла знаний уже хватает, чтобы увидеть подвох, а привычки все делать самому еще нет.
Дело тут в двух крайностях: слишком доверять модели и не отпускать контроль. Обе поправимы.
Промпт решает больше, чем выбор модели
Типичная история. У пользователя была отключена одна из функциональных опций, и программа штатно предупреждала об этом окошком. Пользователь прислал скриншот с подписью «У нас такая-то ошибка». Разработчик перенес формулировку пользователя в промпт как есть — «Пользователь жалуется на такую-то ошибку» — и приложил скриншот. Модель увидела слово «ошибка» и принялась героически ее устранять, причем так, чтобы она больше никогда не повторилась. В итоге предложила переписать половину конфигурации.
Только ошибки на самом деле не было. Была штатная реакция программы на отключенную настройку. Но в промпте стояло слово «ошибка», и модель добросовестно решила ровно ту задачу, которую ей поставили, — а не ту, которую имели в виду. Ошибка в постановке при этом настолько естественная, что через нее проходят все, включая меня.
Второй случай помельче, но весьма показателен. Я сократил в промпте «смотри» до «см.». Модель прочитала это как сантиметры, и следующие 2 промпта ушли на объяснение, что я имел в виду.
Модель не переспрашивает и не сомневается в вашей постановке. Она принимает ее за истину и оптимизирует именно то, что написано. Поэтому в промпте важны:
- факты вместо пересказа чужих слов — что именно видит пользователь, при каких действиях, что вы ожидали увидеть
- явно названная задача — «разобраться в причине» и «исправить» это разные поручения
- привязка к контексту — какая конфигурация, какой объект, какой модуль, что уже проверено
- отсутствие сокращений и двусмысленностей: пишите так, как написали бы новому сотруднику, который платформу знает, а вашу базу нет
Правила проекта. У агентских инструментов есть файлы правил (rules, AGENTS.md), которые подмешиваются в контекст автоматически. Один раз описываете в них стандарты (префиксы новых объектов, что разрабатывать в конфигурации и что в расширении, чего не трогать) и перестаете повторять это в каждом промпте.
Скиллы. Если правила действуют всегда, то скилл подключается под конкретный тип задачи. Как только вы заметили, что второй или третий раз объясняете модели одно и то же, это готовый скилл. Написали один раз, дальше модель берет его сама.
SDD для крупных задач. Для большой задачи сначала пишете с моделью спецификацию: что нужно сделать, каких ограничений держаться, что считать результатом. Читаете ее, правите, соглашаетесь — и только потом даете реализовывать. Выходит дольше на старте, зато исключает ситуацию, когда модель поняла задачу по-своему и вместо решения написала 3 бесполезных модуля.
Как проверять код, который написал ИИ
Работать с ИИ без версионирования нежелательно. Git или хранилище конфигурации здесь обязательны: должно быть видно, что именно агент изменил, и должна быть возможность откатиться обратно одним движением.
Код, который предложила модель, в любом случае лучше переносить в конфигурацию руками. Иногда иначе и не выйдет: конфигурацию, подключенную к хранилищу, из файлов не загрузить. Но и когда такого ограничения нет, ручной перенос дает более надежный контроль. Вы просматриваете каждый фрагмент в тот момент, когда он попадает в конфигурацию.
Синтаксический контроль, проверка конфигурации, прогон сценария — здесь ничего нового, все то же, что при обычной разработке. Меняется статус ревью: код писали не вы, а значит прочитать его глазами обязательно. И только человек ответит на вопрос, соответствует ли результат учетной логике и стандартам компании.
Цена ошибки в 1С выше обычной. Иногда это реальный риск испортить данные в базе, а потом неделями разгребать последствия вручную.
Локальный ИИ для 1С: имеет ли смысл
Модели, которые запускаются прямо на своем компьютере, для серьезной разработки пока сильно уступают лучшим облачным. Мощная локальная модель требует большого объема оперативной или видеопамяти, и обычный компьютер программиста 1С полноценной замены облаку не дает.
Главный аргумент за них — данные никуда не уходят. Беречь имеет смысл действительно чувствительную информацию: реальные персональные данные, коммерческие условия. Код типовой конфигурации секретом не является.
Заодно два понятия, которые чаще всего всплывают именно в разговоре о локальных моделях. Цифры 7B, 30B, 70B — приблизительное количество параметров модели: 7, 30, 70 миллиардов (B — billion, миллиард). Больше параметров обычно означает более сильную модель, но сравнивать модели только по этому числу нельзя: архитектура, обучение и качество данных значат не меньше.
«Температура» — параметр, влияющий на случайность генерации. При низкой температуре модель отвечает предсказуемее и стабильнее, при высокой чаще выбирает нестандартные варианты. Для кода полезна низкая: нам нужна не творческая импровизация, а корректный и воспроизводимый результат. У локальных моделей температуру задает сам пользователь, в облачных сервисах доступа к ней обычно нет.
Доступ и цены для разработчиков из России
Российских моделей, пригодных для реальной разработки, сегодня нет. С задачами уровня «объясни фрагмент кода» они еще справляются, хотя и там галлюцинаций хватает. А настоящую работу с проектом не тянут. Поэтому приходится пользоваться зарубежными нейросетями, и отсюда вытекают свои сложности с доступом и оплатой.
Доступ. Большинство иностранных сервисов в России недоступны, а карты российских банков отклоняются при оплате. Вопрос решаемый, но к теме статьи не относится.
Цены. Начальная подписка на агентский инструмент стоит 20 долларов в месяц. Дальше идут промежуточные тарифы — в Cursor это 60 долларов, в Claude Code 100 — и верхний тариф на 200 долларов, выше практически ни у кого нет.
Подписка почти всегда выгоднее оплаты по API. В нее входит больше токенов, чем вы получили бы, потратив ту же сумму напрямую. В августе 2026 года я сравнил свои тарифы и получил вот что: в Cursor за 60 долларов реально доступен объем, который по ценам API стоил бы около 109. На верхних тарифах разрыв доходит почти до двух раз. А если месячный лимит закончился раньше срока, работу обычно можно продолжить по API — уже за фактическое потребление.
Заменит ли ИИ программиста 1С
В ближайшее время нет. Модель может быстро выдать убедительно выглядящий код с ошибкой или неправильно понять бизнес-логику. Результат надо проверять — тем внимательнее, чем ближе задача к данным.
При этом ИИ уже пригоден для повседневной разработки на 1С. Пользы больше всего там, где он работает как помощник программиста: анализ существующего кода, поиск точек входа, написание и рефакторинг процедур, запросы, разбор ошибок и документации.
Лучший способ составить свое мнение — попробовать. Возьмите задачу, которую вы и так собирались делать руками, и пройдите ее вместе с моделью. Начать лучше с безобидного: разобрать чужой модуль, собрать запрос, дописать внешнюю обработку — там, где ошибка не стоит ничего.
Статья актуальна на конец августа 2026 года.
