Библиотечный корпус · 12 мин
Зачем AI-разработке 1С версионированный библиотечный корпус
Версии API и стандартов, правила команды и кандидаты на замену самописного кода.
Когда агенту поручают интеграцию или изменение в конфигурации, одного графа вызовов мало. Граф показывает, где код связан с кодом. Он не отвечает сам по себе, разрешён ли конкретный метод для нужной версии платформы, какую сигнатуру имеет обменный API и какие правила разработки приняла команда.
Для этих вопросов нужен отдельный корпус знаний. В LEM библиотечный корпус хранит и отдаёт агенту материалы с указанными источником и версией: код библиотек, документацию API, стандарты, схемы интеграций и другие разрешённые материалы. Это самостоятельный контур работы с знаниями. Его можно использовать до подключения большой проектной конфигурации: например, найти метод в нужной версии БСП или проверить контракт интеграции.
Чем библиотечный корпус отличается от папки с документами
В обычной папке поиск возвращает файл, а разработчик сам устанавливает, к какой версии относится фрагмент и можно ли ему доверять. В LEM материал получает идентификатор библиотеки, источник и версию. Поиск можно ограничить этими координатами. Поэтому одинаковое имя метода в двух релизах не должно смешиваться в один безымянный ответ.
Версия здесь не декоративная подпись. Если команда поддерживает два продукта на разных релизах, агенту нужен правильный вариант справки и кода для каждого из них. Внутренний стандарт команды тоже может меняться: найденное правило должно относиться к тому выпуску стандарта, который принят в проекте. Сведения из старой версии полезны для сравнения, но не становятся автоматически рекомендацией для новой.
Корпус допускает разные виды исходников. Код BSL разбивается по процедурам и функциям; подготовленная Markdown-документация — по смысловым разделам; XSD-схема сохраняется вместе со структурным представлением элементов и типов. Для справки платформы существует отдельный путь загрузки HBK. Эти способы помогают искать не только совпадающее слово, но и относящийся к вопросу контракт.
Почему граф без правил может привести к неверной правке
Представим задачу: добавить обмен заказами. Граф проекта покажет, где вызывается существующая процедура отправки и какие модули она затронет. Но граф не сообщает, что внешняя система требует обязательное поле, запрещает определённое значение или принимает схему только версии 2.1. Эти условия лежат в документации и XSD. Точно так же список вызывающих функций не заменяет стандарт команды о том, как оформлять ошибки и возвраты.
Рабочий порядок для агента шире одного поиска:
- Определить проект и целевые версии платформы, БСП и прикладных библиотек.
- Найти требуемый метод, правило или схему в подходящем библиотечном источнике.
- Проверить, откуда взят фрагмент, какая у него версия и что именно он утверждает.
- Посмотреть проектный код и связи, чтобы выбрать место изменения.
- Проверить кандидат правки статическим анализом и, когда задача зависит от поведения базы, испытать его в 1С.
Библиотечный источник даёт норму и контракт, а проектный индекс — фактическую реализацию и область изменения. Вместе они позволяют задать агенту предметный вопрос: «Как изменить этот обработчик под схему 2.1 с учётом версии БСП в нашем проекте?» Ответ становится проверяемым, когда в нём видны и место в коде, и версия источника правила.
Когда стандартная библиотека может заменить самописный код
Представим, что при ревью обработки обнаружилась своя процедура для задачи, которую уже решает БСП или внутренняя библиотека команды. LEM позволяет запросить кандидатов на замену из выбранного библиотечного корпуса. Он сопоставляет имена и сигнатуры, ищет близкие по смыслу реализации и ранжирует найденное с учётом источника и версии. Агент получает не абстрактный совет «используйте стандартную функцию», а конкретные варианты, которые можно открыть и сравнить с текущим кодом.
Такой поиск полезен и при плановом рефакторинге: можно поручить агенту найти самописные реализации, для которых стандарт проекта требует использовать БСП, затем подготовить адресные правки для ревью. Кандидат на замену не равен готовой правке: нужно проверить параметры, возвращаемое значение, поведение на данных и применимость именно к версии библиотеки проекта. После изменения помогают проектный анализ влияния, статические проверки и тесты в 1С.
Что означает «ответ с доказательством»
LEM различает найденный фрагмент и строго установленный факт. Текст стандарта или справки может быть найден по смыслу, но само наличие текста ещё не означает, что все его требования автоматически проверены на всём проекте. Для части структурных фактов доступна точная проверка по индексированному снимку; другие результаты остаются поисковыми кандидатами или требуют человека.
Поэтому правильный ответ агента не ограничивается фразой «так принято в БСП». Он называет библиотеку и версию, показывает исходный фрагмент, объясняет, к какому месту проекта относится правило, и честно отмечает непроверенное. Если версия не указана или источник недоступен, агенту нельзя подменять это уверенным советом.
Где это полезно помимо крупных внедрений
Большой проект с несколькими расширениями действительно получает много пользы от графа и анализа влияния. Но библиотечные вопросы возникают и у небольшой команды: подобрать API для конкретного релиза, понять формат обмена, проверить соглашение по коду, сравнить старую и новую документацию. Для этих задач не требуется сначала построить граф всей организации.
Практический следующий шаг — открыть демонстрацию библиотечного корпуса и проверить, как задаётся версия источника и как ответ ссылается на найденный материал. Для работы с собственными библиотеками и проектным кодом нужен отдельный доступ к пилоту; состав доступных корпусов следует проверять для своего развёртывания.