ИИ-агент написал обработку для девяти типовых: разбор пилота
Я 1С-разработчик, больше шести лет занимаюсь внедрением и доработками. Последние недели строю своё ядро автоматической разработки. Идея простая: человек находит задачу и ставит её, агент пишет код, сам собирает обработку и прогоняет тесты на копиях типовых конфигураций, второй агент принимает работу по постановке, а человек отвечает на вопросы и проверяет результат руками.
Чтобы понять, где такой конвейер ломается, нужны настоящие задачи, а не учебные. Одной из пилотных стала обработка «История изменений за период»: кто, что и когда менял в документах и справочниках. Строчки кода в ней я руками не написал. Зато всё, что сделал агент, проверено: автотесты на девяти конфигурациях и ручная проверка по плану из 29 шагов. Ниже рассказываю, как это было, по журналам конвейера и истории изменений, с цифрами и с ошибками.
Сначала боль, потом код
Задачу я не придумывал. Сначала агент прочитал через браузер то, о чём пишут заказчики и коллеги: 95 заказов на бирже Инфостарта, страницы популярных публикаций с просмотрами, загрузками и комментариями, темы на форумах Инфостарта, «Мисты» и buh.ru. Только чтение, без входа на сайты. За несколько дней до этого был такой же разбор 100 заказов биржи за три месяца.
Из этого получилась таблица из 11 болей. Первые пять: кто, что и когда менял в базе; битые ссылки, которые нельзя починить без Конфигуратора; пакетная рассылка печатных форм; перенумерация документов; что сломалось после обновления. Первое место заняла история изменений. Вопрос возникает в любой базе, а у популярных решений в комментариях вопросы про новые релизы, про пустой результат и одни и те же просьбы: кто удалил реализацию, отбор по номенклатуре, изменения задним числом. Эти просьбы почти готовая постановка. А у меня есть ферма, на которой обработку можно проверить на каждом релизе. Разбор лёг в репозиторий в 23:06, постановка обработки появилась в 23:24 того же вечера.
Типовое версионирование объектов показывает историю одного документа из его карточки. Если нужно понять, кто за неделю распровёл три реализации и у какого заказа поменяли сумму, приходится открывать каждый объект или читать журнал регистрации, который бухгалтеру почти нечитаем. Отсюда требования: одна внешняя обработка на все типовые с Библиотекой стандартных подсистем (БСП), ничего своего в базу не пишет, работает в безопасном режиме и в 1С:Фреш, списки видов и реквизитов строит из метаданных, а не зашивает под релиз.
Так выглядит готовая лента изменений.
Как устроен стенд
У меня есть ферма копий типовых конфигураций. Для этой задачи в проверку вошли девять: Управление торговлей 11.5 и 11.6, Комплексная автоматизация 2.5.27 и 2.5.22, Бухгалтерия предприятия 3.0, Зарплата и управление персоналом 3.1, Управление нашей фирмой 3.0, Розница 3.0 и Бухгалтерия для Казахстана 3.0. Платформы 8.3.27 и 8.5.1.
Задача идёт по фазам. Я пишу постановку, конвейер делает по ней карточку, дальше агент пишет код и тесты, собирает обработку и прогоняет проверку на основной базе: тесты на YAxUnit, открытие формы из «Дополнительных отчетов и обработок» и из файла, снимки экрана. Потом второй агент принимает работу: сверяет сделанное с постановкой и пишет замечания. После приёмки та же сборка проверяется на всех базах, и собирается пакет публикации с описанием, инструкцией и снимками.
Пишет код старшая модель Claude Opus 5.5, принимает работу и готовит тексты младшая Sonnet 5.5. Агент работает только в папке задачи: выйти за неё или удалить файлы ему не даёт отдельный сторож. За задачу он попробовал сделать это 15 раз, все попытки отклонены.
Постановка и первая ночь
Постановка заняла 69 строк: источник данных (регистр версий БСП и её программный интерфейс), настройки, лента изменений в поле HTML-документа, таблица для печати и Excel, поведение на больших периодах, объяснение пустого результата, список баз и сценарий теста. В тесте агент сам включает версионирование, меняет сумму и контрагента, распроводит документ, удаляет строку с номенклатурой, переименовывает элемент справочника и проверяет, что обработка всё это нашла с верным автором и значениями «было» и «стало».
Постановку я отдал в 23:24. В 03:12 был готов пакет версии 1.0.0 на девять конфигураций, через 3 часа 48 минут. Первые четыре прогона на основной базе были красными, с пятого тесты пошли зелёными.
Самое интересное в первую ночь: агент не согласился с постановкой и доказал это тестом. Я просил показывать физически удалённые объекты по их последней версии. Агент выяснил, что измерение «Объект» в регистре версий ведущее: удаляешь объект, и платформа удаляет всю его историю. В тесте было видно: версий до удаления одна, после ноль. Поэтому удаления он стал брать из журнала регистрации и честно написал в описании, что во Фреше и без права на журнал удаления не видны.
Когда агент останавливается и спрашивает
За конвейерную часть агент дважды сам остановился и попросил решения.
Первый раз на Управлении торговлей 11.6: при открытии формы на ферме вылезало модальное окно БСП о переходе на новую версию платформы, потому что база запускалась на 8.3.27, а релиз рекомендует 8.5.1. Агент не стал обходить окно, а описал причину и предложил перевести базу на 8.5.1, которая на ферме уже была. Мой ответ занял две минуты.
Второй раз интереснее. Тест на формат чисел дважды падал с одной ошибкой. Агент разобрался, что дело не в формате: при записи у строки табличной части заполняется ещё одна ссылочная колонка, а строки сопоставлялись по всем ссылочным колонкам, поэтому изменённая строка выглядела как «удалена» и «добавлена». Подгонять тест он не стал, а предложил два варианта с рекомендацией. Вот его сообщение, немного сокращённое:
Та же ошибка дважды подряд: тест
ЧислаПоРазрядностиИзМетаданных. Остальные 15 тестов зелёные, формат сумм работает. Причина: у первой строки «Товары» реализации при записи заполняется ссылочная колонка. Строки табличной части сопоставляются по всем ссылочным колонкам, поэтому изменённая строка показана как «удалена строка 1» и «добавлена строка 1», и количество в ленту не попадает. Это не ошибка формата, а ограничение сопоставления строк.Что решить (рекомендую вариант А).
А. Улучшить сопоставление: сначала по всем ссылочным колонкам, затем оставшиеся строки по номеру строки при совпадении номенклатуры. Тогда строка показывается как изменённая, включая количество. Тест не меняется.
Б. Оставить сопоставление, а тест проверять только там, где строка сопоставилась.
Я выбрал вариант А за 40 секунд.
Ещё два раза конвейер остановил аварийный предел в 50 долларов, который стоит против зацикливания агента. Агент не зацикливался, просто задача шла уже четвёртый круг. После этого предел стал считаться на версию, а не на всю задачу.
Где агент ошибался и что из этого вышло
Ради этого раздела пилот и затевался. Почти каждая ошибка ниже закончилась новой проверкой или правилом в ядре, чтобы следующая задача на ней не споткнулась.
Ссылки в ленте нажимались не всегда. Я заметил это руками: после отборов ни одна ссылка в ленте не открывала объект. Причина оказалась в проверке номера изменения из адреса ссылки:
// было
Если ... Или СтрДлина(СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке(Части[1])) <> СтрДлина(Части[1]) Тогда
// стало
Если ... Или Не СтроковыеФункцииКлиентСервер.ТолькоЦифрыВСтроке(Части[1]) Тогда
Функция БСП возвращает Булево, а не строку из цифр. Длина строкового представления «Да» равна двум, поэтому ссылки работали только у изменений с двузначным номером. Ошибка жила с версии 1.0.0, и автотесты её не видели, потому что вызывали серверную функцию, а не нажимали ссылку. После этого в проверке появился настоящий клик по странице поля HTML-документа: сценарий нажимает ссылку с однозначным номером, на старом коде он красный, на новом зелёный. А в ядре появилась проверка, которая знает, какой тип возвращают функции БСП, и ловит такое сравнение ещё до запуска.
Поиск в списках за четыре захода. Мне нужна была обычная строка поиска над списками видов и реквизитов. Агент сначала сделал свои поля, потом штатный поиск набором, потом отбор на клиенте, и только на четвёртый раз всё решило свойство таблицы ПоложениеСтрокиПоиска, которое я показал ему в Конфигураторе. Вывод для ядра: если требование к интерфейсу можно понять двумя способами, агент сначала спрашивает человека и открывает справку платформы, а не пробует варианты по очереди.
В пакет попала старая сборка. После правок по замечаниям приёмки агент поменял исходники, но обработку не пересобрал, а проверка приняла прежний результат. В пакет ушёл файл предыдущей итерации, а один снимок оказался не тем. Поймала перепроверка после приёмки. Теперь у каждой сборки есть отпечаток исходников, и проверка с пакетом отказываются работать на устаревшей сборке.
Часовой пояс журнала регистрации. Ночью прогон всех баз покраснел на Комплексной автоматизации 2.5.22: тест не находил удалённый документ. У демобазы часовой пояс Москва, у компьютера фермы Иркутск, и отбор журнала по дате начала в тонком клиенте терял события после полуночи по времени компьютера. Вечером даты совпадали, поэтому всё было зелёным. Теперь при разных поясах обработка читает журнал без даты начала и сама проверяет период по дате события.
Четыре бага, найденные проверкой кода. Проверка по стандартам нашла то, что тесты пропустили. «Уксус 9%1л» в заголовке карточки превращался в «Уксус 9Ал», потому что подстановка параметров в строку заменяла «%1» в самом наименовании. Наименование с </script> ломало страницу. Правка терялась, если объект после неё записали ещё раз без изменений. Автор удаления у регламентных заданий подбирался случайно. На эти случаи появился тест: на старом модуле он красный, на исправленном зелёный.
«Объект не найден» у заказов. На снимке для публикации у заказа в истории была строка с битой ссылкой. Агент раскопал в коде типовой: при смене клиента Управление торговлей удаляет прежний элемент «Объекты расчетов» непосредственно, без проверки ссылок, а старые версии заказа продолжают на него ссылаться. Теперь такая ссылка показывается словами, с пометкой «удалён», а замена объекта расчетов на такой же новый не считается изменением.
Так это выглядело до исправления.
Что пилот дал конвейеру
Из одной этой обработки в ядре выросло 17 задач на доработку. Самые важные из них такие.
Карточка задачи больше не подтверждается сама. Если в постановке есть неясность, конвейер останавливается на этапе уточнения, задаёт вопросы и ждёт ответа, а не отдаёт агенту додумывать. Это вывод в том числе из истории с поиском в четыре захода.
Формы теперь проверяются сценариями через тест-клиент: открыть, набрать в поиске, отметить флажок, нажать «Сформировать». На пилоте такие сценарии прошли 5 из 5. Раньше ни один тест не видел, что своё поле поиска затирает набранные буквы.
Появились правила для агента: сначала красный тест, который воспроизводит ошибку, потом исправление; проверять граничные значения; факты о платформе брать из справки, а не из памяти; сначала искать штатное средство платформы и только потом писать своё.
Предел против зацикливания считается на версию, сборка проверяется по отпечатку, повторный прогон всех баз не запускается, если агент только что их проверил на той же сборке. Снимки для публикации делаются на отдельных демонстрационных данных, а не на данных автотестов. И считается покрытие кода тестами: на тестах этой обработки проба показала 86 процентов.
Ещё ядро теперь отдельно считает замечания, которые нашёл человек, а не проверки. По этой задаче их набралось 25. Это главный показатель, который я хочу снижать.
Сколько это стоило и почему так дорого
Работал я по подписке, поэтому суммы ниже в пересчёте на цены API, то есть сколько стоили бы те же запросы при оплате каждого. В конвейерной части агент запускался 30 раз, сделал 1311 ходов и работал около 12 часов чистого времени.
| Круг | Что делали | Стоимость, $ | Время агента |
|---|---|---|---|
| 1 | Версия 1.0.0 с нуля до пакета на девять баз | 24,15 | 3 ч 46 мин |
| 1, правки | Инструкция для пользователя, суммы по разрядности, снимок пустого результата | 6,45 | 1 ч 40 мин |
| 2 | Страница «Во времени»: объект по шагам, версия 1.1.0 | 11,35 | 1 ч 42 мин |
| 3 | Сводка настроек, результат во всю высоту, режим «Рядом» | 5,55 | 56 мин |
| 4 | Поиск и флажки в списках, исправление «по шагам» | 13,73 | 3 ч 49 мин |
| Итого | 61,22 | 11 ч 53 мин |
После этого был ещё день доводки вне конвейера: часовой пояс, ссылки, проверка кода, снимки на чистых данных. Он в таблицу не вошёл.
Почти вся сумма приходится на старшую модель: 56 долларов из 61. Один прогон приёмки младшей моделью стоил от 33 до 60 центов. Дорогими оказались первый заход и переделки интерфейса, особенно круг со списками.
Для готовой обработки это дорого, и я этого не скрываю. Но пилот был нужен не ради обработки. На основной базе было 53 прогона проверки, из них 21 красный, и каждый красный прогон показывал, где агент или сам конвейер спотыкается. Тестов стало 31 вместо 14 в начале. Сколько будут стоить следующие задачи после этих правок, посмотрю на них и напишу отдельно.
Что осталось человеку
Найти боль и написать постановку. Отвечать на остановки агента: в этой задаче ответы заняли от 30 секунд до 18 минут. Решать спорное: что делать с удалёнными объектами, как сопоставлять строки. Проверить руками по плану из 29 шагов, потому что часть ошибок видна только человеку. И написать описание, выбрать цену, переснять снимки на чистых данных, чтобы в галерее не было следов автотестов.
Пять правил, если код пишет агент
1. Проверять на настоящих конфигурациях. На основной базе всё было зелёным, а ночной прогон по всем девяти нашёл ошибку часового пояса только на одной из них. Если обработка заявлена для девяти конфигураций, каждая сборка должна пройти на каждой.
2. Тест должен делать то, что делает пользователь. Серверная функция возвращала правильные данные, тесты были зелёными, а ссылку в ленте нельзя было нажать. Пока тест не кликал по странице, эту ошибку видел только я.
3. Сначала красный тест, потом исправление. Если тест не падал на старом коде, неизвестно, ловит ли он ошибку вообще. Теперь это правило ядра: на найденную ошибку агент сначала показывает красный прогон и только потом исправляет.
4. Агент должен уметь остановиться. Два одинаковых падения подряд, неясность в постановке или перерасход денег означают вопрос человеку с вариантами, а не новую попытку наугад. Четыре захода с поиском в списках как раз о том, что бывает без этого.
5. Человек всё равно проверяет руками, и его находки надо считать. По этой задаче я нашёл 25 замечаний, которые не поймали проверки. Это честная мера того, насколько конвейеру можно доверять, и по ней видно, становится ли он лучше.
Итог
Обработка вышла на Инфостарте 21 октября: «История изменений за период». В первые же дни её начали скачивать, значит боль настоящая. Код открыт, один файл работает на всех девяти конфигурациях из списка.
Режим «Рядом»: слева лента, справа история выбранного объекта по шагам.
Главный вывод пилота для меня: ИИ-агент уже способен сделать обработку под 1С от постановки до пакета публикации, но без фермы, тестов на реальных конфигурациях и человека на спорных местах результату нельзя доверять. Ошибки агента похожи на ошибки разработчика, просто их больше и они другие, поэтому основная работа ушла не в код, а в проверки. Следующие задачи из того же анализа рынка пойдут через этот конвейер, и я посмотрю, насколько он стал лучше.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
