Основа · 12 мин
Знания — фундамент. Библиотека — несущая конструкция
Почему проверяемое знание должно появиться раньше генерации кода.
Агент может быстро написать процедуру, но скорость ответа не делает ответ правильным. Если под ответом нет проверяемого знания о платформе, внутренних соглашениях и ограничениях версий, пробелы заполняются наиболее правдоподобной догадкой. Она может выглядеть убедительно — и всё равно оказаться ошибкой.
Здесь показан принцип работы с библиотечными знаниями. Сведения о вызовах, метаданных и выполнении кода относятся к отдельной проектной части; она не входит в публичный демонабор.
01 · Проблема
Агенту недостаточно «знать 1С вообще»
Даже знакомая на вид задача в 1С существует сразу в нескольких системах координат. Платформенная процедура может быть доступна на клиенте, но не на сервере. Функция собственной прикладной библиотеки 1С может отсутствовать или быть устаревшей в целевой версии. Фрагмент из похожей конфигурации может использовать другой формат данных, нарушать принятые правила вызова, проверки прав или фиксации ошибок.
Обычный поиск помогает найти совпадение. Он не отвечает сам по себе, можно ли применить найденное здесь: в этой версии, в этом контексте выполнения и с этими требованиями. Без устойчивой базы агент смешивает документацию, прошлые примеры и вероятные продолжения текста.
02 · Состав основания
Что входит в библиотечный фундамент
Здесь важно не путать два разных понятия. Прикладная библиотека 1Ссодержит исполняемый код: общие модули, процедуры и функции. Библиотечный корпус LEM содержит знания об этом коде: назначение, версии, правила применения и ограничения. Такой корпус можно версионировать, искать и предъявлять как основание ответа.
Например, для авторской серверной процедуры обработки заказа знание о параметрах экспортной функции общего модуля можно хранить в библиотеке. Но утверждение «именно эта процедура вызывает функцию» появляется только после чтения конкретного проекта. Если исходников проекта нет, честный результат — подтверждённый библиотечный контракт и открытый вопрос о месте вызова.
Возможности платформы 1С
Процедуры, функции, объекты, параметры, типы и доступность на клиенте или сервере.
Форматы и правила вызова
Обязательные поля, допустимые значения, возвращаемые данные и условия выполнения.
Собственные библиотеки 1С
Разрешённые функции общих модулей, порядок вызова и правила интеграции.
Правила разработки
Именование, проверки значений, обработка исключений, права и фиксация ошибок.
Совместимость
Версия платформы, режим совместимости, версия библиотеки, контекст выполнения и расширения.
Известные ошибки
Симптом, условия возникновения, затронутая версия и проверенный обходной вариант.
Подтверждает или опровергает вывод.
Показывает, как правило проявляется здесь.
Даёт устойчивое основание для поиска решения.
Каждый следующий слой уточняет предыдущий, но не подменяет его.
03 · Граница
Библиотека не притворяется конкретным проектом
Запись в библиотечном корпусе может утверждать, какой формат данных и какие правила вызова действуют для указанной версии. Такой набор правил иногда называют контрактом. Но библиотека не должна выдумывать, какой общий модуль использован в вашей конфигурации и какие процедуры его вызывают. Это уже контекст проекта: исходники, процедуры и функции, связи вызовов, метаданные и настройки запуска.
«Для версии X операция принимает тип Y и не поддерживается в серверном контексте».
«В общем модуле A используется разрешённая функция B; вызывающие процедуры находятся в C и D».
«Точный фрагмент подтверждает аргументы, а тест целевого сценария прошёл».
Если одного слоя нет, это должно быть видно в ответе. Хорошая формулировка отделяет подтверждённый факт от гипотезы, которую ещё предстоит проверить.
04 · Сквозной разбор
Синтетический примерВыбрать безопасный вызов для серверной процедуры
Все имена, версии и результаты ниже придуманы специально для демонстрационного корпуса. Они не описывают реальный API платформы 1С.
«В серверной процедуре нужно получить текущую организацию. Найди разрешённый способ для версии Demo 1.3, укажи ограничения и покажи, на какие источники опирается ответ».
Допустимый контекст и тип результата.
Разрешённая функция вместо прямого вызова платформы.
Изменение способа и известное ограничение.
Найдена вызывающая процедура и связанный общий модуль.
05 · Сравнение пути
Один вопрос — два качества ответа
Правдоподобный фрагмент
- похож на рабочий пример;
- не указывает область применимости;
- смешивает прямой вызов и разрешённую функцию общего модуля;
- не отделяет факт от предположения.
Проверяемая рекомендация
- называет формат данных и синтетическую версию;
- указывает разрешённую функцию общего модуля;
- связывает правило с найденной процедурой проекта;
- перечисляет обязательные проверки.
Здесь сравнивается структура ответа, а не скорость или стоимость. Эти показатели требуют отдельного воспроизводимого измерения.
Что можно вызвать?
Формат и версия.
Факт проекта.
Точный источник.
Тест или остановка.
Релевантный кандидат становится решением только после проверки версии и проектного контекста.
06 · Применимость
Версия меняет смысл рекомендации
Фраза «используйте функцию X» неполна. Знание должно хранить область применимости: целевую версию, зависимость от библиотеки или расширения, статус способа, известный дефект и замену. В противном случае корректный старый пример превращается в новую ошибку.
В рабочей библиотеке каждая ячейка должна вести к источнику и условию проверки. Цвет сам по себе доказательством не является.
07 · Полный цикл
Проверки замыкают знание
- 01
Агент фиксирует задачу, целевую версию и ограничения.
- 02
Библиотечный корпус возвращает формат, правила вызова, область применимости и известные риски.
- 03
Контекст проекта показывает реальную процедуру или функцию и связанные участки.
- 04
Точный источник подтверждает, что найден именно нужный факт.
- 05
Изменение проходит статическую проверку, тест и безопасный запуск.
Библиотечный корпус не заменяет проверку синтаксиса, тесты и выполнение кода. Он уменьшает число неправильных гипотез до того, как агент предложит изменение. Если запуск опроверг рекомендацию, нужно исправлять не формулировку ответа, а источник расхождения: версию, контекст или исходное предположение.
08 · Вывод
Знание делает основание видимым
Без стационарных знаний агент импровизирует — иногда удачно, иногда опасно. Библиотека делает основу повторяемой. Контекст проекта уточняет, как правило проявляется именно здесь. Доказательство и запуск проверяют, не превратился ли убедительный ответ в красивую ошибку.
Знание → контекст → доказательство → проверка