Как поручить ИИ-агенту доработку 1С:ERP: пошаговый разбор

На Habr вышел разбор, где доработку 1С:ERP выполняла не команда разработчиков, а визуально-языковая модель Qwen3-VL, подключённая к удалённому рабочему столу: агент получал изображение экрана, распознавал элементы Конфигуратора и нажимал по ним мышью. В базе появился шаблон URL, HTTP-метод GET и обработчик, который его вызывает; перед обновлением конфигурации базы агент сохранил бэкап расширения. Доступа к файлам конфигурации и командной строке у модели не было — только картинка и мышь (https://habr.com/ru/articles/1088750/). Ценность примера не в том, что «ИИ умеет в 1С», а в том, что порог входа в мелкую доработку опускается до уровня «объяснить задачу словами и проверить результат глазами». Сколько часов это экономит, зависит от вашей ставки: посчитайте, сколько времени у вашего специалиста ушло бы на ту же правку, и сравните с временем на постановку задачи, прогоны и приёмку.

Ниже — порядок, который переносит этот сценарий в ваш контур. Логика простая: сначала точка отката, потом отдельная копия базы, потом минимальные разрешения агенту, и только затем изменения. Каждый шаг заканчивается проверяемым результатом, а не ощущением, что «вроде сработало».

1. Сформулируйте одну узкую доработку как проверяемый результат. Не «настроить интеграцию», а «в 1С:ERP появляется шаблон URL с методом GET и обработчик, который его вызывает». Результат: фраза, по которой можно однозначно сказать «сделано» или «не сделано».
2. Соберите точку отката до любых экспериментов: полную выгрузку базы и отдельно файл расширения, если доработка идёт расширением. Храните копии вне той машины, на которой будет работать агент. Результат: база поднимается заново, даже если экземпляр на виртуалке испорчен.
3. Разверните отдельную копию базы, а не рабочую: первое изменение агент делает в тестовом контуре. Результат: из окна, где работает агент, рабочая база недоступна.
4. Подготовьте удалённый рабочий стол с запущенным Конфигуратором и открытой нужной базой. Модель работает по изображению экрана, поэтому ей нужен видимый интерфейс, а не путь к файлам конфигурации. Результат: агент видит то же окно, что и вы.
5. Уберите с рабочего стола всё, что не относится к задаче: файловый менеджер, командную строку, доступ к сетевой папке с релизами, ярлыки других баз. Результат: единственное доступное агенту действие — нажатия по видимым элементам интерфейса.
6. Опишите задачу словами, как объяснили бы стажёру, и приложите один эталон: «открой дерево конфигурации, найди общий модуль, добавь шаблон URL с методом GET» плюс скриншот или пример того, как этот объект выглядит в другой базе. Результат: у агента есть и цель, и образец того, что считается правильным.
7. Первый прогон: только навигация, без изменений. Пусть агент откроет Конфигуратор, дойдёт до нужной ветки, откроет форму объекта и остановится. Результат: на скриншотах видно, что он попадает туда, куда вы сказали, и ничего не изменил.
8. Второй прогон: одно безопасное действие. Создание нового шаблона URL подходит лучше всего: это новый объект, который при ошибке удаляется одной кнопкой. Результат: в дереве конфигурации появился новый элемент, названный так, как вы просили.
9. Проверяйте код, а не нажатия: после появления метода GET и обработчика откройте модуль и прочитайте его построчно. Результат: обработчик читает параметры и возвращает ответ; в коде нет обращений к адресам, которых вы не называли, и нет закомментированных заготовок.
10. Потребуйте бэкап расширения перед обновлением конфигурации базы и проверьте, куда он лёг: в разобранном примере агент сохранил бэкап сам, до обновления (https://habr.com/ru/articles/1088750/). Результат: файл расширения существует, а его дата раньше момента обновления.
11. Обновите конфигурацию базы и проверьте результат в режиме предприятия: вызовите метод из тестового клиента или скрипта. Результат: вызов возвращает ответ, а не ошибку, и журнал регистрации не показывает новых исключений.
12. Сравните трудозатраты с ручным выполнением и запишите разницу, отдельно посчитав время на постановку задачи, прогоны, чтение кода и приёмку. Результат: число часов на одну правку, на которое можно опереться в следующий раз.
13. Зафиксируйте регламент: минимальный список запретов — рабочая база, обновление конфигурации без свежего бэкапа, удаление объектов, снятие с поддержки, любые действия за пределами оговорённой задачи. Результат: правила существуют текстом, а не устной договорённостью.
14. Повторите на второй задаче: первый прогон самый долгий, большую часть времени съедает постановка, вторая правка того же типа идёт быстрее. Результат: свой набор формулировок и проверок, не зависящий от конкретной модели.