Эта статья опубликована на Infostart
Если использовать нейросеть в 1С как обычный чат, она почти всегда оставляет разработчику самую дорогую часть работы: ручную выгрузку, перенос кода, проверку и бесконечные уточнения. В этой статье покажем, как вместо переписки с ИИ собрать практический контур, где агент работает по правилам, помнит контекст проекта, меняет файлы конфигурации и доходит до проверяемого результата.
Почему обычная переписка с ИИ не решает проблему
Обычный чат дает быстрый старт, но почти никогда не закрывает реальную операционную нагрузку. Разработчик по-прежнему остается интегратором всех шагов: сам объясняет контекст, сам переносит изменения, сам запускает проверку и сам восстанавливает историю предыдущих решений.
- каждая новая итерация требует заново подгружать контекст;
- модель легко предлагает правдоподобное, но неприменимое решение;
- токены тратятся на пересказ среды, а не на движение к результату;
- качество процесса зависит не от силы модели, а от терпения разработчика.
| Подход | Как работает | Что теряется | Итог |
|---|---|---|---|
| Обычный чат | Модель выдает текст, всё остальное руками | Состояние проекта, история изменений | Много рутины и уточнений |
| Чат с длинным контекстом | Разработчик докладывает фрагменты | Контекст устаревает, токены на пересказ | Не масштабируется |
| Агент в подготовленной среде | Среда и правила рядом, агент проходит по шагам | Только то, что не зафиксировано в памяти | Процесс наблюдаем и воспроизводим |
Как выглядит контур, в котором агент делает больше, чем отвечает
Ключевая идея — не отдельный промт и не отдельный фрагмент кода, а минимальный автономный конвейер. Его смысл в том, что агент должен не просто ответить, а пройти последовательность шагов, которую затем можно повторять на других задачах.
В простейшем виде цикл: агент получает задачу → выгружает конфигурацию в файлы → изучает метаданные и код → вносит изменения → загружает их обратно → запускает проверку → фиксирует результат → при необходимости повторяет.
Что нужно агенту для 1С
Агенту недостаточно просто «уметь генерировать код». Для реальной работы ему нужен технический контур действий:
| Компонент | Зачем нужен | Эффект |
|---|---|---|
| Skill | Описывает допустимые действия агента | Агент работает по понятным шагам |
| Пакетный режим конфигуратора | Вызов выгрузки, загрузки и проверки без ручного кликанья | Повторяемый цикл |
| Bat-файлы и скрипты | Стабильная точка входа для команд | Меньше хаоса |
| Файл настройки базы | Путь к ИБ и исполняемому файлу 1С | Предсказуемое окружение |
| Локальный проектный контур | Документация, выгрузка и память рядом | Контекст не распадается |
Структура проекта: рабочее место агента
| Элемент | Что хранить | Почему важно |
|---|---|---|
doc/ | ТЗ, пояснения, заметки | Документация рядом с задачей |
src/ | Выгруженные XML, BSL файлы | Агент работает с реальной структурой |
| Каталог со skill | Инструкции и команды | Поведение ограниченно и повторяемо |
| Файл настройки базы | Пути к базе и к 1С | Снижается риск неправильного контура |
spec.md, result.md | Правила, прогресс, результат | Контекст не теряется |
Зачем нужна спецификация
Файл spec.md — не бюрократия, а компактное описание границ проекта:
- версия платформы и режим совместимости;
- наличие или отсутствие БСП;
- правила именования и стандарты кода;
- договорённости по оформлению;
- порядок обновления памяти проекта.
Без спецификации агент получает слишком много свободы — а в инженерной задаче это означает больше случайных гипотез и лишних итераций.
Memory bank: внешняя память вместо повторных объяснений
Даже на средней по длине задаче агент начинает забывать: что уже проверяли, какие файлы меняли, почему был выбран текущий путь. Внешний memory bank решает эту проблему:
- контекст проекта: что за система, ограничения;
- текущий прогресс: какие шаги выполнены;
- активные решения: какие гипотезы приняты и почему;
- result.md: фиксация промежуточного и финального результата.
Критично не только наличие файлов, но и дисциплина обновления.
Полный маршрут работы агента
- Планирует шаги и определяет нужные инструменты
- Формирует или уточняет
spec.md - Выгружает конфигурацию и получает доступ к XML, BSL
- Анализирует структуру, находит нужную логику, вносит изменения
- Загружает обратно только измененные файлы
- Запускает проверку, фиксирует результат в
result.md - При необходимости — ещё одна итерация
Типовые ошибки агента
| Ошибка | Что показывает | Как контролировать |
|---|---|---|
| Неверная гипотеза о хранении | Агент не понял, где лежит артефакт | Проверять структуру заранее |
| Лишняя обработка для автотеста | Склонен добавлять промежуточные слои | Ограничения в spec.md |
| Проблемы со сборкой из XML | Работа упирается в структуру конфигурации | Проверять маршрут сборки |
Ошибки не обнуляют пользу подхода — они показывают, где нужны ограничения и проверки.
С чего начать первый пилот
- Собрать минимальный рабочий контур
- Создать каталог проекта с
doc/,src/, служебными файлами - Подготовить файл настройки базы и рабочие команды
- Подключить skill, завести
spec.mdиresult.md - Выбрать короткую задачу: реквизит, команду, печатную форму
- Дать агенту пройти полный цикл: выгрузка → анализ → код → загрузка → тест
- Сравнить выигрыш с обычной работой
Выводы
- Автономная работа агента начинается не с модели, а со среды: каталогов, настроек, skill и пакетного режима
spec.mdограничивает фантазии агента и снижает цену итераций- Memory bank нужен для сохранения контекста и прогресса
- Практическая ценность — там, где агент проходит полный цикл от анализа до проверки
- Ошибки агента — источник информации о нужных ограничениях
Реалистичный следующий шаг: собрать минимальный контур, подготовить правила, запустить агента на короткой задаче и честно сравнить результат с обычной ручной работой.