Полгода назад фраза «ИИ напишет вам конфигурацию» вызывала у меня ту же реакцию, что и у вас сейчас: ну да, накидает справочников, а потом ты неделю разгребаешь.
Сегодня я показываю два эксперимента, между которыми прошёл месяц. В первом ИИ-агент собрал учётную конфигурацию по ТЗ — с планом счетов, субконто и проведением документов; я изредка подталкивал его промтами. Во втором он прошёл путь целиком сам: сгенерировал себе документацию, изучил платформу, написал код, нашёл и починил собственные ошибки — и отдал результат только после зелёных проверок. Моё участие во втором эксперименте — один промт. Дальше я не нажал ни одной клавиши.
Оба эксперимента записаны на видео одним дублем: ошибки не вырезаны — что пошло не так, то в кадре. И оба сделаны не топовой моделью, а недорогой GLM с тарифом порядка 18 долларов в квартал.
Дисклеймер честности: OneBase — моя авторская платформа, так что я лицо заинтересованное. Именно поэтому в статье будут точные цифры, таймкоды и список того, что пока работает криво.
Что за платформа
OneBase — открытая бизнес-платформа, идеологически близкая 1С: справочники, документы с табличными частями, регистры накопления и сведений, план счетов с субконто, проведение, отчёты, управляемые формы. Технически — один исполняемый файл на Go, который исполняет прикладную конфигурацию поверх PostgreSQL или SQLite. Открытая — в прямом смысле: исходники лежат на GitHub под лицензией MIT. Язык модулей — русскоязычный DSL, до степени смешения похожий на встроенный язык 1С: Процедура ОбработкаПроведения, Движения.Остатки.Добавить(), запросы с ВЫБРАТЬ и виртуальными таблицами .Остатки().
Ключевое отличие, из-за которого и написана эта статья: вся конфигурация — это текстовые файлы. Метаданные — YAML, логика — .os-модули, формы — YAML + модуль обработчиков. Никаких бинарных cf-файлов, никакой выгрузки-загрузки. Папку с конфигурацией можно открыть в любом редакторе, положить в git — и, что важнее всего, отдать ИИ-агенту.
(Конечно, конфигурацию можно хранить и в таблицах базы как в 1С, но это уже про прод и большие внедрения а не разработку, надеюсь про это ещё будут статьи)
дерево файлов проекта конфигурации — catalogs/, documents/, registers/, src/, forms/
Почему «ИИ + учётная платформа» — это обычно больно
Все, кто пробовал скрестить нейросети с 1С, упирались в одно и то же:
- метаданные живут в бинарном формате или гигантских XML-выгрузках — агент их может анализировать и даже менять (иногда не очень успешно) но чтобы доставить изменения даже до тестовой базы нужно развернуть целый конвеер (который ещё и костыльный, собранный энтузиастами)
- обратная связь медленная: чтобы узнать, что запрос кривой, надо загрузить конфигурацию, запустить предприятие и ткнуть кнопку;
- у модели нет способа самостоятельно проверить результат — а без проверки агент превращается в генератор правдоподобного мусора.
Между тем сила современных ИИ-агентов не в том, что они не ошибаются. Ошибаются, ещё как. Сила — в замкнутом цикле: сделал → проверил → увидел ошибку → исправил → снова проверил. Дайте агенту быстрые и честные инструменты проверки — и он доведёт задачу до конца без вас. Не дадите — будете сами носить ему сообщения об ошибках, как курьер.
OneBase я с самого начала строил как платформу, в которой этот цикл замыкается из командной строки, без запуска UI. Дальше — два эксперимента, которые показывают, что из этого вышло.
Эксперимент 1. Конфигурация по ТЗ — без единой строчки кода
«Разработка конфигурации для OneBase с помощью ИИ» (~30 минут)
Ссылка:
https://youtu.be/of_h5L8a9FA
Завязка такая: подписчик прислал мне небольшую 1С-конфигурацию для учёта производства кондитерских изделий — план производства, спецификации, выпуск, реализация — и тестовый расчёт, который должен сойтись в конце.
Первое, что я сделал, — не стал писать ТЗ руками. Я выгрузил конфигурацию в файлы и прогнал через ИИ: «опиши, что здесь сделано, как ТЗ на разработку с нуля». На выходе — увесистый документ: подсистемы, справочники, план счетов, виды субконто, документы с алгоритмами проведения. Плюс тест-кейсы от подписчика: какие остатки и проводки должны получиться на контрольном примере. Реверс-инжиниринг, который раньше занимал день вдумчивого клика по конфигуратору, здесь занял один промт (таймкод 2:12 в первом видео).
Маленький совет из практики: я прогнал конфигурацию через модель дважды — вторым заходом получил «описание проекта» от другой сессии. Это вообще проверенный приём: даже одна и та же модель на втором-третьем проходе находит то, что пропустила на первом.
фрагмент ТЗ, сгенерированного ИИ по выгрузке 1С-конфигурации — раздел с документами и алгоритмом проведения]
Дальше — пустая папка и три команды:
onebase init кондитерка # скелет проекта + AGENTS.md и CLAUDE.md
onebase init кладёт в проект файл AGENTS.md — это сгенерированное самой платформой руководство для ИИ-агента: структура конфигурации, справочник языка, частые грабли запросов и главное — какие команды запускать для проверки себя. Агенту не нужно гуглить документацию: всё, что он должен знать о платформе, уже лежит в его рабочей папке.
Запускаю Claude Code — консольное приложение от Anthropic, которое само читает и пишет файлы проекта. Но не с дорогой моделью, а с подключённой по совместимому API GLM 5.1 — недорогой китайской моделью (как подключить её к Claude Code — у меня есть отдельное видео: ССЫЛКА). Промт — одна строка: «построй конфигурацию строго по пунктам 2 - 5 ТЗ». И ушёл заниматься своими делами.
Дальше агент работает сам (9:40–14:00, финал показан таймлапсом): сканирует папку, читает AGENTS.md, составляет план, создаёт справочники, документы, регистры, модули проведения — и после каждого шага прогоняет onebase check. Вернулся я к финальной сводке: все слои конфигурации прошли валидацию, потрачено 27 тысяч токенов и 7% лимита. Поясню метрику: у тарифа GLM есть потолок потребления, который обновляется каждые пять часов, — агент откусил от этого окна лишь 7%. То есть таких конфигураций можно собирать по десятку в день. Сказал «делай дальше» — он дописал модули проведения остальных документов. Итого на всё — около часа с моими отлучками и 19% лимита.
Потом у меня случилась пауза на четырнадцать дней — к папке я не прикасался: дата изменения файлов видна в кадре на таймкоде 19:02. Возвращаюсь, запускаю OneBase (напомню: это один exe), добавляю базу, SQLite для теста — и захожу в конфигуратор. Всё на месте: подсистемы, справочники, документы, регистры сведений и бухгалтерии, обработки проведения (21:05). Формы агент не рисовал — в OneBase они генерируются автоматически, а управляемые нужны только там, где хочется кастомизации.
конфигуратор — дерево объектов конфигурации «Кондитерка»
Самая интересная часть — приёмка. В ТЗ ведь лежали тест-кейсы. Вторым промтом (уже вышла GLM 5.2 — прогресс не ждёт) я попросил: «сделай обработку, которая создаст тестовые данные по тест-кейсам и проверит результат». Агент написал обработку, я нажал «Выполнить» — и получил таблицу «факт / ожидаемое» по остаткам и проводкам (27:15). Выборочно сверил спецификацию с ТЗ — мука пшеничная, сахар-песок, масло сливочное — сходится. На самом деле сошлось не сразу а с нескольких попыток, это и натолкнуло заставило меня расширить ИИ инструменты
обработка «Приёмка по ТЗ» — таблица сверки факт/ожидаемое
Отдельная радость — казусы. В исходной 1С-конфигурации был справочник с гордым именем «Болвашка», и агент, которого просили «сделай как здесь», честно воспроизвёл и его. ИИ не задаёт лишних вопросов — что в ТЗ, то и в продукте. Делайте выводы о качестве своих ТЗ.
Что я понял после первого эксперимента: работает, но процесс держится на мне. Это я решал, когда сказать «делай дальше», это я просил обработку приёмки отдельным промтом. Хотелось, чтобы агент проходил весь путь сам. да и проверку данных пришлось несколько раз толкать, зачем если есть ТЗ.
На доработку ушёл месяц (на самом деле конечно же нет, просто не было времени заснять видео).
Эксперимент 2. Месяц спустя: один промт — и уйти
«Полный цикл: агент сам пишет, проверяет и чинит конфигурацию» (~27 минут)
Ссылка:
https://youtu.be/JxQTz-dYoJI
За месяц у платформы отросла инструментальная обвязка — набор headless-команд, ради которых, собственно, и затевалась статья. Вот чем агент теперь может проверять себя, не запуская никакого UI:
И сверху — регламент (в видео я называю его агент-протоколом): что агент обязан запускать и чем доказывать результат. Тот же принцип зашит и в AGENTS.md — там появился раздел «Проверка результата», где агенту прямым текстом сказано: зелёный check ещё не значит «работает». Изменил проведение — докажи через procrun и query. Сделал отчёт — покажи report explain --sample. Финальный ответ — только после зелёных проверок и трассировки инструментов: журнала всех вызовов onebase-команд с результатами, который агент прикладывает к отчёту.
Условия второго эксперимента жёстче первого. В папке проекта — единственный файл: агент-протокол, короткий регламент со списком инструментов и требованием доказательств. Больше ничего — даже AGENTS.md с описанием платформы агент сгенерирует себе сам (это видно на 4:12). Промт: «создай мини-конфигурацию МиниКон для организатора конференции: справочники Докладчики, Залы, Темы, документ Доклад, отчёт, дашборд с KPI, обработка заполнения демо-данными. Финальный ответ — только после трассировки инструментов и зелёных проверок». Всё. Модель — та же недорогая GLM 5.2. Запустил — и пошёл наливать чай.
Дальше произошло то, ради чего я в это ввязался. Агент (таймкоды по второму видео):
- 2:27 — прочитал регламент и нарезал себе задачи;
- 4:12 — обнаружил, что в папке нет AGENTS.md, и сам сгенерировал его командой ai-guide;
- 4:48 — снял машинный контракт конфигурации (describe) и посмотрел канонические примеры объектов (examples) — изучил платформу, как новый сотрудник читает вики в первый рабочий день;
- 8:26 — начал писать метаданные: справочники, документ «Доклад», управляемую форму;
- 9:37 — нашёл собственную ошибку ещё до запуска check;
- 11:02 — вошёл в замкнутый цикл: check → ошибка → исправление → check, без моего участия;
- 11:45 — проверил формы, отчёт и виджеты: forms validate, report explain, widget explain, прогнал обработку через procrun;
- 13:18 — обнаружил, что демо-данные сломаны (KPI «докладов сегодня» показывал ноль при пяти докладах), сам диагностировал и починил;
- 14:09 — отчитался: все обязательные проверки регламента зелёные.
терминал — агент получает ошибку и следующим же шагом её исправляет
37 минут. Около 20% пятичасового лимита модели за 18 долларов в квартал. Ноль моих нажатий.
финальный отчёт агента с трассировкой инструментов
Запускаю базу. Дашборды «Заполненность залов» и «Статусы докладов», KPI-виджеты «докладов сегодня / всего», справочники с демо-данными, документ, отчёт «Расписание конференции» (16:36). Открываю встроенный ИИ-чат и спрашиваю: «Какой зал наиболее загружен?» Помощник сам строит запрос к данным и возвращает табличку: Главный — 4 доклада, Зелёный — 3, Мастерская — 2 (18:34).
дашборд «МиниКон» с KPI-виджетами]
ИИ-чат в базе — ответ на вопрос «Какой зал наиболее загружен?»]
Важная мысль, которую я проговариваю в видео (11:02): инструменты нужны не потому, что агент без них не справится. Справится. Просто это будет дольше и потребует вас в роли посредника: запустить, посмотреть на ошибку, скопировать её агенту. С инструментами посредник не нужен — цикл замыкается без человека.
Полный цикл — это не только «сгенерировать»
«ИИ может полный цикл» — главный тезис статьи, поэтому разложу цикл по стадиям и покажу, чем закрыта каждая.
Анализ и ТЗ. ИИ реверс-инжинирит существующую конфигурацию в техзадание (эксперимент 1). Или пишет ТЗ с нуля по вашему рассказу — это уже давно умеет любой чат.
Разработка. Агент в Claude Code (или любом другом MCP-совместимом инструменте — onebase mcp к вашим услугам) пишет метаданные и код, опираясь на AGENTS.md, describe и examples.
Самопроверка. check, query, procrun, explain — замкнутый цикл без человека. Плюс onebase test для настоящих тестов с моками и JUnit-выводом — их тоже пишет агент.
Приёмка. Обработка сверки по тест-кейсам из ТЗ: «факт / ожидаемое» по остаткам и проводкам (эксперимент 1).
Развёртывание. migrate + run — и база работает. В видео я добавляю базу в лаунчер за минуту.
Доработка. Прямо в конфигураторе две кнопки.
Первая — ИИ-помощник разработчика: пишет и объясняет код, расшифровывает ошибки check человеческим языком.
Вторая — генерация каркаса (видео 2, 20:04). Пишете фразой: «журнал расписания докладов с подсветкой статусов» — и ИИ собирает файлы в изолированном staging-каталоге, сам прогоняя по ним check с циклом самоисправления. Вам показывают diff и трассировку инструментов; в конфигурацию изменения попадают только после кнопки «Применить». Во втором видео я так добавил журнал с условным оформлением и справочник «Города» (22:14) — двумя фразами. Часовой пояс в реквизиты городов агент догадался добавить сам (22:50) просто ему было видимо скучно от такого скудного ТЗ.
Эксплуатация. ИИ-чат в базе отвечает пользователям на вопросы по данным (с ролевой моделью доступа, лимитами токенов и журналом обращений — админы, выдыхайте). А из самого DSL доступны ЗапросИИ(), ЗапросИИДжейсон() и РаспознатьДокумент() — например, «умная загрузка»: скан накладной → JSON → черновик документа.
Сопровождение. doctor для здоровья базы, impact — показать, что заденет переименование, refactor rename-field --write — переименовать поле по всей конфигурации с автоматическим check и откатом при красном результате, версии конфигурации с diff и rollback.
генерация каркаса в конфигураторе — diff предлагаемых файлов и tool trace
результат работы генератора каркаса
Это не «ИИ-фича сбоку». Это конвейер, в котором на каждой стадии у агента есть инструмент и способ доказать, что сделанное работает.
Ложка дёгтя, куда без неё
Чтобы статья не выглядела рекламным буклетом — что пока не так:
- Оба эксперимента — маленькие конфигурации. Десятки объектов, а не сотни; демо всегда выглядит лучше жизни. Самая крупная база, собранная этим методом, — мой рабочий учёт разработок с телеграм-ботом и почтой: это уже вечер работы и несколько итераций промтов, а не 37 минут. Полноценную ERP так пока никто не написал — и я не обещаю.
- За качество сгенерированных конфигураций я не ручаюсь. Агент честно воспроизводит ТЗ вместе с его глупостями — помните «Болвашку»? Архитектурный надзор с вас никто не снимал.
- Формы простые. Автогенерация закрывает базовые потребности, если хотите красивый специализированный интерфейс — нужно заморочится с описанием расположения элементов на форме.
- Часть возможностей в статусе «тестируем» — ИИ-чат, генерация каркаса, вкладочный режим. Работают, но обкатка идёт.
- Агент работал 37 минут там, где опытный разработчик OneBase справился бы… нет, не быстрее. Но модель попроще может и час думать — правда, ваше время при этом не тратится вообще.
Я бы, конечно же, рекомендовал разрабатывать топовыми моделями!
Выводы
Два видео с разницей в месяц показывают траекторию: от «агент пишет код, а я дирижирую» до «агент проходит цикл сам, а я принимаю работу». Разница — не в модели (обе дешёвые), а в инструментах и регламенте: текстовые метаданные, headless-проверки, исполняемые доказательства и протокол, который требует их предъявить.
Для себя я этим же способом собрал вполне боевую конфигурацию — учёт моих разработок, продающихся на Инфостарте, с телеграм-ботом и интеграцией с почтой. Не за 37 минут — за вечер с несколькими итерациями. Но вечер вместо недели — это всё ещё другая экономика разработки.
Если хотите повторить: OneBase — https://github.com/ivanarama/onebase, оба видео встроены выше, все команды из статьи — в комплекте одного исполняемого файла. Из знаний нужен хотя бы один язык — русский подойдёт.
Ссылки по теме:
- Releases
- Демо база онлайн Демонов 12345
- Видео 1 Видео 2 Видео 3 Видео 4
- Документация + в репозитории: README.md, QUICKSTART.md, DEVELOPER.md, docs/features.md
- Примеры конфигураций: examples/ Программа управления торговлей (ПУТ)
Пишите комментарии, пишите конфигурации, автоматизируйте!
Вступайте в нашу телеграмм-группу Инфостарт