Всем привет, с вами Низамов Илья. Я поставил задачу кодовому агенту и получил рабочий обмен 1С с сайтом: интернет-магазин на WordPress с категориями, фильтрами, карточками товаров и корзиной — и расширение для «1С:Управление торговлей 11» с собственной админкой обмена. Всё это написал Claude Code с моей обвязкой Harness 1С. Ушло 2,5 часа и чуть больше 600 тысяч токенов.
Ниже — что получилось, что агент придумал и сделал сам, что пришлось решить мне как разработчику 1С, и почему главная работа была не в коде, а в техническом задании.
Это четвёртая часть цикла про Harness 1С. Как устроена сама обвязка — MCP-серверы, контекстная подсказка платформы и оркестратор — я разбирал в статье про автономного AI-агента для разработки 1С. Здесь — первый большой проект, написанный этой связкой целиком.
Что получилось за 2,5 часа работы агента?
Начну с конца — с результата.
На стороне сайта: магазин на WordPress с выгруженной из 1С иерархией групп, работающими фильтрами, карточкой товара, корзиной и началом оформления заказа. Дизайн агент взял из готового markdown-файла с описанием темы, который я скачал заранее.
На стороне 1С: расширение конфигурации с собственным префиксом, подсистемой в командном интерфейсе, регистром настроек, очередью выгрузки, логом обмена, регистром сопоставления и формой администрирования с расписанием регламентного задания.
База — обычная демо-база «Управление торговлей 11». Я не готовил её специально: поставил свой MCP-сервер для работы с 1С, создал пустое расширение с префиксом — и дальше действовал агент.
Про масштаб. В базе 219 непомеченных позиций номенклатуры: 26 групп и 193 товара, дерево глубиной в четыре уровня — «Торговая деятельность → Продукты → Кондитерские изделия → Праздничные наборы». Одиннадцать товаров лежат прямо в корне справочника, без группы, — про них будет отдельный разговор. Полная выгрузка идёт около 80 секунд и заканчивается строкой в форме: «Категорий выгружено: 26, товаров: 193, ошибок: 0».
Почему нельзя просто сказать агенту «сделай обмен с сайтом»?
Типичный сценарий у тех, кто только поставил себе кодового агента: выгрузили конфигурацию в файлы, написали «сделай мне обмен с сайтом» или «перепиши расчёт себестоимости, чтобы работал в десять раз быстрее» — и ждут.
Так это не работает. И дело не в том, что модель слабая.
Агент не знает вашу архитектуру решений. Он не знает, что настройки в этой базе принято держать в регистре сведений, а не в константах. Что план обмена здесь избыточен. Что клиенту удобнее расширение, а не внешняя обработка. Что артикул в этой базе заполнен не у всех позиций, поэтому сопоставлять надо иначе. Всё это — не знание платформы, а знание практики, и оно есть только у вас.
Claude — очень сильный инструмент, но он не отменяет вашего опыта работы с платформой. Он отменяет ручное написание кода.
Зачем ИИ-агенту техническое задание?
Поэтому первый этап — не разработка, а совместное написание технического задания. Выглядит это так: вы говорите, что хотите; агент идёт в базу, анализирует конфигурацию и задаёт наводящие вопросы; вы как разработчик отвечаете — сделай регистр с настройками, сделай админку, регистрируй через регистр сведений, логируй сюда.
Получается документ, где расписано всё: какие подсистемы, какие общие модули, какие регистры, какие реквизиты, какие скрипты агент будет использовать на каждом этапе и что вообще делать нельзя.
Обратите внимание на последний раздел ТЗ — «Чего делать нельзя». В работе с агентом он оказывается не менее важным, чем список задач: границы вы задаёте явно, иначе агент начнёт «улучшать» типовую конфигурацию.
Вот как этот раздел выглядит на практике: не править общие инструменты — правка меняет условия сразу у всех; не копировать файлы из образца как есть — в них чужие идентификаторы, и расширение просто не соберётся; не класть адреса и пароли в код; не считать работу сделанной по файлам в папке, если она не доехала до базы; не отчитываться без прогона. Половина пунктов — не про 1С, а про дисциплину.
На этом же этапе агенту полезно дать пару поручений в сторону: сходить на GitHub и посмотреть, как похожая задача решена в открытых проектах, или разобрать по описанию продуктов, как это устроено у конкурентов. Он найдёт, скачает и заимствует рабочие решения — это дешевле, чем изобретать протокол с нуля.
Ниже — восемь решений, которые в этом проекте принял я, а не агент. Пройдите их и соберите свой вариант ТЗ: счётчик покажет, сколько решений вы всё-таки оставили на усмотрение модели.
Почему работу пришлось разбить на этапы?
2,5 часа — это сумма нескольких заходов, а не один непрерывный сеанс. Задача такого размера в один контекст не помещается, и упирается это не в модель, а в память: к середине работы контекст съеден разбором ошибок, и агент перестаёт помнить, с чего начинал.
Поэтому работа разбита на этапы, и каждый ведёт отдельный агент с чистым контекстом: разведка базы → окружение → объекты расширения → транспорт → категории → товары → очередь и расписание → форма настроек → витрина → приёмка. Этапы идут строго по очереди, и не ради аккуратности: база одна, и два агента, одновременно взявшие её конфигуратором, гарантированно ломают друг другу прогон.
Главное здесь — как передаётся контекст. Не разговором: следующий агент не слышал ни одного вашего вывода и историю чата не читает. Передаются три файла, и ведёт их сам агент:
- план этапа — что сделать и чем проверить;
- решения — почему сделано так, а не иначе;
- грабли — что не сработало и почему.
Кто заканчивает этап — дописывает их последним, кто начинает — читает первым. Не записал — значит не передал, и следующий агент пойдёт по тому же кругу.
Второе правило, без которого первое не работает: у этапа должен быть проверяемый выход — прогон, а не слово «сделано». Категории выгружены — дерево видно на сайте. Товары выгружены — сверка молчит. Иначе следующий агент наследует чужую иллюзию и чинит не то.
Что агент сделал до первой строки кода в 1С?
Дальше начинается часть, которая меня удивила больше всего. До того как написать хоть один модуль расширения, агент собрал себе стенд:
- завёл себе копию рабочей базы на 1,9 ГБ, чтобы не трогать оригинал;
- поднял в Docker тестовый стек WordPress;
- нашёл (или написал сам — я не уточнял) MCP-сервер для работы с WordPress и подключил его к себе: через MCP ему удобнее общаться с сайтом, чем через голый HTTP;
- установил на сайт нужные плагины и простую тему;
- создал пользователя WordPress и выпустил ему пароль приложения, заложив возможность защищённого соединения на будущее.
То есть окружение для собственной работы он подготовил сам. От меня потребовалась только выгруженная база и пустое расширение с префиксом.
Пароль приложения здесь принципиален: это штатный механизм WordPress, отдельные учётные данные для внешней системы, которые можно отозвать, не трогая пароль пользователя. Ключи WooCommerce (consumer key и secret) агент оставил запасным путём — на случай, если у клиента будет закрыт REST-эндпоинт самого WordPress. Подробный разбор самого протокола обмена с плагином — в отдельной статье про WooCommerce и 1С, здесь я на нём не останавливаюсь.
Как устроено расширение: настройки, очередь и лог обмена?
Каркас обмена получился таким.
Регистр сведений «Настройки» — адрес сайта, порт, пользователь, пароль приложения, таймаут, вид цены (выгружается розничная), корневая группа, склад, признак защищённого соединения, выгружать ли пометку удаления, использовать ли полное наименование. Регистр, а не константы — это моё решение на этапе ТЗ: такие настройки клиент меняет сам, и они должны быть данными, а не кодом.
Регистрация к обмену — через регистр сведений, а не через план обмена. Это тоже мой подход, и я его сознательно навязал агенту. План обмена тащит за собой узлы, сообщения, номера сообщений и правила квитирования — весь этот аппарат нужен для двустороннего обмена между базами. Для односторонней выгрузки каталога на сайт достаточно очереди: записали позицию — она встала в список, выгрузили — ушла из списка.
Работает это через подписку на событие записи справочника:
// Подписка на "ПриЗаписи" справочника "Номенклатура".
// Обработчик в общем модуле расширения ставит позицию в очередь на выгрузку.
Процедура НоменклатураПриЗаписи(Источник, Отказ) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Запись = РегистрыСведений.nsdp_СписокОбменаССайтом.СоздатьМенеджерЗаписи();
Запись.Объект = Источник.Ссылка;
Запись.ДатаИзменения = ТекущаяДатаСеанса();
Запись.Выгружен = Ложь;
Запись.Записать();
КонецПроцедурыПроверяется это в базе за пять секунд: открываете любую позицию номенклатуры, записываете, закрываете — и она появляется в списке обмена.
Лог обмена — отдельный регистр, куда пишется каждая операция. Про него ниже отдельный разговор: его настоящая ценность вылезла не там, где я ожидал.
Регистр сопоставления — пары «товар в 1С ↔ товар на сайте». Без него повторный обмен создаёт каталог заново, и на сайте появляются дубли.
Ниже — карта всего обмена целиком. Кликните по узлу: увидите, что он делает и кто его придумал — я в техническом задании или агент по ходу разработки.
Сторона подключения выглядит обычно: базовая авторизация паролем приложения, таймаут и признак защищённого соединения — всё из того же регистра настроек. Транспорт при этом не выбрасывает исключений наружу: каждый вызов возвращает результат с кодом ответа и текстом ошибки. Это тоже пункт ТЗ, а не самодеятельность: обмен идёт по одному объекту, и падение на пятидесятом не должно стирать сведения о первых сорока девяти.
Решение, которое агент не стал принимать сам
Те самые одиннадцать товаров в корне справочника, без группы. Сайт товар без категории проглотит, а приёмка — нет: товар без категории считается ошибкой выгрузки, а не особым случаем.
У агента было три пути: молча положить такие позиции в корневую группу, молча их не выгружать или спросить. Он не стал выбирать за меня и завёл в настройках отдельное поле «группа по умолчанию»: товар без родителя уезжает в её категорию, а если поле пустое — уезжает без категории, и приёмка про него честно скажет.
Это ровно та развилка, ради которой человек в проекте и нужен. Куда девать товары без группы — вопрос не к коду, а к владельцу магазина, и на другой базе ответ будет другим. Хороший агент такие вопросы поднимает наверх. Плохой решает молча — и о его решении вы узнаёте на продуктивной базе.
Админка обмена, которую агент сделал сам
Форму администрирования я в ТЗ обозначил одной строкой — «сделай удобную админку». Получилось лучше, чем я рассчитывал: три закладки (подключение, что выгружать, расписание), кнопки «Записать настройки», «Проверить соединение», «Выгрузить всё», «Выгрузить очередь» и подменю служебных команд. Внизу — состояние: сколько позиций в очереди и сколько уже сопоставлено с сайтом.
Расписание регламентного задания агент тоже настроил из этой формы. Причём настраивал он его не в конфигураторе: он опубликовал базу, зашёл в неё обычным веб-браузером, заполнил поля, применил настройки и запустил фоновое задание — ровно так, как это делал бы человек.
Браузер тут не для красоты — это единственный доступный путь. Код одного расширения не видит объектов другого, поэтому мой MCP-сервер, который сам живёт расширением, ни настройки записать, ни обмен запустить не может: он видит данные типовой конфигурации, но не мои новые регистры. Мостом стал веб-клиент. Побочная выгода оказалась приятнее самой находки: это ровно путь пользователя, так что проверка обмена заодно проверяет форму, а не обходит её стороной.
Витрина: дизайн приехал markdown-файлом
Оформление магазина я отдал отдельным заходом, уже после того как каталог доехал: оформлять пустую витрину нечего.
Дизайн-система приехала одним markdown-файлом — палитра, типографика, сетка, скругления, кнопки, тёмная витрина на стекле. Никаких макетов в графическом редакторе, только описание словами и значениями. По нему агент собрал дочернюю тему к стандартной теме магазина и не переопределил ни одного её шаблона, всё сделал точками расширения. Причина взрослая: переопределённый шаблон расходится с родительской темой при её обновлении и молча теряет её правки.
Дальше началось то, что знает любой верстальщик, а от нейросети не ждёшь. Каталог упорно оставался колонкой карточек шириной в одно слово: правило родительской темы весило больше, хотя файл темы подключался последним. Агент не стал давить это принудительным приоритетом — а он бы сработал — и выровнял вес правил. Логика та же, что у живого разработчика: первое «сделаю через !important» в проекте означает, что и следующую правку придётся делать так же.
Самое интересное — как он проверял результат. Формальная проверка говорит «дизайн-система применена», но не говорит «витрина хороша»: ни один инструмент не видит, что карточка разъехалась на две колонки, а счётчик товаров встал напротив чужой ветки дерева. Поэтому агент открывал страницы браузером и снимал экран в двух ширинах — 1280 и 360 пикселей — и смотрел глазами. По снимкам он и нашёл, что чинить: белую заглушку картинки, которая на тёмной витрине была самым ярким пятном страницы; счётчик, уехавший к соседней строке; текст кнопки меню, наезжающий на иконку на узком экране. Заодно написал русские числительные — иначе на главной так и висело бы «1 корней дерева» и «34 товаров».
Как агент отлаживал сам себя
Вот приём, который мне нравится больше всего.
У моего MCP-сервера есть инструмент выполнения запроса к базе. Когда агент делал выгрузку и она не срабатывала — товар не появился на сайте, категория не создалась, — он сам лез в лог обмена запросом и доставал оттуда полную картину: что отправлялось, что ответил сайт, на каком объекте всё сломалось. И дальше правил код по факту, а не по догадке.
Именно поэтому в ТЗ стоит закладывать свой регистр логов, а не ограничиваться журналом регистрации платформы. Свой регистр агент читает запросом; журнал регистрации так не почитаешь.
Три случая, когда всё выглядело зелёным
Самое дорогое в этой работе — не ошибки в коде. Ошибку в коде видно: она падает. Дорого стоит другое — когда всё отчитывается успехом, а работы нет.
Раскатка отчиталась, а расширение до базы не доехало. Сборка печатала «загружено», «конфигурация базы данных обновлена», «синтаксический контроль чист» — и при этом в базе жила прежняя версия расширения: раздел в интерфейсе не появлялся, регламентного задания не было. Причина — один пропущенный ключ в команде обновления базы: для конфигурации его достаточно, для расширения нет. Ни одного сообщения об ошибке. Молча.
Сверка сказала, что не доехал ни один товар, — а доехали все. Код номенклатуры в «Управлении торговлей» хранится строкой фиксированной длины, то есть с хвостовыми пробелами. Они уехали на сайт в артикул, сверка сравнивала артикул сайта с обрезанным кодом и не находила совпадений ни по одной позиции. Выглядело как «обмен не работает», хотя обмен отработал.
Приёмка была зелёной на мёртвом обмене. Пароль приложения на сайте перевыпустили, а в настройках 1С остался старый — обмен получал отказ доступа. Проверка при этом ходила на сайт своими учётными данными, а не через 1С, и сверяла состав, который доехал раньше. Пока номенклатуру никто не менял, отчёт оставался зелёным.
Отсюда правило, которое я теперь пишу в ТЗ отдельной строкой: проверять по данным на той стороне, а не по выводу инструмента. Расширение применено не тогда, когда сборка так сказала, а когда в базе видна его новая версия. Товар уехал не тогда, когда обмен отчитался, а когда он открывается на сайте.
Сколько времени и токенов ушло на обмен 1С с сайтом?
Разделение по моделям у меня такое: техническое задание пишу на сильной модели (Opus), саму разработку по готовому ТЗ можно спокойно отдавать Sonnet. Haiku для этой работы слабовата.
По ресурсам: 2,5 часа и чуть больше 600 тысяч токенов. Цифра великовата, и я знаю почему — я забыл подключить MCP-сервер поиска по метаданным конфигурации. Без него агент разбирал выгруженные XML-файлы конфигурации напрямую, а выгрузка 1С в XML многословна до неприличия: формы, модули, все свойства объекта. Отсюда и раздутый контекст. С подключённым MCP похожие задачи обходятся в разы дешевле — сервер отдаёт сжатую выжимку по объекту вместо простыни.
Прикиньте разницу на своей конфигурации:
Про подписку. Я сижу на Claude Max за 100 долларов в месяц и в лимиты упираюсь редко — только когда параллельно веду несколько проектов. На весь рабочий день обычно хватает. Начинать я советую не с этого: возьмите тариф за 20 долларов, посмотрите, устраивает ли вас процесс, научитесь пользоваться — и переключайтесь, когда упрётесь. За помощника, который пишет такие проекты, сто долларов в месяц — недорого.
Чем опасно отдавать конфигурацию 1С агенту целиком?
Полностью отдать агенту конфигурацию и сказать «напиши мне вот это» — рискованно. Он что-то напишет. Но с большой вероятностью накосячит: получатся кривые XML-файлы, а потом на рабочей базе вы поймаете ошибку потока и не поймёте, откуда она взялась.
Поэтому вторая по важности часть Harness (после контекста) — это набор готовых, протестированных скриптов вокруг разработки: выгрузка, загрузка, сборка, проверка. Агент не свободно творит с файлами конфигурации, он вызывает проверенные операции.
Побочный эффект, которого я не ждал: агент нашёл в этой обвязке две ошибки, и обе мои. Первая — та самая, из-за которой расширение не доезжало до базы. Вторая тихо переписывала концы строк в главном файле выгрузки расширения при каждой смене версии: платформа так файлы не пишет никогда — в эталонной выгрузке это правило не нарушает ни один из 9797 XML-файлов. Обе нашлись не глазами, а потому что агент упёрся: работа не шла. И ни одну он не стал молча править — в ТЗ было записано, что общие инструменты трогать нельзя, поэтому он доложил о находке и обошёл её у себя. Границы работают в обе стороны: они не только запрещают агенту лишнее, они заставляют его говорить.
Отдельная история из этого же проекта. Пока я дорабатывал агентом собственное расширение, у одного клиента база падала — с моим расширением, хотя все проверки оно проходило. Причину я нашёл, когда выгрузил расширение в XML и попытался загрузить обратно: загрузка не прошла, посыпались ошибки по языкам и синонимам. Расширение получило внутреннее повреждение структуры, которое никак не проявлялось в конфигураторе и не ловилось ни одной проверкой. Скорее всего я когда-то правил его на платформе с багом. Восстанавливать пришлось по старым версиям расширения, накатывая туда нормальные изменения.
Мораль простая: цикл «выгрузить в XML → загрузить обратно» — это тест целостности, а не техническая формальность. Агент такой цикл выполняет постоянно, и повреждение всплывает сразу, а не через полгода на продуктивной базе.
Куда это масштабируется
На тиражном решении система работает так же, только объём больше. Решение живёт в трёх версиях: вторая — старая, но на поддержке, третья — текущая, четвёртая — будущая, в виде сервиса. Клиент пишет: «Илья, вот это не работает». Я говорю агенту: проанализируй эту категорию, сделай обновление и выпусти его для нужной конфигурации. Он анализирует, добавляет реквизиты, правит формы, дописывает проверки — и раскатывает изменения по версиям вверх и вниз, а заодно между разными конфигурациями: «Управление торговлей 11», «Розница», «Управление торговлей 10.3».
Ещё две вещи, которые сильно поднимают качество работы агента и стоят потраченного времени.
Своя документация как MCP-сервис. С WordPress проблем нет — документации много. Но если сервис малоизвестный или документация закрытая, попросите агента выкачать сайт документации целиком и собрать себе из него MCP-сервис. Дальше он ходит с вопросами туда, а не ищет в интернете и не додумывает.
Контекстная подсказка платформы 1С. У агента подключена вся встроенная справка — та самая, что открывается по Ctrl+F1. Благодаря ей он не выдумывает несуществующие методы, а это главная болезнь нейросетей на 1С. Как этот механизм устроен, я разбирал в статье про MCP-сервер для 1С, а общий процесс работы с агентом на конфигурации — в гайде про Claude Code для 1С.
Что осталось недоделанным?
Честный список того, чего в этой итерации нет:
- остатки по складам — цена вида цены из настроек на сайт уезжает, остаток нет: под него нужны своя очередь и своя подписка;
- выгрузка картинок номенклатуры — не делалась;
- обмен заказами с сайта в 1С — не делался;
- очереди (RabbitMQ и подобное) — не поднимались; при необходимости агент поднимет стек в Docker и переведёт обмен на очереди, но в задачу это не входило.
По моей оценке это ещё пара часов работы агента — после чего сервис становится полноценным двусторонним обменом.
Итог, ради которого всё затевалось: по моей оценке 90 % рутинной разработки я автоматизировал. Задачу ставлю промптом, результат проверяю визуально — через сравнение и объединение, когда заливаю изменения в базу клиента. Смотрю, что ничего лишнего не приехало. Всё остальное делает агент.
Если хотите так же — вся обвязка, скрипты, MCP-серверы и скиллы разбираются на моём флагманском курсе «ИИ для 1С»: там мы собираем эту систему по кубикам и учимся писать для неё технические задания, потому что именно ТЗ, а не модель, определяет результат.