Как мы задаём агенту порядок работы с 1С

Попросить AI-агента «исправить ошибку в 1С» легко. Гораздо труднее добиться, чтобы он сначала воспроизвёл проблему, выбрал подходящую версию библиотеки, изменил нужное место, провёл проверки и честно перечислил то, что проверить не удалось. Один только доступ к исходникам не задаёт такого порядка работы.

Поэтому для собственного использования мы собираем библиотеку рабочих сценариев. Это внутренний регламент работы с задачами 1С, оформленный так, чтобы его могли читать и разработчик, и агент. Библиотека содержит не только сведения о том, что есть в проекте, но и инструкции, как действовать при доработке, новой разработке или поиске ошибки. Материалы сценариев мы связываем с версионированным библиотечным корпусом LEM, где доступны стандарты, документация и код применимых библиотек.

Разработчик подключает LEM к своему агенту через MCP — интерфейс вызова инструментов — и даёт ему доступ к рабочему проекту 1С. После этого задачу можно поставить обычными словами: «Доработай обработку», «Найди ошибку», «Напиши новую функцию». Агент уточняет условия, находит подходящий рабочий сценарий и действует по нему, вместо того чтобы каждый раз заново придумывать процесс.

Откуда берётся сценарий

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

Например, отдельные сценарии могут отвечать на разные вопросы:

• Доработка существующей функции: как найти её вызовы и контракт, оценить влияние изменения, выбрать совместимую библиотечную версию и оформить правку.
• Новая разработка: как уточнить спецификацию, проверить стандарт проекта и готовые API, определить границы реализации и подготовить проверку.
• Поиск ошибки: как воспроизвести сбой, собрать наблюдаемые факты, отделить подтверждённую причину от гипотезы и повторить исходный сценарий после исправления.

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

Карточка сценария достаточно конкретна, чтобы по ней можно было начать работу без устных пояснений. Например, для доработки внешней обработки в ней будут указаны: входная спецификация и целевой релиз; применимые стандарты и библиотеки; инструменты поиска и анализа влияния; порядок изменения; способ проверки процедур и основного пользовательского пути; состав отчёта с diff и результатами тестов. Для изменения управляемой формы или обмена набор проверок будет иным. Так библиотека описывает процесс для конкретной технологии, а не один универсальный промпт на все задачи.

Что делает агент с такой библиотекой

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

Дальше агент выполняет шаги сценария. Для поиска по исходникам и связям он может использовать LEM; для правил платформы, БСП и внутренних библиотек — материалы соответствующих версий библиотечного корпуса. Для изменения кода он фиксирует исходный снимок проекта и показывает разницу. Для проверки использует те инструменты, которые указаны в сценарии и доступны в данном развёртывании. В отчёте остаются ссылки на найденные основания, сделанная правка, фактически выполненные проверки и открытые вопросы.

Представим задачу: после доработки перестало заполняться поле документа. Сценарий поиска ошибки требует записать шаги воспроизведения и ожидаемое поведение, найти место присваивания и связанные вызовы, проверить условия и данные тестовой базы. Только после этого агент предлагает минимальное исправление. Затем он повторяет исходный случай и граничный: поле должно заполняться в нужном режиме и не получать значение там, где этого не требует правило. Если тестовая база недоступна, результат остаётся гипотезой по коду, а не заявлением об исправленной работе документа.

Такой порядок полезен и разработчику без агента: требования к задаче, проверкам и итоговому отчёту видны заранее. Агенту он особенно помогает не терять шаги между поиском, правкой и приёмкой.

Проверка включена в спецификацию задачи

Когда разработчик составляет спецификацию, он указывает, нужна ли автоматическая проверка, какой уровень проверки подходит и по какому результату задача считается принятой. Это не решение, которое агент должен принимать по настроению. Для изменения процедуры расчёта можно задать входные значения, ожидаемый возврат и граничные случаи. Для ошибки в форме — шаги пользователя и результат в тестовой информационной базе. Для изменения обмена — ещё и проверку контракта на применимой версии схемы.

Шаблонная внешняя обработка для небольших проверок уже находится среди наших проектов 1С. В библиотеке хранится её описание и документация: как подготовить входные данные, вызвать доступную процедуру или функцию, сопоставить результат с ожидаемым и сохранить результат прогона. Рабочий сценарий ссылается на эту инструкцию, когда такой способ проверки подходит задаче. Если точка вызова недоступна напрямую или поведение зависит от транзакции, формы либо данных информационной базы, сценарий требует другого уровня проверки. Маленькая заготовка не делает такую зависимость «чистым» модульным тестом.

Для коротких сквозных проверок у нас есть собственные smoke-сценарии: они подтверждают, что после правки работает основной путь, и помогают быстро заметить грубую регрессию. В некоторых проектах, где нужен более развитый сценарий пользовательского поведения, мы применяем Vanessa Automation. Это сильный открытый инструмент для BDD и автоматизации проверок в 1С; мы признательны его разработчикам. Своя компактная заготовка решает более узкую задачу и не претендует на замену Vanessa Automation.

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

Что здесь означает «детерминированная разработка»

Модель не становится детерминированной только потому, что ей дали инструкцию. Мы используем это слово для управляемого процесса: на одинаковый тип задачи есть известный сценарий, явные входные данные, контрольные точки и проверяемый результат. Агент может предложить разные реализации, но не должен произвольно пропускать воспроизведение ошибки, выбор версии источника или обязательную проверку. Отклонение от сценария он объясняет и показывает на ревью.

Особенно заметна польза для небольших локальных моделей: вместо свободного выбора из множества возможных действий они получают ограниченный маршрут и нужные материалы. Более сильным моделям сценарий тоже нужен — он удерживает правила команды и критерии приёмки. Насколько это ускоряет работу и уменьшает число ошибок, следует измерять на конкретных задачах; универсальной цифры для любого агента здесь нет.

Библиотека рабочих сценариев дополняет версионированный библиотечный корпус LEM. Код и граф проекта показывают, где работать; стандарты и API объясняют, что применимо; сценарий задаёт, как пройти задачу и чем подтвердить результат. Когда все три части доступны агенту в правильных версиях, разработка становится более последовательной и понятной для проверки человеком.