Обновление конфигурации с переносом доработок руками ИИ: опыт, границы и грабли

Зачем я вообще это затеял

Любой, кто обновлял типовую конфигурацию с большим объёмом доработок, знает эту боль. Включаешь фильтр по дважды изменённым объектам и открываешь окно трёхстороннего сравнения для каждого объекта метаданных. Пробегаешься по методам объекта и принимаешь решения: что затереть, что оставить, что перенести руками, а где отложить — потому что вендор полностью переработал механизм и старую правку в лоб уже не приложишь. И так объект за объектом. Часы или дни механической работы, которая требует внимания и усидчивости.

И вот в чём идея: основная масса этой работы — это перенос кода из одного места в другое по понятным правилам. А перекладывать код по правилам современные модели умеют. К тому же уже есть готовые MCP-серверы, скилы и другие наработки сообщества. Почему бы не попробовать всё это использовать для избавления от самой рутинной части работы 1С-разработчика.

Идея навеяна статьёй «Автоматизированная разработка 1С через нейросети: как мы собрали конвейер из агентов, инструментов и проверок» и другими.

Схема работы

Ключевой идеей было дать модели три вещи: структурированную информацию о текущих доработках конфигурации, исходный код «до обновления» (на случай, когда нужно посмотреть детали) и целевую конфигурацию, доступ к которой предоставлялся через MCP — практически со всей полнотой функционала EDT по рефакторингу, статическому анализу, проверкам и т.д.

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

Пошагово подготовка выглядела так:

1. Из конфигурации ДоОбновления сохранил отчёт о сравнении с конфигурацией поставщика в текстовом формате. Важно, что в этом файле есть и структура конфигурации, и номера доработанных строк исходной конфигурации: по ним модель может без труда обратиться к нужному месту исходного кода, если перенести правку «в лоб» не получится.
2. Выгрузил конфигурацию ДоОбновления в файлы.
3. Загрузил эти файлы в конфигурацию ДляОбновления.
4. Конфигурацию ДляОбновления обновил до актуального релиза 2.5.27 без переноса доработок.
5. Снял ДляОбновления с поддержки и сделал из неё проект EDT.
6. В проект Claude положил отчёт о сравнении и файлы конфигурации ДоОбновления, а саму конфигурацию ДляОбновления в EDT подключил через MCP-сервер.

В результате получились две конфигурации:

• ДоОбновления — наша рабочая КА 2.5.22 со всеми доработками. Это источник, его трогать нельзя. Эта конфигурация существует и в виде файлов, доступных Claude, и в виде обычной конфигурации, подключённой к хранилищу.
• ДляОбновления — та же конфигурация, обновлённая до 2.5.27 без переноса доработок. Под этим я имею в виду последовательное обновление через конфигуратор сразу на несколько релизов, при котором в окне сравнения-объединения я каждый раз нажимал «ОК» без каких-либо правок — то есть забирал чистый код вендора, затирая все наши доработки (кроме новых объектов метаданных и неизменённых объектов).

Получилась следующая схема доступа:

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

Важная деталь про MCP. Мне не удалось найти MCP-инструмент или скилл, который надёжно обрабатывал бы формы. А если даже одна форма из десяти перенесётся криво, это может не дать сохранить cf или привести к другим неприятным последствиям. Поэтому от переноса доработок форм средствами модели я отказался. Если у вас есть положительный опыт на этот счёт — пожалуйста, поделитесь.

Стек, на котором всё это работало: EDT 2025.2.1, MCP-плагин EDT-MCP версии 1.33, клиент — Claude Code (desktop) для Windows.

Так как это все-таки был эксперимент и в каком-то результате не было никакой уверенности, то параллельно с Claude весь процесс обновления с переносом доработок выполнялся ручками по старинке;

Промпт

Задача: перенести доработки конфигурации КА 2.5 после обновления.
В каталоге текущего проекта в файле `ОтчётОСравнении` — информация о доработках конфигурации до обновления. В каталоге текущего проекта в папке `Конфигурация до обновления` — файлы конфигурации до обновления.
При помощи MCP-сервера у тебя есть доступ к конфигурации после обновления, куда нужно перенести доработки. Если что-то непонятно — спроси.

Примечания:
- Папка `Конфигурация до обновления` очень объёмная — не анализируй там всё подряд, используй точечно: конкретный файл; диапазон строк кода.
- Часть доработок уже может быть перенесена.
- MCP-сервер доступен только для конфигурации `ДляОбновления` — для всех операций с ней используй только его.
- `Конфигурация до обновления` доступна только в виде файлов. Не изменяй их, используй как контекст для переноса.
- Если сильно сомневаешься в правильности переноса — не переноси.
- С особой осторожностью переноси изменения элементов и реквизитов форм. Сомневаешься — не переноси.
- После переноса предоставь структурированную информацию: что получилось, что не получилось, в чём сомневаешься — в иерархии объектов метаданных.

Что получилось хорошо

Перенос кода модулей — что и следовало ожидать. Модули объектов, модули менеджеров, модули форм перенеслись на отлично, разница с ручным переносом была только в пробелах (табуляциях) в строках с комментариями.

Что порадовало:

• МенеджерОбмена, МенеджерРегистрации — огромные модули с кучей мелких и не очень доработок. Модель успешно поняла логику доработок и перенесла их в изменившиеся методы поставщика, в том числе специфический синтаксис отборов менеджера регистрации.
• Дублирование функционала — в новой версии вендор добавил-таки ОсновнойБанковскийСчет организации, который ранее нам пришлось делать самим. Так как в обоих случаях была доработана функция ПолучитьБанковскийСчетОрганизацииПоУмолчанию, модель это поняла и дублировать логику не стала. В итоговом отчете о своем решении дала знать.
• СКД - на то, что модель сможет перенести доработки СКД отчетом, я изначально не надеялся, поэтому попросил об этом (один отчетик) после завершения основной работы, в которой более-менее был уверен. Но на удивление, несмотря на изменившуюся СКД вендора, модель успешно перенесла доработки запроса, поля, ресурсы, новое поле структуры, формат полей и (уже само собой) код ПриКомпоновкеРезультата модуля объекта. Запустил отчет в предприятии - действительно все работает.
• Роли, ввод на основании, состав подсистем и т.п. - мелочь, а приятно

Каждое изменение в целевой конфигурации прогонялось через get_project_errors. Финальное состояние — без ошибок проекта.

Где инструмент упёрся в потолок

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

Что осталось на ручной перенос в EDT:

• Изменения форм — элементы, реквизиты, команды и т.д.
• Макеты — печатные формы и т.д.

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

Главные грабли и вывод: журнал на диске

Проблема. Контекст модели не резиновый — он сжимается. На длинной задаче (а перенос доработок крупной конфигурации — это длинная задача на много сеансов) модель начинает терять из виду, что уже сделано. В моем случае контекст в 1 000 000 токенов сжимался несколько раз. Хуже того: она может «помнить», что чанк готов, хотя реально его не доделала. В моём случае это привело к тому, что были пропущены доработки общих модулей — и всплыло это далеко не сразу. Также в итоговом отчете о проделанной работе часть информации по этой же причине была упущена.

Решение, к которому я (конечно, не я - Claude) пришёл, — вынести статус из контекста на диск. Контекст сжимается, файл — нет. Правила, которые модель предложила заложить с самого начала:

# Правила ведения отчёта о переносе доработок

## Журнал на диске (обязательно)
Веди файл `ОтчётПереноса.md` — это единственный источник правды по статусу.
- В НАЧАЛЕ каждого сеанса сначала прочитай этот файл целиком. Если его нет — создай по шаблону.
- ПОСЛЕ обработки каждого чанка СРАЗУ дописывай строку статуса (не в конце работы, не «потом»).
- Никогда не отмечай чанк готовым по памяти — только после реальной сверки с целевой конфигурацией.

## Формат строки (по чанку/объекту)
`- [СТАТУС] <номер> <ОбъектМетаданных> — <что сделано>; <что отложено/пропущено + причина>`
СТАТУС: x=перенесено, ~=частично, o=отложено, -=пропущено осознанно, пусто=не начато.

## Проверка «снизу вверх»
Статус «перенесено» ставь только после сверки целевой конфигурации:
grep по маркерам доработок (`// МАРКЕР` и т.п.) и по именам функций/реквизитов из чанка. Помни: фича может быть размазана по нескольким объектам (модуль + форма + реквизит) — проверяй ВСЕ части, прежде чем считать её готовой.

## Список задач — гранулярно
Заводи задачи по объектам/чанкам, а не пачками «модули 013–029».

## Память проекта
Устойчивые решения (что отложено и почему, принятые соглашения, паттерны пропуска) сохраняй в память проекта — она подгружается в каждый сеанс.

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

В следующий раз так и сделаю, а пока, может кому-то поможет избежать моих ошибок. 

Что в итоге

10 000 строк отчета о сравнении конфигурации Claude Opus обработал и перенес за 3 пятичасовых лимита 20$ подписки.

EDT проект с итогом работы модели я сохранил в .cf для сравнения со своим (ручным) переносом доработок. Если не считать проблем, описанных выше, модель справилась не хуже меня (местами лучше). Хотелось бы полностью делегировать эту задачу ИИ...

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