ИИ-агент в 1С-разработке: как не сжечь токены и получить рабочий результат

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

Но есть нюанс.

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

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

ИИ экономит время не тогда, когда ему отдают всё подряд, а когда разработчик умеет управлять контекстом.

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

ИИ в разработке — это не автопилот

Самая опасная ошибка — воспринимать ИИ-агента как самостоятельного разработчика, которому можно отдать задачу целиком и просто ждать готовый результат.

Например:

“Вот весь проект. Сделай обработку. Исправь ошибки. Улучши код. Проверь всё”.

Звучит удобно. На практике часто получается дорого и непредсказуемо.

ИИ начинает читать много лишнего контекста. Тратит токены на файлы, которые не нужны для текущей задачи. Может попытаться улучшить то, что не просили. Может поменять форму, модуль, структуру проекта, комментарии, имена процедур и попутно внести изменения, которые потом сложно отделить от нужных.

Для 1С это особенно чувствительно.

В 1С многое завязано не только на текст модуля. Есть управляемые формы, реквизиты формы, команды, клиент-серверные директивы, XML-структура формы, события, табличные части, макеты, расширения, настройки прав. Код может выглядеть логично, но форма после правки перестанет открываться.

Поэтому я бы формулировал роль ИИ так:

ИИ-агент — это сильный помощник разработчика, но не владелец результата.

Он может ускорить работу. Но ответственность за проверку, архитектуру и выпуск остается у разработчика.

Где ИИ реально помогает 1С-разработчику

В моей практике ИИ особенно полезен там, где нужно быстро разложить задачу, подготовить черновик решения или увидеть причину, которую сам уже замылил взглядом.

Хорошо подходят такие задачи:

• подготовка фрагментов кода;
• разбор ошибок и возможных причин;
• рефакторинг длинных процедур;
• поиск дублирования логики;
• подготовка шаблона функции или процедуры;
• разделение большой задачи на этапы;
• описание изменений после правки;
• подготовка тест-кейсов;
• создание чек-листа проверки;
• объяснение чужого кода;
• подготовка технического описания;
• оформление инструкции для пользователя;
• помощь в формулировке промпта для следующей итерации.

Например, если есть ошибка в модуле формы, можно не просить ИИ “разобраться во всей обработке”. Достаточно дать конкретный фрагмент кода, текст ошибки или скриншот и попросить:

“Найди вероятную причину ошибки. Не переписывай весь модуль. Предложи минимальную правку и объясни, что проверить после изменения”.

Это уже нормальный рабочий запрос.

ИИ хорошо помогает и с рефакторингом. Когда процедура разрослась, можно попросить предложить структуру: что вынести в отдельные функции, какие проверки объединить, где лучше убрать дублирование. Но лучше не давать команду “сразу всё перепиши”. Сначала — план. Потом — одна точечная правка. Потом — проверка.

Где ИИ может навредить

ИИ может ошибаться. Причем иногда очень уверенно.

В 1С я бы особенно осторожно относился к таким зонам:

• управляемые формы;
• изменения XML формы;
• клиент-серверные директивы;
• права и роли;
• обмены и интеграции;
• запись данных в базу;
• массовая обработка документов;
• регламентные задания;
• расширения конфигурации;
• сложная бизнес-логика без описанного процесса.

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

В конфигурации это еще опаснее.

Если агент внес лишние изменения, потом может быть сложно понять, что именно он поменял и почему после этого начало падать. Особенно если правки затронули несколько объектов сразу.

Поэтому важное правило:

Чем сложнее объект 1С, тем уже должна быть задача для ИИ.

Не “улучши форму”.

А “в модуле формы исправь только обработчик команды, Form.xml не трогай, новые реквизиты не добавляй, остальные процедуры не менять”.

Главная ошибка: выбирать слишком дорогой режим для простой задачи

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

На первый взгляд кажется логично: чем сильнее модель и чем выше режим рассуждения, тем лучше результат.

Но в реальной работе это не всегда так.

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

Это как вызывать архитектора на замену подписи у кнопки.

Для экономии токенов и времени полезно разделять задачи по сложности.

Идея простая: не нужно платить максимальной ценой за каждую мелочь.

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

Chat или Agent: сначала подумать, потом править

Я разделяю два режима работы.

Первый — обсуждение. Второй — правка файлов.

Для обсуждения удобно использовать чат с ИИ. Там можно разобрать архитектуру, план, возможные риски, варианты реализации, ошибки в подходе. В этом режиме ИИ не должен ничего менять. Он должен помочь подумать.

Для правки файлов нужен агент в редакторе кода или проекте. Но к нему лучше идти уже с понятной задачей.

Плохой вариант:

“Посмотри проект и сделай как надо”.

Хороший вариант:

“Открой только модуль формы. Исправь расчет длительности. Файл формы не трогай. Не меняй имена существующих процедур. После правки перечисли, какие процедуры изменил и что проверить в 1С”.

Сначала можно обсудить подход в чате. Потом дать агенту точечный промпт на изменение файлов.

Так меньше лишних правок, меньше расход токенов и выше шанс получить рабочий результат.

Как экономить токены в 1С-разработке

Токены сгорают не только из-за длинных ответов. Они сгорают из-за лишнего контекста.

Если дать агенту весь проект, он будет тратить ресурс на чтение того, что не относится к задаче.

Я бы выделил несколько практических правил.

1. Прикладывать только нужные файлы

Если ошибка в модуле формы, не нужно сразу давать всю выгрузку обработки, все XML, макеты и картинки.

Сначала достаточно:

• модуля формы;
• текста ошибки;
• скриншота, если ошибка визуальная;
• краткого описания, что делал пользователь.

XML формы нужен только если задача связана со структурой формы, реквизитами, командами, элементами или ошибкой открытия, которую нельзя понять по модулю.

2. Не просить повторять весь код в ответе

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

Лучше попросить:

• кратко описать изменения;
• указать измененные процедуры;
• перечислить риски;
• дать список проверок.

Это экономит токены и внимание.

3. Работать маленькими итерациями

Большая задача почти всегда лучше делится на шаги.

Например, не так:

“Сделай всю обработку: форму, загрузку, сравнение, экспорт, настройки, проверки и инструкцию”.

А так:

1. Сначала создать структуру формы и основные реквизиты.
2. Потом реализовать загрузку данных.
3. Потом добавить сравнение.
4. Потом вывести результат в таблицу.
5. Потом добавить экспорт.
6. Потом обработать ошибки.
7. Потом подготовить инструкцию.

После каждого шага — проверка в 1С.

4. Давать результат проверки, а не всю историю заново

После итерации лучше написать:

“Форма открылась. Команда выполняется. При сохранении файла ошибка: такой-то текст. Вот процедура и скриншот”.

А не пересказывать всю постановку задачи с нуля.

ИИ нужен новый факт: что проверили и где упало.

5. Явно писать, что нельзя менять

Это одно из самых полезных правил.

Если нельзя трогать форму — так и написать.

Если нельзя менять структуру данных — написать.

Если нужно сохранить имена процедур — написать.

Если правка должна быть только в одном файле — написать.

ИИ не всегда сам поймет границы задачи. Границы нужно задавать явно.

Шаблон промпта для ИИ-агента

Я бы не усложнял. Хороший промпт для 1С-доработки должен отвечать на несколько вопросов.

Пример:

Режим: агент, правка файлов.
Цель: исправить ошибку при открытии формы обработки.
Файлы: сначала смотреть только модуль формы. XML формы не менять без отдельного согласования.
Что нельзя менять: не переименовывать существующие процедуры, не менять структуру формы, не добавлять новые реквизиты.
Задача: найти причину ошибки и внести минимальную правку.
Ответ: перечислить измененные процедуры, объяснить причину, указать риски.
Проверить после: открытие формы, выполнение основной команды, отсутствие новых ошибок при закрытии формы.

Такой промпт не идеален на все случаи, но он задает рамки.

А рамки для ИИ-агента очень важны.

Какие задачи лучше дробить на маленькие шаги

Чем больше задача затрагивает объектов, тем сильнее ее нужно дробить.

Особенно это касается:

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

Например, если нужно сделать отчет, не стоит одной командой просить:

“Сделай отчет полностью”.

Лучше идти так:

1. Согласовать структуру данных и поля отчета.
2. Подготовить запрос.
3. Проверить запрос на тестовых данных.
4. Сделать вывод результата.
5. Добавить отборы.
6. Добавить проверки пустых данных.
7. Проверить права и доступность.
8. Оформить пользовательские сообщения.

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

Для форм — еще осторожнее.

Сначала логика. Потом команды. Потом элементы формы. Потом проверка открытия. Потом пользовательские сценарии.

Что обязательно проверять после ИИ

ИИ может написать убедительно. Но 1С проверяет честнее.

После правок я бы обязательно проверял:

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

Особое внимание — открытию форм.

Форма может падать даже после небольшой правки. Особенно если затронуты реквизиты, команды, события, клиент-серверные процедуры или данные формы.

Также нужно смотреть, что именно изменил агент.

Не только “работает или нет”, но и:

• не поменял ли он соседнюю логику;
• не удалил ли важную проверку;
• не добавил ли лишнюю зависимость;
• не сделал ли слишком общий обработчик;
• не ухудшил ли читаемость кода;
• не оставил ли временные комментарии или отладочный код.

Хорошая практика — после каждой итерации просить агента кратко перечислить измененные места. Но проверять это всё равно нужно глазами и запуском в 1С.

Информационная безопасность: что нельзя отдавать в ИИ

Отдельный важный блок — информационная безопасность.

ИИ может быть полезным помощником, но это не причина отправлять ему всё подряд.

В запросы не стоит вставлять чувствительные данные:

• пароли;
• токены доступа;
• ключи API;
• реальные персональные данные;
• паспортные данные;
• телефоны и адреса сотрудников или клиентов;
• коммерческие условия;
• реальные договоры;
• конфиденциальные документы;
• закрытую финансовую информацию;
• внутренние URL, если они раскрывают инфраструктуру;
• секреты подключения к базам и сервисам.

Для разработки чаще всего можно подготовить обезличенный пример.

Например, вместо реального контрагента:

ООО “Ромашка”, ИНН 0000000000, договор “Основной”.

Вместо реального URL:

https://example.local/api/documents

Вместо реального токена:

<TOKEN>

Вместо реального документа — структура полей и тестовые значения.

Если ошибка зависит от данных, можно передать:

• структуру объекта;
• тип реквизитов;
• пример без реальных значений;
• текст ошибки;
• фрагмент кода без секретов;
• скриншот с замазанными данными.

Здесь лучше потратить пять минут на очистку контекста, чем потом объяснять, почему чувствительные данные ушли во внешний инструмент.

ИИ не должен видеть больше данных, чем нужно для решения задачи.

Это правило хорошо работает и для безопасности, и для экономии токенов.

Пример нормальной итерации

Допустим, есть внешняя обработка. После правки форма перестала открываться.

Плохой запрос:

“Вот обработка, исправь всё”.

Нормальная итерация:

1. Дать текст ошибки или скриншот.
2. Приложить модуль формы.
3. Сказать, что форму и XML пока не менять.
4. Попросить найти вероятную причину.
5. Попросить минимальную правку.
6. После правки открыть форму в 1С.
7. Если ошибка осталась — дать новый текст ошибки и только нужный фрагмент.

Такой подход может показаться медленнее, чем “сделай всё сразу”.

Но на практике он часто быстрее. Потому что не приходится потом разгребать пачку лишних изменений.

Как понять, что вы хорошо поставили задачу ИИ

Есть простой критерий.

Если после промпта ИИ понятно:

• что именно нужно сделать;
• где именно работать;
• что нельзя менять;
• какой результат вернуть;
• как проверять результат;
• какие данные нельзя использовать;
• какая следующая итерация возможна;

значит задача поставлена нормально.

Если промпт звучит как “посмотри всё и сделай хорошо”, скорее всего, токены будут расходоваться неэффективно.

Мини-чек-лист перед запуском ИИ-агента

Главный вывод

ИИ-агент может быть очень полезен в 1С-разработке.

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

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

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

Я бы оставил главный тезис таким:

ИИ экономит время не тогда, когда ему отдают всё подряд, а когда разработчик умеет управлять контекстом.

И еще один:

Чем точнее задача для ИИ, тем меньше токенов сгорает впустую.

ИИ не отменяет разработчика. Он усиливает того, кто понимает задачу, контролирует изменения и проверяет результат.

В 1С это особенно важно.

Потому что “почти правильно” в тексте может означать “форма не открывается” в реальной базе.