Claude Code и 1С: агент добавил документ в конфигурацию и проверил его за 3 минуты

Задача знакомая: в конфигурации нет документа «Внутреннее потребление товаров». Нужны склад и список товаров, списание по средней стоимости, как у других складских документов, отказ при нехватке остатка, права и подсистема как у перемещения. Я поручила это агенту Claude Code словами, без ТЗ на десять страниц, и запустила три раза с нуля, каждый раз в чистой копии проекта.

После агента я сама пересобрала базу платформой 1С и прогнала приёмочный тест. Все три прогона закончились ИТОГ: ПРИНЯТО.

В заголовке «3 минуты» - худший прогон (2:56), округлённый вверх. Сюда не входят сборка базы до старта секундомера (25,2 / 15,9 / 17,4 с) и моя пересборка с приёмкой после агента (27, 29 и 34 с). Вместе три прогона обошлись примерно в 1,25 USD.

Быстро получилось потому, что в Нано-УТ рядом лежал близкий образец, а проверка была готова заранее. Ниже о том, что именно это значит, и о том, где такой результат не повторится. Это продолжение разговора об агентах в разработке 1С: Cursor + MCP: собираем рабочее место 1С-разработчика за 15 минут.

Стенд

Агент запускался командой:

claude -p "<prompt.txt>" --model sonnet --output-format stream-json --verbose --dangerously-skip-permissions --setting-sources project --strict-mcp-config

Каталог запуска - копия проекта, ввод закрыт, таймаут 90 минут. Каждое событие агента пишется в agent-stream.jsonl с секундой от старта. Ключ --dangerously-skip-permissions отключает запросы подтверждения, поэтому я включала его только в копии проекта; на рабочей базе не стала бы. Ключи --setting-sources project и --strict-mcp-config поставила, чтобы на прогон не влияли мои личные настройки и MCP-серверы.

Что получил агент

Задача дословно, файл prompt.txt:

В учебной конфигурации Нано-УТ 2.0 (каталог src) нет документа «Внутреннее потребление товаров», а в УТ 11.5 он есть. Добавь его по образцу УТ 11.5: склад и табличная часть товаров (номенклатура и количество).
При проведении документ списывает товар со склада по средней стоимости, как это уже делают другие складские документы Нано-УТ, и не даёт уйти в минус: если на складе товара меньше, чем в документе, проведение отклоняется и ничего не записывается.
Права ролей и подсистема у нового документа такие же, как у перемещения товаров.
Собери базу (tools\build.ps1), проверь модули (tools\check.ps1) и добейся, чтобы tools\accept.ps1 выдал ИТОГ: ПРИНЯТО. Скрипты в tools и CLAUDE.md не меняй.
В конце коротко напиши, что сделал.

В проекте лежит CLAUDE.md на 21 строку. Там нет подсказок о том, как писать документ: только как устроен проект (конфигурация живёт в src, база ib собирается скриптом, образцы - документы в src\Documents и общие модули), три команды и правила:

• сборка: powershell -NoProfile -ExecutionPolicy Bypass -File tools\build.ps1, занимает 10-30 секунд;
• проверка модулей: tools\check.ps1;
• приёмка: tools\accept.ps1, печатает ОК: или ОШИБКА: по каждой проверке и в конце ИТОГ: ПРИНЯТО либо ИТОГ: НЕ ПРИНЯТО;
• менять только src; Конфигуратор и 1С в интерактивном режиме не запускать; сборку и приёмку одновременно не гонять, потому что файловую базу открывает один процесс.

Скрипты приёмки лежат в tools, и агент их читал: во всех трёх прогонах в журнале есть вывод текста accept.ps1. Менять скрипты CLAUDE.md запрещает. Хеши SHA-256 папки tools и CLAUDE.md до и после прогона сравнивались, во всех трёх прогонах изменений нет.

Что проверяет приёмка

Тест accept.ps1 работает с базой через COM-соединение. Каждый запуск создаёт свой склад, свой товар и своего поставщика с разным суффиксом, а поступлением на 10 шт. по 41,37 (всего 413,70) заводит остаток.

Пункт б проверяет результат в регистре ТоварыНаСкладах, способ расчёта тест не навязывает.

Как я проверила саму приёмку

Приёмка, которую можно пройти пустой конфигурацией, ничего не стоит. Поэтому до прогонов тест запускался на трёх версиях базы (выводы в STAND-report.md):

Эталон тоже писала модель: отдельный агент, который собирал стенд по моему заданию, без секундомера. По его отчёту, на чтение движка и код ушло 10-15 минут. Сколько это займёт у разработчика, который видит Нано-УТ впервые, я не измеряла.

Эталон и мутант лежали вне копии проекта, с которой работал агент. В журналах трёх прогонов обращений к ним нет.

Прогон 1 по секундам

Хронология строится скриптом timeline.py по agent-stream.jsonl. Вывод скрипта по журналу прогона 1 (длинные команды скрипт обрезает, тот же текст в logs/timeline.txt):

Человеческими словами. До 54-й секунды агент только читает: структуру src, документ «Перемещение товаров» с модулем объекта, общие модули ТоварыУчет и ДокументыУчета, упоминания перемещения в ролях, подсистеме и Configuration.xml, формы перемещения, модуль печати. На 67-й секунде он пишет Python-генератор, который копирует перемещение под новым именем с новыми UUID и правит остальные файлы. На 82-й исправляет синтаксическую ошибку в этом же генераторе. К 117-й секунде первый запуск приёмки даёт НЕ ПРИНЯТО: генератор снова упал, документа в конфигурации нет. На 128-й агент правит вторую ошибку, и к 164-й секунде приёмка проходит. Отчёт он пишет на 173-й секунде, всего 11 ходов.

Что агент поменял

Во всех трёх прогонах набор правок одинаковый, различается только печать.

• Новый документ Documents\ВнутреннееПотреблениеТоваров: XML документа, модуль объекта и три формы (объекта, списка, выбора) - десять файлов. Агент скопировал перемещение, выдал новые UUID, убрал склад-получатель. Реквизиты: Склад, Комментарий, СуммаДокумента, табличная часть Товары (Номенклатура, Количество).
• Проведение: ветка в ТоварыУчет.
• Порядок проведения: в ДокументыУчета приоритет 65, после перемещения (60) и до инвентаризации (70).
• Права: три роли (Администратор, Оператор, Чтение), права скопированы с перемещения.
• Подсистема «Склад» и Configuration.xml.
• Печатная форма в ПечатьСервер: прогоны 1 и 2 добавили её сами, в задаче о печати ничего не было. Прогон 3 печать не трогал, поэтому у него 17 файлов вместо 18.

Вся логика списания уместилась в три строки. Фрагмент changes.diff, прогон 1 (в прогонах 2 и 3 строки те же):

1
2
3

        ИначеЕсли Событие.Тип = "ВнутреннееПотреблениеТоваров" Тогда
            Стоимость = Списать(Состояние, Данные.Склад, Номенклатура, Количество);
            Движение(Состояние, Событие, Данные.Склад, Номенклатура, Количество, Стоимость, Ложь);

Контроль остатка агент не писал. В отчёте прогона 3 прямо сказано: Списать уже выбрасывает исключение, если свободного остатка меньше количества, строки одного товара суммируются, а при исключении проведение откатывается целиком. Приёмка это подтверждает: при 7 шт. на остатке 6 ошибка приходит из общего модуля ТоварыУчет: Недостаточно свободного товара.

Вместе с образцом агент унёс реквизит СуммаДокумента. В отчётах прогонов 1 и 3 он объяснил, зачем оставил его: общая процедура ДокументыСервис.ПроверитьИРассчитать пишет эту сумму у каждого документа. Для списания сумма не считается, поэтому в списке документов колонка «Итого» пустая (рис. 5). Это след копирования: в задаче такого реквизита не было, приёмка его не проверяет.

Где агент ошибался

• Прогон 1. Генератор упал на синтаксисе: обратный слеш в строковом литерале на строке 25. Агент поправил замену через sed. Затем генератор упал второй раз: os.makedirs получил пустой путь. Приёмка на 117-й секунде показала НЕ ПРИНЯТО, потому что документа не было. Исправлено в одну команду.
• Прогон 2. Та же ошибка с пустым путём в makedirs, исправлена одной правкой. Две попытки прочитать много файлов за раз обрезались, и агент перешёл на чтение по частям и инструментом Read.
• Прогон 3. Агент проверил переводы строк, посчитав символы возврата каретки в исходных файлах. Исходники оказались с LF, поломки не было.

Моя ошибка в обвязке: run_agent.py считал «первый ИТОГ: ПРИНЯТО» по строке в выводе. Когда агент просто читал текст accept.ps1, в котором эта строка есть, секундомер засчитывал его как успех: 33 с в прогоне 1 и около 14 с в прогоне 3. Эти значения лежат в summary.txt и result.json, они неверны. Счётчик запусков тоже путается: в прогоне 2 check и accept шли одной командой, и accept посчитан за ноль. Верные цифры в таблице выше взяты из timeline.py, который считает только запуски скриптов: 164, 100 и 145 с.

Как это выглядит в 1С

Приёмка работает через COM, окна она не открывает. Поэтому после прогонов я взяла копию базы прогона 1, завела в ней понятные данные скриптом ui_demo_data.ps1 (склад «Основной склад», товар «Бумага А4, пачка», поступление 10 шт. по 41,37, потребление 4 шт. с проведением и потребление 7 шт.) и открыла формы в тонком клиенте. Формы открывались ссылкой из командной строки (/URL e1cib/...), без щелчков мышью: проводила документы я скриптом, кнопку «Провести» в форме не нажимала.

Потребление 7 шт. при остатке 6 скрипт провести не смог. На снимке повторный прогон того же сценария данных на чистой базе (журнал первого прогона: logs/ui-demo-data.txt):

Документ записан без проведения, в списке он стоит с отметкой «Нет». Две верхние строки списка остались от приёмки, она создаёт свой склад с суффиксом при каждом запуске.

В регистре «Товары на складах» у документа № 3 одна строка расхода: 4 шт. на 165,48, то есть 4 × 413,70 / 10.

Форма документа открылась без ошибок, поле склада-получателя агент из неё убрал. Блок «Учёт на дату» внизу формы пустой, его я не разбирала.

Быстро из-за образца, и это не везде повторится

Агенту хватило нескольких минут по таким причинам.

1. Единый движок. В Нано-УТ складское проведение идёт через один механизм: УчетСервер.Пересчитать при каждом проведении переигрывает все проведённые документы базы по дате и приоритету. В части учёта новому документу нужны только ветка в ТоварыУчет и приоритет в ДокументыУчета. Агент повторил чужую архитектуру, свою придумывать не пришлось.
2. Близкий образец. Перемещение товаров почти совпадает с нужным документом: склад, таблица товаров, те же права и подсистема. Копирование с переименованием закрыло большую часть работы.
3. Готовая приёмка и CLAUDE.md с командами. Агент знал, как собрать базу, как проверить модули и когда остановиться. Без accept.ps1 результата в таком виде нет: он получил бы документ, но не узнал бы, правильно ли тот списывает.

Из этого не следует, что любую доработку типовой УТ агент сделает за три минуты. Нано-УТ мала и устроена прозрачно: 293 файла, один движок. Там, где логика размазана по подпискам, регистрам и расширениям, образца может не оказаться, и приёмку придётся писать самой.

Не проверено:

• типовая УТ 11.5, хотя в промпте на неё ссылка как на образец: агент её не видел, он работал только с Нано-УТ;
• другие модели и другие агенты, в том числе Cursor;
• задачи без близкого образца в конфигурации;
• работа в форме руками: формы я открыла и сняла, но документы проводила скриптом, кнопками формы не пользовалась;
• выборка в три прогона на одной модели: разброс по времени (1:49 - 2:56) виден, а по качеству результата данных мало;
• агент читал текст приёмки и знал, что в ней проверяется. Скрытая приёмка могла бы дать другой результат.

Как повторить у себя

1. Распакуйте архив. В корне run_agent.py, timeline.py, prompt.txt и каталог template: чистая выгрузка Нано-УТ 2.0 без нового документа (src), tools и CLAUDE.md. Рядом журналы трёх прогонов и result-run1\src - выгрузка с документом из прогона 1.
2. Распакуйте в любую папку вне OneDrive: run_agent.py в архиве берёт папку стенда по месту самого скрипта (в моих прогонах путь был жёсткий, C:\nopik-agent1c). Проверка архива из чистой распаковки: заглушка --dry на нетронутой Нано-УТ даёт «НЕ ПРИНЯТО», выгрузка result-run1\src после сборки - «ПРИНЯТО».
3. Если платформа лежит не по пути C:\Program Files (x86)\1cv8\8.3.27.2130\bin\1cv8.exe, задайте переменную окружения NANO_PLATFORM.
4. Проверьте обвязку без расхода модели: python run_agent.py 1 --dry.
5. Запустите прогон: python run_agent.py 1. Скрипт копирует шаблон, собирает базу, сверяет хеши tools, запускает claude, после агента пересобирает базу и гонит приёмку. Каталог уже существующего прогона он перезаписывать откажется.
6. Смотрите runs\run1\summary.txt, accept-final.txt, changes.diff, а хронологию по секундам даёт python timeline.py runs\run1\agent-stream.jsonl.
7. Для своей задачи замените prompt.txt и приёмку: тест, который проходит пустая конфигурация, проверьте на нетронутой базе, на эталоне и на мутанте, как в этой статье.

Нужны Claude Code, платформа 1С 8.3.27 (x86), Windows PowerShell 5.1 и Python 3. COM-часть приёмки перезапускает себя в 32-разрядном PowerShell.

Вопрос к читателям

Какую складскую доработку типовой УТ вы поручили бы агенту первой и что у вас уже есть для проверки результата: тест, обработка, второй разработчик? Если пробовали агента на УТ 11.5 или КА, напишите версию, задачу и шаг, на котором он застрял. Постараюсь собрать такой же стенд и прогнать.

Итог

• Агент Claude Code (Sonnet 5.5) добавил документ в Нано-УТ 2.0 за 1:49 - 2:56 работы в трёх прогонах, и независимая приёмка после каждого прошла.
• Проведение уместилось в три строки в общем модуле: образец рядом и единый движок учёта сделали работу короткой.
• Результат держится на готовой приёмке, проверенной на нетронутой базе, эталоне и мутанте. Без неё остаётся только отчёт агента.
• Не проверено: УТ 11.5, другие модели и агенты, задачи без образца, проведение кнопкой из формы.

Источники

• Документация Claude Code: запуск без интерактива, ключ -p и формат stream-json
• Документация 1С:Предприятия 8.3.27: ключи командной строки Конфигуратора /LoadConfigFromFiles, /UpdateDBCfg, /CheckModules
• Cursor + MCP: собираем рабочее место 1С-разработчика за 15 минут (Ninel_S, 22.09.2026)

Файл к статье

Архив claude-code-nano-ut-companion.zip (цена 1 SM): стенд (run_agent.py, timeline.py, prompt.txt, template с чистой выгрузкой Нано-УТ 2.0, tools и CLAUDE.md, скрипт данных для снимков ui_demo_data.ps1), журналы трёх прогонов (agent-stream.jsonl, timeline.txt, summary.txt, result.json, accept-final.txt, changes.diff) и выгрузка с документом из прогона 1. Для запуска нужны Windows, платформа 1С 8.3.27, Python 3 и Claude Code.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S